05:38 <Lightsword> finally got linux booting fully(into ramdisk) from SD card, guess need to figure out how to enable ethernet, I managed to hack up some uboot drivers that turn on the ethernet port lights but can't seem to get any real network activity(i.e. dhcp fails)

05:41 <Lightsword> also found this bug in uboot, seems there's a faulty assumption that all arm64 boards are at least 512MB ram, mine's only 256MB https://github.com/u-boot/u-boot/blob/v2025.04/include/configs/sunxi-common.h#L73

17:21 <apritzel> Lightsword: but that only affects $ramdisk_addr_r, right? The other values should be fine?

17:23 <apritzel> and I find it hilarious that by far the most expensive device employing an Allwinner SoC is also the most stingy when it comes to DRAM size ...

17:25 <Lightsword> apritzel, I guess, actually there were other values that were problematic but those were configurable via kconfig at least, had to move the uboot load address and reduce malloc size in order to move uboot to a high enough load address so that I could actually unpack a full FIT image with ramdisk

17:25 <Lightsword> think stack size as well

17:25 <Lightsword> also had to strip down the kernel a bit for ramdisk boot to work

17:27 <Lightsword> apritzel, well with how many of these miners that they produce...I guess every little bit helps cost wise, but without a graphics stack 256MB is plenty of RAM in general

17:27 <Lightsword> also I think less ram reduces chance of hardware faults

17:30 <Lightsword> apritzel, https://gist.github.com/jameshilliard/1fec8b3cb7bb7569e5a50588eae62b0b https://gist.github.com/jameshilliard/f14746a966214d1c71f247da84dff467

17:32 <apritzel> > "move the uboot load address": which one do you mean? The 0x4a000000 where the U-Boot image gets loaded to? That should still work, shouldn't it?

17:32 <apritzel> and it's not easy to change, because that's somewhat hardcoded, in the SPL and also in TF-A

17:35 <Lightsword> apritzel, yeah I changed that, it's like 167MB offset which makes it rather tricky to load a ~70MB FIT image and have everything unpack nicely, wasn't exactly hard to change though, it's like a couple of config variables BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES="PRELOADED_BL33_BASE=0x4f000000" and CONFIG_TEXT_BASE=0x4f000000 for uboot

17:40 <apritzel> well, my point is that this is an not upstreamable hack

17:40 <apritzel> and you should be able to just load everything low, after all 256 MB should be enough

17:41 <apritzel> the 160M load address is just for *loading* U-Boot, it immediately relocates itself to the end of DRAM, so at U-Boot proper runtime the 160MB area doesn't matter anymore

17:45 <apritzel> so please try to keep the 0x4a000000 if anyhow possible, and adjust other variables

17:47 <Lightsword> apritzel, hmm, that didn't seem to be the case https://gist.github.com/jameshilliard/198518dc29f74e9dd119457a0ea2d43b https://gist.github.com/jameshilliard/ceaefd8d991b4abe894b9ab0e25df300

17:48 <Lightsword> apritzel, or well at least it didn't seem to be the main issue, which was that uboot would reserve like 64MB of ram for malloc right after the load address

17:48 <Lightsword> also was reserving 16MB for stack by default I think

17:52 <Lightsword> apritzel, the actual relocations changes I made don't require upstreaming, since that's purely configuration changes already and mostly just to make space for larger ramdisks, but should maybe do something about the addresses being wrong in sunxi-common.h which is an issue regardless

17:53 <Lightsword> apritzel, also any reason to not load the kernel right at the start of memory? wondering why that varies in sunxi-common.h based on the configured minimum ram size

17:57 <apritzel> there are certain constraints for where to load images, surely many more for arm32 than there are for arm64. And some historic ones as well: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arch/arm64/booting.rst#n144

17:58 <apritzel> so keep things simple, we just use *one* setup that should work universally, regardless of which kernel you load

17:59 <apritzel> for anything with H616 those old requirement don't apply, so you can load the kernel at anything 2MB aligned, and the ramdisk practically anywhere (I believe)

17:59 <Lightsword> apritzel, ehhh, but it's not consistent, even for arm32, https://github.com/u-boot/u-boot/blob/v2025.04/include/configs/sunxi-common.h#L97 https://github.com/u-boot/u-boot/blob/v2025.04/include/configs/sunxi-common.h#L111

18:01 <apritzel> yes, but arm32 is completely separate mess, reaching back many more years into the "Middle Ages" of ARM Linux support

18:02 <apritzel> arm64 is a separate architecture particularly for that reason

18:03 <Lightsword> apritzel, so using 0x40080000 in the FIT image for kernel load/entry for arm64 should be the best location right?

18:05 <Lightsword> apritzel, btw is this something that should work on h616? https://github.com/apritzel/linux/commits/ac200-WIP/

18:05 <apritzel> better use 0x40200000, as U-Boot will copy it there anyway (the TEXT_OFFSET default in the kernel changed from 512K to 0)

18:06 <Lightsword> apritzel, if I leave the load/entry addresses out of the FIT image will it do that automatically?

18:07 <apritzel> Lightsword: H616 has ac300, which is slightly different. I think jernej had patches somewhere in his github

18:08 <Lightsword> apritzel, this one? https://github.com/jernejsk/linux-1/commits/ac300-net/

18:08 <apritzel> why do you need a FIT image anyway? Can't you just load the kernel and initrd separately, and use $fdtcontroladdr? Then you have better control

18:08 <apritzel> Lightsword: yes, I think so

18:10 <Lightsword> apritzel, I like to use FIT images so that I can store everything in a single UBI volume and then atomic rename the volume for updates https://sbabic.github.io/swupdate/handlers.html#atomic-volume-renaming

18:11 <Lightsword> if I use separate volumes for kernel/dtb/ramdisk the rename AFAIU is then no longer entirely atomic

18:13 <Lightsword> I think ubiswap(which is what I would need to use if splitting into multiple images) is not entirely atomic when operating on multiple volumes.

23:59 <apritzel> I don't know much about UBI, but I guess you put the FIT image in a static UBI volume? And at the moment you do this on the SD card, where UBI is actually not needed?