@lykso I don’t know if you already are collaborating with @vagrantc ?
I’m currently struggling with getting u-boot to work for my imx8mp pocket reform. So far I’ve tried to:
(define-public u-boot-imx8mp-reform-bin
(package
(name "u-boot-imx8mp-reform-bin")
(version "2025-01-12")
(source (origin
(method url-fetch)
(uri "https://source.mnt.re/reform/reform-imx8mp-uboot/-/jobs/7404/artifacts/raw/imx8mp-mnt-pocket-reform-flash.bin")
(sha256 (base32 "1avydp0643hq12y057iyaqwzbb4in66wbakj3jc53gg75k7f044c"))
(file-name "imx8mp-mnt-pocket-reform-flash.bin")))
(build-system copy-build-system)
(arguments
`(#:install-plan '(("imx8mp-mnt-pocket-reform-flash.bin" "bin/"))))
(native-inputs (list coreutils))
(home-page "https://source.mnt.re/reform/reform-imx8mp-uboot")
(synopsis "Prebuilt U-Boot binaries for MNT Reform i.MX8MP")
(description "This package provides prebuilt U-Boot binaries for Pocket Reform devices based on the i.MX8MP processor.")
(license gpl2+)))
(define install-pocket-reform-bootloader
#~(lambda (bootloader root-index image)
(let ((u-boot (string-append bootloader
"/bin/imx8mp-mnt-pocket-reform-flash.bin")))
(write-file-on-device u-boot (stat:size (stat u-boot))
image (* 8 1024)))))
(define imx8mp-bootloader
(bootloader
(inherit u-boot-bootloader)
(package u-boot-imx8mp-reform-bin)
(disk-image-installer install-pocket-reform-bootloader)))
...
(operating-system
...
(bootloader (bootloader-configuration
(bootloader imx8mp-bootloader)))
...
simply use copy-build-system for the boot loader package, as well as another approach which builds u-boot from a local u-boot fork that has every steps and patches from the .gitlab-ci.yml · main · Reform / MNT Reform i.MX8MPlus U-Boot Build · GitLab applied:
(define-public install-imx8mp-u-boot
#~(lambda (bootloader root-index image)
(let ((u-boot (string-append bootloader "/libexec/flash.bin")))
(write-file-on-device u-boot (stat:size (stat u-boot))
image (* 33 1024)))))
(define-public u-boot-imx8mp
(let ((base (make-u-boot-package
"nitrogen8mp"
"aarch64-linux-gnu"
#:defconfig "imx8mp-mnt-pocket-reform_defconfig")))
(package
(inherit base)
(source (local-file "/home/willow/devel/u-boot" #:recursive? #t))
(inputs (modify-inputs (package-inputs base)
(append openssl)))
(arguments
(substitute-keyword-arguments
(package-arguments base)
((#:phases phases '%standard-phases)
#~(modify-phases #$phases
(replace 'configure
(lambda* (#:key make-flags #:allow-other-keys)
(copy-file "imx8mp-mnt-pocket-reform_defconfig" ".config")))
(replace 'build
(lambda* (#:key make-flags #:allow-other-keys)
(apply invoke "make" `(,@make-flags "flash.bin")))))))))))
(define-public u-boot-imx8mp-bootloader
(bootloader
(inherit u-boot-bootloader)
(disk-image-installer install-imx8mp-u-boot)
(package u-boot-imx8mp)))
...
(operating-system
...
(bootloader (bootloader-configuration
(targets '("/dev/mmcblk0"))
(bootloader u-boot-imx8mp-bootloader)))
...
)
in both cases I’m unable to boot guix and it seems to fall back to the emmc (given I get a initramfs REPL after a systemd related message). The u-boot package does seem to look fine though:
~/devel/u-boot$ ls /gnu/store/58kn7bh3192lz1bwfym4bm1v9phrnxcc-u-boot-nitrogen8mp-2025.01/libexec
arch bl31-iMX8MQ.bin bl31-tee-iMX8MP.bin dts lpddr4_pmu_train_1d_dmem_202006.bin scripts tools u-boot-nodtb.bin u-boot.img
bl31-iMX8MM.bin bl31-iMX8ULP.bin bl31-tee-iMX8MQ.bin flash.bin lpddr4_pmu_train_1d_imem_202006.bin spl u-boot u-boot-spl-ddr.bin u-boot.itb
bl31-iMX8MN.bin bl31-tee-iMX8MM.bin bl31-tee-iMX8ULP.bin itb.fit.itb lpddr4_pmu_train_2d_dmem_202006.bin spl.bin u-boot-dtb.bin u-boot.bin
bl31-iMX8MP.bin bl31-tee-iMX8MN.bin doc lib lpddr4_pmu_train_2d_imem_202006.bin tee-imx8mp.bin u-boot-dtb.img u-boot.dtb
so I suspect, it’s either me messing up the offset or the targets or something along those lines?
Please be careful with flashing a custom u-boot to eMMC of imx8mp. Flashing a non-working u-boot may soft brick your device. In case this happens, unbricking it is a bit more involved: Flashing eMMC Bootloader / Unbricking (IMX8MP)
Originally, flashing a different u-boot wasn’t even a thing that was considered to be a feature by MNT unless you really, really, really knew what you were doing: 2024-08-04.log
That’s why for a long time, reform-flash-uboot would completely disallow flashing u-boot on imx8mp. These days, it will let you flash it but only if the hash matches the known latest one and even then only with a big fat warning.
Even with the stock u-boot on eMMC, that u-boot will first try to read boot.scr or extlinux.conf from the first partition of your sd-card. It does not matter that u-boot is on eMMC. The sd-card will be tried first. It does not matter where your u-boot got loaded from and imx8mp cannot load u-boot from your sd-card. So if the stock u-boot does not load your system on sd-card, then you might’ve misconfigured boot.scr or extlinux.conf on your sd-card.
You probably have a UART adapter to figure out what is going on early in the boot process? If yes, please post some output so that we can figure out why it still boots your system on eMMC instead of your system on sd-card. If no, I would really not recommend you flash your custom u-boot image to emmc…
1 Like
Thanks for the in-depth explanation and the word of warning regarding putting a custom u-boot on emmc! I think:
Even with the stock u-boot on eMMC, that u-boot will first try to read
boot.scrorextlinux.conffrom the first partition of your sd-card.
is where my generated image is faulty, it seems to have a EFI partition:
fdisk -l /gnu/store/baqznidcfg10gc5q03a53fgn26vv783d-disk-image
Disk /gnu/store/baqznidcfg10gc5q03a53fgn26vv783d-disk-image: 2.18 GiB, 2345885696 bytes, 4581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/gnu/store/baqznidcfg10gc5q03a53fgn26vv783d-disk-image1 2048 83967 81920 40M ef EFI (FAT-12/16/32)
/gnu/store/baqznidcfg10gc5q03a53fgn26vv783d-disk-image2 * 83968 4581807 4497840 2.1G 83 Linux
that’s not needed and shouldn’t be there. Guix does have other image-types (image-type Reference (GNU Guix Reference Manual)), so I’m currently trying my luck with raw-with-offset-image-type as that only generates an image with one partition. The boot/extlinux/extlinux.conf seems to be correctly generated at least.
Even with the stock u-boot on eMMC, that u-boot will first try to read
boot.scrorextlinux.conffrom the first partition of your sd-card. It does not matter that u-boot is on eMMC. The sd-card will be tried first.
If I read this correctly, I don’t have to build my own u-boot as a part of the sd-image then? and probably am able to rely on the stock u-boot to find boot/extlinux/extlinux.conf on my sdc and boot up guix? that’d be pretty cool, always assumed I had to build u-boot myself and put it on the sdc.
Edit: So with the single-partition image I get:
Warning: Type of root filesystem is unknown, so skipping check.
mount: mounting 38af4c98-533d-621b-e9fd-c91338afc93 on /root failed. No such file or directory.
Failed to mount 38af4c98-533d-621b-e9fd-c91338afc93 as root file system.
and then I’m dropped to initramfs. Was able to verify that the UUID matches the SDC partition:
/dev/mmcblk0p1: LABEL="Guix_image" UUID="38af4c98-533d-621b-e9fd-c91338af4c98" BLOCK_SIZE="4096" TYPE="ext4"
think I may have to use a different image type in the guix system image vommand/maybe a different offset?
That is correct. The imx8m+ will not try to read u-boot from the sd-card, so flashing u-boot onto the sd-card is pointless. Stock u-boot from eMMC will find your /extlinux/extlinux.conf from the first partition on your sd-card and then you “just” need to have that extlinux.conf set up with the correct parameters to continue booting.
How does the uuid match? From the error output, your uuid is:
38af4c98-533d-621b-e9fd-c91338afc93
But in your second command, the uuid is:
38af4c98-533d-621b-e9fd-c91338af4c98
The two are not the same.