On Fri, Aug 23, 2024 at 09:23:23AM +0200, Ahmad Fatoum wrote:
> Hello Stafford,
>
> On 23.08.24 08:28, Stafford Horne wrote:
> > Note the distribution list you use here: openr...@lists.librecores.org
> > Is old and we should use linux-openr...@vger.kernel.org. I will get the
> > qemu
> > maintainer file updated.
>
> So this list is appropriate for all openrisc-related development and not only
> for the kernel?
>
> > On Thu, Aug 22, 2024 at 06:38:38PM +0200, Ahmad Fatoum wrote:
> >> We used to only have a single UART on the platform and it was located at
> >> address 0x90000000. When the number of UARTs was increased to 4, the
> >> first UART remained at its location, but instead of being the first one
> >> to be registered, it became the last.
> >>
> >> This caused QEMU to pick 0x90000300 as the default UART, which broke
> >> software that hardcoded the address of 0x90000000 and expected its
> >> output to be visible when the user configured only a single console.
> >
> > This makes sense but what do you mean here by DEFAULT uart? I guess you
> > mean
> > the one connected to qemu's stdout by default?
>
> Yes. I am not keen on the QEMU terminology, but the first registered UART
> seems
> to have a special place. Besides being connected to QEMU's stdio by default,
> it's also used to populate /chosen/stdout-path as can be seen when dumping
> the dtb:
>
> qemu-system-or1k -kernel /dev/null -machine or1k-sim,dumpdtb=qemu.dtb
> -nographic
>
>
> >> This caused regressions[1] in the barebox test suite when updating to a
> >> newer QEMU. As there seems to be no good reason to register the UARTs in
> >> inverse order, let's register them by ascending address, so existing
> >> software can remain oblivious to the additional UART ports.
> >
> > This sounds good to me. I will test this out and queue to qemu after the
> > small
> > clarification above.
> >
> > Also, I will wait to see if Jason has anything to say.
>
> Sure.
>
> By the way, I botched the RESEND and forgot following two lines:
>
> Fixes: 777784bda468 ("hw/openrisc: support 4 serial ports in or1ksim")
> Signed-off-by: Ahmad Fatoum <a.fat...@pengutronix.de>
>
> Let me know if I should resend (provided there's no code changes warranting a
> v2).
>
This should be fine thanks. I will fixup the commit message and repost after a
bit of testing to ensure this does not affect other environments including
Jason's test suite which uses the 4 UARTs.
-Stafford
