search

CHERIoT-Platform / cheriot-rtos

The RTOS components for the CHERIoT research platform
MIT License
128 stars 44 forks source link

stdio/stderr UART initialization #317

Open GregAC opened 1 week ago

GregAC commented 1 week ago

I just ran into a hang running the test suite on Sonata with reduced UART FIFO sizes (we're moving to small FIFOs to save on FPGA resources). The core issue was a write to stderr which goes to uart1 if it exists (which it does on Sonata).

https://github.com/CHERIoT-Platform/cheriot-rtos/blob/b6875ba4ead8a361aa7e4edb0fbf5f496b21c1a3/sdk/include/stdio.h#L33-L37

The problem is uart1 never get initialised so our small transmit FIFO fills up and the test hangs. stdout goes to uart or uart0 which gets initialised in the loader:

https://github.com/CHERIoT-Platform/cheriot-rtos/blob/b6875ba4ead8a361aa7e4edb0fbf5f496b21c1a3/sdk/core/loader/boot.cc#L1048-L1055

But there's no initialisation for uart1.

Clearly I can just initialize uart1 in the same place but is that the most appropriate place for it? In particular that's aiming to initialise the UART used for debug logs which has the happy side effect of initialising the UART used for stdout as they're the same UART. So mixing in initialisation for stdio specific things doesn't clearly fit there.

We may want stdout and stderr to both go to uart on Sonata anyway so I can sidestep the problem that way but nevertheless there should be some defined stdio or UART init this can all be properly handled in.

davidchisnall commented 1 week ago

This is closely related to #275

I would like to add a device-initialisation phase that can run on the scheduler's stack before we start the scheduler. This is the right place to do UART initialisation and would also be a good place to configure the revoker. The allocator should be able to have a capability that excludes the registers that configure the revokable range of memory and have early initialisation code set this.