Allwinner's H3, which Linux kernel?

[DiTBho]

Anyone is using the HC3 chip? OragnePI or NanoPI?

I need to develop my own kernel driver for a couple of USB-devices, and I need to recompile/patch the kernel.

I am a bit confused because there are too many forks, branches and repo around.

The Sunxi/Legacy Kernel, basically kernel v3.4
Which hasn't yet any official Allwinner's git repository ?!?
The Siarhei Siamashka's branch, the Yann Dirson's fork, The Boris Lovosevic's one.

Then you have "Mainline kernels", but again too many forks, branches, etc, and it seems the Ondřej Jirman's branch (basically kernel v4.19) is the most solid.

Any feedback?   

[Whales]

Purist: only bother with mainline, because everything else is a PITA (not always possible).
Practicalist: you have to port to every goddam fork that's popular if you want your stuff to be used on existing boards (not always possible).
Cheater: skip needing a custom USB driver and use a USB UART chip on your product instead (not always possible).

Every distro that supports an ARM board goes about sourcing the kernel differently.  Many Linux distros will ship with their kernel's header files (eg in /usr/src) so things like DKMS can work.  DKMS may or may not be useful for your goals (keep in mind that some SBC vendors provide a single distro snapshot with a single version of a kernel that never gets updated).

Side rant: Operating systems and kernels on ARM devices are a mess.  As buggy and annoying as x86 BIOSs and other standards like ACPI can be: they're still 1000x better than what we have in the SBC world (where some standards do exist, but they're not commonly utilised).  I can boot basically any version of x86 Windows or *nix on any x86 system, but I need unique specialist magic versions of Windows or *nix to run on any particular Arm board.  EDIT: I am very glad that ARM SoCs have been backwards compatible to older ARM ISAs however!  That's something.

[DiTBho]

skip needing a custom USB driver and use a USB UART chip on your product instead (not always possible).

That's the funny thing: i bought the H3 board specifically for a project where there is a custom USB device. It's a Cypress FX2 one, but the protocol is completely custom.

I also bought an old Atheros5 MIPS32r2 SoC, it comes with EHCI, and it's very very simple. The kernel is not mainline but rather only supported by OpenWRT, hence I installed it only to grab the patches, then I applied them to a Vanilla kernel, and compiled it manually.

Result? In 45 minus, everything works and I didn't have to look into several forks, repositories, whereas with bloody H3 SoC ... I have been struggling for two weeks, even because I destroyed the previous chip due to a kernel bad support for the CPU freq auto scaling, and had to buy a new one.

But again I am lost with the "proprietary" device tree file, and with too many forks, patch, and unclear comments.

I'd rather use the Atheros5 chip, but it's clocked at 180-200Mhz, it only provides one EHCI port (H3 has 3  ports) and it cannot address more than 128Mbyte of ram.

[DiTBho]

Currently, I am with the official linux-sunxi git repository, it's Kernel v3.4.104

[Whales]

That's the funny thing: i bought the H3 board specifically for a project where there is a custom USB device. It's a Cypress FX2 one, but the protocol is completely custom.

May I ask: what's your project?  The desire for Allwinner H3 (cheap) makes me assume it's something you plan to make a lot of; so I presume using SFF x86 computers is not an option.  Raspi's have much better support in the Linux ecosystem, could using them be an option?

My personal experiences: SBC hardware features and speed tend not to be as important as the SBC being well supported by the rest of the world.

Currently, I am with the official linux-sunxi git repository, it's Kernel v3.4.104

5 years or so old.  Keep in mind this often means sticking with period userspace too, this can be annoying depending on what software you or your clients use.

[DiTBho]

May I ask: what's your project?  The desire for Allwinner H3 (cheap) makes me assume it's something you plan to make a lot of

Nah, it's not a product for sale, I am using the H3 only because it's one of the smallest core available. The whole project will be probably shown on Youtube; don't expect a release date and don't expect anything serious, it's just something really really crazy and funny, but I can't spoiler more

I presume using SFF x86 computers is not an option.  Raspi's have much better support in the Linux ecosystem, could using them be an option?

RPI cards are too large compared to a Nano-Core card. In this project, the smaller it goes, the better. Also, I largely prefer uBoot. With the RPI, you can have it, but in a very complicated way.

5 years or so old.  Keep in mind this often means sticking with period userspace too, this can be annoying depending on what software you or your clients use.

Yup, this is the main annoyance. I am with the old v3.4 because I want to inspect the frequency-scaling code. I want to be sure it's working without damaging the core like it happened with the kernel v5.10 provided by DietPI. I cannot add a cooling fan on the top of the head-sink, and the new heat-sink itself is mechanically integrated with the enclosure I designed.

Solving the thermal problem is my priority now!

But I also need to figure out exactly * what * the v3.4 kernel doesn't support in a 2021 glibc or musl rootfs; once figured out, I can rebuild the rootfs accordingly, which is already in my plans anyway

[Whales]

Ooh, you're trying to minimise size.  I'm now imagining a little Allwinner H3 board strapped to an ICBM with a couple of USB cables going in through a gap. OpenICBM will soon be found in the staging directory, but it's marked as not yet ready for production due to some unresolved overheating problems. 

Good luck sir!  Porting the freq scaling code may or may not be easier than dealing with rebuilding older userspace (you'll probably have to patch the glibc itself).

Random distraction: there are some Rockchip boards in the same form-factor as tiny H3 boards.  Eg:

* https://www.friendlyarm.com/index.php?route=product/product&product_id=279
* https://www.cnx-software.com/2019/06/19/rock-pi-s-tiny-sbc-rockchip-rk3308-processor/
* EDIT: Mediatek too https://www.gl-inet.com/products/gl-mt300n-v2/ & matching  OpenWRT page (might be mainline?)

[DiTBho]

What is OpenICBM?

For which terms the Rockchip's rk3308 is better than Allwinner's H3:
For better kernel support?
For less thermal issues?
For better performances (I see, it's a Cortex A53, and the ram is DDR4)?

I can consider the NanoPi NEO3-LTS, but I have to unsolder all the connectors.

• FriendlyARM   NanoPi NEO/Core, Allwinner H3, Quad-cores Cortex-A7 @ @400Mhz..1.2GHz, 256MB..512MB  DDR3
• FriendlyARM   NanoPi NEO3-LTS, RockChip RK3328, Quad-core Cortex A53 @400Mhz..1.3GHz, 1GB..2GB DDR4, 1x USB3.0, 2x USB2.0,

[Whales]

What is OpenICBM?

It's a joke.  I'm trying to guess what you're up to.  ICBM = inter-continental ballistic missile.

I don't know if the boards I mention are better or not, I just mention them in case you get frustrated with the H3 and want some more options to contemplate.  Info in the SBC world is rather scattered, so I thought sharing them might help.

[DiTBho]

In the meanwhile, I have already arranged four testing boxes

• kernel-3.4.39-H3 (untouched, assumed stable, needs testing)
• kernel-4.14.52-H3 (PLL hacked, CPU clock forced to 500Mhz, SMP disabled)
• kernel-4.14.52-H3 (PLL hacked, CPU clock forced to 500Mhz, SMP enabled)
• kernel-5.13.0-H3 (untouched, just cloned from the DietPI's repository)

The rootfs is an uclibc stage loaded with an heavy benchmark program to stress the CPU and check the temperature. I will test the first three during this week.

[DiTBho]

As usual .... DietPC and these distos, are all a mess of broken things

Code: [Select]

=> env save
Saving Environment to FAT... Card did not respond to voltage select!
Failed (1)

U-boot, as installed by DietPC

[bingo600]

I have been using "Armbian" on my OrangePi's
But haven't made any kernel mods yet.

/Bingo

[DiTBho]

k4.* doesn't properly work, too many repositories, all messed up.
I give-up with kernel v4.*

Good news, K5.1* start to move. I am with 5.12.0
- 1core/SMP: works!
- 3 serial lines: work
- 3 usb lines: work
- usb otg: disabled
- clock fixed to 500Mhz
- no overheating

I will spend the next week fixing u-boot.

[Whales]

- no overheating

Hooray   Glad you're getting it to work.  Publish your stuff if you can.

I presume you're fixing the clock so you can fix the vreg setting to something low and not worry about anything more complicated?

[DiTBho]

I presume you're fixing the clock so you can fix the vreg setting to something low and not worry about anything more complicated?

Yup, precisely.