Recently I reviewed the Orange Pi Zero 2 and thought it was a fantastic board. I really like the amount of polish that the Orange Pi line of products have as it is the closest I have seen to anything approaching a Raspberry Pi experience. We also benchmarked the Orange Pi Zero 2 and determined it’s a very capable board.
I recently got a Orange Pi i96 (thanks munecito!) and this board is very exciting because it was purchased on sale for ~$10! That is insanely cheap. The reason it’s so cheap is because it’s a headless board that doesn’t contain any display-out ports.
If you are going to be using the board headless anyway (I use most of my SBCs headlessly) you may be able to save a fortune with this board. Let’s get started!
Hardware Used
Orange Pi i96
The Orange Pi i96 is a low-cost board from the Orange Pi line of SBCs. It uses the RDA8810 SoC and has 256MB LPDDR2 SDRAM. It’s well suited for headless tasks and is astonishingly cheap.
The Geekworm copper heatsink set is designed to fit many different single board computers. It uses thermal conductive adhesive which many “cheap” heatsink kits for SBCs don’t have. Eliminates hotspots and reduces throttling. Can be further enhanced by powered cooling over the heatsinks.
The Orange Pi monitor is meant to be a portable monitor you can take anywhere. It has a resolution of 1080P and features a hinge in the back that folds out to support the monitor.
Alternatively you may use the official images (not recommended for this board). If you’d like to use the official images instead head to the official Orange Pi downloads page:
Orange Pi – Official Downloads Page
Now select the Orange Pi i96 from the list. I will be using Ubuntu Linux for this guide but you may use Armbian as well.
If you are wanting to try Android I highly recommend seeing my Orange Pi Android Installation Guide as the installation process is different than Linux.
Writing the Image
The images are typically distributed as a .tar.gz file. The name of the Ubuntu image tar.gz file at time of writing was OrangePi_i96_ubuntu_xenial_server_linux3.10.62_v0.0.4.tar.gz.
We will need to extract this file. If you are using Windows then grab 7-zip to be able to extract a .tar.gz file.
Inside this file will be a .img file. Since I downloaded the Ubuntu image the name of my file was OrangePi_i96_ubuntu_xenial_server_linux3.10.62_v0.0.4.img. This is the image that we are going to write to our SD card.
There are several choices to write the image to your SD card. If you are on Windows I recommend Win32DiskImager. Etcher is also available for Windows/Linux/Mac OS X.
Write the image to the SD card using your preferred software.
First Startup
Before starting up you should make sure that the Orange Pi’s switches are in these positions (indicating to boot from SD card):
Orange Pi – SD Startup PositionOrange Pi – SD Startup Position
We’re ready to put the SD card into the Orange Pi i96. But how are we going to connect to the device? There’s no network port and the device isn’t configured to connect to our WiFi yet.
Connection Option #1
If you happen to have a USB to Ethernet adapter that is the easiest way to connect to the device for initial configuration:
Once you’ve connected it’s time to do some basic configuration. We will use the tool orangepi-config:
sudo orangepi-config
You may now set the WiFi settings, etc. The orangepi-config is just like raspi-config if you’ve ever used that on a Raspberry Pi.
Don’t reboot before doing the next section.
Fix Second Startup (Debian / Ubuntu)
You will notice if you reboot the device it will often not come up the second startup. This is especially likely if you performed a sudo apt dist-upgrade.
To prevent this I recommend removing the alsautils package. This will impact sound functionality on the board but as I was not using it and intended to use this more as a headless board this was fine for me.
For the wireless to function very well at all you need to set the wireless regulatory domain.
If you are not using my image then you will first need to install the crda package with:
sudo apt install crda -y
Now we can set the regulatory domain by editing the following file:
sudo nano /etc/default/crda
At the bottom of the file there is this line:
REGDOMAIN=
Put the 2 letter country code for your country. Mine is “US”. Once finished press Ctrl+X then Y to save the file.
Optional – Upgrade Debian OS to Buster/Bullseye
Note that this will not upgrade the kernel. You can upgrade everything else though including all the way up to Bullseye. You should do this one release at a time and start with “Stretch” and then do “Bullseye” afterward.
If you are using the Debian installation you can upgrade to Buster by editing your /etc/apt/sources.list file.
Change all instances of “stretch” in the file to “buster” and then do the following:
sudo apt update && sudo apt dist-upgrade -y
Once this has completed reboot the system (make sure you’ve done my fix second reboot section first by purging alsa-utils). Verify you are on Buster with
Now you can upgrade to Bullseye. It’s almost the same as upgrading from Stretch to Buster but there has been a change in the security updates server format. Here is a working “Bullseye” apt sources file for the Debian Orange Pi i96 image:
root@orangepii96:/# cat /etc/apt/sources.list
deb http://ftp.debian.org/debian bullseye main contrib non-free
#deb-src http://ftp2.cn.debian.org/debian bullseye main contrib non-free
deb http://ftp.debian.org/debian bullseye-updates main contrib non-free
#deb-src http://ftp2.cn.debian.org/debian bullseye-updates main contrib non-free
deb http://security.debian.org/ bullseye-security main contrib non-free
#deb-src http://security.debian.org/ bullseye-security main contrib non-free
Once you’ve changed the files do a sudo apt update and make sure you don’t see any errors. If everything looks okay start the Bullseye upgrade with:
sudo apt full-upgrade -y
After a reboot you should be on Bullseye! We can verify this with cat /etc/os-release:
Notice that the kernel has not changed at all (as cautioned at the beginning of the section) but everything else on the system will be Bullseye!
Performance Benchmarking
I benchmarked the board using a SanDisk Extreme SD card on my Pi Benchmarks web site. This gives us comparable results between boards and there are over 30,000 benchmarks submitted for various boards / storage devices.
I had a total score of 497. This was below average or off from an average Raspberry Pi setup by about 47%.
To be clear the storage performance on the board is relatively low compared to the Orange Pi Zero 2 or a Raspberry Pi (Zero or 4). That is to be expected for a price of around ~$7-$10.
I’m not sure I would say this is a disappointing result though. We are talking about a board that is a single digit number of dollars. For the price point that is fantastic performance! In fact for the price point it’s a wonder that it works at all.
Conclusion
It’s a great board. At a price point of $7-$10 it reminds me of the really, really old Raspberry Pi Zero days where you could actually get a Raspberry Pi for around that price point.
The Zero 2 is a significantly more powerful board. It benchmarked much higher than the i96 but it also costs significantly more. If you need more power that board will be a better choice. If you’ve never had an Orange Pi before I would recommend the Zero 2 first as this board is quite a bit trickier and has more outdated software available for it.
The version of Ubuntu on this board is also quite old (Ubuntu 16.04 / Xenial) compared to the Orange Pi Zero 2 which is actually running a modern 5.X kernel whereas this one is a 3.X kernel. Make sure that is not going to be a problem or you will want to step up to a higher Orange Pi. The i96 is definitely meant for simple services / projects that don’t need a lot of power. It’s perfect for those.
If you need a headless board then the Orange Pi i96 may very well fit the bill for you, the price is certainly right! Don’t skip the heatsinks though. It got very warm during testing (warm enough to freeze once during consecutive benchmarks) and Orange Pis are known to get quite hot!
Hi,
What do you think about external hub connected to built-in usb port? By default external usb hub is disabled 🙁
Below you can find the information that I was able to find out
dmesg | grep hub shows
hub 1-1: ignoring external hub
(as a result from CONFIG_USB_OTG_DISABLE_EXTERNAL_HUB = y setting and usb/core/hub.c file )
if you want to delete this line from config, I warn you because another message will pop up
usb: kernel must blacklist external hubs (as a result from this file: usb / musb / musb_core.c)
Here I’m stuck and have no idea where to look further
It looks like it doesn’t even run that check unless you don’t have a controller that supports multipoint. This makes sense because when Marco plugs in a battery (leaving the microUSB port available to be used) it can still only control a single device.
There is multipoint specifically disabled again with define MUSB_NO_MULTIPOINT. In other words in this case it’s not that something is missing. It’s specifically shut off in multiple places and it doesn’t look like all controllers support this. This is actually shut off purposefully and it looks like it’s going to take more than that to remove it. Multipoint support would need to be enabled if that’s even possible with this device.
I can try this but the USB hubs aren’t just missing a kernel flag. There’s at least several places that need to be changed. There’s another one here:
Again here we have multipoint disabled. If I set that to true will it work? I honestly sincerely doubt it but I’m trying it. They *really* went out of their way to make this not work which means I’m guessing I’m going to get horrific crashes when it finishes building my test image here. It doesn’t look like one of those issues where they just forgot to turn a kernel flag on. There’s a lot of code to make those hubs not work in multiple places which strikes me as there’s probably a reason for it.
I’m building a test build with these changes but who knows how many more there are and what kind of errors I’m going to get when I plug in a hub. If I’m seeing weird VBUS errors and really strange errors in dmesg it means that the pins aren’t wired on the USB for this to work properly best I can tell!
EDIT: The USB won’t function at all with those attempted changes (with or without a hub).
I think that usb hubs are disabled due to low powering capacity & to prevent powering too much usb devices (when you plug in sth like usb wireless card the sbc board turns off).
I’ve analyzed the RDA8810PL documentation (link at the end), in it is written:
“USB controller supports up to 15 ‘Transmit’ endpoints and/or up to 15 ‘Receive’ endpoints in addition to Endpoint
0” (Page 62) <– so it is multipoint. There are more informations about the USB controller but I don't understand them…
From what I could deduce and what you may already know, there is one physical connection to the usb port (there is 8 dip switch, where you set which port (microusb / usb A) has to be connected to the usb controller)
I don’t think this is a kernel configuration problem. What is happening is that when you are disabling that setting you’re getting a different warning that is telling you that the hubs should indeed be blacklisted (but that now it’s telling you you have to do it yourself with blacklist files). In my last post I showed all the places where multipoint is disabled but it sounds like from the specs it should support it.
The warning/error is telling you that now you have to blacklist them manually yourself since the kernel parameter is turned off and it knows it shouldn’t be doing it. I fixed this and tried to enable them (including multipoint) and the USB won’t function at all. You can keep changing more flags potentially but I’ve tried this several times (including in my last reply to you) and the USB goes completely dead and nonfunctional.
Maybe it would be easier with a UART to serial adapter which I really need to pick up one of those as when the USB doesn’t function that breaks my ethernet to USB adapter as well. I could use the WiFi but the problem is I have to rebuild the kernel which means it’s a brand new image that hasn’t been configured for WiFi yet. I guess I could preconfigure it for WiFi when I build the image somehow (even if it’s through the chroot) but I’d have to come up with a way to do that as there isn’t one currently. I may be able to use the “Update Kernel” option from the i96 build menus if I first log in with a working kernel, then set up the WiFi and then just start updating kernels but getting the right tools would make this a lot easier / faster.
I’m pretty sure this is a hardware issue. My hub is also self-powered like this one (but I’ve tried plugging it in without it being self-powered leaving the power unplugged). In this thread they are saying that the USB spec is open to interpretation on this issue which leads to the problem if the manufacturers don’t take certain steps (outside of spec) to fix it. It’s not unique to the i96. My impression is this is also fixed with USB-C which is why you will have to go back around 5+ years to find any examples of this happening.
This issue has been different than all of the others. All of the others were just missing things for the most part. I don’t mean to be too cheeky toward Orange Pi here (who else has an actually available to order $6 board) but the original image is missing so much of the bare essentials that there’s just no way this is due to their excellent planning / power management. The original version of the image is too strong of evidence to the contrary (and borders on incompetence, some of tiny fixes we’ve made to this to make the board 5x better were so easy it honestly makes me mad they didn’t do it in the 5-6+ years this board has been out). This is either a mistake that requires a lot more fixes than I’ve realized to get it functioning (possible) or it’s because they needed to add something else to the board for this to work and they know that they didn’t.
If someone else wants to try they can absolutely give it a go. I’ve already tried this several times though and only end up with completely nonfunctional USB! It definitely seems like this is disabled for a reason in this case and unlike most things trying to enable it seems to actually make things break completely from my testing.
I thought this would be an easy one but I can honestly say I’ve tried to fix this more times and spent more time on it than issues that seem like they would be a lot harder to fix such as fixing the SD card and USB ports to both support high speed mode. I fixed those on the first try (not my first build/attempt but I mean the first time I sat down and tried to solve it I was able to eventually without giving up and going to do something else) and this issue I’ve tried and failed on probably 3-4 times (unusual, there’s nothing else that I’ve tried 3-4 times on this on that isn’t fixed, and it’s why I keep questioning if there’s a hardware/electrical component to this issue).
That being said it very well may be possible as a lot of other problems on this board that for sure looked like hardware limitations/issues ended up being fixable 100% (as in like almost every issue people talk about with the i96). This is a tough one though and I’m still in the stage of trying to determine if this is indeed a hardware limitation or if it’s just more crazy image issues. If anyone has any idea how to work around this I’d 100% add this into the image if it’s possible!
Jack
2 years ago
I want to use this board as a webrtc client, the offical img existed many problems and already stoped maintenance several years ago, i had all most drop it until see this blog.
I tried to use the usb sound card on this board, but it could not work normally.
When i inserted the usb sound card into the board, dmesg log show: [ 2734.458007] musb-hdrc musb-hdrc: VBUS_ERROR in a_wait_bcon (98, VALID), retry #1, port1 00000100
[ 2735.932495] usb 1-1: new full-speed USB device number 3 using musb-hdrc
[ 2736.086547] input: C-Media Electronics Inc. USB PnP Sound Device as /devices/platform/musb-rda.0/musb-hdrc/usb1/1-1/1-1:1.3/input/input2
[ 2736.095520] hid-generic 0003:08BB:2902.0002: input,hidraw0: USB HID v1.00 Device [C-Media Electronics Inc. USB PnP Sound Device] on usb-musb-hdrc-1/input3
I used the cmd "aplay -l", the usb sound card device could not be found, just show the rda sound device on this board:
**** List of PLAYBACK Hardware Devices ****
card 0: rdasoundcard [rda-soundcard], device 0: rdaaud-stream rda-codec-dai-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: rdasoundcard [rda-soundcard], device 1: rdavoice-stream rda-voice-codec-dai-1 []
Subdevices: 1/1
Subdevice #0: subdevice #0
I don’t know about USB drivers, is it existed any problmes?
Any help will be very appreciated!
I can definitely enable CONFIG_SND_USB in the image. This should solve at least some of it and with any luck it will just work with this change without needing additional drivers.
Can you give version 1.18 a try and see if it will work on that version?
I just made this change. You will need to download 1.18 from the GitHub releases section and reimage it to see if this change will work! I definitely still can’t guarantee it will work with this kernel flag enabled.
From what I can tell it definitely won’t work without it though but without having the sound card personally we’ll have to see if it’s this simple or not. Let me know what you find either way but from my research the fact that it’s showing in lsusb correctly is a good sign that it might only take this kernel flag change!
I had tested the latest version 1.18, the usb sound card can’t be found at the List of PLAYBACK Hardware Devices: root@orangepii96:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: rdasoundcard [rda-soundcard], device 0: rdaaud-stream rda-codec-dai-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: rdasoundcard [rda-soundcard], device 1: rdavoice-stream rda-voice-codec-dai-1 []
Subdevices: 1/1
Subdevice #0: subdevice #0
Thanks for testing this! I couldn’t even begin to guess what is wrong without having one of these devices. If you are able to build the kernel I’m sure we could figure out which one it’s missing most likely!
I agree, there’s a dozen other flags it could be, there’s also a CONFIG_SND_USB_AUDIO that isn’t even in this kernel config file but other places mention it. I can’t just start guessing though without having one of the devices. Almost nothing in this image has been as easy to fix as flipping a single switch (as you’ve ran into as well). It could be a lot of things for sure!
That would be appreciated if you get a chance. I have a lot of USB accessories but this is unfortunately not one of them at the moment!
Dustin
2 years ago
Hey James,
Got the boards from AliExpress. It only 2 weeks, which was surprising with all the supply chain stuff you hear about. Installed your image, worked great. So, I did a bit of an ID10T move. I AssUMed that I could use a Raspberry Pi camera on one of these boards. Well, I didn’t fry the board, but it got super hot. Haven’t tried the Pi Cam (nervous).
Anyway, I guess I need one like the link. Anybody tried one of these?
Welcome back, that is excellent! I got my couple that I ordered around the same time as you did here on my desk. The heatsinks really, really help with the heat for sure. I have a link in this guide to the ones I’m using (which has a shape that matches the rectangular shape of the i96 pretty closely in that GeekPi set) but you don’t need anything too crazy or specific. You will want to have something though for sure.
The powered fan setup would be another level up from this but I’ve only heard of a couple of people going that far yet. I’m still just on the heatsink system myself with no powered fan at the moment. I definitely don’t recommend running it bare because even with the heatsink it’s possible to overheat it (but it’s much harder, as in installing 800+ packages from apt at once kind of a load required to have a chance of overheating it).
I should note that this will depend on ambient temperature as well. My Orange Pi sits on a shelf in a relatively cool air-conditioned basement in the dry Utah desert (with 30 solar panels on the roof to manage energy costs) so my heatsink air cooling is pretty ideal compared to a lot of other places where you may want to try a powered fan setup (think one of those tiny fans that can be powered by the GPIO pins for example). The person who donated my original Orange Pi i96 board actually did this and said they used a clip to hold the fan in place over the heatsink.
Whether the overheating/crashes can be fixed or not (other than at least by applying a heatsink or even using a powered fan setup) is still under investigation. There’s several approaches that could be taken to fix it. We could write our own throttling code and adjust the frequencies down more aggressively to keep it from overheating potentially. It may be bugs that are causing some heat related crashes too as we have found bugs in almost every place we’ve looked (and been able to fix nearly all of them identified so far collectively as a community).
The camera module is interesting. I actually have not heard from anyone who has used it yet with the i96. I did find one post here related to it. They said it didn’t work for them and then they gave up. That is the only thing I could find on the internet.
Therefore my conclusion would be that I would not expect the official camera module to work out of the box unfortunately and I don’t see any examples of people who got it working yet. Could it be fixed to work with it? Yes, I think it could definitely be fixed although I do not have one so it would probably need to be someone that has one that debugs/fixes the driver. I’d definitely be willing to integrate any fixes for the camera that are found into the image!
Alrighty, once again, I’m throwing caution to the wind and I’m going to ordering up some cameras. Assuming these guys don’t have H264 encoders, I’m hoping they can handle some light MJPEG compression. 🙂
On an unrelated note, I was getting -32dBm WiFi signal (reported by wavemon), which is pretty amazing. (My phone is currently sitting at -49dBm) The throughput speed was only like 250-750K/s which is disappointing. I’ve tried serving a file off both SD and USB using SFTP and FTP, no difference. I have a EERO 6 mesh router and my desktop is wired GBE. Generally, the shell is unresponsive, so I think something is up. Any ideas?
This is an issue with the wireless for sure. If you try using a USB to ethernet adapter you will not experience any of those issues for sure. I’m working on improving the wireless driver but I’m not a WiFi driver expert so it may take some time.
If you have a USB to Ethernet adapter to test with I highly recommend giving it a go just to compare the difference. Hopefully the throughput issues can be fixed!
MZA
2 years ago
Hi James,
I’ve got the spi2 working with spi_gpio driver at 1Mbps. It won’t be a rapid port.
For this, I’ve modified devices.c and the script gpio_fixup.sh to assign back the SPI2 pins to gpio function for the spi_gpio driver to work.
I’ve also modified the default spidev port in the WiringPi lib and the pin labels in the gpio tool.
I’ve declared two slaves to have spidev2.0 with CS pin A10 ( Header 16) and spidev2.1 with CS pin A6 ( Header 12)
All is committed under : OrangePi-I96-Work.git ( OrangePIRDA/kernel and OrangePIRDA/output/rootfs) WiringPi.git
I’ve tested the spi communication using physical loop and read some registers on an MCP2515 CAN transciever, but I failed to have any lcd display work, There are still things to correct in the framebuffer driver I downloaded.
Now the good news is that we could have CAN communication, pin voltage won’t be a problem, the i96 outputs nearly 2.9 V which seems to be compatible with MCP2515. There is a road to go to add socket can and link an mcp2515 driver to the spi port.
Excellent work! The original example I linked to uses the fbtft driver. They actually have to hard link to it in the source code. That person didn’t use spidev at all basically. They actually include the fbtft header even inside that file (does not exist before, and my version does not do this, I did not link the fbtft driver like this person’s example and didn’t go that far).
I don’t think we’re going to get it to be much better than this. It’s always going to require modifying the kernel to do this I think. Why? Because the Raspberry Pi uses device trees and overlays to do this and the Orange Pi board doesn’t support them. It will have to always be hard modified to use whatever driver will support the device you are using. I don’t think this can ever work exactly like the Raspberry Pi because of this lack of device trees and overlays. I could be wrong but I’m not sure how we eliminate having to hard compile drivers into the source (or a bunch of loadable kernel modules) without this piece.
I guess we could just keep adding drivers that people keep using to the image but even if we do that it will probably support a tiny fraction of the screens available out there relatively speaking unless we want to put dozens or more drivers included in the kernel for each different screen type. That might be possible via modprobe with optional “m” compiled kernel modules. Maybe there’s more overlap in the screen drivers than I’m thinking though and that if we added a few it would cover most of the screens out there. I’m actually not sure how many different types of drivers are available but I have yet to see anyone trying to use the same one as anyone else who has tried it before (with admittedly few examples).
I’m definitely going to get these all packaged up and released. Thanks for doing it! I think it’s as good as we can get it and I suspect if anyone wants to use a screen they will have to modify the kernel for every single different screen type due to the lack of overlays / device trees being used in this kernel! This is being packaged as 1.17 and should be up shortly!
I did add the tfbt drivers to the kernel tree, added the device to the board_info etc, the ST7735R driver uses spi transfer and needs either native rda-spi driver or gpio-spi. I set it to spi-gpio like did the russian guy.
Unfortunately, I did not get it display anything, the /dev/fb0 was mounted and every thing seemed OK.
I also tested another e-Ink display without success.
A least, I swapped to the MCP and read a rigister to confirm the spi was working.
Got it, thanks for clarifying! That’s definitely pretty interesting. I was able to get everything integrated into 1.17 here I believe. I wonder why it’s still being stubborn here!
Could the RDA display out be interfering with this somehow? From what I can tell that is always running and has those nasty timeouts every time the board boots (for the backlight service I think for the RDA display output). It just sounds to me like you have everything right here and that something else is going on.
Are you seeing any dmesg activity from the rda display module indicating it might be interfering or trying to map the wrong devices that are related to that output and not yours? Or perhaps that it’s even trying to talk to it or send it commands from the driver (hopefully not this). Even on my system in dmesg:
rda_fb_probe_panel lcd panel'name(mcu_ili9806g) doesn't match of cmdline!
[ 0.642944] ERROR no lcd panel driver init
[ 0.643432] rda_fb_probe_panel lcd panel'name(mcu_ili9806g) doesn't match of cmdline!
[ 0.709045] rda_sensor_video_probe: priv=ce731710
Whatever it’s doing it looks broken. I just wonder if it’s interfering with what you’re trying to do somehow and this video driver is for sure loaded.
Hey James,
I’ve got the same messages, I don’t see any lcd activated and I checked the datasheet, they’re separate from SPI pins.
I’m back to rda-spi driver without DMA and working with the mcp2515 CAN transciver, code and execution seems coherent but the port gets stuck after 3 bytes transfer all RX become 00.
With the gpio-spi driver the MCP2515 device is probed, I can have the can0 interface, bring it up, set its bitrate but then no TX, no RX and no indicators. I think spi-gpio does’nt work with this MCP, the mcp2515 driver uses spi transfers that cannot be mapped obviously to spi-gpio. I could not see where to tell the mcp driver which gpio chip select pin to use. I’ll continue some time my unfortunate effort to bring this CAN.
Thanks a ton for your work on this issue! You’ve gone further and fixed more things along the way than anyone could possibly have asked or hoped for.
I think despite the problems with the CAN that you have probably enabled the use of many other SPI interfaces potentially through your work. I know you have electrically verified many connections using spidev with your changes included.
I really would like to get some simple SPI devices for myself to start testing with (not just for this board but with some of my other boards as well). I wonder if you could get the much simpler SPI devices functional with your existing work as is. I suspect (with the right drivers or for simpler devices that you may just use raw input/output with) that many types of devices would in fact work now with your changes.
Definitely keep me posted, I always love to hear what you’re finding!
Marco
2 years ago
i have been tinkering, trying to get the wifi working better and i dont know for 100% if this affects the wifi-ability, but for me it did.
i set all baudrates which are set from 921600 to 115200, even on uboot. uboot doesnt seem to bother about the new baudrate, so still dont know if i can set it there (i set it in all config files i could find but it still runs on 921600).
since then my wifi is stable enough to get roughly 2.3MB/s over wifi, and bluetooth seems also to work smoother.
this could be a false positive tho but i have the feeling iam not imagine it.
i can even have multiple ssh sessions open without random freezings on the sessions, in adittion i am downloading a file with fullspeed (2.3MB/s), and the shells are still available.
i had so much more problems with the wifi before that, can anyone test that out?
and i also commented out power managment for wifi device //#define WLAND_POWER_MANAGER
in drivers/net/wireless/rdaw80211/rdawlan/wland_defs.h
(but later)
sometimes when bluetooth “scan on” is set, wifi still drops and “scan off” is not applicable, then i use “power off” to disable bluetooth
and after testing further file transfer (download) on the pi, i discovered that the pis speed will drop very quick and drastically, when the cpu is getting hotter, so a heatsink is a musthave
i added cpufrequtils as a pullrequest, after setting the cpugovenor to performance, i didnt receieved that much of a drop after that. the load is still at 2, but the connection seems to be stable and continiously over 2MB/s
Interesting findings! That appears to be a very old bug in the WiFi driver that was never solved (or it’s heat related, more on that in a moment). I don’t see that anyone has ever even tried to solve it or got an answer to why it happens:
I agree about the heatsinks. I’ve always had them on mine and I definitely recommend them in the guide as well. They definitely do help with the stability. It wasn’t too hard for me to crash it out (even apt updates could do it back when you had to install thousands of them to update the main image). I could consistently crash it by installing all the apt updates at once on the old image. There was about a 50% chance it would crash when doing this and if I didn’t let the Orange Pi sit before trying again that chance went up to 100%. That was with me having the heatsink from the very start. If you touch the heatsink when it crashes it will be quite hot. I wonder if this is just heat related kernel panic. I haven’t seen a crash like this for a while because I don’t have to do any very intensive tasks on the new image anymore since all updates are already done.
Performance mode should be the hottest of all the modes. In that mode it should never downclock the CPU (even when it’s doing nothing). Setting it to ondemand or powersaver would probably be the ones that would drop the temperature. You probably want to let this hot board downclock. I bet you could consistently crash it on performance mode even with a heatsink. You’d need a powered fan probably for it to be stable on performance would be my guess.
These crashes are all over the place in dmesg. Is it the WiFi driver? Is it the SDIO driver? The answer appears to be “yes” to both of those questions. There’s crashes related to all of them in here (and the other threads people posted). I really think you are on the right track with the thermals here. The crashes strike me as the board is getting unstable when it’s too hot. I’d love it if this was just a driver bug but your testing seems to point toward load / thermals so far. It doesn’t seem like there’s a specific action that triggers it. It seems like once there’s enough activity to get too hot it does trigger but those are just my initial impressions!
I should also mention it could be both. It could be both a driver bug *and* thermally related. Perhaps we’re reaching a temperature that is triggering buggy driver code. Maybe it is trying to do some sort of throttling and the code that controls it is completely broken. That would not surprise me in the slightest so I figured it would be worth mentioning as well!
If there wasn’t some sort of driver component to this I wouldn’t expect to have been able to find crashes so similar to yours. If the CPU just went completely crazy at a certain temperature I would expect anything to happen and for the errors (and behavior itself) to be pretty wildly different each time as you would expect from a completely malfunctioning component. This does seem to be breaking in a consistent way which suggests to me it can be fixed or at least controlled / alleviated rather than just say the CPU can’t run stable at a certain temp (which should look different than this, I think whatever we are triggering is probably the “warning” level or definitely way below the point where things go completely off the rails). The board is definitely crashing out before we are melting it or even getting high enough for really weird/inconsistent things to start happening it so it seems like something before that point is being triggered and then crashes out.
I found several interesting things. I did a search in VSCodium for files including the name *rda* that have “temperature” in them. In kernel/drivers/cpufreq/rda-cpufreq.c we have:
#ifdef CONFIG_RDA_AP_PLL_FREQ_ADJUST
/*TODO - if more high temperature message keep coming, highest freq can be
* set lower
* */
static struct cpufreq_frequency_table low_freq_table[] = {
/*
* CAUTION:
* CPU frequency range can NOT be too large, otherwise VCORE
* fluctuation might impact DDR.
*/
{ 0, PLL_CPU_FREQ_LOW / 3 * 1 / 1000 },
{ 1, PLL_CPU_FREQ_LOW / 5 * 2 / 1000 },
{ 2, PLL_CPU_FREQ_LOW / 2 * 1 / 1000 },
{ 3, PLL_CPU_FREQ_LOW / 1 * 1 / 1000 },
{ 4, CPUFREQ_TABLE_END },
};
#endif
/* ladder freq is 500M Hz */
static unsigned int ladder_index = 2;
I see all kinds of sketchy looking code in this file and TODOs. The next thing that caught my eye was this in kernel/drivers/net/wireless/rdaw80211/rdacombodev/rda_5990_power_ctrl.c:
Oh look at that. There’s some kind of temperature throttling on the WiFi chip itself at 70 degrees. There’s also several different configurations commented out below it. That looks questionable and certainly one of the crashes comes from the wireless driver. This seems like a potential one here. Maybe this issue is actually with the WiFi temperature throttling?
That’s definitely one of them! If we’re lucky that one capability is generating all those different dmesg errors across various drivers. I suppose you could start by just trying to raise the thermal limit and see if it prevents you from hitting this. This would be at your own risk though messing with the temperature settings on the board though as I have no doubt that this board will let us fry it. None whatsoever.
The Raspberry Pi’s firmware would *never* let you do this as a comparison. You wouldn’t even be able to get to the code that controls this (it’s in Broadcom’s proprietary and closed source firmware which is distributed as a proprietary binary blob). It’s amazing that the thermal and temperature controls are so easily in reach on this board. So are the clock speeds and other things you can only dream about modifying on other boards (unless they give you a special way to control certain frequencies like the Raspberry Pi which is with overlays and config parameters). On this board it’s literally right in the source code and there is nothing else really going on.
Sparques
2 years ago
Thanks for the info / guide on bluetooth. I was able to connect to a Nintendo Pro Controller and got a /dev/hidraw0 interface like I wanted! I think I’ll try integrating the bt_init into the in-kernel driver so it should Just Work.
I’m custom configuring and compiling my kernel in an attempt to get everything working while stripping out all the stuff I don’t need. I don’t have USB working, but I think I’m close. I think one of the reasons why all the RDA support isn’t in upstream kernel is that it wasn’t added correctly. It’s possible to configure the kernel and then it won’t compile because of missing dependencies–i.e. the RDA specific additions don’t specify their dependencies and conflicts correctly.
Eventually I’d like to port all the RDA-specific bits of code to a modern kernel version, (looking at 5.19.9, latest stable) but for now I’m just trying to get the 3.10.62 one from Orange Pi fully working.
I’m also doing a custom-ish userland–I started with the Alpine mini-root filesystem, added OpenRC and other sundries. For my use cases, I don’t really need to boot into a normal R/W root, so I have my whole userland as an initramfs. Pretty neat, not including the compressed kernel image, my rootfs is ~29MB and the compressed initramfs is 11MB. At boot with dbus, bluetooth, and getty running on ttyS0, I’m using 7MB of RAM.
Welcome and thanks for dropping in and leaving your experience! That should absolutely work. I don’t think there’s any reason you couldn’t do the same thing in the kernel!
That makes sense about the RDA support. It definitely has a lot of issues with build flags even in their current iteration as enabling many of them will break building (although maybe this is the same issue you’re talking about but it’s definitely a problem even on this 3.X kernel). I know that the upstream support for the i96 at the very least doesn’t map the SD card storage at all or seem to work with it.
It seems like a good starting point would be the upstream kernel and then adding in the RDA bits that it absolutely needs to work even on the newer kernel (which sounds like what you’re thinking of doing potentially, I’d be fascinated to see what happens if you end up trying this). I think this kernel porting project could end up being both easier than people think but also hard in some tricky and unexpected ways. I’d imagine most of the support needed is in upstream. The storage seems to be a real sticking point though and like it for sure needs some proprietary (or at least not upstreamed) RDA bits.
If someone figured out how to knock out / map the storage (and if all of the other i96 bits worked for the most part) this might not end up being too crazy other than that. Each component on the board is potentially a rabbit hole though where you’d need to port additional drivers. It’s a question of whether this ends up being 2-3 things I suppose or whether it ends up being two dozen components or more that you have to port. A lot of people have tried to go down this road with this board for many years with the kernel and they’re scarcely ever heard from again unfortunately and they don’t really tell the story of what went wrong (but I’d imagine porting the drivers might have some complications they’re getting stuck on).
You’re basically exactly where I am at with the kernel on this project. I wanted to get all of the fixes in we could for now. If there was ever a version 2.0 release of this image though it would be when/if we are able to jump it to a newer kernel. That would be worthy of a major release jump to 2.0 (and it would also give the option of leaving the original Orange Pi kernel as the 1.X branch of the project in case people experience weird kernel issues on the newer one). The custom userland sounds pretty cool and like it would fit on the NAND partition as well for the i96 fairly easily!
Yup, this kernel code is a mess. There were some comments that were not marked as comments (how???) and I just had to add some EXPORT(); macros to get the thing to compile. Once I’m reasonably confident I have fixed everything I can, I’ll publish a diff or something.
Sounds fantastic, I look forward to learning what you find! If you run into any parts that are major sticking points that would be useful information as well. I feel like it should be possible but there’s so many people that have tried and failed to port this kernel for almost the entire life of the board.
Perhaps they discovered that drivers need to be ported and weren’t necessarily expecting that. The fact that you are starting with an understanding of essentially what this is going to take may set you up for success here where others have failed. Many of them had probably done similar things on other boards before not realizing that for this one it’s going to get quite low-level and in-depth compared to almost any other board that this could be tried on. Best of luck and let us know what you find!
Marco
2 years ago
i discovered something disturbing at my gf place while testing the orangepi i96, i dont have an uart-usb adapter latlely so i can just use the wifi, the wifi is pretty unstable as we already know, but now i discovered something i dont understand already
lets say iam connected via wifi and trying to download a big file with multiple connections over axel the download accelerator, the download doesnt even start with multiple connection, but thats enough to jam the whole wifi.
no device is able to connect locally or externally (internet) while the download accelerator (axel) is running.
i have to check that at my place home, but this doesnt shed light on the wifi chip….
That is pretty interesting. Do you have the WiFi regulatory country set? I’m guessing yes for sure or you’d probably be seeing a bunch of crda related messages in dmesg like it used to have before without that set.
It’s wild that it’s functioning as a jammer basically. I’m trying to think how that could happen. Maybe if the signal is low enough it’s flooding the airwaves with repeated packets? Those are some interesting observations though. It could actually be crashing/breaking something on your router potentially if it’s buggy enough. Definitely let me know what other issues you spot when using it as I have no doubt there’s probably further WiFi fixes that could be done!
That is very interesting actually. I suspect the WiFi card is probably doing something wrong but that only certain routers will choke or crash on it. I have a Unifi network setup here with several access points and I haven’t been able to reproduce this but since I have multiple radios it really wouldn’t be possible for the Orange Pi to jam all of the channels (it doesn’t have enough radios for it, when you try to jam and intercept signals from the remote to unlock your car as an example you need a second radio for jamming basically). In fancier networks this would just trigger the traffic to go over a different radio or even access point automatically.
It should be able to only jam one radio with the onboard capabilities in other words and I think this may be what is coming into play here. This would be possible on a single router though as there is a limited number of radios available (as little as one on some consumer models). A lot of newer consumer models are starting to come with multiple radios though as well (and will have like 3-4 or more antennas, this is getting really common on mid-range to upper-range consumer routers). If it’s triggering some kind of software or firmware issue in the other router this could possibly happen no matter how many radios they have.
If it is some kind of jamming though I’m guessing that router only has one radio and so the entire rest of the network stops if it’s being basically bombarded with the Orange Pi. If your router has 3-4 antennas on it though or you know it for sure has additional radios that may be why you can’t reproduce it (the same as me). It might still be getting jammed. It just doesn’t matter because your network may have additional radios or access points to use but a lot of the free ones the ISP gives you or ones that are 5+ years old likely will not have these capabilities. This would just mimic a typical busy network basically (theoretically) where the radios are busy due to legitimate traffic (rather than whatever bug the Orange Pi is triggering).
I was able to get your additional Bluetooth change to fix the MAC address in as well, thanks for submitting that PR!
Hi,
What do you think about external hub connected to built-in usb port? By default external usb hub is disabled 🙁
Below you can find the information that I was able to find out
dmesg | grep hub showshub 1-1: ignoring external hub
(as a result from CONFIG_USB_OTG_DISABLE_EXTERNAL_HUB = y setting and usb/core/hub.c file )
if you want to delete this line from config, I warn you because another message will pop up
usb: kernel must blacklist external hubs (as a result from this file: usb / musb / musb_core.c)
Here I’m stuck and have no idea where to look further
Is it possible to get usb hub working?
Hey Grzegorz,
I’ve tried this before but it’s definitely not that simple:
1441 if (MUSB_CONTROLLER_MHDRC == musb_type) {1442 musb->is_multipoint = 1;
1443 type = "M";
1444 } else {
1445 musb->is_multipoint = 0;
1446 type = "";
1447 #ifndef CONFIG_USB_OTG_BLACKLIST_HUB
1448 printk(KERN_ERR
1449 "%s: kernel must blacklist external hubs\n",
1450 musb_driver_name);
1451 #endif
1452 }
It looks like it doesn’t even run that check unless you don’t have a controller that supports multipoint. This makes sense because when Marco plugs in a battery (leaving the microUSB port available to be used) it can still only control a single device.
In rda_config_defaults.h:
#ifdef CONFIG_MUSB_HCD#define MUSB_NO_MULTIPOINT
#define CONFIG_CMD_USB
#define CONFIG_USB_STORAGE
#define CONFIG_FAT_WRITE
#endif
There is multipoint specifically disabled again with define MUSB_NO_MULTIPOINT. In other words in this case it’s not that something is missing. It’s specifically shut off in multiple places and it doesn’t look like all controllers support this. This is actually shut off purposefully and it looks like it’s going to take more than that to remove it. Multipoint support would need to be enabled if that’s even possible with this device.
I can try this but the USB hubs aren’t just missing a kernel flag. There’s at least several places that need to be changed. There’s another one here:
static struct musb_hdrc_config musb_config = {.multipoint = true,
.dyn_fifo = false,
.num_eps = 16,
.ram_bits = 12,
};
Again here we have multipoint disabled. If I set that to true will it work? I honestly sincerely doubt it but I’m trying it. They *really* went out of their way to make this not work which means I’m guessing I’m going to get horrific crashes when it finishes building my test image here. It doesn’t look like one of those issues where they just forgot to turn a kernel flag on. There’s a lot of code to make those hubs not work in multiple places which strikes me as there’s probably a reason for it.
I’m building a test build with these changes but who knows how many more there are and what kind of errors I’m going to get when I plug in a hub. If I’m seeing weird VBUS errors and really strange errors in dmesg it means that the pins aren’t wired on the USB for this to work properly best I can tell!
EDIT: The USB won’t function at all with those attempted changes (with or without a hub).
Thanks for your response.
I think that usb hubs are disabled due to low powering capacity & to prevent powering too much usb devices (when you plug in sth like usb wireless card the sbc board turns off).
I’ve analyzed the RDA8810PL documentation (link at the end), in it is written:
“USB controller supports up to 15 ‘Transmit’ endpoints and/or up to 15 ‘Receive’ endpoints in addition to Endpoint
0” (Page 62) <– so it is multipoint. There are more informations about the USB controller but I don't understand them…
From what I could deduce and what you may already know, there is one physical connection to the usb port (there is 8 dip switch, where you set which port (microusb / usb A) has to be connected to the usb controller)
Btw, I appreciate your hard work 🙂
RDA8810PL.Smartphone.Application.Processor.V1.04.pdf – just look at page 62
rda8810 schematic – look at page 7 (left bottom corner – dip switch)
Hey Grzegorz,
I don’t think this is a kernel configuration problem. What is happening is that when you are disabling that setting you’re getting a different warning that is telling you that the hubs should indeed be blacklisted (but that now it’s telling you you have to do it yourself with blacklist files). In my last post I showed all the places where multipoint is disabled but it sounds like from the specs it should support it.
The warning/error is telling you that now you have to blacklist them manually yourself since the kernel parameter is turned off and it knows it shouldn’t be doing it. I fixed this and tried to enable them (including multipoint) and the USB won’t function at all. You can keep changing more flags potentially but I’ve tried this several times (including in my last reply to you) and the USB goes completely dead and nonfunctional.
Maybe it would be easier with a UART to serial adapter which I really need to pick up one of those as when the USB doesn’t function that breaks my ethernet to USB adapter as well. I could use the WiFi but the problem is I have to rebuild the kernel which means it’s a brand new image that hasn’t been configured for WiFi yet. I guess I could preconfigure it for WiFi when I build the image somehow (even if it’s through the chroot) but I’d have to come up with a way to do that as there isn’t one currently. I may be able to use the “Update Kernel” option from the i96 build menus if I first log in with a working kernel, then set up the WiFi and then just start updating kernels but getting the right tools would make this a lot easier / faster.
I’m pretty sure this is a hardware issue. My hub is also self-powered like this one (but I’ve tried plugging it in without it being self-powered leaving the power unplugged). In this thread they are saying that the USB spec is open to interpretation on this issue which leads to the problem if the manufacturers don’t take certain steps (outside of spec) to fix it. It’s not unique to the i96. My impression is this is also fixed with USB-C which is why you will have to go back around 5+ years to find any examples of this happening.
This issue has been different than all of the others. All of the others were just missing things for the most part. I don’t mean to be too cheeky toward Orange Pi here (who else has an actually available to order $6 board) but the original image is missing so much of the bare essentials that there’s just no way this is due to their excellent planning / power management. The original version of the image is too strong of evidence to the contrary (and borders on incompetence, some of tiny fixes we’ve made to this to make the board 5x better were so easy it honestly makes me mad they didn’t do it in the 5-6+ years this board has been out). This is either a mistake that requires a lot more fixes than I’ve realized to get it functioning (possible) or it’s because they needed to add something else to the board for this to work and they know that they didn’t.
If someone else wants to try they can absolutely give it a go. I’ve already tried this several times though and only end up with completely nonfunctional USB! It definitely seems like this is disabled for a reason in this case and unlike most things trying to enable it seems to actually make things break completely from my testing.
I thought this would be an easy one but I can honestly say I’ve tried to fix this more times and spent more time on it than issues that seem like they would be a lot harder to fix such as fixing the SD card and USB ports to both support high speed mode. I fixed those on the first try (not my first build/attempt but I mean the first time I sat down and tried to solve it I was able to eventually without giving up and going to do something else) and this issue I’ve tried and failed on probably 3-4 times (unusual, there’s nothing else that I’ve tried 3-4 times on this on that isn’t fixed, and it’s why I keep questioning if there’s a hardware/electrical component to this issue).
That being said it very well may be possible as a lot of other problems on this board that for sure looked like hardware limitations/issues ended up being fixable 100% (as in like almost every issue people talk about with the i96). This is a tough one though and I’m still in the stage of trying to determine if this is indeed a hardware limitation or if it’s just more crazy image issues. If anyone has any idea how to work around this I’d 100% add this into the image if it’s possible!
I want to use this board as a webrtc client, the offical img existed many problems and already stoped maintenance several years ago, i had all most drop it until see this blog.
I tried to use the usb sound card on this board, but it could not work normally.
When i inserted the usb sound card into the board, dmesg log show:
[ 2734.458007] musb-hdrc musb-hdrc: VBUS_ERROR in a_wait_bcon (98, VALID), retry #1, port1 00000100[ 2735.932495] usb 1-1: new full-speed USB device number 3 using musb-hdrc
[ 2736.086547] input: C-Media Electronics Inc. USB PnP Sound Device as /devices/platform/musb-rda.0/musb-hdrc/usb1/1-1/1-1:1.3/input/input2
[ 2736.095520] hid-generic 0003:08BB:2902.0002: input,hidraw0: USB HID v1.00 Device [C-Media Electronics Inc. USB PnP Sound Device] on usb-musb-hdrc-1/input3
I used the cmd "aplay -l", the usb sound card device could not be found, just show the rda sound device on this board:**** List of PLAYBACK Hardware Devices ****
card 0: rdasoundcard [rda-soundcard], device 0: rdaaud-stream rda-codec-dai-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: rdasoundcard [rda-soundcard], device 1: rdavoice-stream rda-voice-codec-dai-1 []
Subdevices: 1/1
Subdevice #0: subdevice #0
I don’t know about USB drivers, is it existed any problmes?
Any help will be very appreciated!
Hey Jack,
I can definitely enable CONFIG_SND_USB in the image. This should solve at least some of it and with any luck it will just work with this change without needing additional drivers.
Can you give version 1.18 a try and see if it will work on that version?
Image version:Legendary_OrangePi_i96_debian_bullseye_server_v1.15
Hey Jack,
I just made this change. You will need to download 1.18 from the GitHub releases section and reimage it to see if this change will work! I definitely still can’t guarantee it will work with this kernel flag enabled.
From what I can tell it definitely won’t work without it though but without having the sound card personally we’ll have to see if it’s this simple or not. Let me know what you find either way but from my research the fact that it’s showing in lsusb correctly is a good sign that it might only take this kernel flag change!
I will try it, thanks!
I had tested the latest version 1.18, the usb sound card can’t be found at the List of PLAYBACK Hardware Devices:
root@orangepii96:~# aplay -l**** List of PLAYBACK Hardware Devices ****
card 0: rdasoundcard [rda-soundcard], device 0: rdaaud-stream rda-codec-dai-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: rdasoundcard [rda-soundcard], device 1: rdavoice-stream rda-voice-codec-dai-1 []
Subdevices: 1/1
Subdevice #0: subdevice #0
Hey Jack,
Thanks for testing this! I couldn’t even begin to guess what is wrong without having one of these devices. If you are able to build the kernel I’m sure we could figure out which one it’s missing most likely!
I had prepared the ubuntu envirement , I will try to build the kernal on my vmware machine.
Hey Jack,
Oh excellent, that should be exactly what we need. You may want to go into the kernel config menus by going into OrangePiRDA/kernel and running
make ARCH=arm menuconfigThis will let you see the kernel options. Definitely let us know what you find!
you could try to add
CONFIG_SND_DRIVERS
but i dont know if that would help
Hey Marco,
I agree, there’s a dozen other flags it could be, there’s also a CONFIG_SND_USB_AUDIO that isn’t even in this kernel config file but other places mention it. I can’t just start guessing though without having one of the devices. Almost nothing in this image has been as easy to fix as flipping a single switch (as you’ve ran into as well). It could be a lot of things for sure!
i should have one of those usb soundcards somewhere, if ill find it, i will try to test it and report
Hey Marco,
That would be appreciated if you get a chance. I have a lot of USB accessories but this is unfortunately not one of them at the moment!
Hey James,
Got the boards from AliExpress. It only 2 weeks, which was surprising with all the supply chain stuff you hear about. Installed your image, worked great. So, I did a bit of an ID10T move. I AssUMed that I could use a Raspberry Pi camera on one of these boards. Well, I didn’t fry the board, but it got super hot. Haven’t tried the Pi Cam (nervous).
Anyway, I guess I need one like the link. Anybody tried one of these?
Hey Dustin,
Welcome back, that is excellent! I got my couple that I ordered around the same time as you did here on my desk. The heatsinks really, really help with the heat for sure. I have a link in this guide to the ones I’m using (which has a shape that matches the rectangular shape of the i96 pretty closely in that GeekPi set) but you don’t need anything too crazy or specific. You will want to have something though for sure.
The powered fan setup would be another level up from this but I’ve only heard of a couple of people going that far yet. I’m still just on the heatsink system myself with no powered fan at the moment. I definitely don’t recommend running it bare because even with the heatsink it’s possible to overheat it (but it’s much harder, as in installing 800+ packages from apt at once kind of a load required to have a chance of overheating it).
I should note that this will depend on ambient temperature as well. My Orange Pi sits on a shelf in a relatively cool air-conditioned basement in the dry Utah desert (with 30 solar panels on the roof to manage energy costs) so my heatsink air cooling is pretty ideal compared to a lot of other places where you may want to try a powered fan setup (think one of those tiny fans that can be powered by the GPIO pins for example). The person who donated my original Orange Pi i96 board actually did this and said they used a clip to hold the fan in place over the heatsink.
Whether the overheating/crashes can be fixed or not (other than at least by applying a heatsink or even using a powered fan setup) is still under investigation. There’s several approaches that could be taken to fix it. We could write our own throttling code and adjust the frequencies down more aggressively to keep it from overheating potentially. It may be bugs that are causing some heat related crashes too as we have found bugs in almost every place we’ve looked (and been able to fix nearly all of them identified so far collectively as a community).
The camera module is interesting. I actually have not heard from anyone who has used it yet with the i96. I did find one post here related to it. They said it didn’t work for them and then they gave up. That is the only thing I could find on the internet.
Therefore my conclusion would be that I would not expect the official camera module to work out of the box unfortunately and I don’t see any examples of people who got it working yet. Could it be fixed to work with it? Yes, I think it could definitely be fixed although I do not have one so it would probably need to be someone that has one that debugs/fixes the driver. I’d definitely be willing to integrate any fixes for the camera that are found into the image!
Alrighty, once again, I’m throwing caution to the wind and I’m going to ordering up some cameras. Assuming these guys don’t have H264 encoders, I’m hoping they can handle some light MJPEG compression. 🙂
On an unrelated note, I was getting -32dBm WiFi signal (reported by wavemon), which is pretty amazing. (My phone is currently sitting at -49dBm) The throughput speed was only like 250-750K/s which is disappointing. I’ve tried serving a file off both SD and USB using SFTP and FTP, no difference. I have a EERO 6 mesh router and my desktop is wired GBE. Generally, the shell is unresponsive, so I think something is up. Any ideas?
Hey Dustin,
This is an issue with the wireless for sure. If you try using a USB to ethernet adapter you will not experience any of those issues for sure. I’m working on improving the wireless driver but I’m not a WiFi driver expert so it may take some time.
If you have a USB to Ethernet adapter to test with I highly recommend giving it a go just to compare the difference. Hopefully the throughput issues can be fixed!
Hi James,
I’ve got the spi2 working with spi_gpio driver at 1Mbps. It won’t be a rapid port.
For this, I’ve modified devices.c and the script gpio_fixup.sh to assign back the SPI2 pins to gpio function for the spi_gpio driver to work.
I’ve also modified the default spidev port in the WiringPi lib and the pin labels in the gpio tool.
I’ve declared two slaves to have spidev2.0 with CS pin A10 ( Header 16) and spidev2.1 with CS pin A6 ( Header 12)
All is committed under :
OrangePi-I96-Work.git ( OrangePIRDA/kernel and OrangePIRDA/output/rootfs)
WiringPi.git
I’ve tested the spi communication using physical loop and read some registers on an MCP2515 CAN transciever, but I failed to have any lcd display work, There are still things to correct in the framebuffer driver I downloaded.
Now the good news is that we could have CAN communication, pin voltage won’t be a problem, the i96 outputs nearly 2.9 V which seems to be compatible with MCP2515. There is a road to go to add socket can and link an mcp2515 driver to the spi port.
Hey MZA,
Excellent work! The original example I linked to uses the fbtft driver. They actually have to hard link to it in the source code. That person didn’t use spidev at all basically. They actually include the fbtft header even inside that file (does not exist before, and my version does not do this, I did not link the fbtft driver like this person’s example and didn’t go that far).
I don’t think we’re going to get it to be much better than this. It’s always going to require modifying the kernel to do this I think. Why? Because the Raspberry Pi uses device trees and overlays to do this and the Orange Pi board doesn’t support them. It will have to always be hard modified to use whatever driver will support the device you are using. I don’t think this can ever work exactly like the Raspberry Pi because of this lack of device trees and overlays. I could be wrong but I’m not sure how we eliminate having to hard compile drivers into the source (or a bunch of loadable kernel modules) without this piece.
I guess we could just keep adding drivers that people keep using to the image but even if we do that it will probably support a tiny fraction of the screens available out there relatively speaking unless we want to put dozens or more drivers included in the kernel for each different screen type. That might be possible via modprobe with optional “m” compiled kernel modules. Maybe there’s more overlap in the screen drivers than I’m thinking though and that if we added a few it would cover most of the screens out there. I’m actually not sure how many different types of drivers are available but I have yet to see anyone trying to use the same one as anyone else who has tried it before (with admittedly few examples).
I’m definitely going to get these all packaged up and released. Thanks for doing it! I think it’s as good as we can get it and I suspect if anyone wants to use a screen they will have to modify the kernel for every single different screen type due to the lack of overlays / device trees being used in this kernel! This is being packaged as 1.17 and should be up shortly!
James,
I did add the tfbt drivers to the kernel tree, added the device to the board_info etc, the ST7735R driver uses spi transfer and needs either native rda-spi driver or gpio-spi. I set it to spi-gpio like did the russian guy.
Unfortunately, I did not get it display anything, the /dev/fb0 was mounted and every thing seemed OK.
I also tested another e-Ink display without success.
A least, I swapped to the MCP and read a rigister to confirm the spi was working.
Hey MZA,
Got it, thanks for clarifying! That’s definitely pretty interesting. I was able to get everything integrated into 1.17 here I believe. I wonder why it’s still being stubborn here!
Could the RDA display out be interfering with this somehow? From what I can tell that is always running and has those nasty timeouts every time the board boots (for the backlight service I think for the RDA display output). It just sounds to me like you have everything right here and that something else is going on.
Are you seeing any dmesg activity from the rda display module indicating it might be interfering or trying to map the wrong devices that are related to that output and not yours? Or perhaps that it’s even trying to talk to it or send it commands from the driver (hopefully not this). Even on my system in dmesg:
rda_fb_probe_panel lcd panel'name(mcu_ili9806g) doesn't match of cmdline![ 0.642944] ERROR no lcd panel driver init
[ 0.643432] rda_fb_probe_panel lcd panel'name(mcu_ili9806g) doesn't match of cmdline!
[ 0.709045] rda_sensor_video_probe: priv=ce731710
Whatever it’s doing it looks broken. I just wonder if it’s interfering with what you’re trying to do somehow and this video driver is for sure loaded.
Hey James,
I’ve got the same messages, I don’t see any lcd activated and I checked the datasheet, they’re separate from SPI pins.
I’m back to rda-spi driver without DMA and working with the mcp2515 CAN transciver, code and execution seems coherent but the port gets stuck after 3 bytes transfer all RX become 00.
With the gpio-spi driver the MCP2515 device is probed, I can have the can0 interface, bring it up, set its bitrate but then no TX, no RX and no indicators. I think spi-gpio does’nt work with this MCP, the mcp2515 driver uses spi transfers that cannot be mapped obviously to spi-gpio. I could not see where to tell the mcp driver which gpio chip select pin to use. I’ll continue some time my unfortunate effort to bring this CAN.
Hey MZA,
Thanks a ton for your work on this issue! You’ve gone further and fixed more things along the way than anyone could possibly have asked or hoped for.
I think despite the problems with the CAN that you have probably enabled the use of many other SPI interfaces potentially through your work. I know you have electrically verified many connections using spidev with your changes included.
I really would like to get some simple SPI devices for myself to start testing with (not just for this board but with some of my other boards as well). I wonder if you could get the much simpler SPI devices functional with your existing work as is. I suspect (with the right drivers or for simpler devices that you may just use raw input/output with) that many types of devices would in fact work now with your changes.
Definitely keep me posted, I always love to hear what you’re finding!
i have been tinkering, trying to get the wifi working better and i dont know for 100% if this affects the wifi-ability, but for me it did.
i set all baudrates which are set from 921600 to 115200, even on uboot. uboot doesnt seem to bother about the new baudrate, so still dont know if i can set it there (i set it in all config files i could find but it still runs on 921600).
since then my wifi is stable enough to get roughly 2.3MB/s over wifi, and bluetooth seems also to work smoother.
this could be a false positive tho but i have the feeling iam not imagine it.
i can even have multiple ssh sessions open without random freezings on the sessions, in adittion i am downloading a file with fullspeed (2.3MB/s), and the shells are still available.
i had so much more problems with the wifi before that, can anyone test that out?
files i changed the baudrate in were
kernel/drivers/tty/serial/rda_uart.cuboot/board/rda/common/uart_test.c
uboot/drivers/serial/serial_ixp.c
uboot/include/configs/rda_config_defaults.h
external/chips/RDA/bootarg/boot.scr
external/chips/RDA/bootarg/boot.cmd
include/configs/rdaarm926ejs.h
include/configs/rda_config_defaults.h
and i also commented out power managment for wifi device
//#define WLAND_POWER_MANAGERin drivers/net/wireless/rdaw80211/rdawlan/wland_defs.h
(but later)
sometimes when bluetooth “scan on” is set, wifi still drops and “scan off” is not applicable, then i use “power off” to disable bluetooth
and after testing further file transfer (download) on the pi, i discovered that the pis speed will drop very quick and drastically, when the cpu is getting hotter, so a heatsink is a musthave
i added cpufrequtils as a pullrequest, after setting the cpugovenor to performance, i didnt receieved that much of a drop after that. the load is still at 2, but the connection seems to be stable and continiously over 2MB/s
after downloading a ton of gigabytes, i ran into the following error.
Hey Marco,
Interesting findings! That appears to be a very old bug in the WiFi driver that was never solved (or it’s heat related, more on that in a moment). I don’t see that anyone has ever even tried to solve it or got an answer to why it happens:
#1
#2
#3
I agree about the heatsinks. I’ve always had them on mine and I definitely recommend them in the guide as well. They definitely do help with the stability. It wasn’t too hard for me to crash it out (even apt updates could do it back when you had to install thousands of them to update the main image). I could consistently crash it by installing all the apt updates at once on the old image. There was about a 50% chance it would crash when doing this and if I didn’t let the Orange Pi sit before trying again that chance went up to 100%. That was with me having the heatsink from the very start. If you touch the heatsink when it crashes it will be quite hot. I wonder if this is just heat related kernel panic. I haven’t seen a crash like this for a while because I don’t have to do any very intensive tasks on the new image anymore since all updates are already done.
Performance mode should be the hottest of all the modes. In that mode it should never downclock the CPU (even when it’s doing nothing). Setting it to ondemand or powersaver would probably be the ones that would drop the temperature. You probably want to let this hot board downclock. I bet you could consistently crash it on performance mode even with a heatsink. You’d need a powered fan probably for it to be stable on performance would be my guess.
These crashes are all over the place in dmesg. Is it the WiFi driver? Is it the SDIO driver? The answer appears to be “yes” to both of those questions. There’s crashes related to all of them in here (and the other threads people posted). I really think you are on the right track with the thermals here. The crashes strike me as the board is getting unstable when it’s too hot. I’d love it if this was just a driver bug but your testing seems to point toward load / thermals so far. It doesn’t seem like there’s a specific action that triggers it. It seems like once there’s enough activity to get too hot it does trigger but those are just my initial impressions!
I should also mention it could be both. It could be both a driver bug *and* thermally related. Perhaps we’re reaching a temperature that is triggering buggy driver code. Maybe it is trying to do some sort of throttling and the code that controls it is completely broken. That would not surprise me in the slightest so I figured it would be worth mentioning as well!
If there wasn’t some sort of driver component to this I wouldn’t expect to have been able to find crashes so similar to yours. If the CPU just went completely crazy at a certain temperature I would expect anything to happen and for the errors (and behavior itself) to be pretty wildly different each time as you would expect from a completely malfunctioning component. This does seem to be breaking in a consistent way which suggests to me it can be fixed or at least controlled / alleviated rather than just say the CPU can’t run stable at a certain temp (which should look different than this, I think whatever we are triggering is probably the “warning” level or definitely way below the point where things go completely off the rails). The board is definitely crashing out before we are melting it or even getting high enough for really weird/inconsistent things to start happening it so it seems like something before that point is being triggered and then crashes out.
Hey Marco,
I found several interesting things. I did a search in VSCodium for files including the name *rda* that have “temperature” in them. In kernel/drivers/cpufreq/rda-cpufreq.c we have:
#ifdef CONFIG_RDA_AP_PLL_FREQ_ADJUST/*TODO - if more high temperature message keep coming, highest freq can be
* set lower
* */
static struct cpufreq_frequency_table low_freq_table[] = {
/*
* CAUTION:
* CPU frequency range can NOT be too large, otherwise VCORE
* fluctuation might impact DDR.
*/
{ 0, PLL_CPU_FREQ_LOW / 3 * 1 / 1000 },
{ 1, PLL_CPU_FREQ_LOW / 5 * 2 / 1000 },
{ 2, PLL_CPU_FREQ_LOW / 2 * 1 / 1000 },
{ 3, PLL_CPU_FREQ_LOW / 1 * 1 / 1000 },
{ 4, CPUFREQ_TABLE_END },
};
#endif
static struct cpufreq_frequency_table *cur_freq_table = &(freq_table[0]);
/* ladder freq is 500M Hz */
static unsigned int ladder_index = 2;
I see all kinds of sketchy looking code in this file and TODOs. The next thing that caught my eye was this in kernel/drivers/net/wireless/rdaw80211/rdacombodev/rda_5990_power_ctrl.c:
#ifdef WLAN_USE_CRYSTAL{0x17, 0x0990},
{0x18, 0x049F},
#else
{0x17, 0x0910},
{0x18, 0x249F},
#endif
{0x19, 0x3C01},
{0x1C, 0x0934},
{0x1D, 0xFF00},//for ver.D20120119for temperature 70 degree
//{0x1F, 0x01F8},//for ver.c20111109
//{0x1F, 0x0300},//for burst tx ����
Oh look at that. There’s some kind of temperature throttling on the WiFi chip itself at 70 degrees. There’s also several different configurations commented out below it. That looks questionable and certainly one of the crashes comes from the wireless driver. This seems like a potential one here. Maybe this issue is actually with the WiFi temperature throttling?
actually rda_5991g_power_ctrl.c is the correct file for us.
Hey Marco,
That’s definitely one of them! If we’re lucky that one capability is generating all those different dmesg errors across various drivers. I suppose you could start by just trying to raise the thermal limit and see if it prevents you from hitting this. This would be at your own risk though messing with the temperature settings on the board though as I have no doubt that this board will let us fry it. None whatsoever.
The Raspberry Pi’s firmware would *never* let you do this as a comparison. You wouldn’t even be able to get to the code that controls this (it’s in Broadcom’s proprietary and closed source firmware which is distributed as a proprietary binary blob). It’s amazing that the thermal and temperature controls are so easily in reach on this board. So are the clock speeds and other things you can only dream about modifying on other boards (unless they give you a special way to control certain frequencies like the Raspberry Pi which is with overlays and config parameters). On this board it’s literally right in the source code and there is nothing else really going on.
Thanks for the info / guide on bluetooth. I was able to connect to a Nintendo Pro Controller and got a /dev/hidraw0 interface like I wanted! I think I’ll try integrating the bt_init into the in-kernel driver so it should Just Work.
I’m custom configuring and compiling my kernel in an attempt to get everything working while stripping out all the stuff I don’t need. I don’t have USB working, but I think I’m close. I think one of the reasons why all the RDA support isn’t in upstream kernel is that it wasn’t added correctly. It’s possible to configure the kernel and then it won’t compile because of missing dependencies–i.e. the RDA specific additions don’t specify their dependencies and conflicts correctly.
Eventually I’d like to port all the RDA-specific bits of code to a modern kernel version, (looking at 5.19.9, latest stable) but for now I’m just trying to get the 3.10.62 one from Orange Pi fully working.
I’m also doing a custom-ish userland–I started with the Alpine mini-root filesystem, added OpenRC and other sundries. For my use cases, I don’t really need to boot into a normal R/W root, so I have my whole userland as an initramfs. Pretty neat, not including the compressed kernel image, my rootfs is ~29MB and the compressed initramfs is 11MB. At boot with dbus, bluetooth, and getty running on ttyS0, I’m using 7MB of RAM.
Hey Sparques,
Welcome and thanks for dropping in and leaving your experience! That should absolutely work. I don’t think there’s any reason you couldn’t do the same thing in the kernel!
That makes sense about the RDA support. It definitely has a lot of issues with build flags even in their current iteration as enabling many of them will break building (although maybe this is the same issue you’re talking about but it’s definitely a problem even on this 3.X kernel). I know that the upstream support for the i96 at the very least doesn’t map the SD card storage at all or seem to work with it.
It seems like a good starting point would be the upstream kernel and then adding in the RDA bits that it absolutely needs to work even on the newer kernel (which sounds like what you’re thinking of doing potentially, I’d be fascinated to see what happens if you end up trying this). I think this kernel porting project could end up being both easier than people think but also hard in some tricky and unexpected ways. I’d imagine most of the support needed is in upstream. The storage seems to be a real sticking point though and like it for sure needs some proprietary (or at least not upstreamed) RDA bits.
If someone figured out how to knock out / map the storage (and if all of the other i96 bits worked for the most part) this might not end up being too crazy other than that. Each component on the board is potentially a rabbit hole though where you’d need to port additional drivers. It’s a question of whether this ends up being 2-3 things I suppose or whether it ends up being two dozen components or more that you have to port. A lot of people have tried to go down this road with this board for many years with the kernel and they’re scarcely ever heard from again unfortunately and they don’t really tell the story of what went wrong (but I’d imagine porting the drivers might have some complications they’re getting stuck on).
You’re basically exactly where I am at with the kernel on this project. I wanted to get all of the fixes in we could for now. If there was ever a version 2.0 release of this image though it would be when/if we are able to jump it to a newer kernel. That would be worthy of a major release jump to 2.0 (and it would also give the option of leaving the original Orange Pi kernel as the 1.X branch of the project in case people experience weird kernel issues on the newer one). The custom userland sounds pretty cool and like it would fit on the NAND partition as well for the i96 fairly easily!
Yup, this kernel code is a mess. There were some comments that were not marked as comments (how???) and I just had to add some EXPORT(); macros to get the thing to compile. Once I’m reasonably confident I have fixed everything I can, I’ll publish a diff or something.
Hey Sparques,
Sounds fantastic, I look forward to learning what you find! If you run into any parts that are major sticking points that would be useful information as well. I feel like it should be possible but there’s so many people that have tried and failed to port this kernel for almost the entire life of the board.
Perhaps they discovered that drivers need to be ported and weren’t necessarily expecting that. The fact that you are starting with an understanding of essentially what this is going to take may set you up for success here where others have failed. Many of them had probably done similar things on other boards before not realizing that for this one it’s going to get quite low-level and in-depth compared to almost any other board that this could be tried on. Best of luck and let us know what you find!
i discovered something disturbing at my gf place while testing the orangepi i96, i dont have an uart-usb adapter latlely so i can just use the wifi, the wifi is pretty unstable as we already know, but now i discovered something i dont understand already
lets say iam connected via wifi and trying to download a big file with multiple connections over axel the download accelerator, the download doesnt even start with multiple connection, but thats enough to jam the whole wifi.
no device is able to connect locally or externally (internet) while the download accelerator (axel) is running.
i have to check that at my place home, but this doesnt shed light on the wifi chip….
Hey Marco,
That is pretty interesting. Do you have the WiFi regulatory country set? I’m guessing yes for sure or you’d probably be seeing a bunch of crda related messages in dmesg like it used to have before without that set.
It’s wild that it’s functioning as a jammer basically. I’m trying to think how that could happen. Maybe if the signal is low enough it’s flooding the airwaves with repeated packets? Those are some interesting observations though. It could actually be crashing/breaking something on your router potentially if it’s buggy enough. Definitely let me know what other issues you spot when using it as I have no doubt there’s probably further WiFi fixes that could be done!
yes i have. its odd because i cant reproduce that error at my home, just am my gf place this error occures
Hey Marco,
That is very interesting actually. I suspect the WiFi card is probably doing something wrong but that only certain routers will choke or crash on it. I have a Unifi network setup here with several access points and I haven’t been able to reproduce this but since I have multiple radios it really wouldn’t be possible for the Orange Pi to jam all of the channels (it doesn’t have enough radios for it, when you try to jam and intercept signals from the remote to unlock your car as an example you need a second radio for jamming basically). In fancier networks this would just trigger the traffic to go over a different radio or even access point automatically.
It should be able to only jam one radio with the onboard capabilities in other words and I think this may be what is coming into play here. This would be possible on a single router though as there is a limited number of radios available (as little as one on some consumer models). A lot of newer consumer models are starting to come with multiple radios though as well (and will have like 3-4 or more antennas, this is getting really common on mid-range to upper-range consumer routers). If it’s triggering some kind of software or firmware issue in the other router this could possibly happen no matter how many radios they have.
If it is some kind of jamming though I’m guessing that router only has one radio and so the entire rest of the network stops if it’s being basically bombarded with the Orange Pi. If your router has 3-4 antennas on it though or you know it for sure has additional radios that may be why you can’t reproduce it (the same as me). It might still be getting jammed. It just doesn’t matter because your network may have additional radios or access points to use but a lot of the free ones the ISP gives you or ones that are 5+ years old likely will not have these capabilities. This would just mimic a typical busy network basically (theoretically) where the radios are busy due to legitimate traffic (rather than whatever bug the Orange Pi is triggering).
I was able to get your additional Bluetooth change to fix the MAC address in as well, thanks for submitting that PR!