adafruit / Adafruit_Blinka

Add CircuitPython hardware API and libraries to MicroPython & CPython devices
https://learn.adafruit.com/circuitpython-on-raspberrypi-linux
MIT License
453 stars 340 forks source link

ROCK_PI_4 improvements #664

Closed MathijsNL closed 1 year ago

MathijsNL commented 1 year ago

This PR will both fix the ROCK_PI_4 pinout to match the wiki and it will make the Rock 4 family work on a single board and pin file. Files were already tested on 4C+ and 4B+ in PR #658 . I tested a few GPIO pins after making the changes for this PR to make sure everything works as intended and it seems to be ok.

This PR will fix #659

MathijsNL commented 1 year ago

It seems like the orange pi 4 is also using the RK3399 chip. This PR won't work as long as the conflict with Orangepi 4 is not resolved.

In my opinion it is important to have a proper detection for Orange pi 4, because even though they use the RK3399 chip has not much to do with their pin layout.

Since I don't have an Orange pi 4 around there is not much I can do about it. Anyone has a solution for this?

MathijsNL commented 1 year ago

It seems the Orange Pi board detection is working properly, I renamed the original rk3399 to rk3399_orangepi4 to solve the issue. The PR as it is right now should fix the complete Rock 4 family without breaking the Orange PI 4.

MathijsNL commented 1 year ago

Maybe a small oversight, I think the board_id has to be added as a check to some of the files as well as to prevent the Orange Pi 4 from breaking. I will have a look at it later this week.

MathijsNL commented 1 year ago

By the looks of it the pinouts are completely incompatible. I think that adjusting the mapping in the Orange pi will not give a proper working board file. Orange Pi 4 does not seem to have PWM, has 1x less UART, 1x less SPI. And that is besides the actual mapping which I have my doubts about, but the documentation from Orange pi isn't great.

So while I agree having a shared chip file would be nice I don't think it is feasible. What would be the next best solution for this problem?

Edit: Here is a comparison between the pinouts, I just had to dig a little bit more for the Orange Pi documentation. It seems that about 5 GPIO numbers are the same, but that's about it. Link to Orange Pi 4 documentation: link

image

makermelissa commented 1 year ago

The reason why we have separate board and microcontroller files is because the microcontroller file maps things like when you are accessing GPIO4_C6, you are actually accessing sysfs pin 150. These values should be constant with the same microcontroller even on different boards. The board file maps what pins are used on the 40-pin header to the microcontroller pin. So for instance referring to the pinouts you posted, pin 13 on one board accesses GPIO4_C6 and a different board it has GPIO1_A3 for pin 13. Both boards make use of GPIO4_C6 in different spots and it maps to 150 in both cases.

While the Orange Pi 4 board only has 1 PWM pin (Pin 7), the microcontroller itself is capable of having 2 PWM pins. The second is just not used.

MathijsNL commented 1 year ago

So if I understand correctly it shouldn't matter if the GPIO numbers are different, it is the chip that matters. So for the RK3399 we should have a mapping to all the pins, even if they are different for different boards, and then use the board file to define which ones actually have to be used?

makermelissa commented 1 year ago

Exactly. :)

MathijsNL commented 1 year ago

Things were getting a bit messy so I force pushed as to not have so many back and forth changes. Sorry for the not so descriptive comment "Fix", I wanted to squash the commits but it failed. The "Fix" commit has the pin definitions needed for the orange pi.

I think the chip files are merged correctly now, and there is no 4cplus board anymore and the orange pi should still work.

Thanks for your input @makermelissa, in the end working with 1 chip file was actually a simpler solution.