On Thu, Nov 21, 2024 at 04:32:25PM -0600, Rob Landley wrote:
> On 9/16/24 02:21, Stafford Horne wrote:
> > On Wed, Sep 11, 2024 at 12:42:58AM -0500, Rob Landley wrote:
> > > Grab this tarball, extract it, and ./run-qemu.sh. It's a simple
> > > linux+initramfs image that boots to a shell prompt.
> > > 
> > >    https://landley.net/bin/mkroot/latest/or1k.tgz
> > > 
> > > QEMU 7.0.0 ran that linux-or1k image, but newer qemu does not. I besected 
> > > the
> > > issue to qemu commit 0a923be2f642, and it's still broken in current tip 
> > > of tree.
> > 
> > Patch is:
> > 
> >   0a923be2f6 ("hw/openrisc: page-align FDT address")
> > 
> > > Rebuilding the image with current linux-git doesn't seem to make a 
> > > difference?
> > > Either way I get serial output with old qemu and don't with current qemu.
> > 
> > The bisect looks strange as it's only moving a page boundary, it could be
> > correct but it seems harmeless.  There is another commit close by that was
> > causing issues with serial output for the barebox guys and this is a patch 
> > I am
> > working on to fix it.
> > 
> > https://lore.kernel.org/qemu-devel/20240908062756.70514-1-sho...@gmail.com/
> > 
> > I will try to get time today to look at your tarball and run it, but if not 
> > have
> > a look at this patch.
> 
> I just regression tested linux-6.12 against qemu-9.2.0-rc1 and I'm still
> getting no output from or1k, with the current image or the old or1k release
> image that worked under old qemu versions.
> 
> I tried applying your serial patch to current qemu, and it made no
> difference: still no output booting the image.

OK, I am trying to get that patch pushed upstream.  I will be sure we fix your
issues before we do that.

> Alas I can no longer test that reverting the commit I identified (git show
> $HASH | patch -p1 -r) makes it work again in current qemu (although it did
> at one point, that's a standard sanity check at the end of bisect for me),
> and I can't fix it up by hand either because hw/openrisc/openrisc_sim.c no
> longer contains the string "load_sim", looks like it got collated with
> common code for other architectures.
> 
> I'm happy to tweak the kernel config if qemu changed in a way that broke
> compatibility with old images (I assume _you_ have a kernel that boots), but
> I was hoping "this week's kernel release" would have any necessary patches
> to work with QEMU's changed ABI.

The patch I have put in 6.12 only helps with earlycon.  Regular output has
always been working for me.  I will work on testing your image again to see what
is special about it.

Note, I did find some issues with the kernel nor properly handling stdout-path.
It seems that if there are multiple uarts the first one will always be used as
the default uart.  Only the console= command line argument can be used to
override that.

So as long as the kernel selects the first uart as the stdout path (it should
have always been the case)  AND qemu picks the first uart as the uart connected
to the console (it should be with my latest patch) we should get serial output.

Another thing that may get me delayed is that I need to rebuild my or1k-elf-gdb
as it's python version is no longer compatible with the kernel's python.

-Stafford

Reply via email to