On 07/12/2018 11.26, Jassi Brar wrote:
I thought that I could also mitigate 2) by busy looping in the TCU driver,
but it turns out that that doesn't work. The reason is that since we are
in atomic context with all interrupts disabled, the mailbox won't ever
consume any new characters, so the read pointer in the circular buffer
won't increment, leaving me with no condition upon which to loop that
would work.
So you want to be able to rely on an emulated console (running on a
totally different subsystem) to dump development-phase early-boot
logs? At the cost of legitimizing busy looping in atomic context - one
random driver messing up the api for ever. Maybe you could have the
ring buffer in some shmem and only pass the number of valid characters
in it, to the remote?
I would like to note that this is the one and only console interface
that exists on these systems, for both development phase and production.
Other UARTs are not externally accessible on the systems, or they are
comparatively difficult to access as they aren't intended to be used as
consoles in the system design. The combination of hardware and firmware
implementing the console is black box from software's point of view
(similarly to any other UART HW). The interface has also been fixed at
an early system design phase, as there are many operating systems
running on these boards, each with their own drivers.
Cheers,
Mikko
