djurny

I also have some oom issues when doing an aptitude upgrade in my opizero w/256 MiB ram. Guess even more on a 128MiB board like yours. Best to add a swap file to make sure upgrades go without issue. Grt,

Little odd that it fails to load the fix up script there; In the old boot.cmd it checks if it can find the file and loads it if it can. Can you share a serial console log of the 21.x release that did work? Incl aembianmonitor -u output? Thx, Grt,

Hi @Zaf9670, Your situation actually helped find an OBOE in the U-Boot image overlap test, so thank you for that! Can you try with an older image and share the U-Boot output? Also, can you add the following in your armbianEnv.txt: verbosity=8 earlycon=on console=serial I've had better experience with setting console to serial only and earlycon might help the kernel spew out some things earlier on. Groetjes,

Hi @Ed van den Enden, I'm still pressing "X" to doubt that dtoverlay=... will work for sunxi boards running Armbian like the Banana Pi M2 zero, as your points do not work on my Orange Pi zero (which is running sunxi Allwinner H2+ just like the Bananana Pi M2 zero). Also, your provided logging clearly indicates that the kernel did not configure any additional RTC, just the H2+ built-in one. But then again, I don't mind being wrong every now and then in life. Can you share the output of the following commands: ls -Failh /dev/rtc* ls -Failh /sys/class/rtc/ egrep -- . /sys/class/rtc/*/name dmesg | egrep -i -- 'rtc' And to read the actual clocks: sudo hwclock --rtc=/dev/rtc0 # per default this is the H2+ built-in RTC sudo hwclock --rtc=/dev/rtc1 # per default this is going to be the I2C RTC Posting the link to @IgorS's topic that shows exactly what to do here again: Also, for reference, here is a link to the Allwinner H2+ datasheet, where it also mentions clearly (chapter 4.8 RTC on page 171) that the SoC itself also has an on-board RTC (this is the RTC detected by the kernel as sun6i-rtc and the one you actually are reading in your case): https://wiki.friendlyelec.com/wiki/images/0/08/Allwinner_H2+_Datasheet_V1.2.pdf Groetjes,

Hi @Zaf9670, Are you sure you did the setenv fdt_addr_r 41000000 U-Boot claims DT is still loaded/applied to the original load address: Working FDT set to 41900000 Can you share your armbianEnv.txt and boot.cmd? I'll have a look at the defailt bootscript in the meantime, perhaps some parts of the bootscript is using fdt_addr_r and other parts might still use loadaddr or scriptaddr... Thx, Gr,

Hi @Zaf9670, Can you try to reset the U-Boot monitor, press any key to stop the autobooting, then enter the following on the commandline: setenv fdt_addr_r 41000000 setenv kernel_addr_r 41080000 setenv ramdisk_addr_r 42080000 These load addresses are based on the sizes of the DT (438272 bytes) and the kernel image (11013984 bytes). Then to kick off the boot: run bootcmd Do share the results please. Groetjes, p.s. That device tree is huge! 428 KiB??

Hi there, Now two pull requests are awaiting review: - https://github.com/armbian/build/pull/8166#issuecomment-2867147049 Update the boot.scr script to calculate load addresses in case `setexpr` is available on the U-Boot monitor. - https://github.com/armbian/build/pull/8170#issuecomment-2867915659 Enable the `setexpr` command on the U-Boot monitor, to unlock load address calculation in combination with the boot.scr update. Both are now tested OK using a built armbian 'minimal' image based on Bookworm. Groetjes,

Hi @Igor, all, Made some updates, see here (including some minor corrections). Tested it with a built image (bookworm-minimal) and it seems to work: I will see how i can change U-Boot configuration to allow for `setexpr` to work, as using `setexpr` will make sure this does not need constant changing whenever kernel grows in size. As this is my first pull request, not sure what to do next? Please have a look-see, Groetjes,

Hi @Zzzz, @Zaf9670, After it fails to boot, can you type the following in the U-Boot monitor prompt and share the ouput: echo $fdt_addr_r echo $kernel_addr_r echo $ramdisk_addr_r setexpr abc 1 + 1 echo "abc=x${abc}x" fdt header fdt header get def totalsize echo "def=x${def}x" Thanks, Groetjes,

Hi @Vaclav Rada, You can also disable the systemd 'predictable naming convention' of interface naming by adding: net.ifnames=0 to your kernel commandline. This can be done in armbianEnv.txt by adding them to the extraargs variable as follows: extraargs=net.ifnames=0 Would be better to adjust your armbianEnv.txt instead of changing on-disk systemd service unit files, as they will be overwritten whenever an update comes along. I have not seen a situation myself where using the 'new' naming convention for network interfaces would work out better. But perhaps my use cases are not as flashy as other's 🙂 Groetjes,

Hi @Igor, Seems that U-Boot 2019.04-armbian-2019.04-S3c99-P6351-H9530-V0854-Bb703-R448a does not have the `setexpr` command configured. I will do more testing and figure out how the change can handle `setexpr` missing and configuring U-Boot to have `setexpr` available. Thanks! Groetjes,

Hi @Heisath, I think i can make a pull request from here: https://github.com/armbian/build/compare/main...djurny:build:patch-1, but would like to see someone else besides me test and scrutinize change. If positive results are in, I would very happy to finally contribute something! Groetjes,

Hi all, @Igor @0r31 I managed to come up with a more structural solution that should work for future increased sizes of the kernel/inital ramdisk as well. Let me know if you are interested in testing this out before I attempt to make a pull request, as some instructions are required to test this out. Changes are all in `boot.cmd` so no rebuilding or updating of U-Boot required. Based on the load addresses in U-Boot, reshuffled the loading of DT, kernel and initial ramdisk last. After loading the DT it will calculate the kernel load address based on the DT `totalsize`. After loading the kernel it will calcuiate the initial ramdisk load address based on the kernel filesize. Some other minor changes are also incorporated; `fdt resize <extrasize>` adter re-loading original DT when applying the overlays has failed. Skip the `fdt apply` and `fdt resize` for the SPI-SATA workaround. Results on my Helios4 with an old U-Boot 2018.11 below: Comments are welcome, Groetjes, boot-mvebu.cmd

HI @kratz00. I'm indeed trying to get myself familiiarized with the build system and making pull requests for this and some other little nitpicky things that I think might help others. Hi @Nova, There is also the Helios64, also from Kobol: https://kobol.io/ There have been some issues with it though, related to the DFS function and the 2.5Gbe NIC hardware. I'm running mine for some years already, albeit still on Buster (from 2020 with kernel 5.9.13). Also I am not using the DFS function and set the CPU frequency (fixed governor either powersave or performance) explicitly before it starts backing up (it's my long term backup server). Most probably the newest armbian will run without major issues - except the 2.5Gbe NIC functionality as that was hardware related. Groetjes, PS I'm not affiliated with Kobol in any way whatsoever.

Hi there, Seems like the kernel is waiting for the wrong filesystem to become available. If blkid shows you PTUUID="8cdc55ae-c576-6f4c-a793-0397a48dccf0 and not any UUID=... associated with a filesystem on that partition, that means that either you do not have a [root] filesystem on that partition or that your root filesystem is on another partition of your SDcard. A PTUUID is the UUID for the partition itself, not for a filesystem. i.e. An empty partition still has a PTUUID. Most (if not all) filesystems have a UUID. Using a UUID makes it easier to have the kernel identify where a/the root filesystem is located. as it is not guaranteed how the storage devices are discovered at boot time. A UUID is linked to the filesystem and not to the device where it is stored on. If you are convinced that you have a root filesystem on a certain partition of your SDcard, you can always use rootdev=/dev/mmcblk1p1 (or wherever your root filesystem lives) in your /boot/armbianEnv.txt to instruct the kernel to expect a root filesystem there. ...but that partition does need to actually have a root filesystem, unless you end up in the same situation you are describing. Can you share the output of sudo parted /dev/mmcblk1 u s pr and sudo blkid -g followed by sudo blkid /dev/mmcblk* ? Groetjes,