Re: [Qemu-riscv] [Qemu-devel] [PATCH for-4.1 2/2] target/riscv: Add support for -bios "firmware_filename" flag

[Alistair Francis]

On Fri, May 31, 2019 at 3:38 PM Jonathan Behrens <address@hidden> wrote:
>
> I've thought some more about this issue, and long term I think there are a 
> couple different useful configurations:
>
> For end users, having default firmware that loaded the OS from a block device 
> would be easiest
>
> Current invocation: impossible
> Proposed: empty command line (i.e. pass neither -bios nor -kernel)
>
> Custom firmware support would be good to test possible firmware improvements 
> or if the default is missing something
>
> Current invocation: -kernel firmware.elf
> Proposed: -bios firmware.elf
>
> A kernel developer may want to test a kernel binary without having to make a 
> full disk image or bundle firmware (on x86 and perhaps other architectures 
> this is done with the -kernel parameter, but for RISC-V that invocation 
> currently is used to load M-mode code rather than supervisor code)
>
> Current invocation: impossible
> Proposed: -bios firmware.elf -kernel kernel.bin
> Ideally `-kernel kernel.bin` be the same except using default firmware, but I 
> don't know if QEMU would be willing to deprecate the current syntax to allow 
> it
>
> For now, it is probably too early to add default firmware (but perhaps not?) 
> which would leave only the firmware only and firmware + kernel variants. What 
> do other people think about this?

I generally agree with what you are saying. I know that x86 includes
seabios (although I'm not sure how) and maybe that is something we can
look at. There is now a default RISC-V firmware which would be useful
to include so that users can just boot their kernel. We would have to
make sure it's possible to overwrite this default one so that people
can test their own.

The hard part becomes building the firmware as we don't expect people
to have a RISC-V toolchain installed.

I think the best bet here is to look at what x86 does for their BIOS
and we can start to move towards that.

Alistair

>
> Jonathan
>
> On Mon, May 20, 2019 at 12:56 PM Alistair Francis <address@hidden> wrote:
>>
>> On Sat, May 18, 2019 at 2:57 PM Jonathan Behrens <address@hidden> wrote:
>> >
>> > > I've never been fully convinced of this, why not just use the generic 
>> > > loader?
>> >
>> > If I understand you are proposing passing bbl (or other firmware) with the 
>> > -kernel flag, and then vmlinux (or another kernel) with the -initrd flag? 
>> > Wouldn't this result in losing the ability to pass a real init ramdisk to 
>> > Linux? It also seems to open the possibility for strange 
>> > bugs/compatibility issues later if firmware starts recognizing any 
>> > "initrd" entries in the device tree as kernel code to jump into.
>>
>> No I mean passing in OpenSBI (or some other boot loader) via the
>> -kernel option and then passing in the kernel with QEMU's generic
>> device loader. This is documented as part of the OpenSBI boot flow:
>> https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md
>>
>> The only disadvantage with that is that we don't get debug symbols
>> from the kernel, but it does mean that the boot loader in QEMU is much
>> simpler.
>>
>> >
>> > I do wonder though how compatible the current design is with providing 
>> > default firmware for riscv in the future.
>> >
>> > > This should be in a generic boot.c file and support added to all RISC-V 
>> > > boards.
>> >
>> > I can do this for v2.
>>
>> Thanks
>>
>> Alistair
>>
>> >
>> > Jonathan