Jump to content

Orange Pi Zero went to the market

zgoda_j

By zgoda_j
in Allwinner sunxi

 Share

Recommended Posts

dgp

dgp

Posted
Posted

Busy with xmas stuff right now, but once this craziness is behind me I'll package dgp's work as I tried to do with fifteenhex and submit a PR so we *can* have a working WiFi driver included.

 

dgp and fifteenhex are one and the same aka me. :)

1
Link to comment
Share on other sites
EUA

EUA

Posted
Posted

Does it possible to use CVBS out on current armbian Legacy 3.4.113?
How to do that?

I add this lines to armbianEnv.txt

disp_init_enable=1
disp_mem_reserves=on
disp_mode=0
screen1_output_type=2
screen1_output_mode=11
tv_used=1
tv_dac_used=1
tv_dac_src=0

and recompiled with:
 

mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

Still no signal.

[sOLVED] Why no one tell me that I have to load tv.ko module also. :)

modprobe tv

Now, anyone know how to make output mode than PAL? I tried 1080p60 by changing the script.bin without success.
dmesg output shows
 

[DISP] disp_device_attached_and_enable,line:159:attched ok, mgr1<-->device1, type=2, mode=10

But TV shows no signal.
Is it my (Samsung 40" LCD) TV's issue or the OPiZero's ?
any ideas?
Thanks.

Link to comment
Share on other sites
dgp

dgp

Posted
Posted

To save confusion, talking about this https://github.com/fifteenhex/xradio/tree/original onthe mainline kernel.

 

I now have station + ap mode working.. so you can have the pi zero connected to wifi and acting as it's own ap. This is probably useful for a lot of potential applications for doing the initial wifi setup. Only downside is the station and ap side need to be on the same channel at the moment.

1
Link to comment
Share on other sites
hmartin

hmartin

Posted
Posted

My problem is that there is a lot of unofficial stuff that also works in many cases very affordably...Great, but lots of learning and caveats.

 

I'd like to split the discussion about PoE into a dedicated thread:

https://forum.armbian.com/index.php/topic/3136-orange-pi-poe/

 

To save confusion, talking about this https://github.com/fifteenhex/xradio/tree/original the mainline kernel.

 

I now have station + ap mode working.. so you can have the pi zero connected to wifi and acting as it's own ap. This is probably useful for a lot of potential applications for doing the initial wifi setup. Only downside is the station and ap side need to be on the same channel at the moment.

 

Thanks for the clarification that dgp = fifteenhex  :)

 

I don't think the XR819 driver is up to the standards of the kernel developers yet. I've also heard from various sources that there is no documentation for the XR819, it's just reverse engineering the chip's functionality from the allwinner SDK driver.

 

Hence, is there anything I can do in the mean time to help? I've written the Makefiles for the module to compile within the mainline kernel. This was part of my PR:

https://github.com/megous/linux/pull/7

 

Changes specific for XR819:

https://github.com/halmartin/linux/commit/4a93b9450a6d563b1e5e469c960c6c5430220bef

 

There are recent fixes to u-boot and the kernel dts to fix the GPIO power regulation on the Orange Pi Zero/One. It would be best to try and push these fixes upstream so that they're included in the next releases, if it's not too late (u-boot v2017.02 and Linux 4.10):

https://github.com/igorpecovnik/lib/issues/580

Link to comment
Share on other sites
dgp

dgp

Posted
Posted

I don't think the XR819 driver is up to the standards of the kernel developers yet. I've also heard from various sources that there is no documentation for the XR819, it's just reverse engineering the chip's functionality from the allwinner SDK driver.

 

Current driver is a mess of driver written by a Chinese vendor (debug print lines for every function entry etc) and a bunch of stuff added on top for specific products or something. So in short, no, not going into mainline any time soon. But I think it's good enough for what we want for now. IMHO it should be kept as an external module instead of trying to merge it into a kernel tree. Some of the kconfig options cause the driver to crash the kernel if you mess around with them so giving users the ability to see that probably isn't a good idea.

 

I asked the orange pi guys for a datasheet for it and got the electrical datasheet for it. Asked for a firmware reference (apparently such a thing exists because the comments in the driver refer to sections in it) and they never got back to me. What's needed to write a new driver that would be acceptable for mainline can probably be done from looking at current driver (I started doing this) but certain sequences of commands crash the firmware on the chip so without a reference it would be pretty frustrating.

Link to comment
Share on other sites
hmartin

hmartin

Posted
Posted

I asked the orange pi guys for a datasheet for it and got the electrical datasheet for it. Asked for a firmware reference (apparently such a thing exists because the comments in the driver refer to sections in it) and they never got back to me. What's needed to write a new driver that would be acceptable for mainline can probably be done from looking at current driver (I started doing this) but certain sequences of commands crash the firmware on the chip so without a reference it would be pretty frustrating.

 

I'm not sure asking the Xunlong guys is going to get very far, but it's worth a shot. The Orange Pi is popular, but these SBCs are a niche market, I don't think Xunlong is a high volume seller of Allwinner chips. I think the best chance is to  wait until something else using the XRADIO is shipping (probably something Android based) and then bother that manufacturer for the module source code/documentation.

 

It's too bad that Allwinner doesn't see the value of open source. They could have an XRADIO driver in mainline kernel quite quickly if they were willing to release the datasheet. The way now is wasted effort for us (trying to reverse engineer without documentation) and them (having a crappy driver).

Link to comment
Share on other sites
dgp

dgp

Posted
Posted

wait until something else using the XRADIO is shipping (probably something Android based) and then bother that manufacturer for the module source code/documentation.

 

I think the chip has been around for a while.The driver code is a few years old. I think there's so little info about it because it's a super cheap chip embedded into super cheap wifi enabled stuff none of us have ever used.

Link to comment
Share on other sites
hmartin

hmartin

Posted
Posted

I think the chip has been around for a while.The driver code is a few years old. I think there's so little info about it because it's a super cheap chip embedded into super cheap wifi enabled stuff none of us have ever used.

 

I can't find any FCC certification for it. I'm not convinced by the copyright date in the code, it's possible they recycled code from somewhere and didn't change the year.

 

Could you share the electrical datasheet you got from Xunlong?

Link to comment
Share on other sites
dgp

dgp

Posted
Posted

I can't find any FCC certification for it. I'm not convinced by the copyright date in the code, it's possible they recycled code from somewhere and didn't change the year.

 

Could you share the electrical datasheet you got from Xunlong?

 

FCC certification would be on a module or a product containing the chip as far as I know.

 

There is a WiFi cert (http://certifications.prod.wi-fi.org/pdf/certificate/public/download?cid=WFA61880) for the chip/driver that is dated September 2015 and it looks like the bits to make the driver compliant were hacked in after the driver was completed. My guess is that this chip became available in 2015 (datasheet also has that date, but says it's from a company called xradio) but it's based on something that's been kicking around for a while and that's why the driver has older dates in it.

 

I will upload the electrical datasheet somewhere if I remember but it's not really that interesting. The only interesting thing from a driver perspective are the timings for the reset pin. The block level diagram shows the radio parts but none of the processing parts.

Link to comment
Share on other sites
atharmian

atharmian

Posted
Posted

Expansion Board on OPi0: what interfaces?

OPi0 SPI 2MB flash bootloader configured?

 

I just read this on OPi0 page on linux-sunxi.org:

 

http://linux-sunxi.org/Xunlong_Orange_Pi_Zero

 

 

"A cheap 'Expansion board' for this connector is now available exposing all interfaces (2 x USB, IR receiver, microphone and combined AV TRRS jack) and can be ordered together with the board on Aliexpress."

 

But when I had emailed Steven@Xunlong some days ago re: $2 OPi0 Expansion Board, he seemed to say only 2xUSB and AV TRRS jack are available. (So I didn't order this expansion board.)

 

1. Can someone clarify? If in fact an IR receiver and a mic are available, wonderful (and sensible)! Is this a mic/ earphone- speaker combo, as shown on the official photo?

 

Is the IR receiver behind the USB ports, and the ear/mic next to the AV port?

 

2.Is the SPI 2MB flash configured to "boot" now?

 

Or will we need to follow the SPI NOR U- boot config instructions in the OPi description?

 

Interestingly PC2 is said ( on Peter Scargill blog article on Nano Pi NEO) to have only 1MB flash installed...Tkaiser vs Pete comments.

 

3. Any status update on WiFi support in Armbian OS with legacy kernel or mainline ( being noob still can't differentiate which kernel will really work, and if we really need mainline kernel features)?

Link to comment
Share on other sites
dgp

dgp

Posted
Posted

2.Is the SPI 2MB flash configured to boot?

 

The ROM in the H2+ processor will try to boot from SPI flash if it has a valid SPL written to it (the bit before the real u-boot starts). If not it will try the SD card.

The SPL will load u-boot from SD card if it's present and will then try SPI.. so you can have a newer u-boot on SD card if you need it.

My guess would be that the SPI flash comes with nothing on it so you'll need an SD card with u-boot etc on it to write u-boot to it.

 

Anyhow, take a look at the stuff I wrote here: https://linux-sunxi.org/Orange_Pi_Zero#SPI_NOR_flash

 

If anyone actually wants to boot a kernel from SPI flash they'll need u-boot with a driver for the SPI controller. I have a crappy hacked up thing here: 

https://github.com/fifteenhex/u-boot/tree/orangepizero

 

2MiB is probably a bit small to be usable though. Not looking forward to having to remove the chip to replace it on future pi zeros I order.

Link to comment
Share on other sites
dgp

dgp

Posted
Posted

If 2MB is low, why should the PC2 have only 1MB, as I read online?

 

I'm not entirely sure what the point of having SPI flash is if you can only get u-boot on it. Maybe from people that want to boot over ethernet but I think a lot of people will want to use the SPI flash to boot a very small environment (I have two kernels, two rootfs etc in 16MiB) and in that case 1MiB or 2MiB just isn't enough.

Link to comment
Share on other sites
jernej

jernej

Posted
Posted

If 2MB is low, why should the PC2 have only 1MB, as I read online?

 

This is explained already in OPi PC2 topic pretty well. Short summary - it enables bios like functionality. U-Boot with proper device tree file can be threated like bios. It support plethora of boot options and best of all, OS images can become board agnostic (universal), just like on PC, because board specific bits are contained on flash chip.

Link to comment
Share on other sites
jernej

jernej

Posted
Posted

But there are 2 conflicting opinions here re: whether even 2MB is enough ;)

You are saying 1MB should suffice?

 

Current H3 build with device tree info included is less than 512 KiB in size. U-Boot for H5 might be a little bigger due to larger instructions and additional FW. But even if it is twice in size, it will still fit. So this flash is really U-Boot only. Kernel is definetly at least few MiB in size.

 

Oh, having U-Boot in flash enables usage of GPT partitions on other storage devices. Allwinner boot procedure has unfortunate consequence of breaking GPT partition table (at least without hacks).

Link to comment
Share on other sites
dgp

dgp

Posted
Posted

Current H3 build with device tree info included is less than 512 KiB in size

 

Apparently no one uses it because even if you boot the current u-boot from SPI it will try to store the environment on MMC. ;)

Link to comment
Share on other sites
hmartin

hmartin

Posted
Posted

Apparently no one uses it because even if you boot the current u-boot from SPI it will try to store the environment on MMC. ;)

 

Pointless for people who want to use it without uSD installed, but I can see the reasons for it. If you're changing the environment lots (say, writing variables on each boot cycle), you run the risk of wearing out the NOR flash.

 

It's all sorts of bad news if you end up with bad blocks in the u-boot ENV area on NOR flash.

Link to comment
Share on other sites
atharmian

atharmian

Posted
Posted

After almost resolving OPi0 PoE as passive only, I see U-boot as is looks controversial.

 

So how could we "fix" Uboot SPL issue, or equivalent?

 

Is 2MB enough for device specific initialization such that we could have device agnostic kernel/OS called from USB, WiFi, eMMC, SD et al?

 

How about cycles affecting above media compared with SPI NOR?

 

I remember tkaiser mentioning that there is now kernel support for eMMC, what was/is missing?

 

Regardless, I do like the little 2MB holiday gift.

 

And despite the issues, I have become a believer in OPi0+ Armbian as best price/perf thus far.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

So how could we "fix" Uboot SPL issue, or equivalent?

If you are talking about my post, then this "issue" is related to main u-boot code, not SPL, and since the "issue" is missing driver it can be solved only by writing such driver.

 

Is 2MB enough for device specific initialization such that we could have device agnostic kernel/OS called from USB, WiFi, eMMC, SD et al?

 

How about cycles affecting above media compared with SPI NOR?

2MB is more than enough for booting from SD, eMMC, network and maybe USB (if you have more than 1 USB storage connected then it starts to get tricky).

And who cares about write cycles if you need to set u-boot environment only once in case you want a custom boot sequence (i.e. TFTP/PXE without DHCP), but if you care you usually get 10000 - 100000 write cycles and u-boot can have redundant environment (a second environment location in case the first one is corrupted).

 

I remember tkaiser mentioning that there is now kernel support for eMMC, what was/is missing?

eMMC is using a hardware interface similar to SD, so it's just a matter of configuring a fancy non-removable "SD card like thing" with 8bit data interface and no card detect pin.

Link to comment
Share on other sites
atharmian

atharmian

Posted
Posted

More questions:

 

1. With Uboot (and SPL signatures for SD card?) on 2MB SPI flash, do we still need "fast" SD memory?

How about 4GB class 6?

 

2. Will this SPI facilitate "fixed" MAC address(es) for board identification by a remote process? It was suggested somewhere as a plus point for having such flash, along with bootloader.

 

3. Is there a way, cheaper than buying "fast" SD cards, to plug/solder eMMC type onboard 4-8GB memory?

 

4. With a bootloader in SPI 2MB flash on OPi0, what are the pros and cons of netbooting ?

Link to comment
Share on other sites
dgp

dgp

Posted
Posted

More questions:

 

1. With Uboot (and SPL signatures for SD card?) on 2MB SPI flash, do we still need "fast" SD memory?

How about 4GB class 6?

2. Will this SPI facilitate "fixed" MAC address(es) for board identification by a remote process? It was suggested somewhere as a plus point for having such flash, along with bootloader.

 

3. Is there a way, cheaper than buying "fast" SD cards, to plug/solder eMMC type onboard 4-8GB memory?

 

4. With a bootloader in SPI 2MB flash on OPi0, what are the pros and cons of netbooting ?

 

1. yes, SPI NOR will only be used to load u-boot. Normal rules apply once the kernel is running. 

 

2. U-boot already inserts fixed MAC addresses based on the unique chip ID from the processor if you kernel device tree is setup correctly. Works for both wired and wireless on mainline with my xradio driver

 

3. no idea

 

4. u-boot on SPI NOR is enough for booting a kernel over the wired interface with TFTP etc. You can then use an NFS rootfs to have a diskless setup. SPI NOR should be cheaper and more mechanically reliable (soldered on instead of a connector) than an SD card.... and if you get a chip that supports it you can write protect the blocks with the SPL/u-boot and make it pretty hard to break. Main con is that 100mbit isn't all that fast.. but if you run everything out of RAM it doesn't matter once booted.

Link to comment
Share on other sites
dgp

dgp

Posted
Posted

dgp,

 

4K movies on cheap cards? :)

 

Any AliExpress/other links for cheapo 4GB or more cards?

 

 

Sorry there was meant to be a "not" in there. I was trying to convey that I don't do anything that requires lots of bandwidth.

 

I wouldn't bother buying SD cards from aliexpress. They are cheap enough on Amazon etc already.

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
Posted

@dpg, I've tried to integrate your xradio work into my branch, it compiled properly.

Using your sun8i-h2-orangepi-zero.dts, it was hanging on the CPU throotling, I don't know why.

So, I decided to merge only xradio stuff into plain copy of sun8i-h3-orangepi-one.dts.

No more hand, but a flood of mmc error when network is started, such as :

Dec 28 17:04:12 localhost kernel: [   40.171288] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD RTO !!
Dec 28 17:04:12 localhost kernel: [   40.177230] sunxi-mmc 1c10000.mmc: data error, sending stop command
Dec 28 17:04:12 localhost kernel: [   40.183531] sunxi-mmc 1c10000.mmc: send stop command failed
Dec 28 17:04:12 localhost kernel: [   40.189150] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD RTO !!
Dec 28 17:04:12 localhost kernel: [   40.195093] sunxi-mmc 1c10000.mmc: data error, sending stop command
Dec 28 17:04:12 localhost kernel: [   40.201387] sunxi-mmc 1c10000.mmc: send stop command failed
Dec 28 17:04:12 localhost kernel: [   40.206982] xradio_wlan mmc1:0001:1: Failed to read control register.

Looking more at this big syslog, I could see that it has actually got it IP from DCHP, but it is a bit after that it start flooding.

 

Do you have any ideas why I'm unable to make it working ?

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept