Boot on real RISC-V hardware - the MangoPi MQ-Pro #99
Conversation
…ld it We had this in-tree a while ago and got rid of it because QEMU ships with its own version. However, now we're building for hardware, we need a way to supply it, and it seems sensible to have a nice `xtask` command to build it. In the future this can be extended to know how to build OpenSBI for each platform.
This is just intended to prove that the D1 + FEL etc actually does work, because naively uploading OpenSBI and running it does not produce output (probably because it doesn't know where the UART is without a device tree lmao). It's named `d1_boot0` because it will become the boot-shim (known as the SPL in U-Boot terminology, or `boot0` in the D1 bootloader) for both FEL booting and booting from a persistent medium.
We were actually getting problems with squirting out too many bytes and messing up the UART, so listen to its line control register to send bytes at a rate it can handle. This differs from QEMU's UART in that each register is 4-bytes instead of 1 - we need some way of dealing with all these platform differences in the future, but for `boot0` we can just shove a new serial definition in here. Also includes some formatting changes bc we got nvim's auto-formatter working again.
IsaacWoods
force-pushed
the
d1
branch
3 times, most recently
from
c7ef89f
to
7e87054
Compare
Getting upstream OpenSBI workingThe remaining issues with getting upstream OpenSBI to boot seem to be around strange changes to the address of things from Confusingly, building OpenSBI with Working theory is something strange is going on with the early relocation logic - will need to work out what it's doing. Edit: |
|
Getting the D1 booting our code through OpenSBI has been more time-consuming than I'd expected (e.g. finding a valid device tree, getting OpenSBI booted, etc.) so I think I'll reduce the scope of this PR to basically getting Seed booting (which is now largely succeeding!) and will work on further functionality in other PRs or directly into |
These are both RISC-V platforms, obviously, but actually need relatively different build infra. For now, we're just completely severing the relation between them, but I imagine in the future we can reconnect similar platforms that'll have shared components.
The flags thing was acting strangely for some reason, which was fixed by upgrading it. Also makes some of the code a little nicer!
The device tree we got out of U-Boot for the MQ-Pro is full of extra stuff and also doesn't actually work... This was a real pain but we've extracted a working version from Linux (manually sticking bits of their device-tree system together lmao) - this provides an easy way to (mostly) correctly pre-process and then compile a device tree in this format.
The D1's UART controller has 4-byte registers instead of one. This information should be gathered from the device tree, but for now this just hardcodes it.
We need to load at different addresses on each platform - the easiest way to do this seems to be duplicating the linker scripts, but this doesn't seem super optimal. Fine for now.
Finding this was way more difficult than I anticipated... This is clearly not entirely correct, because it won't boot on an unpatched OpenSBI lmao. However, it's basically directly copied from the Linux DT for the same platform, so not quite sure what's going wrong yet. Will need more investigation.
This avoids having to open something like `minicom` separately, which is a nice ergonomics win. Not sure if we'll need something more complex in the future, but this is a nice start for now.
I'm not sure why the original device tree doesn't include this - a mystery for the future because Seed needs one to boot, and we can easily just add it here? There are actually multiple models of the MQ-Pro that have different amounts of RAM, so we could support that in the future.
This is obviously not required as part of the D1 boot, but does: - Stop it from crashing the D1 when a Virtio device is not present - Provide an abstraction we can then use for the ramdisk for FEL booting - Provide an abstraction we can use for an SDHC driver in the future - Hopefully move kernel loading forward for both Risc-V platforms (by getting rid of the horrendous QEMU-memory-poking hack we're currently using)
The UART spuriously produces invalid UTF-8, presumably because of corrupted bytes (likely due to the slightly dodgy situation with the wiring). We'll resolder it when we have access to an iron, but for now we (and probably for the long-term) it's probably a good idea to just accept dodgy input, rather than hard-erroring.
For some reason we were saving and then outputting the output from building OpenSBI - this is not the behaviour we want.
This is actually left from when we were going in a very different direction, but reasonably might be useful at some point so we'll keep it around. We do need to gracefully handle a platform not having a PCIe host node though.
See comment in crate. This should be ignored and is useful for now, but will be needed when we work on booting the D1 from persistent media, so we might as well leave it lying around.
Closes #98
This PR builds out support for the desired development workflow for the MangoPi MQ-Pro - using
xfelto load code from a host computer, which will also handle DRAM initialization etc.Booting from persistent media (SD-card or flash) will require more support, namely an initial boot shim that can initialize the DRAM and load further boot stages from the media (this PR will likely contain the start of this package (
d1_boot0) - this was because I initially thought we'd need this shim onxfel-booted systems too, but looks like we won't).xfel, make sure serial output works etc.xtaskxtasksupport for compiling device treesBefore merging:
fix CIcommits into original breakagescargo xtask opensbirespect config file platformd1_boot0