wulfy23

Hello, to avoid this error, you can disable strict mode in the pin controller driver
https://elixir.bootlin.com/linux/v6.7.12/source/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
 
 
But I'm not sure that the driver for this touchscreen can work on allwinner processors without changes, because  their "gpio_in" and "irq" are different multiplexer states
 
 
I think they cannot work simultaneously, so something similar is needed
 
 
PS Of course you can use different pins for interrupts and gpio and then everything should work out of the box.

This has been replaced by: User Space IO get more details on this thread.
 

 
Well, it's time to say goodbye to sysfs and hello to libgpiod! @zador.blood.stained pointed me in the right direction, but you need to do one little hack I'll explain below involving compiler_types.h. I tested this on a NanoPi Duo, but it should work on any mainline Armbian release (and other distros as well) as long as the kernel is >= 4.8. Try ls /dev/gpiochip* and see if anything is listed. If so, then proceed.
 
I'm continuing work on my Github site https://github.com/sgjava/libgpiod-extra, so please report any issues there. There is an Armbian install script that automates the steps below I generated the Python wrapper, but there's a lot of functions to test, so I'm not sure of the quality. I'm working on some simple Python tests.
sudo armbian-config, Software, Headers sudo apt-get install libtool pkg-config git clone https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git cd libgpiod mkdir -p include/linux cp /usr/src/linux-headers-$(uname -r)/include/linux/compiler_types.h include/linux/. ./autogen.sh --enable-tools=yes --prefix=/usr/local CFLAGS="-I/usr/src/linux-headers-$(uname -r)/include/uapi -Iinclude" make sudo make install sudo ldconfig Let's try some commands:
 
sudo gpiodetect
 
gpiochip0 [1c20800.pinctrl] (224 lines)
gpiochip1 [1f02c00.pinctrl] (32 lines)
 
sudo gpioinfo | grep "\[used\]"
 
    line  10:      unnamed "nanopi:blue:status" output active-high [used]
    line 166:      unnamed         "cd"   input  active-high [used]
    line 202:      unnamed  "interrupt"   input  active-high [used]
    line 205:      unnamed      "reset"  output   active-low [used]
    line   6:      unnamed          "?"  output  active-high [used]
    line   7:      unnamed   "vcc-wifi"  output  active-high [used]
    line  10:      unnamed "nanopi:green:pwr" output active-high [used]
 
Notice how it found the Duo's built in LEDs
 
Now let's test the Duo's built in button (press and release 3 times):
 
sudo gpiomon --num-events=3 --rising-edge gpiochip1 3
 
event:  RISING EDGE offset: 3 timestamp: [1516774143.944174870]
event:  RISING EDGE offset: 3 timestamp: [1516774145.123474395]
event:  RISING EDGE offset: 3 timestamp: [1516774145.987531088]
 
Wire up LED (the normal way) and use Duo's IOG11 then to turn on and off:
 
sudo gpioset gpiochip0 203=0
sudo gpioset gpiochip0 203=1
 
Python code
import time from libgpiod.libgpiod import * chip = gpiod_chip_open("/dev/gpiochip0") line = gpiod_chip_get_line(chip, 203) # The will set line for output and set initial value (LED on) if gpiod_line_request_output(line, "test", 0) == 0: time.sleep(3) # LED off gpiod_line_set_value(line, 1) gpiod_line_release(line) gpiod_chip_close(chip) More reading at https://www.cnx-software.com/2017/11/03/learn-more-about-linuxs-new-gpio-user-space-subsystem-libgpiod and https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/README. Maybe @Larry Bank will work on ArmbianIO II It looks like in the old Github site there was a milestone to create Python and C++ wrappers https://github.com/brgl/libgpiod/milestone/3. Once I learn more about libgpiod I may just generate them like I did for ArmbianIO.

For information purposes,  that the 1.3-inch SH1106 OLED connected to I2C on OZPI v3 works very well
 
OLED connected to PIN 3 of SDA and PIN 5 of SCK and in armbian-config in HARDWARE set to [*] i2c3-ph
 
Using tools i2cdetect -y
 
shows that the OLED is at address 0x3c
 
All Python code with the adafruit library works fine
 

I kinda remember that in the original image, u-boot can be extracted from there the same way posted a few comments earlier, that with the u-boot SPL bin file and instructions.
 
I looked at the /boot/boot.cmd from the some-files-from-boot-folder archive
 
thoughts are that things could have changed between u-boot versions as new u-boot versions 'advanced' till today, 
though I'm not sure if Orange Pi could have made some customizations in u-boot (the actual core u-boot code itself) so that the /boot/boot.cmd works the way they wanted it.
e.g. that some of the 'environment variables' may not be there in the 'standard' u-boot. that could cause the boot script to fail and hence what you saw.
to get things back on track, I'd guess restoring the old u-boot could be a simplest resort, but the 'old' 1.5g issue stays with that u-boot.
 
to be upfront, I'm learning all these new as well, u-boot basically run a bunch of scripts within the 'environment (with variables)', u-boot's own (specialized) shell commands / scripts.
there is a bunch of scripts (environment (variables)) in the 'standard' core, then along the way core u-boot scripts evaluates/calls the scripts in /boot/boot.scr (if it exists), if not /boot/boot.cmd directly, that enables u-boot to 'pass' 'environment variables' between the core u-boot to the scripts in /boot/boot.cmd in the linux root partition. this will more than likely break things (e.g. script fail) when u-boot tries to run a /boot/boot.cmd that use 'environment variables' not there in the 'standard'. of course, this technique is 'powerful', everything is 'black magic' - undocumented, can vary with every different implementation of /boot/boot.cmd in infinite number of permutations (e.g. you can always add a variable in core u-boot for your hardware, then reference it in the /boot/boot.cmd (or /boot/boot.scr), then a 'standard' implementation would simply throw error once it reach there.
not that it is 'wrong', but that that is the state of the art, 'bleeding edge' if you'd like to call it. that is the state of the art of the embedded world infinite permutations of permutations and no 2 of them are 'standard'.
raspberry pi uses u-boot as well, so do a 'thousand' other soc and boards and no 2 u-boot implementation is 'the same', among all of all of them.
 

@ag123 I have been doing a lot of tests using official Orange Pi Zero 3 SDK following instructions here, and I think a got a way to detect the right memory size. I was not able to fix random memory size detection yet, so it would be next.
 
Anyway, what I saw is that current memory size detection is based on top address wap around to base address. It works well for 1GB, 2GB and 4GB, but not for 1.5GB, as it is not even tried by this method. So I tried to write something to 1.5GB memory address and looking around memory to find a match, and I did not find anything. Instead what I got is that address maps to nowhere, because writing something and then reading once an again, what I got was a kind of random values. And based on that I coded a memory size fix.
 
First of all I need a funcion to check top memory:
bool mctl_mem_matches_top(ulong offset) { static const unsigned value= 0xaa55aa55; /* Take last usable memory address */ offset -= sizeof(unsigned); dsb(); /* Set zero at last usable memory address */ writel(0, (ulong)CONFIG_SYS_SDRAM_BASE + offset); dsb(); /* Set other value at last usable memory address */ writel(value, (ulong)CONFIG_SYS_SDRAM_BASE + offset); dsb(); /* Check if the same value is actually observed when reading back */ return readl((ulong)CONFIG_SYS_SDRAM_BASE + offset) == value; }  
And then just use it to fix memory size:
static unsigned long mctl_calc_size(struct dram_para *para) { u8 width = para->bus_full_width ? 4 : 2; unsigned long size; /* 8 banks */ size = (1ULL << (para->cols + para->rows + 3)) * width * para->ranks; /* Fix size if last usable memory address is not valid */ if (!mctl_mem_matches_top(size)) size = (size * 3) / 4; return size; }  

@voapilro @bjorn @Long-Johnny, all
psst some fun stuff
https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/
ok that's the 2nd attempt to create a custom u-boot to boot Armbian on 1.5 GB OPi Zero 3 boards, do visit the repository for more info.
 
first you can try that with the 'official' image
https://www.armbian.com/orange-pi-zero-3/
but that this u-boot is build from mainline u-boot at the 2024.04 release
https://gitlab.com/u-boot/u-boot
and that it requires a working /boot/boot.scr or /boot/boot.cmd to boot linux. /boot/boot.scr or /boot/boot.cmd are the boot scripts that actually has u-boot commands which loads the kernel and dependencies and boot linux.
if the boot drops you into a command shell, it could mean either that the /boot/boot.scr or /boot/boot.cmd is invalid or that it is using a *custom* u-boot and the /boot/boot.cmd, /boot/boot.scr uses or is expecting some variables that is not there in 'standard' mainline u-boot.
I managed to boot to the Linux command prompt this time !
 
I'd just like to say that I took the Armbian Bookworm minimal image from the Armbian release web for Orange Pi Zero 3
Armbian_community 24.5.0-trunk.474 6.6.28 
https://www.armbian.com/orange-pi-zero-3/
did my u-boot patch, run it on my 1.5 GB Orange Pi Zero 3 and it booted to the prompt! and just right now
 
Here is a screenshot running from Orange Pi Zero 3 - 1.5 GB board tethered from usb-uart to debug console, I ran the command 'free' which shows that the total memory is 1.5GB
how about that for a proof-of-concept 
without this u-boot 'patch' u'd get 'stuck' at the boot reporting 2GB seen on the usb-uart debug console for the 1.5GB board.
 

 
men I feel like celebrating, now Armbian runs on 'all variants' of Orange Pi Zero 3 - 1 GB / 1.5 GB (with this hack) / 2 GB / 4GB 

Hi Long Vu . I use Vontar H618 2GB ram. it's running well with armbian 6.7.10 . only need to fix wifi driver

What do these explicitly do? 
 
Which ones can be disabled?
 
Which ones can interfere with other system mods?
 
sudo systemctl list-unit-files | grep armb* armbian-firstrun-config.service            enabled         armbian-firstrun.service                   disabled        armbian-hardware-monitor.service           enabled         armbian-hardware-optimize.service          enabled         armbian-ramlog.service                     enabled         armbian-resize-filesystem.service          disabled        armbian-zram-config.service                enabled       I've notices that ramlog can be disabled two ways - in the config, or disable the service, others related to if zram-config is installed or not - HW monitor actually doesn't seem to impact things on 5.60+ when running local, other than we see less /var/log stuff (which is ok) - the zram-config-service can get in the way of testing, but generally harmless otherwise.
 
Just curious as to why?
 
 

@ag123, @c0rnelius, and anyone else that has interest in sound on these devices.
 
I have been able to put together a patch that enables audio for H161/H618 devices.  So far only audio on HDMI works. Analog audio is still generating an error on startup.
 
The patches were taken from a git repository by warpme:
https://github.com/warpme/minimyth2/tree/master/script/kernel/linux-6.6/files
, and probably came from the Zunlong SDK. A lot of the code was written by Allwinner.
 
@pixdrift generated a version of the patches for Armbian and I continued to work on them.
 
I have a git repository if anyone would like to test, particularly on boards other than orangpizero3, on which I have tested.
 
repository:
https://github.com/stephengraf/armbian_build_sg.git
 
There is another repository mentioned in the Armbian Forum:
https://github.com/NickAlilovic/build
 
If anyone has interest and skills to debug the analog audio, the dmesg errors are:
[    7.125509]  ahub_dam-snd-soc-dummy-dai: substream ahub_dam-snd-soc-dummy-dai has no playback, no capture
[    7.125539] sunxi-snd-mach soc:ahub_dam_mach: ASoC: can't create pcm ahub_dam-snd-soc-dummy-dai :-22
[    7.125780] sunxi-snd-mach: probe of soc:ahub_dam_mach failed with error -22
 

A bss138 FET or something similar can be used.

I found the wifi firmware needed for this box. Download and rename the file to "brcmfmac4335-sdio.transpeed,8k618-t.bin". Place it in /lib/firmware/brcm.
https://github.com/LibreELEC/brcmfmac_sdio-firmware/blob/master/brcmfmac4335-sdio.bin
 
Also needs the brcmfmac4335-sdio.txt. No need to rename it just place it in /lib/firmware/brcm.
https://github.com/LibreELEC/brcmfmac_sdio-firmware/blob/master/brcmfmac4335-sdio.txt
 
 

I have used the old /sys/class gpio interface quite extensively in the past.  However it is not available in the newer kernels and my only experience with the new api has been to test the orangepizero3 with the code in the links below. It worked.
 
https://docs.rs/gpio-cdev/latest/gpio_cdev/
 
https://github.com/rust-embedded/rust-gpio-cdev

For anyone coming to this post facing the same issue - I solved my problem.
 
Following the guide here: https://forum.inovato.com/post/building-armbian-from-source-12449428?pid=1333459893
 
I was able to build the latest from trunk - Armbian_23.02.0-trunk_Aw-h6-tv_bullseye_current_5.15.91 which I was able to boot from an SD card and then write to the boards emmc
The guide applies some patches to the build process - one of which is an emmc patch, which I'm going to assume fixed the issue.
 
It took 4+ hrs to build the image on a single core linux VM, so if you are going to attempt this just know it will take that long to make the image.