[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RESEND] hw/openrisc/openrisc_sim: keep serial@90000000 as def
From: |
Ahmad Fatoum |
Subject: |
Re: [PATCH RESEND] hw/openrisc/openrisc_sim: keep serial@90000000 as default |
Date: |
Fri, 23 Aug 2024 09:23:23 +0200 |
User-agent: |
Mozilla Thunderbird |
Hello Stafford,
On 23.08.24 08:28, Stafford Horne wrote:
> Note the distribution list you use here: openrisc@lists.librecores.org
> Is old and we should use linux-openrisc@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.fatoum@pengutronix.de>
Let me know if I should resend (provided there's no code changes warranting a
v2).
Thanks,
Ahmad
>
> -Stafford
>
>> [1]:
>> https://lore.barebox.org/barebox/707e7c50-aad1-4459-8796-0cc54bab32e2@pengutronix.de/T/#m5da26e8a799033301489a938b5d5667b81cef6ad
>> ---
>> v1 -> RESEND:
>> - expand addressees beyond apparently defunct openrisc@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
>>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |