#timvideos

cr1901_modern1: ping?

Hi mithro. Just saw your e-mail.

Hi!

When I last did board bringup, it was on ARM using ATAGs. I'm new to devicetree.

https://git.kernel.org/pub/scm/linux/kernel/git... looks useful though.

Title: booting-without-of.txt\devicetree\Documentation - kernel/git/torvalds/linux.git - Linux kernel source tree (at git.kernel.org)

futaris: or1k is pretty tied to devicetree from what I can see

Yep. devicetree is much more modern, and I would be surprised if or1k wasn't using it.

And oops about typing lm32 in my last e-mail. I keep meaning to say or1k.

Do you have your .config for the linux kernel?

futaris: It's pretty much the defconfig for or1k

shenki just tested stock or1k with buildroot and qemu and it worked apparently

Yep. The instructions in the e-mail should just work.

I suppose we can use the same "machine type" number as the or1ksim.

CONFIG_OPENRISC_BUILTIN_DTB is building the DTB into the kernel, so we shouldn't have to worry too much...

futaris: yeah

https://git.kernel.org/pub/scm/linux/kernel/git... is the arch specific devtree stuff.

Title: prom.c\kernel\openrisc\arch - kernel/git/torvalds/linux.git - Linux kernel source tree (at git.kernel.org)

So nothing from _emergency_print: Copying Linux....

futaris: Hrm?

The first linux does is relocate the kernel in memory... "Copying Linux.............." (with a new dot each time)

Title: head.S\kernel\openrisc\arch - kernel/git/torvalds/linux.git - Linux kernel source tree (at git.kernel.org)

Is this just upstream or?

Every arch does this.

futaris: Oh, your not seeing this - your just telling me what *should* happen

https://github.com/01org/kvm-sgx/blob/master/ar... - bootargs = "console=uart,mmio,0x90000000,115200";

Title: kvm-sgx/or1ksim.dts at master · 01org/kvm-sgx · GitHub (at github.com)

Now, we don't have the uart at that mmio on mor1k / litex...

Let's ignore the bootargs first, and just get _emergency_print fixed for our UART.

futaris: okay

futaris: https://github.com/timvideos/HDMI2USB-firmware-...

Title: HDMI2USB-firmware-prebuilt/csr.h at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at github.com)

The quick way to get it working, is to just hack head.S first. _early_uart_init and emergency_print ...

So just write a char/byte to 0xe0001000 (physical) and the UART will spit it out?

Can you fix the SYS_CLK and UART_DIVISOR for litex?

Title: head.S\kernel\openrisc\arch - kernel/git/torvalds/linux.git - Linux kernel source tree (at git.kernel.org)

Actually, UART_DLL and UART_DLM don't exist on litex do they?

futaris: https://github.com/enjoy-digital/litex/blob/mas...

Title: litex/uart.c at master · enjoy-digital/litex · GitHub (at github.com)

Hmm. How do I set the baud rate of the UART with litex?

futaris: Its hard coded I think

futaris: https://github.com/enjoy-digital/litex/blob/mas...

Title: litex/core.py at master · enjoy-digital/litex · GitHub (at github.com)

Ok. So _early_uart_init can essentially be just "l.jr r9, l.nop"

This is the ASM instruction set for openrisc:

futaris: Do you need to check if the uart is full?

Title: OPENRISC Instruction Documentation (at sourceware.org)

We'll just assume we've just powered on the machine, and jumped straight into the beginning of the linux kernel after the BIOS has done the DDR init etc.

futaris: Correct

So, just rewrite ENTRY(_emergency_print) first...

So the original function in the original routine clobbers r4, r5, r6, r7. putc is l.movhi r4,hi(UART_BASE_ADD) ...

Actually, looking at your init code for uart, we probably should do the same. uart_ev_pending_write(uart_ev_pending_read()); and uart_ev_enable_write(UART_EV_TX);

We don't need irqs in early emergency_printk support. Just keep polling until we can print.

futaris: Yeah

futaris: Have you attempted to build my qemu with litex support?

Yeah, it builds.

I was just helping shenki to build it then

futaris: As part of the HDMI2USB-litex-firmware?

I think I just built from the tree.

futaris: with the ./build-qemu-litex.sh script?

I'll try that script again soon. Last time I built using the script, I only built lm32, not or1k.

Yeah - I'm pretty sure that shenki just discovered that using that script doesn't really work for or1k at the moment

I'm heading to dinner be back in an hour

The following packages will be DOWNGRADED due to dependency conflicts: python: 3.6.0-0 --> 3.5.3-1

./scripts/download-env.sh fails at openocd for me.

drivers/tty/serial/8250 is where the or1k (non litex) UART is done. CONFIG_SERIAL_8250, CONFIG_SERIAL_8250_CONSOLE. 8250_of.c gets the information from the devicetree if CONFIG_SERIAL_OF_PLATFORM is defined.

futarisWeb: sorry, I went to dinner

I'm back now

So looking at https://github.com/enjoy-digital/litex/blob/mas... the UART essentially is just doing bit banging in hardware? Is there any more documentation on the offsets etc?

Title: litex/core.py at master · enjoy-digital/litex · GitHub (at github.com)

futarisWeb: What do you mean?

futarisWeb: Are you using the web gateware as you haven't discovered IRCCloud yet?

like register offsets. Eg in an 8250, the CONTROL register, etc...

futarisWeb: None apart from the implementation and the code which uses it

Been a while since I was using IRC.

highly recommend irccloud, they even have a phone client

No free account though?

I used to use BitchX.

futarisWeb: https://www.irccloud.com/pricing

Title: Pricing | IRCCloud (at www.irccloud.com)

The major thing with the free account is that if you are inactive for more then 2 hours it disconnects you

:(

Pushed a fix for the openocd issue

futarisIRCcloud: I also hang out on #openrisc and #m-labs

What question did you have about the uart?

Prebuilt headers+bios+firmware for or1k on the Opsis/Atlys platform will be available in about an hour -> https://travis-ci.org/timvideos/HDMI2USB-litex-...

I only just saw today, that you can't change baudrate for example... I'm just looking through drivers/tty/serial trying to see the simplest uart driver, to base a new litex uart off.

You want a basic fifo style uart

Ok. xilinx uartlite references https://www.xilinx.com/support/documentation/ip... ... Nothing similar for litex uart?

futarisIRCcloud: The uart isn't even close to being that complicated

The full implementation is here -> https://github.com/enjoy-digital/litex/blob/mas...

Title: litex/core.py at master · enjoy-digital/litex · GitHub (at github.com)

futarisIRCcloud: #define GET_UART_CSR(addr) ((unsigned char)(*((uint32_t*)addr)))

futarisIRCcloud: while(true) { while(GET_UART_CSR(0xe0001004)); SET_UART_CSR(0xe0001000, 'x'); }

that would print infinite x's without overflowing the UART

Yep.

futarisIRCcloud: reading is similar

So there is no hardware flow control? I thought you had interrupts and events for TX full etc.

futarisIRCcloud: There are interrupts for the fifo getting full or empty

qemu-system-or32: -M litex: unsupported machine type

futarisIRCcloud: How did you build qemu?

Just realised third-party/qemu-litex needed a git pull.

We could probably just start of with a modern version of:

start _off_

futarisIRCcloud: You were telling me how to modify head.S?

Just need to modify _early_uart_init. It'll probably work if we remove everything, and just "l.jr r9" then "nop".

I don't quite understand all the or1k asm, but _emergency_printf should just check until it can write, putc, check that the byte was written, then do the same for the next character until it reaches the end of the string.

What is l.jr r9?

return to where this function was called from.

Oh

Well, I guess we don't really need to init the uart

Title: OPENRISC Instruction Documentation (at sourceware.org)

Technically we might want to drain the uart

For qemu, it shouldn't really matter.

_emergency_print_nr will need to be fixed up the same like _emergency_print too...

Yeah