/srv/irclogs.ubuntu.com/2020/05/02/#ubuntu-devel.txt

fo0barwgrant: 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 image01:21
fo0barBTW, things have been pretty stable (at least from a general dev perspective; no idea how well the buildds are handling), thanks!01:23
wgrantfo0bar: 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
wgrantBut 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 ideal01:29
wgrantThat gets things booting like the suggested qemu args.01:30
fo0barwgrant: 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 latter01:31
wgrantI 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.bin01:32
fo0barah, I hadn't dived too much into OpenSBI itself and didn't know you could do that01:32
wgrantfo0bar: They're both GPT images (though the firmware is raw rather than qcow2 because it's small enough).01:33
wgrantBut they contain different partitions.01:33
fo0bar"wrapped in OpenSBI" makes more sense now01:33
fo0barbut huh, odd01:33
wgrantIt's pretty common for platforms to only support chaining to a single blob01:33
wgrantFortunately in this case the platform firmware is modifiable01:34
fo0baryeah, you need to do something similar with allwinner arm-trusted-firmware -> u-boot chaining IIRC01:35
fo0barhttps://pastebin.ubuntu.com/p/R8Qfd3KKDY/ <-- anyway, I'm still not sure why qemu-virt-20200422-ubuntu-firmware.bin doesn't look like a GPT table01:38
wgrantfo0bar: this is what you get for asking me questions while I'm time-shifted and haven't had coffee yet01:41
wgrantI missed that you were talking about the qemu one. That's just a flat OpenSBI+u-boot fw_payload.bin01:42
wgrantBecause there's no FSBL required01:42
fo0barwgrant: aha.  in my defense, I assumed you were tomorrow-ish like normal, and would get around to responding sometime monday :)01:43
wgrantSo 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 one01:43
wgrantOnly diff from master OpenSBI and u-boot there is CONFIG_PREBOOT to get extlinux working by default01:44
fo0baryeah.  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 build01:44
fo0barwgrant: 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 ago01:56
fo0barmaybe include an example libvirt definition: https://pastebin.ubuntu.com/p/KcGbFD4kw4/01:56
alkisgHi 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
ubottuLaunchpad 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!