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

[martinayotte]

I have successfully tested i2c on Armbian 5.04 with RTC 3231 module

Good !

Glad to see this post !

As TKaiser said very often, this kind of post merits to be transformed to some kind of Tutorial in the forum ...

I've could then contribute by posting my MCP3017 python code.

[martinayotte]

BTW, since talking about I2C, since my previous attempt to get it working on Mainline 4.4.1 several weeks ago, I've tried several thing on the newer 4.4.3 these recent days.

I'm kind of newbie with DTS, I've tried many things assuming that I2C on H3 is supposed to be the same as A23/A31/A58 ... Am I right ?

I didn't get any success and dmesg didn't provide me much details yet.

If I can get I2C and SPI working fine under 4.4.3, I would be glad to switch to it forever and drop 3.4.110.

[yogesh]

Good !

Glad to see this post !

As TKaiser said very often, this kind of post merits to be transformed to some kind of Tutorial in the forum ...

I've could then contribute by posting my MCP3017 python code.

Thanks ..Let me add more verbose instruction with photo and add this as tutorial to forum.English is not first language so it will take some time

 

I have some interesting stuff in home lab and in coming days I will  like to make them working under Armbian.

[tkaiser]

BTW, since talking about I2C, since my previous attempt to get it working on Mainline 4.4.1 several weeks ago, I've tried several thing on the newer 4.4.3 these recent days.

I'm kind of newbie with DTS, I've tried many things assuming that I2C on H3 is supposed to be the same as A23/A31/A58 ... Am I right ?

 

H3 or Orange Pi PC hasn't landed in mainline kernel yet. All that Armbian does is to try to collect the various patches here and there, patch the kernel sources on the fly and then you end up with a somewhat working OPi PC. Main problem is the device tree stuff, there's not that much defined yet:

 

 

 

/*
 * Copyright (C) 2015 Chen-Yu Tsai <wens@csie.org>
 *
 * This file is dual-licensed: you can use it either under the terms
 * of the GPL or the X11 license, at your option. Note that this dual
 * licensing only applies to this file, and not this project as a
 * whole.
 *
 *  a) This file is free software; you can redistribute it and/or
 *     modify it under the terms of the GNU General Public License as
 *     published by the Free Software Foundation; either version 2 of the
 *     License, or (at your option) any later version.
 *
 *     This file is distributed in the hope that it will be useful,
 *     but WITHOUT ANY WARRANTY; without even the implied warranty of
 *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *     GNU General Public License for more details.
 *
 * Or, alternatively,
 *
 *   Permission is hereby granted, free of charge, to any person
 *     obtaining a copy of this software and associated documentation
 *     files (the "Software"), to deal in the Software without
 *     restriction, including without limitation the rights to use,
 *     copy, modify, merge, publish, distribute, sublicense, and/or
 *     sell copies of the Software, and to permit persons to whom the
 *     Software is furnished to do so, subject to the following
 *     conditions:
 *
 *     The above copyright notice and this permission notice shall be
 *     included in all copies or substantial portions of the Software.
 *
 *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
 *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
 *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 *     OTHER DEALINGS IN THE SOFTWARE.
 */

/dts-v1/;
#include "sun8i-h3.dtsi"
#include "sunxi-common-regulators.dtsi"

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/sun4i-a10.h>

/ {
	model = "Xunlong Orange Pi PC";
	compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3";

	aliases {
		serial0 = &uart0;
	};

	chosen {
		stdout-path = "serial0:115200n8";
	};
};

&ehci1 {
	status = "okay";
};

&ehci2 {
	status = "okay";
};

&ehci3 {
	status = "okay";
};

&ir {
	pinctrl-names = "default";
	pinctrl-0 = <&ir_pins_a>;
	status = "okay";
};

&mmc0 {
	pinctrl-names = "default";
	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
	vmmc-supply = <&reg_vcc3v3>;
	bus-width = <4>;
	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
	cd-inverted;
	status = "okay";
};

&ohci1 {
	status = "okay";
};

&ohci2 {
	status = "okay";
};

&ohci3 {
	status = "okay";
};

&uart0 {
	pinctrl-names = "default";
	pinctrl-0 = <&uart0_pins_a>;
	status = "okay";
};

&usbphy {
	/* USB VBUS is always on */
	status = "okay";
}; 

 

 

 

If I2C/SPI isn't already defined in one of the icludes then it's not there (hardware definitions are dropping in slowly, as an example the IR receiver). So by combining .dts/fex for a better supported board like Banana Pi for example you might get the idea how to create a dts patch for the userpatches dir to get these nodes at least defined.

 

Thanks ..Let me add more verbose instruction with photo and add this as tutorial to forum.English is not first language so it will take some time

 

I have some interesting stuff in home lab and in coming days I will  like to make them working under Armbian.

 

Really looking forward to it

 

BTW: Since I've seen you're already interested in the camera module please keep in mind the "Known to NOT work (reliably) yet" section in our H3 Mini FAQ. It would also be great if @lex would join the party since he has the skills to apply the missing patches so the camera could be useable in Armbian

[Manjuprasad Basangi]

How do i compile MT7601 Wifi Dongle Driver on armbian for orangepi one.
I have an loboris image for Orangepi PC which has driver for MT7601.
How i import driver from loboris kernel to armbian sd card.
Please Help

[tkaiser]

How do i compile MT7601 Wifi Dongle Driver on armbian for orangepi one.

 

Why would you want to do this? The driver should already be included and last commit is 10 days old so it should work with 5.04 out of the box.

 

If there's a problem it would help if you try to explain the problem in a way others can understand/help/fix. Describe which OS image you're using, describe what you're doing, describe what you expect that should happen and what happens in reality. Without providing at least dmesg and lsusb output (using something like pastebin.com!) I fear we can't help at all.

[Da Alchemist]

I am still searching for a solution of the little HDMI Sound Problem (there is some strange Downmix to 2 Channels instead of 8) A very interesting thing i found doing some googling, is this Patch: https://github.com/igorpecovnik/lib/blob/master/patch/kernel/sun4i-default/0023-HDMI-8ch-and-Alsa-fix.patch

 

Is it included in the Kernel?

 

Regards

[tkaiser]

I am still searching for a solution of the little HDMI Sound Problem (there is some strange Downmix to 2 Channels instead of 8) A very interesting thing i found doing some googling, is this Patch: https://github.com/igorpecovnik/lib/blob/master/patch/kernel/sun4i-default/0023-HDMI-8ch-and-Alsa-fix.patch

 

Is it included in the Kernel?

 

Nope, since:

checking file drivers/video/sunxi/hdmi/drv_hdmi.c
Hunk #1 FAILED at 314.
1 out of 1 hunk FAILED
checking file sound/soc/sunxi/hdmiaudio/sndhdmi.c
Hunk #1 FAILED at 85.
Hunk #2 FAILED at 129.
2 out of 2 hunks FAILED
checking file sound/soc/sunxi/hdmiaudio/sunxi-hdmiaudio.c
Hunk #1 FAILED at 34.
Hunk #2 FAILED at 67.
Hunk #3 FAILED at 182.
3 out of 3 hunks FAILED
checking file sound/soc/sunxi/hdmiaudio/sunxi-hdmipcm.c
Hunk #1 FAILED at 45.
Hunk #2 succeeded at 417 with fuzz 2 (offset 70 lines).
Hunk #3 succeeded at 448 with fuzz 2 (offset 73 lines).
1 out of 3 hunks FAILED

At least all the files are there so anyone with a bit of time and knowledge could've a look whether this sun4i patch could be applied to the sun8i sources and then create a proper patch

[Manjuprasad Basangi]

Board Orangepione:

OS: Armbian 5.04 h3;
Problem: does not detect wifi connections if i am using MT7601 Wifi dongle.

Modified /etc/network/interfaces

 

auto eth0

        iface eth0 inet dhcp

#       hwaddress ether # if you want to set MAC manually

#       pre-up /sbin/ifconfig eth0 mtu 3838 # setting MTU for DHCP, static just$

#

# Wired adapter #2

#auto eth1

#       iface eth1 inet dhcp

#       hwaddress ether # if you want to set MAC manually

#       pre-up /sbin/ifconfig eth0 mtu 3838 # setting MTU for DHCP, static just$

#

# Wireless adapter #1

auto wlan0

        iface wlan0 inet dhcp

        wpa-ssid *********

        wpa-psk ******

auto ra0

     iface ra0 inet dhcp

     wpa-ssid *************

     wpa-psk ******

 

 

 

 

Dongles work: 
Tplink WN721N : Atheros AR9271 chipset
TPLINK WN823N : RTL8192CU chipset

My lsusb:
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 002 Device 004: ID 0461:4d0f Primax Electronics, Ltd HP Optical Mouse

Bus 002 Device 003: ID 1a2c:0c21 China Resource Semico Co., Ltd

Bus 002 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 001 Device 002: ID 148f:7601 Ralink Technology, Corp.

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

dmesg: http://pastebin.com/MsdVwwRw

[Da Alchemist]

Nope, since:

At least all the files are there so anyone with a bit of time and knowledge could've a look whether this sun4i patch could be applied to the sun8i sources and then create a proper patch

 Thanks for checking, these things. Compiling a kernel for armbian is beyond my skills, i have only managed to do the Multichannel Changes on my pi....

 

 

Regards

[tkaiser]

dmesg: http://pastebin.com/MsdVwwRw

 

Thx. Disclaimer: I dealt exactly one time in my live with WiFi in Linux, had a laugh and gave up (so terrible especially when compared with OS X). So I'm not able to help you. Maybe others jump in. You could help them helping you by providing more informations (since dmesg output doesn't show anything regarding connected devices), whether the problem also occurs when you directly attach the dongle and so on...

 

 Thanks for checking, these things. Compiling a kernel for armbian is beyond my skills

 

That's why I checked the patch asapissimo -- to get the idea whether it's worth a look. Either by you or by someone else interested in audio improvements. If OPi users don't start to act as a strong community they're lost since vendor support can't be expected (you get what you pay for -- I'm always having a good laugh when people complain publicly that they expect 1st class customer support for a board worth 10 bucks

[tetref]

Hi, my little experience with Orange Pi One:

 

1. Hardware

Wifi dongle TP-LINK TL-WN722N (Atheros Communications, Inc. AR9271 802.11n) - Working

Wifi dongle Edimax (Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]) - Working

Wifi dongle ??? (Ralink Technology, Corp. RT5370 Wireless Adapter) - BAD

USB hub PremiumCord KU2HUB4WN (Terminus Technology Inc. 4-Port HUB) - Working

 

2. Software (Armbian 5.04 Orangepi h3 Ubuntu trusty desktop)

without network LAN is booting 2 minutes

/etc/init.d/armhwinfo not recognize my board OPI One (after little dirt hack this file, ...)

Because my DVI monitor 1280x1024 is not recognize (unsuported resolution), i had to edit the orangepih3.dvi and orangepione.dvi file in section [disp_init] screen0_output_mode to 5 and of course DVI hack in [hdmi_para]

 

Setting other language:

apt-get install language-pack-xx

nano /etc/default/locale - change to my language

update-locale LANG=xx_XX.utf-8

dpkg-reconfigure locales

nano /etc/environment (add two lines: LANG="xx_XX.UTF-8" and LC=ALL="xx_XX.UTF-8")

after rebooting is desktop localized

[tkaiser]

without network LAN is booting 2 minutes

/etc/init.d/armhwinfo not recognize my board OPI One (after little dirt hack this file, ...)

Because my DVI monitor 1280x1024 is not recognize (unsuported resolution), i had to edit the orangepih3.dvi and orangepione.dvi file in section [disp_init] screen0_output_mode to 5 and of course DVI hack in [hdmi_para]

 

Thx for the feedback. Regarding the above stuff. If you often boot without connected Ethernet think about replacing 'auto' with 'allow-hotplug' (we use this at the 1st boot to speed things up if network is not available and replace it with auto for safety reasons automatically later). Auto detection of the OPi should work with the 5.04 release so it would maybe help if you can comment a bit more on this.

 

And regarding the 1280x1024 issue it would be good if you provide your solution so others can apply this.

 

Regarding hardware issues I try to sum it up

• we have one report of a non-working RT5370 (lsusb/dmesg missing)
• we have one report of a non-working MT7601 (dmesg output strange)
• we have one report claiming something's wrong setting the 480i HDMI mode (at least I wasn't able to understand what has been done and what happened
• regarding HDMI audio maybe someone experienced could have a look whether this older Patch can be applied to the H3 sources
• and everything that's listed in "Known to NOT work (reliably) yet"

Am I'm missing something?

[jernej]

@tkaiser,

there is really no point in using CedarX binary libraries. You could extract them and that's about it, because none of the standard video players know how to use it. Much better approach would be to use libvdpau-sunxi. That way, any player, which knows how to use VDPAU API, should work and it's open source

 

EDIT: About HDMI audio patch - As far as I can see, almost all changes are already included, namely setting max number of channels to 8. Probably something can be improved by looking at A64 kernel source and porting changes over.

[tetref]

Thx for the feedback. Regarding the above stuff. If you often boot without connected Ethernet think about replacing 'auto' with 'allow-hotplug' (we use this at the 1st boot to speed things up if network is not available and replace it with auto for safety reasons automatically later). Auto detection of the OPi should work with the 5.04 release so it would maybe help if you can comment a bit more on this.

 

 

And regarding the 1280x1024 issue it would be good if you provide your solution so others can apply this.

 

 

To speed up boot process i am set /etc/network/interfaces.default

# Wired adapter #1
#auto eth0
#    iface eth0 inet dhcp
#    hwaddress ether # if you want to set MAC manually
#    pre-up /sbin/ifconfig eth0 mtu 3838 # setting MTU for DHCP, static just: mtu 3838
#
# Wired adapter #2
#auto eth1
#    iface eth1 inet dhcp
#    hwaddress ether # if you want to set MAC manually
#    pre-up /sbin/ifconfig eth0 mtu 3838 # setting MTU for DHCP, static just: mtu 3838
#
# Wireless adapter #1
#auto wlan0
#    iface wlan0 inet dhcp
#    wpa-ssid .............
#    wpa-psk .............
#auto wlan1
# to generate proper encrypted key: wpa_passphrase yourSSID yourpassword
#
# Local loopback
auto lo
    iface lo inet loopback

and Wicd Network manager make access to network...

 

And solution for 1280x1024?

 

Simply change default setting for orangepih3.bin:

 

[disp_init]

...

screen0_output_type = 3

screen0_output_mode = 5

screen1_output_type = 3

screen1_output_mode = 5

...

 

and then after running h3disp I set desired resolution, DVI etc.

[tkaiser]

use VDPAU API [...] Probably something can be improved by looking at A64 kernel source and porting changes over.

 

I've been told we use VDPAU already And regarding audio another one has to look into. I'm already perfectly satisfied being able to use OPi PC/One headless for the stuff we need them for

 

[disp_init]

...

screen0_output_type = 3

screen0_output_mode = 5

screen1_output_type = 3

screen1_output_mode = 5

 

Already changed days ago and default with next release.

[martinayotte]

H3 or Orange Pi PC hasn't landed in mainline kernel yet. All that Armbian does is to try to collect the various patches here and there, patch the kernel sources on the fly and then you end up with a somewhat working OPi PC. Main problem is the device tree stuff, there's not that much defined yet:

 

If I2C/SPI isn't already defined in one of the icludes then it's not there (hardware definitions are dropping in slowly, as an example the IR receiver). So by combining .dts/fex for a better supported board like Banana Pi for example you might get the idea how to create a dts patch for the userpatches dir to get these nodes at least defined.

 

Yes, that was my intention, but unfortunately, it doesn't seem to be an easy task. I will try to dig further ...

[jernej]

@tkaiser,

did you notice this patch? It's about led and keys definition and it is already merged.

[martinayotte]

Just to let you know : I've finally got I2C working under 4.4.4 !!!

Several days of work, adding traces into kernel driver, to let me figure out that everything was related to <&bus_res> register.

I will now try to get SPI working, and cleanup the sun8i-h3.dtsi to produce a patch. This patch probably needs to be submit to Mainline guys.

[tkaiser]

did you notice this patch? It's about led and keys definition and it is already merged.

 

Hmm... on every OS image so far the red led was power and the green one user defined and now just the opposite: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/411512.html

 

Just to let you know : I've finally got I2C working under 4.4.4 !!!

Several days of work, adding traces into kernel driver, to let me figure out that everything was related to <&bus_res> register.

I will now try to get SPI working, and cleanup the sun8i-h3.dtsi to produce a patch. This patch probably needs to be submit to Mainline guys.

 

Good luck with the latter. I doubt the mainline guys like boards that work as expected in the meantime. But producing a patch would be fantastic so the various distros (well, mainline kernel? Ok, Armbian) can integrate the patch and we can move on to 4.4 rather sooner than later. BTW: You're doing great work, highly appreciated!

[jernej]

Hmm... on every OS image so far the red led was power and the green one user defined and now just the opposite: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/411512.html

 

To be honest, I also tried to use green led for power. Actually, my ultimate goal is to have green led for power on and red led for suspend. Feels more natural because other home entertainment devices has same policy. However, I didn't succed in to turn on green led in U-Boot due to problems with R_PIO pins. Maybe I didn't enable clock or there is problem with pin mapping or both. But currently I have more interesting work than playing with LEDs.

[martinayotte]

Good luck with the latter. I doubt the mainline guys like boards that work as expected in the meantime. But producing a patch would be fantastic so the various distros (well, mainline kernel? Ok, Armbian) can integrate the patch and we can move on to 4.4 rather sooner than later. BTW: You're doing great work, highly appreciated!

 

BTW, Thanks, Tkaiser !

 

I've finally got the SPI working after whole day of work, I've faced several issues, one of them was related to http://www.spinics.net/lists/linux-spi/msg03301.html where Mainline guys don't wish that SPIDEV been part of the DT.

So, now I will have to work on the tasks of creating a patch for Armbian containing all DTS fixes but also small addition to driver/spi/spidev.c

 

(BTW, I've finally received my Opi-One this afternoon, but didn't got chance to try it out yet)

[tkaiser]

To be honest, I also tried to use green led for power. Actually, my ultimate goal is to have green led for power on and red led for suspend.

 

Ok, this is useful from a 'user experience' point of view. As soon as you get the green led working please drop us a note, we will switch the behaviour of both leds (I also believe it would make some sense if our projects coordinate a bit regarding user experiences)

 

I've finally got the SPI working after whole day of work, I've faced several issues, one of them was related to http://www.spinics.net/lists/linux-spi/msg03301.html where Mainline guys don't wish that SPIDEV been part of the DT.

So, now I will have to work on the tasks of creating a patch for Armbian containing all DTS fixes but also small addition to driver/spi/spidev.c

 

Great! If you want to go the extra mile think about submitting it upstream. You will learn a lot but it might also cause a 'bit' of frustration And another problem might be that you would have to rebase your patch since AFAIK there exist currently a few different WiP branches for H3 upstream.

[tkaiser]

Since we just upgraded our development version number to 5.05 a quick overview of open issues with Armbian for H3 devices. I try again to sum up the reports of users claiming something's not working correctly or definitely known to not work yet:

1. we have one report of a non-working RT5370 (lsusb/dmesg missing)
2. we have one report of a non-working MT7601 (dmesg output strange)
3. we have one report claiming something's wrong setting the 480i HDMI mode (at least I wasn't able to understand what has been done and what was expected)
4. regarding HDMI audio maybe someone experienced could have a look whether this older Patch can be applied to the H3 sources
5. and everything that's listed in "Known to NOT work (reliably) yet"

N° 1, 2 and 3 will remain unresolved since informations are missing and we can not reproduce the issue. Regarding N°4 we need someone familiar with audio stuff who wants to look into the issue. And regarding the known issues I fear booting from NAND on OPi Plus won't be possible with the next version also -- the other issues should've been resolved.

 

If we don't get comprehensive feedback on the first issues above then nothing will change. The same with feature requests. Users write us personal messages demanding this and that instead of joining the thread or opening an issue on Github. Juste a waste of time. No need to poke individuals -- this is a community project! If you demand something from the project you would've to contribute to the project

[jernej]

1. regarding HDMI audio maybe someone experienced could have a look whether this older Patch can be applied to the H3 sources
2. and everything that's listed in "Known to NOT work (reliably) yet"

N° 1, 2 and 3 will remain unresolved since informations are missing and we can not reproduce the issue. Regarding N°4 we need someone familiar with audio stuff who wants to look into the issue. And regarding the known issues I fear booting from NAND on OPi Plus won't be possible with the next version also -- the other issues should've been resolved.

 

4. Audio patch has no significance on H3. Basically it just sets number of channels to 8 and that's done already.

5. I think you can remove HW video decoding point, if you sure that Armbian alreadi includes libvdpau-sunxi. You can also take updated driver for wifi from my github, although I'm not sure how much better it is. Speed is still something to be desired.

 

About booting from NAND: Yes, that will still take a long time before it would be possible, but I made same mistake as you. OPiPlus has eMMC not NAND. This means that in theory it uses same driver as SD card and booting should be possible. I think that just U-Boot configuration should be adjusted. I will try this next week, when I get hands on Plus.

[tkaiser]

About booting from NAND: Yes, that will still take a long time before it would be possible, but I made same mistake as you. OPiPlus has eMMC not NAND. This means that in theory it uses same driver as SD card and booting should be possible. I think that just U-Boot configuration should be adjusted. I will try this next week, when I get hands on Plus.

 

Good to know! Since I don't have the Plus in both issues (WiFi and eMMC) another one has to look into. We already added to the H3 Armbian Mini FAQ the 5.05 release info that HW accelerated video now works with most formats. Maybe we also switch with the desktop version from Ubuntu Trusty to Xenial since this might increase user experience a bit or a lot depending on the perspective (to be discussed internally).

 

BTW: Zador (my personal hero) added FEL boot and rootfs over NFS capabilities to our build process. That means when you connect the board to test to the build host with USB the time between finished build and boot can be reduced close to 0 seconds (and no SD cards were harmed during testing )

[martinayotte]

Here are the patches I've prepared for getting I2C and SPI on OrangePiPC under 4.4.4.

 

BTW, Tkaiser, I wouldn't been able to add the last I2C (TWI_R where the PMIC is attached) because lack of PL* pins in the current H3 pinctrl.

I would'nt like start new task for that since the mainline guys already working to have another H3 R_PinCtrl : https://lkml.org/lkml/2016/2/1/150

orangepipc-patches.zip

[jernej]

@tkaiser,

I can confirm that booting from eMMC already works. Only one option is needed to be turned on in U-Boot (check my github).

 

There is one interesting detail, though. /dev/mmcblk0 and /dev/mmcblk1 have reversed meaning for Plus, at least in OpenELEC. Usually, /dev/mmcblk0 is SD card, but for Plus this means eMMC.

[tkaiser]

Dear users,

 

we need again your help. We're currently developing some sort of a support framework called armbianmonitor that enhances collecting important system health data.

 

One of the more advanced armbianmonitor features will be disk monitoring. This is quite easy when done with SATA disks (applies to the A10/A20/i.MX6/Marvell boards we support) but somewhat challenging when we're talking about USB disks.

 

Depending on the USB-to-SATA bridge chip used onboard (Orange Pi Plus) or in the disk enclosures it's a bit hard to query the disk or even impossible.

 

And this is where you have to help us collecting a huge amount of data from our user base. The most recent armbianmonitor version supports the -d switch. In case you call "sudo armbianmonitor -d" it checks whether a disk is connected (if none it silently exits) and if any, loops through every disk and tries do detect the disk features.

 

The current code does not do that much except of collecting support data that helps us to improve this feature in one of the next Armbian releases. Since I've only 6 different USB-to-SATA bridges here we need your help. If you've one or more USB disks lying around please think about connecting it to your Orange Pi one after another and start "sudo armbianmonitor -d". There's no need to mount the disk, it needs not even a partition table or filesystem readable by Linux. It's only about "disk attached to USB port".

 

Armbianmonitor starts to collect data, might install necessary requirements automagically (gdisk or smartmontools for example), will upload the collected data to an online pasteboard service (sprunge.us -- this will then look somewhat like this) and provide you with the URL to the data. Then you should post the URL together with armbianmonitor's full output here so I can start to analyse this stuff when I'm back from vacation.

 

The new armbianmonitor version will be part of Armbian 5.05 (to be released soon) or you get it doing this as root:

wget -q -O /usr/local/bin/armbianmonitor https://raw.githubusercontent.com/ThomasKaiser/lib/master/scripts/armbianmonitor/armbianmonitorchmod755 /usr/local/bin/armbianmonitor/usr/local/bin/armbianmonitor -d 

Please do not expect feedback on your reports now, they just help us to improve our software and it will take some time to even look into it (at least for me since it's time for vacation now)

 

BTW: If we don't get at least 50 different reports back then it's already time to think about stopping the whole armbianmonitor approach

[jimbolaya]

If you've one or more USB disks lying around please think about connecting it to your Orange Pi one after another and start "sudo armbianmonitor -d". There's no need to mount the disk, it must not even have a partition table or filesystem readable by Linux. It's only about "disk attached to USB port".

 

So, specifically USB -> SATA bridges with a SATA device attached. Not just any USB storage like flash.

 

Also I read "it must not even have a partition table or filesystem readable by Linux." to mean that it must be a blank disk with no partition table whatsoever.