Converting to DM SERIAL for Kirkwood boards
Tony Dinh
mibodhi at gmail.com
Tue Dec 20 02:36:17 CET 2022
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?
Thanks,
Tony
> Thanks,
> Tony
>
> > Thanks,
> > Tony
> >
> > > Thanks,
> > > Stefan
More information about the U-Boot
mailing list