XFer012
-
Posts
36 -
Joined
-
Last visited
Posts posted by XFer012
-
-
You may try with the latest Unstable kernel (based upon 5.11.x), but I don't think WiFi works even with that one.
-
On 4/30/2021 at 1:54 PM, lampra said:
If @hexdump could provide headers for his kernel, then we could have the edge image with his kernel and support for usb, reboot and onewire until proper support is enabled.
I think hexdump added some DTS patches to:
https://github.com/jernejsk/linux-1/tree/h616-hdmi
Me, I was unable to "integrate" that kernel into mainline. But I'm a newbie.
-
I think he was referring to Armbian, which does not reboot even with genuine Sandisk cards.
I seem to remember that at a certain point, amid various kernel reconfig/rebuilds, I had it rebooting properly by disabling "Enable suspend to disk" and disabling "Enable hibernate" in kernel Power Management section. But I'm not 100% sure.
-
Confirmed.
At some point, rebuilding the latest mainline kernel from the Unstable branch, I managed to have the board rebooting properly; but it was in the middle of many tests and never managed to succeed again.
-
Indeed.
For example, my Rock64 and my Neo3 are stable at 1.3 GHz with -25mV and -50mV respectively vs. default OPP values. Silicon lottery.
It's still strange that H6 DTS lacks a proper OPP. Maybe with Unstable kernel, based upon 5.11 mainline? Some patches for H6 were included in 5.11 and accompaining DTS.
-
-
Maybe my problem is a bit different then.
My Rock64 (with both Armbian Stable and Unstable) does not reboot after "sudo poweroff": it performs the shutdown sequence, but does not really "power off". It is halted, does not respond to login or ping, but the peripherals are still powered and the board still draws the typical idle current (about 220 mA); the heatsink stays warm too.
-
This sounds like good news!!
Maybe poor little H616 is going to get some love by mainline kernel? Fingers crossed!!
Arm updates in Linux 5.12
Removal of several obsolete 32-bit Arm platforms – efm32, picoxcell, prima2, tango, u300, zx, and c6x, as well as associated device drivers.
Allwinner
Allwinner H616 and H616-R – Initial support including pin controllers, clocks
Allwinner/sunxi power management
Various DTS changes
...
-
@firewire10000
Hi, I can confirm this behaviour, both with the Stable image (kernel 5.10.21) and with the latest Unstable from yesterday (kernel 5.11.15).
Unfortunately I don't know how to fix it.
I tried rebuliding the kernel from the latest "Edge", with CPU Power Management enabled, but nothing changed.
The Rock64 is not supported by Armbian, so if powerdown is important to you, I would advice sticking with Ayufan images.
-
Ok, so let's see the steps I followed.
1. Installed Armbian Unstable for OrangePi Zero2:
2. Forced ethernet at 100 mbit/s, otherwise it did not work: added in /etc/rc.local
ethtool -s eth0 speed 100 duplex full autoneg off
3. Downloaded hexdump's precompiled kernel (derived from jernej's 5.11.0rc1 kernel):
4. Extracted the various parts and fixed the symlinks:
Image -> Image-5.11.0-rc1-stb-616+
uInitrd -> uInitrd-5.11.0-rc1-stb-616+
dtb -> dtb-5.11.0-rc1-stb-616+
5. Inside dtb-5.11.0-rc1-stb-616+, created a new folder "allwinner" and moved the 3 .dtb there; otherwise, initramfs would not find them
6. Rebooted. Voilà, we now have a working mainline-ish kernel (patched 5.11.0rc1) with USB support!
[ 57.289791] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 57.454110] usb-storage 2-1:1.0: USB Mass Storage device detected [ 57.454976] scsi host0: usb-storage 2-1:1.0 [ 59.122397] scsi 0:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 6 [ 59.124408] sd 0:0:0:0: [sda] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB) [ 59.125522] sd 0:0:0:0: [sda] Write Protect is off [ 59.125549] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 59.126563] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 59.163290] sda: sda1 sda2 [ 59.168389] sd 0:0:0:0: [sda] Attached SCSI removable disk -
Partial success.
I was able to boot @hexdump 's precompiled kernel (using Armbian "unstable" image).
This kernel indeed has USB working!
I am not able to rebuild this kernel by myself, but at least we have a mainline-ish kernel with working USB!More details later, have to go now.
-
Not the same results.. maybe different revisions?
and my OrangePiZero2 never got past 61 degrees, and that's without an heatsink.
I added a tiny heatsink, and it stayed below 52 degrees even after repeating 7zr benchmarks
-
13 minutes ago, NicoD said:
@XFer012Do you need HDMI? Otherwise the RockPiS is way more power efficient. Runs at 0.1A idle
I have the RockPiS, too; quite nice, but very difficult to find here (Italy) and it's quite slower. Power efficiency is not much higher, by the way.
In absolute terms, using "7zr b" as benchmark, RockPi-S gives 2327, OrangePiZero2 3739 (1.6x)
Using "7zr b" MIPS / MHz as an IPC figure, the RockPi-S gives 1.78, while the OPIzero2 gives 2.54.
Using "7zr b" MIPS / W as an efficiency figure, RockPi-S gives 1450, OPIZero2 1246
Also, microSD speed is almost 2x on the OPI02.
A very nice board (at 20 Eur!), if only we could iron out USB support.
-
The board is very good. IMHO, one of the best out there! And I have so many SBCs... maybe 10 or more.
Let me summarize:
Small and cheap
Draws little power, thanks to the 28nm SOC
Does not run hot, at all, not even with the (quite bad) Orange kernel (which loads one core at 100% all the time), not even at 1.5 GHz
Has onboard audio
MicroSD is quite fast, among the fastest actually
I see it as the best SBC for battery-powered projects, or whenever heat dissipation is an issue
-
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.
-
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
-
@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 oldconfigwhich 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!
-
@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.
-
understood
-
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 VERSIONThanks!!
-
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
-
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
-
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!
-
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.
OrangePi Zero2 - Allwinner H616
in Board Bring Up
Posted
I would test it gladly.
Is it OK to install it on an Armbian Unstable? It's what I have now.
If you advice against it, no problem, will reinstall.