marcz

I now use some uboot settings analogous to what you propose on the base of archinux configuration. But as you said value coded in uboot spi have to be changed when you update the kernel. This is the purpose of not storing kernel dependent values in the spi, but loading them from the device, like it is done in ArmbianEnv.txt or in archlinux in /boot/uEnv.txt. What I still does not understand is while the itb image, gives an error when trying to bootm from it. I agree that chaining UEFI bootloader should be a more flexible option, after updating the kernel it is very easy to do an update-grub, and let it generate the initrd and new grub code. And you don't have to touch the uboot itself. I have to learn more about uboot UEFI, before being able to try this option. I have never used the bootflows, so I have to learn. I have seen an interesting thread on the boot process in this forum in The boot process and various devices , beginning by a good summary by @ManoftheSea @bschnei you seem to have expertise in uboot, you should contribute to Armbian. Armbian is not to be despised, its strength is the maintenance of many sbc kernels that are not available in Debian or archlinux. And they have developed a build system that allow the update of so many device, a task out of reach of an individual alone.

to debug I launched the kernel with: setenv fdt_name dtb/marvell/armada-3720-espressobin.dtb setenv bootargs root=/dev/mmcblk0p1 rootwait ${console} ext4load mmc 0:1 $initrd_addr boot/uInitrd ext4load mmc 0:1 $kernel_addr_r boot/Image ext4load mmc 0:1 $fdt_addr_r boot/${fdt_name} booti $kernel_addr_r $initrd_addr $fdt_addr_r And it boots on the console, I will explore how I can set a more proper boot process.

The image contain in the boot/ directory: Marvell >> ls mmc 0:1 boot/ <DIR> 4096 . <DIR> 4096 .. <SYM> 32 Image <SYM> 28 dtb <DIR> 4096 dtb-5.15.149-current-mvebu64 38518 boot.bmp 0 .next <SYM> 32 uInitrd 1592 boot.cmd 4198770 System.map-5.15.149-current-mvebu64 95 armbianEnv.txt 1536 armbian_first_run.txt.template 1664 boot.scr 9681576 uInitrd-5.15.149-current-mvebu64 193310 config-5.15.149-current-mvebu64 21899776 vmlinuz-5.15.149-current-mvebu64 9681512 initrd.img-5.15.149-current-mvebu64 <SYM> 39 fdt.dtb 16578860 espressobin.itb and the content of armbianEnv.txt is board_version=v5 verbosity=1 rootdev=UUID=eb19bd31-6e1d-40ca-b936-d2823be614de rootfstype=ext4 The boot.cmd or boot.scr is "# Some tests to try to keep compatibility with old variables if test -z "${kernel_addr_r}"; then setenv kernel_addr_r $kernel_addr fi if test -z "${ramdisk_addr_r}"; then setenv ramdisk_addr_r $initrd_addr fi if test -z "${fdt_addr_r}"; then setenv fdt_addr_r $fdt_addr fi if test -z "${distro_bootpart}"; then setenv distro_bootpart 1 fi if test -z "${devtype}"; then setenv devtype $boot_interface fi load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}armbianEnv.txt env import -t ${scriptaddr} ${filesize} setenv bootargs "$console root=${rootdev} rootfstype=${rootfstype} rootwait loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} ${extraargs}" load $devtype ${devnum}:${distro_bootpart} $ramdisk_addr_r ${prefix}espressobin.itb bootm ${ramdisk_addr_r}#$board_version # fallback to non-FIT image if test -z "${image_name}"; then setenv image_name "Image" fi if test -z "${initrd_image}"; then setenv initrd_image "uInitrd" fi if test -z "${fdt_name}"; then if test -z "${fdtfile}"; then setenv fdt_name "dtb/marvell/armada-3720-espressobin.dtb" else setenv fdt_name "dtb/$fdtfile" fi fi load $devtype ${devnum}:$distro_bootpart $kernel_addr_r ${prefix}$image_name load $devtype ${devnum}:$distro_bootpart $ramdisk_addr_r ${prefix}$initrd_image load $devtype ${devnum}:$distro_bootpart $fdt_addr_r ${prefix}$fdt_name booti $kernel_addr_r $ramdisk_addr_r $fdt_addr_r # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr When trying to load in memory boot.scr and source it it fails, so to locate the problem I rather walk through the script step by step. I can load espressobin.itb: Marvell>> load $devtype ${devnum}:${distro_bootpart} $ramdisk_addr_r ${prefix}espressobin.itb 16578860 bytes read in 730 ms (21.7 MiB/s) but when trying to boot: Marvell>> bootm ${ramdisk_addr_r}#$board_version Wrong Image Format for bootm command ERROR: can't get kernel image! I don't understand why I get this wrong image format. The following fallback script does not work either, everything go well until the booti command then Marvell>> booti $kernel_addr_r $ramdisk_addr_r $fdt_addr_r ## Loading init Ramdisk from Legacy Image at 08000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 9681512 Bytes = 9.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 Loading Ramdisk to 7ecf0000, end 7f62ba68 ... OK Using Device Tree in place at 0000000006f00000, end 0000000006f05d61 Starting kernel ... "Synchronous Abort" handler, esr 0x02000000

Nice to know about your fork of globalscale boot loader, I may go further deeper in your project later on. For today I have no longer access to my board, I will post tomorrow the two files. For specifying the device the ArmbianEnv.txt use an UUID, so it does not dépend of the location of the device.

@bschnei you say that you don't use the distribution, I don't know what you meant. But if you have a similar board that is running Armbian, it could help if you tell me the image version and the environment you use.

I have set this value as you told @bschnei, and it changes nothing. After examining boot.scr that is first loaded, I see that root is reset in this script so the root env value does not matter. After setting the variables like cited above, it find the script it seems to load armbianEnv.txt but fail on the next load. but some parameter that are not set in my env nor ArmbianEnv.txt seem missing like this file size. I have only reset the default environment and set few variables, so it is easy to reset again. But I don't know how to find the extra parameters that are not set in armbianEnv.txt nor boot.scr.

Yes my environment is broken, this is the environment that I got by downloading the new u-boot image and resetting the environment to the default one. Now I am quite lost I don't know how to recover a proper environment. It seems that these erroneous root variables are in any case overridden by the boot.scr script. I see that some variables are necessary for running this script. At least ${devtype}, ${devnum}, ${distro_bootpart}, ${scriptaddr}, ${prefix}, ${filesize} some are easy like devtype=mmc devnum=0 distro_bootpart=1 prefix=boot/ I have seen elsewhere, but I don't know how to check it scriptaddr=0x6d00000 For filesize I have no idea in any case my load_script does not work. If somebody could help me to recover a proper basic environment, it would help a lot.

I try to boot for first time an espresso bin v5, I followed the advice in (Espressobin / Ultra – Armbian](https://www.armbian.com/espressobin/) and updated my uboot, and reset the environment. env default -a ## Resetting to default environment I added the image and fdt address with: setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb setenv image_name boot/Image setenv scriptaddr 0x6d00000 The last line is after seeing in the forum that this setting has been erased when resetting the default environment my environment is now: When I try to boot, it seems to load the initrd but never complete the boot I get: Marvell>> boot *** ERROR: `serverip' not set *** ERROR: `serverip' not set ... booting from SD 1631 bytes read in 9 ms (176.8 KiB/s) ## Executing script at 00800000 load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. ## Info: input data size = 2100 = 0x834 load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. bootm - boot application image from memory Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image When booting a Linux kernel which requires a flat device-tree a third argument is required which is the address of the device-tree blob. To boot that kernel without an initrd image, use a '-' for the second argument. If you do not pass a third a bd_info struct will be passed instead Sub-commands to do part of the bootm sequence. The sub-commands must be issued in the order below (it's ok to not issue all sub-commands): start [addr [arg ...]] loados - load OS image ramdisk - relocate initrd, set env initrd_start/initrd_end fdt - relocate flat device tree cmdline - OS specific command line processing/setup bdt - OS specific bd_t processing prep - OS specific prep before relocation or go go - start OS 21764608 bytes read in 2021 ms (10.3 MiB/s) ext4load - load binary file from a Ext4 filesystem Usage: ext4load <interface> [<dev[:part]> [addr [filename [bytes [pos]]]]] - load binary file 'filename' from 'dev' on 'interface' to address 'addr' from ext4 filesystem 11618 bytes read in 12 ms (945.3 KiB/s) ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 Using Device Tree in place at 0000000006f00000, end 0000000006f05d61 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 5.15.48-mvebu64 (root@8b3d501f9218) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #22.05.3 SMP PREEMPT Wed Jun 22 07:22:16 UTC 2022 [ 0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board [ 0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '') ..... Omitted a long boot log .... [ 2.376178] Key type fscrypt-provisioning registered [ 2.383950] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no [ 2.394740] d0012000.serial: ttyMV0 at MMIO 0xd0012000 (irq = 0, base_baud = 1562500) is a mvebu-uart [ 2.404251] printk: console [ttyMV0] enabled [ 2.404251] printk: console [ttyMV0] enabled [ 2.412987] printk: bootconsole [ar3700_uart0] disabled [ 2.412987] printk: bootconsole [ar3700_uart0] disabled [ 2.425972] xenon-sdhci d00d0000.sdhci: Got CD GPIO [ 2.464648] mmc0: SDHCI controller on d00d0000.sdhci [d00d0000.sdhci] using ADMA [ 2.473851] Waiting for root device ... [ 2.512635] mmc0: new high speed SDHC card at address d6d7 [ 2.520455] mmcblk0: mmc0:d6d7 SU08G 7.40 GiB [ 2.531514] mmcblk0: p1 It seems that my boot env is incomplete. I tried with the last bullseyes and bookworm image, with the same result. I also tried the instructions in Armbian Documentation - Esspresso bin even if it seems obsolete by now, as it uses old uboot variable names, and contain a booiti command after sourcing the boot.scr script which itself contain the booti command; but I got the same result, even if the inird addr was distinct. Please what is wrong, and what I'm missing in this uboot environment.

I have no expertise in this domain, so I'm not sure it is related to your problem; but I remark that you have a typo in your env instead of scriptaddr=0x6d0000

For marvell-mvebu build DRBD is not supported, the module is missing in either current and edge config a grep of CONFIG_BLK_DEV_DRBD in build/config/kernel from the git build repo shows that most boards have DRBD compiled as module except some few exceptions. One of these few exception is mvebu (ClearFog Base/Pro, ESPRESSObin, Helios 4). I don't understand why. DRBD is a very nice and secure block device which provides network block replication (raid over network), and it is widely used. DRDB compile and work flawlessly on helios4 with the mvebu kernel. But we are obliged to compile the kernel or only the module, which is somewhat painful. As I have an helios4 which provides a DRBD node, I first compiles three years ago the module using the current kernel headers,. Then I refrained from updating since I was needing this DRDB node. But now I need to update to buster, so I updated to the current branch. Of course I lost my DRBD device, and so I compiled a home made kernel. This is now technically very easy with the new build environment and docker. compile.sh and the associated set of bash scripts are very handy and well conceived. Thank you for the developers who did this work. But with my servers t has been nevertheless very long and painful. I have only low power servers, and my gateway upper download rate is 300KB. So when I tried the script it could not download anything, I found that it gives to aria2c a lowest speed limit of 500K, so no hope to download something on my network. I tried to change this limit. I tried many value, usually I could down load at 220K, but it seems that the speed can slow down during short period of time, so my downloads aborted. I had to reduce this minimal speed to 70KB to be able to download the software. Then I compiled the kernel 14h of compilation on my machine! Next time I will try either to launch a temporary instance on a VPS with better bandwidth, and/or install DISTCC, but I have never tried discc in docker, and I have to learn. Now running current-mvebu_22.11.0-trunk with kernel 5.15.76, drbd works flawlessly on helios4. But for next release I strongly wish that it would be incorporated in the distribution. I think it could be useful for people looking fr a server to support a drbd node. But how to request it, posting in the github issues? doing a PR seems quite overkill to just replace 'n' by 'm' in CONFIG_BLK_DEV_DRBD.

I was just pointing out that even if "Nightly" are unavailable, "Other" can still work. Since the previous post answered that "Other" is working. So is just to avoid confusion between these two actions, if some other people happen to read this thread, and to tell them, don't do like I did, first look at available packages.

First in armbian-config the entry is not the same that nightly build, the first one look for an other kernel in the same apt.debian.com repository so you can switch to an other version without changing your source list in armbian.list, going back to the old kernel work flawessly, but nightly change the repository, this is why if your distribution is missing after deleting packages, you cannot go forward installing inexistent nightly build, nor backward since the stable packages are not there either. EspressoBin is not the same than helios4 since the first is arm64 and the second armhf, but looking to https://beta.armbian.com/dists/buster/main/binary-arm64/Packages it seems it is also currently missing in nightly builds; and I guess that if you try on your board to switch to nightly builds, may be you non longer can tell that

I looked in armbian-config and the debian-config-functions and I may have found why the test of downloading did not work. At the beginning of reload_bsp we update the cache to use beta.armbian.com which does not include the architecture and the board. So all lookup by apt-cache fail, In this case the PACKAGE_LIST is set to the old packages, so the download work and no error is returned. The the purge is not done on the the PACKAGE_LIST but on a fixed list of package, which may be or not in PACKAGE_LIST. When trying to reinstall the purged packages are missing. This as a script which is quite complicated if we have to consider all combination of parameters, and I don't think I am able to give a pull request that will not break a lot more than what it will repair. But I would suggest that if the apt-cache lookup always fail, the script exit without deleting anything. And only purging the PACKAGE_LIST that has been downloaded.

Yes it is what is done in #1597 now in the kernel tree.

Sorry Igor if my post looks like ranting, it was not my purpose, I don't want to protest against any defect, if it looks so I apologize. This title that I thought to be a joke mimicking tabloids title , may have caused a misunderstanding. I was knowing that switching to nightly build could break the system, but I was supposing it is because a defect in or incompatibility in the development package, I was surprised the script uninstall packages without verifying there is a replacement. I wanted also to tell other users of Helios4 to care not to switch to nightly build without first checking it exists. When I asked "and why?" it was not a complain, but I would like to know why this architecture is missing. For the armbian-config script, I did not know if it could be useful to open an issue on github, so I asked here, with your answer I suppose, that such issue is not welcome until I can submit a push request. I'm new, no to armbian, but to armbian build system. It is why I was asking the question about how to build a module, looking at the forum, I have found people having tried different methods, but I don't know what is the right way. May be I have to reinstall my broken banana pi, and wait for linux-mvebu64-next for DRBD. I apologize again if something could look offensive in my post, I am thankful to developers who provide this great distribution, and hope not to hurt anybody.