Jump to content

OrangePi Zero2 - Allwinner H616


Werner

Recommended Posts

Hello there!

I have small project where i want to put OrangePi Zero 2 in LE advertising mode (peripheral) and connect to it with NRF51822 (central) keychain.

Currently I have a problem with BlueZ, the stack not registering LEAdvertisingManager1
 in dbus because not recognizing BLE support by adapter. But adapter support BLE, you can check this with low level hci tools, example turn on LE advertising:

root@orangepizero2:~# hciconfig hci0 up
root@orangepizero2:~# hciconfig hci0 leadv 0

and device can found with any tool like NRF Connect.

First at all look to output of hciconfig commands/featureshttps://pastebin.com/0AYH0bJx

Commands prints big list of supported commands where you can see LE support, but features output looks wrong, i not sure.

So i decided to download source of BlueZ 5.62 and try to do debug, but found nothing...

When bluetoothd initializing, it send MGMT_OP_READ_INFO (0x0004) to adapter, when data arrived, callback read_info_complete (adapter.c:9689) called. There are present variables: rp->supported_settings and rp->current_settings (adapter.c:9693). In my scenario i have supported_settings = 0x10BF, current_settings = 0x90.  Further along the code, the presence of the LE flag (MGMT_SETTING_LE 0x00000200) is checked. Of course 0x200 bit in supported_settings not set, so support dropped. If you try to hardcode bit (adapter->supported_settings |= MGMT_SETTING_LE) LEAdvertisingManager1 appears in dbus, advertise appears in bluetoothctl, but BLE still not work properly:

[bluetooth]# advertise on
Failed to register advertisement: org.bluez.Error.NotPermitted
[bluetooth]# 

So, now i don't have any ideas yet. The reason is clearly not in BlueZ, perhaps some problem with the driver.

Any ideas?

 

Configure flags: ./configure --enable-debug --prefix=/usr --enable-experimental --enable-testing --enable-logger --enable-admin

Armbian 21.08.1 Bullseye with Linux 4.9.280-sun50iw9

Bluetoothd log: https://pastebin.com/9eQqkiE4

 

Sorry for my English.

Link to comment
Share on other sites

4 hours ago, Werner said:

Because there was no active development on this SoC/board in a while and probably won't be until either support is dropped on December 1st anyways or somebody steps up to maintain this board.

 

We got dedicated maintainer for this board (which doesn't even need to be a developer since he can't substitute team of developers) and there is some development going on. Even everyone on the project would focus just on this (any other new) boards, we can't fix troubles on the speed that has being asked, taken care on the bugs that bumps up and work to pay the bill users don't and live lives at the same time. If users wants to have those (fancy) features, they should pay for R&D perhaps? Since Orangepi vendor is among those that respects our work and cover some small portion of costs we have, we will do best possible for this board. But best possible has limits, which we can't go over. 

 

Dear @mantouboji and @apkx. Even Orange / Xunlong helps us with donations here and there, most of the bill you are creating to our private finances, remain unpaid: https://docs.armbian.com/User-Guide_FAQ/#development-time (please read entire FAQ and consider contributing - we plan to shrink things down dramatically since without your money, we can't hire people to work on your agenda, while project just grows)  I will (already moving into that mood) ignore people that doesn't have top subscription (i think we will anyway enforce this as mandatory for certain sections of this forum), but are here to asks questions which require thousands of our money to get the answer and further a lot more to get things working. We don't need that those features works. You do! Cover the costs or just hire someone that will do that for you. And make a PR, so we can include the code you paid development for yourself and others. Even those costs are also ours, they are at least manageable.

Link to comment
Share on other sites

2 hours ago, mantouboji said:

I will abandon all of my Zero2 and not to use them again.


Perhaps showing respect to people that waste their precious time for your hobby or business? For us expense and suffering (development is suffer in case you don't know) you totally ignore. Stop pushing. This is not directed to you personally - a lot of people on this forum are losing touch with reality they need to accknowledge.

 

I feel terrible for making such notes on forum, but without pushing you back, you (not you personally) would eat us alive. And you would not even notice. Just one day support would end, because people that works in your interest, are burned out. We gave you a notice one month in advance, that we will shrink it down so we can survive. And you will get even less what you have now. (in general, not related to this board)

 

Perhaps think how you can help and give back something? Help us and we will happily help you. Since you don't, how can you expect that we are happy about? Do we owe you something? Nope. Do you owe us something. Sure you do.

Link to comment
Share on other sites

11 hours ago, Igor said:


Perhaps showing respect to people that waste their precious time for your hobby or business? For us expense and suffering (development is suffer in case you don't know) you totally ignore. Stop pushing. This is not directed to you personally - a lot of people on this forum are losing touch with reality they need to accknowledge.

 

You are always welcome.

 

As a hobbyist, I only want use this board to run homeassistant and a WireGuard router, so when I found some bug, I think I should report it in here . Since supporting for this model is so difficult, it seems that switch to other board  is a better choice. 
 

Thanks a lot for you and all of developers here, I will keep using Armbian on other supported boards .
 

Grazie mille. Большое спасибо.

 

Link to comment
Share on other sites

On 10/30/2021 at 1:01 PM, Igor said:

 

We got dedicated maintainer for this board (which doesn't even need to be a developer since he can't substitute team of developers) and there is some development going on. Even everyone on the project would focus just on this (any other new) boards, we can't fix troubles on the speed that has being asked, taken care on the bugs that bumps up and work to pay the bill users don't and live lives at the same time. If users wants to have those (fancy) features, they should pay for R&D perhaps? Since Orangepi vendor is among those that respects our work and cover some small portion of costs we have, we will do best possible for this board. But best possible has limits, which we can't go over. 

 

Dear @mantouboji and @apkx. Even Orange / Xunlong helps us with donations here and there, most of the bill you are creating to our private finances, remain unpaid: https://docs.armbian.com/User-Guide_FAQ/#development-time (please read entire FAQ and consider contributing - we plan to shrink things down dramatically since without your money, we can't hire people to work on your agenda, while project just grows)  I will (already moving into that mood) ignore people that doesn't have top subscription (i think we will anyway enforce this as mandatory for certain sections of this forum), but are here to asks questions which require thousands of our money to get the answer and further a lot more to get things working. We don't need that those features works. You do! Cover the costs or just hire someone that will do that for you. And make a PR, so we can include the code you paid development for yourself and others. Even those costs are also ours, they are at least manageable.

 

That is very strange answer @Igor. I do not expect that someone to do my problem for me for free, i just looking for advice. Maybe someone was working on it or know something, that i don't know, so it can help me or show me the right way, so i can fix my problem. And when i fix my problem i contribute that fix to community for free. My projects just for me, they do not bring me money.

I like your project, but I cannot help it financially. But don't blame me of disrespecting the developers.

Link to comment
Share on other sites

15 minutes ago, apkx said:

But don't blame me of disrespecting the developers.


I certainly don't blame you / anyone specifically. General rant - I have no idea how to communicate dark sides in not disturbing way ? :(

 

16 minutes ago, apkx said:

My projects just for me, they do not bring me money.


Money could solve few things, but not all. Helping on project is far more valuable and that, anyone can. We need help to keep this expensive system up. Which also doesn't cover costs, but someone needs to pay for them. 

Link to comment
Share on other sites

Hey! I just found out about this amazing project because I was looking in to creating a OMV (with armbian as a base) server in my lan and I was considering a OrangePi Zero2 to do so. I read a couple of pages in this forums about the problems that it has and I don't think that they will affect me. Should I look somewhere else or right now it is usable?

Link to comment
Share on other sites

Hi Guys,

 

The orangepi zero2 is an amazing powerfull sbc, I'm glad everything works as expected for me on this board (docker, domoticz, deconz, pihole etc).

 

But, I have 1 strange entry (every second) in the syslog, it logs this usually about 10 to 60 times an hour.

kernel: [69795.396748] sdiohal:sdiohal_cp_sleep_wakeup entry

 

Does anyobody know what to do, I researched it but found 0 results, I do know it has something to do with my sd-card i/o ?

I'm running Armbian 21.08.3 Buster with Linux 4.9.280-sun50iw9

 

I noticed some u-boot failing to upgrade after a apt-get upgrade before it happened, probably a reinstall removes the error but i'm just curious how to handle this.

Edited by Jelmer
Link to comment
Share on other sites

This happens because the SDIO driver was built with some no-commented debug message. It's a pain that date back from initial build of linux for this CPU. You'll need rebuild the kernel and add a patch that's commenting the message if it bothers you too much.

 

@mantouboji Have you seen this: https://github.com/orangepi-xunlong/orangepi-build/blob/main/external/packages/bsp/sunxi/ap6256-wifi.service

It seems some firmware binary blob is required for Wifi to work. Hopefully, you can load them at runtime.

Edited by xryl669
Link to comment
Share on other sites

2 hours ago, xryl669 said:

This happens because the SDIO driver was built with some no-commented debug message. It's a pain that date back from initial build of linux for this CPU. You'll need rebuild the kernel and add a patch that's commenting the message if it bothers you too much.

 

@mantouboji Have you seen this: https://github.com/orangepi-xunlong/orangepi-build/blob/main/external/packages/bsp/sunxi/ap6256-wifi.service

It seems some firmware binary blob is required for Wifi to work. Hopefully, you can load them at runtime.

 

Thanks my dear, Are you kidding me ? there is no this modules in 5.14.x kernel. 

Link to comment
Share on other sites

FYI, if anyone is interested in advancing Armbian support for H616, I just fixed reboot issue on mainline kernel for OrangePi Zero2. In fact, I started collecting H616 patches in hope to create LibreELEC image. Patches can be found here: https://github.com/jernejsk/linux-1/commits/h616-full

 

Note: U-Boot needs this hack: https://github.com/jernejsk/u-boot/commit/d420184997f302f546bb0862b1774cca6b43fb9a Without it, Linux will hang at loading Panfrost driver.

Link to comment
Share on other sites

On 11/7/2021 at 7:05 AM, Igor said:

 

still no reboot, and USB is broken

 

11月 08 08:11:11 orangepizero2 kernel: usb 2-1: new full-speed USB device number 6 using ohci-platform
11月 08 08:11:12 orangepizero2 kernel: usb 2-1: device descriptor read/64, error -62
11月 08 08:11:12 orangepizero2 kernel: usb 2-1: device descriptor read/64, error -62
11月 08 08:11:12 orangepizero2 kernel: usb 2-1: new full-speed USB device number 7 using ohci-platform
11月 08 08:11:12 orangepizero2 kernel: usb 2-1: device descriptor read/64, error -62
11月 08 08:11:13 orangepizero2 kernel: usb 2-1: device descriptor read/64, error -62
11月 08 08:11:13 orangepizero2 kernel: usb usb2-port1: attempt power cycle
11月 08 08:11:13 orangepizero2 kernel: usb 2-1: new full-speed USB device number 8 using ohci-platform
11月 08 08:11:13 orangepizero2 kernel: usb 2-1: device not accepting address 8, error -62
11月 08 08:11:14 orangepizero2 kernel: usb 2-1: new full-speed USB device number 9 using ohci-platform
11月 08 08:11:14 orangepizero2 kernel: usb 2-1: device not accepting address 9, error -62
11月 08 08:11:14 orangepizero2 kernel: usb usb2-port1: unable to enumerate USB device

 

Link to comment
Share on other sites

14 minutes ago, lampra said:

Check the device tree. Only one change was needed https://github.com/jernejsk/linux-1/commit/acb0d7a34dd77ed84228478f5ffb3479a3118fed

I changed this in my board using armian-config

`Welcome to Armbian 21.08.2 Focal with bleeding edge Linux 5.14.8-sunxi64`

and reboot works

 

this patch was overlapped by h616_0005 one 

 

I build hirsute 

Link to comment
Share on other sites

On 11/5/2021 at 12:53 PM, jernej said:

FYI, if anyone is interested in advancing Armbian support for H616, I just fixed reboot issue on mainline kernel for OrangePi Zero2. In fact, I started collecting H616 patches in hope to create LibreELEC image. Patches can be found here: https://github.com/jernejsk/linux-1/commits/h616-full

 

Note: U-Boot needs this hack: https://github.com/jernejsk/u-boot/commit/d420184997f302f546bb0862b1774cca6b43fb9a Without it, Linux will hang at loading Panfrost driver.

Trying to use Panfrost on ili9488: I thought the GPU driver can be used to do fast blts and/or triangle draws to a framebuffer and then the SPI device drivers would just scan them out. Do you know if this is the case? AIGLX thinks my ili8488 screen is not DRI2 capable:

 

Quote

pi@orangepizero2:~$ cat /var/log/Xorg.0.log | egrep -i "panfrost|mali|midgard|gpu|dri|drm|software"
[    17.829] (==) Automatically adding GPU devices
[    17.829] (==) Automatically binding GPU devices
[    17.918]    X.Org Video Driver: 24.1
[    17.918]    X.Org XInput driver : 24.1
[    17.923] (II) xfree86: Adding drm device (/dev/dri/card0)
[    18.011] (**) OutputClass "Panfrost" setting /dev/dri/card0 as PrimaryGPU
[    18.303] (II) LoadModule: "dri2"
[    18.303] (II) Module "dri2" already built-in
[    18.303] (II) Applying OutputClass "Panfrost" to /dev/dri/card0
[    18.303]    loading driver: modesetting
[    18.303] (==) Matched modesetting as autoconfigured driver 0
[    18.303] (==) Matched fbdev as autoconfigured driver 1
[    18.304] (==) Assigned the driver to the xf86ConfigLayout
[    18.315] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    18.346]    Module class: X.Org Video Driver
[    18.346]    ABI class: X.Org Video Driver, version 24.1
[    18.346] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[    18.371]    Module class: X.Org Video Driver
[    18.371]    ABI class: X.Org Video Driver, version 24.1
[    18.371] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    18.371] (II) FBDEV: driver for framebuffer: fbdev
[    18.546] (II) modeset(0): using drv /dev/dri/card0
[    18.564]    ABI class: X.Org Video Driver, version 24.1
[    18.565] (II) Applying OutputClass "Panfrost" options to /dev/dri/card0
[    22.692] (WW) modeset(0): Option "PrimaryGPU" is not used
[    22.713] (II) Initializing extension DRI3
[    22.715] (II) AIGLX: Screen 0 is not DRI2 capable
[    22.748] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[    22.750] (II) Initializing extension XFree86-DRI
[    22.755] (II) Initializing extension DRI2
 

 

Link to comment
Share on other sites

1 hour ago, mantouboji said:

If I want to add a new device tree overlay (for instance, H616 W1-gpio or pps-gpio), how to do it and produce diff patch?


Use:

 

 ./compile.sh CREATE_PATCHES="yes"


change sources when asked and a patch will be created / updated. Once done, copy that patch to the patck/kernel/sunxi64-edge/ folder and pay attention to the patch executing order. Hint - if you need that patch is executed last, add higher number or simply xx in front of the patch filename.

 

For adding an overlay, check this patch: https://github.com/armbian/build/blob/master/patch/kernel/archive/sunxi-5.15/general-sunxi-overlays.patch

Link to comment
Share on other sites

On 11/8/2021 at 11:34 AM, yam1 said:

Trying to use Panfrost on ili9488: I thought the GPU driver can be used to do fast blts and/or triangle draws to a framebuffer and then the SPI device drivers would just scan them out. Do you know if this is the case? AIGLX thinks my ili8488 screen is not DRI2 capable:

 

 

May I ask how  to use panfrost on hdmi display? From what I see, panfrost driver seems supported now with the great work of our developers, but I can't get images on my display with current armbian builds(5.x kernel).

I tried orangepi-build to build linux 5.13 kernel, which boots but "modprobe panfrost" doesn't work. Checked the device tree, not gpu sections. Tried also armbian-build, but the config for orange pi zero 2 is still using 4.9 kernel, not including the panfrost driver. At first I thought of using armbian-build with xunlong's config(5.13 kernel), but then I realised it's not possible. Patches are different on both sides.

Since there are so many great works done by many great developers, I guess it's possible to use panfrost but I just dont know how.

 Thank everyone for advising.

Edited by izeroo
Link to comment
Share on other sites

I simply copied the sun50i-h6-w1-gpio.dts  to h616 one , and then modified the file , change h6 to h616 , and change pin to PC7 . and then fixed the general-sunxi-overlays.patch to include overlay subdir.

 

build well . but when I load the dtbo, error message is :

 

[   86.285837] Driver for 1-wire Dallas network protocol.
[   86.300790] sun50i-h616-pinctrl 300b000.pinctrl: pin PC7 already requested by onewire@0; cannot claim for 300b000.pinctrl:71
[   86.300836] sun50i-h616-pinctrl 300b000.pinctrl: pin-71 (300b000.pinctrl:71) status -22
[   86.300862] w1-gpio onewire@0: gpio_request (pin) failed
[   86.300875] w1-gpio: probe of onewire@0 failed with error -22

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines