Gunjan Gupta

Look at the path of the patch and you will understand why. In the PR I have patched both 6.1 and 6.6 kernel. In 6.1 kernel, there is no sun50i-h616-orangepi-zero.dtsi and hence changes were needed in sun50i-h616-orangepi-zero2.dts. However, as 6.6 kernel has sun50i-h616-orangepi-zero.dtsi, changes were done in the same.

The sun4i-drm patch needs a lot of work before it can merge into Armbian and without it there will be no HDMI support. It conflicts with a lot of other patches. I am planning to work on it next week.
 
All thats needed is building an image for current and edge kernels, flash it on sdcard and boot on zero2. See if you are provided an option to connect to wifi and if you are able to connect to it.

Thanks @Gunjan Gupta I have forked your github zero2w repo and will add everything I have (patches/config) to get zero 3 working so it's based off your existing work with minimal changes... hoping we can then work to get both boards into the mainline Armbian

https://github.com/pixdrift/armbian_build/tree/zero3

I will post back here when I have all the changes tidied up, merged in, and building cleanly.

Could you please share more detail about why you think 6.1.63 is affected? As I can see in the links you have shared, the problematic commit was introduced in 6.1.64. So 6.1.63 is not affected. Am I missing something?

Most of the Armbian kernels are made by taking the upstream kernel and applying patches on top of it.
 
If you go to https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/fs/ext4/file.c?h=v6.1.66, you will see that the commit at the top is the one that caused the bug. In the same url, if you change the version to 6.1.63, you can see the commit is not there. Hence we are not affected.
 
Fun Fact, first commit after we had made v23.11 release was upgrading to 6.1.64 kernel, and it was only published to beta repository. Currently beta repository is using 6.1.66 kernel for current branch. 

To my understanding it was introduced by kernel commit 91562895f803, which was accepted by kernel team
https://lore.kernel.org/linux-ext4/87bkbbijwt.fsf@doe.com/T/
 
I didn't find any changelogs for the kernel on my Armbian host. I looked into these changelogs, but didn't find any data:
  zless /usr/share/doc/linux-dtb-current-meson64/changelog.gz
  zless /usr/share/doc/linux-image-current-meson64/changelog.gz
--> I'm unsure, if I'm affected. FUD.,
 
On the other side, on the Debian Users ML are reports, that Debian Bookworm is affected:
https://lists.debian.org/debian-user/2023/12/msg00500.html
More FUD on my site.
 
As I don't have a changelog, and people are saying that my distribution (bookworm) is affected, I can only assume that Armbian is very likely affected too.

But I'm glad to here, that I'm not.
Thank you.

@IgorI think the problem is caused by the way the packages are published. I think we ran the build for bookworm and jammy, but when publishing we updated the Package list of bullseye as well. Thats how bullseye is now getting armbian-bsp-cli package for 23.11 version. As build was not run for bullseye, the bullseye specific base-files package didn't got updated. I think we need to modify our repo updating job to also take account of what distributions to be updated, instead of updating all of the distributions. That should fix these kind of upgrade issues when we drop support for older OS. Lets disccuss this further in today's meeting 

@IgorI think the problem is caused by the way the packages are published. I think we ran the build for bookworm and jammy, but when publishing we updated the Package list of bullseye as well. Thats how bullseye is now getting armbian-bsp-cli package for 23.11 version. As build was not run for bullseye, the bullseye specific base-files package didn't got updated. I think we need to modify our repo updating job to also take account of what distributions to be updated, instead of updating all of the distributions. That should fix these kind of upgrade issues when we drop support for older OS. Lets disccuss this further in today's meeting 

agree with @Igor, supporting a board is a long term commitment and no easy feat.
Those who are reading this thread should take it that there is no official Armbian release (not even 'community' nor 'unsupported')  for this board (yet).
The images tested prior to these comment includes:
vendor's images some images created by 3rd parties (possibly including Armbian derivative) These are 'community efforts', attempts to run it on Orange Pi Zero 3 and is purely 'experimental'.
 
But I'm hoping that we can build up enough *community* support and involvement for Orange Pi Zero 3 here.
Note that for a supported board, it would call on the community for continuous maintenance and integration,  as well as being involved in doing tests when new releases are made. Armbian isn't just supporting one single board after all.
It'd also means that the community would need to support this effort financially as well, i.e. supporting Armbian.
--
I've been (*messing*) experimenting with this board and I learned something, while one is messing with 'experimental' software, and 'experimental' boards e.g. this board.
It is easy to think of it as a software problem. After all the experiments, it turns out some of my network woes I encountered are simply due to a defective network cable.
But that said, there are 3rd party images or some such images there are broken in the software.

issues with other (e.g. network) hardware are after all quite common e.g. in this case a problem with network hub, and in my case a defective network cable
https://forum.armbian.com/topic/29954-sd-card-corrupt-after-hard-power-off/?do=findComment&comment=176561
 
i.e. there are so many blind spots when something doesn't work, and your hardware (including like cables, other hardware etc) should be in the checklist for troubleshooting.
 

I just found the problem! I just commented the parameter CONFIG_DRAM_CLK from u-boot defconfig (sunxi_Gemei_G9_defconfig) and the problem is gone. Thank you very much for yours tips Gunjan!

Interesting...I tested the 32-bit Allwinner kernel before we release on a H3 board and it was booting.
 
You can give images from the archive a try. You can also try creating image yourself, Use branch as edge and it will create an image with 6.6 kernel. Instructions for building an image can be found here - https://docs.armbian.com/Developer-Guide_Build-Preparation/

if you can mount the sdcard and see the contents, then try editing boot/armbianEnv.txt file and the following at the end of. the file
 
earlycon=on extraargs=debug verbosity=7 console=serial  
This will get you more output on your serial port and then we can proceed based on the same

Probably, it will also be a good idea to add
fdtfile=sun4i-a10-gemei-g9.dtb Just to make sure that your device specific device tree is used.

Easier method: create an device tree overlay and use the same.
 
/dts-v1/; /plugin/; &{/soc} { ehci0: usb@1c14000 { compatible = "allwinner,sun8i-r40-ehci", "generic-ehci"; reg = <0x01c14000 0x100>; interrupts = <0x00 0x27 0x04>; clocks = <&ccu 0x2f>; resets = <&ccu 0x17>; phys = <&usbphy 0>; phy-names = "usb"; status = "okay"; }; ohci0: usb@1c14400 { compatible = "allwinner,sun8i-r40-ohci", "generic-ohci"; reg = <0x01c14400 0x100>; interrupts = <0x00 0x28 0x04>; clocks = <&ccu 0x32>, <&ccu 0x7f>; phys = <&usbphy 0>; phy-names = "usb"; status = "okay"; }; };  
Assuming I didn't left any syntax errors in the above overlay, you should be able to create a dts file with the above content and then use "sudo armbian-add-overlay <dts-filename>" to enable the same

WiFi is working with the edge kernel!

A colleague just pointed out to me that you are doing docker in docker. May be just run ./compile.sh PREFER_DOCKER=no to avoid spawning docker instance within docker?

I solved the issue on hardware level. It turned out that those pins had external pull-ups.
I switched to two other pins which worked just fine.

For separate ext2 boot partition, I think you can pass BOOTFS_TYPE=ext2 to the compile commandline.
 
If you are ok with writing extensions for armbian build framework or to modify the same, the script that handles partitioning is lib/functions/image/partitioning.sh. There are few hook used functions in there. I am not 100% sure if using those in a custom extension will allow to use LVM for partitioning or not, so you have to try that yourself. Worst case scenario, you have to modify partitioning.sh to add support for LVM.

@surenz Seems like discord went down. So posting here instead
 
As the overlay you are using seems ok, could you try creating your own custom image using https://github.com/armbian/build. I think there is a kernel patch that might be causing the conflict. Try editing patch/kernel/archive/sunxi-6.1/series.conf file to add a - (hyphen) at the start of the line that contains patches.megous/phy-allwinner-sun4i-usb-Add-support-for-usb_role_switch.patch. Then compile using ./compile.sh BOARD=orangepione BRANCH=current. For detailed instruction on setting up build environment and creating an image, see https://docs.armbian.com/Developer-Guide_Build-Preparation/

Wifi for current and edge kernel is fixed and updated kernel is available from beta repository and in nightly builds. It will be pushed to stable later may be in few days or once 23.11 is released

for uwe5622, when it comes to allwinner, only device tree specific thing needed is to mark the corresponding mmc node status as ok. Other than that, only available option is for configuring bt_wake pin for bluetooth low power mode. But that is optional. So as long as mmc node is present and status is set to ok, wifi should work find once the corresponding drivers are loaded either manually or via kernel commandline.

@FelSM The format you have used to define gpios for cs-gpios format seems bit odd to me. May be it is just my lack of knowledge, not 100% sure. Generally for allwinner boards, the format I have seen contains 4 parameter i.e. reference to pinctrl node either &pio or &r_pio, pin line number, gpio number and then state. You only have mentioned 3 parameters which makes me a bit confused about what pins you are trying to use as chip selects here.

Allwinner H3 CPU has an in-built RTC which is mounted at /dev/rtc0. This is the reason the RTC doesn't save current time when CPU powers off. The RTC present on the NAS kit (DS1307) needs to be accessed using i2c interface which itself needs to be enabled before doing anything else, and all time sync done with DS1307.
 
Enable i2c (i2c-tools is present in Armbian bullseye by default) by editing /boot/armbianEnv.txt file:
sudo nano /etc/armbianEnv.txt in the line
overlays=... where "..." means there are already some overlays mentioned, append " i2c" (notice a space before i2c) so that the line should look like
overlays=... i2c Save and close. Next, make sure DS1307 module is present in your kernel (it is present in Armbian bullseye by default)
sudo modinfo rtc-ds1307 If you see some description and a signature, it is present. Load the module on system start up by adding line to /etc/modules:
sudo echo rtc-ds1307 >> /etc/modules  Run the following command:
sudo i2cdetect -y 0 If you see something like this:
0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- then you can see rtc1 in /dev:
sudo ls -al /dev/ | grep rtc You need to initialize rtc1 (one time):
sudo hwclock --rtc /dev/rtc1 --systohc Create a new file called rtc_ds1307 and add following text (copied from here) by following command:
sudo cat <<EOF > rtc && sudo mv rtc /etc/init.d/rtc_ds1307 && sudo chmod +x /etc/init.d/rtc_1307 #! /bin/sh ### BEGIN INIT INFO # Provides: rtc_ds1307 # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: DS1307 real-time clock usage script # Description: This file should be used to construct scripts to be # placed in /etc/init.d. ### END INIT INFO # PATH should only include /usr/* if it runs after the mountnfs.sh script PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="ds1307_rtc maintenance service" do_start() { echo "Selecting correct RTC instance" echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device sudo ln -f -s /dev/rtc1 /dev/rtc echo "Syncing system time to RTC" #You need to sync from rtc1 instead of default (rtc0) sudo hwclock -s -f /dev/rtc1 } do_stop() { echo "Syncing RTC to system time" sudo hwclock -w } case "\$1" in start) do_start ;; stop) do_stop ;; status) echo "RTC time:" hwclock -r echo "System time:" date ;; restart|force-reload) do_stop ;; *) echo "Usage: rtc_ds1307 {start|stop|status|restart}" >&2 exit 3 ;; esac EOF Update rc.d then reboot:
sudo update-rc.d rtc_ds1307 defaults sudo reboot now Check your system time by following command:
timedatectl  

Few changes to above answer:
Edit armbianEnv.txt by
sudo nano /boot/armbianEnv.txt And append i2c0 instead of i2c
overlays=... i2c0 install i2c-tools
sudo apt install i2c-tools If your "sudo i2cdetect -y 0" returns 68, run the following commands first:
Load rtc-ds1307 by
sudo modprobe rtc-ds1307 sudo echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device  

Moved to rockchip forum as this is not an Allwinner board