Re: Converting to DM SERIAL for Kirkwood boards

["Pali Rohár" <pali@kernel.org>]

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@gmail.com> wrote:
> > > 
> > > Hi Stefan,
> > > 
> > > On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > > > 
> > > > Hi Stefan,
> > > > 
> > > > On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese <sr@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).