fo0bar | wgrant: how is qemu-virt-20200422-ubuntu-firmware.bin built? it contains both OpenSBI and u-boot, but doesn't appear to be either a straight concatenation of them, or the GPT wrapper as with the hifive image | 01:21 |
---|---|---|
fo0bar | BTW, things have been pretty stable (at least from a general dev perspective; no idea how well the buildds are handling), thanks! | 01:23 |
wgrant | fo0bar: the firmware image is a GPT image with two partitions: the FSBL, and an OpenSBI fw_payload build with u-boot as the payload. OpenSBI can embed the payload for cases where the firmware can only load one. | 01:27 |
wgrant | But because we control FSBL, it is possible to use OpenSBI's fw_jump, and have u-boot on a separate partition, which makes things a bit more sensible. I prototyped it last week in https://github.com/wgrant/freedom-u540-c000-bootloader/commit/2e133a6d1437d4644d634c632d33793eddfe3564 and it works nicely, but obviously a diverged FSBL isn't ideal | 01:29 |
wgrant | That gets things booting like the suggested qemu args. | 01:30 |
fo0bar | wgrant: so TBC, you're saying both the hifive-unleashed and qemu-virt bins are GPT images assembled as described in your README? because fdisk recognizes the former as such, but not the latter | 01:31 |
wgrant | I can write up exactly how I built the existing firmware image, but the only slightly odd thing was basically just building OpenSBI with FW_PAYLOAD_PATH=u-boot-dtb.bin and then using fw_payload.bin rather than fw_jump.bin | 01:32 |
fo0bar | ah, I hadn't dived too much into OpenSBI itself and didn't know you could do that | 01:32 |
wgrant | fo0bar: They're both GPT images (though the firmware is raw rather than qcow2 because it's small enough). | 01:33 |
wgrant | But they contain different partitions. | 01:33 |
fo0bar | "wrapped in OpenSBI" makes more sense now | 01:33 |
fo0bar | but huh, odd | 01:33 |
wgrant | It's pretty common for platforms to only support chaining to a single blob | 01:33 |
wgrant | Fortunately in this case the platform firmware is modifiable | 01:34 |
fo0bar | yeah, you need to do something similar with allwinner arm-trusted-firmware -> u-boot chaining IIRC | 01:35 |
fo0bar | https://pastebin.ubuntu.com/p/R8Qfd3KKDY/ <-- anyway, I'm still not sure why qemu-virt-20200422-ubuntu-firmware.bin doesn't look like a GPT table | 01:38 |
wgrant | fo0bar: this is what you get for asking me questions while I'm time-shifted and haven't had coffee yet | 01:41 |
wgrant | I missed that you were talking about the qemu one. That's just a flat OpenSBI+u-boot fw_payload.bin | 01:42 |
wgrant | Because there's no FSBL required | 01:42 |
fo0bar | wgrant: aha. in my defense, I assumed you were tomorrow-ish like normal, and would get around to responding sometime monday :) | 01:43 |
wgrant | So it's the same as the second partition of the HFU image, except built for qemu and not wrapped in GPT because there only needs to be one | 01:43 |
wgrant | Only diff from master OpenSBI and u-boot there is CONFIG_PREBOOT to get extlinux working by default | 01:44 |
fo0bar | yeah. the missing magic was, at first glance at the opensbi tree, it didn't look like you could just embed a u-boot payload during build | 01:44 |
fo0bar | wgrant: thanks. I was thinking of doing a deeper dive, putting together updated images and writing a blog post, but then saw that you were already 99% there with https://people.ubuntu.com/~wgrant/riscv64/ since the initial upload a month ago | 01:56 |
fo0bar | maybe include an example libvirt definition: https://pastebin.ubuntu.com/p/KcGbFD4kw4/ | 01:56 |
alkisg | Hi all, https://bugs.launchpad.net/snapd/+bug/1867415 was marked as resolved, but I still see it in the final 20.04 live CDs, I did comment there, am I supposed to reopen it? | 05:38 |
ubottu | Launchpad bug 1867415 in snapd (Ubuntu) "Hardlinking snaps wastes 400 MB tmpfs RAM in live CDs" [Critical,Fix released] | 05:38 |
=== acheronuk is now known as RikMills | ||
=== gusnan is now known as Guest45142 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!