babbleberry / rpi4-osdev

Tutorial: Writing a "bare metal" operating system for Raspberry Pi 4

Home Page:https://www.rpi4os.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Question: USB Support

suityou01 opened this issue · comments

In your excellent tutorials you mention you pursued BLE as USB was much more difficult. Could you sketch out the steps, as you see it, even if from a high level, on how to go about adding USB support to this Kernel?

I note you added the HCD file from the bluetooth firmware to your kernel. Is there a similar firmware we can leverage for the USB chip on these boards? Presumably this is a client server architecture (or host, client)?

Edit : I found this, is this any use? >> https://github.com/hathach/tinyusb

It's a great challenge and one that would create a whole world of possibilities on bare metal. I will have a look into the link you sent and whether it could accelerate this kind of work on the RPi4 for us. I'd be excited about getting USB up to enable access to the onboard Ethernet controller rather than relying on an SPI peripheral to do that (easier interface). Then there's obvious stuff like being able to connect a keyboard/pointing device etc.

It's been a while since I have updated the tutorial and so maybe this could be a good (but challenging) next step? 🤔

Let me write when I have some idea of feasibility!

Thanks for the inspiration/nudge...

Looks like tinyusb does not have support for xhci. It could be added though and there are people talking about how. This git was linked >> https://github.com/cherry-embedded/CherryUSB/tree/master/port/xhci

Hmmmmnn, well USB 2.0 would be a great start - USB 3.0 is just the icing on the cake! 🍰

Agreed. I found this on OSDev which purports to be the concise explainer of USB 2.0 from the spec
https://wiki.osdev.org/Universal_Serial_Bus

I shall have a read and revert with findings.

So it appears we will need some memory management, chiefly spinlocks and dma. This can be implemented as separate chapters I would have thought and would then segue into the USB piece.

I also found this >> https://github.com/Chadderz121/csud/tree/master

Yup - and actually I implement DMA in the sound tutorial and touch on the spinlock concept in the multi core tutorial, so we're not a million miles off...

Also wonder if we couldn't mod this to support Raspberry Pi 4? https://github.com/rsta2/uspi

Edit: Seems not easy. "USB on the RPi 4 needs MMU LPAE support (for AArch32) and a driver for the PCIe host bridge too. And if one wants Ethernet access, this would be another separate driver. With the increasing variety of RPi hardware, [the repo owner] decided to focus on Circle and related projects."

So far I am looking at building a Pi3 with usb support in Qemu. Then I am going to look at enumerating devices on the PCI Bus. I have also acquired a large book 978-1717425362 by Ben Lunt.

So far I have that you need to download the qemu code and some dependencies

For debian flavoured linux do this

sudo apt-get install libusb-1.0
sudo apt-get install libusbredirparser-dev

The compile from source like

git clone https://gitlab.com/qemu-project/qemu.git
cd qemu
git submodule init
git submodule update --recursive
./configure
make

The output from ./configure you are looking for is

libusb                                       : YES 1.0.25
usb net redir                                : YES 0.11.0

More when I get it

Nice! I have to say that I'm really targeting the Pi4 which has significant hardware differences... Seems non-trivial

Agree and my aim is aligned with yours. Qemu supports the PI3 out of box (there are Pi4 versions out there that I will try in time). I just want to get to the point where I have a barebones OS running on QEMU with something Pi shaped enumerating the PCIe bus from my native code. The same code should in theory port to the Pi4 and once we can get the address of the USB root controller from the PCIe bus then we are off and running.

Fell at the second hurdle with Qemu. Link to issue >>
https://gitlab.com/qemu-project/qemu/-/issues/1845

I think we close this for now. I am excited to see what will be possible with RPi5... ;)