Received-SPF: pass (google.com: domain of linux-kernel+bounces-7151-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Wed, 20 Dec 2023 16:22:24 +0100
From: Sam Ravnborg <sam@ravnborg.org>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Arnd Bergmann <arnd@kernel.org>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	"David S . Miller" <davem@davemloft.net>,
	Andreas Larsson <andreas@gaisler.com>, Helge Deller <deller@gmx.de>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org, linux-fbdev@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-sound@vger.kernel.org
Subject: Re: [PATCH 00/27] sparc32: sunset sun4m and sun4d
Message-ID: <20231220152224.GA867968@ravnborg.org>
References: <20231219-sam-sparc32-sunset-v3-v1-0-64bb44b598c5@ravnborg.org>
 <01ea8c41-88cd-4123-95c7-391640845fc3@app.fastmail.com>
 <e897e6d5a88ec2f9024c62f7bee5c13bfb2cab55.camel@physik.fu-berlin.de>
 <dbb60b13-565f-43b8-8cb8-6f8cd98b06df@app.fastmail.com>
 <3d733b57-884a-4755-a32a-74061b48e182@ilande.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3d733b57-884a-4755-a32a-74061b48e182@ilande.co.uk>

Hi Mark,

On Wed, Dec 20, 2023 at 11:30:27AM +0000, Mark Cave-Ayland wrote:
> On 20/12/2023 10:47, Arnd Bergmann wrote:
> 
> > On Wed, Dec 20, 2023, at 09:54, John Paul Adrian Glaubitz wrote:
> > > On Wed, 2023-12-20 at 08:36 +0000, Arnd Bergmann wrote:
> > > > All of these were found through inspection rather than testing,
> > > > so there is a good chance that other fatal kernel bugs prevent
> > > > testing in qemu, at least until the fixes from Andreas' tree
> > > > are included.
> > > 
> > > Andreas has fixes for these issues?
> > 
> > Not sure, all I know is that
> > 
> > - Andreas has some fixes for Leon in his tree
> > - Sam is unable to boot mainline in qemu
> > - There is an unknown set of bugs in sparc32 since it has not
> >    been tested for many years without Andreas' patches
> > 
> > it appears that the qemu developers are still testing the sun4m
> > model against old Linux and Solaris installations [1], but
> > failure to run the leon3 model could still be any combination
> > of kernel, qemu or configuration problems.
> > 
> >          Arnd
> > 
> > [1] https://wiki.qemu.org/Documentation/Platforms/SPARC#Compatibility
> 
> Hi all: I'm one of the QEMU sun4m and sun4u maintainers so thought it would
> be worth a few comments here.

I can imagine that the proposal to drop sun4m from the kernel is then
not the best news this December - sorry about that.

> 
> My SPARC work on QEMU is unsponsored, so of course it is reliant upon me
> finding time between work and family to fix various bugs. This means that I
> simply don't have the time to constantly build and test the latest kernels:
> what generally happens is that someone pings me a regression bug report when
> something breaks and provides a test kernel/rootfs for me to look at. In the
> past both Rob Landley and Guenter Roeck have often flagged regressions and
> kindly provided these for me.
> 
> Other than that I just assume that everything is still working against the
> upstream kernel.

It is a fantastic tool that we can build and boot a kernel using qemu
and your work is appreciated - thanks!

> 
> The leon3_generic machine is maintained by different people so I'd suggest
> contacting them: see [1] for their contact details. I see there is an
> avocado boot test for the leon3_generic machine included within the QEMU
> source tree, but it uses a downloadable image of HelenOS rather than Linux.

Thanks for the pointer, I will try to reach out to them when I have
something a bit more solid than "it does not work".

I tried to hack around a little in qemu and I have an idea where things
goes wrong. The leon_generic assumes another address layout than what is
used by the kernel, so the very first jump to a kernel address fails.

	Sam