06:49 <sphalerite> ok, managed to find the actual error in the massive dump that linux gave me yesterday by doing it again. Turns out it's the same old memory allocation issue \o/

07:57 <mmind00> did you try adding a "manual" memory node to the dts?

07:58 <mmind00> sphalerite: ^^

08:14 <sphalerite> mmind00: not yet, but it turns out it works fine if I use kexec without --dtb

08:15 <mmind00> sphalerite: in which case I guess it just re-uses the original devicetree?

08:15 <sphalerite> I'm guessing so

08:15 <mmind00> sphalerite: which in this case uboot would have made sure to actually have a memory node

08:15 <sphalerite> right

08:15 <mmind00> /proc/device-tree/memory I guess

08:16 <sphalerite> yep that exists

08:19 <maz> in general, booting with a different device tree is difficult. you need to make sure you propagate all the info that the initial bootloader has placed in there, which is non-trivial.

08:19 <maz> s/booting/kexec-ing/

08:20 <sphalerite> right

08:20 <sphalerite> so the simple solution is "don't use --dtb" I guess :)

08:21 <sphalerite> originally I thought "the kernel ships a dtb, so I should probably use that?" but I see how that doesn't work now :)

08:23 <maz> sphalerite: "it's complicated". with kexec, the kernel is a bootloader. you need to perform everything a normal bootloader would do, such as insering the right memory and chosen nodes, mac addresses, everything.

08:24 <maz> sphalerite: remember that what we have in the kernel is only a template for bootloaders to use, not something to beused as is (even if it work in some limited cases).

08:24 <sphalerite> right

22:15 <sphalerite> so amarula's patches seem to allow two ways of booting—using rockchip's miniloader or using the U-boot SPL… Are there any reasons to prefer either of these? (https://github.com/amarula/u-boot-amarula/commit/a0e93bb32bd94f3ee443854743f9725cdde3e913 )

22:18 <anarsoul> sphalerite: if your memory is supported by SPL I see no reason to use rockchip's miniloader

22:24 <sphalerite> anarsoul: cool, thanks!

22:24 <sphalerite> also, if I try to boot 4.19.34 on my nanopi m4 via kexec, it resets after a while without displaying any info about a panic: https://sphalerite.org/dump/4.19.34-boot-fail.log anyone have any idea what might be going on there?

22:29 <sphalerite> (that stray D is from "DDR Version 1.15 20181010", the first message printed by the firmware)