On Sunday, 21 May 2023 21:28:40 CEST Adam Lackorzynski wrote: > Hi Paul, > > On Sat May 20, 2023 at 00:35:37 +0200, Paul Boddie wrote: > > > > 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. > > Thanks, we've changed this. > > > (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.) > > Frank did work in this area recently to move this closer together.
One thing that did not seem to work as expected was the propagation of the UART information to the kernel, and for some time I wondered if the structure set up in the bootstrap module was not getting read correctly by the kernel, perhaps due to inscrutable caching issues, or that the address set in the structure was not being translated correctly in the kernel. In the startup function, we see this: lko->uart = kuart; lko->flags |= kuart_flags; The lko pointer refers to the kernel options, of course, so one would expect that the kernel picks up all these options. However, looking at the platform code, the UART is initialised separately for the bootstrap code: static L4::Uart_16550 _uart(kuart.base_baud, 0, 0, 0, 0x10 /* FCR UME */); Obviously, I now know what "FCR UME" is supposed to mean. FCR (FIFO control register) is reset in the kernel, which caused the UART to be disabled again. So, maybe more of the settings need to be transferred. > > 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've also queued a change to disable ERL. Not sure on the other issue > yet. A long time ago, we discussed rdhwr and I think it was suggested that the place for supporting some of the functionality could be outside the kernel, with the kernel invoking a user space handler, although at the time I didn't see how that would be possible given that it is used in these two ways: 1. To provide cache size information (SYNCI_Step) for the synci instruction. 2. To provide access to the ULR register which offers thread-local storage. SYNCI_Step is read from a privileged register, but since it is constant, I imagine that it could be stored somewhere and retrieved by a user space handler. ULR appears to be cached in the thread context structure, if I remember and interpret the exception handler correctly. I think this code was largely in place when I first investigated it, so it does not seem as familiar to me. I hope this is helpful, anyway. Paul _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
