Orange Pi Zero 3

[thuvasooriya]

can someone confirm whether alwinner h616 and h618 have compatible pin configurations or not

[TRay]

I'm using Armbian an OZPI v3 beta with the kernel:

 

Linux localhost 6.6.23-current-sunxi64 #3 SMP Tue Mar 26 22:22:53 UTC 2024 aarch64 GNU/Linux

 

In armbian-config UART5 is enabled

 

 

and:

ls -al /dev/ttyS5
crw-rw---- 1 root dialout 4, 69 Mar 31 09:49 /dev/ttyS5

 

I am trying to use communication via serial port UART5 /dev/ttyS5 but without success. When I try to set parameters for serial port

 

stty -F /dev/ttyS5 9600 cs8 -cstopb -parenb
stty: /dev/ttyS5: Input/output error

 

When try to send command:

 

echo "AT+VERSION" >/dev/ttyS5
-bash: echo: write error: Input/output error

 

Has anyone successfully used communication via UART5 on OZPI v3?

[8p8c]

Hi all,

 

LONG POST WARNING!!!

 

I have been trying to get an SPI TFT screen to work with the OPI Zero 3.

To that end, the first goal was to get SPI output confirmed working on physical pins 19, 21, 23 and 24.

I have compiled 6.7.10-edge-sunxi64 from the build environment.

 

The actual board is gold screen printed as a "Waveshare Spotpear 3.2" which may well be a clone, as the chipset is marked HR2046, i.e.

 an XPT2046 -ish which is, possibly a clone of the TI ADS7846, some or all of this sentence may be incorrect.

 

To get the overlays to display in armbian-config it is required  to name the overlays with the chipset prefix - i.e. for Opi Zero 3, this would be sun50i-h616-myoverlay.dtbo - bearing in mind the chipset for the zero 3 is actually h618, but I am aware discussions are ongoing as is the work, for which many thanks.

 

6.x Kernel SPI on H618:

 

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

 

This allows compilation for the Zero 3:

./compile EXPERT=”yes”

 

Remember to select the drivers for TFT displays in the config, I say this (not remembering exactly where they are buried) because it may be the case that they cannot be easily added after the fact - don't shoot me - I read it somewhere in my travels plus it was easier for me.

 

Alter and compile the chosen DTS files to DTBO

Set up the ENV and copy the DTBO files to the device.

 

If activated overlays have parameters marked as “Required”, those parameters have to be set to proper values

U-boot does not support overlay parameters, so changing values is implemented via executing a "fixup" script after all overlays were applied. This script uses environment variables loaded from /boot/armbianEnv.txt to change the live tree using fdt command.

 

How to work out the numbers:

 

// Select pins: 1st number = pos. of letter in the alphabet - 1

// 2nd number = pin number

// 3rd number = DON'T CHANGE! (1 = ACTIVE_LOW, 0 = ACTIVE_HIGH)

// Example: PA2 = <&pio 0 2 1>

// PC7 = <&pio 2 7 0>

 

The dtc is used to decompile/recomple the DTS to DTBO and vice versa, the exception being user created overlays, it is fully documented so not repeated here, this can be added via the "sudo armbian-add-overlay" command - which compiles and places .dts files into /boot/overlay-user/

 

Documentation is here: https://docs.armbian.com/User-Guide_Allwinner_overlays/

https://docs.armbian.com/Hardware_Allwinner/

https://github.com/armbian/sunxi-DT-overlays

 

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt

 

https://github.com/rm-hull/spidev-test is invaluable for testing.

 

The following commands have also proved useful:

 

sudo /bin/bash -c "cat /sys/kernel/debug/pinctrl/*/pinmux-pins"

sudo cat /sys/kernel/debug/gpio

 

I also downloaded and installed the Orangepi wiringOP:

 

Download the code of wiringOP

orangepi@orangepi:~$ sudo apt update

orangepi@orangepi:~$ sudo apt install -y git

orangepi@orangepi:~$ git clone https://github.com/orangepi-xunlong/wiringOP.git -b next

Note that the source code needs to download the code of the wiringOP next branch, please don't miss the -b next parameter.

 

According to initial loopback testing before adding my own overlays (apply a jumper between MISO and MOSI) , via "sudo ./spidev_test -v -D /dev/spidev1.0" - this interface is functioning as expected.

 

The Opi Zero 3 seems to have two SPI busses, and the devices on said bus need to be targeted correctly (0 or 1) hence what I think is correct, which is to add a CS (chipselect) overlay.

 

Results of  gpio readall (screenshot as copy paste mucks up the formatting):

 

 

Next step was to add the dtbo files and activate via armbianEnv.txt

 

verbosity=1
bootlogo=true
console=both
disp_mode=1920x1080p60
overlay_prefix=sun50i-h616
overlays=spi-ads7846 spi-double-spidev-cs spi-spidev
param_spidev_spi_bus=1
param_spidev_cs=0
rootdev=UUID=22c98ce5-14a8-483f-b440-35690209c856
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

 

I have added my own dtbo files modified from the ones in https://github.com/armbian/sunxi-DT-overlays - which are attached.

The error I am getting appears to be interrupt related, so my question is - how are the interrupts assigned, or more directly what do I put in place of  PA7 which appears to be the issue the first three errors notwithstanding as I believe from reading about other OrangePi devices, the board .dtb may need looking at?

 

dmesg | grep spi
[    1.840708] sun6i-spi 5010000.spi: Error applying setting, reverse things back
[    1.840994] sun6i-spi 5011000.spi: Error applying setting, reverse things back
[    1.849460] sun6i-spi 5010000.spi: Error applying setting, reverse things back
[    1.857263] spi-nor spi0.0: supply vdd not found, using dummy regulator
[    1.872754] spi-nor spi0.0: spi-nor-generic (16384 Kbytes)
[    7.127377] SPI driver ads7846 has no spi_device_id for ti,tsc2046
[    7.127404] SPI driver ads7846 has no spi_device_id for ti,ads7843
[    7.127409] SPI driver ads7846 has no spi_device_id for ti,ads7845
[    7.127413] SPI driver ads7846 has no spi_device_id for ti,ads7873
[    7.132367] sun50i-h616-pinctrl 300b000.pinctrl: pin PA7 already requested by spi1.0; cannot claim for 300b000.pinctrl:7
[    7.132399] ads7846 spi1.0: failed to request pendown GPIO
[    7.132405] ads7846: probe of spi1.0 failed with error -22

 

There also seems to be a bit of a debate about the <compatible> tag and what should or should not be in it.

 

I am fast approaching the end of my knowledge on this, as this is a first post, please be gentle! This is an attempt to document the fact that due diligence has been applied as much as possible, it might help others, and if nothing else, it has imbued me with admiration for those who have got this board to the state of functionality that we can enjoy today. If anything is hideously wrong, please guide (gently) as I know there are people here who have far greater detailed knowledge than I.

 

Main takeaway - SPI works - needs tweaking, help and guidance appreciated.

sun50i-h616-spi-double-spidev-cs.dts sun50i-h616-spi-ads7846.dts

Edited March 31 by 8p8c

[TRay]

 

I try to find where is problem with UART5

 

dmesg |grep serial
[    1.306076] sun50i-h616-pinctrl 300b000.pinctrl: pin-224 (5000000.serial) status -517
[    1.306095] dw-apb-uart 5000000.serial: Error applying setting, reverse things back
[    1.306231] sun50i-h616-pinctrl 300b000.pinctrl: pin-226 (5001400.serial) status -517
[    1.306249] dw-apb-uart 5001400.serial: Error applying setting, reverse things back
[    1.333692] 5000000.serial: ttyS0 at MMIO 0x5000000 (irq = 296, base_baud = 1500000) is a 16550A
[    1.334902] 5001400.serial: ttyS1 at MMIO 0x5001400 (irq = 297, base_baud = 1500000) is a 16550A

 

dmesg don't show ttyS5 only ttyS0 and ttyS1 so UART5 on PIN26 header is ttyS1 not ttyS5 ?

 

[isy]

I am about to order 3x units of Orange Pi Zero 3 4GB, and checked that this community work is on going. 
Thanks again guys!

your efforts here made me want to sign up and Subscribe! (or donate if you want to call it that way) lol

[Guest]

Purchased an Orange Pi Zero 3, thought I'd be informed at check the limitiation this device has in linux so far. Was sorely met with disappointment when I checked the official Orange Pi images and looked at the current linux kernel support overall in other distros.

However, I've managed to find Armbian and have been so excited to recieve the SBC now thanks to the selfless work of you guys on this forum and on github do. Thanks for much, I look forward to testing Armbian for the first time.
Never owned an SBC, only messed with Arduinos and ESP32s, so I've made sure to research as much about the kernel and Armbian itself and what's been implimented, I'm excited to see the progress you've made, and the mainline kernel have made in their newest version. (6.8-6.9)

Looks like I'll be using this for a lot more than just the previously only intended RTL-TCP server and weather station. Did not expect there would be progress all over the board yet being this new, it seems like this has better support than the Orange Pi 2 and Zero2 now?! 😀 I suspect you could run Moonlight on this for streaming? I would love to set this up as a portable gaming rig for my partner, we already use a laptop that streams from a virtual machine on my server & GPU passthrough. I heard ethernet had issues, will this interrupt the stream or has this been fixed?

Nice work, I'd love to help out in the community at some point soon once mine has arrived.  Even if it's just for testing.
Much love from the UK! 😘

Edited April 5 by Joshua Higgins

[jimg]

On 3/31/2024 at 11:33 AM, TRay said:

dmesg don't show ttyS5 only ttyS0 and ttyS1 so UART5 on PIN26 header is ttyS1 not ttyS5 ?

Yes, that appears to be correct. 

 

I couldn't figure out why the UART on the p26 pin header wasn't working.  Found your post and tried ttyS1 instead.  Working beautifully now.  Thanks 🙂.

[TRay]

Yes, I confirm the OZPI v3 UART5 described in the original documentation and as /dev/ttyS5 in ArmBian it is marked as /dev/ttyS1 and works correctly

[mc510]

Wondering if there is someplace that I can look to see status and plans for Zero 3 support? Personally I'm most interested in keeping an eye on any progress towards analog audio support, and wifi improvements, but I'd be interested to see any developments as they happen. Or maybe it's the case that now that Zero 3 is up and running, with most functions working, it doesn't have anyone continuing to work on it?

[SteeMan]

@mc510 You may know this but I'm adding this in case you or others reading this thread don't.  This board isn't supported by Armbian.  With limited resources Armbian can only support a limited number of boards with their resources.  This board is a Community Maintained board, which means that it is up to the people in these forums to submit PRs to maintain and or improve support for this board.  What often happens is that no one contributes back to the community and over time Community boards degrade in quality until they no longer build in which case they are set to end of life status.  And removed.

For the official description on Supported vs Community Maintained see:

https://docs.armbian.com/User-Guide_Board-Support-Rules/

[ag123]

@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.

 

[bjorn]

 The 1,5 Gb version does not boot. Or at least does not turn on the screen using the Armbian 6.6.26 Jammy image.

I thought firs the board was broken but it does boot on the Orange Pi OS.

 

(The 1,5 Gb version might be special somehow as the Orange Pi OS had separate Image for the 1,5 Gb  variant)

[Werner]

1 hour ago, bjorn said:

might be special somehow as the Orange Pi OS had separate Image for the 1,5 Gb  variant

Probably Armbian also needs a dedicated image for that or some dirty hackjob to allow both variants to boot. Anyway I don't think somebody will waste time on this task...

[ag123]

@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.

 

[bjorn]

Thanks @ag123

 

Sadly I don't think I have the skill set to tinker it or make my self image to put on it.

 

But what you say is almost certainly correct since I went into the Orange Pi OS build tool chain and looked and it seemed to be just switch.

 

I have for now put Debian on it which seems to work very well. (Though I have bit of a backdoor trust issues with OS coming directly from Orange Pi)

 

But I will keep eyes open if image will be made at some point then I can least help test it.

Edited April 16 by bjorn

[ag123]

@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.

 

 

[bjorn]

I guess the dtb file for it is here:

 

https://github.com/leeboby/opizero3-uboot-dtb

 

I guess that does not help without the DTS source file ?

[ag123]

@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. 

 

 

 

[voapilro]

Hi! I just bought two Orange Pi Zero 3 with 1.5 GB RAM, and I think they have same memory size detection mentioned earlier in this thread. I am looking for a quick solution, as I do not have much time to return them if it is not possible to fix them. I installed Debian Bookworm for 1.5 GB board with kernel version 6 and without GUI. Apparently it was working well, but sometimes rebooting via SSH just powered off. I did not see anything wrong in dmesg and syslog, but after plugging in a console cable I could see that when reboot failed, u-boot detected 3 GB of memory. Even more, next power cycle boots board with 3 GB memory detected. I did not have time to stress boad, but this issue will probably make board unstable appart not being able to reboot all the times. I attached console output with some comment for details.

 

Any help would be welcome. I you want, I can provide more information or make more tests, in order to look for a solution. Thanks in advance for your help.

commented-boot-20240417.out

[electricworry]

@voapilro I can offer to help but I might not be able to help at the speed you desire; it might take me a few days to have time to offer some patches. You may find that if you power on the board a number of times you will observe correct and incorrect memory counts, and having an approximate percentage of how often it's wrong would be interesting.

 

My direction of attack would be to look at the vendor BSP and check what's different between the 1.5GB build they offer and the build for 1GB/2GB/4GB. The difference should provide a clue to what might need patched and whether something might be missing from the Armbian patch collection. (Out of interest have you tried the vendor build, and if so does it exhibit the same problem? Does it fail with the same percentage?)

 

I'm not working directly in Armbian with the Orange Pi Zero 3 but have been working on a yocto layer which incorporates patches collated by @Nick A.

[voapilro]

Thanks @electricworry for your help! I installed an official Debian build for Orange Pi Zero 3 with 1.5GB, downloaded from here and named Orangepizero3_1.0.2_debian_bookworm_server_linux6.1.31_1.5gb.7z. I coud see that there is no official Armbian release, just an unofficial community release not tested by Armbian, so I did not try it. I could not find any other trustable build I could try, so please let me kown if there are other options. Regarding "vendor build" you mentioned, are you talking about a build provided by seller? If that is the case, I do not think they can provide it, they just sell the boards.

 

Regarding the number of times I observe correct and incorrect memory size, it is difficult to say. I rebooted and power cycled the boards a lot of times since last monday, that is when I receved them, and it is quite ramdom. Sometimes it is easy to get and incorrect memory size once and again, other times is more difficult, and I do not see a pattern. I have both boards powered on all the time, and from time to time I reboot or power cycle them. Anyway, I would say that memory size is incorrect 1 of 4 times in all, but it is just an overall perception.

 

I really like these boards, and 1.5GB memory size is the best option for my purposes. I bought two other Orange Pi Zero 3  with 1GB memory two months ago and they are working well. I am using them for creating a VPN, and they are more than enough. However, I would like to install some network management software that should fit in 1 GB memory, but I prefer to have some spare memory, just in case. I have being using some Raspberry Pi for several years, and I am happy with them, but prices are higher year by year, so Orange Pi could be a good alternative.

[SteeMan]

54 minutes ago, voapilro said:

I have being using some Raspberry Pi for several years, and I am happy with them, but prices are higher year by year, so Orange Pi could be a good alternative.

A significant reason that the Raspberry Pis are more expensive is that the manufacturer actually invests time and resources into the underlying software.  OrangePi does not.  OrangePi takes advantage of the open source community hoping they can get software support for free without contributing much if anything to that process.  There is a reason that OrangePi boards are not generally supported by Armbian, and lack of manufacturer support is a big reason.

 

So that means that if you want good software to run on OrangePi boards, then OrangePi expects you to do the work.  And that is a lot about what this thread in the forum is about - the community trying to support these boards.

[livingcreative]

Hello all.

 

I can say that now I'm almost happy owner of the Orange Pi Zero 3 board. It took me weeks of googling to get to this awsome thread. Links from official OPi site lead to outdated images where many things didin't work as expected and with broken graphics acceleration. Finally I found armbian and its latest builds for Orange Pi Zero 3 board with working graphics at least. So, first of all, thanks to all people who contributed to this builds, it's an awsome work.

 

I'm total noob in Linux, so I can't do much help here, however, if something needs testing with this board (OPi Zero 3, 2Gb RAM) I'll try to help.

 

Inspite of being able to make my own toy OS for x86 platform I struggle with Linux as it is seems very complex to me so I came here for help or at least right direction.

My current goal with Zero 3 board is to get very minimal Linux build which includes:

- all CPU cores workig and ability to run single graphics application without desktop environment at all

- working 3D acceleration for smooth graphics

- working sound (either built in or through i2s interface, preferably)

- working GPIO/SPI/UART for communicating with other peripherials built with 8-bit MCUs like ATmel 8-bit chips

 

Currently I'm just learning how to build such kind of Linux images. I've already tried buildroot and "default" build didn't work for me, I guess it is not configured to use HDMI output for terminal by default and I couldn't find how to do that.

I also found sunxi site and as I understood armbian is based on that. I tried to follow their instructions to build uboot and kernel however stuck with some steps and errors, and it's also not very clear if they managed to set up HDMI/Mail graphics working with their builds as some instructions labeled as outdated.

I also tried Bookworm image and it works pretty well, I even set up xorg there and run glgears app for testing it, but it still pretty big to me and there are several issues with running graphical apps without desktop environment.

 

So, any help on these two topics is very appreciated:

- How to get really minimum build and where to find actual informaton about that kind of builds as there are many tutorials but they seems to be outdated/incomplete or do not cover board specifics.

- How to get single graphics app running fullscreen without desktop environment (for this experiment I can start with Bookworm build)

 

Thank you.

 

[SteeMan]

15 minutes ago, livingcreative said:

How to get really minimum build and where to find actual informaton about that kind of builds as there are many tutorials but they seems to be outdated/incomplete or do not cover board specifics.

I would suggest you use the armbian build system and build the CLI minimal build for your board.  That should be sufficient for your needs as a starting point.  It is also a low barrier to entry as you can get that working with minimal understanding of what is going on behind the scenes.  Then you can dig into the details to learn as you need.

[voapilro]

1 hour ago, SteeMan said:

A significant reason that the Raspberry Pis are more expensive is that the manufacturer actually invests time and resources into the underlying software.  OrangePi does not.  OrangePi takes advantage of the open source community hoping they can get software support for free without contributing much if anything to that process.  There is a reason that OrangePi boards are not generally supported by Armbian, and lack of manufacturer support is a big reason.

I do not want to start a discussion on this subject. I just want to clarify my point of view. I have several flavours of RPi2, RPi3, RPi4 and I will buy a RPi5 soon. I really like RPi, not only the boards, specially software provided by both manufacturer and community. Just googling a while you can find a lot of resources on RPi, and as a contrary much less for OPi.

 

I do not think RPi4 or RPi5 are expensive, they are new desings, very powerfull, so they cost money. But must of the times, in my case, a RPi3B+ is more than enough, it is an old design, but still powerfull enough for a lot of things, and very well supported. What I do not understand is that RPi3B+ is almost the price of RPi4B-1GB. If RPi3B+ price was more reasonable, I would not be looking for alternatives like OPi. I guess this way RPi manufacturer is pushing us to RPi4 and RPi5, but what they get is that some people like me are looking for other options same power as RPi3.

[ag123]

@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.

 

 

 

[ag123]

@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.

 

 

 

[usual user]

2 hours ago, ag123 said:

u-boot does the bulk of the 'black magic' dealing with memory initialization and sizing

This is not correct. Due to its size, U-Boot must be run from RAM. The RAM must therefore already be initialized before U-Boot can be loaded at all. This is usually done by Trusted Firmware-A (TF-A). U-Boot is only the payload (in TF-A terminology: BL33).
You might want to read TF-A's documentation to understand the boot flow, I think here is a good place to start. You're lucky if TF-A is open source for your SoC, but often only a binary BLOOB for BL2 and BL31 is provided by the SoC manufacturers.

[ag123]

 

 

@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

 

[ag123]

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,