According with comment in
rtems_cache_invalidate_multiple_instruction_lines(), final_address
indicates the last address which needs to be invalidated. But if in
while loop we got final_address == i_addr condition then loop breaks and
final_address will not be invalidated.
Problem:
The console works fine when only transmitting data from the ERC32, but stops
working after a while when receiving data.
"Stops working" means, bytes are neither sent nor received from the UART, but
the rest of the system keeps functioning (task are executing, the operative
system is responsive, etc).
Context:
- When an RX error occurs, the ERC32 UARTS stop generating RX/TX interrupts
until the corresponding error flag in the UART_STATUS are cleared.
- The console.c code currently cleans the error flags from the console_isr_x
subroutines, but those are NOT called when an RX error occurs. Thus the error
flag is never cleaned and then the UARTs stop generating interrupts
indefinitely.
- The ERC32 UARTs generate a different interrupt when an RX error occurs.
Fixed by:
- Adding a third interrupt service routine console_isr_error to handle the
UART_ERROR trap. This isr cleans the error flags of the channels.
- Cleaning the error flags manually just after having initialized the interrupt
vectors. This is because if the error flag was already set by the time the
interrupt vectors are configured, the interrupts might never be called.
The readv() and writev() support was implemented in terms of multiple
calls to the read and write handlers. This imposes a problem on device
files which use an IO vector as single request entity. For example a
low-level network device (e.g. BPF(4)) may use an IO vector to create
one frame from multiple protocol layers each with its own IO vector
entry.
This allows an application to provide a localised clock freq with
needing to go down the BSP opts path. This is important with the
Zynq where the Xilinx tools generate the frequency.
