web/lukegbcom: add 2023-08-08-uefi-boot-for-mochabin
This commit is contained in:
parent
7a8614d2f7
commit
d8de67e55a
1 changed files with 269 additions and 0 deletions
269
web/lukegbcom/posts/2023-08-08-uefi-boot-for-mochabin.md
Normal file
269
web/lukegbcom/posts/2023-08-08-uefi-boot-for-mochabin.md
Normal file
|
|
@ -0,0 +1,269 @@
|
||||||
|
---
|
||||||
|
title: "UEFI Boot for Mochabin"
|
||||||
|
date: 2023-08-08
|
||||||
|
layout: Post
|
||||||
|
hero: https://images.unsplash.com/photo-1506619216599-9d16d0903dfd
|
||||||
|
hero credit: https://unsplash.com/photos/XtUd5SiX464
|
||||||
|
hero credit text: "Jakub Dziubak"
|
||||||
|
classes:
|
||||||
|
header: header-black-gradient
|
||||||
|
---
|
||||||
|
|
||||||
|
MOCHAbin is a pretty capable ARM board - it has a quad core ARMv8 Cortex-A72 @
|
||||||
|
1400MHz, 8GB of RAM, 16GB of onboard eMMC, not to mention a _bunch_ of Ethernet
|
||||||
|
connectivity (1x 10Gb SFP+ cage, 1x 1Gb SFP cage, a WAN RJ45 port with PoE in,
|
||||||
|
and 4x LAN ports connected to an onboard switch chip).
|
||||||
|
|
||||||
|
The main downside for me, however, was the boot firmware. Out of the box, it
|
||||||
|
ships with a [pretty
|
||||||
|
ancient](https://github.com/globalscaletechnologies/u-boot-marvell/tree/u-boot-2020.10-gti)
|
||||||
|
build of U-Boot, which fails to properly support UEFI.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
There are other options: there are references to people using what I can only
|
||||||
|
assume to be some variant of Marvell's fork of EDK II to provide UEFI support.
|
||||||
|
However, I went down the route of trying to get a more modern version of U-Boot
|
||||||
|
working.
|
||||||
|
|
||||||
|
To cut a long story short, I got [Tow-Boot](https://tow-boot.org), a user-friendly
|
||||||
|
distribution of U-Boot with a pretty decent build system, to boot properly including
|
||||||
|
proper UEFI support.
|
||||||
|
|
||||||
|
## What works
|
||||||
|
|
||||||
|
- Environment storage in SPI flash
|
||||||
|
- Reading (and booting) from:
|
||||||
|
- eMMC
|
||||||
|
- USB
|
||||||
|
- EFI boot
|
||||||
|
|
||||||
|
## What's not tested
|
||||||
|
|
||||||
|
- The SFP+/SFP cages
|
||||||
|
- The WAN NIC
|
||||||
|
- SATA
|
||||||
|
- PCIe
|
||||||
|
|
||||||
|
## What doesn't work
|
||||||
|
|
||||||
|
- Any of the 4 "LAN" ports -- I think they require bringup of the switch chip,
|
||||||
|
and I haven't tried configuring that properly yet
|
||||||
|
- Using the actual `hw_info` SPI block that's supposed to hold the Ethernet MAC
|
||||||
|
addresses and PCB serial number.
|
||||||
|
|
||||||
|
## Building an image
|
||||||
|
|
||||||
|
If you want to build an image yourself, you'll need a Linux system with a
|
||||||
|
working install of [Nix](https://nixos.org). This doesn't need to be NixOS, Nix
|
||||||
|
on Debian should do just fine. You can even (probably) use Nix inside a Docker
|
||||||
|
container if you'd like.
|
||||||
|
|
||||||
|
Got that together? Alright:
|
||||||
|
|
||||||
|
1. Grab https://github.com/lukegb/Tow-Boot. The `lukegb/globalscale-mochabin`
|
||||||
|
branch should be the default, and it's what you'll need.
|
||||||
|
1. Run `nix-build -A globalscale-mochabin-8gb` (if you have the 8GB RAM
|
||||||
|
variant), or `nix-build -A globalscale-mochabin-4gb` (if you have the 4GB
|
||||||
|
variant).
|
||||||
|
1. Wait.
|
||||||
|
1. You should now have a `result` symlink that points to a directory with some
|
||||||
|
files in it. The one you probably want is
|
||||||
|
`result/binaries/Tow-Boot.spi.bin`, which is the build of Tow-Boot that uses
|
||||||
|
the SPI flash for storing the U-Boot environment.
|
||||||
|
|
||||||
|
At this point, you can use the instructions in "Recovering" below to use
|
||||||
|
`mvebu64boot` to just boot this once, to see what it's like, or continue below
|
||||||
|
to flash it as your main bootloader.
|
||||||
|
|
||||||
|
## Flashing
|
||||||
|
|
||||||
|
Apologies in advance: many of these steps _should_ be automated, but _aren't_.
|
||||||
|
There are various steps where you should take notes or backups of things so you
|
||||||
|
can restore your device to a working state later. Please do that, and copy them
|
||||||
|
somewhere safe!
|
||||||
|
|
||||||
|
You will need:
|
||||||
|
|
||||||
|
- a USB stick that you can wipe
|
||||||
|
- a micro-USB cable to use to connect to the MOCHAbin via USB-serial
|
||||||
|
|
||||||
|
### Getting set up
|
||||||
|
|
||||||
|
1. Wipe your memory stick. Put a ext2<sup>\*</sup> filesystem on it, and copy
|
||||||
|
`result/binaries/Tow-Boot.spi.bin` to it.
|
||||||
|
1. Turn off the MOCHAbin.
|
||||||
|
1. Unplug any other USB devices from the MOCHAbin, and connect your memory
|
||||||
|
stick.
|
||||||
|
1. Start your terminal emulator. The MOCHAbin runs at 115200 bps.
|
||||||
|
1. Turn on the MOCHAbin. When prompted to interrupt boot, press a key.
|
||||||
|
1. You should now have a `Marvell>>` prompt.
|
||||||
|
|
||||||
|
### Making sure everything is in place
|
||||||
|
|
||||||
|
1. Run `usb start`. You should get some output ending in `scanning usb for storage devices... 1 Storage Device(s) found`.
|
||||||
|
1. Run `usb part`. You should see your single, ext2 filesystem.
|
||||||
|
1. Run `ext2ls usb 0:1`. You should see the content of your filesystem,
|
||||||
|
including `Tow-Boot.spi.bin`.
|
||||||
|
|
||||||
|
### Backing up the SPI flash
|
||||||
|
|
||||||
|
1. Run `sf probe`. This should report `SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB, total 4 MiB`. This is the information about
|
||||||
|
your SPI flash. *If your SPI flash is not 4MiB, stop!*
|
||||||
|
1. Run `sf read $kernel_addr_r 0 0x400000`. This should report `device 0 whole chip` and then hang for 10s or so.
|
||||||
|
1. Run `ext4write usb 0:1 $kernel_addr_r /backupspi.img 0x400000`. This
|
||||||
|
should report `File System is consistent`, and then complete after between
|
||||||
|
6 and 15s.
|
||||||
|
|
||||||
|
### Backing up the environment block
|
||||||
|
|
||||||
|
1. Run `env export -t $kernel_addr_r`. This will appear to do nothing.
|
||||||
|
1. Run `ext4write usb 0:1 $kernel_addr_r /backupenv.txt $filesize`. This
|
||||||
|
should again report `File System is consistent`, then complete after a few
|
||||||
|
seconds.
|
||||||
|
|
||||||
|
### Noting down key environment variables
|
||||||
|
|
||||||
|
1. Run `env print ethaddr eth1addr eth2addr pcb_sn`.
|
||||||
|
1. Copy and save the output somewhere. **You'll need this later.**
|
||||||
|
|
||||||
|
### Flashing the new image
|
||||||
|
|
||||||
|
1. Erase your SPI flash: run `sf erase 0 0x400000`. This ensures you don't
|
||||||
|
have any of the existing U-Boot environment lingering around. This will
|
||||||
|
appear to hang for a few tens of seconds, then report `SF: 4194304 bytes @ 0x0 Erased: OK`.
|
||||||
|
1. Flash the new image: run `bubt Tow-Boot.spi.bin spi usb`.
|
||||||
|
|
||||||
|
### Rebooting and setting the environment again
|
||||||
|
|
||||||
|
1. Turn the power off, then on again
|
||||||
|
1. When prompted to interrupt boot, hit Escape or press Ctrl-C.
|
||||||
|
1. You'll now be presented with the Tow-Boot menu. Scroll down to `Firmware Console` using the arrow keys and hit enter.
|
||||||
|
1. Now instead of `Marvell>> `, you should get a `=> ` prompt.
|
||||||
|
1. For each of `ethaddr`, `eth1addr`, `eth2addr` and `pcb_sn`, run `env set $VARIABLE_NAME $THE_VARIABLE_VALUE_YOU_NOTED_DOWN_EARLIER`
|
||||||
|
1. Run `env save`. This should eventually print `OK`.
|
||||||
|
1. Turn the power off, then on again.
|
||||||
|
|
||||||
|
### Congratulations!
|
||||||
|
|
||||||
|
You now have Tow-Boot. If you have a UEFI-compatible boot medium (either on the
|
||||||
|
eMMC or over USB, for instance), it will Just Work(TM).
|
||||||
|
|
||||||
|
1. Take the memory stick and back up `backupspi.img` and `backupenv.txt`
|
||||||
|
somewhere safe.
|
||||||
|
|
||||||
|
<sup>\*</sup> Technically this could be ext4. I suggest ext2 because modern
|
||||||
|
Linux distros will enable some ext4 extensions that won't work by default, and
|
||||||
|
this is very temporary.
|
||||||
|
|
||||||
|
## Using an up-to-date DTB
|
||||||
|
|
||||||
|
U-Boot will automatically discover new DTBs from the boot partition. I have the
|
||||||
|
following setup (my EFI System Partition is mounted at `/boot`; adjust
|
||||||
|
appropriately if yours is `/boot/efi`):
|
||||||
|
|
||||||
|
```
|
||||||
|
/boot
|
||||||
|
/boot/dtb
|
||||||
|
/boot/dtb/marvell
|
||||||
|
/boot/dtb/marvell/armada-7040-mochabin.dtb
|
||||||
|
```
|
||||||
|
|
||||||
|
I copy this file from the DTBs shipped with my Linux kernel build on update; if
|
||||||
|
you don't do this then you will (I think?) inherit the DTB used by U-Boot.
|
||||||
|
|
||||||
|
## Recovering
|
||||||
|
|
||||||
|
Oops! Something went wrong and you need to recover. No sweat. The Marvell
|
||||||
|
BootROM supports sending it an image via X-Modem, and you can do that over the
|
||||||
|
USB-Serial interface.
|
||||||
|
|
||||||
|
The tool I've been using for doing this is
|
||||||
|
[`mvebu64boot`](https://github.com/pali/mvebu64boot), which is super simple. If
|
||||||
|
you have Nix, then this is available in recent `nixpkgs-unstable`, but this is
|
||||||
|
super trivial to build without Nix: just clone that somewhere and use `make`.
|
||||||
|
|
||||||
|
Make sure you don't have any terminal emulators open on the port, and run:
|
||||||
|
|
||||||
|
```txt
|
||||||
|
$ mvebu64boot -t -b path/to/flash-image.img /dev/ttyUSB0
|
||||||
|
|
||||||
|
# for instance:
|
||||||
|
$ mvebu64boot -t -b backupspi.img /dev/ttyUSB0
|
||||||
|
|
||||||
|
# or:
|
||||||
|
$ mvebu64boot -t -b result/binaries/Tow-Boot.spi.bin /dev/ttyUSB0
|
||||||
|
|
||||||
|
# or, using the bootloader images available from Globalscale's FTP (ftp://76.80.10.5/Downloads/Mochabin/bootloader_for_mochabin_hw-rev-1-5-0_20220905/):
|
||||||
|
$ mvebu64boot -t -b mochabin-bootloader-ddr4-8g-mvddr-41927ee-atf-277d4b6b-uboot-b794de0054-20220905-rel.bin /dev/ttyUSB0
|
||||||
|
```
|
||||||
|
|
||||||
|
(where ttyUSB0 is replaced with whatever device name you have for the flash
|
||||||
|
image you're booting)
|
||||||
|
|
||||||
|
Once this prints `Sending boot pattern...`, powercycle the MOCHAbin. You should
|
||||||
|
then get `BootROM is ready for image file transfer`, followed by a
|
||||||
|
rapidly-increasing percentage. This will take a few minutes - first the image
|
||||||
|
prolog needs to be sent, then there's a `Waiting for BootROM...` stage, then
|
||||||
|
the image itself. You'll then be presented with a serial terminal. Use `Ctrl-\ c` to exit.
|
||||||
|
|
||||||
|
This works for booting the Tow-Boot images you built, or the SPI flash backup
|
||||||
|
image I repeatedly reminded you to make.
|
||||||
|
|
||||||
|
To return to the previous image, boot to the U-Boot console (either the
|
||||||
|
built-in Marvell one or a Tow-Boot one), insert a memory stick containing the
|
||||||
|
image to flash from (I suggest ext2 again, for the same reasons as above) and
|
||||||
|
run `bubt backupspi.img spi usb`.
|
||||||
|
|
||||||
|
## Getting things working
|
||||||
|
|
||||||
|
NOTE: if you're just interested in building your own image, you can ignore
|
||||||
|
everything from this point on.
|
||||||
|
|
||||||
|
Getting things working was all relatively simple: upstream U-Boot 2022.07 and
|
||||||
|
2023.07 have pretty much all the hardware support that's required to boot this
|
||||||
|
board. The main thing missing is a device tree.
|
||||||
|
|
||||||
|
### Device trees
|
||||||
|
|
||||||
|
Device trees are effectively a description of what hardware is where: this
|
||||||
|
avoids some of the automatic configuration, and simplifies a bunch of
|
||||||
|
customization required to get things booting. The Linux kernel has a bunch of
|
||||||
|
these - and we're in luck, because Globalscale have been paying Sartura to
|
||||||
|
upstream a bunch of the hardware enablement required to get the MOCHAbin to
|
||||||
|
boot well
|
||||||
|
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/marvell/armada-7040-mochabin.dts).
|
||||||
|
|
||||||
|
There's one problem here, however: this DTS doesn't work inside the U-Boot
|
||||||
|
tree. U-Boot tries to be compatible with whatever Linux is doing so that device
|
||||||
|
trees are as portable as possible from the Linux source to the U-Boot tree, but
|
||||||
|
the specific naming of the `compatible` arguments is important for drivers, and
|
||||||
|
some of the includes are in different places.
|
||||||
|
|
||||||
|
Instead, I opted to take the device tree [from their version of
|
||||||
|
U-Boot](https://github.com/globalscaletechnologies/u-boot-marvell/blob/u-boot-2020.10-gti/arch/arm/dts/armada-7040-mochabin.dts),
|
||||||
|
and hack it together until it worked on a more recent version.
|
||||||
|
|
||||||
|
### Porting their device tree forwards
|
||||||
|
|
||||||
|
To give Globalscale credit, this mostly worked without a hitch. There are a few
|
||||||
|
differences (`phy-mode = "sfi";` needed to become `phy-mode = "10gbase-r";`),
|
||||||
|
but for the most part this... just worked.
|
||||||
|
|
||||||
|
I haven't tested a bunch of the functionality that I didn't need: in particular,
|
||||||
|
I don't plan on PXE booting or using any network functionality at startup. I also
|
||||||
|
don't have any drives connected over the internal M.2 SATA interface, so I couldn't
|
||||||
|
test that either.
|
||||||
|
|
||||||
|
### Future work
|
||||||
|
|
||||||
|
I'm hoping to, eventually:
|
||||||
|
|
||||||
|
- Try to get the Linux DTS working on U-Boot and upstream it.
|
||||||
|
- Get the 4 RJ45 LAN ports working.
|
||||||
|
- Check that the SATA M.2 port actually works.
|
||||||
|
- Get writable EFI variables working?
|
||||||
|
- Upstream my build to Tow-Boot proper.
|
||||||
|
- Getting the flashing steps automated in the Tow-Boot installer.
|
||||||
|
|
||||||
|
So stay tuned. Maybe.
|
||||||
Loading…
Reference in a new issue