qemu-devel
[Top][All Lists]
Advanced

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

Re: Deprecation of the LM32 target


From: Michael Walle
Subject: Re: Deprecation of the LM32 target
Date: Sat, 26 Dec 2020 12:50:32 +0100
User-agent: Roundcube Webmail/1.4.9

Hi,

Am 2020-12-26 10:06, schrieb John Paul Adrian Glaubitz:
Hello!

On 12/26/20 9:39 AM, Thomas Huth wrote:
the problem is not that the target CPU is old, but rather that according to the (former?) maintainer, there are no users left:

 https://www.mail-archive.com/qemu-devel@nongnu.org/msg605024.html

So it got marked as deprecated in this commit here:

 https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d84980051229fa43c96b3

Without maintainer and without users, there is no point in keeping this target, is there?

I'm not sure how you determine whether there are people using the code
or not. There
is no really user tracking in QEMU, is there?

That is correct, one cannot know if there are actually users of the
milkymist board or the lattice eval board. These are the two only
supported boards. The (or I should better say "my") main purpose to
add a qemu target for milkymist was to help the developers of the
board, e.g. to ease debugging, etc. But development has stopped
long time ago [1]. I've never seen a request to add a new board.

And the maintainer's claim that RISC-V takes over makes no sense
either.

I've meant the ecosystem around the SoC. LM32 on linux never took of,
mostly because there is no MMU (we've worked on one though). There is
no official lm32 support in linux and g++ support is broken (or never
even worked). While for RISC-V there is huge userbase building all sorts
of tooling.

There is a project called LiteX [2], some sort of toolbox to build your
own SoC, which supports the LM32 as a CPU component. But I've never seen
anyone trying to add a board to qemu.

The point of
emulators is to be able to run old and existing software. If a target had only a
justification to exist while it's commercially viable, you would have
to remove 90% of the targets in QEMU.
I mean, the whole point of an emulator is being able to run existing
code on modern hardware,
usually because the old hardware is no longer available. And as long
as the target is
functional, I don't see a point in taking away the functionality.

I'm not arguing against this. In fact, I'd also like to keep the lm32
qemu target, but I personally don't have any time for that anymore. And
I don't know if its fair to put the burdon of unmaintained boards to all
the qemu developers. There are a lot of test cases for the LM32
target, but these only cover the CPU instructions. The last time I've
looked audio was broken. So without anyone caring about the target, it
won't also be much help for the user either.

-michael

[1] https://github.com/m-labs/milkymist/commit/7d944d3dcffb5e528a44937b10123ff65a0aecbc
[2] https://github.com/enjoy-digital/litex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]