Hi Stefan, On Wed, Dec 21, 2022 at 1:29 AM Stefan Roese <s...@denx.de> wrote: > > 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 <mibo...@gmail.com> wrote: > >>>> > >>>> Hi Stefan, > >>>> > >>>> On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh <mibo...@gmail.com> wrote: > >>>>> > >>>>> Hi Stefan, > >>>>> > >>>>> On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese <s...@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-p...@kernel.org/ > > https://lore.kernel.org/u-boot/20220408143015.23163-2-p...@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?
Sure, I'll be glad to. Thanks, Tony > > Thanks, > Stefan