[01:21] <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:23] <fo0bar> BTW, things have been pretty stable (at least from a general dev perspective; no idea how well the buildds are handling), thanks!
[01:27] <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:29] <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:30] <wgrant> That gets things booting like the suggested qemu args.
[01:31] <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:32] <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:33] <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:34] <wgrant> Fortunately in this case the platform firmware is modifiable
[01:35] <fo0bar> yeah, you need to do something similar with allwinner arm-trusted-firmware -> u-boot chaining IIRC
[01:38] <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:41] <wgrant> fo0bar: this is what you get for asking me questions while I'm time-shifted and haven't had coffee yet
[01:42] <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:43] <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:44] <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:56] <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/
[05:38] <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]
=== acheronuk is now known as RikMills
=== gusnan is now known as Guest45142