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 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. [1]: https://lore.barebox.org/barebox/707e7c50-aad1-4459-8796-0cc54bab3...@pengutronix.de/T/#m5da26e8a799033301489a938b5d5667b81cef6ad --- v1 -> RESEND: - expand addressees beyond apparently defunct openr...@lists.librecores.org NOTE: I am not familiar with QEMU internals, so please let me know if registration in inverse order served a particular purpose. --- hw/openrisc/openrisc_sim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c index bffd6f721f7b..d147b00e4817 100644 --- a/hw/openrisc/openrisc_sim.c +++ b/hw/openrisc/openrisc_sim.c @@ -265,7 +265,7 @@ static void openrisc_sim_serial_init(Or1ksimState *state, hwaddr base, serial_irq = get_cpu_irq(cpus, 0, irq_pin); } serial_mm_init(get_system_memory(), base, 0, serial_irq, 115200, - serial_hd(OR1KSIM_UART_COUNT - uart_idx - 1), + serial_hd(uart_idx), DEVICE_NATIVE_ENDIAN); /* Add device tree node for serial. */ -- 2.39.2
