Hi ;)
On Tue, Dec 10, 2024 at 10:52:04PM +0100, Ahmad Fatoum wrote:
> You can print hex numbers with puthex_ll(), although by now you are
> already relocated, so you can add
>
> pbl_set_putc((void (*)(void *, int))debug_ll_ns16550_putc, uart0);
>
> after omap_debug_ll_init(), enable CONFIG_DEBUG_PBL and then you can
> use normal printf and also see the panic message if the BUG() indeed
> triggers.
I did enable CONFIG_PBL_CONSOLE and CONFIG_DEBUG_PBL in both barebox.bin
and MLO.
I get this:
2>6ABCuncompress.c: memory at 0x80000000, size 0x20000000
Dmmu: enabling MMU, ttb @ 0x9ffe0000
EF%G-%|!_H-%|!_I-%|!_%%%%JKLMendmem = 0xa0000000
arm_mem_scratch = 0x9fff8000+0x00008000
arm_mem_stack = 0x9fff0000+0x00008000
arm_mem_ttb = 0x9ffe0000+0x00010000
arm_mem_barebox_image = 0x9fe00000+0x00200000
arm_mem_early_malloc = 0x9fde0000+0x00020000
membase = 0x80000000+0x20000000
uncompress.c: uncompressing barebox binary at 0x402f65a0 (size 0x0000e3c8) to 0x9fe00000 (uncompressed size: 0x00018310)
NOPuncompress.c: jumping to uncompressed image at 0x9fe00001
QZSwitch to console [cs0]
[...] normal startup with more debug output continuiung.
I left the single char debug sequence char output stuff I inserted as it
was last time.
Warm restart gives me this:
barebox@TI AM335x BeagleBone black:/ reset
>6ABCuncompress.c: memory at 0x8f001b00, size 0x9f00b500
Dmmu: enabling MMU, ttb @ 0x2dfe0000
EF%
[DEAD]
This looks like a tiny bit different than last time without the new PBL
CONFIG options enabled. It reaches
static inline uint32_t *get_ttb(void)
{
putc_ll('%');
/* Clear unpredictable bits [13:0] */
return (uint32_t *)(get_ttbr() & ~0x3fff);
}
but not
uint32_t *ttb = get_ttb();
putc_ll('|');
the line after this.
Last time looked like it hit the BUG_ON which I thout stopped the
execution because of messed up addresses.
Here one sees addresses are totallfy messed up in uncompress.c already.
Still it is possible to make soft start working by adding an additional
char in lowlevel.c:
putc_ll('>');
putc_ll('6');
putc_ll('5');
makes it work,
putc_ll('>');
putc_ll('6');
or less gives the error.
I replaced all three chars with a hand crafted __udelay in lowlevel.c
(but left debugging enabled), makes everything working fine, too.
I was not able to add the line
pbl_set_putc((void (*)(void *, int))debug_ll_ns16550_putc, uart0);
to lowlevel.c. I admit I asked chatgpt to explain to me, if this
still is valid C, wow! :-)
Adding it gives an error:
arch/arm/boards/beaglebone/lowlevel.c:161:2: error: implicit declaration of function `pbl_set_putc´; did you mean `__set_bit´? [-Werror=implicit-function-declaration]
pbl_set_putc((void (*)(void *, int))debug_ll_ns16550_putc, uart0);
^~~~~~~~~~~~
__set_bit
arch/arm/boards/beaglebone/lowlevel.c:161:61: error: `uart0´ undeclared (first use in this function)
pbl_set_putc((void (*)(void *, int))debug_ll_ns16550_putc, uart0);
> I suspect the RAM controller itself may be acting funky after a warm reboot
> and letting some time go by fixes that :/
Yes. But the PLL lock bits are properly set I checked already and the
barebox code does that to...
Regards
Konsti
--
INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen
Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010
konstantin.kletschke@xxxxxxxxxxxxx
http://www.inside-m2m.de
Geschäftsführung: Michael Emmert, Derek Uhlig
HRB: 111204, AG Hannover
