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!
RDA8810 Boot_ROM V1.6
HW_CFG: 0286
SW_CFG: 0000
Load EMMC
Open eMMC
EMMC OCR timeout
Open eMMC card Failed
Load EMMC Fail
Load SD
Open SD card
mcd_Open
Card is SDHC
Inserted Card is a SD card
mcd_Open Done
Loading image from SD card ................................................................................................Done
rda2 stand for dqs_prsel_preset
rda2=0 rda2=1 rda2=2 rda2=3 rda2=4 rda2=5 rda2=6 rda2=7
R R R R R * * R
Please check the result and choose the best one
final rda2= 1, rda2_old = 2
setup ddr vtt to 1
pll freq CPU = 988
pll freq BUS = 800
pll freq MEM = 260
Init DDR, flag = 0x0002, para = 0x00001338
32bit dll-on Mode ...
ddr2 phy init done!
format ctrl value: 22000202
address ctrl value: 30301
decode ctrl value: 10
dram init done ...
Done
What is happening with it? Does it boot? I only see down to set hostname to . which does look wrong. Does it not go any further past that point?
This is definitely not normal behavior. I’m guessing you need to clean that SD card off before imaging with something like the SD Card Association’s Formatting Tool (free). If it was imaged with btrfs or any type of networking file system ever then this is 100% the problem and the SD card association’s tool is the only way to fix it.
You may want to try V1.6 if you have a SPI device connected as I just fixed a lockup related to those.
I’ve definitely seen this a lot over the years on the Raspberry Pi but it happens with all boards / devices with certain types of partitioning. The SD card association’s tool should (truly) blank it for you and let you image the SD card correctly!
No worries at all, I had wondered if that happened! Let’s see what 1.6 does as I had to have been uploading it probably minutes after you downloaded 1.5.
Etcher should be fine. Just keep in mind Etcher doesn’t blank SD cards which is why previous partitioning can be a problem. For btrfs it’s almost impossible to erase it using normal tools as SD cards have basically hidden proprietary manufacturer partitions that are invisible to formatting tools and it seems to utilize these. The SD card association’s tool will clear out the “secret” manufacturer partitions and all of that.
The eMMC / SPI flash warnings in the boot sequence are normal. There are fixes for those out there but I haven’t merged them into this image yet (but I have for other things that throw similar nasty startup messages in dmesg / the terminal). It’s used for some unexpected things like storing the wireless MAC address (this is supposed to be stored on the SPI flash / NAND partition). Nobodies Orange Pi comes imaged with the proper partitions for it (this actually has a different fix for the wireless MAC address in it). That is what a lot of the startup messages are related to though.
The fix in this image actually writes your wireless MAC address to a file on the root partition. It’s at /data/misc/wifi/WLANMAC. Once you do your first startup it will have a file there with the MAC address in it. If you reimage the Orange Pi you can actually carry that MAC address file over if you want to to keep the same MAC address as your previous image.
I do plan on cleaning these up for sure. There aren’t too many left and I have seen people who have fixes for them in other images so this is definitely on the to-do list.
v1.6 booted – I don’t have SPI needs (right now 😉 seems to work – some findings on WiFi:
The wifi connected – once in moments and the next time it was at 830 seconds with these messages 15-30 seconds apart dropping onto the console: [ 770.773071] cfg80211: Calling CRDA to update world regulatory domain
I also found I had to start and enable resolved.service so DNS lookups would work: systemctl start systemd-resolved.service
systemctl enable systemd-resolved.service
That is interesting with the WiFi. I do not get the DNS issues when I use a Eth to USB adapter (which I always am). Is your DNS working even over WiFi then? How about your SSL? Orange Pi’s own instructions always bypass the SSL but maybe that is DNS related as well.
My /etc/resolv.conf looks like this:
orangepi@orangepii96:~$ cat /etc/resolv.conf
# Generated by NetworkManager
search jamesachambers.net
nameserver 192.168.1.85
nameserver 192.168.1.90
nameserver 192.168.1.91
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 192.168.1.1
That’s definitely all pulled down by my network it looks like. I have definitely noticed that you cannot make SSL connections on the WiFi though but maybe this is resolved related. I’ll enable this service within the image!
The WiFi is absolutely broken on this board and I do not use it personally. Your findings make me wonder though how much of that might be related to the image / kernel and isn’t actually the WiFi chip or any of that! Maybe we can get it working a lot better than it is still!
I’m not sure how you’d change your regulatory domain on the Orange Pi. This is a thing though. Everyone’s will be different so I can’t set one in the image. On the Raspberry Pi you need to set this or 5GHz WiFi won’t even work basically. Can you try the following to set your wireless regulatory domain:
iw reg set US
Replace with your own country code and let’s see if that resolves that!
The Wifi will work and then not: I won’t be able to resolve github.com , SSL won’t work, and then it will start working and clone a repo…
I stopped systemd-resolved.service and DNS still worked – so it may have been coincident turning resolved on helped…
I set the US country as you advised – I still got a message. Now I am exploring maybe antenna orientation/signal strength? So a better wifi connection and ‘things’ work better (no messages, names resolve, SSL is good)? I’ll plod on with wifi – at the moment it is working 😉
Very interesting. I’ve made some changes and fixes from your feedback as well as some other general cleanup in 1.7. I added the orangepi user to some missing groups as well as some other service related fixes. I fixed a service startup issue in e2scrub_all and actually removed hostapd. It may have been hostapd crashing over and over that was impacting the WiFi so I think it may be worth trying the new version.
V1.7 is giving me a clean startup with:
sudo systemctl status
In other words there are no failed services starting up on the new version. If you’re willing I’d be curious if the hostapd service crashing over and over was impacting this and if 1.7 improves things!
Steve Gotthardt
The antenna may be the weak point – I used wavemon to monitor signal strength and the signal-strength jumps all over with even slight movement. I moved my i96 to within 10 feet of router and it might be better at connecting (I was around 30ft) but I still get these:
Great observations. This makes sense to me. The reason I say that is that I honestly have not had nearly the trouble with the wireless as other people. It’s not perfect but I have left this image running on it for days at a time and still been able to reconnect wirelessly.
My network is not typical though. I have 6 Unifi access points mounted all over the place throughout the house including a couple within line of sight of the device. The network conditions couldn’t be more ideal. I’d imagine if someone just has like, a normal wireless router, that this weak antenna may barely be able to hold a link. This seems to be part of what you’re uncovering here for sure as these logs are clean and not filled with errors for this.
Did you get a chance to try with V1.7? It may not have any impact if you’re right but the hostapd service was starting and crashing over and over again before and it’s possible that may have been causing the wireless to drop (or some of it, maybe part of the DNS?). The hostapd is supposed to configure your wireless card as an access point other devices can connect to. It had no hostapd.conf so it was just crashing over and over so I removed the broken base package (since if someone still wants to do this if they install it fresh from apt they will configure a working hostapd.conf with it).
Your CRDA looks good. It’s definitely happy with that now. I don’t see any errors. I think you’re right. It looks like standard disconnects related to signal strength to me in that output as well (there’s no errors which is because it thinks you’re probably moving away from that base station to transition to a different one in range which is normal behavior).
In other words since we are just getting a “CTRL-EVENT-DISCONNECTED” signal strength is by far the most likely explanation. This is just a normal notice/event rather than a warning/error since most mobile/IoT stuff is designed to be able to move (or at least has those capabilities available with addons). People could just be moving away from the access point on a mobile device for example and then you would expect it to disconnect and transition to either another base station or another network in the range of where they are moving to.
Do you have a higher quality antenna you could test with it? The connectors on it should fit antennas from other SBCs or IoT devices if you have any other ones around known to be of higher quality (probably anything else will be better realistically than what they gave us on a board at this price point). That would be a worthy test to see how it impacts the stability and if you can possibly maintain a stable connection for a long period of time! If we get some evidence that it can hold a stable connection with an antenna swap I’m sure there are probably <$5 parts available on Amazon and AliExpress that would improve this signal dramatically.
Steve Gotthardt
I am running v1.7
I was able to clone and start the klipper3d repo (my main use case for the i96) in one try!
I am going to research (connector type varies) antenna and order some – I see many on Amazon
Ahh, I may be able to be of assistance there! Specifically you are looking for a U.FL connector antenna. There are actually a lot of adapters to take it to a larger antenna size too (in fact I’d say there are more adapter options than antenna options but you will see what I mean). These types of antennas/connectors are super common on drones especially.
That is definitely the kind you want though. It’s a standardized connection fortunately and not proprietary in this case. I think this is an ideal test and I’m excited to see what you find!
Steve Gotthardt
Thanks!
I also found that the US setting was not ‘taking’ and I found this article.
Ahh yes, that is what I was looking for! The method I gave you wouldn’t have survived reboots either. I couldn’t remember where the config file for this was.
The only thing is that it doesn’t exist on the device right now. I then realized the crda package isn’t installed. Ugh! NOW I have a /etc/default/crda:
orangepi@orangepii96:/etc/default$ cat crda
# Set REGDOMAIN to a ISO/IEC 3166-1 alpha2 country code so that iw(8) may set
# the initial regulatory domain setting for IEEE 802.11 devices which operate
# on this system.
#
# Governments assert the right to regulate usage of radio spectrum within
# their respective territories so make sure you select a ISO/IEC 3166-1 alpha2
# country code suitable for your location or you may infringe on local
# legislature. See `/usr/share/zoneinfo/zone.tab' for a table of timezone
# descriptions containing ISO/IEC 3166-1 alpha2 country codes.
REGDOMAIN=
and that is where you would put your regulatory domain. Perfect. I’ll update the instructions (and I’ll have to update the image to include the crda package for 1.8). Thanks!
EDIT: This is up now but for you specifically you could just do sudo apt install crda if you haven’t already! It’s mostly for anybody downloading it new and to match the new documentation.
Steve Gotthardt
Thanks. That’s better than hacking the systemd.
I’ll try it
Steve Gotthardt
re CDRA for US. I found kernel code was looking in the environment for a code so:
on the command line: $ export COUNTRY=US
I got a lot of output 😉 but now sudo iw reg get shows US – where before it was not sticking
my solution: In /etc/systemd/system/dbus-fi.w1.wpa_supplicant1.service
I added the Environment line in the [Service] section: [Service]
Type=dbus
BusName=fi.w1.wpa_supplicant1
Environment="COUNTRY=US"
ExecStart=/sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
MZA
Hello James,
Great job, thank you for the updates and the tutorial.
I’m running your latest Image Bullseye 1.3 got from your git repo, and I see overuns on the serial cnsole.
I see also bad characters definition/encoding with orangepi-config menu and with locale reconfiguration.
Any clue how to fix that.
I’m going next to generate my own image for development purposes.
My Best
I’m actually not sure about this one yet. I don’t actually have a USB to TTL converter! I should get one though because they are super inexpensive and it would help me debug some other things as well. Which baud rate are you using? A lot of people are saying it’s when you use baud rates too high but if you’re using a standard baud rate then I’d imagine this is something that needs additional fixes.
Those ones are typically fixable with kernel flags. We could definitely change these in this build. I haven’t changed any build flags yet (everything has been kernel drivers so far) but you absolutely can rebuild the kernel flags. You can do a make menuconfig inside the OrangePiRDA kernel folder and see all of the options. They will be overwritten if you change them that way but you can permanently change kernel flags by changing the OrangePiRDA/kernel/arch/arm/configs/i96_linux_defconfig. That is the default build flags for the device and if you change them there it should build with them.
I may need your help on this one since I don’t have the TTL adapter yet. I can definitely get one though and I probably should. Hopefully that helps!
Yes sure I can do.
First, I think that the high serial bitrate 921600 is what is set by the boot rom, even before uboot. Changing console bitrate may be done by changing the bootcmd in uboot.
Now from the stakoverflow thread, with “make menuconfig” :
HSUART is not found ( old kernel),
CONFIG_8250 are all disabled,
CONFIG_DW is tens of flags, most of them disabled.
DMA also is disabled on most of device drivers and especially SERIAL_RDA_UART_DMA [=n]
Now I have used the same bitrate for the Xenial image and the display was correct, the wrong chars encoding in the orangepi-config menu appeared in the bullseye images 1.2 and 1.3.
I’m switching to more recent kernel, I’ve found a discussion that RDA8810pl and i96 were added to kernel since 5.0.2. It has not booted yet but it’s interesting to have more recent kernel and make more peripherals run. I need I2c, spi, spidev, socketcan, CAN with mcp2515, gpios etc. I have’nt spent much time on bullseye to check them or add them.
Excellent testing and diagnosing. All your findings and conclusions look right to me here!
Let me know how it goes with a new kernel. I would not be surprised if a newer kernel just straight up fixes this without any further configuration. I would also love to use a newer kernel in this if it’s working well!
I’m honestly afraid to try a newer kernel because I feel like it would open a huge can of worms and create completely new issues that nobody has really seen before related to the newer kernel. I’m definitely trying to avoid that for sure as that’s way beyond the scope of what I was trying to do with the image but if the kernel is already demonstrated to be working well with the Orange Pi i96 without a bunch of weird new issues I am 100% on board with moving to a newer kernel.
To be clear you are saying that this does not happen in version 1.1 correct? That’s very interesting. That is definitely after I made the UART driver change which is supposed to fix copy/pasting over the serial console. Only 1.0 wouldn’t have that change.
In fact 1.2 would point to locales. That was the only change I made in that version besides adding ntpd which definitely wouldn’t have anything to do with it. The locales very much would though especially strange symbols appearing. I made this change to prevent all the warnings related to locales during package configuration but if your default locale isn’t the same as mine then it’s possible I traded one issue for another for you. The fix for both of those issues should be to set the correct locale.
Can you try the following:
sudo dpkg-reconfigure locales
Select your correct locale and let it generate your locales. Can you then try orangepi-config again? It may possibly need a reboot but I believe the locales are supposed to change on most things immediately. I wonder if the strange symbols will be gone. If they are I probably need to reconsider applying a default locale if it breaks things that were working with having no locale set at all. That was definitely not my intention so let me know if this ends up being the problem.
I also wonder if this is breaking the serial terminal in some way since it’s possibly expecting a different locale. The default images had no locale set. It’s now set to en-US as of version 1.2. This has to be what the problem is. The question is will regenerating the correct locales take care of it for you? I think that it is worth a try!
EDIT: I reverted this change in 1.4 so as soon as it finishes uploading can you try again with 1.4?
Hi James,
Re configuring the locales to add en_US.UTF-8 and en_US.ISO-8859-15 and setting SYSTEM env variables locale to en_US.ISO-8859-15 worked this time. Menus ( dpkg-reconfigure locales and orangepi-config) are displayed correctly.
I’ve seen no more overruns on the serial port and copy paste to edited file ( with vi) of hundreds of chars worked fine.
Congrats and thank you.
Thanks for confirming that! I reverted that change in there because it doesn’t really break anything to not have a locale set in the main image. I did add a first startup instructions to set the locale to the README as well as syncing the time and a couple of other quick start steps.
I think this is a better solution than me forcing the en-US locale in the image. Even if people don’t reconfigure the locale there doesn’t seem to be any negative consequences of having none set (other than annoying but otherwise harmless package configuration errors related to locales from Perl). There does seem to be negative consequences to having the wrong one set though. Thanks again for confirming!
If you mind, I’ll continue testing with you. I’m interested in bringing up more peripherals ( spi/CAN through MCP2515) on this board.
I’ve compiled the spidev device as a loadable modules, it can be inserted but does not bring the /dev/spidev.
here’s what I see orangepi@orangepii96:~$cat /sys/bus/spi/devices/spi0.0/modalias
spi:rda-dpi-panel
orangepi@orangepii96:~$cat /sys/bus/spi/devices/spi0.1/modalias
spi:tlv320aic23-spi
Does this mean that the spi are already used ? ( ALSA SoC TLV320AIC23 codec driver )
I’d love that, that would be great! So with any modern kernel / distribution it means that we need to add spidev to the device tree file for the device. This isn’t too unusual. Here’s some instructions.
There’s only one problem. This kernel / uboot is older than that. It doesn’t use device trees at all for the RDA board. If you look through the OrangePi_Build tree almost every other device does use a device tree / dtb but you will find there is no such file used at all for the RDA board. This would be trivial to modify. I think other boards that are still supported also went through this but they all appear to have been updated to use device trees (except the i96). If you Ctrl+F or bulk search the source code for .dtb you will find them and how they work for the other boards.
In other words I’ve already enabled everything necessary for this to work except for the device tree. I don’t think this uses a device tree. It seems to me like it’s all hard coded drivers. I think that what we need to modify is the uboot part of the distribution as that is where it is on all the other boards. I’m definitely familiar with the kernel and device trees and have been doing it that way since… at least the Raspberry Pi 2 or so and I want to say even the Pi 1. These older kernels I’m definitely not as familiar with.
This is absolutely trivial on a modern board. It’s actually trivial on most boards. The 5.X kernel also natively supports the i96 but apparently the storage isn’t mapped so all you can do is boot into an initramfs and can’t map the SD storage. On this board it’s all hard coded and I’m not sure where to look for it. If you can figure out how to change the device mapping though everything should be in place for this to work. I doubt it would even need the image to be recompiled if we knew where / how to map spidev on this board (unless it’s hard coded in the kernel itself which it might be on this one)!
I honestly think we are partly reliving the lives of the Orange Pi team as well as the Armbian team looking at the work that needs to be done and just literally every single thing is pain. The entire kernel needs to be completely revamped (which they did on their still supported boards), it probably needs a completely new wireless driver or updated wireless driver as well. I try to ignore that because that is literally what sunk anyone even trying to do anything with this board. My goal is to just get as many fixes in it as we can and publicly release those so that if this board does break me that all the work we did is still out there and easy to build / available for everyone!
I still think it’s worth it as the work done already has made it viable for light headless applications. I would absolutely love to get the spidev interface working though. If that happens we are actually having a different conversation at that point. That would make it basically a fully featured board for under $10. There literally is no such thing right now and there may never have been. I guess the Pi Zero is close but good luck getting one of those for very far under $100 these days!
MZA
Uboot is old and does not use dts. The kernel 3.10 does.
I’ve searched in uboot code ( after retrieving compilation steps in the scripts) for ports settings and passing them to kernel and I found nothing.
I’ve at the end found this document from freescale / nxp that explains how to make recent linux ( with dts) boot from older uboot. Interesting.
Google search “old uboot dts” if the link does not work.
In summary, if uboot does not provide the device tree to the kernel, then they can be appended to zImage when building the kernel.
Hope this helps.
Yes, this looks like exactly what I need. It’s right from the right time era and they’re even using the linaro toolchain. I will investigate and report back!
EDIT 1: It looks like CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT are not set. There is no /sys/firmware/devicetree/base, no /proc/device-tree. There’s nothing present I can just ask it what device tree it is using.
I then looked for more ways to find out what exactly it’s doing. This led me to fdtcontroladdr. I was able to find a reference to this in /uboot/arch/arm/lib/board.c. Is this being used? Yes, but it specifies by memory address where the blob is.
All OrangePiRDA’s build process is for uboot is this:
"OrangePiRDA")
echo -e "\e[1;31m Configure OrangePi 2G-IOT or i96 \e[0m"
# make CROSS_COMPILE=${TOOLS} clean
make CROSS_COMPILE=${TOOLS} rda8810_config
echo -e "\e[1;31m Compiling Uboot \e[0m"
make CROSS_COMPILE=${TOOLS}
cp -rf ${UBOOT}/u-boot.rda ${UBOOT_BIN}
;;
// Enable RDA signed bootloader:
#define CONFIG_SIGNATURE_CHECK_IMAGE
#define CONFIG_SYS_CACHELINE_SIZE 32
#endif /* __CONFIG_H */
Oh sure. This led me to uboot/configs/rda_config_defaults.h. Okay. This doesn’t look like a device tree but it wouldn’t surprise me if this is one of the key files we have to change. I have no idea what to do with it though nor have I seen or read anything that suggests to me this is the right place although it’s the closest looking I’ve found.
Alright, so let’s go back to the rda8810_config. Is this going anywhere? I doubt it. I just go in circles for hours and hours with this because the whole thing shouldn’t work as far as I understand how the kernel works. Okay, let’s finish up this part of the investigation though. I assume that it’s using uboot/kernel/arch/arm/configs/rda8810_config. So I go to that file and it is… just another copy of the kernel configuration file. It’s not one I’ve modified yet but this is not a device tree nor will it make one. I might as well replace it with my updated config so they match but there’s no way this will make spidev appear.
That leaves me basically right where I started. Where is the device tree? How is it doing it? It has none of the kernel flags set for it to be built into zImage. There’s no uboot.dtb file generated even though it’s referenced in some of the files. There’s no /proc or /sys entries for device trees that would tell me what it’s even using. It does not work the way as these instructions are suggesting. That would actually be an upgrade to how it works.
We need even older documentation apparently. It doesn’t use or support this method (the flags aren’t set and I’d pretty much have to write it in which makes no sense vs. just starting with a new uboot). It’s even older of a method of this that it’s using apparently even though these documents are from 2009-2010. This honestly would explain why I’ve never encountered a kernel like this *EVER*. Once you get back to 2005 that is the year I graduated from High School. I was still in college when this document was written (for Psychology and would have an 8 year social work career oddly enough) but if the kernel worked this way I could absolutely work with it much easier still.
I have no idea how to work with this. It would be easier for me to start with a new uboot and a new kernel. It really would. You can absolutely see why so many people tried this and reached the conclusion they should try with a new kernel (and are never heard from again). It’s an obvious choice vs. trying to work with such an old and janky codebase. It’s also completely unreasonable for one person to do on their own for no money. It’s so, so painful to try and figure out how something this old works (they were using 10+ year old code when they made this board which now it has been many years since then on top of that) that doesn’t work this way anymore for very, very good reasons!
I think the new kernel would be workable if you figured out how to map the storage on it. I’m guessing it’s not as easy as just adding a device tree entry for the SD card port or nobody would be talking about it like it’s an obstacle. It would help to understand how it is working now as I have spent several days on it and have not even been able to LOCATE a device tree where we would add in spidev entries. It’s another question entirely how the storage is all being mapped right now and is working. It all just must be custom code/drivers in this kernel since it definitely had no mainline support until I want to say 5.X but it may have been late 4.X.
Someone tried porting the uboot as recently as like 24 days ago. Her name is Julia. Her comments on her commits are “I hate myself for doing this”. Anyone who has tried this will say that for sure. It really couldn’t be more difficult/painful of a problem even for experienced Linux / kernel people. It’s like every possible thing that could go wrong or make it as difficult as humanly possible to do something is not only there but there in ways that exceed what I thought was possible!
A lot of smart people have worked on this problem already. Combining everyone’s knowledge together has yielded an improved image for sure across the board. I wonder if Julia figured out enough of how this works that she could tell me where on earth (or elsewhere) the device tree / device mapping is happening on this uboot combined with a kernel that is supposed to use device trees (but has literally no sign of them in /proc or /sys)!
This is now uploaded as V1.5. Figuring out this issue was honestly one of the hardest things I’ve ever done on the site, no question about it! It’s straight C built right into the kernel on this one. No device tree in sight for this board. To get an idea of where I had to start I had to translate a 5 year old post from what I assume is Russian. The winning Google query was:
"rda8810" spi_board_info
with a grand total of one result. I was pretty sure this was what I needed to find after hours and hours of research on ancient hardcoded boards and to my shock this guy had done it with the i96 2G more than 5 years ago (and literally nobody else ever best I can tell). Whoever that guy is he is definitely a genius. It looked like to me like he just casually decided to do this and completely rewrite the hardcoded driver like it was nothing (even adding completely new functionality / a new controller for the GPIO SPI).
It does not cover how to add spidev (he only mentioned that it was possible and this is where you would want to do it) but just knowing where to go gave me enough to start. That was by far the most frustrating part since it’s hard coded into the kernel among literally thousands and thousands of files many of which have additional copies in other places you also need to find / change and it goes on and on.
Will it work? I have no idea, it might need another change and I saw some things online that suggested you may need a display driver for this to work but I’ll leave that to you if you can access the interface. You may want to run that link through Google Translate like I did because he literally covers doing a screen with it (but he says it’s slow). His was a full TFT but if yours is something like a digital display it will probably work fine.
If it needs further tweaks that will be easy compared to what had to be done to get to this point!
Michael
Incredible what you have done so far!
I have tested V1.5 but SPI is not working. I am able to open the device, but when I try to send data over SPI 1.0 the system freezes and I have to reset it. I tested python and c, the result is the same.
After looking at the schematics and the RDA8810PL datasheet I don’t understand why our spi should be spi1.0. The schematic says SPI2_CLK, DIO, DI, CS_1 is connected to GPIO_A_2, 3, 4, 6. The full RDA8810PL datasheet confirms this.
It’s basically whatever we say it is. I don’t think I’ll be able to fix it without buying a SPI device. I’d just have to change the bus and other parameters until it works. I will not be able to get one of these before I go to Vegas on Monday unfortunately.
If I had followed what the original person did I would have actually made it on bus 3 which would have made it show up as spidev 3:0. There are several SPI devices connected to the system that you can’t access as well. One is the sound card and one is the actual RDA display-out port. You can see those devices showing up (these are the only things you could detect without the spi_gpio driver). There is zero SPI GPIO support in the base image. It doesn’t exist and it never did.
Basically the way to fix it is I will have to change the parameters and build it over and over again until it works. I’m just guessing though and I have no way to test / adjust the parameters at all. I do not have a SPI device to hook up to it to test it at the moment!
I hope the problem is what you say. I notice though that this bus number is used by a lot of other boards for spidev such as the Orange Pi Zero. I honestly hope this is what is wrong and not anything way, way more complicated than that.
Basically if neither of you are able to build / adjust it I will have to get some hardware to do this.
Michael
The most basic test for the SPI would be just a loopback connection from DI to DIO. You don’t need extra hardware for that. But the I96 crashed somewhere in the sending data part. I have never build a Linux system before. Maybe I can narrow down the part where the crash happens.
That would be great! I’ll see if I can get something like that set up. I was at least able to freeze the board so that is what I needed to have happen.
I’m guessing I need this:
.controller_data = (void *) 5, // CS pin
Except everything I’m reading says the CS pin should be 6. It could be different on the i96 2G (there are some differences) or they could not be counting from 0. I’m adding that part in here though and I’ll test and see if it’s still freezing here!
I don’t have to guess though so now I can just rebuild the kernel and keep trying it here.
I actually changed the interface address to match the other person’s because I have literally no clue what I’m doing. That means that the spidev interface is actually now 3:0. Can I change it? Yes, but I just want to get it working first and then we can make it pretty later!
I did not do a loopback connection yet. This is with nothing connected so 0x00 should be the expected result. I wasn’t even able to do that before without it locking up the entire board in what I assume is a kernel panic.
There were a couple of problems. First I wasn’t matching the ID to the new spi_gpio controller (which is why the interface is 3:0 now, but if you find it is working I would change everything to match to a lower number but since I’ve never done anything like this before I want to start with what was known working and then modify it from there).
Second I didn’t include the CS pin. That was this line:
.controller_data = (void *) 5, // CS pin
It turns out this is obviously pretty important. If it doesn’t know what the right CS pin is I’m sure it was just crashing and burning.
I’m uploading 1.6 if you can give that a try here in a bit!
MZA
Fantastic, you’ve done a great job.
Thank you very much. I am reading your explanations and I will test it asap.
Bravo
MZA
I’ll receive a small TFT in the coming days and I’ll try the same, thank you for this miraculous link and tips. I think the dislay I’ll get is a cheap i2c display, but I have, since years now, an e-Ink spi display that has never been used. I’ll try it if the first is not satisfactory.
For now I’ll focus on the mcp2515, it is to be connected to the spi from the 40 pin header, it needs a GPIO interrupt and a slave select. If it works, it will bring CAN interface to the board.
I guess I must add this device and GPIO pin number in the files you’ve already modified ?
Yes I’m not sure how you could get this module working exactly. It looks like there’s a few problems. The first one is they want you to use an overlay. There are no overlays for this. I just had to fight with it for days to figure out there is no such thing. From their documents:
In other words the problem is drivers. This board doesn’t support overlays which basically makes writing stuff like this dead simple. There needs to be a hardware driver in the kernel for this to work just like everything else on the system because this kernel was never upgraded to use device trees / overlays and everything is purely kernel driver based. This controller may have a kernel module that can be built though with some kernel flags. If there is support in this kernel for it (even if it’s not enabled) this would be much easier to fix that way.
Theoretically this device does support device trees. Is it possible to use overlays with it still even though they are not used for anything? It has the dtc compiler in it. I’m not sure though, this would take some experimentation and nobody has ever done it before. It’s pretty clear to me that I probably won’t be able to figure out more without getting a SPI device. I’ve found where everything is but I’d just have to put out 20 different versions guessing different settings and that probably isn’t a good use of time here.
The good news is can-utils are available in the orangepi repository with:
sudo apt install can-utils
Therefore it’s not hopeless but you are right that this is going to take some creative thinking / some doing. This is absolutely why device trees are a thing. That just makes it easier though. It’s not impossible.
If you were to hardcode this you are right that everything would need to be put into device.c. With any luck you’d just need to select the right driver theoretically but I cannot find an example of anyone ever doing this on a board that doesn’t use overlays. If it had overlays it would have been about a 3-4 line change to enable the spidev interface!
Michael
Hello James,
Thank you fot the guide and the Debian Bullseye Image.
I am using an Amazon basics USB to Ethernet adapter. It is working fine.
Is there a way to get SPI working?
No problem at all and welcome! Can you clarify what you mean by SPI working? I assume you are referring to the 512MB internal SPI flash on the board.
It can definitely work with Android but it’s definitely too small for Linux. Even the server version image is something like 1.2GB-1.3GB in size so there’s just no way it’s going to fit in there. There are certain Linux flavors that could but not the official ones or Debian. It would almost need to be a busybox-based one with only 512MB.
Or do you mean the SPI pins / GPIO? That is covered in the Orange Pi wiki here but I probably should just implement the GPIO utility in the image. I don’t know why they’re having people build it. Let me know exactly what you’re trying to do though and I should be able to help further!
EDIT: I did just fix the GPIO pins which should allow accessing the SPI pins now. I used patb’s tool here. If you’re trying to access the GPIO pins can you try with version 1.3 when it finishes uploading here?
The new version looks like this with the included tool:
orangepi@orangepii96:~$ sudo gpio status
Board auto-detect found OrangePi i96. To skip auto-detect, create a file named /etc/OrangePi-i96
That little script will run at boot time, and change the gpio pins on the 40 pin connector (pins 23-34) into true GPIO pins, and it'll restore proper operation of the UART2 and SPI2 pins (pins 3,9,8,10,12,14) NOTE: this is OrangePi-i96 specific; do not use on the 2G-iot board
I have implemented this script as a systemd startup service on the board (sudo systemctl status gpio_fixup) so the SPI2 pins should be working now!
Thank you for the link to patb’s tools. I get the same gpio status as you.
The hardware for the spi seems to be OK, though it says spi0.1 instead of spi2: root@orangepii96:~# dmesg | grep spi
[ 0.551757] rda-spi rda-spi.0: master is unqueued, this is deprecated
[ 0.552429] spi spi0.0: max_speed_hz = 500000, bus_speed_hz = 200000000, divider = 199
[ 0.553466] spi spi0.1: max_speed_hz = 1000000, bus_speed_hz = 200000000, divider = 99
[ 0.554443] rda-spi rda-spi.1: master is unqueued, this is deprecated
[ 0.555236] rda-spi rda-spi.2: master is unqueued, this is deprecated
But there is no spidev
root@orangepii96:~# ls /dev/spidev*
ls: cannot access ‘/dev/spidev*’: No such file or directory
I want to use the SPI with a python script for an e-paper display. But I am stuck here without the spidev.
I got this up and running on my orangepi zero 2!
Thanks for following up with me! It looks like the spidev kernel module isn’t built in the default Orange Pi kernel.
I’m building version 1.4 right now which will have this driver enabled. Can you try with 1.4 once it’s available here?
EDIT #1: It’s not going to be easy to enable it. I’ve never found anyone who was able to do it before and it looks like I need to recompile some dtb files. This may take some time! It’s not in 1.4 yet but there’s some other fixes in there.
EDIT #2: I think I’m getting closer. This is in the upcoming V1.5 but here’s what it looks like so far (still no spidev yet):
EDIT #3: I haven’t been able to crack this one still. I know I have to be close. On other boards I would modify the .dtb files but the RDA kernel/uboot doesn’t seem to use a dtb file at all. That means it’s all hard coded somewhere and I’m not sure where to find it yet. The devices can be seen at:
So clearly everything is being seen here but still no /dev/spidev. I’ve installed the appropriate drivers here including spidev and spi_gpio. There’s still some step missing here and I’m pretty sure it’s the equivalent of editing the .dtb files for the board. Since those don’t appear to be used in this old version of uboot it’s hard coded somewhere and I have absolutely no idea where. I also can’t find any examples of anyone doing anything like this (or ever using spidev on the board).
It should absolutely be possible to do but I don’t know where to look yet exactly for this. No board released in a long time works like this anymore. All modern kernels use device trees / dtbs but this one is before that and does not appear to be using them (at least not with uboot, maybe it’s using one hard compiled into the kernel itself, again this stuff is so old that I’m not sure as even very early versions of the Pi used dtbs).
Somebody out there will know or remember exactly how this works (or I’ll continue to investigate and finally find a breakthrough as tends to happen sometimes). I’m sure it’s easy if you have a strong understanding of the structure of these earlier 3.X kernels and the uboot versions from the time but it’s like looking for a needle in a haystack if you don’t trying to find some of these hardcoded options that are normally much more modular / accessible in modern kernel versions (and uboot versions as well, it’s all been changed/upgraded from the official Orange Pi one which is something like a minimum of 5-6 years old making it much harder to find relevant information). This is some older school knowledge that people who were working in the industry at the time will just know I’m sure.
Hello James, could you please inform what is the model of the USB to Ethernet device are you using? I’ve been trying a few models an the Linux doesn’t recognize other network interface, probably is because the old Linux doesn’t have the drivers. So I’m looking a model that works in orange pi I96
I’m actually using that at this very moment to work on answering Andy’s question (hang in there Andy!). Ironically it is a Microsoft adapter. I tend to use generic ones that are bundled by the manufacturers of laptops and tablets. Here’s the specific one:
This one was probably from an older Surface but it may have been another Microsoft product potentially. I also have ones from HP and I have a USB 2.0 Belkin one that I’ve used in the past (but not with the i96). I can definitely give those a try as well (let me finish with Andy’s first) but wanted to show you the one I specifically was using!
EDIT: I tried with one even a little bit more interesting. This is a HP one using a USB-C RJ45 adapter with a USB-C to USB-A adapter (comes with newer higher-end HP business/enterprise laptops as an included in-box accessory a lot of the time) and it also worked perfectly:
It doesn’t seem too picky so far with newer ones and USB 3.0 ones. The HP one is quite modern being USB-C (the little USB-C to USB-A adapter also comes in the box with the laptops that include these). It has a P/N on it so I’m sure you could find one but these are just basically ones I have just got for free over the years as accessories from different stuff (or from my IT tech career when people already had several of these and didn’t want the new one from the box when I was deploying a new machine to them). I probably have at least 6 of the HP ones because I would end up with a pile of them on my desk when I was doing deployments of 20-30 laptops at a time since at least a few people wouldn’t want them each batch.
I didn’t try the Belkin USB 2.0 one but I’ve had trouble with that one on other Linux distros lately. I seem to actually have the best luck with newer ones or fairly modern ones rather than USB 2.0 ones in my experience for what it’s worth (but it’s only in the past few years that has been true and it used to be exactly the opposite where the Belkin USB 2.0 and a lot of those well-known ones were the *only* ones that worked within Linux).
I suspect that is due to increased gadget support (on the manufacturer/adapter side as well as the Linux kernel side) and if you read my reply to Andy you will see that even the Microsoft one is actually using gadget mode (and so does the HP one) and I’m guessing a lot of the older ones either don’t use it at all or don’t implement correctly or the extent that newer USB-C compliant ones do.
Hopefully that helps!
thank you for the interesting guide. I bought one of these last year but although I managed to install an old version of Armbian and the official Ubuntu and Debian images, and despite the board is running nicely, I have never succeded in getting the USB port to work properly with any distribution.
Any USB 2.0 pen or device that I connect to the USB port (which is claimed to be a 2.0/480M High Speed port) is always recognized as a “Full Speed” device instead (hence the data transfer rate is reduced to 12M instead of 480M) .
My intention was to use the board as a very low-cost ADS-B decoder, using a DVB-T dongle (I use an OPI Zero and a Lite for the very same task, but they are significantly more expensive), but the decoding software, based on rtllib needs the USB 2.0 high speed to work.
Are you able to check if your board’s USB port handles correctly (that is, at high speed) USB 2.0 devices, jus to exclude that my board is somewhat faulty?
Welcome! I can definitely confirm this issue. It definitely not your board. I was also able to reproduce your powered USB hub results. With a hub it won’t even detect anything plugged in.
Here’s what I get during my testing:
root@orangepii96:/boot# dmesg | grep usb
[ 0.297302] v_usb: 1800 2800 mV normal standby
[ 0.320495] usbcore: registered new interface driver usbfs
[ 0.321105] usbcore: registered new interface driver hub
[ 0.321838] usbcore: registered new device driver usb
[ 0.585327] usbcore: registered new interface driver usb-storage
[ 0.587219] platform disable musb
[ 0.587463] musb-hdrc: ConfigData=0x1a (UTMI-8, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 0.588378] musb-hdrc: HDRC RTL version 2.0
[ 0.588989] gpio-vbus gpio-vbus: registered host 'musb-hdrc'
[ 0.691711] usbcore: registered new interface driver usbmouse
[ 0.949707] musb_gadget_pullup android usb didn't ready
[ 0.951538] android_usb gadget: Mass Storage Function, version: 2009/09/11
[ 0.952270] android_usb gadget: Number of LUNs=1
[ 0.953674] android_usb gadget: android_usb ready
[ 0.954101] gpio-vbus gpio-vbus: registered gadget 'musb-hdrc'
[ 0.954833] musb-hdrc musb-hdrc: MUSB HDRC host driver
[ 0.955444] musb-hdrc musb-hdrc: new USB bus registered, assigned bus number 1
[ 0.957702] platform enable musb
[ 4.942016] usb cable connect...
[ 6.591857] usb cable disconnect...
[ 7.110046] usb 1-1: new full-speed USB device number 2 using musb-hdrc
[ 7.250244] usb 1-1: Parent hub missing LPM exit latency info. Power management will be impacted.
[ 7.251281] usb 1-1: not running at top speed; connect to a high speed hub
[ 8.721618] cdc_ether 1-1:2.0 eth0: register 'cdc_ether' at usb-musb-hdrc-1, CDC Ethernet Device, 60:45:bd:fb:3d:7d
[ 8.732788] usbcore: registered new interface driver cdc_ether
root@orangepii96:/boot# lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Communications, Driver=cdc_ether, 12M
|__ Port 1: Dev 2, If 1, Class=CDC Data, Driver=cdc_ether, 12M
I think it’s somehow related to the musb-hdrc driver. This isn’t exactly the driver I would expect and is a USB OTG driver. I think the USB OTG power port and the host port may be sharing the same host controller and that may have something to do with this.
To see why I suspect this take a look at all of the settings for musb-hdrc:
root@orangepii96:/home/orangepi# ls /sys/class/udc/musb-hdrc/
a_alt_hnp_support a_hnp_support b_hnp_enable current_speed device is_a_peripheral is_otg maximum_speed power soft_connect srp state subsystem uevent
root@orangepii96:/home/orangepi# cat /sys/class/udc/musb-hdrc/*
0
0
0
UNKNOWN
cat: /sys/class/udc/musb-hdrc/device: Is a directory
0
1
high-speed
cat: /sys/class/udc/musb-hdrc/power: Is a directory
cat: /sys/class/udc/musb-hdrc/soft_connect: Permission denied
cat: /sys/class/udc/musb-hdrc/srp: Permission denied
not attached
cat: /sys/class/udc/musb-hdrc/subsystem: Is a directory
DRIVER=android_usb
USB_UDC_NAME=musb-hdrc
USB_UDC_DRIVER=android_usb
There is a *lot* of OTG stuff enabled on this driver and this is the driver it’s using for stuff plugged into the regular USB-A port. It may be possible to blacklist it and use a different driver but it’s quite likely that will also make it not see the device at all. I did try a manual override using the kernel debug testmode parameter located here:
root@orangepii96:/sys/kernel/debug/musb-hdrc# ls
regdump testmode
You can set the testmode to force it to go to high speed mode. When I tried this it stopped seeing the adapter until I rebooted.
A little bit more information:
root@orangepii96:/sys/kernel/debug/musb-hdrc# sudo lsusb -v | grep 'Support\|Product\|operate\|Lowest\|InterfaceProtocol'
idProduct 0x07c6 RTL8153 GigE [Surface Ethernet Adapter]
iProduct 2 Ethernet Adapter
bInterfaceProtocol 0
bInterfaceProtocol 0
can't get debug descriptor: Resource temporarily unavailable
bInterfaceProtocol 0
bInterfaceProtocol 0
HIRD Link Power Management (LPM) Supported
Latency Tolerance Messages (LTM) Supported
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 2
Lowest fully-functional device speed is High Speed (480Mbps)
idProduct 0x0002 2.0 root hub
iProduct 2 MUSB HDRC host driver
bInterfaceProtocol 0 Full speed (or root) hub
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
You can see the problem is actually in the “root hub”. It’s not actually in the adapter / the device you are plugging in. You can see here that it’s actually detecting that the device itself is not only capable of 480M but is actually capable of SuperSpeed 5Gbps (and it knows it / can see it) but it’s nevertheless limited by the root hub. It’s the root hub that is set to full speed: bInterfaceProtocol 0 Full speed (or root) hub. I know I’ve seen blacklisting certain hub drivers fix issues like this in the past but I haven’t tried blacklisting the driver yet (or know if there’s other drivers that will take over for it yet if I tried to).
I’m wondering if some of these options may have any impact (particularly quirks or avoid_reset_quirk, some of the user controllable options):
root@orangepii96:/sys/bus/usb/devices/usb1# ls
1-0:1.0 authorized_default bConfigurationValue bDeviceSubClass bMaxPower busnum dev driver idVendor maxchild quirks serial uevent
1-1 avoid_reset_quirk bDeviceClass bmAttributes bNumConfigurations configuration devnum ep_00 ltm_capable power removable speed urbnum
authorized bcdDevice bDeviceProtocol bMaxPacketSize0 bNumInterfaces descriptors devpath idProduct manufacturer product remove subsystem version
On some boards you can edit the .dtb files and recompile them to change how the kernel is seeing the devices. That would theoretically be these files.
I’m continuing to investigate the problem. From what I can tell (and maybe you got this sense as well) it might take a kernel rebuild to fix this with some additional options checked but I am continuing to check if there is another way here!
first of all, thanks for your investigations, now I know my board is not faulty (even if it was somewhat easier to purchase another 7$ board to replace a faluty one rather than having to deal with this kind of driver-related problems).
I copy and paste what I wrote on the Armbian forum months ago. They used to provide an image but it was soon abandoned due to the limited capacity of the board, in their opinion not powerful enough and with a too flacky wifi to deserve further developing. I do not agree and believe that this little board could really be a nice toy to play with… if the USB worked as expected.
Here is my dmesg | grep usb
[ 0.378479] : pid = 10, v_usb: ext_len = 0
[ 0.378540] v_usb: 1800 2800 mV normal standby
[ 0.388732] usbcore: registered new interface driver usbfs
[ 0.388793] usbcore: registered new interface driver hub
[ 0.388854] usbcore: registered new device driver usb
[ 0.697265] usbcore: registered new interface driver usb-storage
[ 0.697753] platform disable musb
[ 0.697814] musb-hdrc: ConfigData=0x1a (UTMI-8, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 0.697814] musb-hdrc: HDRC RTL version 2.0
[ 0.697875] gpio-vbus gpio-vbus: registered host 'musb-hdrc'
[ 0.791931] usbcore: registered new interface driver usbmouse
[ 0.822021] musb_gadget_pullup android usb didn't ready
[ 0.822937] android_usb gadget: Mass Storage Function, version: 2009/09/11
[ 0.822937] android_usb gadget: Number of LUNs=1
[ 0.823181] android_usb gadget: android_usb ready
[ 0.823242] gpio-vbus gpio-vbus: registered gadget 'musb-hdrc'
[ 0.823242] musb-hdrc musb-hdrc: MUSB HDRC host driver
[ 0.823242] musb-hdrc musb-hdrc: new USB bus registered, assigned bus number 1
[ 0.823364] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.823364] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.823364] usb usb1: Product: MUSB HDRC host driver
[ 0.823364] usb usb1: Manufacturer: Linux 3.10.62-rda8810 musb-hcd
[ 0.823364] usb usb1: SerialNumber: musb-hdrc
[ 0.823913] platform enable musb
[ 4.835388] : pid = 10, v_usb: ext_len = 0
[ 4.835449] usb cable connect...
[ 6.715698] usb cable disconnect...
[ 7.181274] usb 1-1: new full-speed USB device number 2 using musb-hdrc
[ 7.324584] usb 1-1: not running at top speed; connect to a high speed hub
[ 7.335021] usb 1-1: New USB device found, idVendor=0bda, idProduct=2838
[ 7.335021] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7.335083] usb 1-1: Product: RTL2838UHIDIR
[ 7.335083] usb 1-1: Manufacturer: Realtek
[ 7.335144] usb 1-1: SerialNumber: 00000212
[ 15.373962] musb-hdrc musb-hdrc: VBUS_ERROR in a_host (98, VALID), retry #1, port1 00000103
[ 16.553955] usb 1-1: USB disconnect, device number 2
[ 16.831298] usb 1-1: new full-speed USB device number 3 using musb-hdrc
[ 16.976806] usb 1-1: not running at top speed; connect to a high speed hub
[ 16.987182] usb 1-1: New USB device found, idVendor=0bda, idProduct=2838
[ 16.987182] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 16.987182] usb 1-1: Product: RTL2838UHIDIR
[ 16.987243] usb 1-1: Manufacturer: Realtek
[ 16.987243] usb 1-1: SerialNumber: 00000212
[ 215.878356] musb-hdrc musb-hdrc: BUS BABBLE as a_host
[ 215.878356] musb-hdrc musb-hdrc: usb otg cable is still on, and id is low
[ 215.878906] usb 1-1: USB disconnect, device number 3
[ 217.352416] usb 1-1: new full-speed USB device number 4 using musb-hdrc
[ 217.505798] usb 1-1: not running at top speed; connect to a high speed hub
[ 217.516784] usb 1-1: New USB device found, idVendor=0bda, idProduct=2838
[ 217.516845] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 217.516906] usb 1-1: Product: RTL2838UHIDIR
[ 217.516906] usb 1-1: Manufacturer: Realtek
[ 217.516906] usb 1-1: SerialNumber: 00000212
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=, 12M
|__ Port 1: Dev 4, If 1, Class=Vendor Specific Class, Driver=, 12M
I wondered if it could be a power-related problem, but I tested all the three power adapters I own, two 2.1A and one 2.4A, two of which with mobile USB cables and the last with fixed cable which work without a problem with my OPI Lite and my OPI Zero (each one having mounted to their USB ports an RTL-SDR dongle, plus a CPU fan, SSD1306 OLED screen and external RTC module attached to their GPIO header).
I doubt that the same power unit that is able to drive a 4-core board with all that stuff attached to the USB and GPIO header (and in the case of the Zero powered through the same micro-usb port) is unable to deliver enough power to this single core board and just one device attached. Or am I wrong?
I tried with any possible combination of power adapters and cables I have and even tried to (succesfully) power up the board through the GPIO header’s pins, but nothing changes.
I tried to attach an external 4-ports 2.0 Hub, I have two, one is powered, the second is not. The powered one is simply not recognized, the other one is recognized as a 2.0 Hub but if I then attach the dongle to it, the dongle is not recognized anymore (not even as a 1.1. device).
I then tried to use a Y USB cable to provide this latter hub some external power (by attaching the power cable to a second power adapter) but nothing changes (the hub is recognized, but no other devices attached to it are).
Of course I tried to switch the RTL-SDR dongles, I have three, but all of them are recognized as 1.1 devices as well as different USB 2.0 pens to the board but even these are recognized as 1.1. devices, so I can assume the issue is not power-related but agree with you that the problem is definitely with the musb-hdrc driver and the way it deals with both the OTG port (which can be used to power up the board) and the USB-A port.
Unfortunately I’m still quite new to Linux and scratching my head around when dealing with kernel recompilation…
Thanks a lot for the time you are devoting to the problem.
No problem at all, this is an extremely tough one! What I am trying to determine if it’s possible. What do I mean by that? The question in my mind is did they implement the USB incorrectly at the hardware level to save money. I feel like on this board the answer is going to be yes, they did not implement USB properly and it was on purpose to save money. That’s simply a function of the fact that it’s widely available for under $10 and none of their other boards are (not even ones older than the i96!).
I’ve covered issues like this a lot on the site as it also relates to Raspberry Pis and whether they can use the cheap 2.5″ to SATA adapters and they are absolutely notorious for implementing USB wrong (on purpose) to save money. In this case I’m talking about the adapter manufacturers but Raspberry Pi themselves has had issues with implementing USB properly as well such has with the Pi 4 launch where they had to revise how they implemented it at the hardware level on later revisions of the board (the earliest Pi 4 launch revisions still have that USB hardware defect where it won’t work with certain USB-C chargers which is not supposed to be a thing with USB-C).
Take a look at this thread here. This isn’t the exact issue the Orange Pi has but the engineers in this thread covered so many of the terms and concepts that we’re dealing with here that I found it extremely valuable.
I’m certain nobody has been able to figure out how to solve this problem. I came across your original thread many, many times during my research on this as there is almost nothing related to this out there. It really sucks that the community gave up on the board because a lot of those guys who do the Armbian programming are exactly who we needed to look at this board to fix it and they kind of washed their hands with it already.
I definitely don’t think it’s power related but that was actually my first thought (and why I recreated your powered hub experiment). I agree with your conclusion here. The other thing that points to this is that those Eth to USB adapters are extremely low powered and I’ve never had an issue getting power to those on any devices so this doesn’t seem to fit either.
It pretty much all boils down to is this a kernel configuration issue or is this an actual hardware issue where they didn’t implement USB correctly? One of those can be fixed and one of them can’t. Recompiling the kernel isn’t too hard (other than you will probably have to cross-compile unfortunately for this model) but knowing what to change is more tricky. If I was working on this within a company this is the part where I would call in the electrical engineers / hardware engineers.
I’m more of the software/development guy and this problem is getting extremely low level. I’m definitely comfortable with all types of hardware but we’re getting to straight up electrical engineering here. It’s not easy to get the guys with that level of electrical engineering and consumer electronics experience to look at it as you’re starting to get to the skill levels where there just aren’t that many people at that level (similar to higher level hacking). That’s why it’s a bummer the Armbian guys wouldn’t keep going with this board. No doubt they would have already figured this out by now (or they already know that the USB can’t be fixed and that may have weighed into their decision even if it wasn’t as public of a point, hard to say).
Despite this I do have a history of fixing things like this. One of my most popular projects on GitHub was actually fixing Ubuntu 18.04 for the Raspberry Pi which was not officially supported at the time. I *hated* doing this project but the people *loved* it. It has over 500 stars on GitHub which only my Raspberry Pi Minecraft Bedrock server project has more (and it took a lot longer to get them). Why did I hate it? Because it’s really, really hard to fix these kinds of issues. You really need to have 2 God-tier skillsets to do that (advanced software and electrical engineering). The reason it is hard and miserable for me is I have 1 of those skillsets and I have to learn everything about the other one. I can do it (anyone can learn anything given enough time) but the cost is time.
I have some ideas to try fixing this that I’ve mentioned in my previous post and I have a few others as well. For example if I were to try rebuilding the kernel I would start by going into the options related to “musb-hdrc” and see what Orange Pi has checked and hasn’t checked. I’d investigate if I can remove the OTG driver altogether if I’m not going to be using that functionality to see if that will let it use the normal driver for USB 2.0 devices.
The thing I am struggling with is I do not want to go down this road if this issue is because of a hardware design issue on the board. I want to understand more about exactly what is happening before sinking probably at least dozens and realistically hundreds of hours into a board fix project (although I learned a lot from my last one and would definitely do a lot to minimize the scope of what I’m trying to do with it, maybe just that one fix).
Did you ever try contacting Orange Pi support officially? I know you made some of those posts but it didn’t seem like you got an official answer. I have seen official answers to similar questions like this though on other Orange Pi models like the PC 2. I think this would be worth asking them (possibly privately through their normal ticket system) if you haven’t tried already to see if they tell us that it’s physically impossible or not as that would really help both of us decide whether it’s worth going further!
I didn’t realise it before you told that but I believe you may be right when you think they may have implemented incorrectly the USB ports. I’m by no means and electrical engineer, but the simple fact that the I96 was let alone by it’s manufacturer just a few months after launch (their official distros are quite old and there is no signs of updates for those) make me think that the board probably had some problems in that respect.
I totally agree with you that you may loosing your time trying to patch the official distribution not knowing if the problem is hardware-related. I will open a ticket with OPI support and see if I can get an answer of any sort, but I’m not confident they will ever answer. The board is already old (and supposedly already out of production) and even if they may be aware of the problem it has I don’t think they would have resources to devote to solve it, being the I96 the cheapest of the bunch.
Anyway, will try to get in touch with them and will post here any reply I will get (if ever)….
Thank you so much for your great reply! I think this is the right course of action. Let’s see what they say.
I have no doubt there are problems with the board. We know about the WiFi (I haven’t really seen as many issues with this but lots of people have). We know the board isn’t perfect for sure. That’s not the interesting question though in my eyes.
The fact is this board costs less than $10. You can’t get anything nearly as powerful for that much money. A Pico W is $7 if you can even find one and that one is only a microcontroller and not even a SBC!
That $10 price makes this an interesting question. We know the board has problems, but is this problem insurmountable or is this problem just one of dozens of problems with the board that actually could have been fixed if they stuck with it (all boards are like this at launch, even Pis especially early model Pis). It also matters which problems are insurmountable and which ones aren’t. If the WiFi is just flaky but we can get it working pretty well otherwise then with that caveat this would still be a good choice for a lot of projects.
Because of that I’m actually not sure which category this is going to fall in. Is this a hardware defect that would have to be fixed literally by making a new board revision? Or is it one of the potentially dozens of software and kernel issues that would easily be resolved?
The mainline kernel has support for the i96 now. There is no premade image out there that let’s you install this very easily. I’ve tried. I tried installing the kernel from apt as well but it won’t use it because uboot still loads the old kernel. I half wonder if the mainline kernel would work *much* better and faster than the i96 image which is several years old. Here’s when official support was added for the i96 to the Linux kernel.
I literally have not figured out how to get the Orange Pi i96 to the mainline kernel yet. As I look through the link I just posted above I did see some things I can try though to switch over the kernel. I saw a few other things I could try as well such as installing Arch Linux from a base image and I already tried several other things such as installing linux-image-generic through apt and the Orange Pi will not load the new kernel due to uboot. I would probably have to cross compile uboot and the kernel or try the Arch method possibly to get on that newer i96 kernel.
I still have a few ideas I want to try. I want to see if I can get it on Arch Linux from some of these tutorials from 5 years ago and make my way to a newer kernel. I might also just get the cross compiler and try some basics and see if it makes any difference.
I’m willing to help fix this. I think the best course of action is to attempt to contact them first as we talked about here. If they won’t answer within a week or two or whatever your best judgement is come back and let me know they never replied! I’ll also add some replies if I get anywhere trying to use the actual native Linux 5.0 kernel to use the built in i96 support (which probably very few people have ever experienced).
The fix is is to comment out this code in kernel/drivers/usb/musb/rda.c:
/* disable high speed when host*/
power = musb_readb(regs, MUSB_POWER);
power &= ~MUSB_POWER_HSENAB;
musb_writeb(regs, MUSB_POWER, power);
Now he is using the 2G model and the modem is still messing with his USB speeds for some reason. I just have the plain i96 and so I rebuilt the kernel and take a look here:
orangepi@orangepii96:~$ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Communications, Driver=cdc_ether, 480M
|__ Port 1: Dev 2, If 1, Class=CDC Data, Driver=cdc_ether, 480M
orangepi@orangepii96:~$ uname -a
Linux orangepii96 3.10.62-rel5.0.2+ #2 PREEMPT Tue Aug 23 16:49:14 MDT 2022 armv7l GNU/Linux
orangepi@orangepii96:~$
Yep, that’s it, it’s working! Notice that my kernel date is 2022. This is because I did actually rebuild the kernel. I used the OrangePi_Build system and made some modifications. I did this on Ubuntu 22.04 but I did have to make a change to the source as it was trying to install old dependencies that no longer exist.
It also has a bonus perk. While I was upgrading the build system to work I went ahead and updated the image to Debian Bullseye! I know you are using the Armbian distro that has been cut off which this could be built into that as well (although going to Debian Bullseye will probably be a newer and better choice if not for the kernel then for everything else).
Andy
James you are GREAT!
I’m downloading your image right now and will install over the week end. I don’t know how you managed to find that post by Mr. Hidvegi, I searched forever the web without finding any useful clue!
Thanks a lot also for preparing the image, I own the plain I96 version so it is exactly what I needed (sorry to hear that the fix has some caveats for the 2G version though).
Will keep you posted as soon as I have everything up and running!
No problem at all! He said that it works on the 2G version if you wait something like 6 seconds to load the driver. It looks like he planned on making an image as well but it doesn’t look like that happened.
Definitely let me know how it goes! If there are other fixes available out there it should be pretty easy to implement them. Instead of just producing an image one time I wanted to patch the official build system so that people could pretty easily reproduce images as this seems to be an obstacle that was never really overcome. I haven’t seen any Orange Pi i96 images available anywhere like this (not since that Armbian fork was abandoned).
I’m sure fixing the Ubuntu build isn’t impossible either. 22.04 doesn’t build clean at all. 20.04.1 actually does build clean but won’t boot for some reason. It’s hard to debug it without having the serial UART connector (I don’t) as I have no idea why the image isn’t booting (just that it isn’t). I’m hoping if I just get the ball rolling though that some others will show up here and there with some additional fixes.
I’m not as worried about scope with this project as Ubuntu. I implemented literally every fix I could find that is available for the i96 (only 3 total) but is it all of them that exist? I kind of doubt it because of how many times both of us didn’t find that post. Are there a few other fixes out there like that both of us haven’t seen? Probably and that is where I hope some other people may contribute or even fork it with some additional fixes.
I look forward to hearing what you find!
Andy
Hi James
I can confirm that your image fixes the problem and the little board can definitely be used as an ultra-cheap ADS-B receiver when coupled to a likewise cheap DVB-T dongle! THANK YOU!
Excellent news, thanks so much for testing it! That is fantastic for a $7 board and I don’t think there’s anything else like it available. Thanks so much for testing this and sharing!
Alexander Farley
Thank you, I followed this guide to get the i96 working and it was quite helpful.
I’m glad it could help! I couldn’t believe that board is on Amazon for something like $7 + shipping. It actually works really well. These are fantastic for so many projects / use cases that don’t need anything more than a low power headless board.
It’s been out for a while so I’m certainly late to the party but it’s the Raspberry Pi shortage that led me to investigate these boards. They were probably honestly miserable to use at the time back in 2017-2018 (and earlier for some Orange Pis) compared to now since they’ve had years of refinements / upgrades (particularly with the kernel). Anyone jumping into it now will almost certainly have a much smoother time than when many of these Orange Pi models were originally released (as long as you know where to find certain up-to-date tools / downloads which this guide covers).
Thanks for leaving this. It definitely does make a difference especially on the newer articles that don’t have a lot of feedback yet and lets me know that I need to keep doing more articles/guides like this on the site. Take care!
Interesting! I think I mentioned that when I saw the price I bought to then think what project I will be using the board on. I think it may do well with some sort of sensor based automation or wireless control for something.
Thank you for putting the time in to tinker with it James.
No problem at all, it was really fun to play with! I think you’re absolutely on the right track. I’ve actually been working on a demo project for the Pico W that will basically use those cheap $7 Picos as a wireless scanning station. It will scan for all SSIDs in the area and look for changes.
This is mostly just to demo the wireless but it does need a low power controller. This would be perfect and is kind of along the ideas of a wireless controller. It’s honestly almost the same price as a Pico W. This is more powerful than a Pico W though. You could use these as the door/gate wireless controllers instead of a Pico W simply because they cost about the same!
Thanks for the image – I have several i96 to use for 3D printing host for klipper since RPi are so hard to get now…
I bought a TTL-USB via Amazon.. It uses CP2102 HiLetgo CP2102 USB 2.0 to TTL Module Serial Converter Adapter Module USB to TTL Downloader With Jumper Wires – drivers here.
Using PuTTY – here
Using image 1.5 – here are interesting parts:
RDA8810 Boot_ROM V1.6HW_CFG: 0286
SW_CFG: 0000
Load EMMC
Open eMMC
EMMC OCR timeout
Open eMMC card Failed
Load EMMC Fail
Load SD
Open SD card
mcd_Open
Card is SDHC
Inserted Card is a SD card
mcd_Open Done
Loading image from SD card ................................................................................................Done
rda2 stand for dqs_prsel_preset
rda2=0 rda2=1 rda2=2 rda2=3 rda2=4 rda2=5 rda2=6 rda2=7
R R R R R * * R
Please check the result and choose the best one
final rda2= 1, rda2_old = 2
setup ddr vtt to 1
pll freq CPU = 988
pll freq BUS = 800
pll freq MEM = 260
Init DDR, flag = 0x0002, para = 0x00001338
32bit dll-on Mode ...
ddr2 phy init done!
format ctrl value: 22000202
address ctrl value: 30301
decode ctrl value: 10
dram init done ...
Done
U-Boot 2012.04.442-rel5.0.2-g5ee06c1-dirty (Sep 01 2022 - 17:48:37)
RDA8810 SoC
Board: RDA8810
DRAM: 236 MiB
CPU: enable instruction caches
CPU: enable data caches
CPU: enable neon
CPU: p15-c1-c1 (NSACR): 0x00000000 -> 0x00000c00
CPU: p15-c1-c0 (CPACR): 0x00000000 -> 0x00f00000
NAND: metal 28 hwcfg 286, use eMMC, skip nand init
0 MiB
MMC: MMC: registered mmc interface 0
Cannot find the emmc corresponding mclk adj and inv.Now use default zero. Please add it
MMC: registered mmc interface 1
ERROR: v7_dcache_inval_range - stop address is not aligned - 0x8dae5e88
Welcome to Debian GNU/Linux 11 (bullseye)!
[ 3.011291] systemd[1]: Set hostname to .
Hey Steve,
What is happening with it? Does it boot? I only see down to set hostname to . which does look wrong. Does it not go any further past that point?
This is definitely not normal behavior. I’m guessing you need to clean that SD card off before imaging with something like the SD Card Association’s Formatting Tool (free). If it was imaged with btrfs or any type of networking file system ever then this is 100% the problem and the SD card association’s tool is the only way to fix it.
You may want to try V1.6 if you have a SPI device connected as I just fixed a lockup related to those.
I’ve definitely seen this a lot over the years on the Raspberry Pi but it happens with all boards / devices with certain types of partitioning. The SD card association’s tool should (truly) blank it for you and let you image the SD card correctly!
heh – somehow the log was cut off. Yes, it boots – ill try 1.6 – using BelenaEtcher seems to be fine.
Hey Steve,
No worries at all, I had wondered if that happened! Let’s see what 1.6 does as I had to have been uploading it probably minutes after you downloaded 1.5.
Etcher should be fine. Just keep in mind Etcher doesn’t blank SD cards which is why previous partitioning can be a problem. For btrfs it’s almost impossible to erase it using normal tools as SD cards have basically hidden proprietary manufacturer partitions that are invisible to formatting tools and it seems to utilize these. The SD card association’s tool will clear out the “secret” manufacturer partitions and all of that.
The eMMC / SPI flash warnings in the boot sequence are normal. There are fixes for those out there but I haven’t merged them into this image yet (but I have for other things that throw similar nasty startup messages in dmesg / the terminal). It’s used for some unexpected things like storing the wireless MAC address (this is supposed to be stored on the SPI flash / NAND partition). Nobodies Orange Pi comes imaged with the proper partitions for it (this actually has a different fix for the wireless MAC address in it). That is what a lot of the startup messages are related to though.
The fix in this image actually writes your wireless MAC address to a file on the root partition. It’s at /data/misc/wifi/WLANMAC. Once you do your first startup it will have a file there with the MAC address in it. If you reimage the Orange Pi you can actually carry that MAC address file over if you want to to keep the same MAC address as your previous image.
I do plan on cleaning these up for sure. There aren’t too many left and I have seen people who have fixes for them in other images so this is definitely on the to-do list.
Let’s see how it goes with the new version!
v1.6 booted – I don’t have SPI needs (right now 😉 seems to work – some findings on WiFi:
The wifi connected – once in moments and the next time it was at 830 seconds with these messages 15-30 seconds apart dropping onto the console:
[ 770.773071] cfg80211: Calling CRDA to update world regulatory domainI also found I had to start and enable resolved.service so DNS lookups would work:
systemctl start systemd-resolved.servicesystemctl enable systemd-resolved.service
Hey Steve,
That is interesting with the WiFi. I do not get the DNS issues when I use a Eth to USB adapter (which I always am). Is your DNS working even over WiFi then? How about your SSL? Orange Pi’s own instructions always bypass the SSL but maybe that is DNS related as well.
My /etc/resolv.conf looks like this:
orangepi@orangepii96:~$ cat /etc/resolv.conf# Generated by NetworkManager
search jamesachambers.net
nameserver 192.168.1.85
nameserver 192.168.1.90
nameserver 192.168.1.91
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 192.168.1.1
That’s definitely all pulled down by my network it looks like. I have definitely noticed that you cannot make SSL connections on the WiFi though but maybe this is resolved related. I’ll enable this service within the image!
The WiFi is absolutely broken on this board and I do not use it personally. Your findings make me wonder though how much of that might be related to the image / kernel and isn’t actually the WiFi chip or any of that! Maybe we can get it working a lot better than it is still!
I’m not sure how you’d change your regulatory domain on the Orange Pi. This is a thing though. Everyone’s will be different so I can’t set one in the image. On the Raspberry Pi you need to set this or 5GHz WiFi won’t even work basically. Can you try the following to set your wireless regulatory domain:
iw reg set USReplace with your own country code and let’s see if that resolves that!
The Wifi will work and then not: I won’t be able to resolve github.com , SSL won’t work, and then it will start working and clone a repo…
I stopped systemd-resolved.service and DNS still worked – so it may have been coincident turning resolved on helped…
I set the US country as you advised – I still got a message. Now I am exploring maybe antenna orientation/signal strength? So a better wifi connection and ‘things’ work better (no messages, names resolve, SSL is good)? I’ll plod on with wifi – at the moment it is working 😉
Hey Steve,
Very interesting. I’ve made some changes and fixes from your feedback as well as some other general cleanup in 1.7. I added the orangepi user to some missing groups as well as some other service related fixes. I fixed a service startup issue in e2scrub_all and actually removed hostapd. It may have been hostapd crashing over and over that was impacting the WiFi so I think it may be worth trying the new version.
V1.7 is giving me a clean startup with:
sudo systemctl statusIn other words there are no failed services starting up on the new version. If you’re willing I’d be curious if the hostapd service crashing over and over was impacting this and if 1.7 improves things!
The antenna may be the weak point – I used wavemon to monitor signal strength and the signal-strength jumps all over with even slight movement. I moved my i96 to within 10 feet of router and it might be better at connecting (I was around 30ft) but I still get these:
WiFi info – from journalctl -r
Sep 03 00:43:12 orangepii96 kernel: cfg80211: Calling CRDA for country: USSep 03 00:43:12 orangepii96 wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED>
Sep 03 00:42:48 orangepii96 wpa_supplicant[257]: wlan0: CTRL-EVENT-CONNECTED - >
Sep 03 00:42:48 orangepii96 wpa_supplicant[257]: wlan0: WPA: Key negotiation co>
Sep 03 00:42:46 orangepii96 wpa_supplicant[257]: wlan0: CTRL-EVENT-SUBNET-STATU>
Sep 03 00:42:46 orangepii96 wpa_supplicant[257]: wlan0: Associated with d4:5d:6>
Sep 03 00:42:44 orangepii96 wpa_supplicant[257]: wlan0: Trying to associate wit>
Sep 03 00:42:42 orangepii96 wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED>
Sep 03 00:42:42 orangepii96 kernel: cfg80211: Calling CRDA to update world regu>
Sep 03 00:42:37 orangepii96 wpa_supplicant[257]: wlan0: CTRL-EVENT-CONNECTED - >
Sep 03 00:42:37 orangepii96 wpa_supplicant[257]: wlan0: WPA: Key negotiation co>
Sep 03 00:42:36 orangepii96 wpa_supplicant[257]: wlan0: CTRL-EVENT-SUBNET-STATU>
Sep 03 00:42:36 orangepii96 wpa_supplicant[257]: wlan0: Associated with d4:5d:6>
Sep 03 00:42:35 orangepii96 sudo[731]: pam_unix(sudo:session): session closed f>
Sep 03 00:42:34 orangepii96 wpa_supplicant[257]: wlan0: Trying to associate wit>
Sep 03 00:42:32 orangepii96 kernel: cfg80211: Calling CRDA for country: US
Sep 03 00:42:32 orangepii96 wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED>
Sep 03 00:42:00 orangepii96 sudo[731]: pam_unix(sudo:session): session opened f>
Sep 03 00:42:00 orangepii96 sudo[731]: orangepi : TTY=ttyS0 ; PWD=/home/orangep>
Sep 03 00:41:52 orangepii96 sudo[700]: pam_unix(sudo:session): session closed f>
Hey Steve,
Great observations. This makes sense to me. The reason I say that is that I honestly have not had nearly the trouble with the wireless as other people. It’s not perfect but I have left this image running on it for days at a time and still been able to reconnect wirelessly.
My network is not typical though. I have 6 Unifi access points mounted all over the place throughout the house including a couple within line of sight of the device. The network conditions couldn’t be more ideal. I’d imagine if someone just has like, a normal wireless router, that this weak antenna may barely be able to hold a link. This seems to be part of what you’re uncovering here for sure as these logs are clean and not filled with errors for this.
Did you get a chance to try with V1.7? It may not have any impact if you’re right but the hostapd service was starting and crashing over and over again before and it’s possible that may have been causing the wireless to drop (or some of it, maybe part of the DNS?). The hostapd is supposed to configure your wireless card as an access point other devices can connect to. It had no hostapd.conf so it was just crashing over and over so I removed the broken base package (since if someone still wants to do this if they install it fresh from apt they will configure a working hostapd.conf with it).
Your CRDA looks good. It’s definitely happy with that now. I don’t see any errors. I think you’re right. It looks like standard disconnects related to signal strength to me in that output as well (there’s no errors which is because it thinks you’re probably moving away from that base station to transition to a different one in range which is normal behavior).
In other words since we are just getting a “CTRL-EVENT-DISCONNECTED” signal strength is by far the most likely explanation. This is just a normal notice/event rather than a warning/error since most mobile/IoT stuff is designed to be able to move (or at least has those capabilities available with addons). People could just be moving away from the access point on a mobile device for example and then you would expect it to disconnect and transition to either another base station or another network in the range of where they are moving to.
Do you have a higher quality antenna you could test with it? The connectors on it should fit antennas from other SBCs or IoT devices if you have any other ones around known to be of higher quality (probably anything else will be better realistically than what they gave us on a board at this price point). That would be a worthy test to see how it impacts the stability and if you can possibly maintain a stable connection for a long period of time! If we get some evidence that it can hold a stable connection with an antenna swap I’m sure there are probably <$5 parts available on Amazon and AliExpress that would improve this signal dramatically.
I am running v1.7
I was able to clone and start the klipper3d repo (my main use case for the i96) in one try!
I am going to research (connector type varies) antenna and order some – I see many on Amazon
Hey Steve,
Ahh, I may be able to be of assistance there! Specifically you are looking for a U.FL connector antenna. There are actually a lot of adapters to take it to a larger antenna size too (in fact I’d say there are more adapter options than antenna options but you will see what I mean). These types of antennas/connectors are super common on drones especially.
That is definitely the kind you want though. It’s a standardized connection fortunately and not proprietary in this case. I think this is an ideal test and I’m excited to see what you find!
Thanks!
I also found that the US setting was not ‘taking’ and I found this article.
Ahh yes, that is what I was looking for! The method I gave you wouldn’t have survived reboots either. I couldn’t remember where the config file for this was.
The only thing is that it doesn’t exist on the device right now. I then realized the crda package isn’t installed. Ugh! NOW I have a /etc/default/crda:
orangepi@orangepii96:/etc/default$ cat crda# Set REGDOMAIN to a ISO/IEC 3166-1 alpha2 country code so that iw(8) may set
# the initial regulatory domain setting for IEEE 802.11 devices which operate
# on this system.
#
# Governments assert the right to regulate usage of radio spectrum within
# their respective territories so make sure you select a ISO/IEC 3166-1 alpha2
# country code suitable for your location or you may infringe on local
# legislature. See `/usr/share/zoneinfo/zone.tab' for a table of timezone
# descriptions containing ISO/IEC 3166-1 alpha2 country codes.
REGDOMAIN=
and that is where you would put your regulatory domain. Perfect. I’ll update the instructions (and I’ll have to update the image to include the crda package for 1.8). Thanks!
EDIT: This is up now but for you specifically you could just do sudo apt install crda if you haven’t already! It’s mostly for anybody downloading it new and to match the new documentation.
Thanks. That’s better than hacking the systemd.
I’ll try it
re CDRA for US. I found kernel code was looking in the environment for a code so:
on the command line:
$ export COUNTRY=USI got a lot of output 😉 but now
sudo iw reg getshows US – where before it was not stickingmy solution: In /etc/systemd/system/dbus-fi.w1.wpa_supplicant1.service
I added the Environment line in the [Service] section:
[Service]Type=dbus
BusName=fi.w1.wpa_supplicant1
Environment="COUNTRY=US"
ExecStart=/sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
Hello James,
Great job, thank you for the updates and the tutorial.
I’m running your latest Image Bullseye 1.3 got from your git repo, and I see overuns on the serial cnsole.
I see also bad characters definition/encoding with orangepi-config menu and with locale reconfiguration.
Any clue how to fix that.
I’m going next to generate my own image for development purposes.
My Best
Hey MZA,
I’m actually not sure about this one yet. I don’t actually have a USB to TTL converter! I should get one though because they are super inexpensive and it would help me debug some other things as well. Which baud rate are you using? A lot of people are saying it’s when you use baud rates too high but if you’re using a standard baud rate then I’d imagine this is something that needs additional fixes.
It could be something like this.
Those ones are typically fixable with kernel flags. We could definitely change these in this build. I haven’t changed any build flags yet (everything has been kernel drivers so far) but you absolutely can rebuild the kernel flags. You can do a make menuconfig inside the OrangePiRDA kernel folder and see all of the options. They will be overwritten if you change them that way but you can permanently change kernel flags by changing the OrangePiRDA/kernel/arch/arm/configs/i96_linux_defconfig. That is the default build flags for the device and if you change them there it should build with them.
I may need your help on this one since I don’t have the TTL adapter yet. I can definitely get one though and I probably should. Hopefully that helps!
Yes sure I can do.
First, I think that the high serial bitrate 921600 is what is set by the boot rom, even before uboot. Changing console bitrate may be done by changing the bootcmd in uboot.
Now from the stakoverflow thread, with “make menuconfig” :
HSUART is not found ( old kernel),
CONFIG_8250 are all disabled,
CONFIG_DW is tens of flags, most of them disabled.
DMA also is disabled on most of device drivers and especially SERIAL_RDA_UART_DMA [=n]
Now I have used the same bitrate for the Xenial image and the display was correct, the wrong chars encoding in the orangepi-config menu appeared in the bullseye images 1.2 and 1.3.
I’m switching to more recent kernel, I’ve found a discussion that RDA8810pl and i96 were added to kernel since 5.0.2. It has not booted yet but it’s interesting to have more recent kernel and make more peripherals run. I need I2c, spi, spidev, socketcan, CAN with mcp2515, gpios etc. I have’nt spent much time on bullseye to check them or add them.
Regards.
Hey MZA,
Excellent testing and diagnosing. All your findings and conclusions look right to me here!
Let me know how it goes with a new kernel. I would not be surprised if a newer kernel just straight up fixes this without any further configuration. I would also love to use a newer kernel in this if it’s working well!
I’m honestly afraid to try a newer kernel because I feel like it would open a huge can of worms and create completely new issues that nobody has really seen before related to the newer kernel. I’m definitely trying to avoid that for sure as that’s way beyond the scope of what I was trying to do with the image but if the kernel is already demonstrated to be working well with the Orange Pi i96 without a bunch of weird new issues I am 100% on board with moving to a newer kernel.
To be clear you are saying that this does not happen in version 1.1 correct? That’s very interesting. That is definitely after I made the UART driver change which is supposed to fix copy/pasting over the serial console. Only 1.0 wouldn’t have that change.
In fact 1.2 would point to locales. That was the only change I made in that version besides adding ntpd which definitely wouldn’t have anything to do with it. The locales very much would though especially strange symbols appearing. I made this change to prevent all the warnings related to locales during package configuration but if your default locale isn’t the same as mine then it’s possible I traded one issue for another for you. The fix for both of those issues should be to set the correct locale.
Can you try the following:
sudo dpkg-reconfigure localesSelect your correct locale and let it generate your locales. Can you then try orangepi-config again? It may possibly need a reboot but I believe the locales are supposed to change on most things immediately. I wonder if the strange symbols will be gone. If they are I probably need to reconsider applying a default locale if it breaks things that were working with having no locale set at all. That was definitely not my intention so let me know if this ends up being the problem.
I also wonder if this is breaking the serial terminal in some way since it’s possibly expecting a different locale. The default images had no locale set. It’s now set to en-US as of version 1.2. This has to be what the problem is. The question is will regenerating the correct locales take care of it for you? I think that it is worth a try!
EDIT: I reverted this change in 1.4 so as soon as it finishes uploading can you try again with 1.4?
Hi James,
Re configuring the locales to add en_US.UTF-8 and en_US.ISO-8859-15 and setting SYSTEM env variables locale to en_US.ISO-8859-15 worked this time. Menus ( dpkg-reconfigure locales and orangepi-config) are displayed correctly.
I’ve seen no more overruns on the serial port and copy paste to edited file ( with vi) of hundreds of chars worked fine.
Congrats and thank you.
My best.
It was with your bullseye 1.4
Hey MZA,
Thanks for confirming that! I reverted that change in there because it doesn’t really break anything to not have a locale set in the main image. I did add a first startup instructions to set the locale to the README as well as syncing the time and a couple of other quick start steps.
I think this is a better solution than me forcing the en-US locale in the image. Even if people don’t reconfigure the locale there doesn’t seem to be any negative consequences of having none set (other than annoying but otherwise harmless package configuration errors related to locales from Perl). There does seem to be negative consequences to having the wrong one set though. Thanks again for confirming!
Hey MZA,
You’re very welcome, thanks for trying it and following up with me!
If you mind, I’ll continue testing with you. I’m interested in bringing up more peripherals ( spi/CAN through MCP2515) on this board.
I’ve compiled the spidev device as a loadable modules, it can be inserted but does not bring the /dev/spidev.
here’s what I see
orangepi@orangepii96:~$cat /sys/bus/spi/devices/spi0.0/modaliasspi:rda-dpi-panel
orangepi@orangepii96:~$cat /sys/bus/spi/devices/spi0.1/modalias
spi:tlv320aic23-spi
Does this mean that the spi are already used ? ( ALSA SoC TLV320AIC23 codec driver )
orangepi@orangepii96:~$ find /sys/bus -name "*spi*"/sys/bus/spi
/sys/bus/spi/devices/spi0.0
/sys/bus/spi/devices/spi0.1
/sys/bus/spi/drivers/spidev
/sys/bus/platform/devices/rda-spi.0
/sys/bus/platform/devices/rda-spi.1
/sys/bus/platform/devices/rda-spi.2
/sys/bus/platform/drivers/rda-spi
/sys/bus/platform/drivers/rda-spi/rda-spi.0
/sys/bus/platform/drivers/rda-spi/rda-spi.1
/sys/bus/platform/drivers/rda-spi/rda-spi.2
Hey MZA,
I’d love that, that would be great! So with any modern kernel / distribution it means that we need to add spidev to the device tree file for the device. This isn’t too unusual. Here’s some instructions.
There’s only one problem. This kernel / uboot is older than that. It doesn’t use device trees at all for the RDA board. If you look through the OrangePi_Build tree almost every other device does use a device tree / dtb but you will find there is no such file used at all for the RDA board. This would be trivial to modify. I think other boards that are still supported also went through this but they all appear to have been updated to use device trees (except the i96). If you Ctrl+F or bulk search the source code for .dtb you will find them and how they work for the other boards.
In other words I’ve already enabled everything necessary for this to work except for the device tree. I don’t think this uses a device tree. It seems to me like it’s all hard coded drivers. I think that what we need to modify is the uboot part of the distribution as that is where it is on all the other boards. I’m definitely familiar with the kernel and device trees and have been doing it that way since… at least the Raspberry Pi 2 or so and I want to say even the Pi 1. These older kernels I’m definitely not as familiar with.
This is absolutely trivial on a modern board. It’s actually trivial on most boards. The 5.X kernel also natively supports the i96 but apparently the storage isn’t mapped so all you can do is boot into an initramfs and can’t map the SD storage. On this board it’s all hard coded and I’m not sure where to look for it. If you can figure out how to change the device mapping though everything should be in place for this to work. I doubt it would even need the image to be recompiled if we knew where / how to map spidev on this board (unless it’s hard coded in the kernel itself which it might be on this one)!
I honestly think we are partly reliving the lives of the Orange Pi team as well as the Armbian team looking at the work that needs to be done and just literally every single thing is pain. The entire kernel needs to be completely revamped (which they did on their still supported boards), it probably needs a completely new wireless driver or updated wireless driver as well. I try to ignore that because that is literally what sunk anyone even trying to do anything with this board. My goal is to just get as many fixes in it as we can and publicly release those so that if this board does break me that all the work we did is still out there and easy to build / available for everyone!
I still think it’s worth it as the work done already has made it viable for light headless applications. I would absolutely love to get the spidev interface working though. If that happens we are actually having a different conversation at that point. That would make it basically a fully featured board for under $10. There literally is no such thing right now and there may never have been. I guess the Pi Zero is close but good luck getting one of those for very far under $100 these days!
Uboot is old and does not use dts. The kernel 3.10 does.
I’ve searched in uboot code ( after retrieving compilation steps in the scripts) for ports settings and passing them to kernel and I found nothing.
I’ve at the end found this document from freescale / nxp that explains how to make recent linux ( with dts) boot from older uboot. Interesting.
Google search “old uboot dts” if the link does not work.
In summary, if uboot does not provide the device tree to the kernel, then they can be appended to zImage when building the kernel.
Hope this helps.
Hey MZA,
Yes, this looks like exactly what I need. It’s right from the right time era and they’re even using the linaro toolchain. I will investigate and report back!
EDIT 1: It looks like CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT are not set. There is no /sys/firmware/devicetree/base, no /proc/device-tree. There’s nothing present I can just ask it what device tree it is using.
I then looked for more ways to find out what exactly it’s doing. This led me to fdtcontroladdr. I was able to find a reference to this in /uboot/arch/arm/lib/board.c. Is this being used? Yes, but it specifies by memory address where the blob is.
All OrangePiRDA’s build process is for uboot is this:
"OrangePiRDA")echo -e "\e[1;31m Configure OrangePi 2G-IOT or i96 \e[0m"
# make CROSS_COMPILE=${TOOLS} clean
make CROSS_COMPILE=${TOOLS} rda8810_config
echo -e "\e[1;31m Compiling Uboot \e[0m"
make CROSS_COMPILE=${TOOLS}
cp -rf ${UBOOT}/u-boot.rda ${UBOOT_BIN}
;;
Okay, so let’s look at rda8810_config.
There’s also a uboot/configs/rda8810.h. Oh boy.
#ifndef __CONFIG_H#define __CONFIG_H
#include
/*
* SoC Configuration
*/
#define CONFIG_MACH_RDA8810
#define CONFIG_MACH_TYPE (5002)
/*
* Flash & Environment
*/
/* #define CONFIG_NAND_RDA_DMA */
#define CONFIG_NAND_RDA_V1 /* V1 for rda8810, rda8850 */
#define CONFIG_SYS_NAND_MAX_CHIPS 1
// Enable RDA signed bootloader:
#define CONFIG_SIGNATURE_CHECK_IMAGE
#define CONFIG_SYS_CACHELINE_SIZE 32
#endif /* __CONFIG_H */
Oh sure. This led me to uboot/configs/rda_config_defaults.h. Okay. This doesn’t look like a device tree but it wouldn’t surprise me if this is one of the key files we have to change. I have no idea what to do with it though nor have I seen or read anything that suggests to me this is the right place although it’s the closest looking I’ve found.
Alright, so let’s go back to the rda8810_config. Is this going anywhere? I doubt it. I just go in circles for hours and hours with this because the whole thing shouldn’t work as far as I understand how the kernel works. Okay, let’s finish up this part of the investigation though. I assume that it’s using uboot/kernel/arch/arm/configs/rda8810_config. So I go to that file and it is… just another copy of the kernel configuration file. It’s not one I’ve modified yet but this is not a device tree nor will it make one. I might as well replace it with my updated config so they match but there’s no way this will make spidev appear.
That leaves me basically right where I started. Where is the device tree? How is it doing it? It has none of the kernel flags set for it to be built into zImage. There’s no uboot.dtb file generated even though it’s referenced in some of the files. There’s no /proc or /sys entries for device trees that would tell me what it’s even using. It does not work the way as these instructions are suggesting. That would actually be an upgrade to how it works.
We need even older documentation apparently. It doesn’t use or support this method (the flags aren’t set and I’d pretty much have to write it in which makes no sense vs. just starting with a new uboot). It’s even older of a method of this that it’s using apparently even though these documents are from 2009-2010. This honestly would explain why I’ve never encountered a kernel like this *EVER*. Once you get back to 2005 that is the year I graduated from High School. I was still in college when this document was written (for Psychology and would have an 8 year social work career oddly enough) but if the kernel worked this way I could absolutely work with it much easier still.
I have no idea how to work with this. It would be easier for me to start with a new uboot and a new kernel. It really would. You can absolutely see why so many people tried this and reached the conclusion they should try with a new kernel (and are never heard from again). It’s an obvious choice vs. trying to work with such an old and janky codebase. It’s also completely unreasonable for one person to do on their own for no money. It’s so, so painful to try and figure out how something this old works (they were using 10+ year old code when they made this board which now it has been many years since then on top of that) that doesn’t work this way anymore for very, very good reasons!
I think the new kernel would be workable if you figured out how to map the storage on it. I’m guessing it’s not as easy as just adding a device tree entry for the SD card port or nobody would be talking about it like it’s an obstacle. It would help to understand how it is working now as I have spent several days on it and have not even been able to LOCATE a device tree where we would add in spidev entries. It’s another question entirely how the storage is all being mapped right now and is working. It all just must be custom code/drivers in this kernel since it definitely had no mainline support until I want to say 5.X but it may have been late 4.X.
Someone tried porting the uboot as recently as like 24 days ago. Her name is Julia. Her comments on her commits are “I hate myself for doing this”. Anyone who has tried this will say that for sure. It really couldn’t be more difficult/painful of a problem even for experienced Linux / kernel people. It’s like every possible thing that could go wrong or make it as difficult as humanly possible to do something is not only there but there in ways that exceed what I thought was possible!
A lot of smart people have worked on this problem already. Combining everyone’s knowledge together has yielded an improved image for sure across the board. I wonder if Julia figured out enough of how this works that she could tell me where on earth (or elsewhere) the device tree / device mapping is happening on this uboot combined with a kernel that is supposed to use device trees (but has literally no sign of them in /proc or /sys)!
I don’t believe it. I think I got it. You won’t believe what I had to do to fix it.
It was all hard coded. 100% of it. It’s in kernel/arch/arm/marc-rda/devices.c.
I had to add a new device here:
static struct spi_board_info rda_spi_board_info[] = {#ifdef CONFIG_FB_RDA_DPI
{
.modalias = RDA_DPI_PANEL_DRV_NAME,
.max_speed_hz = 500000,
.bus_num = 0,
.chip_select = 0,
//.controller_data =
},
#endif
{
.modalias = "tlv320aic23-spi",
.max_speed_hz = 1000000,
.bus_num = 0,
.chip_select = 1,
.controller_data = (void *)&tlv320aic23_spi,
},
{
.modalias = "spidev", // driver name
.max_speed_hz = 32000000,
.mode = SPI_MODE_0,
.bus_num = 1, // our spi number is 1
.chip_select = 0,
},
};
I also needed to add a spi-gpio controller to the driver. It did not have one before.
The final result:
orangepi@orangepii96:~$ sudo dmesg | grep spi[ 0.628662] spi_gpio spi_gpio.3: registered master spi3
[ 0.629150] spi_gpio spi_gpio.3: master is unqueued, this is deprecated
[ 0.630126] rda-spi rda-spi.0: registered master spi0
[ 0.630615] rda-spi rda-spi.0: master is unqueued, this is deprecated
[ 0.631408] spi spi0.0: max_speed_hz = 500000, bus_speed_hz = 200000000, divider = 199
[ 0.632385] spi spi0.0: setup mode 0, 8 bits/w, 500000 Hz max --> 0
[ 0.633178] rda-spi rda-spi.0: registered child spi0.0
[ 0.633789] spi spi0.1: max_speed_hz = 1000000, bus_speed_hz = 200000000, divider = 99
[ 0.634765] spi spi0.1: setup mode 0, 8 bits/w, 1000000 Hz max --> 0
[ 0.635620] rda-spi rda-spi.0: registered child spi0.1
[ 0.636291] rda-spi rda-spi.1: registered master spi1
[ 0.636779] rda-spi rda-spi.1: master is unqueued, this is deprecated
[ 0.637695] spi spi1.0: max_speed_hz = 32000000, bus_speed_hz = 200000000, divider = 3
[ 0.638610] spi spi1.0: setup mode 0, 8 bits/w, 32000000 Hz max --> 0
[ 0.639587] rda-spi rda-spi.1: registered child spi1.0
[ 0.640136] rda-spi rda-spi.2: registered master spi2
[ 0.640686] rda-spi rda-spi.2: master is unqueued, this is deprecated
orangepi@orangepii96:~$ ls /dev | grep spi
spidev1.0
This is now uploaded as V1.5. Figuring out this issue was honestly one of the hardest things I’ve ever done on the site, no question about it! It’s straight C built right into the kernel on this one. No device tree in sight for this board. To get an idea of where I had to start I had to translate a 5 year old post from what I assume is Russian. The winning Google query was:
"rda8810" spi_board_infowith a grand total of one result. I was pretty sure this was what I needed to find after hours and hours of research on ancient hardcoded boards and to my shock this guy had done it with the i96 2G more than 5 years ago (and literally nobody else ever best I can tell). Whoever that guy is he is definitely a genius. It looked like to me like he just casually decided to do this and completely rewrite the hardcoded driver like it was nothing (even adding completely new functionality / a new controller for the GPIO SPI).
It does not cover how to add spidev (he only mentioned that it was possible and this is where you would want to do it) but just knowing where to go gave me enough to start. That was by far the most frustrating part since it’s hard coded into the kernel among literally thousands and thousands of files many of which have additional copies in other places you also need to find / change and it goes on and on.
Will it work? I have no idea, it might need another change and I saw some things online that suggested you may need a display driver for this to work but I’ll leave that to you if you can access the interface. You may want to run that link through Google Translate like I did because he literally covers doing a screen with it (but he says it’s slow). His was a full TFT but if yours is something like a digital display it will probably work fine.
If it needs further tweaks that will be easy compared to what had to be done to get to this point!
Incredible what you have done so far!
I have tested V1.5 but SPI is not working. I am able to open the device, but when I try to send data over SPI 1.0 the system freezes and I have to reset it. I tested python and c, the result is the same.
After looking at the schematics and the RDA8810PL datasheet I don’t understand why our spi should be spi1.0.
The schematic says SPI2_CLK, DIO, DI, CS_1 is connected to GPIO_A_2, 3, 4, 6. The full RDA8810PL datasheet confirms this.
Hey Michael,
It’s basically whatever we say it is. I don’t think I’ll be able to fix it without buying a SPI device. I’d just have to change the bus and other parameters until it works. I will not be able to get one of these before I go to Vegas on Monday unfortunately.
If I had followed what the original person did I would have actually made it on bus 3 which would have made it show up as spidev 3:0. There are several SPI devices connected to the system that you can’t access as well. One is the sound card and one is the actual RDA display-out port. You can see those devices showing up (these are the only things you could detect without the spi_gpio driver). There is zero SPI GPIO support in the base image. It doesn’t exist and it never did.
Basically the way to fix it is I will have to change the parameters and build it over and over again until it works. I’m just guessing though and I have no way to test / adjust the parameters at all. I do not have a SPI device to hook up to it to test it at the moment!
I hope the problem is what you say. I notice though that this bus number is used by a lot of other boards for spidev such as the Orange Pi Zero. I honestly hope this is what is wrong and not anything way, way more complicated than that.
Basically if neither of you are able to build / adjust it I will have to get some hardware to do this.
The most basic test for the SPI would be just a loopback connection from DI to DIO. You don’t need extra hardware for that. But the I96 crashed somewhere in the sending data part. I have never build a Linux system before. Maybe I can narrow down the part where the crash happens.
Hey Michael,
That would be great! I’ll see if I can get something like that set up. I was at least able to freeze the board so that is what I needed to have happen.
I’m guessing I need this:
.controller_data = (void *) 5, // CS pinExcept everything I’m reading says the CS pin should be 6. It could be different on the i96 2G (there are some differences) or they could not be counting from 0. I’m adding that part in here though and I’ll test and see if it’s still freezing here!
I don’t have to guess though so now I can just rebuild the kernel and keep trying it here.
Hey Michael,
I think I got it here thanks to your tip. Here’s what I’m getting now (no lockups):
orangepi@orangepii96:~$ sudo python3 test.py0x00 0x00
0x00 0x00
0x00 0x00
I actually changed the interface address to match the other person’s because I have literally no clue what I’m doing. That means that the spidev interface is actually now 3:0. Can I change it? Yes, but I just want to get it working first and then we can make it pretty later!
I did not do a loopback connection yet. This is with nothing connected so 0x00 should be the expected result. I wasn’t even able to do that before without it locking up the entire board in what I assume is a kernel panic.
There were a couple of problems. First I wasn’t matching the ID to the new spi_gpio controller (which is why the interface is 3:0 now, but if you find it is working I would change everything to match to a lower number but since I’ve never done anything like this before I want to start with what was known working and then modify it from there).
Second I didn’t include the CS pin. That was this line:
.controller_data = (void *) 5, // CS pinIt turns out this is obviously pretty important. If it doesn’t know what the right CS pin is I’m sure it was just crashing and burning.
I’m uploading 1.6 if you can give that a try here in a bit!
Fantastic, you’ve done a great job.
Thank you very much. I am reading your explanations and I will test it asap.
Bravo
I’ll receive a small TFT in the coming days and I’ll try the same, thank you for this miraculous link and tips. I think the dislay I’ll get is a cheap i2c display, but I have, since years now, an e-Ink spi display that has never been used. I’ll try it if the first is not satisfactory.
For now I’ll focus on the mcp2515, it is to be connected to the spi from the 40 pin header, it needs a GPIO interrupt and a slave select. If it works, it will bring CAN interface to the board.
I guess I must add this device and GPIO pin number in the files you’ve already modified ?
Hey MZA,
Yes I’m not sure how you could get this module working exactly. It looks like there’s a few problems. The first one is they want you to use an overlay. There are no overlays for this. I just had to fight with it for days to figure out there is no such thing. From their documents:
dtparam=spi=ondtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25
dtoverlay=sp1-1cs
This has to be hardcoded on this board unfortunately. There aren’t any overlays. I’m not sure how you would do this at all.
On the Orange Pi people have done it before. Not with this one though. That is an Orange Pi that uses overlays via dtb/dts files.
In other words the problem is drivers. This board doesn’t support overlays which basically makes writing stuff like this dead simple. There needs to be a hardware driver in the kernel for this to work just like everything else on the system because this kernel was never upgraded to use device trees / overlays and everything is purely kernel driver based. This controller may have a kernel module that can be built though with some kernel flags. If there is support in this kernel for it (even if it’s not enabled) this would be much easier to fix that way.
Theoretically this device does support device trees. Is it possible to use overlays with it still even though they are not used for anything? It has the dtc compiler in it. I’m not sure though, this would take some experimentation and nobody has ever done it before. It’s pretty clear to me that I probably won’t be able to figure out more without getting a SPI device. I’ve found where everything is but I’d just have to put out 20 different versions guessing different settings and that probably isn’t a good use of time here.
This person seemed to have done it using the built-in drivers but it’s not using a CAN controller I don’t think.
The good news is can-utils are available in the orangepi repository with:
sudo apt install can-utilsTherefore it’s not hopeless but you are right that this is going to take some creative thinking / some doing. This is absolutely why device trees are a thing. That just makes it easier though. It’s not impossible.
If you were to hardcode this you are right that everything would need to be put into device.c. With any luck you’d just need to select the right driver theoretically but I cannot find an example of anyone ever doing this on a board that doesn’t use overlays. If it had overlays it would have been about a 3-4 line change to enable the spidev interface!
Hello James,
Thank you fot the guide and the Debian Bullseye Image.
I am using an Amazon basics USB to Ethernet adapter. It is working fine.
Is there a way to get SPI working?
Hey Michael,
No problem at all and welcome! Can you clarify what you mean by SPI working? I assume you are referring to the 512MB internal SPI flash on the board.
It can definitely work with Android but it’s definitely too small for Linux. Even the server version image is something like 1.2GB-1.3GB in size so there’s just no way it’s going to fit in there. There are certain Linux flavors that could but not the official ones or Debian. It would almost need to be a busybox-based one with only 512MB.
Or do you mean the SPI pins / GPIO? That is covered in the Orange Pi wiki here but I probably should just implement the GPIO utility in the image. I don’t know why they’re having people build it. Let me know exactly what you’re trying to do though and I should be able to help further!
EDIT: I did just fix the GPIO pins which should allow accessing the SPI pins now. I used patb’s tool here. If you’re trying to access the GPIO pins can you try with version 1.3 when it finishes uploading here?
The new version looks like this with the included tool:
orangepi@orangepii96:~$ sudo gpio statusBoard auto-detect found OrangePi i96. To skip auto-detect, create a file named /etc/OrangePi-i96
+-----+-----+----------+------+-+ OrangePi i96 +-+------+----------+-----+-----+
| gpio| alt | i96 Name | Mode | V | Physical | V | Mode | i96 Name | alt | gpio|
+-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+
| | | GND | | | 1 || 2 | | | GND | | |
| 40 | CTS | UART2.CTS| alt | ? | 3 || 4 | | | PWR_BTN_N| | |
| 104 | TX | UART2.TX | alt | ? | 5 || 6 | | | RST_BTN_N| 1.4v| |
| 103 | RX | UART2.RX | alt | ? | 7 || 8 | ? | alt | SPI2.CLK | CLK | 2 |
| 41 | RTS | UART2.RTS| alt | ? | 9 || 10 | ? | alt | SPI2.DI | DI | 4 |
| 14 | TX | UART1.TX | alt | ? | 11 || 12 | ? | alt | SPI2.CS | CS | 6 |
| 102 | RX | UART1.RX | alt | ? | 13 || 14 | ? | alt | SPI2.DO | DO | 3 |
| 0 | SCL | I2C2.SCL | alt | ? | 15 || 16 | ? | alt | I2S.LRCK | LRCK| 10 |
| 1 | SDA | I2C2.SDA | alt | ? | 17 || 18 | ? | alt | I2S.BCK | BCK | 9 |
| 38 | SCL | I2C3.SCL | alt | ? | 19 || 20 | ? | alt | I2S.DO | DO | 13 |
| 39 | SDA | I2C3.SDA | alt | ? | 21 || 22 | ? | alt | I2S.DI | DI | 11 |
| 15 | CTS | GPIO.A | in* | 0 | 23 || 24 | 0 | in* | GPIO.B | LCD | 20 |
| 56 | ROM | GPIO.C | out | 0 | 25 || 26 | 0 | in* | GPIO.D | CTS | 66 |
| 67 | RTS | GPIO.E | in* | 0 | 27 || 28 | 0 | in* | GPIO.F | LCD | 22 |
| 30 | LCD | GPIO.G | in* | 0 | 29 || 30 | 0 | in* | GPIO.H | LCD | 29 |
| 28 | LCD | GPIO.I | in* | 0 | 31 || 32 | 0 | in* | GPIO.J | LCD | 27 |
| 26 | LCD | GPIO.K | in* | 0 | 33 || 34 | 0 | in* | GPIO.L | LCD | 25 |
| | 1.8v| V_PAD | | | 35 || 36 | | | SYS_DCIN | n/c | |
| | 5V | VDD_IN | | | 37 || 38 | | | SYS_DCIN | n/c | |
| | | GND | | | 39 || 40 | | | GND | | |
+-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+
Note: *these pins are set to GPIO mode but do NOT have exports in /sys/class/gpio
According to patb:
That little script will run at boot time, and change the gpio pins on the 40 pin connector (pins 23-34) into true GPIO pins, and it'll restore proper operation of the UART2 and SPI2 pins (pins 3,9,8,10,12,14) NOTE: this is OrangePi-i96 specific; do not use on the 2G-iot boardI have implemented this script as a systemd startup service on the board (sudo systemctl status gpio_fixup) so the SPI2 pins should be working now!
Thank you for the link to patb’s tools. I get the same gpio status as you.
The hardware for the spi seems to be OK, though it says spi0.1 instead of spi2:
root@orangepii96:~# dmesg | grep spi[ 0.551757] rda-spi rda-spi.0: master is unqueued, this is deprecated
[ 0.552429] spi spi0.0: max_speed_hz = 500000, bus_speed_hz = 200000000, divider = 199
[ 0.553466] spi spi0.1: max_speed_hz = 1000000, bus_speed_hz = 200000000, divider = 99
[ 0.554443] rda-spi rda-spi.1: master is unqueued, this is deprecated
[ 0.555236] rda-spi rda-spi.2: master is unqueued, this is deprecated
But there is no spidev
root@orangepii96:~# ls /dev/spidev*
ls: cannot access ‘/dev/spidev*’: No such file or directory
I want to use the SPI with a python script for an e-paper display. But I am stuck here without the spidev.
I got this up and running on my orangepi zero 2!
Hey Michael,
Thanks for following up with me! It looks like the spidev kernel module isn’t built in the default Orange Pi kernel.
I’m building version 1.4 right now which will have this driver enabled. Can you try with 1.4 once it’s available here?
EDIT #1: It’s not going to be easy to enable it. I’ve never found anyone who was able to do it before and it looks like I need to recompile some dtb files. This may take some time! It’s not in 1.4 yet but there’s some other fixes in there.
EDIT #2: I think I’m getting closer. This is in the upcoming V1.5 but here’s what it looks like so far (still no spidev yet):
orangepi@orangepii96:~$ sudo dmesg | grep spi[ 0.628906] rda-spi rda-spi.0: registered master spi0
[ 0.629333] rda-spi rda-spi.0: master is unqueued, this is deprecated
[ 0.630126] spi spi0.0: max_speed_hz = 500000, bus_speed_hz = 200000000, divider = 199
[ 0.631103] spi spi0.0: setup mode 0, 8 bits/w, 500000 Hz max --> 0
[ 0.631958] rda-spi rda-spi.0: registered child spi0.0
[ 0.632568] spi spi0.1: max_speed_hz = 1000000, bus_speed_hz = 200000000, divider = 99
[ 0.633483] spi spi0.1: setup mode 0, 8 bits/w, 1000000 Hz max --> 0
[ 0.634338] rda-spi rda-spi.0: registered child spi0.1
[ 0.635009] rda-spi rda-spi.1: registered master spi1
[ 0.635559] rda-spi rda-spi.1: master is unqueued, this is deprecated
[ 0.636413] rda-spi rda-spi.2: registered master spi2
[ 0.637084] rda-spi rda-spi.2: master is unqueued, this is deprecated
EDIT #3: I haven’t been able to crack this one still. I know I have to be close. On other boards I would modify the .dtb files but the RDA kernel/uboot doesn’t seem to use a dtb file at all. That means it’s all hard coded somewhere and I’m not sure where to find it yet. The devices can be seen at:
orangepi@orangepii96:/sys/bus/spi/drivers/spidev$ find /sys/bus -name "*spi*"/sys/bus/spi
/sys/bus/spi/devices/spi0.0
/sys/bus/spi/devices/spi0.1
/sys/bus/spi/drivers/spidev
/sys/bus/platform/devices/rda-spi.0
/sys/bus/platform/devices/rda-spi.1
/sys/bus/platform/devices/rda-spi.2
/sys/bus/platform/drivers/rda-spi
/sys/bus/platform/drivers/rda-spi/rda-spi.0
/sys/bus/platform/drivers/rda-spi/rda-spi.1
/sys/bus/platform/drivers/rda-spi/rda-spi.2
/sys/bus/platform/drivers/spi_gpio
So clearly everything is being seen here but still no /dev/spidev. I’ve installed the appropriate drivers here including spidev and spi_gpio. There’s still some step missing here and I’m pretty sure it’s the equivalent of editing the .dtb files for the board. Since those don’t appear to be used in this old version of uboot it’s hard coded somewhere and I have absolutely no idea where. I also can’t find any examples of anyone doing anything like this (or ever using spidev on the board).
It should absolutely be possible to do but I don’t know where to look yet exactly for this. No board released in a long time works like this anymore. All modern kernels use device trees / dtbs but this one is before that and does not appear to be using them (at least not with uboot, maybe it’s using one hard compiled into the kernel itself, again this stuff is so old that I’m not sure as even very early versions of the Pi used dtbs).
Somebody out there will know or remember exactly how this works (or I’ll continue to investigate and finally find a breakthrough as tends to happen sometimes). I’m sure it’s easy if you have a strong understanding of the structure of these earlier 3.X kernels and the uboot versions from the time but it’s like looking for a needle in a haystack if you don’t trying to find some of these hardcoded options that are normally much more modular / accessible in modern kernel versions (and uboot versions as well, it’s all been changed/upgraded from the official Orange Pi one which is something like a minimum of 5-6 years old making it much harder to find relevant information). This is some older school knowledge that people who were working in the industry at the time will just know I’m sure.
Hello James, could you please inform what is the model of the USB to Ethernet device are you using? I’ve been trying a few models an the Linux doesn’t recognize other network interface, probably is because the old Linux doesn’t have the drivers. So I’m looking a model that works in orange pi I96
Hey JeShcmitz,
I’m actually using that at this very moment to work on answering Andy’s question (hang in there Andy!). Ironically it is a Microsoft adapter. I tend to use generic ones that are bundled by the manufacturers of laptops and tablets. Here’s the specific one:
This one was probably from an older Surface but it may have been another Microsoft product potentially. I also have ones from HP and I have a USB 2.0 Belkin one that I’ve used in the past (but not with the i96). I can definitely give those a try as well (let me finish with Andy’s first) but wanted to show you the one I specifically was using!
EDIT: I tried with one even a little bit more interesting. This is a HP one using a USB-C RJ45 adapter with a USB-C to USB-A adapter (comes with newer higher-end HP business/enterprise laptops as an included in-box accessory a lot of the time) and it also worked perfectly:
Big Version (HP)
It doesn’t seem too picky so far with newer ones and USB 3.0 ones. The HP one is quite modern being USB-C (the little USB-C to USB-A adapter also comes in the box with the laptops that include these). It has a P/N on it so I’m sure you could find one but these are just basically ones I have just got for free over the years as accessories from different stuff (or from my IT tech career when people already had several of these and didn’t want the new one from the box when I was deploying a new machine to them). I probably have at least 6 of the HP ones because I would end up with a pile of them on my desk when I was doing deployments of 20-30 laptops at a time since at least a few people wouldn’t want them each batch.
I didn’t try the Belkin USB 2.0 one but I’ve had trouble with that one on other Linux distros lately. I seem to actually have the best luck with newer ones or fairly modern ones rather than USB 2.0 ones in my experience for what it’s worth (but it’s only in the past few years that has been true and it used to be exactly the opposite where the Belkin USB 2.0 and a lot of those well-known ones were the *only* ones that worked within Linux).
I suspect that is due to increased gadget support (on the manufacturer/adapter side as well as the Linux kernel side) and if you read my reply to Andy you will see that even the Microsoft one is actually using gadget mode (and so does the HP one) and I’m guessing a lot of the older ones either don’t use it at all or don’t implement correctly or the extent that newer USB-C compliant ones do.
Hopefully that helps!
Hello James
thank you for the interesting guide. I bought one of these last year but although I managed to install an old version of Armbian and the official Ubuntu and Debian images, and despite the board is running nicely, I have never succeded in getting the USB port to work properly with any distribution.
Any USB 2.0 pen or device that I connect to the USB port (which is claimed to be a 2.0/480M High Speed port) is always recognized as a “Full Speed” device instead (hence the data transfer rate is reduced to 12M instead of 480M) .
My intention was to use the board as a very low-cost ADS-B decoder, using a DVB-T dongle (I use an OPI Zero and a Lite for the very same task, but they are significantly more expensive), but the decoding software, based on rtllib needs the USB 2.0 high speed to work.
Are you able to check if your board’s USB port handles correctly (that is, at high speed) USB 2.0 devices, jus to exclude that my board is somewhat faulty?
Thanks anyway
Andy
Hey Andy,
Welcome! I can definitely confirm this issue. It definitely not your board. I was also able to reproduce your powered USB hub results. With a hub it won’t even detect anything plugged in.
Here’s what I get during my testing:
root@orangepii96:/boot# dmesg | grep usb[ 0.297302] v_usb: 1800 2800 mV normal standby
[ 0.320495] usbcore: registered new interface driver usbfs
[ 0.321105] usbcore: registered new interface driver hub
[ 0.321838] usbcore: registered new device driver usb
[ 0.585327] usbcore: registered new interface driver usb-storage
[ 0.587219] platform disable musb
[ 0.587463] musb-hdrc: ConfigData=0x1a (UTMI-8, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 0.588378] musb-hdrc: HDRC RTL version 2.0
[ 0.588989] gpio-vbus gpio-vbus: registered host 'musb-hdrc'
[ 0.691711] usbcore: registered new interface driver usbmouse
[ 0.949707] musb_gadget_pullup android usb didn't ready
[ 0.951538] android_usb gadget: Mass Storage Function, version: 2009/09/11
[ 0.952270] android_usb gadget: Number of LUNs=1
[ 0.953674] android_usb gadget: android_usb ready
[ 0.954101] gpio-vbus gpio-vbus: registered gadget 'musb-hdrc'
[ 0.954833] musb-hdrc musb-hdrc: MUSB HDRC host driver
[ 0.955444] musb-hdrc musb-hdrc: new USB bus registered, assigned bus number 1
[ 0.957702] platform enable musb
[ 4.942016] usb cable connect...
[ 6.591857] usb cable disconnect...
[ 7.110046] usb 1-1: new full-speed USB device number 2 using musb-hdrc
[ 7.250244] usb 1-1: Parent hub missing LPM exit latency info. Power management will be impacted.
[ 7.251281] usb 1-1: not running at top speed; connect to a high speed hub
[ 8.721618] cdc_ether 1-1:2.0 eth0: register 'cdc_ether' at usb-musb-hdrc-1, CDC Ethernet Device, 60:45:bd:fb:3d:7d
[ 8.732788] usbcore: registered new interface driver cdc_ether
root@orangepii96:/boot# lsusb -t/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Communications, Driver=cdc_ether, 12M
|__ Port 1: Dev 2, If 1, Class=CDC Data, Driver=cdc_ether, 12M
I think it’s somehow related to the musb-hdrc driver. This isn’t exactly the driver I would expect and is a USB OTG driver. I think the USB OTG power port and the host port may be sharing the same host controller and that may have something to do with this.
To see why I suspect this take a look at all of the settings for musb-hdrc:
root@orangepii96:/home/orangepi# ls /sys/class/udc/musb-hdrc/a_alt_hnp_support a_hnp_support b_hnp_enable current_speed device is_a_peripheral is_otg maximum_speed power soft_connect srp state subsystem uevent
root@orangepii96:/home/orangepi# cat /sys/class/udc/musb-hdrc/*
0
0
0
UNKNOWN
cat: /sys/class/udc/musb-hdrc/device: Is a directory
0
1
high-speed
cat: /sys/class/udc/musb-hdrc/power: Is a directory
cat: /sys/class/udc/musb-hdrc/soft_connect: Permission denied
cat: /sys/class/udc/musb-hdrc/srp: Permission denied
not attached
cat: /sys/class/udc/musb-hdrc/subsystem: Is a directory
DRIVER=android_usb
USB_UDC_NAME=musb-hdrc
USB_UDC_DRIVER=android_usb
There is a *lot* of OTG stuff enabled on this driver and this is the driver it’s using for stuff plugged into the regular USB-A port. It may be possible to blacklist it and use a different driver but it’s quite likely that will also make it not see the device at all. I did try a manual override using the kernel debug testmode parameter located here:
root@orangepii96:/sys/kernel/debug/musb-hdrc# lsregdump testmode
You can set the testmode to force it to go to high speed mode. When I tried this it stopped seeing the adapter until I rebooted.
A little bit more information:
root@orangepii96:/sys/kernel/debug/musb-hdrc# sudo lsusb -v | grep 'Support\|Product\|operate\|Lowest\|InterfaceProtocol'idProduct 0x07c6 RTL8153 GigE [Surface Ethernet Adapter]
iProduct 2 Ethernet Adapter
bInterfaceProtocol 0
bInterfaceProtocol 0
can't get debug descriptor: Resource temporarily unavailable
bInterfaceProtocol 0
bInterfaceProtocol 0
HIRD Link Power Management (LPM) Supported
Latency Tolerance Messages (LTM) Supported
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 2
Lowest fully-functional device speed is High Speed (480Mbps)
idProduct 0x0002 2.0 root hub
iProduct 2 MUSB HDRC host driver
bInterfaceProtocol 0 Full speed (or root) hub
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
You can see the problem is actually in the “root hub”. It’s not actually in the adapter / the device you are plugging in. You can see here that it’s actually detecting that the device itself is not only capable of 480M but is actually capable of SuperSpeed 5Gbps (and it knows it / can see it) but it’s nevertheless limited by the root hub. It’s the root hub that is set to full speed:
bInterfaceProtocol 0 Full speed (or root) hub. I know I’ve seen blacklisting certain hub drivers fix issues like this in the past but I haven’t tried blacklisting the driver yet (or know if there’s other drivers that will take over for it yet if I tried to).I’m wondering if some of these options may have any impact (particularly quirks or avoid_reset_quirk, some of the user controllable options):
root@orangepii96:/sys/bus/usb/devices/usb1# ls1-0:1.0 authorized_default bConfigurationValue bDeviceSubClass bMaxPower busnum dev driver idVendor maxchild quirks serial uevent
1-1 avoid_reset_quirk bDeviceClass bmAttributes bNumConfigurations configuration devnum ep_00 ltm_capable power removable speed urbnum
authorized bcdDevice bDeviceProtocol bMaxPacketSize0 bNumInterfaces descriptors devpath idProduct manufacturer product remove subsystem version
On some boards you can edit the .dtb files and recompile them to change how the kernel is seeing the devices. That would theoretically be these files.
I’m continuing to investigate the problem. From what I can tell (and maybe you got this sense as well) it might take a kernel rebuild to fix this with some additional options checked but I am continuing to check if there is another way here!
Hi James
first of all, thanks for your investigations, now I know my board is not faulty (even if it was somewhat easier to purchase another 7$ board to replace a faluty one rather than having to deal with this kind of driver-related problems).
I copy and paste what I wrote on the Armbian forum months ago. They used to provide an image but it was soon abandoned due to the limited capacity of the board, in their opinion not powerful enough and with a too flacky wifi to deserve further developing. I do not agree and believe that this little board could really be a nice toy to play with… if the USB worked as expected.
Here is my dmesg | grep usb
[ 0.378479] : pid = 10, v_usb: ext_len = 0[ 0.378540] v_usb: 1800 2800 mV normal standby
[ 0.388732] usbcore: registered new interface driver usbfs
[ 0.388793] usbcore: registered new interface driver hub
[ 0.388854] usbcore: registered new device driver usb
[ 0.697265] usbcore: registered new interface driver usb-storage
[ 0.697753] platform disable musb
[ 0.697814] musb-hdrc: ConfigData=0x1a (UTMI-8, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 0.697814] musb-hdrc: HDRC RTL version 2.0
[ 0.697875] gpio-vbus gpio-vbus: registered host 'musb-hdrc'
[ 0.791931] usbcore: registered new interface driver usbmouse
[ 0.822021] musb_gadget_pullup android usb didn't ready
[ 0.822937] android_usb gadget: Mass Storage Function, version: 2009/09/11
[ 0.822937] android_usb gadget: Number of LUNs=1
[ 0.823181] android_usb gadget: android_usb ready
[ 0.823242] gpio-vbus gpio-vbus: registered gadget 'musb-hdrc'
[ 0.823242] musb-hdrc musb-hdrc: MUSB HDRC host driver
[ 0.823242] musb-hdrc musb-hdrc: new USB bus registered, assigned bus number 1
[ 0.823364] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.823364] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.823364] usb usb1: Product: MUSB HDRC host driver
[ 0.823364] usb usb1: Manufacturer: Linux 3.10.62-rda8810 musb-hcd
[ 0.823364] usb usb1: SerialNumber: musb-hdrc
[ 0.823913] platform enable musb
[ 4.835388] : pid = 10, v_usb: ext_len = 0
[ 4.835449] usb cable connect...
[ 6.715698] usb cable disconnect...
[ 7.181274] usb 1-1: new full-speed USB device number 2 using musb-hdrc
[ 7.324584] usb 1-1: not running at top speed; connect to a high speed hub
[ 7.335021] usb 1-1: New USB device found, idVendor=0bda, idProduct=2838
[ 7.335021] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7.335083] usb 1-1: Product: RTL2838UHIDIR
[ 7.335083] usb 1-1: Manufacturer: Realtek
[ 7.335144] usb 1-1: SerialNumber: 00000212
[ 15.373962] musb-hdrc musb-hdrc: VBUS_ERROR in a_host (98, VALID), retry #1, port1 00000103
[ 16.553955] usb 1-1: USB disconnect, device number 2
[ 16.831298] usb 1-1: new full-speed USB device number 3 using musb-hdrc
[ 16.976806] usb 1-1: not running at top speed; connect to a high speed hub
[ 16.987182] usb 1-1: New USB device found, idVendor=0bda, idProduct=2838
[ 16.987182] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 16.987182] usb 1-1: Product: RTL2838UHIDIR
[ 16.987243] usb 1-1: Manufacturer: Realtek
[ 16.987243] usb 1-1: SerialNumber: 00000212
[ 215.878356] musb-hdrc musb-hdrc: BUS BABBLE as a_host
[ 215.878356] musb-hdrc musb-hdrc: usb otg cable is still on, and id is low
[ 215.878906] usb 1-1: USB disconnect, device number 3
[ 217.352416] usb 1-1: new full-speed USB device number 4 using musb-hdrc
[ 217.505798] usb 1-1: not running at top speed; connect to a high speed hub
[ 217.516784] usb 1-1: New USB device found, idVendor=0bda, idProduct=2838
[ 217.516845] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 217.516906] usb 1-1: Product: RTL2838UHIDIR
[ 217.516906] usb 1-1: Manufacturer: Realtek
[ 217.516906] usb 1-1: SerialNumber: 00000212
usb-devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=03.10
S: Manufacturer=Linux 3.10.62-rda8810 musb-hcd
S: Product=MUSB HDRC host driver
S: SerialNumber=musb-hdrc
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=2838 Rev=01.00
S: Manufacturer=Realtek
S: Product=RTL2838UHIDIR
S: SerialNumber=00000212
C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M|__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=, 12M
|__ Port 1: Dev 4, If 1, Class=Vendor Specific Class, Driver=, 12M
I wondered if it could be a power-related problem, but I tested all the three power adapters I own, two 2.1A and one 2.4A, two of which with mobile USB cables and the last with fixed cable which work without a problem with my OPI Lite and my OPI Zero (each one having mounted to their USB ports an RTL-SDR dongle, plus a CPU fan, SSD1306 OLED screen and external RTC module attached to their GPIO header).
I doubt that the same power unit that is able to drive a 4-core board with all that stuff attached to the USB and GPIO header (and in the case of the Zero powered through the same micro-usb port) is unable to deliver enough power to this single core board and just one device attached. Or am I wrong?
I tried with any possible combination of power adapters and cables I have and even tried to (succesfully) power up the board through the GPIO header’s pins, but nothing changes.
I tried to attach an external 4-ports 2.0 Hub, I have two, one is powered, the second is not. The powered one is simply not recognized, the other one is recognized as a 2.0 Hub but if I then attach the dongle to it, the dongle is not recognized anymore (not even as a 1.1. device).
I then tried to use a Y USB cable to provide this latter hub some external power (by attaching the power cable to a second power adapter) but nothing changes (the hub is recognized, but no other devices attached to it are).
Of course I tried to switch the RTL-SDR dongles, I have three, but all of them are recognized as 1.1 devices as well as different USB 2.0 pens to the board but even these are recognized as 1.1. devices, so I can assume the issue is not power-related but agree with you that the problem is definitely with the musb-hdrc driver and the way it deals with both the OTG port (which can be used to power up the board) and the USB-A port.
Unfortunately I’m still quite new to Linux and scratching my head around when dealing with kernel recompilation…
Thanks a lot for the time you are devoting to the problem.
Andy
Hey Andy,
No problem at all, this is an extremely tough one! What I am trying to determine if it’s possible. What do I mean by that? The question in my mind is did they implement the USB incorrectly at the hardware level to save money. I feel like on this board the answer is going to be yes, they did not implement USB properly and it was on purpose to save money. That’s simply a function of the fact that it’s widely available for under $10 and none of their other boards are (not even ones older than the i96!).
I’ve covered issues like this a lot on the site as it also relates to Raspberry Pis and whether they can use the cheap 2.5″ to SATA adapters and they are absolutely notorious for implementing USB wrong (on purpose) to save money. In this case I’m talking about the adapter manufacturers but Raspberry Pi themselves has had issues with implementing USB properly as well such has with the Pi 4 launch where they had to revise how they implemented it at the hardware level on later revisions of the board (the earliest Pi 4 launch revisions still have that USB hardware defect where it won’t work with certain USB-C chargers which is not supposed to be a thing with USB-C).
Take a look at this thread here. This isn’t the exact issue the Orange Pi has but the engineers in this thread covered so many of the terms and concepts that we’re dealing with here that I found it extremely valuable.
I’m certain nobody has been able to figure out how to solve this problem. I came across your original thread many, many times during my research on this as there is almost nothing related to this out there. It really sucks that the community gave up on the board because a lot of those guys who do the Armbian programming are exactly who we needed to look at this board to fix it and they kind of washed their hands with it already.
I definitely don’t think it’s power related but that was actually my first thought (and why I recreated your powered hub experiment). I agree with your conclusion here. The other thing that points to this is that those Eth to USB adapters are extremely low powered and I’ve never had an issue getting power to those on any devices so this doesn’t seem to fit either.
It pretty much all boils down to is this a kernel configuration issue or is this an actual hardware issue where they didn’t implement USB correctly? One of those can be fixed and one of them can’t. Recompiling the kernel isn’t too hard (other than you will probably have to cross-compile unfortunately for this model) but knowing what to change is more tricky. If I was working on this within a company this is the part where I would call in the electrical engineers / hardware engineers.
I’m more of the software/development guy and this problem is getting extremely low level. I’m definitely comfortable with all types of hardware but we’re getting to straight up electrical engineering here. It’s not easy to get the guys with that level of electrical engineering and consumer electronics experience to look at it as you’re starting to get to the skill levels where there just aren’t that many people at that level (similar to higher level hacking). That’s why it’s a bummer the Armbian guys wouldn’t keep going with this board. No doubt they would have already figured this out by now (or they already know that the USB can’t be fixed and that may have weighed into their decision even if it wasn’t as public of a point, hard to say).
Despite this I do have a history of fixing things like this. One of my most popular projects on GitHub was actually fixing Ubuntu 18.04 for the Raspberry Pi which was not officially supported at the time. I *hated* doing this project but the people *loved* it. It has over 500 stars on GitHub which only my Raspberry Pi Minecraft Bedrock server project has more (and it took a lot longer to get them). Why did I hate it? Because it’s really, really hard to fix these kinds of issues. You really need to have 2 God-tier skillsets to do that (advanced software and electrical engineering). The reason it is hard and miserable for me is I have 1 of those skillsets and I have to learn everything about the other one. I can do it (anyone can learn anything given enough time) but the cost is time.
I have some ideas to try fixing this that I’ve mentioned in my previous post and I have a few others as well. For example if I were to try rebuilding the kernel I would start by going into the options related to “musb-hdrc” and see what Orange Pi has checked and hasn’t checked. I’d investigate if I can remove the OTG driver altogether if I’m not going to be using that functionality to see if that will let it use the normal driver for USB 2.0 devices.
The thing I am struggling with is I do not want to go down this road if this issue is because of a hardware design issue on the board. I want to understand more about exactly what is happening before sinking probably at least dozens and realistically hundreds of hours into a board fix project (although I learned a lot from my last one and would definitely do a lot to minimize the scope of what I’m trying to do with it, maybe just that one fix).
Did you ever try contacting Orange Pi support officially? I know you made some of those posts but it didn’t seem like you got an official answer. I have seen official answers to similar questions like this though on other Orange Pi models like the PC 2. I think this would be worth asking them (possibly privately through their normal ticket system) if you haven’t tried already to see if they tell us that it’s physically impossible or not as that would really help both of us decide whether it’s worth going further!
Hello James,
I didn’t realise it before you told that but I believe you may be right when you think they may have implemented incorrectly the USB ports. I’m by no means and electrical engineer, but the simple fact that the I96 was let alone by it’s manufacturer just a few months after launch (their official distros are quite old and there is no signs of updates for those) make me think that the board probably had some problems in that respect.
I totally agree with you that you may loosing your time trying to patch the official distribution not knowing if the problem is hardware-related. I will open a ticket with OPI support and see if I can get an answer of any sort, but I’m not confident they will ever answer. The board is already old (and supposedly already out of production) and even if they may be aware of the problem it has I don’t think they would have resources to devote to solve it, being the I96 the cheapest of the bunch.
Anyway, will try to get in touch with them and will post here any reply I will get (if ever)….
Thansk again for your efforts.
Andrea
Hey Andy,
Thank you so much for your great reply! I think this is the right course of action. Let’s see what they say.
I have no doubt there are problems with the board. We know about the WiFi (I haven’t really seen as many issues with this but lots of people have). We know the board isn’t perfect for sure. That’s not the interesting question though in my eyes.
The fact is this board costs less than $10. You can’t get anything nearly as powerful for that much money. A Pico W is $7 if you can even find one and that one is only a microcontroller and not even a SBC!
That $10 price makes this an interesting question. We know the board has problems, but is this problem insurmountable or is this problem just one of dozens of problems with the board that actually could have been fixed if they stuck with it (all boards are like this at launch, even Pis especially early model Pis). It also matters which problems are insurmountable and which ones aren’t. If the WiFi is just flaky but we can get it working pretty well otherwise then with that caveat this would still be a good choice for a lot of projects.
Because of that I’m actually not sure which category this is going to fall in. Is this a hardware defect that would have to be fixed literally by making a new board revision? Or is it one of the potentially dozens of software and kernel issues that would easily be resolved?
The mainline kernel has support for the i96 now. There is no premade image out there that let’s you install this very easily. I’ve tried. I tried installing the kernel from apt as well but it won’t use it because uboot still loads the old kernel. I half wonder if the mainline kernel would work *much* better and faster than the i96 image which is several years old. Here’s when official support was added for the i96 to the Linux kernel.
I literally have not figured out how to get the Orange Pi i96 to the mainline kernel yet. As I look through the link I just posted above I did see some things I can try though to switch over the kernel. I saw a few other things I could try as well such as installing Arch Linux from a base image and I already tried several other things such as installing linux-image-generic through apt and the Orange Pi will not load the new kernel due to uboot. I would probably have to cross compile uboot and the kernel or try the Arch method possibly to get on that newer i96 kernel.
I still have a few ideas I want to try. I want to see if I can get it on Arch Linux from some of these tutorials from 5 years ago and make my way to a newer kernel. I might also just get the cross compiler and try some basics and see if it makes any difference.
I’m willing to help fix this. I think the best course of action is to attempt to contact them first as we talked about here. If they won’t answer within a week or two or whatever your best judgement is come back and let me know they never replied! I’ll also add some replies if I get anywhere trying to use the actual native Linux 5.0 kernel to use the built in i96 support (which probably very few people have ever experienced).
UPDATE! I was able to fix this. I finally found a breakthrough post here by a Mr. Gabor Hidvegi. I do not know how I missed it in my 100 searches before but this guy had already cracked it.
The fix is is to comment out this code in kernel/drivers/usb/musb/rda.c:
/* disable high speed when host*/power = musb_readb(regs, MUSB_POWER);
power &= ~MUSB_POWER_HSENAB;
musb_writeb(regs, MUSB_POWER, power);
Now he is using the 2G model and the modem is still messing with his USB speeds for some reason. I just have the plain i96 and so I rebuilt the kernel and take a look here:
orangepi@orangepii96:~$ lsusb -t/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Communications, Driver=cdc_ether, 480M
|__ Port 1: Dev 2, If 1, Class=CDC Data, Driver=cdc_ether, 480M
orangepi@orangepii96:~$ uname -a
Linux orangepii96 3.10.62-rel5.0.2+ #2 PREEMPT Tue Aug 23 16:49:14 MDT 2022 armv7l GNU/Linux
orangepi@orangepii96:~$
Yep, that’s it, it’s working! Notice that my kernel date is 2022. This is because I did actually rebuild the kernel. I used the OrangePi_Build system and made some modifications. I did this on Ubuntu 22.04 but I did have to make a change to the source as it was trying to install old dependencies that no longer exist.
I’m going to build some images and make them available here: https://github.com/TheRemote/Legendary-OrangePi-i96
It also has a bonus perk. While I was upgrading the build system to work I went ahead and updated the image to Debian Bullseye! I know you are using the Armbian distro that has been cut off which this could be built into that as well (although going to Debian Bullseye will probably be a newer and better choice if not for the kernel then for everything else).
James you are GREAT!
I’m downloading your image right now and will install over the week end. I don’t know how you managed to find that post by Mr. Hidvegi, I searched forever the web without finding any useful clue!
Thanks a lot also for preparing the image, I own the plain I96 version so it is exactly what I needed (sorry to hear that the fix has some caveats for the 2G version though).
Will keep you posted as soon as I have everything up and running!
Again THANKS!
Andy
Hey Andy,
No problem at all! He said that it works on the 2G version if you wait something like 6 seconds to load the driver. It looks like he planned on making an image as well but it doesn’t look like that happened.
Definitely let me know how it goes! If there are other fixes available out there it should be pretty easy to implement them. Instead of just producing an image one time I wanted to patch the official build system so that people could pretty easily reproduce images as this seems to be an obstacle that was never really overcome. I haven’t seen any Orange Pi i96 images available anywhere like this (not since that Armbian fork was abandoned).
I’m sure fixing the Ubuntu build isn’t impossible either. 22.04 doesn’t build clean at all. 20.04.1 actually does build clean but won’t boot for some reason. It’s hard to debug it without having the serial UART connector (I don’t) as I have no idea why the image isn’t booting (just that it isn’t). I’m hoping if I just get the ball rolling though that some others will show up here and there with some additional fixes.
I’m not as worried about scope with this project as Ubuntu. I implemented literally every fix I could find that is available for the i96 (only 3 total) but is it all of them that exist? I kind of doubt it because of how many times both of us didn’t find that post. Are there a few other fixes out there like that both of us haven’t seen? Probably and that is where I hope some other people may contribute or even fork it with some additional fixes.
I look forward to hearing what you find!
Hi James
I can confirm that your image fixes the problem and the little board can definitely be used as an ultra-cheap ADS-B receiver when coupled to a likewise cheap DVB-T dongle! THANK YOU!
Hey Andy,
Excellent news, thanks so much for testing it! That is fantastic for a $7 board and I don’t think there’s anything else like it available. Thanks so much for testing this and sharing!
Thank you, I followed this guide to get the i96 working and it was quite helpful.
Hey Alexander,
I’m glad it could help! I couldn’t believe that board is on Amazon for something like $7 + shipping. It actually works really well. These are fantastic for so many projects / use cases that don’t need anything more than a low power headless board.
It’s been out for a while so I’m certainly late to the party but it’s the Raspberry Pi shortage that led me to investigate these boards. They were probably honestly miserable to use at the time back in 2017-2018 (and earlier for some Orange Pis) compared to now since they’ve had years of refinements / upgrades (particularly with the kernel). Anyone jumping into it now will almost certainly have a much smoother time than when many of these Orange Pi models were originally released (as long as you know where to find certain up-to-date tools / downloads which this guide covers).
Thanks for leaving this. It definitely does make a difference especially on the newer articles that don’t have a lot of feedback yet and lets me know that I need to keep doing more articles/guides like this on the site. Take care!
Interesting! I think I mentioned that when I saw the price I bought to then think what project I will be using the board on. I think it may do well with some sort of sensor based automation or wireless control for something.
Thank you for putting the time in to tinker with it James.
Hey munceito,
No problem at all, it was really fun to play with! I think you’re absolutely on the right track. I’ve actually been working on a demo project for the Pico W that will basically use those cheap $7 Picos as a wireless scanning station. It will scan for all SSIDs in the area and look for changes.
This is mostly just to demo the wireless but it does need a low power controller. This would be perfect and is kind of along the ideas of a wireless controller. It’s honestly almost the same price as a Pico W. This is more powerful than a Pico W though. You could use these as the door/gate wireless controllers instead of a Pico W simply because they cost about the same!