Converting to DM SERIAL for Kirkwood boards

[Stefan Roese]

Hi Pali,

On 12/20/22 09:07, Pali Rohár wrote:
> On Tuesday 20 December 2022 07:20:15 Stefan Roese wrote:
>> Hi Tony,
>>
>> On 12/20/22 02:36, Tony Dinh wrote:
>>> Hi Stefan,
>>>
>>> On Mon, Dec 19, 2022 at 4:06 PM Tony Dinh <mibodhi at gmail.com> wrote:
>>>>
>>>> Hi Stefan,
>>>>
>>>> On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh <mibodhi at gmail.com> wrote:
>>>>>
>>>>> Hi Stefan,
>>>>>
>>>>> On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese <sr at denx.de> wrote:
>>>>>>
>>>>>> Hi Tony,
>>>>>>
>>>>>> On 12/19/22 07:17, Stefan Roese wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>>> git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3
>>>>>>>> Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for
>>>>>>>> programming LD0 and LD1 eFuse
>>>>>>>> HEAD is now at 37bb396669 timer: orion-timer: Only init timer once
>>>>>>>>
>>>>>>>> This is where the Pogo V4 was frozen during boot. Among the Kirkwood
>>>>>>>> boards that I have and used for testing, it is the only one that has
>>>>>>>> CONFIG_BOOTSTAGE=y.
>>>>>>>
>>>>>>> Thanks for testing and git bi-secting.
>>>>>>>
>>>>>>>> Should I create a new post for would like to continue this topic here
>>>>>>>> in this thread?
>>>>>>>
>>>>>>> Let me check, if I can find the root cause and this problem quickly. If
>>>>>>> not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for
>>>>>>> a short while until we've fixed this issue.
>>>>>>
>>>>>> I fail to spot the problem with this small commit 37bb396669b27a. I can
>>>>>> also not reproduce this on my Armada XP board - it uses SPL though, this
>>>>>> might make a difference.
>>>>>>
>>>>>> Could you perhaps apply this attached debug patch and make sure, that
>>>>>> you have DEBUG_UART enabled in your Pogo v4 config. And boot into the
>>>>>> resulting image.
>>>>>
>>>>> Here is the kwboot log with DEBUG_UART. Note that number 322322 below
>>>>> is part of the log.
>>>>>
>>>>> 322322
>>>>>
>>>>> U-Boot 2023.01-rc3-00057-g9bd3d354a1-dirty (Dec 19 2022 - 01:29:21 -0800)
>>>>> Pogoplug V4
>>>>>
>>>>> SoC:   Kirkwood 88F6281_A1
>>>>> Model: Cloud Engines PogoPlug Series 4
>>>>> DRAM:  128 MiB
>>>>> 322322322Core:  19 devices, 15 uclasses, devicetree: separate
>>>>> NAND:  4
>>>>>
>>>>
>>>> Going a bit further with your debug patch, I've added more prints.
>>>>
>>>>    static void orion_timer_init(void *base, enum input_clock_type type)
>>>>    {
>>>>           /* Only init the timer once */
>>>> -       if (early_init_done)
>>>> +       if (early_init_done) {
>>>> +               printch('6'); // test-only
>>>>                   return;
>>>> +       }
>>>>
>>>> And the boot log below shows somehow the early_init_done is already
>>>> true by the time the orion_timer_init is called. Pretty weird, to say
>>>> the least!
>>>>
>>>> --BEGIN LOG--
>>>> 3262632626
>>>>
>>>> U-Boot 2023.01-rc4-dirty (Dec 19 2022 - 15:35:26 -0800)
>>>> Pogoplug V4
>>>>
>>>> SoC:   Kirkwood 88F6281_A1
>>>> Model: Cloud Engines PogoPlug Series 4
>>>> DRAM:  128 MiB
>>>> 326263262632626Core:  19 devices, 15 uclasses, devicetree: separate
>>>> NAND:  456
>>>> --END LOG--
>>>>
>>>
>>> I tried this change in drivers/timer/orion-timer.c and it seems to
>>> work consistently.
>>>
>>> -static bool early_init_done __section(".data") = false;
>>> +static bool early_init_done = false;
>>>
>>> I still can't see why it would make a difference. Why does the
>>> __section macro not work? does the reallocation timing have anything
>>> to do with this variable being of the wrong value?
>>
>> Hmmm, so we might have a problem with memory being overwritten? You
>> should perhaps where the sections (especially data) are located and
>> where the stack etc is located. I suggest to also enable DEBUG in
>> board_f/c.c to see a bit more of the addresses being used.
>>
>> Thanks,
>> Stefan
> 
> Maybe similar issue as with mbus or atsha?
> https://lore.kernel.org/u-boot/20220810124609.5765-1-pali@kernel.org/
> https://lore.kernel.org/u-boot/20220408143015.23163-2-pali@kernel.org/
> 
> static variables do not work correctly _before_ u-boot relocation. You
> should avoid usage global OR static variables in code which may be
> called before relocation. And on some boards are all global, static and
> bss variables read-only (those which use execute-in-place, e.g. ppc
> flash).

Thanks for the input. Frankly, I was always a bit hesitant when using
early static variables. Also with moving them into the data segment.
Even though this seems to work on some platforms AFAICT.

I've prepared a patch getting rid of this variable by introducing a
function instead. Tested successfully on my Armada XP platform.

Tony, could you (and perhaps others as well?) test with this new patch,
if everything still works as expected?

Thanks,
Stefan