Am 07.01.2019 um 21:47 schrieb Marek Vasut:
On 1/7/19 9:33 PM, Simon Goldschmidt wrote:
Am 07.01.2019 um 21:25 schrieb Marek Vasut:
On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
Am 07.01.2019 um 21:19 schrieb Marek Vasut:
On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
When debug UART is enabled on socfpga_gen5, the debug uart driver
hangs
in an endless loop because 'socfpga_bridges_reset' calls printf before
the debug UART is initialized.
After the generic fix for this in the UART driver did not work due to
portability issues, let's just drop this printf statement when called
from SPL with debug UART enabled.
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschm...@gmail.com>
Can we have an un-portable fix which at least works on SoCFPGA ? :)
This one worked on socfpga but broke rockchip:
https://patchwork.ozlabs.org/patch/992553/
However, the message below wasn't shown either with that patch applied.
The code just runs too early to enable the UART.
Do you want to keep the message (although I failed to see in which
situation it can be printed) or do you just dislike the #ifdef thing?
I'd like to keep the error message if possible. Is it possible ?
I have *never* seen this message yet. I have failed to produce a
situation where it is shown.
I believe that.
This function ('socfpga_bridges_reset') is called 5 times throughout the
code, but only *one* single time with 'reset=0' as argument (only with
0, the code in question is executed). And this is in SPL before
initializing the console and even before the debug UART can be initialized.
As I could see, the printf *is* executed on every boot (I saw the code
hanging when enabling debug UART). However, when not booting from FPGA,
it is just normal that the FPGA is not ready when running SPL. Why do
you want an error message here anyway?
I was under the impression this is an error message, but it might not be
so ? Maybe the wording is incorrect ?
Now that I re-read it, "aborting" is incorrect, yes.
So how should we proceed? This is an error message that can never be
shown (like the code is now) but breaks debug UART.
I'd say we can drop it altogether. It might only be interesint if (in
the future) that code would get called from somewhere else (i.e. later,
after console initialization).
Re-reading spl_gen5.c, there are some 'debug' calls before the debug
uart is initialized which probably would need to be removed as well, but
that's a different story...
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
