Raspberry Pi 2 support

[bluerise]

The Raspberry Pi 2 has a quad-core Cortex-A7, so it's based on the ARMv7 architecture. As we stopped supporting everything lower than ARMv7 we can actually try to support this new SoC.

I have spent a bit of time to make it run, trying to be FDT-only instead of using the board. There's a small list of things that I should work on before proper implementation can work.

• Implement a bit of ASM code to boot the kernel from the correct place. Maybe there's another way? Setting kernel_address to 0x0030000?
• Move fdtbus into MI arm tree.
• Attach cortex devices to fdtbus in FDT case.
• Don't attach FDT nodes twice, needed for interrupt-controller scan.
• Scan for "interrupt-controller" and attach them before other devices.
• Create a list of interrupt-controller nodes, so that an arm_intr_establish can call establish on the correct interrupt controller.
• Write interrupt controller driver.
• Write SoC peripheral drivers. Probably can be copied from FreeBSD.
  • Improve SDMMC stack
  • Write SDHC driver for PIO mode.
  • Support SDHC DMA.
  • Support USB DWC. (In Progress)
  • Watchdog (99%)
  • GPIO (99%)
• Find out how to load symbols/ramdisk. Load ELF directly? Tiny "bootloader" in the kernel?

[bluerise]

Parts of the fundament have been written now.

Next step is to make the interrupt establish a little bit more MI using the FDT.

[bluerise]

I have some kind of MI interrupt establish using FDT, but am not 100% happy and would love some feedback on 8f94a39.

I have started on the interrupt controller driver and am working on bringup on the SoC. I have a WIP commit with a559882, but might be waiting on ithreads for simplification.

[bluerise]

The symbols/ramdisk issue has been resolved with 18d548b.

mkuboot already created a binary with symbols + ramdisk, but always put a u-boot header infront. In this case we want the same thing, but without the header. Now there's a way to produce raw binaries.

[bluerise]

Aaaand some more updates.

[leto]

I would like to help with testing this. Is there a specific commit/configuration that you would prefer help with?

[bluerise]

I just committed what I have so far to master, see commit 5d4c5b9.

Unfortunately USB (and thus network) still doesn't work. Without that, I wouldn't call it usable. :/

[leto]

I have a new RPi2 burning a hole in my desk, so I am interested to help with bitrig development. I notice that there is no "starting to hack on bitrig" or any docs to help devs get involved with the project. I am happy to help with that, which will be useful for me as well. I will make a different issue for that.

As for this issue, what about Ethernet support? Does that rely on USB support? The more you can break up and define the remaining tasks in supporting RPi2, the more I can help.

[bluerise]

True that, I'll have a look at that other issue then.

Yeah, Ethernet relies on USB. The ethernet controller is not natively connected on the SoC, but basically a usb->ethernet device. I can actually see and talk to the USB devices, but once there's a bulk transfer to the input endpoint, it times out.

Things that are to do:

• Debug the USB issue
• Remove mutexes/spinlocks from dwc2 and replace them with spl calls
• Implement vcprop interface, so that we can talk to the GPU about Video
• Implement display driver, which uses the vcprop interface
• cpu frequency scaling?

[bluerise]

And, of course, setting up a miniroot/install procedure for it.

[ghost]

Hi guys
Is this effort dead at the moment?
Best wishes

[bluerise]

Since I'm not involved with the project anymore, I guess I can close this issue.