Open mithro opened 7 years ago
Current status as of 13th April.
workingset: timestamp_bits=30 max_order=13 bucket_order=0
romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
io scheduler noop registered
io scheduler cfq registered (default)
gpio-mockup: probe of gpio-mockup failed with error -22
drivers/tty/serial/uart-litex.c litex_uart_init
litex: calling uart_register_driver()
litex: calling platform_driver_register()
drivers/tty/serial/uart-litex.c litex_uart_probe
drivers/tty/serial/uart-litex.c litex_uart_assign
drivers/tty/serial/serial_core.c uart_add_one_port ttyLX
drivers/tty/serial/uart-litex.c litex_uart_config_port
drivers/tty/serial/uart-litex.c litex_uart_request_port
litex console: port=c03a5a54; port->mapbase=e0001000
drivers/tty/serial/uart-litex.c litex_uart_type
e0001000.serial: ttyLX0 at MMIO 0xe0001000 (irq = 1, base_baud = 0) is a litex_uart
drivers/tty/serial/uart-litex.c litex_uart_set_mctrl
drivers/tty/serial/uart-litex.c litex_uart_console_setup
drivers/tty/serial/uart-litex.c litex_uart_set_termios
drivers/tty/serial/uart-litex.c litex_uart_console_write
drivers/tty/serial/uart-litex.c litex_uart_console_putchar
drivers/tty/serial/uart-litex.c uart_out32
drivers/tty/serial/uart-litex.c litex_outbe32
drivers/tty/serial/uart-litex.c litex_uart_console_wait_tx
console [ttyLX0] enabled
dummy-irq: no IRQ given. Use irq=N
i2c-core: driver [at24] registered
3 ofpart partitions found on MTD device 20000000.spiflash
Creating 3 MTD partitions on "20000000.spiflash":
0x000000000000-0x000000080000 : "gateware"
0x000000080000-0x000000088000 : "bios"
0x000000088000-0x000000200000 : "firmware"
slram: not enough parameters.
i2c /dev entries driver
i2c-core: driver [i2c-slave-eeprom] registered
tty-ldisc-0
drivers/tty/serial/uart-litex.c litex_uart_startup
Freeing unused kernel memory: 920K
This architecture does not have kernel memory protection.
drivers/tty/serial/uart-litex.c litex_uart_start_tx
random: dd: uninitialized urandom read (512 bytes read)
fifo_wr_idx:1
@futaris - Once you have accepted the invite to the TimVideos organisation I can assign this task to you.
As I mentioned on IRC (on 14 April 2017),
http://www.spinics.net/lists/linux-serial/msg22724.html
Linux UARTs need to be driven by an IRQ. The current qemu-litex serial hardware doesn't generate TXFULL and RXEMPTY Interrupts.
We could hack around this using timers or something, but really the qemu hardware needs to be fixed.
CONFIG_CONSOLE_POLL is only used for kgdb and the like: https://www.kernel.org/doc/Documentation/serial/driver
For most UARTs, like the uartlite (https://www.xilinx.com/support/documentation/ip_documentation/opb_uartlite.pdf) :
If interrupts are enabled, an interrupt is generated when one of the following conditions is true:
Not sure if we are the same, as we only have TXFULL and RXEMPTY events.
https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/uart/core.py#L163
https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/uart/core.py#L176
There's a typo in the python, but they mean tx_fifo becomes non-full and rx_fifo becomes non-empty.
So as long as TX IRQ isn't active, we can TX.
And if there are any bytes in RX buffer, the RX IRQ is active.
Seems like we still might have to set up the IRQs (in linux), so that:
!TX_IRQ - means we can TX RX_IRQ - means bytes in rx_fifo
But reading the python, it seems that self.ev / Event Manager just ORs ( || ) together the two events into one IRQ?
https://github.com/m-labs/misoc/blob/master/misoc/interconnect/csr_eventmanager.py
So theoretically, no IRQ will happen, until we get a TXFULL or a RX event.
This is what I get for writing comments at night:
The last comment doesn't make sense. It should be:
So as long as TX IRQ isn't active, we can TX.
And if there are any bytes in RX buffer, the RX IRQ is active.
Seems like we still might have to set up the IRQs (in linux), so that:
TX_IRQ - means we can TX RX_IRQ - means bytes in rx_fifo
But reading the python, it seems that self.ev / Event Manager just ORs ( || ) together the two events into one IRQ?
https://github.com/m-labs/misoc/blob/master/misoc/interconnect/csr_eventmanager.py
So theoretically, an IRQ will always happen, until the TX FIFO is full and RX FIFO is empty.
Having the TX IRQ trigger off non full tx_fifo just means that we can't stuff as many bytes into the FIFO.
A really hacked up version has now been committed!
0x000000088000-0x000000200000 : "firmware"
spi_gpio spi: registered child spi32766.0
i2c /dev entries driver
i2c-core: driver [i2c-slave-eeprom] registered
tty-ldisc-0
drivers/tty/serial/uart-litex.c requested irq 2
drivers/tty/serial/uart-litex.c ret 0
drivers/tty/serial/uart-litex.c TXFULL 0
drivers/tty/serial/uart-litex.c RXEMPTY 1
drivers/tty/serial/uart-litex.c EV_STATUS 2
drivers/tty/serial/uart-litex.c EV_PENDING 0
drivers/tty/serial/uart-litex.c EV_ENABLE 0
drivers/tty/serial/uart-litex.c enabling EV
Freeing unused kernel memory: 920K
This architecture does not have kernel memory protection.
Starting logging: OK
Initializing random number generator... random: dd: uninitialized urandom read (512 bytes read)
done.
Starting network: ip: socket: Function not implemented
ip: socket: Function not implemented
FAIL
drivers/tty/serial/uart-litex.c litex_uart_tx_empty
Welcome to Buildroot
buildroot login: root
Jan 1 00:00:26 login[70]: root login on 'console'
# help
Built-in commands:
------------------
. : [ [[ alias bg break cd chdir command continue echo eval exec
exit export false fg getopts hash help history jobs kill let
local printf pwd read readonly return set shift source test times
trap true type ulimit umask unalias unset wait
#
:+1:
It's a simple MMIO FIFO object.