Re: Does a netinst iso image exist for qemu RISC-V ?
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
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Reply to: