[U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5

[Simon Goldschmidt]

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.goldschmidt at 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