On Wed, Jan 11, 2023 at 12:01:46AM +0100, Joost van Zwieten wrote: > > > On Tue, Jan 10, 2023 at 13:41, Tom Rini <tr...@konsulko.com> wrote: > > On Tue, Jan 10, 2023 at 09:13:32AM +0100, Joost van Zwieten wrote: > > > > > Dear maintainers, > > > > > > As of commit 4963f63fe61f15329d77472a762b1d8bf754d24b U-Boot fails > > > to start > > > a kernel (with `bootz`) on my Odroid U2 unless I force > > > `initrd_high`, e.g. > > > to `0x50000000`. With commit 4963f63f and `initrd_high` *unset* I > > > get the > > > following output: > > > > > > U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31 > > > +0100) > > > > > > CPU: Exynos4412 @ 1 GHz > > > Model: Odroid based on Exynos4412 > > > Type: u3 > > > DRAM: 2 GiB > > > LDO20@VDDQ_EMMC_1.8V: set 1800000 uV; enabling > > > LDO22@VDDQ_EMMC_2.8V: set 2800000 uV; enabling > > > LDO21@TFLASH_2.8V: set 2800000 uV; enabling > > > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0 > > > Loading Environment from MMC... *** Warning - bad CRC, using > > > default > > > environment > > > > > > In: serial > > > Out: serial > > > Err: serial > > > Boot device: MMC(2) > > > Net: No ethernet found. > > > Hit any key to stop autoboot: 0 > > > Odroid # env set fk_kvers 5.10.0-20-armmp > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r} > > > /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb > > > 53440 bytes read in 50 ms (1 MiB/s) > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${kernel_addr_r} > > > /boot/vmlinuz-${fk_kvers} > > > 4973056 bytes read in 182 ms (26.1 MiB/s) > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${ramdisk_addr_r} > > > /boot/initrd.img-${fk_kvers} > > > 22231585 bytes read in 777 ms (27.3 MiB/s) > > > Odroid # env set bootargs console=ttySAC1,115200n8 > > > Odroid # bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} > > > ${fdt_addr_r} > > > Kernel image @ 0x41000000 [ 0x000000 - 0x4be200 ] > > > ## Flattened Device Tree blob at 40800000 > > > Booting using the fdt blob at 0x40800000 > > > Loading Ramdisk to b9947000, end bae7aa21 ... OK > > > Loading Device Tree to b9936000, end b99460bf ... OK > > > > > > Starting kernel ... > > > > > > And that's all I ever see. Normally the initrd loads a module that > > > causes an > > > LED on the Odroid to blink, and this is not happening either, so > > > I'm pretty > > > confident the kernel doesn't start or at least crashes before > > > producing > > > output. If I set `initrd_high` to `0x50000000` (or something in the > > > neighborhood) the kernel starts just fine: > > > > > > U-Boot 2020.10-rc2-00314-g4963f63fe6 (Jan 09 2023 - 23:59:31 > > > +0100) > > > > > > CPU: Exynos4412 @ 1 GHz > > > Model: Odroid based on Exynos4412 > > > Type: u3 > > > DRAM: 2 GiB > > > LDO20@VDDQ_EMMC_1.8V: set 1800000 uV; enabling > > > LDO22@VDDQ_EMMC_2.8V: set 2800000 uV; enabling > > > LDO21@TFLASH_2.8V: set 2800000 uV; enabling > > > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0 > > > Loading Environment from MMC... *** Warning - bad CRC, using > > > default > > > environment > > > > > > In: serial > > > Out: serial > > > Err: serial > > > Boot device: MMC(2) > > > Net: No ethernet found. > > > Hit any key to stop autoboot: 0 > > > Odroid # env set fk_kvers 5.10.0-20-armmp > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r} > > > /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb > > > 53440 bytes read in 49 ms (1 MiB/s) > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${kernel_addr_r} > > > /boot/vmlinuz-${fk_kvers} > > > 4973056 bytes read in 181 ms (26.2 MiB/s) > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${ramdisk_addr_r} > > > /boot/initrd.img-${fk_kvers} > > > 22231585 bytes read in 777 ms (27.3 MiB/s) > > > Odroid # env set bootargs console=ttySAC1,115200n8 > > > Odroid # env set initrd_high 0x50000000 > > > Odroid # bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} > > > ${fdt_addr_r} > > > Kernel image @ 0x41000000 [ 0x000000 - 0x4be200 ] > > > ## Flattened Device Tree blob at 40800000 > > > Booting using the fdt blob at 0x40800000 > > > Loading Ramdisk to 4eacc000, end 4ffffa21 ... OK > > > Loading Device Tree to bae6a000, end bae7a0bf ... OK > > > > > > Starting kernel ... > > > > > > [ 0.000000] Booting Linux on physical CPU 0xa00 > > > <truncated> > > > > > > The difference between those two runs is the location where U-Boot > > > loads the > > > initrd. The parent commit of 4963f63f boots fine without setting > > > `initrd_high`: > > > > > > U-Boot 2020.10-rc2-00313-gdfaf6a5797 (Jan 10 2023 - 00:13:19 > > > +0100) > > > > > > CPU: Exynos4412 @ 1 GHz > > > Model: Odroid based on Exynos4412 > > > Type: u3 > > > DRAM: 2 GiB > > > LDO20@VDDQ_EMMC_1.8V: set 1800000 uV; enabling > > > LDO22@VDDQ_EMMC_2.8V: set 2800000 uV; enabling > > > LDO21@TFLASH_2.8V: set 2800000 uV; enabling > > > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0 > > > Loading Environment from MMC... *** Warning - bad CRC, using > > > default > > > environment > > > > > > In: serial > > > Out: serial > > > Err: serial > > > Boot device: MMC(2) > > > Net: No ethernet found. > > > Hit any key to stop autoboot: 0 > > > Odroid # env set fk_kvers 5.10.0-20-armmp > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${fdt_addr_r} > > > /boot/dtbs/${fk_kvers}/exynos4412-odroidu3.dtb > > > 53440 bytes read in 49 ms (1 MiB/s) > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${kernel_addr_r} > > > /boot/vmlinuz-${fk_kvers} > > > 4973056 bytes read in 181 ms (26.2 MiB/s) > > > Odroid # load mmc ${mmcbootdev}:${mmcbootpart} ${ramdisk_addr_r} > > > /boot/initrd.img-${fk_kvers} > > > 22231585 bytes read in 776 ms (27.3 MiB/s) > > > Odroid # env set bootargs console=ttySAC1,115200n8 > > > Odroid # bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} > > > ${fdt_addr_r} > > > Kernel image @ 0x41000000 [ 0x000000 - 0x4be200 ] > > > ## Flattened Device Tree blob at 40800000 > > > Booting using the fdt blob at 0x40800000 > > > Loading Ramdisk to 4eacc000, end 4ffffa21 ... OK > > > Loading Device Tree to 4eabb000, end 4eacb0bf ... OK > > > > > > Starting kernel ... > > > > > > [ 0.000000] Booting Linux on physical CPU 0xa00 > > > <truncated> > > > > > > I've tested two different kernels from Debian (buster and bullseye) > > > and both > > > have the same problem. I'm building U-Boot using the default config > > > for > > > board `odroid` and boot the Odroid from an SD card with firmware > > > (`bl1`, > > > `bl2` and `tzsw`) from Hardkernel's clone of the u-boot repository > > > [1]. > > > There are no peripherals connected apart from the SD card and the > > > serial > > > console. Please let me know if you need more information. > > > > Interesting. So what does "bdi" show, both in the older good and > > then current tree? Specifically the information about where DRAM is, and > > how large it is? Thanks. > > > > -- > > Tom > > Both 4963f63f (not working) and its parent (working) produce the same > output: > > boot_params = 0x40000100 > DRAM bank = 0x00000000 > -> start = 0x40000000 > -> size = 0x10000000 > DRAM bank = 0x00000001 > -> start = 0x50000000 > -> size = 0x10000000 > DRAM bank = 0x00000002 > -> start = 0x60000000 > -> size = 0x10000000 > DRAM bank = 0x00000003 > -> start = 0x70000000 > -> size = 0x10000000 > DRAM bank = 0x00000004 > -> start = 0x80000000 > -> size = 0x10000000 > DRAM bank = 0x00000005 > -> start = 0x90000000 > -> size = 0x10000000 > DRAM bank = 0x00000006 > -> start = 0xa0000000 > -> size = 0x10000000 > DRAM bank = 0x00000007 > -> start = 0xb0000000 > -> size = 0x0ff00000 > memstart = 0x40000000 > memsize = 0x7ff00000 > flashstart = 0x00000000 > flashsize = 0x00000000 > flashoffset = 0x00000000 > baudrate = 115200 bps > relocaddr = 0xbfe83000 > reloc off = 0x7c083000 > Build = 32-bit > current eth = unknown > ethaddr = (not set) > IP addr = <NULL> > fdt_blob = 0xbae7bf00 > new_fdt = 0xbae7bf00 > fdt_size = 0x00002fa0 > lmb_dump_all: > memory.cnt = 0x1 > memory.size = 0x0 > memory.reg[0x0].base = 0x40000000 > .size = 0x7ff00000 > > reserved.cnt = 0x1 > reserved.size = 0x0 > reserved.reg[0x0].base = 0xbae7acd0 > .size = 0x5085330 > arch_number = 0x000010c1 > TLB addr = 0xbfef0000 > irq_sp = 0xbae7bef0 > sp start = 0xbae7bee0 > Board Type = 0 > Early malloc usage: f0 / 400 > > I'm not sure if this is relevant, but with the failing commit I can get the > kernel to start with `initrd_high` set to `0x70000000` or lower, but not > higher.
OK, so 8 whole banks, of 256MB each. Does this platform have 2GB of memory for real? -- Tom
signature.asc
Description: PGP signature