Before complaining about an issue read this!

 

tl;dr: Put your Zero2 and/or any other H616 based device on the shelf and WAIT for proper support to come. And no. There is no ETA. Assuming usable state end 2021/beginning 2022.

 

Software support is still work in progress and under heavy development. Provided preview images can break any time. Do not report this, we are aware of that and can/will not help you with that if you are not willing to investigate and research by yourself.

Feel free to join fellow developers to their efforts to create proper software support. But don't waste our time with complains. Thank you!

 

https://github.com/apritzel/linux/commits/h616-v5

https://github.com/jernejsk/u-boot/tree/h616-v2

https://github.com/apritzel/arm-trusted-firmware/tree/h616-v2-wip

 

 

-----------------------------------------------------------------------------

 

I started to play with this board and obviously failed miserably creating a basic Armbian integration.

 

Anyway. These are the information I collected so far:

 

dtb extraction from Xulong image: https://pastebin.com/raw/Uni2JzBF

 

orangepimonitor 🙄  http://ix.io/2FM0

 

 

root@orangepizero2:/etc/apt# lsmod
Module                  Size  Used by
zram                   36864  2
sprdwl_ng             438272  0
sprdbt_tty             36864  2
uwe5622_bsp_sdio      294912  2 sprdbt_tty,sprdwl_ng

 

kernel config: https://pastebin.com/raw/e2jTTZ7A

Also interesting to see. This board, or better to say their image suffering from a similar issue like the first H6 images: constant load on one core for no reason. loadavg is ALWAYS 1 or higher...

At least they could reduce it. On H6 3 of 4 cores had always 100% load

 

Also shutdown leads into reboot.

Some first work on U-Boot: https://github.com/jernejsk/u-boot/commits/h616-v1

2 hours ago, Werner said:

Some first work on U-Boot: https://github.com/jernejsk/u-boot/commits/h616-v1

I just updated that branch, now it can boot normally from SD card.

 

You'll also need TF-A and Linux to make it usable:

https://github.com/apritzel/arm-trusted-firmware/commits/h616-WIP

https://github.com/apritzel/linux/commits/h616-WIP

 

UART, ethernet and SD card already work, so it already works good enough for headless server...

Thanks. Hopefully somebody like @martinayotte has a chance to play with the collected information and create some basic Armbian support with it

1 hour ago, Werner said:

Hopefully somebody like @martinayotte has a chance to play with the collected information and create some basic Armbian support with it

I will try my best, but "time is the missing ingredient" as usual ...

(I'm currently chasing why SPI0 doesn't work properly on OPiOne+ while it was with few earlier kernel versions)

On 11/29/2020 at 4:28 PM, jernej said:

UART, ethernet and SD card already work, so it already works good enough for headless server...

 

I am playing around and ... are there any general changes that I am missing-> U-boot file not found [ u-boot.itb ]

2 hours ago, Igor said:

are there any general changes that I am missing-> U-boot file not found [ u-boot.itb ]

At the end of U-Boot build process you should get u-boot-sunxi-with-spl.bin - this is now unified for 32 and 64 bit SoCs for some time now. It is possible that names of intermediary files changed since script for generating single binary was moved from shell script to python one recently.

2 hours ago, jernej said:

At the end of U-Boot build process you should get u-boot-sunxi-with-spl.bin - this is now unified for 32 and 64 bit SoCs for some time now. It is possible that names of intermediary files changed since script for generating single binary was moved from shell script to python one recently.

It puzzles me since we have different variants for 32 and 64 bit. So you are saying its safe to migrate to u-boot-sunxi-with-spl.bin
https://github.com/armbian/build/blob/master/config/sources/families/include/sunxi64_common.inc#L44-L48

 

OK.

Manage to boot but can't login via serial login ... huh. Will try once again tomorrow. https://github.com/armbian/build/pull/2418

8 hours ago, Igor said:

It puzzles me since we have different variants for 32 and 64 bit. So you are saying its safe to migrate to u-boot-sunxi-with-spl.bin

Certainly. I'm using unified approach for quiet a while on LE.

7 hours ago, Igor said:

Manage to boot but can't login via serial login ... huh.

Strange. I use Arch 32-bit userspace without any big issue.

Maybe it is a good idea to build on top of sunxi-dev instead of current since dev is 5.10 and will be next LTS kernel. Isn't the work of apritzel based on 5.10?

 

There you go

 

• cpufreq does not work yet.

root@orangepizero2:~# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 1:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 2:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 3:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.

 

• Leds are inverted

/sys/devices/platform/leds/leds/orangepi:green:status/trigger actually toggles the red led and vice versa

 

• network works: http://ix.io/2GH3

 

 

Works now. Building beta images ... https://www.armbian.com/orange-pi-zero-2/

• Reboot does not work. Leads into shutdown/freeze
• HDMI does not work. No output whatsoever
• USB does not work
• ran into random power down

  orangepizero2 login: [   17.491648] sysrq: Power Off
  [   17.502363] reboot: Power down

   

• Other weird stuff

  [   33.768377] usb1-vbus: disabling
  [   33.768404] vcc3v3-ext: disabling
  [   33.768749] vcc3v3-ext2: disabling
  [   33.769067] cldo1: disabling

   

27 minutes ago, Werner said:

• HDMI does not work. No output whatsoever
• USB does not work

That's expected, only things that I explicitly stated work - so SD card, network and serial console. Maybe also SPI and I2C, but I don't test buses unless some device is connected to it.

 

29 minutes ago, Werner said:

Reboot does not work. Leads into shutdown/freeze

Strange. It works for me. Make sure you have DT node which reserves memory for firmware. Without it, ATF will be overwritten and reset won't work. Other than that, I don't know.

 

34 minutes ago, Werner said:

[ 33.768377] usb1-vbus: disabling [ 33.768404] vcc3v3-ext: disabling [ 33.768749] vcc3v3-ext2: disabling [ 33.769067] cldo1: disabling

Why would be that strange? AFAIK kernel disables unused voltage regulators.

2 minutes ago, jernej said:

Why would be that strange? AFAIK kernel disables unused voltage regulators.

I don't know. Maybe I just did not pay close attention to that on any other board yet . If this is expected behavior never mind.

4 minutes ago, jernej said:

It works for me.

Probably our implementation breaks something. https://github.com/armbian/build/pull/2418/files

I don't see anything out of the ordinary, but note that there are newer Linux patches: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=394711

 

However, they shouldn't change anything AFAIK.

https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201204071107.25206-1-huangshuosheng@allwinnertech.com/

https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201204070901.24592-1-huangshuosheng@allwinnertech.com/

 

This might help fix cpufreq I assume

10 minutes ago, Werner said:

This might help fix cpufreq I assume

Those patches are for A100, not H616.

 

The biggest issue for cpufreq is making opp table - you have to make sure that each point is stable. BSP one is good starting point, but testing is not fun. On top of that, it's very good to have thermal driver working, to prevent burning hot SoC... I don't plan working on OPP...

17 hours ago, jernej said:

Those patches are for A100, not H616.

Oops, my bad.

 

Will try the new patch series.

Reworked to the new patch series. Boots. Does neither fix nor break anything so far.

I tried to migrate to the recent patchset published here https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=400181

but wont do a clean boot for me. https://paste.debian.net/1176460/

For the moment I assume two issues:

1. Something wrong with axp20 when applied against megi's orangepi-5.10 sources and
2. mmc broke with the switch from the very first patchset to the 2nd (the linked above is the 3rd AFAIK)

 

The 1st I could nail down by disabling by disabling Andre's [v2,10/21] mfd: axp20x: Allow AXP chips without interrupt lines patch (which is not necessary a smart idea but at least I does not throw an Oops at boot).

The 2nd however I could not figure out yet. I still get dropped into a shell and mmc is not present in /dev.

 

https://github.com/armbian/build/commit/2445b310692c44a129926fd24ec0f0b63c466342

@Werner - it might be better (at least in the beginning) to use a plain mainline as a base as i guess this is what the authors of the patches use when creating them ... mixing it with another tree with lots of own patches in them might make it harder to debug problems

Yeah you are right, the patches are applied and built against mainline is just fine. However it would be nice to see them work against megi's sources too at some point. That is why I mention it here so maybe somebody has some clue why

 

Hi!
I'm trying to boot from booster and focal images provided here (Jan 6 2021) but I my Orange Pi Zero2 it's not booting with this images. The red light on the board never turns on and the LAN are blinking in a wired way when trying this images.

I can perfectly boot from booster, focal and Android images provides in the Orange Pi site (but I don't like theirs configuration), so it's not a an SD issue. I just making my images with dd as always.

I have tried with a new SD, but it's the same... OrangiPi build are working, armbian are not.

 

Are you guys still working in this new images?

Is it necessary any additional step after burning with dd?

 

Thanks a lot!

dd

Support claims for images written with dd or any other tool that lack verification are rejected.

https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card

 

Seems like jernejsk made some changes to his U-Boot branch which could be the reason: https://github.com/jernejsk/u-boot/tree/h616-v1

46 minutes ago, Andyvec said:

armbian are not.

 

We are developing support for this board from scratch, based on modern kernel. There are just a little work here and there, by different people, some things are the same as on older, some not. It costs a lot of time at this stage. Perhaps we should provide images with stock closed loader and private kernel? That works at least the same as stock and now certainly works better then mainline based images ... but its a dead end support path. I tried to boot that kernel with modern u-boot ... which would be some good mid path, but I already lost two afternoons on that and got nowhere. Which could be used better. Perhaps spending with family

 

Our images are not done, which is why we label them WIP. They work or not. If they don't, we can't afford to left our jobs and/or spent afternoons to make them work. Which we usually do, when support is matured and we often (due too lots of investment into knowing how things works) knows why things bread down. And repair broken images.

2 hours ago, Werner said:

Seems like jernejsk made some changes to his U-Boot branch

Yeah, I forgot to add A100 compatible to mmc driver, that's why it doesn't boot.

14 minutes ago, jernej said:

Yeah, I forgot to add A100 compatible to mmc driver, that's why it doesn't boot.

Ah. Thanks for letting us know

Here is fixed v2 version: https://github.com/jernejsk/u-boot/commits/h616-v2

 

Note - it's not finished yet, so it will still change (force pushes).