On 21.07.21 01:34, Marek Vasut wrote:
On 7/20/21 11:08 AM, Jan Kiszka wrote: [...]
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index f60ee3a7e6..23b99a541c 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -43,6 +43,7 @@ DECLARE_GLOBAL_DATA_PTR; static struct tag *params; +#ifndef CONFIG_ARM64 static ulong get_sp(void) { ulong ret; @@ -86,6 +87,7 @@ void arch_lmb_reserve(struct lmb *lmb) break; } } +#endif __weak void board_quiesce_devices(void) {
This causes troubles for [1], but I have no clue yet, what is happening. Without the patch, we start like this:
Found U-Boot script /boot/boot.scr 889 bytes read in 21 ms (41 KiB/s) ## Executing script at 83000000 Loading /usr/lib/linux-image-4.19.94/ti/k3-am6548-iot2050-advanced.dtb... 78306 bytes read in 25 ms (3 MiB/s) Loading /boot/vmlinux-4.19.94... 13537288 bytes read in 107 ms (120.7 MiB/s) ## Flattened Device Tree blob at 82000000 Booting using the fdt blob at 0x82000000 Loading Device Tree to 00000000fdefa000, end 00000000fdf101e1 ... OK
Starting kernel ...
With the patch applied, I'm getting stuck like this:
Found U-Boot script /boot/boot.scr 889 bytes read in 21 ms (41 KiB/s) ## Executing script at 83000000 Loading /usr/lib/linux-image-4.19.94/ti/k3-am6548-iot2050-advanced.dtb... 78306 bytes read in 25 ms (3 MiB/s) Loading /boot/vmlinux-4.19.94... 13537288 bytes read in 109 ms (118.4 MiB/s) ## Flattened Device Tree blob at 82000000 Booting using the fdt blob at 0x82000000 Loading Device Tree to 00000000fffe9000, end 00000000fffff1e1 ...
Obviously, the DT target adress changed, possibly to an unsupported/reserved address. But I do not understand the mechanics behind all this yet. Any hints welcome on what goes wrong here and whether something needs to be adjusted in our board settings.
Can you share the output of bdinfo on this board ?
Sure (with your commit reverted for now):
IOT2050> bdinfo boot_params = 0x0000000000000000 DRAM bank = 0x0000000000000000 -> start = 0x0000000080000000 -> size = 0x0000000080000000 flashstart = 0x0000000000000000 flashsize = 0x0000000000000000 flashoffset = 0x0000000000000000 baudrate = 115200 bps relocaddr = 0x00000000fff2d000 reloc off = 0x000000007f72d000 Build = 64-bit current eth = unknown ethaddr = 70:77:77:77:57:70 IP addr = <NULL> fdt_blob = 0x00000000fdef9f10 new_fdt = 0x00000000fdef9f10 fdt_size = 0x0000000000012ea0 lmb_dump_all: memory.cnt = 0x1 memory[0] [0x80000000-0xffffffff], 0x80000000 bytes flags: 0 reserved.cnt = 0x2 reserved[0] [0x9e800000-0xa21fffff], 0x03a00000 bytes flags: 4 reserved[1] [0xfdef86c0-0xffffffff], 0x02107940 bytes flags: 0 arch_number = 0x0000000000000000 TLB addr = 0x00000000ffff0000 irq_sp = 0x00000000fdef9b20 sp start = 0x00000000fdef9b20 Early malloc usage: 23c8 / 8000
There is some "TLB" block apparently overlapping when we move the DT. What's this? Looking at the code, not a TLB with the usual meaning but rather the page table U-Boot uses for itself, right?
Were we just lucky so far with side effects of the LMB reservation on this platform (and I suspect that it affect k3 in general, not only our board)?
Thanks, Jan