On Tue, 27 Aug 2024 at 19:53, Stafford Horne <sho...@gmail.com> wrote: > > On Sun, Aug 25, 2024 at 03:09:20PM +0100, Peter Maydell wrote: > > On Sun, 25 Aug 2024 at 12:35, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > > > > > On Fri, Aug 23, 2024 at 07:28:43AM +0100, Stafford Horne wrote: > > > > Also, I will wait to see if Jason has anything to say. > > > > > > So long as this doesn't change the assignment of the serial ports to > > > device nodes in Linux, I don't think this should interfere with much. > > > You might want to try it, though. > > > > It looks like this board already creates the fdt /aliases/ > > node and puts uart0, uart1, etc, so that part should be OK. > > > > However I notice that the openrisc_sim_serial_init() code > > will always set the /chosen/stdout-path, so this means > > (unless I'm misreading the code -- I haven't tested) that > > the last UART we create will be the stdout-path one. Before > > this patch, that would be serial_hd(0), but after this it > > will not be. So I think we probably need to fix this too > > in the same patch, so that we only set stdout-path for uart0, > > rather than setting it and then overwriting it on all the > > subsequent calls. This patch on its own will change the > > stdout-path value I think. > > Hi Peter, > > I suspected the same and tested the theory. Now when running linux with > or1k-sim machine we get no stdout output from qemu. Upon debugging and > looking at dmesg via gdb I can see the wrong uart is getting setup in > Linux: > > [ 0.080000] workingset: timestamp_bits=30 max_order=17 bucket_order=0 > [ 0.100000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled > [ 0.110000] printk: legacy console [ttyS0] disabled > [ 0.110000] 90000300.serial: ttyS0 at MMIO 0x90000300 (irq = 2, > base_baud = 1250000) is a 16550A > [ 0.120000] printk: legacy console [ttyS0] enabled > [ 0.120000] 90000200.serial: ttyS1 at MMIO 0x90000200 (irq = 2, > base_baud = 1250000) is a 16550A > [ 0.130000] 90000100.serial: ttyS2 at MMIO 0x90000100 (irq = 2, > base_baud = 1250000) is a 16550A > [ 0.130000] 90000000.serial: ttyS3 at MMIO 0x90000000 (irq = 2, > base_baud = 1250000) is a 16550A > [ 0.150000] NET: Registered PF_PACKET protocol family > [ 0.160000] clk: Disabling unused clocks
Interesting, that seems to have assigned ttyS0/1/2/3 in the reverse order, which suggests it might be ignoring the /aliases/ nodes entirely? Though that would surprise me, so perhaps something else is going on. For the Arm virt board we ended up taking a conservative approach of making sure the UARTs were listed in the dtb in the exact same order we'd traditionally done it, for the benefit of any guests which didn't honour /aliases/ or /chosen/stdout-path. But we were thinking more about that being old firmware rather than the kernel. -- PMM
