Right. The kernel code and the device model are fine, with the possible
exception that the device signals that it's empty immediately with the
LSR register. There's some sort of bug in my instruction
implementations, I think, which is garbling the data between the two.
I'm working through an in
But that driver works fine for Alpha/Linux and it should be the same
driver.
Ali
On Apr 20, 2008, at 7:09 PM, Gabe Black wrote:
I think I at least figured out what's going on. The console isn't
using interrupts from the UART to determine when to send the next
character. It's polling the LS
I think I at least figured out what's going on. The console isn't using
interrupts from the UART to determine when to send the next character.
It's polling the LSR register which is hardwired (in M5) to always say
the UART is ready to go. What's actually happening, I think, is that
when message
>I've been digging and digging and digging and digging, and I think I'm
> getting closer to an answer. What I'm trying to figure out now is if output
> to the console is handled by a dedicated thread, or if it happens inline
> with printk. It looks like printk puts stuff in a buffer and then th
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o
