On Thu, Jun 20, 2019 at 1:16 AM Andrea Bolognani <abolo...@redhat.com> wrote: > > On Wed, 2019-06-19 at 11:23 -0700, Alistair Francis wrote: > > On Wed, Jun 19, 2019 at 7:42 AM Bin Meng <bmeng...@gmail.com> wrote: > > > On Wed, Jun 19, 2019 at 10:30 PM Alistair Francis <alistai...@gmail.com> > > > wrote: > > > > On Wed, Jun 19, 2019 at 7:26 AM Bin Meng <bmeng...@gmail.com> wrote: > > > > > > pc-bios/opensbi-riscv32-fw_jump.elf | Bin 0 -> 197988 bytes > > > > > > pc-bios/opensbi-riscv64-fw_jump.elf | Bin 0 -> 200192 bytes > > > > > > > > > > Since we are considering adding "bios" images, I prefer to add the > > > > > pure binary images instead of ELF images here. > > > > > > > > I didn't think about that. Can we just boot them in QEMU like we do > > > > with the ELFs? > > > > > > Yes, use load_image_targphys() instead of load_elf(). > > > > Ah, that is obvious. I'll update it to use the bin files then. > > I'm unclear on the advantages of using one format over the other,
The main one that I see is that everyone else is already using .bin and no one else is using .elf. > but one question comes to mind: once this is in, we will probably > want to have OpenSBI packaged separately in distributions, the same > way it already happens for SeaBIOS, SLOF and edk2-based firmwares. > > Will using either of the formats prevent that from happening? Both options allow this. OE-Core already packages OpenSBI by default, Fedora and Debian are moving to OpenSBI for RISC-V targets as well. Any distro that supports the RISC-V toolchain (which is all upstreamed) can build OpenSBI. Alistair > > -- > Andrea Bolognani / Red Hat / Virtualization >