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

[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 ?

-- 
Best regards,
Marek Vasut