Re: L4Re: Boot module copying and the MIPS Creator CI20

On Friday, 19 May 2023 19:03:36 CEST Paul Boddie wrote:
> 
> I suppose, then, the conclusion is that the CI20 UART code got inadvertently
> broken when that functionality was reworked. Whether the UART
> initialisation should be suppressed or whether the UART can be cleanly
> reinitialised is something to investigate further, I imagine.

Of course I have to follow up to this! The fixes required here involve 
adjusting the src/kern/mips/bsp/ci20/Modules file to use the following 
definitions:

OBJECTS_LIBUART       += uart_16550.o
CXXFLAGS_uart-libuart += $(call LIBUART_UART, 16550) \
                         -DUART_16550_INIT_FCR=0x10

If the INIT_FCR setting is not used, the initialisation code clears the 
trigger level field (defined in the 16550 data sheet) and also the UART enable 
field (defined in the JZ4780 programming manual, reserved in the 16550 data 
sheet), disabling the UART.

For the above value, I merely reproduced the UART enable bit (0x10) set by the 
Uart_16550 initialisation in the bootstrap code. The trigger level field can 
be read, yielding a value of 0xc0 which corresponds to (3 << 6) or a level of 
60 according to the JZ4780 manual, but the field is documented as being write-
only, so maybe reading it doesn't make sense. Allowing that field to be 
cleared does not appear to be harmful.

(I see that the drivers-frst code strongly resembles the library code in the 
kernel but is slightly older, and I wonder about whether these things could 
eventually be integrated in a sensible way.)

Alongside these changes, the CI20 still needs instruction emulation for rdhwr, 
since this instruction is still used by various libraries, even though the 
bootstrap code avoids it. Meanwhile, I still find that the bootstrap crt0.S 
file needs patching to fix the memory mapping and to not run with the ERL flag 
set. Fixing the UART handling in the kernel does not make that issue 
disappear.

I hope this was informative, at least.

Paul