<Armbian-Discord> <T​onymac32> It can take months to get a patch set approved, and that's for only 1 specific change
<Armbian-Discord> <c​0rnelius> so this is kind of interesting specify device tree efi: seeding entropy pool Reserved memory: created CMA memory pool at 0x0000000020c00000, size 896 MiB don't specify device tree efi: seeding entropy pool Reserved memory: created CMA memory pool at 0x000000006ac00000, size 256 MiB
<Armbian-Discord> <c​0rnelius> whats it reading if not the dtb to dictate the memory pool?
<Armbian-Discord> <M​anoftheSea> Compiled in dtb or kernel default?
<Armbian-Discord> <c​0rnelius> Short of not being able to use overlays, using a uefi setup on boards like the Radxa Zero would be a better approach because of the varying memory options that board provides. I'm pretty sure this 896 MiB is why 512 and 1GB models don't boot using Armbian.
<Armbian-Discord> <c​0rnelius> Of course there could be something else fundamentally wrong with the build, but this does seem to be a trend.
<Armbian-Discord> <T​onymac32> no, the CMA allocation is killing it on the smaller boards
<Armbian-Discord> <T​onymac32> it was the same problem faced on the C2/K2/Le Potato/La Frite/VIM
<Armbian-Discord> <T​onymac32> 896 made the 512 MB and 1 GB devices fail to boot
<Armbian-Discord> <T​onymac32> So are you saying you don't define the CMA in the device tree, or you don't specify a device tree at all?
<Armbian-Discord> <c​0rnelius> I don't tell it what device tree to use.
<Armbian-Discord> <T​onymac32> ok, so it's defaulting to one
<Armbian-Discord> <T​onymac32> and the one it is using has a small CMA
<Armbian-Discord> <T​onymac32> at a different memory location
<Armbian-Discord> <T​onymac32> which u-boot is it?
<Armbian-Discord> <c​0rnelius> Yeah whatever it finds in dtb/amlogic in this case I believe. That's where it's suppose to look.
<Armbian-Discord> <c​0rnelius> most recent release of uboot
<Armbian-Discord> <c​0rnelius> Stable
<Armbian-Discord> <T​onymac32> armbian or vanilla?
<Armbian-Discord> <c​0rnelius> Vanilla. I do have it patched but it's not a fundamental change in this case it's just cosmetic. Splash.
<Armbian-Discord> <T​onymac32> cool
<Armbian-Discord> <c​0rnelius> I'll test it on a zero tomorrow. That test is on a Potato.
<Armbian-Discord> <T​onymac32> is the device tree you specified one that Armbian modified? The u-boot device tree has CMA of 256 MB
<Armbian-Discord> <T​onymac32> just trying to see where the values live
<Armbian-Discord> <c​0rnelius> Well yeah I patched the kernel with the same patch Armbian uses. That's where the 896 comes from.
<Armbian-Discord> <T​onymac32> ugh ok
<Armbian-Discord> <T​onymac32> yeah that will break anything 1 GB or less
<Armbian-Discord> <c​0rnelius> That's the question I guess. Is it getting the 256 from uboot?
<Armbian-Discord> <T​onymac32> yes
<Armbian-Discord> <T​onymac32> that's for the potato and friends
<Armbian-Discord> <c​0rnelius> Makes sense then.
<Armbian-Discord> <c​0rnelius> Not sure how that can be isolated in the armbian build since things tend to be patched across the world and not the board.
<Armbian-Discord> <T​onymac32> right
<Armbian-Discord> <T​onymac32> My thought was to have a minimum CMA and have overlays for bigger ones
<Armbian-Discord> <T​onymac32> the thing is the giant numbers are only needed by the half broken vdec
<Armbian-Discord> <c​0rnelius> That's a thought. You tried an overlay for CMA? Would that even work?
<Armbian-Discord> <T​onymac32> sure, you just swap out the values, u-boot doesn't use it at all, so it modifies the tree and you load it up
<Armbian-Discord> <T​onymac32> but with EFI, well I don't know how to do that 😄
<Armbian-Discord> <c​0rnelius> Worth an experiment
<Armbian-Discord> <T​onymac32> I feel like the loaded boot menu program would need to do that
<Armbian-Discord> <T​onymac32> I don't think GRUB is such a tool
<Armbian-Discord> <c​0rnelius> Nah grub isn't up for the task.
<Armbian-Discord> <c​0rnelius> So I'm thinking the overlay should really be for upping CMA, other wise it should default to 256 which should in theory make it bootable across the boards regardless of the memory footprint.
<Armbian-Discord> <T​onymac32> right, agreed
<Armbian-Discord> <T​onymac32> that way little boards work
<Armbian-Discord> <T​onymac32> without interference
<Armbian-Discord> <c​0rnelius> Exactly
<Armbian-Discord> <M​anoftheSea> What does uefi change about different memory sizes?
<Armbian-Discord> <c​0rnelius> Apparently its not changing it. Whats happening is, if the devicetree isn't defined during boot, it will default to the one used during the creation of u-boot and since Armbian changes the CMA pool for GXL/G12 this results in a size diff.
<Armbian-Discord> <M​anoftheSea> okay, that makes sense.
<Armbian-Discord> <M​anoftheSea> I found where the extlinux.conf can be told to use a DTBO, but I don't know if u-boot provides the EFI environment if it works through the extlinux.conf LABEL Manjaro ARM KERNEL /Image FDT /dtbs/rockchip/rk3399-rockpro64.dtb FDTOVERLAYS /dtbs/overlays/pcf8574.dtbo APPEND initrd=/initramfs-linux.img [...]
<Armbian-Discord> <c​0rnelius> So the thought is, instead of forcing the CMA change across all those SoCs and leaving some boards unbootable, we could instead provide an overlay option for upping the pool for those who need it or want it.
<Armbian-Discord> <M​anoftheSea> It'd be possible to write an extlinux.conf that defaults to minimal memory, then you can set the default from the running system... Actually, that's not a bad idea for the ebin v5/v7 difference in network devices.
<Armbian-Discord> <c​0rnelius> Well yeah... I was doing the testing using grub. With extlinux.conf the board won't even unless defined.
<Armbian-Discord> <c​0rnelius> and no grub doesn't provide an overlay option like extlinux fdtoverlays does. not sure any uefi bootloaders/managers do at this time.
<Armbian-Discord> <c​0rnelius> set timeout=0 set default=0 menuentry "Renegade" { insmod gzio insmod part_gpt insmod ext2 set root=hd0,gpt1 echo "Loading kernel ..." linux (hd0,2)/boot/Image root=LABEL=ROOTFS console=tty1 console=ttyS2,115200n8 console=both rw rootwait rootfstype=ext4 fsck.repair=yes loglevel=1 net.ifnames=0 echo "Loading ramdisk ..." initrd (hd0,2)/boot/initrd.gz echo "Loading
<Armbian-Discord> devicetree ..." devicetree (hd0,2)/boot/rockchip/rk3328-roc-cc.dtb }
<Armbian-Discord> <M​anoftheSea> the fdtoverlays was added to the bootloader spec in 2019...
<Armbian-Discord> <M​anoftheSea> But also, the running system can apply overlays to configfs (maybe?)
<Armbian-Discord> <c​0rnelius> I've tried that, never got it working.
<Armbian-Discord> <c​0rnelius> I was able to enable the overlay but it didn't actually function.
<Armbian-Discord> <c​0rnelius> maybe something missing from the patch I used?
<Armbian-Discord> <M​anoftheSea> Well, if this is the latest https://systemd.io/BOOT_LOADER_SPECIFICATION/ then the keys are named "devicetree" and "devicetree-overlay" (and takes a space-separated list)
<Armbian-Discord> <c​0rnelius> oh interesting. let me try and see if that devicetree-overlay actually works.
<Armbian-Discord> <M​anoftheSea> in grub?
<Armbian-Discord> <c​0rnelius> yeah
<Armbian-Discord> <M​anoftheSea> Does Grub follow bootloader spec?
<Armbian-Discord> <M​anoftheSea> I thought bootloader spec was a thing the systemd folks were writing for themselves to follow
<Armbian-Discord> <c​0rnelius> its considered a bootloader so I would hope so.
<Armbian-Discord> <c​0rnelius> guess we are gonna find out
<Armbian-Discord> <c​0rnelius> i know when looking through the grub docs I didn't see anything about that devicetree-overlay option. but that doesn't mean it won't work.
<Armbian-Discord> <M​anoftheSea> it definitely doesn't follow the same format. GRUB's menu format predates bootloader spec, dunnit?
<Armbian-Discord> <T​onymac32> this causes a race condition and is not stable enough to be mainline
<Armbian-Discord> <c​0rnelius> tells me it can't find the command devicetree-overlay .
<Armbian-Discord> <M​anoftheSea> tant pis
<Armbian-Discord> <c​0rnelius> hmm. one problem there is you can't use systemd-boot on non-gpt partitions. at least I wasn't able too..? so if thats the case systemd-boot isn't viable with allwinner and amlogic.
<Armbian-Discord> <c​0rnelius> kind of a real dick punch honestly
<Armbian-Discord> <c​0rnelius> i also didn't do tons of research and basically just did the install and went about the setup which ended it with it telling me, no gpt? no fun for you!
<Armbian-Discord> <M​anoftheSea> I agree.
<Armbian-Discord> <M​anoftheSea> amlogic, at least, uses area right in the middle of the GPT header
<Armbian-Discord> <M​anoftheSea> You could use it in a fragile and broken way, I suppose...
<Armbian-Discord> <M​anoftheSea> I don't know about allwinner's bootloader requirements
<Armbian-Discord> <c​0rnelius> i believe allwinner as well. once you flash the boot bins it kills the gpt partition.
<Armbian-Discord> <M​anoftheSea> And I imagine I read something from Lennert about how systemd-boot is for the future, and MBR isn't part of the future
<Armbian-Discord> <M​anoftheSea> Allwinner uses something in the middle of the table, but the table can be offset. I think.
<Armbian-Discord> <M​anoftheSea> the header is just sector 1
<Armbian-Discord> <c​0rnelius> not sure honestly. I only recently started reading up on gpt and putting it in practice where I can.
<Armbian-Discord> <c​0rnelius> i've come to the conclusion sgdisk pretty much sucks though. using parted to create the table is cleaner.
<Armbian-Discord> <c​0rnelius> allwinner flashes at sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblkX conv=fsync bs=1024 seek=8
<Armbian-Discord> <c​0rnelius> amlogic at 512
<Armbian-Discord> <c​0rnelius> RK at 64 and 16384
<Armbian-Discord> <M​anoftheSea> hmm, 512 might be possible.
<Armbian-Discord> <M​anoftheSea> oh, wait, no, 512-byte sectors.
<Armbian-Discord> <M​anoftheSea> 16k would conflict with what, partitions 125-128?
<Armbian-Discord> <M​anoftheSea> sectors 33 and 34, so only the last two
<Armbian-Discord> <c​0rnelius> @Tonymac32 Well the overlays works. I did the test in reverse as the kernel is already patched at 896M Reserved memory: created CMA memory pool at 0x00000000e4c00000, size 256 MiB So should be as easy as changing 0x0 0x10000000 to 0x0 0x38000000 and "wham oh" people who use the overlay have it reserved at 896M. https://paste.debian.net/1252572/
<Armbian-Discord> <M​anoftheSea> what'd you use to load it?
<Armbian-Discord> <c​0rnelius> extlinux
<Armbian-Discord> <n​armstrong> Actually I added fdtoverlays to u-boot syslinux/extlinux 🙂
<Armbian-Discord> <c​0rnelius> thats because ur awesome 🙂
<Armbian-Discord> <c​0rnelius> thanx for that
<Armbian-Discord> <n​armstrong> Thx 😊