[WiP / Orange Pi One] Support for the upcoming Orange Pi One?

[zador.blood.stained]

@jmarcelino

Latest log suggests that it's crashing while parsing mmc config in script.bin, but previous logs have another stack traces. So it's either hardware fault (who knows), either some cryptic error in configuration or images.

[jmarcelino]

So I reverted config/orangepione.fex back to 80e7d5a while keeping the rest of the tree up to date and my Orange Pi One is now happy again, booting correctly, has network.

 

Boot log: http://pastebin.com/AdfaAUYe

 

I'll see if I can narrow it further.

[tkaiser]

Now with all the recent fixes (reboot issue also fixed) we're ready to upgrade the kernel via apt repository (one single kernel build for all sun8i boards). Since some people experience no HDMI output (see below) I thought about giving user feedback through the LEDs. Due to switching to recent u-boot (2016.03-rc2) we're able to switch on power LED (the red one) directly after booting an we've also defined in fex settings that the LED is on by default.

 

Might be an idea to temporarely activate something like this for sun8i from within armhwinfo?

echo heartbeat >/sys/class/leds/green_led/trigger

Or maybe this (less annoying):

echo timer >/sys/class/leds/green_led/trigger 
echo 1900 >/sys/class/leds/green_led/delay_off
echo 100 >/sys/class/leds/green_led/delay_on

What do you think?

 

Regarding HDMI issues. We had one problem with the 5.00 release with kernel cmdline not matching kernel code -- this is fixed now. And Igor found one compile setting that prevented HDMI output on his Plus. I'm currently rebuilding again with the 'better' setting to see whether that's really the culprit.

[Igor]

Regarding HDMI issues. We had one problem with the 5.00 release with kernel cmdline not matching kernel code -- this is fixed now. And igor found one compile setting that prevented HDMI output on his Cubietruck. I'm currently rebuilding again with the 'better' setting to see whether that's really the culprit.

 

I made several tests and it's no go in my Opi+ ... unfortunately don't have any other H3 board here to test. Since we need HDMI we can leave out this minor (?) performance change for future. 

 

We might need to adjust boot script - is it safe using this script on A20 board?

 

I am out of lab next week so won't be able to test anything. I am putting out new images probably today and then let's collect what needs to be done ... for a week.

[jernej]

BTW: Do you guys (Igor and you) meet next week at Nuremberg or somewhere else (I ask since the only other guy called Jernej I know is from Slovenia -- one of the best times of my live being there working and constantly 'party hard')

 

I'm from Slovenia too, but we will have a meeting in Nuremberg.

 

On topic: What do you say if I adapt 1-wire patch which would take standard GPIO settings, e.g.:

[w1_para]
w1_used = 1
gpio = port:PA20<1><default><default><0>

It seems to me that it would be less confusing for users.

[Igor]

I rebuilt and upload all H3 images.

 

BTW: my OP+ is now little hotter in idle - sensor shows 47°C

[martinayotte]

Hi folks,

 

I've start playing with the 5.0.3 on OPi-PC, at first look, I discovered that "reboot" still not working.

I will continue to play with it to figured out if anything else needs to be reported.

 

EDIT : I've tested orangepi_PC_gpio_pyH3-master that I used on other OPi-PC with Loboris, the GPIOs can be flashed but it stop flashing after few blinks, without any crash.

Simply restarting the python script again, and it flash again, but only for few blinks.

[tkaiser]

We might need to adjust boot script - is it safe using this script on A20 board?

 

Without the disp.screen0_output_mode stuff? I would better try to patch in the sun7i stuff as outlined in my submit comment and then again use one single boot script for all sunxi devices. And in the meantime use a different boot script for sun8i.

 

Now we would only be able to specify something like disp.screen0_output_mode=10 instead of EDID:1920x1080p60 (especially the EDID stuff would be nice -- but I will not look into it since for my use cases the situation is already perfect: we can start to deploy Orange Pi PC/One with RFID readers for a large printing/scanning project)

 

 What do you say if I adapt 1-wire patch which would take standard GPIO settings, e.g.:

[w1_para]
w1_used = 1
gpio = port:PA20<1><default><default><0>

It seems to me that it would be less confusing for users.

 

If we would start from scratch I would agree. But since there are already countless references to the syntax we now use available it might users confuse even more if OpenELEC and Armbian now again use something different. And I still think it's good that OpenELEC and Armbian chose the same pin as loboris since then it's easy: 1-Wire? Pin 37 on the connector when using Orange Pi.

 

BTW: If you change LED definitions (exclude from GPIO range and define like we do) then they're accessible through sysfs below /sys/class/leds/ and you can use various triggers (needs Kconfig tweaks too)

 

@Igor: Unfortunately I forgot to adjust gpio definitions in orangepipc.fex or something with the commit went wrong. Should be the same as for the 3 others. I can send a pull request maybe tomorrow (build host currently down), in case you're willing to rebuild the PC image maybe you fix it yourself?

 

EDIT: 'spi_used = 1' and the 3 other SPI fixes also missing :-(

 

I rebuilt and upload all H3 images.

 

BTW: my OP+ is now little hotter in idle - sensor shows 47°C

 

Ok, I thought about enhancing firstrun since all 4 images are exactly identical with just 3 exceptions: The file script.bin links to and contents of /etc/default/cpufreq-utils and /etc/modules -- if I understand correctly firstrun gets called after armhwinfo? If so it's pretty easy to implement adjusting the symlink and the file contents from within firstrun. So we would only need to build one image with settings for the Plus that will work on every device (even the yet not available Lite -- I'm pretty confident that Steven/Xunlong is smart enough to reuses the same Wi-Fi chip and order of USB ports there)

 

Regarding temperatures: That seems to be clock related and yes, they're always a bit off when we're not using the old uboot 2011.09 from Allwinner.

[tkaiser]

I've start playing with the 5.0.3 on OPi-PC, at first look, I discovered that "reboot" still not working.

 

Strange, we all had this issue but it disappeared on Igor's Plus and on the One I was solely testing today. Just a wild guess: are you able using bin2fex/fex2bin to adjust script.bin contents so that the GPIO section reads like this: https://github.com/igorpecovnik/lib/blob/master/config/orangepione.fex#L221-L246

 

And then try again and report back?

[martinayotte]

Hi TKaiser,

I found the GPIO issue just few seconds ago, while reading your previous post saying that "1-Wire? Pin 37 on the connector when using Orange Pi"

The OneWire driver was preload in Igor's image, and it was fighting with the python gpio_lib doing mem-map.

I've simply removed the OneWire modules for now. Next, I will start testing I2C.

 

About the "reboot" issue, I don't know, since I've used Igor's 5.0.3 image instead of building it myself this time to be up-and-running quickly.

Even during the "firstrun" phases, I had to wait more than the famous "3 mins" and power-recycle to do the reboot.

[tkaiser]

About the "reboot" issue

 

Maybe this is solved when adjusting the gpio stuff in the fex file? Still just a wild guess since we've no idea where this reboot issue came from and why it disappeared but since it seems fex related and I f*cked up the fex adjustments for Orange Pi PC (and did not test today with these but just the One) it would be worth a try...

[martinayotte]

I've tested I2C, one of my OPi-PC had already a MCP23017 plugged on TWI1. At first, it didn't work, but I figured out that simply the TWI1 wasn't set as "use = 1" in the FEX and also had to remove PA18/PA19 from GPIO pins list.

[martinayotte]

Oh !

I've found a very strange bug !

With this 5.0.3 image, I had to first use wired networking, to be able to setup things.

I added an RTL8188 on USB, it was working fine too, until I unplug the wired RJ45, the WiFi SSH freezed.

Plugin the wired network, it works again, without any change, simply reissue the SSH command.

So, it is really weird, it is like if eth0 is not working and running, no other network can works.

 

I've never saw that, and all my other OPi-PC are running fine with only RTL8188 on them along with Loboris image.

[jmarcelino]

Continuing my Pi One testing, I tried the very latest image and still had no success so I kept experimenting with the orangepione.fex 

 

I've now tracked down my problem to @tkaiser's patch attempting "to fix potential overvolting and overheating"

 

For some reason my Pi One needs the older settings of:

pmu_level0 = 11300

pmu_level1 = 1100

and  

LV1_volt = 1300

LV2_volt = 1100

 

If I use the new 1270 values it never boots sucessfully and crashes with the random errors I've documented previously.

 

Even with the latest image replacing the values on the 4 lines above in the .fex makes my Pi One work again. I've even run the cpufreq-ljt-stress-test script successfully afterwards (output below)

 

 

 

root@orangepione:~/cpuburn-arm# ./cpufreq-ljt-stress-test 

The cjpeg and djpeg tools from libjpeg-turbo are not found.

Trying to download and compile them.

CPU stress test, which is doing JPEG decoding by libjpeg-turbo

at different cpufreq operating points.

 

Testing CPU 0

 1536 MHz SKIPPED

 1440 MHz SKIPPED

 1344 MHz SKIPPED

 1296 MHz SKIPPED

 1200 MHz SKIPPED

 1104 MHz ............................................................ OK

 1008 MHz ............................................................ OK

  912 MHz ............................................................ OK

  816 MHz ............................................................ OK

  720 MHz ............................................................ OK

  648 MHz ............................................................ OK

  600 MHz SKIPPED

  504 MHz SKIPPED

  480 MHz SKIPPED

  408 MHz SKIPPED

  312 MHz SKIPPED

  240 MHz SKIPPED

  120 MHz SKIPPED

   60 MHz SKIPPED

 

Testing CPU 1

 1536 MHz SKIPPED

 1440 MHz SKIPPED

 1344 MHz SKIPPED

 1296 MHz SKIPPED

 1200 MHz SKIPPED

 1104 MHz ............................................................ OK

 1008 MHz ............................................................ OK

  912 MHz ............................................................ OK

  816 MHz ............................................................ OK

  720 MHz ............................................................ OK

  648 MHz ............................................................ OK

  600 MHz SKIPPED

  504 MHz SKIPPED

  480 MHz SKIPPED

  408 MHz SKIPPED

  312 MHz SKIPPED

  240 MHz SKIPPED

  120 MHz SKIPPED

   60 MHz SKIPPED

 

Testing CPU 2

 1536 MHz SKIPPED

 1440 MHz SKIPPED

 1344 MHz SKIPPED

 1296 MHz SKIPPED

 1200 MHz SKIPPED

 1104 MHz ............................................................ OK

 1008 MHz ............................................................ OK

  912 MHz ............................................................ OK

  816 MHz ............................................................ OK

  720 MHz ............................................................ OK

  648 MHz ............................................................ OK

  600 MHz SKIPPED

  504 MHz SKIPPED

  480 MHz SKIPPED

  408 MHz SKIPPED

  312 MHz SKIPPED

  240 MHz SKIPPED

  120 MHz SKIPPED

   60 MHz SKIPPED

 

Testing CPU 3

 1536 MHz SKIPPED

 1440 MHz SKIPPED

 1344 MHz SKIPPED

 1296 MHz SKIPPED

 1200 MHz SKIPPED

 1104 MHz ............................................................ OK

 1008 MHz ............................................................ OK

  912 MHz ............................................................ OK

  816 MHz ............................................................ OK

  720 MHz ............................................................ OK

  648 MHz ............................................................ OK

  600 MHz SKIPPED

  504 MHz SKIPPED

  480 MHz SKIPPED

  408 MHz SKIPPED

  312 MHz SKIPPED

  240 MHz SKIPPED

  120 MHz SKIPPED

   60 MHz SKIPPED

 

Overall result : PASSED

 

 

 

I've also run cpuburn-a7 for a while and recorded ~ 60C using a thermal probe directly on top of the CPU which doesn't seem too concerning. This is without a heatsink.

 

I understand there were concerns about overvoltage/overtemperature which led to adopting the lower values and some (several?) of you are running with those - on the latest image - just fine on your Pi Ones, but for some reason my Pi One doesn't work with them while it's perfectly happy with the previous values.

 

Is there anything I can do to test this out further? For example I probe the voltages if you can point me to test points to look at.

[tkaiser]

EDIT: Schematic has been released: http://linux-sunxi.org/File:ORANGE_PI-ONE-V1_1.pdf

 

If I use the new 1270 values it never boots sucessfully [...] I've also run cpuburn-a7 for a while and recorded ~ 60C [...]

Is there anything I can do to test this out further? For example I probe the voltages if you can point me to test points to look at.

 

To be clear. The 1270 is just a value without any meaning. Could also be 2000 or 50 instead. It's 1270 since based on my experiments I fear the lower voltage available is close to 1.3V (to be able to compare graphs in RPi-Monitor). The fex fixes just should prevent switching from the lower voltage to the higher, this is just a binary switch.

 

Measuring 60°C when running cpuburn-a7 on an overvolted H3 when only 1 CPU core is active is pretty normal. Please do that test again and check with 'grep -c ^processor /proc/cpuinfo' afterwards (In my opinion doing such tests without RPi-Monitor is useless since you always overlook too many things)

 

Would be great if you can try out the tests points. Please have a look into the schematic for VDD-CPUX. I would set performance governor and then switch between a low and a high cpufreq since this triggers the binary switch for the voltage:

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 1104000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
# measure
echo 648000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
# measure again

It would also be very interesting whether cpufreq-ljt-stress-test passes when you set scaling_max_freq to 648000 (you know that it's not enough to run cpufreq-ljt-stress-test alone, you'll have to start in another shell session cpuburn-a7 already a few minutes before. Without running cpuburn-a7 in parallel the results of cpufreq-ljt-stress-test are meaningless!).

 

Since what you describe sounds like on your Orange Pi One voltages are different than on mine (yours are lower so you run in instability issues when staying at the lower voltage, the old settings you now use again lead to being on the higher voltage when not totally idle).

 

So, it is really weird, it is like if eth0 is not working and running, no other network can works.

 

This sounds like the usual 'default gateway' bug/feature.

 

I've tested I2C, one of my OPi-PC had already a MCP23017 plugged on TWI1. At first, it didn't work, but I figured out that simply the TWI1 wasn't set as "use = 1" in the FEX and also had to remove PA18/PA19 from GPIO pins list.

 

Would you please put your fex on pastebin.com or similar to be able to merge your changes? Thx!

[tkaiser]

I've even run the cpufreq-ljt-stress-test script successfully afterwards

 

Just to emphasise on this a little. The most important part when running these tests is this:

 

Especially on a multi-core system you may want to run CPU-intensive tasks in the background while running cpufreq-ljt-stress-test in order to keep all cores busy. The cpuburn scripts (see below) or compiling a kernel might be suitable tasks for this end

 

That means running cpufreq-ljt-stress-test alone isn't enough on a quad-core H3. You have to use 'cpuburn-a7' or 'stress -c 4' or 'sysbench --test=cpu --cpu-max-prime=100000 run --num-threads=4' running in parallel and it's a good idea to start a few minutes in advance since then the SoC gets closer to worst case conditions.

 

Since you did not apply a heatsink already the whole test is useless since thermal throttling will occur and cpufreq-ljt-stress-test simply isn't able to test the higher operating points (use RPi-Monitor to get a clue). When I ran cpuburn-a7 with overvolted settings and a heatsink the second protection method jumped in: CPU cores got killed, see a few posts before  (always use RPi-Monitor to get a clue)

 

So in your situation without a heatsink the best test would be to set scaling_max_freq to 648000 as already suggested, fire up cpuburn-a7 and start the test script 5 minutes later. If that fails then you've the clear indication that on your Orange Pi One the lower voltage is definitely too low. And fex settings that will feed the SoC always with the higher voltage might be an idea. Something like (the voltage value being without any meaning only the 1st bit being important):

pmu_level0 = 11300
pmu_level1 = 11300

LV1_volt = 1300
LV2_volt = 1300 

[jmarcelino]

@tkaiser

Thanks so much for your guidance! Really appreciate it - I may owe you a few beers if you're around Nuremberg :-)

I will follow the steps you suggested this afternoon and report back.

 

This morning I was looking around the board for test points and noticed that while there's lots of mentions of the regulator being a SY8113, the chip on my One didn't match the markings on the datasheet (top mark should be MLxyz, mine is WC5V1)

 

After a bit of smd marking detective work I found out that the regulator on my board is actually an AX3833: http://www.micro-bridge.com/data/Axelite/AX3833.pdf

 

At first glance they seem very similar in specs so maybe 100% compatible, but I wonder if this could explain the differences in operation. Could you check which chip yours' has? Here's a photo of mine:

 

[kevinheb]

Hi guys, I'd like to offer to help in anyway I can.  Coding knowledge is zero, but I'm familiar using linux.  If there are any tests that you'd like me to run, just let me know.

 

Have an Orange Pi PC, have been messing around with images for the last couple of months.  Would like to use the Orange Pi PC as a low energy Plex server.  Have found some of the images quite flaky, but have had success running loboris' Ubuntu trusty image, have got Plex server up and serving.

 

Have just tested the 5.0.3 image with the Orange Pi PC, and seems to be working well.  I am running the pi headless and accessing it via ssh.  Have just used the nand install script to run from my external hard drive, and will now start cataloging the plex library to see how it is getting on.

[szaflik]

Schematic for Orange Pi ONE is available now - it should help to solve some issues with voltage. There is 1V2C test point on PCB - it is the right place to check 1.1V / 1.3V switching

 

ORANGE_PI-ONE-V1_1.pdf

[tkaiser]

Schematic for Orange Pi ONE is available now - it should help to solve some issues with voltage. There is 1V2C test point on PCB - it is the right place to check 1.1V / 1.3V switching

 

Thanks, I already uploaded the schematic to the linux-sunxi wiki few hours ago.

 

This morning I was looking around the board for test points and noticed that while there's lots of mentions of the regulator being a SY8113, the chip on my One didn't match the markings on the datasheet (top mark should be MLxyz, mine is WC5V1)

 

Great finding. Do you allow me to use your picture for the linux-sunxi wiki? My chip also reads WC5V1 so this isn't the difference. I also tested to supply undervolted DC-IN (4.5V) but that doesn't make a difference (just monitored temperatures under full load when feeding 5.1V and 4.5V).

 

Are you able to measure the 1V2C test point on the board as @szaflik pointed out and get back with results for both states?

[zador.blood.stained]

The most interesting thing on this schematic is that feedback voltage for CPU power regulator comes from separate H3 pins (VDD-CPUFB and GND-CPUFB) and there are test points for these pins too. I would recommend measuring VDD_CPUFB voltage too (test point is marked TP1 on schematic, page 6, top right corner).

[jmarcelino]

Great finding. Do you allow me to use your picture for the linux-sunxi wiki? My chip also reads WC5V1 so this isn't the difference. I also tested to supply undervolted DC-IN (4.5V) but that doesn't make a difference (just monitored temperatures under full load when feeding 5.1V and 4.5V).

 

Are you able to measure the 1V2C test point on the board as @szaflik pointed out and get back with results for both states?

 

Yes of course, use the photo as you please. Thanks for all your help so far, I'm learning a lot too.

 

Just measured the 1V2C test point and seeing it at 1.11 V @ 648 Mhz and switch to 1.31 V for higher speeds and under load - this is of course with the old .fex.

 

TP1 point is showing very similar values, just very slightly lower (less than 0.002V difference)

[kevinheb]

One very minor thing that I've noticed, the red LED comes on initially, but then turns off again after a period of time.  I mistakenly thought that the pi had stopped working, but realised that the pi was still on,. just the led had gone out

[tkaiser]

Just measured the 1V2C test point and seeing it at 1.11 V @ 648 Mhz and switch to 1.31 V for higher speeds and under load - this is of course with the old .fex.

 

Ok, then on your board everything works as expected and my proposed 'fix' leads to the undervoltage situation and the crashes. So something's wrong with my board instead and both my fix-thermal-problems.sh script and the fex settings our Orange Pi One image uses are counterproductive.

 

I believe we would need some more feedback from users now. And at least my board seems to be overvolted. I can run the cpufreq-ljt-stress-test test on the 'lower' voltage even with 1200MHz while running cpuburn-a7 in parallel. But on the higher voltage level it's impossible since then throttling occurs and CPU cores are shut down.

[jernej]

Did anyone noticed that pine64 source code includes newer version of Allwinner's U-Boot? It seems to me that at least some drivers could be reused. like NAND, arisc, video... If NAND driver works as expected, we could support booting from flash.

 

Although their kernel source doesn't support H3 per se, it includes some drivers which should have some improvements against our code base. For example, I noticed that disp2 driver has quiet a lot of changes. Most of them are code reorganization, but some has actual meaning, like additional checks before doing stuff...

 

EDIT: Does mainline U-Boot already supports NAND booting on H3?

[martinayotte]

 

This sounds like the usual 'default gateway' bug/feature.

 

 

Would you please put your fex on pastebin.com or similar to be able to merge your changes? Thx!

 

 

 

Yes, that was a 'default gateway' issue. Fixed by now ...

 

For the FEX diff requires for TW1, here it is :

150c150
< twi_used = 0
---
> twi_used = 1
239,240d238
< gpio_pin_20 = port:PA19<1><default><default><0>
< gpio_pin_21 = port:PA18<1><default><default><0>

[tkaiser]

One very minor thing that I've noticed, the red LED comes on initially, but then turns off again after a period of time.  I mistakenly thought that the pi had stopped working, but realised that the pi was still on,. just the led had gone out

 

Yeah, I overlooked a few settings in the fex file for the Orange Pi PC (GPIOs wrong, SPI not working and also disabled power LED). In case you want to fix this now, grab  the most recent fex file and use fex2bin to overwrite /boot/bin/orangepipc.bin

 

For the FEX diff requires for TW1, here it is

 

Thx, in the meantime I figured it out myself and disabled also two other GPIOs since they conflicted with activated tw0.

 

@all: I sent Igor as part of a pull request the skeleton for h3disp, the utility to be able to patch script.bin for different display resolutions. The patch part is tested and stable but I lack the time/motivation to do the user interaction part (displaying the menu with reasonable HDMI resolutions, letting the user choose one and also ask for the DVI stuff -- see the comments in the script). Might be cool if someone else can take over so that we can include this as /usr/local/bin/h3disp

[tkaiser]

Did anyone noticed that pine64 source code includes newer version of Allwinner's U-Boot?

 

 

Yes, we looked into it 2 months ago. Since A64 seems to be more or less an H3 with Cortex-A53 cores we might be able to take a few parts from there. But I fear that at least my motivation to do so will be very limited if not close to zero since I've to admit that I'm more interested in operating the H3 Orange Pis headless (as cheap but powerful controllers/servers for this and that).

 

But I still hope that a few more devs join in and contribute so every suggestion highly appreciated.

 

BTW: Regarding the Orange Pi One I took some time to collect the major differences to the PC (especially one that already puzzled me: the 'wrong' orientation of the GPIO header. That was the reason I got 1-Wire not to work in the first place and that I wasn't able to power the board through the GPIO pins: I actually tried to fry the board when doing this):

 

Quick Review of Orange Pi One: http://forum.armbian.com/index.php/topic/724-quick-review-of-orange-pi-one/

[martinayotte]

 

especially one that already puzzled me: the 'wrong' orientation of the GPIO header

Oh ! that is strange ...

I didn't received my OPi-One yet, but seeing your discovery, I feel sad. Fortunately, I've only purchased one, and still love my 4 OPi-PC.

[jmarcelino]

Following @tkaiser's guidance I've battered the hell out of the poor H3 on my Pi One with benchmarks. Again for those not following the saga this is using the old switching .fex since apparently my Pi One - unlike some others - is actually switching to the correct voltages.

 

So I started a sysbench --test=cpu --cpu-max-prime=100000 run --num-threads=4 in one session, left it for a while and then started another session to run the cpufreq-ljt-stress-test concurrently. I did this using the "performance" governor with scaling_max_freq set first to 1104000  and then 648000 (which stays at the lower voltage)

 

This is the OPi monitor result:

I don't see evidence of thermal throttling. I also measured temperatures with a probe over the CPU using my Fluke 17B and saw around 44C when running just sysbench+stress test at the lowest core speed going up to 50C when running same at highest core speed. To liven up things a bit I also run cpuburn-a7 on top of both other tests which quickly brought temperature to 65C. This is where the SoC temperature peaks up on the OPi graph, the internal SoC temperature reported by OPi was actually close to 80C - this was a "throw everything at the SoC" kind of moment but still all 4 cores kept operating.

 

Running tests at scaling_max_freq 648000 also revealed no issues.

 

So I'm satisfied that at least my Pi One is solid using the old switching .fex. I hope we can find out what's going on with other Pi Ones which don't like this, for now it means I'll have to keep patching the .fex to work on mine...

 

I'm also now intrigued to try allowing 1200Mhz and perhaps increase the DRAM speed to the "listed" value.

 

On the back of the schematics being available and the problems understood I'm going to order a few more OPi Ones and look forward to testing those. Like tkaiser I'm very much looking to use these as headless controllers.