
Hi Stefan,
On Wed, Dec 21, 2022 at 1:29 AM Stefan Roese sr@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 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).
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