Orange Pi Zero went to the market

[praveenbm5]

Cheers @praveenbm5 . Quick clarification, do you mean megabits per second or megabytes per second (how file transfer is normally reported!)?

 

One other thing that would be of great interest is your actual link speed/signal strength. If you've an Android device just tapping on the active connection in Wi-Fi settings should reveal the answer If it reports a low signal strength and a low link speed then improving the antenna could help matters... 

 

(Single chain 802.11n in 20MHz should be able to achieve 144Mbps max let's see how close we can get to that with a 30 cent chip!)

 

1. Its Mega bits per second unfortunately
2. When I stand very close to the OPZ then the link speed is 65Mbps. But the upload/download is only ~5 Mbps even when standing close.

[reverend_t]

 

1. Its Mega bits per second unfortunately
2. When I stand very close to the OPZ then the link speed is 65Mbps. But the upload/download is only ~5 Mbps even when standing close.

 

 

So Qualcomm Atheros have nothing to worry about just yet! It will be interesting to see how things change as the community improves this driver.

[atharmian]

It is a bit disappointing that Xunlong chose to use an obscure and cheapo XR819 wifi chip to save maybe a dollar so OPi0 could look like a more featured $9 CHIP.

 

But CHIP has way better marketing:

 

https://techcrunch.com/2017/01/06/next-thing-chip-pro/

 

1. Can someone elaborate a bit on OPi0 WiFi available vs missing features, e.g. speed in Mbps over what range, AP, bridge etc modes?

 

2. How does above compare with WiFi on other OPis? Do other models all have same WiFi chip, not XR819?

 

3. Any comments on comparison with CHIP WiFi capabilities?

[martinayotte]

2) No ! The other OPi were using RTL8189.

[reverend_t]

It is a bit disappointing that Xunlong chose to use an obscure and cheapo XR819 wifi chip to save maybe a dollar so OPi0 could look like a more featured $9 CHIP.

 

But CHIP has way better marketing:

 

https://techcrunch.com/2017/01/06/next-thing-chip-pro/

 

1. Can someone elaborate a bit on OPi0 WiFi available vs missing features, e.g. speed in Mbps over what range, AP, bridge etc modes?

 

2. How does above compare with WiFi on other OPis? Do other models all have same WiFi chip, not XR819?

 

3. Any comments on comparison with CHIP WiFi capabilities?

 

I don't have my hands on it (yet) but unlike some 802.11(x) chips this is certified under the Wi-Fi Alliance's testing program. The biggest issues holding it back will likely be the performance of the open source driver and the transmit power that can be achieved. The history of wireless of Linux suggests it's not worth holding your breath for improved drivers!

[martinayotte]

Presence of SPI NOR gives you possibility to do just that. You must build SPI enabled U-Boot and burn it on SPI chip. Then you can boot from USB, network, etc. But 2 MB is far too litle to boot full OS. AFAIK there is no tutorial how to put U-Boot on chip.

 

Hi Jernej,

 

I've uploaded a u-boot into the SPI Flash, and working well with USB-Boot.

Network is another issue, problably because u-boot is unware of xr819, and neither the plain H3 eth0 (I was getting DHCP not responding, if I remember), I didn't investigate further.

SPI-Flash Tutorial ? Well, there are a lot of manual steps, first making sure you have a SPI floash solder properly (my early PiZero didn't have any), then loading my spidev overlay to get /dev/spidev, then get latest flashrom sources, edit the source to make sure it doesn't do any SPI transaction longer than 64 bits, compile it.  Create flash.img of the size of the SPI Flash, then "dd" again on the same image to write /usr/lib/linux-u-boot-dev-orangepizero_5.24_armhf/u-boot-sunxi-with-spl.bin into it with "conv=notrunc" and write the resulting image into flash using modified flashrom.

Nothing automated yet ... Maybe scripts can be written here, maybe even avoid using flashrom and use pure Python script which will handle the DT overlay also ...

Lot of jobs in the pipeline.

[ja7tdo]

hi,

 

I am looking for XR819 datasheet.

does anyone help me?

[zador.blood.stained]

SPI-Flash Tutorial ? Well, there are a lot of manual steps, first making sure you have a SPI floash solder properly (my early PiZero didn't have any), then loading my spidev overlay to get /dev/spidev, then get latest flashrom sources, edit the source to make sure it doesn't do any SPI transaction longer than 64 bits, compile it.  Create flash.img of the size of the SPI Flash, then "dd" again on the same image to write /usr/lib/linux-u-boot-dev-orangepizero_5.24_armhf/u-boot-sunxi-with-spl.bin into it with "conv=notrunc" and write the resulting image into flash using modified flashrom.

Nothing automated yet ... Maybe scripts can be written here, maybe even avoid using flashrom and use pure Python script which will handle the DT overlay also ...

Lot of jobs in the pipeline.

It may be simpler to use the Xenial legacy image as it would work with flashrom without any patches (just for purpose of writing u-boot to SPI)

Usage example for a 64Mbit flash:

dd if=/dev/zero of=flash.img bs=1M count=8
dd if=u-boot-sunxi-with-spl.bin of=flash.img conv=notrunc
flashrom -p linux_spi:dev=/dev/spidev0.0 -w flash.img

Also flashing via FEL is possible, but AFAIK this functionality is not in the main repo yet.

[martinayotte]

Hi Zador,

Yes, this is exactly the manual method we are all currently using, but I wish to get rid of "flashrom".

First, because, if you remember, in my case, I add to patch flashrom to avoid SPI transaction bigger than 64 bytes.

Second, I wish to avoid flashing the whole 64Mbits (or even 128Mbits) when real SPL is much smaller, this will reduce flash time.

Third, SPIDev are not active by default, I'm using an DT overlay, so, I want to bundle the overlay inside a BASH script and do all the Flashing jobs with a single "flash-spl.sh" command.

[zador.blood.stained]

@martinayotte

I was talking about the legacy kernel. Even if you are not interested in legacy development, it still can be used just for the purpose of flashing to SPI more easily.

 

As for getting rid of flashrom on the mainline - a patch or a DT overlay like this adds SPI flash as a partitioned MTD device, and you can write u-boot there with "flashcp" command without manual alignment.

Edit: this obviously requires fixing SPI transfer size on the kernel side.

[martinayotte]

@Zador,

Oh ! The SPI partioning was one thing I was looking at ealier. Thanks for pointing that to me, it will save time.

Yes, fixing the transfer size into the kernel was another thing I've explored, I was looking at that patch as a possibility :

https://patchwork.kernel.org/patch/9173711/

[zador.blood.stained]

Yes, fixing the transfer size into the kernel was another thing I've explored, I was looking at that patch as a possibility :

We have a similar patch for sunxi-next, I don't know if it applies to sun8i-dev.

[martinayotte]

Interesting ! And even less complex using FIFO than the full complex DMA one !

I will give it a try in my next build ...

[spock]

Not to fan the flames, but as I received my zero's today, I installed the 4.9 kernel nightly build, updated and the wifi "just works" 

 

Awesome.

[martinayotte]

Good !

On my side, I've ordered yesterday a new one since I still have WiFi problems (flooding in dmesg) with my current one, suspecting hardware issue.

But "slow boat" will bring it only next month, at best in 3 weeks.

[spock]

With the latest though, there seems to be no CPU governor as '/sys/devices/system/cpu/cpu0/cpufreq/' is missing. Without this, I am fearful of burning them so will need to work out what is broken.

[reverend_t]

With the latest though, there seems to be no CPU governor as '/sys/devices/system/cpu/cpu0/cpufreq/' is missing. Without this, I am fearful of burning them so will need to work out what is broken.

 

What ambient idle temperatures are you seeing?

[spock]

It's hovering around 29C ...

[reverend_t]

It's hovering around 29C ...

 

that doesn't sound like performance/no governor to me

 

check what /etc/default/cpufrequtils says, also run the following in the terminal

cpufreq-info

Armbian uses Interactive by default https://docs.armbian.com/#performance-tweaks

[exquisitus]

Hi Jernej,

 

I've uploaded a u-boot into the SPI Flash, and working well with USB-Boot.

mine 512m is without flash. some people in ali comments claim theirs have flash. so perhaps new versions are with flash?

anybody here with a version that has flash on it?

 

example from ali with flash

https://ae01.alicdn.com/kf/UT8qwZZXLdXXXagOFbXJ.jpg

[zador.blood.stained]

that doesn't sound like performance/no governor to me

 

check what /etc/default/cpufrequtils says, also run the following in the terminal

cpufreq-info

Armbian uses Interactive by default https://docs.armbian.com/#performance-tweaks

Please don't confuse legacy vs mainline, @spock talks about the mainline, where DVFS was (or is) broken and needs more testing.

[spock]

@zador.blood.stained - I tried the latest full build from this image and we have both wifi and DVFS working 

 

In my post #286, I has started with the build from Dec 26th and updated it - somehow that ended up broken. Probably something I did 

 

Now to make these little boards useful ...

[dgp]

For anyone expecting the wifi performance to be as good as their laptop or smart phone please adjust your expectations.

This is a chip for super cheap applications. It's basically a G device that supports enough of N to avoid hurting the performance of network it's on too much.

 

Even if the chip could handle high rates etc the SDIO bus it's on isn't amazingly fast either.

[dgp]

I don't have my hands on it (yet) but unlike some 802.11(x) chips this is certified under the Wi-Fi Alliance's testing program. The biggest issues holding it back will likely be the performance of the open source driver and the transmit power that can be achieved. The history of wireless of Linux suggests it's not worth holding your breath for improved drivers!

 

The driver relies on the host to do almost all of the MAC operation so it's actually limited a lot by the host and SDIO bus too.

Also it only supports the bare minimum of N it needs to function.

[dgp]

hi,

 

I am looking for XR819 datasheet.

does anyone help me?

 

I have the electrical datasheet which is useless. The chip and firmware is/is based on an ST/Ericsson design. The cw1200 driver in the mainline kernel source is basically the same as the xr819 driver and that driver (the in-kernel one) came from a code dump from ST/Ericsso so there probably isn't anyone that still has the technical documentation for the firmware (because ST/Ericsson no longer exists) and all winner have probably done a bunch of undocumented hacks in the firmware anyhow. 

[micke_s]

exquisitus:

I ordered two orange pi zero board with 1 month between.

First one does not have SPI flash, the other have.

 

 

[willmore]

I'm trying out Armbian_5.24.170110_Orangepizero_Ubuntu_xenial_4.9.0.7z on my Opi0/512MB. The delay with the wireless is better than it was with the legacy kernel. But, the bandwidth is still poor:

iperf -t 30 -c 192.168.0.5 -r
------------------------------------------------------------
Server listening on TCP port 5001TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.0.5, TCP port 5001TCP window size: 43.8 KByte (default)
------------------------------------------------------------
 local 192.168.0.96 port 39736 connected with 192.168.0.5 port 5001
 ID Interval       Transfer     Bandwidth
  0.0-57.4 sec   256 KBytes  36.5 Kbits/sec
 local 192.168.0.96 port 5001 connected with 192.168.0.5 port 41207
  0.0-31.3 sec  14.0 MBytes  3.75 Mbits/sec

Is that the expected behavior?

[tkaiser]

I'm trying out Armbian_5.24.170110_Orangepizero_Ubuntu_xenial_4.9.0.7z on my Opi0/512MB. The delay with the wireless is better than it was with the legacy kernel. But, the bandwidth is still poor:

  0.0-57.4 sec   256 KBytes  36.5 Kbits/sec

Is that the expected behavior?

 

Sure, but honestly... who cares? Please read through this thread where the guys who are actually working on improving the driver share some insights: https://forum.armbian.com/index.php/topic/3243-orange-pi-zero-xradio-st-cw1200/

 

The driver the mainline nightly image contains is based on dgp's version from 3 weeks ago and in the meantime he improved stuff. Unless you want to help these guys improving the driver (then using their most recent version of course!) any feedback on 'performance' seems pretty useless to me. It's ok for IoT stuff (sending/receiving small amounts of data from time to time) but as you can see above (your 30 second tests being delayed to 57.4 sec most probably due to excessive TX retransmits) you should lower expectations with the driver in its current state and this chip in general.

 

This is 'as cheap as possible' WiFi and IMO it's pretty useless to 'benchmark' throughput anyway especially since we're talking about 2.4 GHz band here where you never can be sure that 'low througput' is not just the result of your 'shared media' (the specific radio frequency) being used by too many other 'devices' at the same time (Microwave ovens, USB3 peripherals [1], and of course other WiFi networks using the same channels and so on). But in your case and based on the breakdown from the aforementioned thread it's obvious that there's still something wrong in TX direction anyway.

 

But again: without a reference providing numbers is useless (please compare with Martin's and dgp's iperf numbers that are way higher than yours). With reference I mean something like this: http://www.friendlyarm.com/Forum/viewtopic.php?f=42&t=379#p1222 (it's obvious that internal aerial of NanoPi M3 sucks compared to NanoPi Air with same WiFi chip but external aerial. But in my neighborhood 2.4 GHz band is close to unusable since way too overcrowded so you never know what's the reason the Air achieves only 20 Mbits/sec -- the tests were done at night since during the day and especially in the evening here 2.4 GHz is close to unusable)

 

[1] At a small customer (agency using only MacBooks for all their stuff) they bought external USB3 harddrives and connected those to every Mac a while ago. Then complaints started their server would've been becoming slow. In the end only those Macs were affected using WiFi and only when the hourly TimeMachine backups ran. Fortunately we were able to figure out that due to a misconfiguration of the AP only 2.4 GHz band was used. Switching to 5 GHz was the obvious solution.

[tkaiser]

Another Zero addon - NAS.

 

Available on Aliexpress now: https://aliexpress.com/store/product/Orange-Pi-Zero-NAS-Expansion-board-Interface-board-Development-board-beyond-Raspberry-Pi/1553371_32789632568.html

 

Still wondering whether Xunlong will release another Zero (maybe based on H5 SoC instead) with Gigabit instead of Fast Ethernet. Combining Fast Ethernet equipped OPi Zero with 2 of the fastest USB-to-SATA bridges (JMS568) is somehow a waste of ressources.

 

Edit: Now wondering whether the 2 USB Type A jacks are meant as input connections since 'The NAS could connect to every Orange pi boards.' -- Steven already confirmed that data lines are multiplexed with the ones on the 13 pin header suitable for the OPi Zero... but to be of any use combined with 'every Orange pi' A-to-A USB cables would be needed (that do exist but violate USB specs).

[ErwinH]

Sure it can connect to every Orange Pi Board using a USB breakout. (At least I hope that's what they mean) and the USB A connectors are linked to 2 of the 10 GPIO outputs on the JMS568.