Orange Pi Zero 3

[pixdrift]

On 12/20/2023 at 11:36 PM, Benedito Portela said:

@pixdrift could indicate a armbian build compile  for pi zero 3? 

Thank you.

The 'most complete' testing build at time of writing is this version, USE AT YOUR OWN RISK!
https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.7.tar.xz

There are elements that we know aren't working (Bluetooth, CPU Frequency scaling) and items that are currently untested (audio output via HDMI and the expansion board).

I understand you are looking for a working image, but the Zero3 Armbian image is still in early development and depends heavily on people testing and providing feedback with identified issues. If you do run this image, please provide feedback on specific items you have tested and let us know. It is too early in the development at this stage to provide any advice or assistance for third party user space programs/applications that may produce errors or not work.

Edited February 2 by pixdrift

[pixdrift]

Another day another update

I merged in the Bluetooth fixes from @Gunjan Gupta's pull request to Armbian main branch into my zero3 fork, this includes moving to the extension pattern for the wifi driver.

I did a quick build and tested Bluetooth (pairing to a BT speaker) and the pairing worked, but I didn't test past this. If you have some tests you can do with Bluetooth, I would appreciate the feedback (USE AT YOUR OWN RISK etc.)
https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.7.bt.fixed.tar.xz

I have looked at the CPU Frequency patch @Gunjan Gupta mentioned and I will look at modifying this patch to write to the shared .dtsi as suggested so both zero2 and zero3 benefit, I think that is a great suggestion.. this update doesn't include any CPU Frequency fixes yet unfortunately.
 

Thanks to everyone here that is providing feedback from their testing!
 

The github repo isn't updated with the BT fixes yet, I will try and get to this tonight so everyone can build updated images.

 

-edit-

 

GitHub fork for zero3 is now up to date with BT fixes
https://github.com/pixdrift/armbian_build/tree/zero3

Edited February 2 by pixdrift

[Gunjan Gupta]

@pixdrift could you please test the kernel from the following link on Orange Pi Zero 2 - https://drive.google.com/drive/folders/1cjCyISx3r7bVlXEPapf_5BbONQMyTcHX?usp=drive_link 

 

This kernel has all of the sun4i-drm patches enabled. See if HDMI works

[Gunjan Gupta]

@pixdriftTry hdmi on orange pi zero 2 for both 6.1 and 6.6 kernel from my branch - https://github.com/viraniac/armbian_build/tree/h616-hdmi 

 

If this works, I will then move all the orangepizero2 patches to orangepizero.dtsi. I want to get this out of the way before I bump the edge kernel to 6.7

[isy]

This is  so exciting. I know it has just been a week since @pixdrift forked and worked on the zero3. But this looks like this is heavily being worked on.
 

I was about to pass on purchasing the 4GB Orange Pi Zero 3 to settle for an older 1GB Zero 2. My (personal) project of stacking 3 units of Opi Zero3 is not starting until mid next year and will only do docker and use Gbe on it.

I am fairly new to Armbian ~2 years running (coming from FreeBSD community for ~15 years) -- would it safe to say that this effort is a strong indicator that we're getting  Opi Zero 3 (official) build at some point... next year? 😀
 

[Stephen Graf]

@pixdriftI tested with your image and bluetooth worked. I was able to pair with my cellphone.

 

I have been getting the following error on all my builds and also from your recent image. This happens for about 5 different pins. Are you getting it also and on zero2?

From dmesg:

[    1.644799] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation.
[    1.652819] sun50i-h616-pinctrl 300b000.pinctrl: initialized sunXi PIO driver
[    1.653318] gpio gpiochip1: Static allocation of GPIO base is deprecated, use dynamic allocation.
[    1.653525] sun50i-h616-r-pinctrl 7022000.pinctrl: initialized sunXi PIO driver
[    1.653722] sun50i-h616-pinctrl 300b000.pinctrl: request() failed for pin 224
[    1.653731] sun50i-h616-pinctrl 300b000.pinctrl: pin-224 (5000000.serial) status -517
[    1.653740] sun50i-h616-pinctrl 300b000.pinctrl: could not request pin 224 (PH0) from group PH0  on device 300b000.pinctrl
[    1.653750] dw-apb-uart 5000000.serial: Error applying setting, reverse things back

 

Also from dmesg:
[    1.654472] debugfs: Directory '1100000.mixer' with parent 'regmap' already present!
[    1.654499] debugfs: Directory '1100000.mixer' with parent 'regmap' already present!

[pixdrift]

On 12/22/2023 at 1:03 AM, Gunjan Gupta said:

@pixdriftTry hdmi on orange pi zero 2 for both 6.1 and 6.6 kernel from my branch - https://github.com/viraniac/armbian_build/tree/h616-hdmi 

 

If this works, I will then move all the orangepizero2 patches to orangepizero.dtsi. I want to get this out of the way before I bump the edge kernel to 6.7

Sorry @Gunjan Gupta not having much luck with these images unfortunately.

I did a quick test of both kernel versions on a Zero2, and neither had HDMI output, although interestingly after the kernel boots it appears to send an HDMI signal (monitor detects it) but doesn't have any output. I tested both kernel versions using Bookworm as the OS.

I noticed in your branch, you haven't enabled console output 'both' or marked display as 'yes', so I rebuilt after updating the configuration and unfortunately I still didn't get anything displaying on HDMI out.
https://github.com/viraniac/armbian_build/blob/h616-hdmi/config/boards/orangepizero2.conf#L7-L8

I did test CPU Freq though and that appears to be working correctly. Here is some debugging output from the 6.1 Bookworm build.
 

root@orangepizero2:~# uname -a
Linux orangepizero2 6.1.69-current-sunxi64 #1 SMP Wed Dec 20 16:00:29 UTC 2023 aarch64 GNU/Linux

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:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 244 us.
  hardware limits: 480 MHz - 1.51 GHz
  available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 480 MHz and 1.51 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.51 GHz (asserted by call to hardware).
  cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31%  (333)
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 244 us.
  hardware limits: 480 MHz - 1.51 GHz
  available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 480 MHz and 1.51 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.51 GHz (asserted by call to hardware).
  cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31%  (333)
analyzing CPU 2:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 244 us.
  hardware limits: 480 MHz - 1.51 GHz
  available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 480 MHz and 1.51 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.51 GHz (asserted by call to hardware).
  cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31%  (333)
analyzing CPU 3:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 244 us.
  hardware limits: 480 MHz - 1.51 GHz
  available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 480 MHz and 1.51 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.51 GHz (asserted by call to hardware).
  cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31%  (333)

root@orangepizero2:~# lsmod
Module                  Size  Used by
algif_hash             16384  1
algif_skcipher         16384  1
af_alg                 24576  6 algif_hash,algif_skcipher
bnep                   28672  2
hci_uart              135168  1
btqca                  24576  1 hci_uart
btrtl                  28672  1 hci_uart
btbcm                  20480  1 hci_uart
btintel                40960  1 hci_uart
bluetooth             724992  29 btrtl,btqca,btintel,hci_uart,btbcm,bnep
ecdh_generic           16384  2 bluetooth
ecc                    32768  1 ecdh_generic
sprdwl_ng             352256  0
sunxi_addr             20480  1 sprdwl_ng
cfg80211              376832  1 sprdwl_ng
sunrpc                290816  1
snd_soc_hdmi_codec     24576  0
lz4hc                  16384  0
lz4                    16384  0
polyval_ce             16384  0
sunxi_cedrus           45056  0
polyval_generic        16384  1 polyval_ce
v4l2_mem2mem           36864  1 sunxi_cedrus
videobuf2_dma_contig    24576  1 sunxi_cedrus
videobuf2_memops       20480  1 videobuf2_dma_contig
dw_hdmi_cec            16384  0
dw_hdmi_i2s_audio      16384  0
videobuf2_v4l2         24576  2 sunxi_cedrus,v4l2_mem2mem
videobuf2_common       49152  5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops
videodev              204800  4 sunxi_cedrus,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem
panfrost               69632  0
mc                     53248  5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem
gpu_sched              28672  1 panfrost
dump_reg               24576  0
apple_mfi_fastcharge    20480  0
drm_shmem_helper       20480  1 panfrost
display_connector      20480  0
cpufreq_dt             20480  0
zram                   28672  3
binfmt_misc            24576  1
sprdbt_tty             36864  2
uwe5622_bsp_sdio      208896  2 sprdbt_tty,sprdwl_ng
rfkill                 36864  7 sprdbt_tty,bluetooth,cfg80211
fuse                  126976  1
dm_mod                131072  0
hid_apple              28672  0
realtek                32768  1
dwmac_sun8i            28672  0
mdio_mux               16384  1 dwmac_sun8i

root@orangepizero2:~# dmesg | grep -i hdmi
[    1.444604] sun8i-dw-hdmi 6000000.hdmi: Detected HDMI TX controller v2.12a with HDCP (DWC HDMI 2.0 TX PHY)
[    1.445267] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver
[    1.445657] sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff800008ea4d48)
[   96.336072] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin
[   96.336102] sun8i-dw-hdmi 6000000.hdmi: read_hpd result: 1
[  103.529860] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin
[  189.979691] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin

It seems very close, just not displaying anything. I will do some more testing and let you know if I get something to work.

If anyone else has a Zero2 and wants to validate my testing, I have posted the images built from @Gunjan Gupta's HDMI testing branch here
https://armdev.pixeldrift.net/orangepi/zero2/viraniac/

Edited February 2 by pixdrift

[Gunjan Gupta]

18 minutes ago, pixdrift said:

dmesg | grep -i hdmi

Could you share the output of 

dmesg | grep sun4i-drm

It would be best if you can share complete dmesg output

[Werner]

6 hours ago, Ivan Sy said:

(official)

CSC support can be added anytime if someone steps up to send PR with everything necessary.

Standard support has different criteria:https://docs.armbian.com/User-Guide_Board-Support-Rules/

[pixdrift]

6 hours ago, Ivan Sy said:

I am fairly new to Armbian ~2 years running (coming from FreeBSD community for ~15 years) -- would it safe to say that this effort is a strong indicator that we're getting  Opi Zero 3 (official) build at some point... next year? 😀

Hi @Ivan Sy thanks for your interest in our Zero3 work and welcome to the forum!

I won't speculate on timelines for official support, but a PR with everything necessary (that @Werner alludes to) shouldn't be far off and we have most of the pieces working to different degrees which is what you will see in some of the testing and discussion in this thread.

The biggest challenge with merging to mainline is really getting the HDMI patch working for the zero2 as the zero2 and zero3 share a lot of similarities in their SoC. @Gunjan Gupta has done some incredible work to wrangle patches for the Zero2 to get everything working, and that is why you will see some Zero2 discussion here which may seem out of place.

Unfortunately the most recent Zero2 test for HDMI still has some challenges, and I have given as much feedback as possible to @Gunjan Gupta but unfortunately @Gunjan Gupta doesn't have a physical Zero2 to test on (yet). Once this patch is merged into the mainline Armbian, I think there will be some effort to move the remaining pieces that are common for both Zero2/Zero3 into a consolidated .dtsi file so both boards can benefit, then it will only take a small amount of effort to add Zero3 configuration (because it's almost identical).

The Zero3 fork I am maintaining, and posting here doesn't take into consideration anything other than the Edge branch and making the Zero3 work, where @Gunjan Gupta has put incredible effort into the Zero2 specifically and I have been porting/testing those changes on Zero3 as we go.

I think the Zero3 is a great board and I am confident that if we maintain momentum with the people who are contributing feedback and assistance from the community here, combined with the amazing patching work form upstream.. we will be able to put together a PR of the quality the project will approve of

Also, if you do buy a Zero2 or Zero3 board, please hang around and help us test  and to anyone else browsing this thread that has a Zero2/Zero3 board, create an account and say hi

[pixdrift]

12 hours ago, Stephen Graf said:

@pixdriftI tested with your image and bluetooth worked. I was able to pair with my cellphone.

 

I have been getting the following error on all my builds and also from your recent image. This happens for about 5 different pins. Are you getting it also and on zero2?

Sorry @Stephen Graf I didn't miss your message.

Good news about the cellphone pairing.. not so good news about the gpio messages in dmesg. I don't recall seeing that on the zero2 but I could have a closer look. No doubt something with the gpio configuration that needs investigation. I am currently trying to get CPU Frequency scaling fixed on the zero3, but I will add these error messages (and checking if zero2 is the same) to my list.

@Gunjan Gupta regarding the CPU Frequency scaling on the zero3.. I modified the arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling patch as discussed to add the sun50i-h616-cpu-opp.dtsi include to the shared zero dtsi, that all worked well. The &cpu configuration had to be in the separate zero2 and zero3 .dts files because the regulator for vdd-cpu differs for each (zero2 is dcdca, zero3 is dcdc2). All that worked fine and compiled fine, but still not getting any results from the cpufreq-info command.

Upon closer inspection of the patch, I suspect I may need to add references for the h618 SoC to this patch:
https://github.com/pixdrift/armbian_build/blob/c519c355d83f2588c1b0442420f6cdf184b4bc40/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling-v1_6_2.patch#L127-L130

and several other references in the file will need the h618 configuration added to the check.

Would you be able to run your eye over this and see if this looks like I am on the right track? If so I will try to put together a patch to resolve it (if a working version doesn't exist elsewhere).

[fizban]

First of all, I would like to congratulate and thank you all for the effort put in this initiative. Besides @Gunjan Gupta , special thanks to @pixdrift for making available a test image that we can play with, thus hiding the complexity of compiling the image ourselves.

 

Having said that, and with the intention of giving some testing feedback as you requested, here are some comments. I own a 4GB orange pi Zero 3 with extension board. I started playing with the first image a bit until you uploaded the second image, with which I played a little bit more.

 

With any of both images I did not seem to have good hdmi output initially. By "good" I mean that my monitor detected "something" but I suspect it was not able to synchronize properly. Unplugging the cable and plugging it again seemed to force some recognition and I was able to see the login prompt, but with a lot of flicker and unstability. I remember having similar problems when I played with the miniarch image.  With your second image I believe it was worst and I was not able to see anything. So I logged in using the serial connection (see attachment for the boot log over serial).  I followed the initial configuration steps and then here the two images seemed to behave differently. While I think the first image started the desktop environment after that, I had to run armbian-config with the second image to activate it.  In the first image, once the desktop environment started, I got a good signal through HDMI, albeit in 600x800. I was able to change the resolution but after rebooting I lost the signal again. Getting into armbian-config, deactivating the desktop and activating it again seemed to fix the issue, probably because it activated also the autologin functionality. No browser seemed to be installed, so I installed chromium and I checked the playability of some videos in youtube and they were quite unplayable (not that I expected much, anyway).

 

With the second image, as I said, I had to go to armbian-config to activate the desktop. I selected xfce and it took a while to download and install the packages. After rebooting, nothing was displayed on the monitor. Again I tried the trick of disabling and enabling the desktop to activate the autologin and I was able to have a nice desktop on my monitor, although I had to wait maybe more than one minute until something was shown, and by default I had more than 10 display configuration windows already opened that I had to close (I know, really weird).

The usb ports on the expansion board worked nicely and the wifi was also working fine. I was not able to activate bluetooth, though. Maybe I was missing something there.

Anyway, I saw that firefox was installed and tried to run it, but it stayed on the task bar without being able to get maximized or anything. So I installed chromium and it behaved much better. It was much snappier than with the previous image. So I checked youtube and to my surprise the videos seemed to be quite playable. I installed then vlc, had to configure it in preferences-video to use xvideo output (xbc) and tested some 1080p sample videos at https://oliverx.link/samples/ . Two samples showed very few lost frames, while using a reasonable amount of CPU, which make me believe they were HW decoded: V206 AVI – MPEG-4 24fps – MP3 and V207 TS – AVC 24fps – AAC 

 

So far so good. And I'd say this looks very promising.

 

Thank you again for the effort put in this.

 

 

armbian serial log.txt

[Gunjan Gupta]

13 hours ago, Stephen Graf said:

[    1.653731] sun50i-h616-pinctrl 300b000.pinctrl: pin-224 (5000000.serial) status -517

That message is pretty early in boot. Also 517 is EPROBE_DEFER which means pin is not available right now and driver will retry to grab it later. Its feel its ok to have that message unless it breaking some functionality. 

 

43 minutes ago, pixdrift said:

The &cpu configuration had to be in the separate zero2 and zero3 .dts files because the regulator for vdd-cpu differs for each (zero2 is dcdca, zero3 is dcdc2)

That sounds correct

 

43 minutes ago, pixdrift said:

Upon closer inspection of the patch, I suspect I may need to add references for the h618 SoC to this patch:
https://github.com/pixdrift/armbian_build/blob/c519c355d83f2588c1b0442420f6cdf184b4bc40/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling-v1_6_2.patch#L127-L130

That not needed. Are your changes in your git branch? May be I can take a look

[Gunjan Gupta]

Looks like there might be another H618 board in the pipeline named orange pi r1b - https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/boards/orangepir1b.conf

[fizban]

Jus one more piece of news. After rebooting the device (I believe I had to reboot it twice), bluetooth started and I was able to pair it with a loudspeaker, working beautifully.  On top of that, I was then able to set VLC to use OpenGL for embedded systems (which did not work before) and, with this configuration, some videos even played with 0 lost frames.

I also connected a 4G modem that supported the rndis driver through the USB and it was recognised without problem. I then installed SQM and cake-autorate to keep the latency in control and so far so good. It seems to be working quite stable. This little device seems to be quite promising, with several nice features at an unbeatable price...

[pixdrift]

8 hours ago, Gunjan Gupta said:

9 hours ago, pixdrift said:

Upon closer inspection of the patch, I suspect I may need to add references for the h618 SoC to this patch:
https://github.com/pixdrift/armbian_build/blob/c519c355d83f2588c1b0442420f6cdf184b4bc40/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling-v1_6_2.patch#L127-L130

That not needed. Are your changes in your git branch? May be I can take a look

I will get the CPU Frequency changes up into a branch in my repo tonight, realise that would have made troubleshooting a fair bit easier.. it was getting late here.. thanks for taking a look, and I will post when I get a minute

[pixdrift]

4 hours ago, Gunjan Gupta said:

Looks like there might be another H618 board in the pipeline named orange pi r1b - https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/boards/orangepir1b.conf

Great find, an Orange Pi with a H618 would be a great addition to their lineup :).. I will keep an eye on AliExpress to make sure we have one to test as soon as it's released! 

[pixdrift]

8 hours ago, fizban said:

Having said that, and with the intention of giving some testing feedback as you requested, here are some comments. I own a 4GB orange pi Zero 3 with extension board. I started playing with the first image a bit until you uploaded the second image, with which I played a little bit more.

Hi @fizban thanks for this information and taking the time to post!

Some of your feedback is a bit high level for current development (userspace applications such as Firefox/VLC are above where we are working at the moment) but it's all good information we can refer to in future. When referring to the images you are testing, could I ask you to provide the link you used to download the image? that will make it easier to marry up to a commit. Speaking of which, I will try and improve my method of naming the downloads so they have a commit or another consistent feature because even I am losing track at times as there are several fronts of development

The HDMI information is interesting. I did have display issues with output on one of my monitors, but another monitor I had handy was able to handle the signal ok, so HDMI may still have some quirks on this board. I didn't think to disconnect/reconnect the monitor after the initial detection, this may help with some of the Zero2 troubleshooting.

Great that you were able to validate expansion USB port, WiFi and Bluetooth.. they have been the key things we've been working through. One thing I don't currently have any feedback on is audio, did any of your tests confirm audio out works on the expansion board or HDMI? I haven't really devised a simple test for this yet.

Thanks again!

[pixdrift]

@Gunjan Gupta the changes for zero3 CPU Frequency are all bundled into this commit
https://github.com/pixdrift/armbian_build/commit/e53cba13aea0d1d7c555599bd4fbd6ae94d49dd0

It's on my branch zero3_cpufreq
https://github.com/pixdrift/armbian_build/tree/zero3_cpufreq
 

Changes of interest are are
https://github.com/pixdrift/armbian_build/blob/e53cba13aea0d1d7c555599bd4fbd6ae94d49dd0/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling-v1_6_2-dtsi.patch#L98-L141

Thanks for the offer to take a look

Edited December 22, 2023 by pixdrift

[fizban]

@pixdrift No, on board sound was not available, at least on the analog output. My monitor does not have hdmi sound, so i cannot test that. Anyway, the Alsa mixer/Volume control does not display any sound device,  just the Dummy Output.

 

By the way, now Firefox behaves as expected. I guess the reboot helped also in that sense, although Chromium feels snappier and more stable.

[Stephen Graf]

@pixdrift I just built and loaded the latest from your repo.  Something to look into for the HDMI, on startup I get this message:

 

Waiting for system to finish booting ...
/usr/lib/armbian/armbian-firstlogin: line 337: /sys/class/graphics/fb0/virtual_size: No such file or directory
Welcome to Armbian-unofficial!

 

It is easy to miss because a big blue screen comes right after this.

 

@fizban Did you test the usb ports on the expansion board also?

[Gunjan Gupta]

55 minutes ago, Stephen Graf said:

Waiting for system to finish booting ...
/usr/lib/armbian/armbian-firstlogin: line 337: /sys/class/graphics/fb0/virtual_size: No such file or directory
Welcome to Armbian-unofficial!

Thats from armbian-firstrun. It tends to give that message if no display is detected.

 

5 hours ago, fizban said:

@pixdrift No, on board sound was not available, at least on the analog output. My monitor does not have hdmi sound, so i cannot test that. Anyway, the Alsa mixer/Volume control does not display any sound device,  just the Dummy Output.

Most likely will be due to missing audio hub patches - https://github.com/orangepi-xunlong/linux-orangepi/commit/cfe0a8df18c2418f77acb24b17b88c9271d9613c

[Gunjan Gupta]

7 hours ago, pixdrift said:

@Gunjan Gupta the changes for zero3 CPU Frequency are all bundled into this commit
https://github.com/pixdrift/armbian_build/commit/e53cba13aea0d1d7c555599bd4fbd6ae94d49dd0

It's on my branch zero3_cpufreq
https://github.com/pixdrift/armbian_build/tree/zero3_cpufreq
 

Changes of interest are are
https://github.com/pixdrift/armbian_build/blob/e53cba13aea0d1d7c555599bd4fbd6ae94d49dd0/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling-v1_6_2-dtsi.patch#L98-L141

Thanks for the offer to take a look

Will take a look and get back to you

[Gunjan Gupta]

BTW I am working on migrating armbian to 6.7 kernel - https://github.com/armbian/build/pull/6079

 

Feel free to test and comeback. currently it fails compilation for xradio and some realtek wifi drivers that I will fix today. It can be compiled when building with EXTRAWIFI=no, but that will skip compiling uwe5622 driver.

 

Edit: Compilation issue is now fixed.

[fizban]

@Stephen Graf yes, the usb ports on the expansion board work fine. I connected mouse and a keyboard to them without problems.

[iun cuim]

There is a warpme development with arch, which contains all the necessary patches, including many test things that have not yet made it to the mainline, but are being tested in linux-sunxi. Support for Zero2 and zero3 was added a very, very long time ago. https://github.com/warpme/minimyth2/tree/master/script/kernel/linux-6.6

HDMI support and everything related to it is handled by jernej, last effort is branch h616-var: https://github.com/jernejsk/linux-1/tree/h616-var

 

[Gunjan Gupta]

14 minutes ago, iun cuim said:

HDMI support and everything related to it is handled by jernej, last effort is branch h616-var: https://github.com/jernejsk/linux-1/tree/h616-var

We are aware of it. The HDMI patch that we are trying to integrate is from Jernej's tree as well. What you need to understand is that we have a generic kernel for all 64-bit allwinner SoCs, which means we have patches that can conflict changes that are done simply on top of mainline tree.

[iun cuim]

18 minutes ago, Gunjan Gupta said:

We are aware of it. The HDMI patch that we are trying to integrate is from Jernej's tree as well. What you need to understand is that we have a generic kernel for all 64-bit allwinner SoCs, which means we have patches that can conflict changes that are done simply on top of mainline tree.

I just warned against wasting time on work that has already been done.

Having a reference that already works and has been tested is also useful.

[pixdrift]

1 hour ago, iun cuim said:

There is a warpme development with arch, which contains all the necessary patches, including many test things that have not yet made it to the mainline, but are being tested in linux-sunxi. Support for Zero2 and zero3 was added a very, very long time ago. https://github.com/warpme/minimyth2/tree/master/script/kernel/linux-6.6

HDMI support and everything related to it is handled by jernej, last effort is branch h616-var: https://github.com/jernejsk/linux-1/tree/h616-var

 

40 minutes ago, iun cuim said:

1 hour ago, Gunjan Gupta said:

We are aware of it. The HDMI patch that we are trying to integrate is from Jernej's tree as well. What you need to understand is that we have a generic kernel for all 64-bit allwinner SoCs, which means we have patches that can conflict changes that are done simply on top of mainline tree.

I just warned against wasting time on work that has already been done.

Having a reference that already works and has been tested is also useful.

Hi @iun cuim and welcome to the forum!

 

Thanks for taking the time to create an account here and link to the development branches from warpme. I'm not too familiar with minimyth (and only new here) so hadn't come across this effort myself. I think it's great to see so many people showing enthusiasm for these boards, and it's always good to have more information so we aren't doubling up on work as you mention  This is very much a learning journey for me, but having a working reference for many of the same upstream patches will be a great help!

Do you know if there is similar forum discussion around the development for the attached github repository? and do you know if anyone is building full Orange Pi images using this modified/patched kernel? It would be great to compare capabilities of different images when we identify issues in development builds.
 

Thanks again!

-edit-

correct reference to repo

Edited December 24, 2023 by pixdrift
Update name to tag iun

[iun cuim]

10 minutes ago, pixdrift said:

Do you know if there is similar forum discussion in the Arch space for the attached github repository? and do you know if anyone is building full Orange Pi images with Arch using this modified/patched kernel? It would be great to compare capabilities of different images when we identify issues in development builds.

Here images: https://github.com/warpme/miniarch/releases

Quick start guide: https://github.com/warpme/miniarch#quick-start

There is no specific forum, since this project is led by one person. I only know about it from the #linux-sunxi developer channel.