Jump to content

ag123

Members
 View Profile  See their activity

  • Posts

    246

  • Joined

  • Last visited

 Content Type 

Posts posted by ag123

    Sound on H616/H618 socs

    in Allwinner sunxi

    Posted

    thanks, I'd probably try that some time. if audio for HDMI works, I think many users will be happy, I've read some comments some are looking for that.

    currently, I'm using headless as wifi ap, so I did not know if it works.

    analog may need to go back into h616 zero 2 to see how it is done there, maybe dts etc.

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    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

    Spoiler 
    # DO NOT EDIT THIS FILE
#
# Please edit /boot/orangepiEnv.txt to set supported parameters
#

# default values
setenv load_addr "0x45000000"
setenv overlay_error "false"
setenv rootdev "/dev/mmcblk0p1"
setenv verbosity "1"
setenv rootfstype "ext4"
setenv console "both"
setenv docker_optimizations "on"
setenv bootlogo "false"

# Print boot source
itest.b *0x10028 == 0x00 && echo "U-boot loaded from SD"
itest.b *0x10028 == 0x02 && echo "U-boot loaded from eMMC or secondary SD"
itest.b *0x10028 == 0x03 && echo "U-boot loaded from SPI"

echo "Boot script loaded from ${devtype}"

if test -e ${devtype} ${devnum} ${prefix}orangepiEnv.txt; then
	load ${devtype} ${devnum} ${load_addr} ${prefix}orangepiEnv.txt
	env import -t ${load_addr} ${filesize}
fi

if test "${console}" = "display" || test "${console}" = "both"; then setenv consoleargs "console=ttyS0,115200 console=tty1"; fi
if test "${console}" = "serial"; then setenv consoleargs "console=ttyS0,115200"; fi
if test "${bootlogo}" = "true"; then
        setenv consoleargs "splash plymouth.ignore-serial-consoles ${consoleargs}"
else
        setenv consoleargs "splash=verbose ${consoleargs}"
fi

# get PARTUUID of first partition on SD/eMMC it was loaded from
# mmc 0 is always mapped to device u-boot (2016.09+) was loaded from
if test "${devtype}" = "mmc"; then part uuid mmc 0:1 partuuid; fi

setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs}"

if test "${docker_optimizations}" = "on"; then setenv bootargs "${bootargs} cgroup_enable=memory swapaccount=1"; fi

load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
fdt addr ${fdt_addr_r}
fdt resize 65536
for overlay_file in ${overlays}; do
	if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-${overlay_file}.dtbo; then
		echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo"
		fdt apply ${load_addr} || setenv overlay_error "true"
	fi
done
for overlay_file in ${user_overlays}; do
	if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then
		echo "Applying user provided DT overlay ${overlay_file}.dtbo"
		fdt apply ${load_addr} || setenv overlay_error "true"
	fi
done
if test "${overlay_error}" = "true"; then
	echo "Error applying DT overlays, restoring original DT"
	load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
else
	if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-fixup.scr; then
		echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)"
		source ${load_addr}
	fi
	if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then
		load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr
		echo "Applying user provided fixup script (fixup.scr)"
		source ${load_addr}
	fi
fi

if test "${ethernet_phy}" = "rtl8211f"; then
        fdt set /soc/ethernet@5020000 allwinner,rx-delay-ps <3100>
        fdt set /soc/ethernet@5020000 allwinner,tx-delay-ps <700>
fi

if test "${ethernet_phy}" = "yt8531c"; then
        fdt set /soc/ethernet@5020000 allwinner,rx-delay-ps <0>
        fdt set /soc/ethernet@5020000 allwinner,tx-delay-ps <600>
fi

load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd
load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}Image

booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

# Recompile with:
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

     

     

    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.

     

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @voapilro

    oops, did you backup your original u-boot from the image? to restore this, you would need that u-boot backup.

    some u-boot bin files are customized with particular ways to start the kernel and that stored into u-boot in that 1st 1 meg or so.

    For the standard u-boot, it uses files in /boot/boot.cmd or /boot/boot.scr in the Linux root partition to boot linux, that is normally the case for Armbian distributions

     

    btw that scary prompt is the u-boot command prompt / shell :)

    https://docs.u-boot.org/en/latest/usage/index.html

    https://linux-sunxi.org/U-Boot

    https://krinkinmu.github.io/2023/08/12/getting-started-with-u-boot.html

     

    try  

    ls mmc 0 [directory e.g. /, /boot etc]

     

    and

    'help' in the u-boot command prompt, confusing at least

    if you can post the contents of /boot/boot.cmd in the root partition, normally those are the commands to boot linux from u-boot. If that is goofy (incorrect), linux will not boot. Those bunch of u-boot commands are critical to start linux. normally that can be compiled into another file called /boot/boot.scr (that is for an older version of u-boot)

    u-boot reads that /boot/boot.cmd (or /boot/boot.scr) which contains the commands to start linux with the kernel image, ram disk and the device tree binary (also called the flattened device tree FDT)

    this is so that changing the kernel probably means only editing /boot/boot.cmd (and generate /boot/boot.scr if needed)

     

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    ok just an update, I managed to get past that '1.5GB' issue

    the hack is done in u-boot, but the bad news is that that alone won't fix things:

    Spoiler 
    U-Boot SPL 2024.04-00757-FixOPiZero3_1.5G (Apr 19 2024 - 23:25:32 +0800)
sunxi_board_init
DRAM:sunxi_dram_initdetected memsize 2048 M
 1536 MiB
spl_board_init_r
Trying to boot from MMC1
NOTICE:  BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c
NOTICE:  BL31: Built : 23:11:18, Apr 18 2024
NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
NOTICE:  BL31: Found U-Boot DTB at 0x4a0b4330, model: OrangePi Zero3
ERROR:   RSB: set run-time address: 0x10003


U-Boot 2024.04-00757-FixOPiZero3_1.5G (Apr 19 2024 - 23:25:32 +0800) Allwinner Technology

CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  1.5 GiB
Core:  58 devices, 25 uclasses, devicetree: separate
WDT:   Not starting watchdog@30090a0
MMC:   mmc@4020000: 0
Loading Environment from FAT... Unable to use mmc 0:1...
In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Allwinner mUSB OTG (Peripheral)
Net:   eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC de:ad:be:ef:00:01
HOST MAC de:ad:be:ef:00:00
RNDIS ready
, eth1: usb_ether
starting USB...
Bus usb@5200000: USB EHCI 1.00
Bus usb@5200400: USB OHCI 1.0
scanning bus usb@5200000 for devices... 1 USB Device(s) found
scanning bus usb@5200400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3259 bytes read in 4 ms (794.9 KiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
205 bytes read in 4 ms (49.8 KiB/s)
32823 bytes read in 8 ms (3.9 MiB/s)
Working FDT set to 4fa00000
4203 bytes read in 7 ms (585.9 KiB/s)
Applying kernel provided DT fixup script (sun50i-h616-fixup.scr)
## Executing script at 45000000
10936176 bytes read in 457 ms (22.8 MiB/s)
23570440 bytes read in 982 ms (22.9 MiB/s)
Moving Image from 0x40080000 to 0x40200000, end=41910000
## Loading init Ramdisk from Legacy Image at 4ff00000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    10936112 Bytes = 10.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
Working FDT set to 4fa00000
   Loading Ramdisk to 49592000, end 49ffff30 ... OK
   Loading Device Tree to 0000000049521000, end 0000000049591fff ... OK
Working FDT set to 49521000

Starting kernel ...

[    2.144698] thermal thermal_zone0: gpu-thermal: critical temperature reached, shutting down
[    2.153147] reboot: HARDWARE PROTECTION shutdown (Temperature too high)
[    2.192185] reboot: Power down

     

     

    This gpu over temperature is nonsense, the chip is hardly warm and this same image boots just fine on a 2GB device with the 'standard' u-boot.

    It'd seem that some other things is at play here, e.g. that the registers for 1.5GB model are after all different and may need a different DTS configuration.

    I don't have a solution to go forward for now for 1.5GB devices, configuring DTS takes much more than this little hack, in the sense that we'd not know if this gpu thermal thing is the only odd thing or that there are other things that needs to be fixed as well.

     

    --

    for those who insist if you would like to test this solution, the attached file is the modified u-boot compiled from 

    https://source.denx.de/u-boot/u-boot

    https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads#L1353

    the function arch / arm /mach-sunxi /dram_sun50i_h616.c

    function mctl_calc_size() is modified as: 

    static unsigned long mctl_calc_size(const struct dram_config *config)
{
        u8 width = config->bus_full_width ? 4 : 2;

        /* 8 banks */
        unsigned long long memsz = (1ULL << (config->cols + config->rows + 3))
                * width * config->ranks;
        log_info("detected memsize %d M\n", (int)(memsz >> 20));
        /* 1.5 GB hardcoded */
        memsz = 2048UL * 1024UL * 1024UL * 3 / 4;
        return memsz;
}

    i.e. that 1.5GB is *hardcoded*, obviously this won't be appropriate for most boards except in particular case of 1.5GB.

    Initially, i placed an if statement that says if the detected ram is 2GB say that it is 1.5GB, that is bad as well as then 2GB boards will simply read 1.5GB.

    however, during tests, I noted that the detected dram size varies between 2 GB and 4 GB. my guess is there are timing issues associated with the 1.5GB dram chip, hence I resorted to hard coding which does not bother how much dram is really detected.

    if you prefer to build u-boot from sources, follow instructions from here:

    https://docs.u-boot.org/en/latest/board/allwinner/sunxi.html

     

    To use this modified u-boot, the best practice is to start with / use an image that is known to work on 1GB / 2GB / 4GB Orange Pi Zero 3 boards.

     

    assuming that your image SD card is mounted at /dev/sdX, you can backup your existing u-boot e.g.  

    sudo dd if=/dev/sdX of=u-boot-backup.bin bs=1024 skip=8 count=1024

    that should backup the u-boot in your device to u-boot-backup.bin

     

    then to write the modified u-boot into the SD card it is (be sure that you are writing to the correct device ! mistakes here can corrupt your existing hard disks / storage) 

    sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8

     

    it may be possible to write that to an existing image file (do backup your image file beforehand) 

    dd if=u-boot-sunxi-with-spl.bin of=file.img bs=1024 seek=8 conv=notrunc

    but that I've not tried this.

     

    I've created a 'sd image u-boot patcher' uploaded here in github gist:

    https://gist.github.com/ag88/cebfcd2bc1b413d2a0d43dafa6b572f0 

    usage: image-u-boot-patcher.py [-h] [--nobak] [--ignimgsize] image uboot_bin

  patch u-boot binary into image

  positional arguments:
  image image file
  uboot_bin u-boot bin file

 options:
 -h, --help show this help message and exit
 --nobak do not backup image
 --ignimgsize  ignore image size check

     

    you need python3 to use that 'sd image u-boot patcher'

    https://www.python.org/downloads/release/python-3123/

    run it as 

    python3 sdimage-u-boot-patcher.py imagefile.img uboot-spl.bin

     

    it is a console app, which means that for Windows users, it'd need to be run in a Cmd prompt window.

    note: I've not tried running this in Windows, only tested in Linux.

    This may help for 'Windows' users who may not have access to commands like 'dd' which is mainly available in unix, Linux.

    This is so that you can patch the image file directly and perhaps use Balena etcher

    https://etcher.balena.io/

    or Rufus

    https://rufus.ie/en/

    to write the image to an SD card / usb drive.

     

    In linux, it is found that the sdimage-u-boot-patcher script can actually update /dev/sdX directly. But that it it cannot determine the image size as it is a device and normally it'd need to be run as root.

    Hence, I've added a  --ignimgsize  ignore image size check flag for those who wanted to use it that way. e.g. 

    sudo python3 sdimage-u-boot-patcher.py --ignimgsize /dev/sdX uboot-spl.bin

    this is 'slightly safer' than using dd as sdimage-u-boot-patcher actually validates the image format (it look for signatures for a master boot record this can still be confused with a regular disk, and a signature for u-boot at around 8k. it would prompt that the image does not appear to be valid linux image if it either can't find the master boot record 1st sector and the u-boot signature at 8k. you can then stop the patch by pressing control-c or answering 'n' when prompted to continue. for a valid image, it also verifies that the u-boot bin file should not overwrite into the root partition

     

    and note this is caveat emptor (let the user beware, use at your own risk), there is no assurance if after all it fixes anything or break other things.

     

    u-boot-sunxi-with-spl1_5gfix.bin

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    I got past that  

    DRAM:  0 Bytes

    it is my own goof when I'm editing the u-boot codes 

    U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 19 2024 - 18:04:53 +0800)
sunxi_board_init
DRAM:sunxi_dram_initmemsize 2048 M
 1536 MiB
spl_board_init_r
Trying to boot from MMC1
NOTICE:  BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c
NOTICE:  BL31: Built : 23:11:18, Apr 18 2024
NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
NOTICE:  BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3
ERROR:   RSB: set run-time address: 0x10003
...

    the hack seemed to work

    next I'd need to learn u-boot,  ;)

     

     

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

     

     

    @usual user I think this is what happens, within the microprocessor soc, there is sram likely small 10s-100s of K bytes is likely, so the on board rom loads u-boot as a SPL (secondary program loader) also into s-ram.

    Then that u-boot needs to *clock the dram* (i.e. setup the dram so that it is actually working), determine dram size, configure dram to be up and running e.g. the 'rows and columns', setup memory mapping.

    All these in *sram* it did not even touch dram. Then that once everything is up, u-boot loads the *linux kernel* into dram, pass over the DTS and pass over the dram memory size and jumps into the kernel code, then linux boots up from there on.

     

    The trouble is that u-boot did not detect the DRAM and the codes is directly from the stem (mainline)

    https://source.denx.de/u-boot/u-boot

     

    I added a lot of debug() statements to trace execution flow and it seemed apparently that it did not even go into the dram initialization parts of the code. So I actually need help with the u-boot codes.

    I can't figure out why it is not working.

     

    All that BL31 etc is mainly for power management (e.g. shutdown / suspend etc), didn't seem to deal with DRAM

    https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/allwinner/sun50i_h616

     

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @voapilro, @bjorn, @electricworry I'm attempting to fix (at least a hack) the 1.5GB problem by attempting to build a custom u-boot to attempt to resolve the issue.

     

    The thing is the codes are pretty complex.

    https://docs.u-boot.org/en/latest/

    https://source.denx.de/u-boot

    but that actually I succeeded in building u-boot

     

    The trouble is I'm getting this: 

    U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800)
DRAM: 0 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c
NOTICE:  BL31: Built : 23:11:18, Apr 18 2024
NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
NOTICE:  BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3
ERROR:   RSB: set run-time address: 0x10003
ion

U-Boot 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800) Allwinner Technology

size=30, ptr=590, limit=2000: 26370
CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  0 Bytes

     

    So I literally need help with the codes, I'm doing pretty tedious debug etc with a 1.5G OPi Z3 board I bought for this purpose.

    if you run the 'original' images, that has a 'working' u-boot, it reads DRAM 2GB

    https://www.armbian.com/orange-pi-zero-3/

    still 'incorrect' but that accordingly there'd be fixes for it (in u-boot)

    https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/42

    https://gist.github.com/iuncuim

     

    The trouble as i try to trace where the calls are going is that it is not even going into the dram initialization codes in u-boot meant for H616/H618 to initialize and size up the lpddr4 dram.

    the codes are complex and I'd hope to get some leads there to attempt a solution. if a 'custom u-boot' can fix that, it'd at least help those who still only have 1.5GB boards to get Armbian running on it.

    By *replacing* the u-boot (practically the boot loader (and BIOS)) in the image or sd card.

    The image (and on the SD card) looks like this

     

    • 0-7 KB (unused/reserved) 
    • 8 KB - 1 MB u-boot
    • 1 MB - the rest of your sd card (this is your linux partition and Armbian proper (Debian or Ubuntu) lives here)

     

    u-boot does the bulk of the 'black magic' dealing with memory initialization and sizing, and then passing that across to linux during boot up.

    and linux uses the device tree (DTB, DTS) to configure the various devices uart, usb, sd card, leds, etc  etc and subsequently present various of them in /dev.

     

    a 'custom u-boot' apparently seem to be a most feasible 'solution' (hack) to at least get past the 1.5GB problem.

    it is quite easy to simply take the original image, and substitute one u-boot made to say the memory is 1.5GB.

     

     

     

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @voapilro orange pi's suffer from a few things, in particular poor software support and if you have an issue and goto their forums

    http://www.orangepi.org/orangepibbsen/

    you can see a lot of no responses, spams etc. and that for the 'official' images you have obtained, those are the relevant support forums as they are different from Armbian today.

    The images released from Orange Pi are linux kernel versions 6.1 which has yet been updated, nothing 'wrong' about it, but that linux version progress is relentless.

    in fact Orange Pi Zero 3 (and a little later Zero 2W) is supported out of mainline linux from kernel release 6.6, i.e. the DTS (device tree configuration) is released open sourced.

    And that the implementation from mainline is completely developed open sourced (by various talented individuals outside here in linux-sunxi i think, and subsequently the few of us here siezed on the opportunity and tried to make Armbian run on it, browse the earlier part of this thread and you see @Gunjan Gupta, @pixdrift, @Stephen Graf et.al working this, we also found that a lot of things are undocumented and it is a *miracle* that it is after all running (well) today.

    try getting a 1G / 2G / 4G board and run Armbian on it.

    https://www.armbian.com/orange-pi-zero-3/

    And I'd like to add that Armbian itself @Igor and team contributes in no small measure that makes this project possible (just consider catching up with the linux versions with so many platforms to carry), considering that there is no 'big company' (e.g. Intel, Rpi etc) behind this. it is all little contributors whom you see here.

     

    In this sense, the users of Armbian are the contributors and maintainers as well, a co-operative, practically the spirit of open source, if after all that economic model works.

    A good thing is that you can literally build ths whole thing (the images for your board from *source*)

    https://github.com/armbian/build

    you can configure all the kernel parameters for all you want for the build, edit the source codes, fix bugs, add features etc, there are many 'upstream' projects which include the linux kernel itself, u-boot, the distributions Debian / Ubuntu that contributes into the assembly, probably others as well, and the armbian build framework at this day is huge and complex considering the platforms (boards) that is supported.

    This probably also matter to 'security conscious' people who want to know every nut that is in there. But that it is up to you to make the effort to inspect that there are no 'holes' (e.g. trojans, backdoors, connecting to 'unauthorized' C2 (command and control) sites that you don't want etc). e.g. you can inspect and tweak all you want and afterwards run the build.

     

    And not least being open sourced means that it is nearly / practically *bare metal*, the codes work the metal (transistors / silicion / registers) directly, no blobs in-between.

    The trouble with blobs is your app is release to you as a binary, the driver is a binary (blob), then a new os (e.g. linux version, you can even consider windows) is released, now your binary app and or driver no longer works in the new os version (linux or windows), and you can use your device (e.g. mouse) as your new door stop. buy a new one and again more binaries , more device driver blobs.

     

     

     

    1

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @bjorn there are things I'm myself learning as well, hence won't be able to give an appropriate answer.

    btw, avoid using a source repository outside the armbian and mainline source tree.

    the main armbian build framework is here

    https://github.com/armbian/build

    and

    https://git.kernel.org

    for the 'real' mainline, I liked to ref Linus's git repository ;)

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

    Orange Pi Zero 3 and Zero 2W literally is directly supported out of mainline

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts?h=v6.8

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts?h=v6.8

    but that over here in Armbian, various contributors made further changes, go back pages in this thread and you would see them.

     

    But that the memory detection problem is not in the kernel.

    it is in u-boot and this is the original source the 'main stem'

    https://source.denx.de/u-boot/u-boot

    the 'black magic' for all that memory probing is in there

    https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads 

    // SPDX-License-Identifier: GPL-2.0+
/*
 * sun50i H616 platform dram controller driver
 *
 * While controller is very similar to that in H6, PHY is completely
 * unknown. That's why this driver has plenty of magic numbers. Some
 * meaning was nevertheless deduced from strings found in boot0 and
 * known meaning of some dram parameters.
 * This driver supports DDR3, LPDDR3 and LPDDR4 memory. There is no
 * DDR4 support yet.
 *
 * (C) Copyright 2020 Jernej Skrabec <jernej.skrabec@siol.net>
 *
 */

    https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_timings/h616_lpddr4_2133.c?ref_type=heads

     

    now here is the big story

    https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/38?u=ag1233

     

    accordingly, the memory probing logic (is pretty much a hack), does by writing values to memory and reading it back. But that for 1.5GB dram chips, the address *wraps around* to some *unknown address*.

    so that 1.5GB is *incorrectly* detected as 2GB, so as soon as thing boot, it crash/hang. But that the dram controller is *undocumented* hence we can't simply access registers in the dram chip and simply read the memory size from the dram chip (that is the normal way to get the dram size these days, but that allwinner h616/h618 choose to *hide* the documentation for the dram controller, so there is *no way* to get at it.

     

    Then by reasoning, the only way left is: to find some ways to pass the memory size to *u-boot* so that u-boot would take that value and initialize the *whole* system.

    this is a / the solution to 'fix' this '1.5GB problem' as once that procedure is known and documented, then one can use this image with practically *any arbitrary dram size* , you can boot any H616/H618 board by passing the correct memory size e.g. by means of a 'config' file (e.g. a DTS overlay)

     

    u-boot is the bootloader and practically the *BIOS* e.g. it does things that the kernel 'don't know' about.

    this is the extreme of the *state of the art*, armbian (along with u-boot) is completely *bare metal*, you control the metal (e.g. transistors, silicion) *directly*, nothing, no software blobs is sitting in between you and the metal.

     

    ---

    one 'other' way that is practically a *hack*

    https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads#L1348 

    static unsigned long mctl_calc_size(const struct dram_config *config)
{
	u8 width = config->bus_full_width ? 4 : 2;

	/* 8 banks */
	return (1ULL << (config->cols + config->rows + 3)) * width * config->ranks;
}

     

    it may be possible to compile a *custom u-boot*, and you change this code to return a memory size that you want, risky but I'd guess that may be what is floating out there in those binary blobs.

    The DTS (device tree source) file probably has other changes which is needed as well. imho, not quite a 'solution', but for things 'in the wild' you may instead be getting this hack in a binary blob.

    the *solution*, probably needs to be found in u-boot itself, that that may mean understanding the codes, and eventually a fix in u-boot itself to read the memory size say from a 'config' file (DTS?)

     

    all these ideas are for now just 'theory', it would take working this and testing it to see if e.g. simply return 1.5 GB in this function and writing the custom u-boot into the image literally gets the *whole system* up and running. 

     

     

     

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @bjorn it actually isn't necessary to make a new image from scratch, but that we'd need to figure out how to pass that 1.5GB memory size to u-boot, e.g. possibly a DTS overlay.

    then this means the procedure may possibly be:

    • write the existing published image to sd card
    • make a DTS overlay with the 1.5GB configured (a text file) - may need to be compiled into a DTB file
    • update armbianEnv.txt to use the edited overlay and save them on the image sd card appropriately

    on booting up, the os should then boot normally as do any other boards.

    Unfortunately, no one yet has probed this and document the steps to do this successfully.

     

     

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @bjorn the "1.5G issue" is a known issue, few of us has time to work on that for now.

    if you scroll a little back, you would find this comment

    The problem is in *u-boot*, the 'solution' is to pass a parameter to u-boot to tell u-boot the memory size of the board.

    None of us has tried it in the meantime, and among the options is to make a DTS overlay that has the memory size (not tested) and perhaps update armbianEnv.txt to load that overlay

    https://docs.armbian.com/User-Guide_Armbian_overlays/

    this has to be manually done for every board that u-boot cannot detect the memory size (because the dram controller is *undocumented*, the current memory probe is at best a hack, and it works for 'whole numbers' dram sizes 1G, 2G, 4G)

    You could give that a shot by exploring that solution, just that none (of us, including yourself) has worked it yet.

     

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @mc510 , Guests, et. al.

     

    yup this board is 'community maintained', i.e. by 'all (various) of us' including yourself here.

     

    There are some images linked at the board page (scroll to the bottom), currently 6.6.26 as seen (they could be new versions as things progress)

    https://www.armbian.com/orange-pi-zero-3/

     

    if you prefer a more recent 'bleeding edge' versions, try building the image yourselves:

    https://docs.armbian.com/Developer-Guide_Build-Preparation/

    That makes it really good as you can configure every kernel build parameter and change codes for the build as you deem fit yourselves.

    Jumping this hoop which is quite a high bar is also a necessary step to learn to maintain Armbian.

     

    None of us truly 'own' nor is committed to the (long term) maintenance, but that all (various) of us who owns the board (including yourselves) participate to test and work the board (e.g. use it) and chip in to fix issues as they get discovered (ourselves).

     

    I'd nevertheless give credits to @Igor, staff, contributors and friends, and various other contributors, moderators, you could find them if you browse this thread. For the relentless work as Linux versions progresses. This is one of the distributions that attempts to go up to the very recent mainline kernel releases (e.g. 6.8 recently), and not least for hosting this forum and the web site.

    Do consider sponsoring Armbian https://forum.armbian.com/subscriptions/ as that makes this project a co-operative, e.g. the users of Armbian are also its contributors and that this become more sustainable.

     

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @thuvasooriya wrote

    Quote

    not sure if these are supposed to happen. and yes i switched to unstable 6.7.10 kernel like a madman only to notice all the gpio harware configurations from armbian-config disappear.

     

    hi if you review this thread, the earlier comments, you would notice that there are quite varous discussions about DTS overlays for the gpio headers. noticably discussions from / between

    @Gunjan Gupta @pixdrift @Stephen Graf. Unfortunately, it seemed for now not all the changes have made it into the trunk.

     

    there are also various discussions about libgpiod and gpiod, hope those may help with access to the pins.

     

     

     

     

     

     

    1

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @thuvasooriya wrote

    Quote

    so it would be convenient for me if I could also setup the image to setup ssh and autologin on the first start. I've explored the forums only to find confusing and sometimes angry arguments. If anyone of you do care and have a method to make it work by modifying a file before boot or something, let me know. Sorry if this is a dumb or unpleasant question in any way.

     

    rather than to use HDMI and a monitor, I used a usb-uart (usb-serial) dongle

    that lets me connect over the serial console with the debug pins and I'm literally able to boot up in a serial console and (even) configure networking, i.e. I didn't even need network and can change the network interface configurations. That would also be a way to troubleshoot boot up problems if there is. I used the serial debug pins/console to configure networking as more than often, the default setup of network isn't what I want, and playing with the network interfaces will lock me out of ssh.

     

    After I've network configured over usb-uart, I can then ssh remotely into the device over the network.

    And that if you use dynamic IP, it may help to install and use avahi-daemon and avahi-tools (i.e. multicast DNS), I installed avahi-daemon on the OPi Z3 Armbian board so that I can find it from my main linux box using avahi-browse -a , and that ssh into there could be simply ssh orangepizero3.local  

     

    that's a way to practically use it headless , in fact, after I've setup things, it is now my  WiFi AP on the desk.

     

     

    1

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @electricworry I can't remember where I saw comments about the HDMI sound issues, but that it is more than likely that HDMI and even graphics could be *undocumented* and *reverse engineered* (possibly by the talented people on the linux sunxi https://linux-sunxi.org/Main_Page and such efforts), it could be an up hill task to reverse engineer HDMI sound in particular considering the complexity of such interfaces.

     

    there is apparently some related work, thread

    and thanks to @Nick A for researching and sharing various info, there may be some hints as to what needs to be done.

    it seemed quite possible to patch dts files to get hdmi sound support, but it is just wild guesses, you would need to review the info.

     

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @thuvasooriya

    while I do not have an OrangePi Zero 2W (I only have Zero 3), it would seem to me that Zero 2W is basically Zero 3 less the onboard Ethernet. I'm not sure what else is different where 'compatibility' goes. Ethernet for Zero 2W is on the expansion board that Orange Pi sells, hence if you want ethernet, you may want to purchase the expansion board to experiment. No promises if it'd works though.

     

    It'd seem to me that OrangePi is basically selling on the 'form factor' difference, and 2W being smaller won't fit the bulky ethernet RJ45 connector and the phy chip.

     

    But that if you actually try that, it'd be good to report in a comment if it (expansion board and ethernet) works or otherwise.

     

    As well if you used the Zero 3 images, e.g. from 'original'  image https://www.armbian.com/orange-pi-zero-3/ , if you scroll down to the bottom you woul see the links to the images and torrents.

    It would be good to feedback in a comment about what works or not etc.

     

    I went straight with Zero 3 initially as I wanted both ethernet and wifi, those are built on board for Zero 3 and hence that. 

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @boorch wrote

    Quote

    Hello! Just received a OrangePi Zero 2W and read Zero3 images work with this, so gave your build a try. Looks okay for now but I've yet to try any desktop environment etc. I'll post updates.

    Btw my board has H618 cpu or some reason and I've read OrangePi Zero 2W supposed to have H616?

     

    Hi thanks for trying it out, I feel somewhat embarrassed that I've not tried it out myself.

     

    In terms of the release the vendor Orange Pi (Xun Long) actually first released the Zero 3 then subsequently Zero 2W they are both based on H618

     

    do post a comment to say what works or not. 

     

    If your are trying my image, that is based on a minimal Debian Bookworm build, I did that mainly to save up on the image size/footprint.

    And also that I'm using that mainly as a wifi hotspot, and a desktop environment bring along too much baggage add gigabytes of storage use, consume a lot of memory and possibly slow down my intended use.

     

    To go from minimal to a desktop environment, I googled and found this page:

    https://wiki.debian.org/DesktopEnvironment

     

    as documented you can try  

    > apt show task-desktop

Package: task-desktop
Version: 3.73
Priority: optional
Section: tasks
Source: tasksel
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Installed-Size: 6,144 B
Depends: tasksel (= 3.73), xorg, xserver-xorg-video-all, xserver-xorg-input-all, desktop-base
Recommends: task-gnome-desktop | task-xfce-desktop | task-kde-desktop | task-lxde-desktop | task-gnome-flashback-desktop | task-cinnamon-desktop | task-mate-desktop | task-lxqt-desktop, xdg-utils, fonts-symbola, avahi-daemon, libnss-mdns, anacron, eject, iw, alsa-utils, sudo, firefox | firefox-esr, cups
Download-Size: 1,036 B
APT-Sources: http://mirror.sg.gs/debian bookworm/main arm64 Packages
Description: Debian desktop environment
  
> apt show task-gnome-desktop
Package: task-gnome-desktop
Version: 3.73
Priority: optional
Section: tasks
Source: tasksel
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Installed-Size: 9,216 B
Depends: tasksel (= 3.73), task-desktop, gnome-core
Recommends: gnome, synaptic, libreoffice-gnome, libreoffice-writer, libreoffice-calc, libreoffice-impress, libreoffice-help-en-us, mythes-en-us, hunspell-en-us, hyphen-en-us, network-manager-gnome
Download-Size: 1,184 B
APT-Sources: http://mirror.sg.gs/debian bookworm/main arm64 Packages
Description: GNOME

    ^ I think that is the package to install the desktop environment

     

    for instance to install gnome desktop it could be

      

    > sudo apt install task-gnome-desktop
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  accountsservice acl adwaita-icon-theme apache2-bin apg appstream apt-config-icons
  at-spi2-common at-spi2-core baobab bluez-obexd bubblewrap colord colord-data dconf-cli
  dconf-gsettings-backend dconf-service desktop-base desktop-file-utils dictionaries-common
  emacsen-common eog evince evince-common evolution-data-server evolution-data-server-common
  folks-common fonts-quicksand fonts-urw-base35 gcr gdisk gdm3 geocode-glib-common
  gir1.2-accountsservice-1.0 gir1.2-adw-1 gir1.2-atk-1.0 gir1.2-atspi-2.0 gir1.2-evince-3.0
  gir1.2-freedesktop gir1.2-gck-1 gir1.2-gcr-3 gir1.2-gdesktopenums-3.0 gir1.2-gdkpixbuf-2.0
  gir1.2-gdm-1.0 gir1.2-geoclue-2.0 gir1.2-gmenu-3.0 gir1.2-gnomebluetooth-3.0
  gir1.2-gnomedesktop-3.0 gir1.2-gnomedesktop-4.0 gir1.2-goa-1.0 gir1.2-graphene-1.0
  gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 gir1.2-gtk-3.0 gir1.2-gtk-4.0
  gir1.2-gtksource-4 gir1.2-gweather-4.0 gir1.2-handy-1 gir1.2-harfbuzz-0.0 gir1.2-ibus-1.0
  gir1.2-javascriptcoregtk-4.1 gir1.2-json-1.0 gir1.2-mutter-11 gir1.2-nm-1.0 gir1.2-nma-1.0
  gir1.2-notify-0.7 gir1.2-pango-1.0 gir1.2-peas-1.0 gir1.2-polkit-1.0 gir1.2-rsvg-2.0
  gir1.2-soup-3.0 gir1.2-upowerglib-1.0 gir1.2-webkit2-4.1 gjs gkbd-capplet glib-networking
  glib-networking-common glib-networking-services gnome-backgrounds gnome-bluetooth-3-common
  gnome-bluetooth-sendto gnome-calculator gnome-characters gnome-contacts gnome-control-center
  gnome-control-center-data gnome-core gnome-desktop3-data gnome-disk-utility gnome-font-viewer
  gnome-keyring gnome-logs gnome-menus gnome-online-accounts gnome-session gnome-session-bin
  gnome-session-common gnome-settings-daemon gnome-settings-daemon-common gnome-shell
  gnome-shell-common gnome-shell-extensions gnome-software gnome-software-common gnome-sushi
  gnome-system-monitor gnome-terminal gnome-terminal-data gnome-text-editor gnome-themes-extra
  gnome-themes-extra-data gnome-user-docs gnome-user-share grilo-plugins-0.3
  gsettings-desktop-schemas gstreamer1.0-gl gstreamer1.0-gtk3 gstreamer1.0-packagekit
  gstreamer1.0-pipewire gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-x
  gtk-update-icon-cache gtk2-engines-pixbuf gvfs gvfs-backends 

...

Suggested packages:
  apache2-doc apache2-suexec-pristine | apache2-suexec-custom www-browser colord-sensor-argyll
  gnome | kde-standard | xfce4 | wmaker ispell | aspell | hunspell wordlist eog-plugins
  nautilus-sendto unrar evolution fonts-freefont-otf | fonts-freefont-ttf fonts-texgyre orca
  libpam-fprintd libpam-sss libpam-pkcs11 gstreamer1.0-pulseaudio pkexec gnome usbguard
  gir1.2-malcontent-0 gir1.2-telepathyglib-0.12 gir1.2-telepathylogger-0.2

...

Recommended packages:
  xserver-xephyr fonts-noto-color-emoji cups-pk-helper gnome-remote-desktop power-profiles-daemon
  rygel | rygel-tracker malcontent-gui network-manager-gnome realmd firefox-esr | firefox
  | chromium | chromium-browser | epiphany-browser | gnome-www-browser
  libproxy1-plugin-networkmanager low-memory-monitor gnome-keyring-pkcs11 iio-sensor-proxy pkexec
  bolt chrome-gnome-shell ibus switcheroo-control gnome-shell-extension-prefs fwupd
  nautilus-extension-gnome-terminal gnome-accessibility-themes aspell-en | aspell-dictionary
  | aspell6a-dictionary libaacs0 libcanberra-gtk3-module enchant-2 libgdk-pixbuf2.0-bin
  libgphoto2-l10n fonts-droid-fallback libgtk-3-bin libgtk-4-bin usbmuxd libmtp-runtime

...

0 upgraded, 584 newly installed, 0 to remove and 32 not upgraded.
Need to get 301 MB of archives.
After this operation, 1,218 MB of additional disk space will be used.
Do you want to continue? [Y/n]

     

    I stopped and answered 'n' at the prompt, if you have the space, you could try that out to see if that works to install and setup a full desktop environment

     

    note that I've not tried the above, and there are also other selections / desktop environment that you can choose 

    Recommends: task-gnome-desktop | task-xfce-desktop | task-kde-desktop | task-lxde-desktop | task-gnome-flashback-desktop | task-cinnamon-desktop | task-mate-desktop | task-lxqt-desktop, xdg-utils, fonts-symbola, avahi-daemon, libnss-mdns, anacron, eject, iw, alsa-utils, sudo, firefox | firefox-esr, cups

     

    e.g. there are the above of task-xxx-desktop which I'd think installs the respective desktop environment.

     

    After installing 

     sudo systemctl set-default graphical.target

    to make sure that the desktop environment starts up on reboot

     

    if you do try that out, do leave a comment on your experiences with it and how it works. That may help others wanting to do the same. post a screenshot :)

     

    another page found from a google search for a reference

    https://www.layerstack.com/resources/tutorials/How-to-install-Graphical-User-Interface-GUI-for-Debian-11-Cloud-Servers

    ^ there are other stuff there e.g. enable root login etc

     

     

    0

    Is Linux not portable enough ?

    in Beginners

    Posted

    Quote

    - why don't the Orange Pi 3B or Quartz 64B Armbian images, with the same MCU, don't work on the Radxa Zero 3W ? Aka, shouldn't an OS be portable ? I'm not expecting such of Windows, but I did expect it from Linux

     

    SBC and embedded world is an absolute jungle, take for instance Orange Pi Zero 3 (just as an example) , it has an on board flash chip which can store a boot rom. the kernel bootloader u boot https://en.wikipedia.org/wiki/Das_U-Boot

    can either: 

    • boot from a normal sd card (and this depends on the vendor's boot rom, which loads the first few sectors on the sd card (which is u-boot itself) and jumps to u-boot which in turns boots linux (no uefi)
    • u-boot can be installed in that boot rom become the BIOS ! itself, and u-boot can boot linux *directly*
    • u-boot can practically emulate any kind of booting scheme (including the vendor's original, uefi etc) but that requires u boot to replace the vendor's boot rom (deemed a risky activity, it may brick the board)
    • and that every different board can have different hardware configuration (a LED on a different pin or configuration (e.g. pull up or pull down) make a different board (with everything else being the same) !)

     

    the above already constitute M different boot configurations and N different boards, with just 8 pins for LEDs you can make a combination of 8! 8x7x6x5x4x3x2x1 permutations x 2 configurations (pull up or pull down) ~ 80640 different boards for the same board. so for sanity and practicality, a device tree overlay is made for a *fixed* board. e.g. Orange Pi Zero 3

     

    and that this project is practically supporting M socs x N boards x X configurations x Y distributions (debian / ubuntu to name just 2, wrong not just 2 within that 2 there are different *releases* ) x Z kernels  (legacy / stable / bleeding edge) and that is not just 3 versions, oh and just UEFI alone has another N different versions https://uefi.org/specifications 😛

     

    btw u-boot practically achieved the *holy grail* (look ma no BIOS)

    http://www.haifux.org/hebrew/lectures/111/img0.html

    it is as hard core and bare metal as one can be.

     

    it isn't about OS being 'portable' per se, than it is about what you see in each figment (i.e. a particular board with a particular config) is just one single very narrow endpoint in the sea of infinite permutations.

    0

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    @Igor, @Gunjan Gupta thanks for all that effort, I'm sure many would patiently, and eagerly wait for that :)

     

    and an ad for Armbian, for/to new users who have stumbled into this thread

    https://www.armbian.com/donate/

    those who are using Armbian e.g. on Orange Pi Zero 3, do consider 'sponsoring' Armbian (e.g. with a subscription etc). 'donate' is actually an incorrect term for that, but there is no equivalent.

    open sourced projects like such takes a lot of effort, but that unlike commercial SASS (software as a service) etc, there is practically no feasibility to put a *paywall* as do most other commercial providers / software.

    Some providers resorted to *close source*. And most will *detest* this as imagine that you need to fix a bug that *blink a led* on your pin header, that'd means *no access*, *cannot be done*.

    embedded *intrusive* ads would be a next wors(e,t) thing

     

    --- 

    on another topic, about technicals:

    i look at some 'solutions' for patches, i've not found practically anything that 'works'

     

    the problem of patch sets against multiple targets (different patch set applies) and version, and between multiple different *contexts*, between 'release' upgrades

    and that the patch sets in themselves has their own dependencies on the core source codes (sometimes even modules in the source codes become recursive patch-on-patch dependencies) and between patches.

     

    something like gerrit code review,

    *does not address the issue*

    https://www.gerritcodereview.com/about.html

    https://gerrit-documentation.storage.googleapis.com/Documentation/3.9.2/intro-rockstar.html

    that would instead cause stalls in development workflow as we have n different boards with different distribution targets with different *boot loaders* and hardware and configuration (e.g. a led on a different pin  makes a *different board* even if every thing else being the same) this conundrum has never been fully addressed even today with the device tree. We need 'dynamic device tree' that can literally *change on the fly* after things booted up, because you can hot plug anything on the pin headers.

    the whole development would practically *stop* as the different *boards* would have *no (or very few) reviewers*

     

    then I looked at stackedgit

    https://stacked-git.github.io/guides/usage-example/

    https://stacked-git.github.io/guides/tutorial/

    https://github.com/stacked-git/stgit/

    looks promising

    but again that would take time and effort to explore and it is likely not adequate to address this same issue.

     

     

     

     

    0

    Orange Pi Zero 3, WIFI AP mode: protocol 0000 is buggy, dev wlan0

    in Allwinner sunxi

    Posted

    the 'community' one is here, scroll right to the bottom

    https://www.armbian.com/orange-pi-zero-3/

    and the kernel version is at least 6.6 and above

     

    apparently someone has seen the same , so it isn't 'new'

    https://www.linux.org/threads/protocol-0000-is-buggy-dev-wlan0.42774/

     

    if one google around the web one may stumble into this

    https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

     

    it could mean a device you have is sending out goofy packets that are not regular IP packets. the normal protocols used are usually TCP, UDP and ICMP.

     

    1

    Orange Pi Zero 3

    in Allwinner sunxi

    Posted

    just like to mention that I managed to run a build for Orangepizero3

    Armbian-unofficial_24.5.0-trunk_Orangepizero3_bookworm_edge_6.7.10_minimal
    the kernel is 6.7.10 

    the build managed to run to completion

    the image is completely untested 

    -rw-rw-r-- 1 armbian root  1413480448 Mar 20 02:38 Armbian-unofficial_24.5.0-trunk_Orangepizero3_bo
okworm_edge_6.7.10_minimal.img
-rw-rw-r-- 1 armbian root         213 Mar 20 02:38 Armbian-unofficial_24.5.0-trunk_Orangepizero3_bo
okworm_edge_6.7.10_minimal.img.sha
-rw-rw-r-- 1 armbian root       19756 Mar 20 02:38 Armbian-unofficial_24.5.0-trunk_Orangepizero3_bo
okworm_edge_6.7.10_minimal.img.txt

     

    And I'm not sure if it'd even work. It is not uploaded anywhere,

     

    For this build as OrangePi Zero 3 is deemed csc, you need to select the experimental unsupported builds to see the boards being listed.

    I ran the build just to see that the build completes after all, having no time (yet) to run tests with that.

    -- update it was TLDR (too late didn't read) then

    ok it is here, and remember *untested* (it is not known if it'd work if at all), *unofficial* *unsupported* use at your own risk

    https://www.mediafire.com/file/bym559l94sn8xyd/Armbian-unofficial_24.5.0-trunk_Orangepizero3_bookworm_edge_6.7.10_minimal20240320.7z/file

    this (file) won't be there on the permanent basis

    it'd seem @Igor is moving Armbian to 6.8 (hey that's just 9 days 'old' https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tag/?h=v6.8,  as of this comment)

    that's a good thing, and thanks :)

    this linked image would be a pre-6.8, if it works.

     

    other fun stuff

    https://www.omgubuntu.co.uk/2024/03/linux-kernel-6-8-new-features

    https://www.zdnet.com/article/linux-kernel-6-8-offers-some-exciting-new-features-and-fixes-all-over/

    https://www.theregister.com/2024/03/04/linux_6_8_rc_7/

    https://www.phoronix.com/review/linux-68-features

    https://lore.kernel.org/linux-kernel/CAHk-=wiehc0DfPtL6fC2=bFuyzkTnuiuYSQrr6JTQxQao6pq1Q@mail.gmail.com/T/

     

    0

    no release file

    in Beginners

    Posted

    i'd be kind of 'off topic' here, armbian is somewhat in the 'fast lane', 'bleeding edge'

    https://www.debian.org/releases/

    recently when we worked on Orange Pi Zero 3 

    we actually jumped right into bookworm, had there been something more 'bleeding edge' that may be it ;)

    and that we jumped into 6.6 kernel (as it is about the 1st kernel that has support for Orange Pi Zero 3 on allwinner H618 cpu, and that actually as development progress, it actually advanced to 6.7, 6.8 etc.

    Today, I just installed Ubuntu jammy from Ubuntu, only to find that that is 6.5 !

    and that even orange pi's 'official' image for Orange Pi Zero 3 gets 'left behind' at 6.1 :)

     

    I'd suggest to try upgrading to the 'latest'  debian (bookworm?) image, it may take quite a bit of  'reinstall' though. And that everything is 'brand new', 'bleeding edge' there.

    the python 3 version is 3.11, that in ubuntu jammy is 3.10 ! ;)

    that said, there are bound to be some broken bones left around somewhere, it is 'under construction'  (all the time) ;)

     

    oh some fun stuff, 6.8 is  9 days old, who knows that might be the new Armbian kernel ;)

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

     

     

    0

    Orange Pi Zero 3

    in Beginners

    Posted

    it is there in 'community releases' 

    https://www.armbian.com/orange-pi-zero-3/

    scroll to the bottom of that page

    get a 'whole number' (1GB, 2GB, 4GB) dram size board, for 1.5GB there it is still under 'research', you + (community) need to find a way to tell u-boot (the bios and boot loader) that the board is 1.5GB

    once that is figured out, it is possible to practically use any board with any amount of memory.

    0
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept