I’m wondering if anyone here has had success setting up an ArchARM install. I saw the one thread but it looks like the person there is still booting to the SD card and then handing over to NVME.
I’ve done EFISTUB installs on x86 before so I think I understand that portion, I’m hazy on the uboot config though.
Other places metion a /uEnv.txt (or /extlinux/extlinux.conf) for configuring uboot at runtime but I placed those in the SD card root folder as a test and it didn’t seem like the installed uboot image respected them because it booted to the SD card as usual (no failure and no nvme boot). I pulled the uboot build from the mnt gitlab but I don’t see an obvious way to bake in the bootargs and load commands and would like to leave those as something that can be configured without a reflash. The reform image doesn’t seem to have a uEnv.txt or a extlinux.conf file so I’m wondering how they pass in the harware dtb file at boot.
Is Image (or Image.gz) the arm equivalent of vmlinuz-linux?
Looking at the kernel repo for the reform there are some patches, does that mean I’ll need to use that as my kernel as well, at least until the patches are upstreamed?
I have written up instructions for manually compiling, configuring and installing u-boot. You can find them in the Gentoo wiki. The process should be pretty much the same across all distributions.
What happens is that u-boot loads a boot-script (boot.scr) and then that script loads the kernel, the initrd and the .dtb file. The kernel parameters are also described in that file. So when you have a new kernel or want to change the parameters, there is no need to re-flash. Just compile a new boot.scr and copy it to the SD-card / internal FLASH where you boot from.
About the kernel… It’s the 5.17 from sysimage V3 I’m struggling with. I was able to build and am currently using the 5.12 kernel that came with sysimage v2. To build it, I applied the patches and copied in the configuration file and the .dts file contained in the repository. Then I ran make -j5 Image modules freescale/imx8mq-mnt-reform2.dtb.
I am not sure about the technicalities, but I would say you are right in comparing the resulting Image with the vmlinuz files on x86. The file type, when probed with file, should be Linux kernel ARM64 boot executable Image, little-endian, 4K pages. I ended up with a gz-compressed image at some point which did not work at all
Thanks for the info, that helps a lot. So it looks like I need to compile the script and run it that way. I’m curious if you’ve experimented with flashing the script to the internal flash? I know you haven’t updated the guide yet but I’m wondering if you’ve had any success before I go risking it. I do have a black magic probe for reflashing via JTAG but I don’t even know if it supports the i.mx8.
I did actually flash the bootloader to the internal storage once, but that was about a year back, with an older version of u-boot.
I think the risk of flashing to the internal storage is manageable. Wether the system boots from internal storage or from the SD-card is determined by a dip-switch on the SOM, so even if you mess up, you should be able to boot from SD and then fix your mistake, no need for a JTAG. That said, make sure your SD-card boots correctly beforehand.
Also remember that the dip-switch on the SOM only determines where the bootloader is loaded from (SD-card or internal storage), but the bootloader itself can then load the bootloader configuration file (boot.scr) and the OS (vmlinuz, initrd, dtb-file and boot.scr) from a different location alltogether. So you can mix-and match, having, for example, the bootloader on the SD-card but then load the configuration file (boot.scr) and the OS (vmlinuz, initrd, dtb-file and boot.scr) from the internal storage. In fact, I would recommend doing just that; place the boot.scr, the kernel, initrd and dtb-file in /dev/mmcblk0p1 and then flash the bootloader to a new, empy SD-card and attempt to boot from that. If that works, you know that in principle, all of your components work just fine. So when you make the last step and flash to the internal storage and flip the dip-switch, the chances of it working are very high. Plus, if it doesn’t work, there is pretty much only one possible source of error left, which then makes it easier to debug.
I will write up detailed instructions sometime in the future, but removing the heatsink to get to the dip-switch is a bit of a hassle and I first want to have a good kernel and initrd, so it might be some time…
