OrangePi Zero2 - Allwinner H616

[btrfs]

thx to post of successful run yesterday so i find i cant load from any 32 GB card but works on 16GB. assuming card in ur run 64GB and tha ti can run 4.9 linux from 32 gb its some driver timing error cuz not depend on file systems. i got some error data from driver  error occurs on fs runtime but never on bootimg load on start

 

in: Mounting roo[    3.914411] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
t file system ..[    3.922603] dwmac-sun8i 5020000.ethernet: Normal descriptors
. Begin: Running[    3.929684] dwmac-sun8i 5020000.ethernet: Chain mode enabled
 /scripts/local-[    3.937249] libphy: stmmac: probed
top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
[    3.968273] mmc0: host does not support reading read-only switch, assuming write-enable
[    3.978283] mmc0: new high speed SDHC card at address 0001
[    3.984807] mmcblk0: mmc0:0001 SD 29.2 GiB 
[    3.990677]  mmcblk0: p1 p2 p3
[    4.006865] random: fast init done
[    4.130966] sunxi-mmc 4020000.mmc: irq 23 opcode 18 error -110 blksize 512 blk_addr 61156183 flags 512 data error, sending stop command
[    5.140649] sunxi-mmc 4020000.mmc: send stop command failed
[   33.764700] usb1-vbus: disabling
[   33.767942] vcc3v3-ext: disabling
[   33.771618] vcc3v3-ext2: disabling
[   33.775338] cldo1: disabling

 

or that

 

Begin: Will now check root file system ... fsck from util-linux 2.34
[/usr/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 
/dev/mmcblk0p1: [    4.395397] sunxi-mmc 4020000.mmc: irq 23 opcode 25 error -110 blksize 512 blk_addr 1056768 flags 256 data error, sending stop command

 

but thats all i could understand for now

 

 

[XFer012]

I used Putty (Windows) and a CP2104 USB-to-Serial adapter, at 115200.

32 GB Sandisk Ultra card, written with Balena Etcher

[jernej]

20 hours ago, XFer012 said:

Unable to detect (or change) CPU frequency/governor:

that gets sorted out usually very late, when a lot of other features are already working.

 

20 hours ago, XFer012 said:

Some dmesg entries indicate the kernel is still alpha-stage, as expected:

sun50i-h616-pinctrl 300b000.pinctrl: supply vcc-pf not found, using dummy regulator
sun50i-h616-pinctrl 300b000.pinctrl: supply vcc-pi not found, using dummy regulator
dwmac-sun8i 5020000.ethernet: supply phy-io not found, using dummy regulator
dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 51fe6 (expect 0)
usb1-vbus: disabling
vcc3v3-ext: disabling
vcc3v3-ext2: disabling
cldo1: disabling

Those messages don't indicate alpha stage. Disabling just means that regulator was enabled at boot but Linux doesn't need it. "using dummy regulator" means that voltage regulator is not needed (vcc- regulators might get specified later but most of the time are not needed). syscon value message is imo useless and will probably get removed sooner or later.

In short - several of these messages will probably stay in later, more complete kernel.

[jernej]

13 hours ago, Henry Delphing said:

How to do that?   If I can enable USB to activate my webcam, it is already almost 100% usable to me.

Check ohci, ehci and usbphy nodes in my DT: https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts#L134 and https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi. You should make a patch which adds these changes to DT, add patch to build system and build image. You can probably get away with making DT overlay too.

Note that these are developer level instructions - I don't plan to write more detailed steps.

[XFer012]

(vs. kernel messages): Thank you!

Since the cpufreq driver will be sorted out later, is there a way to fix the CPU frequency to a known working value via DTB? Just to perform a few tests with a fixed, known CPU clock.

[jernej]

You can try with (but no guarantee) in cpu0 node:

assigned-clocks = <&ccu CLK_CPUX>;
assigned-clock-rates = <1080000000>;

Safe default is set in SPL (one of the first things that's is done).

23 minutes ago, XFer012 said:

Since the cpufreq driver will be sorted out later

Note that everything is done by community without any plan. I just told you current pattern regarding these things. It could be that someone would prepare such patches soon or no one would find it interesting enough to work on it.

[XFer012]

Understood, thank you!

[jernej]

@XFer012Above DT change will most probably lock up CPU - CPU is changing clock from which it is running. Much safer bet is to change CONFIG_SYS_CLK_FREQ in U-Boot to the frequency you want. There CPU is first switched to alternate (slow) clock source and once main CPU clock is adjusted, it's switched back.

[XFer012]

Excellent advice, thanks!

[XFer012]

I failed to enable the USB port.

Let's see:

 

1. I decompiled the DTB of the unstable image to a DTS

2. Examining jernej's DTS and DTSI files, I found all the nodes related to USB in the original DTS; none was missing, there was a good correspondence between the decompiled DTS and jernej's DT sources

3. The USB nodes:
 

usb@5310000
usb@5311000
usb@5311400

had

status = "disabled";

and I changed them to

status = "okay";

 

4. I also changed the model name to

model = "OrangePi Zero2 USB v1";

 

in order to verify it was actually loaded.

 

5. I rebuilt the DTB (after having saved the original one as .bak)

dtc -I dts -O dtb /boot/dtb/allwinner/sun50i-h616-orangepi-zero2_USB.dts -o /boot/dtb/allwinner/sun50i-h616-orangepi-zero2.dtb

 

6. Rebooted

7. Checked the new DTB was loaded:

cat /proc/device-tree/model	

OrangePi Zero2 USB v1

 

8. Checked the status of the edited USB nodes (under /proc/device-tree/soc): now all USB nodes have status = okay

 

Despite that, USB port does not work: inserting a pendrive does not trigger anything, no lines on "dmesg"

 

Maybe enabling all the USB nodes is not enough... anyway, it was an interesting task, and I learned a few new things!

 

sun50i-h616-orangepi-zero2_USB.dts

[jernej]

@XFer012Check USB changes here https://github.com/jernejsk/linux-1/commit/a57b81d6188b0f8888d4856c17eff5c5e9816fd8 You can ignore others. Note the changes in number of phys in usbphy nodes.

[XFer012]

First of all, thanks for your support. Much appreciated.

 

It seems to me, that changes in that commit are already present in my decompiled DTS (from kernel 5.11.11-sunxi64 Thu Apr 1): I see the same phys references in USB nodes. It's a bit hard without the labels, but

phys = <0x15 0x01>

seem to correspond to your

phys = <&usbphy 1>

and so on

 

		usb@5100000 {
			compatible = "allwinner,sun50i-h616-musb\0allwinner,sun8i-a33-musb";
			reg = <0x5100000 0x400>;
			clocks = <0x02 0x72>;
			resets = <0x02 0x32>;
			interrupts = <0x00 0x19 0x04>;
			interrupt-names = "mc";
			phys = <0x15 0x00>;
			phy-names = "usb";
			extcon = <0x15 0x00>;
			status = "okay";
			dr_mode = "otg";
			phandle = <0x35>;
		};

		phy@5100400 {
			compatible = "allwinner,sun50i-h616-usb-phy";
			reg = <0x5100400 0x24 0x5101800 0x04 0x5200800 0x04 0x5310800 0x04 0x5311800 0x04>;
			reg-names = "phy_ctrl\0pmu0\0pmu1\0pmu2\0pmu3";
			clocks = <0x02 0x63 0x02 0x65 0x02 0x67 0x02 0x69>;
			clock-names = "usb0_phy\0usb1_phy\0usb2_phy\0usb3_phy";
			resets = <0x02 0x26 0x02 0x27 0x02 0x28 0x02 0x29>;
			reset-names = "usb0_reset\0usb1_reset\0usb2_reset\0usb3_reset";
			status = "okay";
			#phy-cells = <0x01>;
			usb0_vbus-supply = <0x16>;
			usb1_vbus-supply = <0x17>;
			phandle = <0x15>;
		};

		usb@5101000 {
			compatible = "allwinner,sun50i-h616-ehci\0generic-ehci";
			reg = <0x5101000 0x100>;
			interrupts = <0x00 0x1a 0x04>;
			clocks = <0x02 0x6a 0x02 0x6e 0x02 0x62>;
			resets = <0x02 0x2a 0x02 0x2e>;
			status = "okay";
			phandle = <0x36>;
		};

		usb@5101400 {
			compatible = "allwinner,sun50i-h616-ohci\0generic-ohci";
			reg = <0x5101400 0x100>;
			interrupts = <0x00 0x1b 0x04>;
			clocks = <0x02 0x6a 0x02 0x62>;
			resets = <0x02 0x2a>;
			status = "okay";
			phandle = <0x37>;
		};

		usb@5200000 {
			compatible = "allwinner,sun50i-h616-ehci\0generic-ehci";
			reg = <0x5200000 0x100>;
			interrupts = <0x00 0x1c 0x04>;
			clocks = <0x02 0x6b 0x02 0x6f 0x02 0x64>;
			resets = <0x02 0x2b 0x02 0x2f>;
			phys = <0x15 0x01>;
			phy-names = "usb";
			status = "okay";
			phandle = <0x38>;
		};

		usb@5200400 {
			compatible = "allwinner,sun50i-h616-ohci\0generic-ohci";
			reg = <0x5200400 0x100>;
			interrupts = <0x00 0x1d 0x04>;
			clocks = <0x02 0x6b 0x02 0x64>;
			resets = <0x02 0x2b>;
			phys = <0x15 0x01>;
			phy-names = "usb";
			status = "okay";
			phandle = <0x39>;
		};

		usb@5310000 {
			compatible = "allwinner,sun50i-h616-ehci\0generic-ehci";
			reg = <0x5310000 0x100>;
			interrupts = <0x00 0x1e 0x04>;
			clocks = <0x02 0x6c 0x02 0x70 0x02 0x66>;
			resets = <0x02 0x2c 0x02 0x30>;
			phys = <0x15 0x02>;
			phy-names = "usb";
			status = "okay";
			phandle = <0x3a>;
		};

		usb@5310400 {
			compatible = "allwinner,sun50i-h616-ohci\0generic-ohci";
			reg = <0x5310400 0x100>;
			interrupts = <0x00 0x1f 0x04>;
			clocks = <0x02 0x6c 0x02 0x66>;
			resets = <0x02 0x2c>;
			phys = <0x15 0x02>;
			phy-names = "usb";
			status = "okay";
			phandle = <0x3b>;
		};

		usb@5311000 {
			compatible = "allwinner,sun50i-h616-ehci\0generic-ehci";
			reg = <0x5311000 0x100>;
			interrupts = <0x00 0x20 0x04>;
			clocks = <0x02 0x6d 0x02 0x71 0x02 0x68>;
			resets = <0x02 0x2d 0x02 0x31>;
			phys = <0x15 0x03>;
			phy-names = "usb";
			status = "okay";
			phandle = <0x3c>;
		};

		usb@5311400 {
			compatible = "allwinner,sun50i-h616-ohci\0generic-ohci";
			reg = <0x5311400 0x100>;
			interrupts = <0x00 0x21 0x04>;
			clocks = <0x02 0x6d 0x02 0x68>;
			resets = <0x02 0x2d>;
			phys = <0x15 0x03>;
			phy-names = "usb";
			status = "okay";
			phandle = <0x3d>;
		};

 

Anyway, I don't want to waste your time; you was very kind already, and I am new to this DTS stuff, most probably I'm missing something.

I will keep looking at your commits and will keep trying new nightly images.

This board looks nicer and nicer by the day. Quite fast, feature rich for the price and does not run hot, a welcome change vs. other SBCs. 

 

[jernej]

There is one more difference - usb@5101000 and usb@5101400 are missing

phys = <0x15 0x00>;
phy-names = "usb";

If that doesn't work, then I don't know.

 

I don't think anyone currently works on H616, so it probably won't change much in near future.

[XFer012]

Good catch. Added the phys references to usb@5101000 and usb@5101400, but unfortunately it does not work yet.

Host controllers show up in dmesg, but the USB port remains "dead": does not even power peripherals.

It will take a longer wait it seems, thanks anyway!

 

 

 

[hexdump]

@XFer012 - i think the best approach might be to build your own kernel and then you can change the original dts and dtsi files directly (with labels etc.) instead of dealing only with the compiled versions ... maybe my notes from playing around with the h616 on tv boxes might be helpful for you: https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel

 

i also built a kernel with working usb and early hdmi (based on the code of @jernej): https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/tag/5.11.0-rc1-stb-616%2B - i did not test it on a orange pi zero 2 myself (as i only tried it on a h616 tv box), but at least i tried to keep the opi zero 2 dtb up to date, so it might just work

 

all that is not a perfect solution, but maybe its helpful for you on your way

 

good luck and best wishes - hexdump

[XFer012]

Thank you! Will study how to cross-compile a kernel, outside the "standard" Armbian scripts.

I'm new to cross-compiling and also to kernel building for ARM boards (u-boot, DTB etc.), so it's going to be fun

[hexdump]

@XFer012 - you can also build a kernel directly on the box - takes a bit of time, but works well - i'm building all my arm kernels on arm devices

[XFer012]

You mean, on my lowly 512 MB OrangePiZero2? Aren't 512 MB too scarce to build a kernel? That's good to know!

I mean, back in the times I used to build 1.x on a 32 MB 80386, but Linux kernels were tiny in comparison

[hexdump]

@XFer012 - oh - if you have the 512mb version then it might get a bit short on memory maybe, 1gb should be fine ...

[gounthar]

But if it is already running Armbian, you could use a swap file with the memory optimizations... I did it on the Zero.

[XFer012]

2 hours ago, hexdump said:

@XFer012 - i think the best approach might be to build your own kernel and then you can change the original dts and dtsi files directly (with labels etc.) instead of dealing only with the compiled versions ... maybe my notes from playing around with the h616 on tv boxes might be helpful for you: https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel

 

I'm an Armbian newbie. As for now, following the guide at https://docs.armbian.com/Developer-Guide_Build-Preparation/ , I think I have a working build environment.

Where should I copy your kernel source, config etc. (from https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel) within the Armbian "build/"  folder?

It looks like:

-rwxrwxr-x  1  8569 Apr  5 15:07 compile.sh
drwxrwxr-x 13  4096 Apr  5 15:07 config
drwxrwxr-x  2  4096 Apr  5 15:07 lib
-rw-rw-r--  1 18026 Apr  5 15:07 LICENSE
drwxrwxr-x  3  4096 Apr  5 15:08 output
drwxrwxr-x  5  4096 Apr  5 15:07 packages
drwxrwxr-x  6  4096 Apr  5 15:07 patch
-rw-rw-r--  1 13703 Apr  5 15:07 README.md
drwxr-xr-x  2  4096 Apr  5 15:08 userpatches
-rw-rw-r--  1    14 Apr  5 15:07 VERSION

 

Thanks!!

 

[hexdump]

@XFer012 - those files are not intended to be used in the armbian build system, but when building a kernel standalone. they are basically just my notes on getting the kernel compiled and working and not intended to be just dropped into an armbian build.

[XFer012]

understood

[Henry Delphing]

On 4/5/2021 at 12:03 AM, jernej said:

Check ohci, ehci and usbphy nodes in my DT: https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts#L134 and https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi. You should make a patch which adds these changes to DT, add patch to build system and build image. You can probably get away with making DT overlay too.

Note that these are developer level instructions - I don't plan to write more detailed steps.

That looks like beyond my skill.   I think I'd better wait few more months for Armbian to update the images.

 

[XFer012]

@Henry Delphing

I'm trying to set up an "OrangePi kernel building" environment on one of my SBCs, a Rock64 2GB running Armbian stable.

It's a difficult task, because documentation is often obsolete, sparse and conflicting; plus, every pre-cooked build environment is quite rigid about what to build and from which source.

Anyway, my goal is to replicate Hexdump's kernel: clone jernej's sources, apply hexdump's patches, load hexdump's kernel config and build. Then sort out which of the various DTSs actually enables USB on the PiZero2.

If and when I'll reach my goal, I'll post a link to the working kernel here, I promise.

 

[hexdump]

@XFer012 - in case you run into any problems while trying get it working based on my notes, just open an issue on that git repo and i may try to help you to resolve them

 

good luck - hexdump

[XFer012]

@hexdump thanks for your support.

I'm reading through your "readme.616" now, and have a few doubts.

You write:

# make defconfig
# /compile/doc/stable-aw/misc.616/options/enable-docker-options.sh
# /compile/doc/stable-aw/misc.616/options/enable-additional-options.sh
make oldconfig

 

which is not very clear to me.

Apart from the "docker options", which are not interesting to me ATM, why did you comment out the other lines?

Why do you perform a "make oldconfig"?

 

Thanks!

[XFer012]

A summary of my (fruitless, at the moment) efforts:

 

Working on OrangePiZero2 512 MB, headless, so command line only: can't comment about GUI, graphic driver etc.

 

- Armbian Unstable boots, but:

CPU works at low clockspeed (I would say about 1.0-1.2 GHz but with something like "powersave" or anyway a conservative governor); overall is not very responsive, in particular it's very slow at building anything

There are lots of drivers loaded, so the available RAM is scarce (about 300 MB) and leads to swapping when compiling

Ethernet does not work at 1000 mbit/s, needs to be forced at 100: "ethtool -s eth0 speed 100 duplex full autoneg off"

USB does not work

 

Since @jernej and @hexdump succeded in building a working 5.11.0RC1 kernel with working USB, I tried to follow their steps and rebuild jernej's kernel with hexdump's patches and DTBs, but:

 

- Armbian build system is very "self-contained" and does not allow integrating a 3rd-party kernel and patches. Or at least, it looks like a long, painful and unsupported task

- I tried building the kernel on the OrangePiZero2 itself, but with the current, slow CPU clock is so painful ( > 3 hours for the kernel alone) it does now allow for whatever error, and:

 i) hexdump's kernel config seems unfit for the OrangePiZero2 (lots of drivers and options for devices the board does not have)

ii) "make modules" exits with an error about missing "irq_check_status_bit"

iii) after having tried to sort out the above, I end up with a kernel which does not boot because it does not "see" the microSD (initramfs drops to a shell and there are no /dev/mmcblk* devices)

 

Being quite headstrong, I'll try sorting out something by myself, but would gladly accept whatever help

 

Thanks for reading

 

[SinEt]

Thanks @Igor to refer me to this forum.

I experienced the same issues that you are talking here, but my knoledge is not enought to help in this situation. 
As I can see, this issue is comming from last year, and it is not easy to solve.

I will do my "tests" direcly with the image that is provided by Orange Pi, but I hope Armbian image will be successed soon.

 

 

Thanks for your effort!

 

@Igor I read all posts, and I hope you will have a new board to follow the tests  

[XFer012]

We know that 5.11.0RC1, patched by jernej and then by hexdump, had USB port working.

 

I tried using their DTS with Armbian current unstable image (kernel 5.11.11), but USB did not work.

So, I would guess, something occurred between 5.11.0RC1 and 5.11.11, which did break USB for the OrangePiZero2.

 

I tried building their 5.11.0RC1 on the OPI itself; but it did not boot (dropped to a shell within initramfs: no microSD visible to the kernel)

 

Now I am trying a few local builds of 5.11.0RC1 with different kernel configs. Not easy, because each build takes forever (as cpufreq drivers are not present and the CPU clock is quite low).

 

At a certain point, I'll have to surrender and wait for someone more knowledgeable to carry on the work on H616 mainlining.

It is a bit annoying, because we are so near! The board is almost useable with "unstable" Armbian.