Re: Does a netinst iso image exist for qemu RISC-V ?
On Tue, Aug 07, 2018 at 03:58:17PM +0200, John Paul Adrian Glaubitz wrote:
> On 08/07/2018 03:51 PM, Dennis Clarke wrote:
> > Given that there is no such thing as a "standard" platform for RISC-V
> > then it isn't really reasonable to worry about this. Yet. There is a
> > lot of talk about RISC-V and only a few companies have begun to really
> > fabricate some hobby type boards. The sifive folks are one of them and
> > their hardware seems to be all that exists. However it is arduino type
> > stuff or maybe "test" level type of hardware. So it may be another year
> > or more before an actual defacto common motherboard exists.
>
> Well, we could add support to debian-installer for the board type that
> is emulated by qemu-riscv-system. Since src:linux builds fine on riscv64,
> one of the most important pieces for d-i support is already in place.
Hello,
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.
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 :-).
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.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: