Re: Does a netinst iso image exist for qemu RISC-V ?
> On Aug 7, 2018, at 3:55 PM, Paul van der Vlis <paul@vandervlis.nl> wrote:
>
> Hi Karsten and others,
>
> Op 07-08-18 om 21:00 schreef Karsten Merker:
>> unfortunately we are not yet there on the kernel side. The
>> kernel package for now only builds linux-libc-dev (which is
>> necessary to build glibc), but no kernel image. The reason for
>> that is that the upstream kernel still lacks a number of drivers
>> that are necessary for booting a usable system, in particular the
>> clocksource and the PLIC (interrupt controller) drivers. There
>> have been rather longish discussions on LKML about the proper
>> design for those and it is still open whether they will make it
>> into the kernel 4.19 merge window. Keep your fingers crossed...
>>
>>> If anyone is interested working on this, I can help. I have d-i commit
>>> access and I have done d-i work before.
>>
>> Many thanks for the offer! I'm a d-i contributor as well and
>> adding d-i support is a top priority on my todo list, but
>> starting with that only makes sense when we have a working
>> upstream kernel.
>
> Or a good patch, to get it working for the time being?
>
>> Regarding bootloaders: currently BBL is the only available
>> bootloader, and BBL is "special" in that it cannot chainload a
>> kernel. The "normal" way of building BBL is linking the kernel
>> as an ELF object into BBL, which makes things rather complicated.
>>
>> The current qemu-riscv development version as well as the current
>> BBL head have gained a feature that solves this problem to a
>> certain extent for the case of booting in qemu: qemu can preload
>> separate BBL and kernel images and pass the appropriate memory
>> location information in the device-tree, which enables BBL to
>> find the necessary bits in memory and boot the kernel.
>> Unfortunately this feature hasn't yet made it into upstream qemu
>> and as qemu is now in deep freeze for the 3.0 release, it is
>> unlikely that it will make it into qemu 3.0.
>>
>> I have a built a preliminary BBL package for use with qemu, but
>> uploading that only makes sense when we have the corresponding
>> qemu support in the archive. The BBL package isn't public yet; I
>> have discussed a number of licensing questions with upstream and
>> while I think that all potentially problematic points have been
>> cleared up, I need to find a bit of free time for finishing the
>> licensing review and for a bit of package polishing :-).
>
> Wouldn't this be a work-arround specific for Qemu? Not sure that is the
> way to go.
>
>> A u-boot port for RISC-V is work-in-progress (mainly by
>> developers from Andes), but AFAIK for now it only supports
>> booting on the Andes RV32 platforms, but not in qemu or on the
>> HiFive Unleashed board. AFAIK the u-boot port also still lacks a
>> resident SBI implementation, i.e. for the time being it relies
>> on BBL to provide the SBI.
>
> And what's the situation with coreboot?
>
> Coreboot works in Qemu, it can also boot the HiFive Unleased (and it can
> take U-boot as payload, not sure that's interesting).
>
> https://www.phoronix.com/scan.php?page=news_item&px=Coreboot-4.8-Released
> https://www.phoronix.com/scan.php?page=news_item&px=Coreboot-U-Boot-Payload
>
> Bye,
> Paul
As far as I know, Coreboot would only work on the HiFive Unleashed if it was
loaded by the ‘FSBL’ (first-stage bootloader). It should be possible “real soon now”
(famous last words) to get the FSBL code recompiled and/or included into things
like Coreboot and U-boot, and once that happens it gets a lot easier to be able to
build a functional netinst image.
Reply to: