allwinner: extend supported CPUS (H2, H3) #1
Comments
|
Could you contribute one? If you want the headers, you could create a directory orangepi and use https://github.com/periph/host/tree/main/pine64 as an inspiration, then send a PR. |
|
okey. i will give a try. |
|
@chenjeff622 Any progress on this? If not, I could pick this one up. |
|
https://github.com/periph/host/tree/main/allwinner |
|
Even if the pinout is not supported, you can still use sysfs driver as a fallback. |
maruel
changed the title
Add support for the Allwinner H2+ and H3 CPUs, which are almost identical. The H2+ has no GBit MAC and no 4h HDMI, but the rest is completely identical. For this library tho, it is not relevant, so we can combine these two CPU types into one single H3 and detect the H2+ as a H3 CPU. Support for detecting Orange Pi Zero boards are added, which uses the H3 SOC. The Pinouts are from the Orange Pi manual. This resolves periph#1
|
I've implemented support for H2+ and H3 CPUs. |
* Support for Allwinner H2+ and H3 (OrangePiSZero) Add support for the Allwinner H2+ and H3 CPUs, which are almost identical. The H2+ has no GBit MAC and no 4h HDMI, but the rest is completely identical. For this library tho, it is not relevant, so we can combine these two CPU types into one single H3 and detect the H2+ as a H3 CPU. Support for detecting Orange Pi Zero boards are added, which uses the H3 SOC. The Pinouts are from the Orange Pi manual. Fixes #1
[RSDK-1008] Support GPIO pins on the NVidia Jetson Orin board Tried at my desk: with these changes linked into the Viam RDK, I'm able to set the GPIO pins high and low through our app! Motivation for this is described at periph#26: on every other (non-Orin) board, if you enable a GPIO pin, it gets created in `/sys/class/gpio/gpioN` where `N` is the pin's number. but the Orin uses different names, so we need to include those names separately. Linking things up: this is the same PR as periph#27, but into our own fork instead of the original repo. This is a quick-and-dirty approach to get our Orin prototype up and running. This approach doesn't support muxing the pins to other locations (apologies if that's the wrong phrasing, I only half understand what it means), hence why the other version of this PR might not get accepted into the original repo in the near future. We (or they, if they get there first?) can figure that out later, when our support for the Orin is further along. #### How the list of names was constructed #### [Nvidia's documentation](https://developer.nvidia.com/docs/drive/drive-os/archives/6.0.3/linux/sdk/oxy_ex-1/common/topics/sys_components/CalculatingGPIOIndexinLinux32.html) describes what they should be in theory. In practice, there are 2 GPIO chips, and you can see their offsets and how many pins they have: ``` viam@orindevkit2:~$ cd /sys/class/gpio viam@orindevkit2:/sys/class/gpio$ ls export gpiochip316 gpiochip348 unexport viam@orindevkit2:/sys/class/gpio$ cat gpiochip316/base 316 viam@orindevkit2:/sys/class/gpio$ cat gpiochip316/ngpio 32 viam@orindevkit2:/sys/class/gpio$ cat gpiochip348/base 348 viam@orindevkit2:/sys/class/gpio$ cat gpiochip348/ngpio 164 ``` You can see that they're contiguous with each other: one starts at 316 and has 32 pins, and the other starts at 348 and has 164 pins. You can then enumerate all the pins by running `for i in $(seq 316 511); do echo "$i: $(echo $i > export; ls|grep -v export|grep -v gpiochip3; echo $i > unexport)"; done`. A handful of pins give errors rather than being exported, but all the rest of the names match up with what they're supposed to be in theory.
as title. how do i porting please?
The text was updated successfully, but these errors were encountered: