LiteX internal bus architecture (was Re: patches)

[Tim Ansell]

I only got a few minutes to look at your patches today. They all seem to have the same simplebus changes in them? Am I suppose to be using just one of them, or? Maybe pushing to GitHub would make it easier to see what is going on.

Do you have a github username? If so I'll add you to the repo at https://github.com/timvideos/linux-litex and assign the UART github issue to you.

Regarding the bus, pretty much everything in LiteX is memory mapped IO. The SoC has two busses inside it, a wishbone and CSR. 

 * The wishbone bus is 32bits wide that both CPU's instruction and data interfaces are connected to (Von Neumann arch). 

    - The wishbone bus looks like memory from the CPU's point of view, things on it are accessed via load/store operations (through the MMU).

    - The CPU is not the only master on the wishbone bus, other things like DMA engines can also access this bus but *don't* go through the MMU and are totally transparent to the CPU (except sometimes making load/store operations appear to stall for a while). 

    - The bus can only be accessed on 32bit boundaries (is that a word?), I'm unclear if the CPU "fixes up" unaligned accesses?

 * The CSR bus is bridge into the wishbone bus with a 1:1 mapping. 

    - All the control registers for peripherals in the LiteX universe are attached to the CSR bus.

    - Every CSR "word" takes up one aligned 32bit address location in the wishbone space. However, the CSR word size is normally only 8bits, so you end up with 8bits in CSR space taking up 32bits in wishbone space.

    - CSR registers can be wider than a single word but are "rounded up" to the next full word size.

      For example;

      * A 1 bit CSR register would take up one word in CSR space (8bits) and one word in wishbone space (32bits). 

      * A 9 bit CSR register would take up two words in CSR space (16bits) and one word in wishbone space (64bits). 

    - CSRs can be an arbitrary number of bits in size which are mapped to words. A 9bit CSR register would take up two 32bit words in the wishbone space. This is why you get weird things like this.

    - Generally CSR registers are write or read. The FIFO in the UART is bit of a legacy thing and these days would be two separate CSR registers.

    - IRQs are handled via a thing called "Event Manger" which provides a couple of CSR registers for determining their current state, if they have fired since last been cleared and ability to clear the fired state.

 * Sometimes we might have a non-LiteX peripheral on the wishbone bus. No guarantees about how that would work but it would still be accessed from the CPU via load/stores.

If we are required to have a bus, then simplebus makes a lot of sense. It is unclear to me if there is an advantage to Linux knowing about our internal CSR bus? I guess it could be useful to let us configure the CSR word size?

I created a mailing list for the project at https://groups.google.com/forum/#!forum/linux-litex

Tim 'mithro' Ansell

On 11 April 2017 at 20:22, Hasjim Williams <hasjim....@futaris.org> wrote:

Some more patches attached.

The 0015 ones I was trying to debug simplebus / CONFIG_OF. Trying to move the serial port and network port onto a simplebus (for or1ksim). Once I got it working on or1ksim.

0005 has the core code for litex-uart.c. Haven't fixed it for our 0xe0001000 yet.  Shouldn't need to use any of the FIFO flags (like overflow / empty) on QEMU builds, at least.

0005 has a bunch of printk_once(INFO) for my debugging.

Most arm dtbs have everything on a amba bus, which does a little bit more. simplebus is basically a MMIO bus.  Should be fine for our purposes.  The more complicated stuff is on wishbone, isn't it?

If the dtb is setup correctly, then everything should probe fine without cmdline.

On Tue, Apr 11, 2017, at 09:30 AM, Tim Ansell wrote:

Should be committed now.

Tim 'mithro' Ansell

On 10 Apr. 2017 9:33 pm, "Hasjim Williams" <hasjim....@futaris.org> wrote:

Can you e-mail the .config that you used with this kernel?

On Mon, Apr 10, 2017, at 11:54 AM, Tim Ansell wrote:

I updated your patches to support earlycon and was able to see the code executing correctly. I then discovered a bug in page table handling which was preventing the register writes going to the right physical address location. I don't think this would be affecting the stock or1ksim and your setup however.

As earlycon is polled and not interrupt based I haven't had a chance to test if there is something weird going on there. It would be good to get you going with earlycon stuff. You need to add an "earlycon=litex,<address>" replacing the "console=" line in the device tree. Then connect with gdb and put a breakpoint on the earlycon code and the step through. To make sure it ends up writing to the correct address.

Looking at the uart code, you definitely picked the wrong uart example to use as a base. There is a whole lot of stuff here which just makes things a bit messy / hard to follow. The 

uartlite driver is much closer to our device. See 

https://github.com/mithro/HDMI2USB-misoc-linux/blob/master/drivers/tty/serial/uartlite.c

(That is the driver I stole the earlycon code from.)

Could you look at redoing your driver based on the above one? I'll try and push some more updates later today with my earlycon stuff.

Tim 'mithro' Ansell

[Hasjim Williams]

Ok, So I made some changes to buildroot, to support building v4.11-rc5 kernel for or1k (which are attached).

Buildroot .config is attached.

I got lazy and just told buildroot, to use a patch against v4.11-rc5, which is generated by mkdiff.sh.

Still need to modify the litex-uart driver.

I pulled the linux-hacks branch of qemu-litex and noticed that the -kernel stuff still Resets PC to: 0x40000100.

With openrisc_sim / or1ksim , I was using this command line:

~/HDMI2USB-litex-firmware/build/opsis_base_or1k/qemu/or32-softmmu/qemu-system-or32 -kernel output/images/vmlinux -nographic

-M openrisc_sim is the default, for or32-softmmu I think.

Is there a script to build the flash-or1k.qcow2 somewhere?

I guess for litex something like the below should work:

~/HDMI2USB-litex-firmware/build/opsis_base_or1k/qemu/or32-softmmu/qemu-system-or32 -M litex -drive if=mtd,format=qcow2,file=build/flash-or1k.qcow2,serial=n25q16 -nographic

I wonder if I still need the other 0001 0002 patches (from or1ksim), since I think the gcc, binutils etc in buildroot aren't the latest.

What gcc, binutils etc did you use to build your or1k litex kernel Tim?

--

You received this message because you are subscribed to the Google Groups "linux-litex" group.

To unsubscribe from this group and stop receiving emails from it, send an email to linux-litex...@googlegroups.com.

To post to this group, send email to linux...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-litex/CAHLUNMy9J1MSq4PJ3vEDeJ2CTqrziVSe5X%2B9Heuz9BM2OJxUuA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Tim Ansell]

On 13 April 2017 at 22:20, Hasjim Williams <hasjim....@futaris.org> wrote:

Ok, So I made some changes to buildroot, to support building v4.11-rc5 kernel for or1k (which are attached).

Buildroot .config is attached.

Should we fork a buildroot repo into the TimVideos org?

 

I got lazy and just told buildroot, to use a patch against v4.11-rc5, which is generated by mkdiff.sh.

Still need to modify the litex-uart driver.

I pulled the linux-hacks branch of qemu-litex and noticed that the -kernel stuff still Resets PC to: 0x40000100.

The vmlinux file starts with the reset vector. 0x100 is the reset position of the vector.

I've been loading the kernel with or1k-elf-gdb

Start qemu with;

build/or32-softmmu/qemu-system-or32 -nographic -nodefaults \

  -serial stdio \

  -M litex \

  -drive if=mtd,format=qcow2,file=build/flash-or1k.qcow2,serial=n25q16 \

  -s -S \

  -d guest_errors \

  -monitor telnet:127.0.0.1:1235,server,nowait

I then have a .gdbinit with 

target remote :1234

load vmlinux 0x40000000

add-symbol-file vmlinux 0x40000000

add-symbol-file vmlinux 0xc0000000

source <path to>/vmlinux-gdb.py

jump *0x40000100

You might want to put breakpoints before the jump line if you want to stop somewhere.

With openrisc_sim / or1ksim , I was using this command line:

~/HDMI2USB-litex-firmware/build/opsis_base_or1k/qemu/or32-softmmu/qemu-system-or32 -kernel output/images/vmlinux -nographic 

-M openrisc_sim is the default, for or32-softmmu I think.

Upstream qemu has changed or32 to or1k I believe. I will try and rebase our litex stuff onto upstream qemu this weekend.

 

Is there a script to build the flash-or1k.qcow2 somewhere?

The build-litex-qemu.sh script has a command to convert a .bin file for flashing into a qemu qcow2 format; see https://github.com/timvideos/qemu-litex/blob/master/build-litex-qemu.sh#L73-L78

To create a .bin file you need the mkimage.py script which needs to run in the HDMI2USB-litex-firmware environment (you can see the script here -> https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/mkimage.py). The scripts/build-qemu.sh script in that repo does the following to create a .bin file;

/usr/bin/env python mkimage.py --output-file=qemu.bin --override-gateware=none --force-image-size=true

$TARGET_QEMU_BUILD_DIR/qemu-img convert -f raw $TARGET_BUILD_DIR/qemu.bin -O qcow2 -S 16M $TARGET_BUILD_DIR/qemu.qcow2

You can probably use --override-firmware with the kernel file to replace the HDMI2USB

 

I guess for litex something like the below should work:

~/HDMI2USB-litex-firmware/build/opsis_base_or1k/qemu/or32-softmmu/qemu-system-or32 -M litex -drive if=mtd,format=qcow2,file=build/flash-or1k.qcow2,serial=n25q16 -nographic

See what I'm doing above.

 

I wonder if I still need the other 0001 0002 patches (from or1ksim), since I think the gcc, binutils etc in buildroot aren't the latest.

Which patches? Are these in buildroot?

 

What gcc, binutils etc did you use to build your or1k litex kernel Tim?

I'm using binutils + gcc + gdb from the HDMI2USB conda repository. You can find the metadata about that here -> https://github.com/timvideos/conda-hdmi2usb-packages/tree/master/or1k

The versions are;

 * binutils - 2.28.0 (upstream)

 * gcc - 5.4.0 (or1k fork)

 * gcc+newlib - 5.4.0 + 2.4.0 (upstream)

 * gdb - 7.11 (or1k fork)

Tim 'mithro' Ansell