[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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).



Paul van der Vlis Linux systeembeheer Groningen

Reply to: