Add support for AllWinner CPUs (Banana Pi and Orange Pi)

[akuker]

Info

Raspberry Pi's have become "unobtanium" with the current chip shortage. Because of this, I think RaSCSI should be expanded to work with other Raspberry Pi compatible clones, such as the Banana Pi or Orange Pi.

• Which version of Pi are you using: Banana Pi M2 Zero
• Which github revision of software: 22.02
• Which board version: Any
• Which computer is the RaSCSI connected to: Any

Describe the issue

The GPIO low level software interface of the Banana Pi M2 Zero (Allwinner H3 CPU) does not appear to be compatible with the RaSCSI service. It would probably be possible to use a higher level GPIO interface (such as wiring Pi), but that is likely going to kill the performance.

Additional details

The RaSCSI gpiobus.cpp is looking for a /proc entry at /proc/device-tree/soc/ranges. The Banana Pi does not have this proc entry. However, the general "gpio" utility seems to work.

I'm going to use this issue to document the notes that I find and any progress that I make. If anyone has a Banana Pi and wants to help, I would welcome it!

Todo list:

• Try latest version of Armbian
• Buildroot has a defconfig for the Banana Pi. Potentially give that a try?
• Maybe some clues in the Allwinner H3 Datasheet

[akuker]

FYI: https://wiki.banana-pi.org/Banana_Pi_BPI-M2_ZERO

[uweseimet]

@akuker Wouldn't it be better to address the numerous open issues instead of spending time on new ports? There is no automated testing, no code analysis etc. that would ensure that any changes for new platform don't break existing code. You often say you are lacking time, a new port would not help with that ;-).

[rdmark]

I think this is a high priority feature due to the extreme ongoing scarcity of Raspberry Pis. It is practically impossible to get into RaSCSI as someone who doesn't already own a Pi, which really does the project a disservice.

That said, introducing unit testing and static analysis first would be incredibly beneficial for maintaining confidence in code quality while making low-level changes! :)

[uweseimet]

@rdmark There is no shortage of these other boards? Why is that? Just because they are not as popular as the Pi? The RaSCSI board can be used with them without any modification?

One more thing: It's not just about code quality, but also about the code building and working. Do you remember the segfault some time ago that only happened with optimized code, and that vanished when having the same line of code in the .cpp instead of the .h file? In addition, I regularly stumble upon build errors on one of the Pi platforms, just because the OS or compilers (32/64 bit, Raspberry Pi OS/Ubuntu, or just the OS version like buster/bullseye) differ. This will not get better with additional platforms. Without automated building/testing you cannot avoid missing issues like these. In the quite distant past I was involved in various C++ software porting projects (Unix flavors, Linux, Windows). Without automated building/testing these projects would not have been possible. Of course, a lot depends on how different the platforms actually are. But even very similar platforms can cause issues (see the examples above). An increasing number of build time or runtime errors, that's what IMHO would do the project a disservice, not just affecting new but also existing users.

Some years ago, and again recently I had a look at the SCSI2SD release notes. They were/are full of recurring bugs. Fixed in one firmware release, re-appearing in one of the next releases. This is why my software explicitly does not support SCSI2SD. It's not reliable, at least that' my personal opinion based on the release notes, and this is what should be avoided.

[uweseimet]

I just created https://github.com/akuker/RASCSI/issues/703, which is related to the question on how to test, and also on how to support other hardware without affecting most of the existing code. Once more the lack of code modularity and abstraction becomes apparent. This cannot be properly resolved by just adding some #ifdefs here and some work-arounds there ;-).

[rdmark]

@uweseimet I can only speculate, but the Banana Pis are simply not well known among the general populace, and are only traded directly from China. Lower pressure on their stock, and the proximity to manufacturing plants in China perhaps means that they can keep up with demand easily, while RPis are on backorder everywhere which has a cumulative effect on demand. But I digress. Someone with an economics major could probably explain this more accurately. :)

@akuker The going price on Aliexpress for a Banana Pi M2 Zero seems to be about $30 with shipping. Is this what you paid as well?

[akuker]

Wouldn't it be better to address the numerous open issues instead of spending time on new ports?

I agree that the open issues are important. There were other folks in the discord channel who were interested in this same thing. I can't speak to WHY officially rapsberry pi's are so hard to purchase, but these clones are available. My PhD in supply chain analysis isn't quite done yet ;-) I've had several inquiries from folks who wanted to get involved in the project, but they can't find Raspberry Pi's.

For me, this will be a background task. When I'm watching TV, I'll be browsing Allwinner documentation and maybe poking at Armbian builds. I really think the changes will be limited to the gpiobus.cpp class. Other than the low level GPIO interface, the code should be the same.

Regarding #703 - I would like to abstract the gpiobus.cpp class so that we could have different sub-classes:

• Raspberry Pi GPIO (current implementation)
• Allwinnner GPIO
• Simulated GPIO (would work great for implementation - maybe just used shared memory or something?)

But again, this is lower priority for me. We should make better use of the "bug" label in the issue list. This will help us focus on those items instead of the enhancements. Right now there are only a couple issues tagged as "bug", so I'd welcome help with tagging the ones that are true bugs.

[uweseimet]

@akuker I doubt that there are (many) issues that are bugs but are not labelled as bugs. Is there any way to prioritize issues with github? Just with labels it is hard to prioritize.

[uweseimet]

@akuker Regarding a simulated GPIO I don't see (maybe I am missing something) how shared memory would help here. I guess a kind of state machine would be needed, something that remembers and can change the status of the bus signals. I would expect the methods gettting/setting the signals, which are the interface between GPIO and the controllers as far as I can tell, would be the ones that end up iin different implementations (all implementing the same interface), for different hardwares or just the simulation.

[uweseimet]

@akuker Regarding prioritization, maybe github supports a Scrum board, which may make working with priorities easier. On the other hand, being able to pick any open ticket you like (which is NOT Scrum) is IMO important for projects like RaSCSI, where contributions are voluntary and the skills of the contributors are unlikely to match the order of prioritized tickets.

[akuker]

https://armbian.hosthatch.com/archive/bananapim2zero/archive/Armbian_21.08.1_Bananapim2zero_hirsute_edge_5.13.12.img.xz

https://armbian.hosthatch.com/archive/bananapim2zero/archive/

[akuker]

https://wiki.banana-pi.org/Getting_Started_with_M2_Zero#Advanced_Development

[akuker]

https://linux-sunxi.org/Main_Page

[uweseimet]

@akuker Any news on this? Pis are still almost unavailable.

[akuker]

No news - doesn't work. Closing ticket. If someone finds time to work on this, we can reopen.