Orange Pi One Plus usability ?'

[Vincen]

Hi

 

I own since a while an Orange Pi One Plus board that I have been unable to use till now (OS images supplied by manufacturer are just a joke !). I wanted to give it a test with ARMBian as you offer now some Beta images.

As both Bionic and Stretcher are offered, is there one of them more stable or more near something finished ?

Did someone have tried the board with one of these ? and did it work ?

 

Thanks

 

Vincèn

[WarHawk_AVG]

Unknown...Stretch img might be the best bet as it's been around longer

They will eventually dial it in...but in the mean time make sure you keep backups of the stuff you want to keep

 

[Vincen]

57 minutes ago, WarHawk_AVG said:

Unknown...Stretch img might be the best bet as it's been around longer

They will eventually dial it in...but in the mean time make sure you keep backups of the stuff you want to keep

 

Thanks for advices so tested both and it looks like both are still early testing images, not usable at all ! Mac address changes at each boot (so no way to give it a a fixed lease in DHCP) and if you put in fixed IP address when it reboots network never comes back

Interesting bug too: after doing system updates with apt update/upgrade, you can never reboot the system (RED led on board at boot !!).

 

If someone is interested by an useless Orange Pi One Plus v2 board let me know or it'll go to electronic recycle bin and I'll know to never buy again any Orange Pi board (no support at all from manufacturer

[manuti]

I propose to add a little nuance: never buy an Orange Pi board before they have an armbian in supported status https://www.armbian.com/download/?device_support=Supported

[Tido]

2 hours ago, Vincen said:

to electronic recycle bin

H6 SoC is getting more updates in mainline release after release. Come back in 6 months.

 

Network.. it is either broken code or you didn't use: nmtui   to configure.

[guidol]

2 hours ago, Vincen said:

Thanks for advices so tested both and it looks like both are still early testing images, not usable at all ! Mac address changes at each boot (so no way to give it a a fixed lease in DHCP) and if you put in fixed IP address when it reboots network never comes back

If someone is interested by an useless Orange Pi One Plus v2 board let me know or it'll go to electronic recycle bin and I'll know to never buy again any Orange Pi board (no support at all from manufacturer

did you try - when using /etc/network/interfaces - to set a hwadress like

iface eth0 inet dhcp
hwaddress 1a:2b:3c:4d:5e:6f

For not loosing the net-connection - beside the serial tty-port - its alwasy good to have a USB-Ethernet dongle which normally does get a DHCP-Adress without problems (also has the same MAC every time).

 

When the H6 OPis did get available on the market I also thought about buying one - but did read about the problems.
I didnt think that it will be so hard from H2+/H3 over H5 to a H6 CPU-system

 

So I did buy H5 systems like the NanoPI Neo2, K1 Plus or OPi Zero Plus H5 and the OPi Zero Plus2 H5.

 

But mostly the time will come for the systems (OK,  I also have to wait for better supper for my BPI M2 Berry and the NanoPi A64).

 

nmtui mostly work on the systems (also got 1-2 systems where I have to use a USB Ethernet because of missing drivers).

and if nmtui doenst work - on one system I got success using nmcli  after the basic-configuration via nmcli then also nmtui did work for reconfiguration.

 

OPi PC, PC2 and One does work also fine with armbian

 

...and you can always try to build yourself a newer image for your OPi via the armbian-build-system:
https://docs.armbian.com/Developer-Guide_Build-Preparation/

 

[Werner]

On 12/21/2018 at 9:10 AM, Vincen said:

 

Interesting bug too: after doing system updates with apt update/upgrade, you can never reboot the system (RED led on board at boot !!).

 

The reason for this seems to be a regression or a missing commit from @Icenowy sources (https://github.com/Icenowy/linux/commits/h6-integrate-2-ugly) which has not made the jump into mainline (yet).

Therefore you either have to use the 4.18.0-rc7 kernel image (which I run two OPi 1+ perfectly fine on right now) or temporarily disable dwmac like @martinayotte did as workaround to successfully boot up the board with a kernel built from newer sources (and use a USB-Ethernet adapter).

For confirmation you can utilize a UART serial adapter to check the kernel boot for errors like "sun8i_dwmac_probe+0x164/0x518".

 

As stated mainline support has still a long way to go to better support the H6 SoC. Do not just discard the board. Just put it on the shelf and it may run fine in a couple of month.

[WarHawk_AVG]

On 12/21/2018 at 4:26 AM, manuti said:

I propose to add a little nuance: never buy an Orange Pi board before they have an armbian in supported status https://www.armbian.com/download/?device_support=Supported

Nah...I trust their "testing" builds before I trust the releases from the Orange Pi manufacturers

 

[GeraltOfTrivia]

Sorry to necro an old thread, but I didn't find a more suitable one and I didn't want to start a new one. 

Anyway, to the point.

When I install or build any of the Armbian dev/nightly images with kernel 5.x, the sdcard is practically unusable after the installation. 

hdparm shows read/write speeds of max. 5 MB/sec. The reason is that unless the bus-width for mmc@4020000 is explicitly set to 4 bits in 

sun50i-h6-orangepi-one-plus.dtb

 mmc@4020000 {
                        compatible = "allwinner,sun50i-h6-mmc", "allwinner,sun50i-a64-mmc";
                        reg = <0x4020000 0x1000>;
                        clocks = <0x2 0x43 0x2 0x40>;
                        clock-names = "ahb", "mmc";
                        resets = <0x2 0x12>;
                        reset-names = "ahb";
                        interrupts = <0x0 0x23 0x4>;
                        status = "okay";
                        #address-cells = <0x1>;
                        #size-cells = <0x0>;
                        pinctrl-names = "default";
                        pinctrl-0 = <0xb>;
                        vmmc-supply = <0xc>;
                        bus-width = <0x4>;
                        cd-gpios = <0xd 0x5 0x6 0x1>;
                        phandle = <0x2f>;
                };

the bus width defaults to 1 bit as seen in 

root@orangepi:~# cat /sys/kernel/debug/mmc0/ios
clock:          50000000 Hz
actual clock:   50000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      0 (1 bits)
timing spec:    2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type:    0 (driver type B)

which practically cripples the SD card interface. By default there is no bus-width entry in sun50i-h6-orangepi-one-plus.dtb for mmc@4020000. I don't know if this is Armbian specific or not or if this has been mentioned again, I just thought I'd share my findings in case this helps someone. 

[chwe]

hmm interesting

https://github.com/torvalds/linux/blob/e53f31bffe1d552f496b674cd1733658a268e177/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi#L58-L65

seems to be not default in mainline

 

as well as in megous:

https://github.com/megous/linux/blob/e22caec8c77183c5a54d332d55d9af53283ebb68/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi#L58-L65

 

going quickly through our patches doesn't show an obvious one here as well.. Just add @martinayotte

[martinayotte]

31 minutes ago, chwe said:

going quickly through our patches doesn't show an obvious one here as well.. Just add @martinayotte

Yes ! Thanks a lot to @GeraltOfTrivia for reporting !!!

This seems to have slipped in all Kernel Devs faces, even @megous or @Icenowy ...

I'm just adding 3 patches to Armbian : one for H3-H5, one for A64 and one for H6 ...

 

EDIT : I've figured out that some boards have the bus-width directly into their own DTS, like OPiPrime, but some other don't like Pine64. So, my patches done on DTSI is more general and more safe.

Committed : https://github.com/armbian/build/commit/2645877aa5d5c58ac792d74f1bdc751ede55fa8d

 

Quote

bus-width: Number of data lines, can be <1>, <4>, or <8>. The default will be <1> if the property is absent.

 

[Icenowy]

Maybe it's some early patch.

 

In early development of Pine H64 support, I missed bus-width for Pine H64. (BTW do anyone of you here have the experience of installing an ECC-capable brain?) Then it gets fixed in commit d177c8b61d6b4ef360b1c2682e4d8e3bae01738b .

 

If it's some early patch derived from Pine H64 patch in 4.19, it might suffer from this error.

[martinayotte]

7 minutes ago, Icenowy said:

Maybe it's some early patch.

Hi @Icenowy , glad of your presence !

What we have just catch now, is that all AllWinner SoC DTSI don't default it to 4bits, and since most boards DTS don't explicitly provide the bus-width, it is defaulted to 1bits.

So I bet there are many boards in this situation ... I don't know how many, so that is why my own Armbian patches is forcing it directly on DTSI ...

[Icenowy]

@martinayotteI think many board DO explicitly provide the bus-width. Of course, I think many people haven't equipped ECC brain like me, so there could be some boards w/o bus-width.

 

You can submit patches for mainline for those boards.

 

The mainline doesn't agree to add bus-width to SoC DTSI because it's for the board's designer to decide the bus-width (of course it cannot go beyond the controller's maximum). For example, some board uses a SD card slot (which is bus-width = <4>) on a eMMC controller (which can be at most bus-width = <8>), and in this case the 4 remaining data lines can even be used as GPIO.

[megi]

@martinayotte Pine64 has bus-width set to 4 in 5.1-rc#. There are no boards that don't set it mainline:

 

You can check with:

 

grep -L bus-width `grep -Rl '&mmc0'`

 

[martinayotte]

19 minutes ago, megi said:

Pine64 has bus-width set to 4 in 5.1-rc

You're right for Pine64, it is just in the hurry, when doing "cat /sys/kernel/debug/mmc0/ios" with no SDCard inserted (I've a USB-HDD as rootfs of my Pine64), it shows 1 bits ...

But in the case of OPiOnePlus and OPiLite2, they are really absent ...

 

EDIT : Sorry for the false alarms, Megous is right, and OPiOnePlus and OPiLite2 are created by Armbian scripts, not from his branch.

[maxnuker]

What is the current state of the Orange Pi One Plus? I was looking between getting this one and a PC2 (with the H5) to hook up to a 3d printer to be running octoprint. Would you guys recommend to get a One Plus or go with the H5 since it's already in supported state?

 

 

[Igor]

On 5/10/2019 at 12:49 AM, maxnuker said:

What is the current state of the Orange Pi One Plus? I was looking between getting this one and a PC2 (with the H5) to hook up to a 3d printer to be running octoprint. Would you guys recommend to get a One Plus or go with the H5 since it's already in supported state?

 

 

Orangepi PC2 is a good board and would be much safer option since support is fairly mature, while (any) H6 still has many glitches and is still under development.