Converting to DM SERIAL for Kirkwood boards

[Stefan Roese]

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