ag123

@robertoj, all I stumbled into this: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/ This seemed to be there in a 'minimal' build, check if you are able to run those commands the pins didn't seemed named sudo gpioinfo [sudo] password for armbian: gpiochip0 - 288 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused input active-high ... gpiochip1 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high ... however, that they seemed to be mapped to 2 (set of) pin-control drivers https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c?h=v6.7.4 #include "pinctrl-sunxi.h" static const struct sunxi_desc_pin h616_pins[] = { /* Internally connected to the AC200 part in the H616 SoC */ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "emac1"), /* ERXD1 */ SUNXI_FUNCTION(0x4, "i2c0"), /* SCK */ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PA_EINT0 */ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "emac1"), /* ERXD0 */ SUNXI_FUNCTION(0x4, "i2c0"), /* SDA */ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* PA_EINT1 */ ... a lot more ... static const unsigned int h616_irq_bank_map[] = { 0, 2, 3, 4, 5, 6, 7, 8 }; static const struct sunxi_pinctrl_desc h616_pinctrl_data = { .pins = h616_pins, .npins = ARRAY_SIZE(h616_pins), .irq_banks = ARRAY_SIZE(h616_irq_bank_map), .irq_bank_map = h616_irq_bank_map, .irq_read_needs_mux = true, .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL, }; static int h616_pinctrl_probe(struct platform_device *pdev) { return sunxi_pinctrl_init(pdev, &h616_pinctrl_data); } static const struct of_device_id h616_pinctrl_match[] = { { .compatible = "allwinner,sun50i-h616-pinctrl", }, {} }; static struct platform_driver h616_pinctrl_driver = { .probe = h616_pinctrl_probe, .driver = { .name = "sun50i-h616-pinctrl", .of_match_table = h616_pinctrl_match, }, }; builtin_platform_driver(h616_pinctrl_driver); https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c?h=v6.7.4 #include "pinctrl-sunxi.h" static const struct sunxi_desc_pin sun50i_h616_r_pins[] = { SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "s_rsb"), /* SCK */ SUNXI_FUNCTION(0x3, "s_i2c")), /* SCK */ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "s_rsb"), /* SDA */ SUNXI_FUNCTION(0x3, "s_i2c")), /* SDA */ }; static const struct sunxi_pinctrl_desc sun50i_h616_r_pinctrl_data = { .pins = sun50i_h616_r_pins, .npins = ARRAY_SIZE(sun50i_h616_r_pins), .pin_base = PL_BASE, }; static int sun50i_h616_r_pinctrl_probe(struct platform_device *pdev) { return sunxi_pinctrl_init(pdev, &sun50i_h616_r_pinctrl_data); } static const struct of_device_id sun50i_h616_r_pinctrl_match[] = { { .compatible = "allwinner,sun50i-h616-r-pinctrl", }, {} }; static struct platform_driver sun50i_h616_r_pinctrl_driver = { .probe = sun50i_h616_r_pinctrl_probe, .driver = { .name = "sun50i-h616-r-pinctrl", .of_match_table = sun50i_h616_r_pinctrl_match, }, }; builtin_platform_driver(sun50i_h616_r_pinctrl_driver); gpiochip0 apparently corresponds to sun50i-h616-pinctrl, the main large bank of IO lines / those are muxed and a lot of them have alternate functions e.g. emac, etc. it'd seemed a little strange that gpiochip1 (sun50i-h616-r-pinctrl) gets a readout of 32 lines. (^edit: https://www.kosagi.com/w/index.php?title=Definitive_GPIO_guide linux gpio number = (gpio_bank - 1) * 32 + gpio_bit solves the puzzle, it could mean that the gpio register is 32 bits and that actually 2 lines are defined. that gives a feeling that the other bits/lines are *undocumented* (often marked 'reserved') apparently, it may be possible to name the lines in the DTS https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpio/gpiolib.c?h=v6.7.4#n456 and apparently gpiod bindings are after all standard https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/bindings

@robertoj I started reading up a few things but that I'm more confused as ever: There is this thing about pincontrol https://www.kernel.org/doc/html/v4.13/driver-api/pinctl.html https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf https://wiki.st.com/stm32mpu/wiki/Pinctrl_overview ^ I liked this one from ST, but that I've not read well enough to understand how pin-control relates to gpio. on a superficial level, I understand it like such, as there are various configurations related to gpio pins e.g. that gpio pins can be configured in varous setups, e.g. input, output, pull up, pull down and other gpio properties etc (possibly soc related), then that for the pins in addition to gpio, there is pin mux, which 'behind' it can be configured for various 'alternate functions' e.g. spi, i2c, uart, pwm etc, then add interrupts etc. and accordingly earlier 'gpio' implementations eventually digressed and requires 'hacks' to get around 'missing' capabilities that is mapped in the more complex pin-control. But that I don't understand deeper than this that if pin control after all configures the pins as above, then where do gpio in the 'simple' sense e.g. reading the pins high or low, or writing to the pins work? Accordingly, there are API interfaces for that if you read the documentation, but I got stuck understanding further about this, i.e. I still don't know how gpio works in this context. on further 'google searches', I stumbled into more recent documentation https://www.kernel.org/doc/html/v6.7/driver-api/pin-control.html https://www.kernel.org/doc/html/v6.7/driver-api/gpio/index.html so it'd seem pin-control and gpio are after all 2 sets of API

@Tusc wrote: they are not quite yet ready for 'prime time', check out the rolling releases: https://github.com/armbian/os/releases/latest https://github.com/armbian/os/releases/tag/24.2.0-trunk.519 expand the 'Assets' flap, use your web browser's in page search and look for 'zero3'. still in 'bleeding edge' (technology) stage, try it/them out feedback on what works, issues etc. @Gunjan Gupta curiously in the most recent trunk.526 https://github.com/armbian/os/releases/latest a text search for 'zero3' draws a blank, but it is there in 519

i used one of those ch340 dongles https://www.aliexpress.com/w/wholesale-ch340.html , but with Orange Pi Zero 3, they worked quite well not so much for 'quality', but that they are rather low costs, and that some of the modules has switches between 3.3v and 5v vcc. I get one of those with switches and set it at 3.3v

@VioletGiraffe Orange Pi Zero 3 is still in *test* phase, review the many comments above e.g. from @pixdrift, @Gunjan Gupta, @Stephen Graf et.al. , if images links are embedded in comments, those are *test* images if they are listed for now. the rolling release images can be found here: https://github.com/armbian/os/releases/latest do try them out and add your comment as feedback in this thread if you tried it, providing info such as your board , memory size, the image used etc. what works and any issues if you discovered it. but practically speaking, support for Orange Pi Zero 3 is really / practically *reverse engineered*, even the dram controller is *undocumented* and it is an 'best effort' that it works (many things are wild guesses e.g. trials based on other chips e.g. H616 and 'they happened to work'). Hence, the images would likely always be *use at your own risk* even if it becomes 'community' support.

actually that box is good in a sense that it has quite a few peripherals on board and is probably cheaper than development boards in a sense that it comes with a case. i've not 'touched' them as that normally public documentation tend to be even thinner than do development boards. but yup, I'd think it would be good if Armbian runs on them as well, more options for whoever is using Armbian hopefully that the H618s are after all similar that the difference between them is simply a DTS

@pixdrift rather than to say that 'enable all' isn't well received, i think we (at least myself) may be misguided, as I've not explored a lot of things, especially access to the io header pins. there are also a lot of things that we'd need @pixdrift, @Gunjan Gupta, @Stephen Graf and others who happened to use those functionality (e.g. the header pins / spi / gpio etc) to share if after all enabling them actually lead to conflicts? and if after all pinmux 'works the way as expected', e.g. my notion that pin mux selects the function is *pure speculation*, e.g. that after all we can simply 'enable everything' and just use pin mux to choose between them. e.g. pin mux determines if gpio or alternate function ( spi / uart/ i2c / pwm etc is seen at the pin. There are also *unproven* things that I simply speculate if simply 'okay' the device in DTS actually cause a higher power consumption / higher temperature, there is no actual report / comment to indicate that it really works that way ! i'm simply being *lazy* to comment that maybe leaving it 'disabled' is just 'safe', that may not even be true.

@Igor it is a little unfortunate that in this open sourced world, not all users would see using and supporting Armbian as a cooperative https://dictionary.cambridge.org/dictionary/english/cooperative I'm not sure what can be done, but this state of the situation would likely persist. in a certain sense, getting Linux and Armbian to run on Orange Pi Zero 3 is already a 'heroic' effort. Given, the dram controller is *undocumented*, all that u-boot codes that made the memory detection work is a 'miracle' pieced together from reverse engineering and wild guesses. So are all that 'heroic' efforts by linux-sunxi and Armbian to make it run on H616 / H18 and supporting the ethernet PHY as well as uwe-5622 wifi. for that matter the H618 and uwe5622 technical reference manual cannot be found in the wild and all these efforts thus far from notably @Gunjan Gupta , @pixdrift , @Stephen Graf et.al. the wild tests and trials to tweak the configurations *so happens to work*! it can reasonably be said that running any open-sourced linux and/or Armbian on Orange Pi Zero 3 will practically be always *use at your own risk*, as no one can give any assurance that any of these are after all formal. In short, it wouldn't have happened without all these community effort and Armbian itself and efforts from linux-sunxi contributors. it is an incredible effort on its own. for that matter Orange Pi Zero 3 with all these community effort from Armbian and linux sun-xi nearly makes it lives up to an Raspberry Pi 3B+, at least in terms of functionality and performance. it is no small feat / achievement. There is also the notion that the board developers / manufacturers should after all fund and support Armbian including the technicals, it is a different consideration however. I'd like to say that Armbian *runs well* on Orange Pi Zero 3, for 'basic' use with ethernet and wifi. There are many other things that I've not yet explored but the @pixdrift, @Stephen Graf have explored to some extent. e.g. the gpios, spi and such alternate functions on the pins etc. as for the "1.5GB problem", my thoughts are currently this. We'd need to publish *release notes* or more correctly *read this first*, with this board if this board is hosted as a 'community supported' board. Because, the memory detection logic *in uboot* will probe into *wrap around* addresses and falsely detect memory as available. There is *no solution* as the dram controller is *undocumented* , so one way out of this is to publish a note to say that for 1.5GB and some such board owners, a *solution*, is they have to edit /boot/armbianEnv.txt, and use a different DTS overlay that encode the memory size in the overlay. This is thinking ahead, I've not tried this solution if it after all works if at all. we'd probably can put other *pitfalls* and known-limitations and *disclaimers* (e.g. use at your own risk) in the *read this first*

@Uko take a look at this comment it is 'stashed in the middle' a few pages earlier in this thread https://forum.armbian.com/topic/29202-orange-pi-zero-3/?do=findComment&comment=179400

@Gunjan Gupta wrote: hi no worries, I'm just raising awareness so that more people could perhaps review the codes to see what may be improved. For what is worth, the wifi driver works well, if that is uwe5622 that is.

that's your wifi on a longer term is to review the codes to see what can be done about it, the driver that is.

[U-Boot,v2.1,11/13] sunxi: add DRAM support to H6 https://patchwork.ozlabs.org/project/uboot/patch/20180722221334.3679-1-icenowy@aosc.io/ https://linux-sunxi.org/DRAM_Controller the (S)DRAM controller on H6, H616, H618 (for this even the technical reference manual cannot be found in the wild) is *undocumented*, it is incredible how far we have come. (the pioneers and all did a lot of work) I'd guess is a reason for the very limited support we've today e.g. the "1.5GB problem" the memory detection logic is practically 'a hack'. There are registers in the dram chips which no publicly known ways to access them fromm the system interrface in the SOC is documented, the memory sizes would otherwise be read from the registers and alleviate all these issues. accordingly to iuncuim https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/38?u=ag1233 it is quite possible the addresses wrap around in the 1.5GB LPDDR4 dram chips and the 'test' for memory there returns a false positive. This is practically 'dangerous' as the dram would be detected as 2GB which is actually lesser. this reflects what is observed in the 'complaint' earlier. 1.5GB would otherwise be detected as 1GB and that would have worked even if part of that goes to waste.

hi about u-boot and "1.5G problem" take a look here https://gist.github.com/iuncuim and in particular this patch for u-boot https://gist.github.com/iuncuim/3d2b20f7274aa8ea69a634bc7aeb54a2 I guess that will fix the problems surrounding 1.5G boards, possibly that the memory isn't correctly detected. But with the patch, it should 'just work'. But i'm not sure if that may have some unintended 'side effects' I think iuncuim https://github.com/iuncuim is probably involved in developing openwrt, hopefully that he could submit his patch for consideration and added into the upstream u-boot, that would make support common for all the Orange Pi Zero 3 and Orange Pi Zero 2w variants. I don't have the 1.5G board, if all of us don't have that for now, we'd wait for 'complaints' oh yea, I'd guess most would be more 'comfortable' with the 1G, 2G, 4G 'whole numbers' while buying boards, the price isn't that different after all, lol ok news from over at DietPi, the complaint comes from there instead: https://github.com/MichaIng/DietPi/issues/6594#issuecomment-1907369622 Sadly, the 1.5GB doesn't 'just work'. It reports 2GB (and then stops): U-Boot SPL 2024.01-rc5-armbian (Jan 13 2024 - 14:02:32 +0000) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.10.0 (debug):armbian NOTICE: BL31: Built : 14:02:12, Jan 13 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b2e68, model: OrangePi Zero3 INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: PMIC: Probing AXP305 on RSB ERROR: RSB: set run-time address: 0x10003 INFO: Could not init RSB: -65539 INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied INFO: PSCI: Suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 INFO: Changed devicetree. ns16550_serial serial@5000000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2024.01-rc5-armbian (Jan 13 2024 - 14:02:32 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 2 GiB (effective 8 EiB) we probably have to look at this patch https://gist.github.com/iuncuim/3d2b20f7274aa8ea69a634bc7aeb54a2 diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c b/arch/arm/mach-sunxi/dram_sun50i_h616.c index c5c1331..9b51b7e 100644 --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c @@ -1352,6 +1352,9 @@ static unsigned long mctl_calc_size(const struct dram_config *config) u8 width = config->bus_full_width ? 4 : 2; /* 8 banks */ + u32 offset = (1ULL << (config->cols + config->rows + 3)) * width * config->ranks; + if (mctl_mem_matches(offset-0x10)) + return (1ULL << (config->cols + config->rows + 3)) * width * config->ranks * 3 / 4; return (1ULL << (config->cols + config->rows + 3)) * width * config->ranks; } applied to this file https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads hold it there is also this patch https://gist.github.com/iuncuim/a7b01ecd919dfd82d90f0f0fe81b50fd From 4a542204ebd3ce90393c24a102679c9a3c7c13bc Mon Sep 17 00:00:00 2001 From: iuncuim <iuncuim@gmail.com> Date: Sat, 16 Dec 2023 19:00:16 +0300 Subject: [PATCH] Update dram_sun50i_h616.h and dram_sun50i_h616.c --- .../include/asm/arch-sunxi/dram_sun50i_h616.h | 1 + arch/arm/mach-sunxi/dram_sun50i_h616.c | 18 ++++++++++++++++-- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h index a8fdda124a..0d81077ce5 100644 --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h @@ -166,6 +166,7 @@ struct dram_config { u8 rows; u8 ranks; u8 bus_full_width; + bool dram_shrink; }; static inline int ns_to_t(int nanoseconds) diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c b/arch/arm/mach-sunxi/dram_sun50i_h616.c index c5c1331a4c..3d8171e9ae 100644 --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c @@ -154,7 +154,10 @@ static void mctl_set_addrmap(const struct dram_config *config) /* Ranks */ if (ranks == 2) - mctl_ctl->addrmap[0] = rows + cols - 3; + if (config->dram_shrink) + mctl_ctl->addrmap[0] = rows + cols - 5; + else + mctl_ctl->addrmap[0] = rows + cols - 3; else mctl_ctl->addrmap[0] = 0x1F; @@ -204,7 +207,10 @@ static void mctl_set_addrmap(const struct dram_config *config) mctl_ctl->addrmap[7] = 0x0F0F; break; case 15: - mctl_ctl->addrmap[6] = (cols - 3) | ((cols - 3) << 8) | ((cols - 3) << 16) | 0x0F000000; + if (config->dram_shrink) + mctl_ctl->addrmap[6] = (cols - 3) | ((cols - 2) << 8) | ((cols - 2) << 16) | 0x0F000000; + else + mctl_ctl->addrmap[6] = (cols - 3) | ((cols - 3) << 8) | ((cols - 3) << 16) | 0x0F000000; mctl_ctl->addrmap[7] = 0x0F0F; break; case 16: @@ -1324,6 +1330,7 @@ static void mctl_auto_detect_dram_size(const struct dram_para *para, struct dram_config *config) { /* detect row address bits */ + config->dram_shrink = false; config->cols = 8; config->rows = 18; mctl_core_init(para, config); @@ -1345,6 +1352,11 @@ static void mctl_auto_detect_dram_size(const struct dram_para *para, config->bus_full_width))) break; } + u32 dram_size = (1ULL << (config->cols + config->rows + 3)) * (config->bus_full_width + 1) * 2 * config->ranks; + if (mctl_mem_matches(dram_size - 0x10)) { + config->dram_shrink = true; + mctl_core_init(para, config); + } } static unsigned long mctl_calc_size(const struct dram_config *config) @@ -1352,6 +1364,8 @@ static unsigned long mctl_calc_size(const struct dram_config *config) u8 width = config->bus_full_width ? 4 : 2; /* 8 banks */ + if (config->dram_shrink) + return (1ULL << (config->cols + config->rows + 3)) * width * config->ranks / 4 * 3; return (1ULL << (config->cols + config->rows + 3)) * width * config->ranks; } -- 2.43.0 and to rebuild u-boot from source Then merge that on an image for the tests. The thing is unless any one of us has a 1.5G board, it'd probably be difficult to verify if it after all works and that we'd probably need to test it all over again for 'side effects' e.g. if it break any other boards including other allwinner boards beyond just H616 / H618 that uses the same algorithm / routine for LPDDR4 (and 3? e.g. H616) dram setup and size detection https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads hopefully that if this is indeed a stable solution that it can be upstreamed in uboot. ----- i reluctantly ordered a 1.5G board, I don't need it, but I'd help to test it as I'd guess 'sooner than later' someone would 'show up here' with that 1.5G board. when my 1.5G board arrive, I'd test that solution if indeed it fixes 1.5G board issue, and report it in here. --- just an update here https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/34?u=ag1233 the patches given above probably won't work on Orange Pi Zero 3 1.5 GB the author has replied and he is probably the same author who have written the dram memory support for Orange Pi Zero 3 that we are using currently ! https://source.denx.de/u-boot/u-boot/-/commit/4b02f0120a4bb2a5d7081aef8cef6a4ca57e9db2 Notice that he is probably the same guru/person who provided the LPDDR4 support for H618 Orange Pi Zero 3, Zero 2w in the 1st place? Hence, the current status is best defined as that 1.5GB board is not supported (by mainline u-boot) for the time being. And that we'd continue to test pre-mature changes 'offline' and that most likely the support would be a future release of mainline u-boot when it is supported. In the mean time, the best deal for any one is to use the 1GB, 2GB or 4GB variants of Orange Pi Zero 3 and skipping the 1.5GB variant.

Das u-boot the magic behind all the memory size detection for H616/H618 memory sizes and support ! hi all, this is a little 'off-topic' but related I've been wondering what is the change that makes it possible for the memory size on Orange Pi Zero 3, Zero 2w to be detected 'automagically'. Sometime back, Orangepi distributed quite a number of images that is matched to each different memory size 1&2 GB, 1.5GB, 4GB I originally thought that the memory size is encoded in the DTS, but that if this is true then that U-boot needs to send a different DTS / DTB template with the specific memory size to the kernel at boot. This would be bad as it means having a different configuration for every dram memory size. I had a rather difficult time chasing down where this is implemented. It turns out the *magic* is all in u-boot https://source.denx.de/u-boot/u-boot/-/commit/4b02f0120a4bb2a5d7081aef8cef6a4ca57e9db2 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 * ... There is a lot of codes in there that does the LPDDR4 / DDR3 initialization, clocks and detecting the memory size. We'd need to observe and keep u-boot up-to-date for this purpose as I'd guess most of us don't have a 1.5GB board, and it may fail if someone shows up here with a 1.5GB board complaining about issues. My thoughts are that 1.5GB boards if they are not yet supported would be added for support in the upstream u-boot as above. Hence, it helps to watch u-boot for additions and use an up-to-date uboot as the patches get updated. das uboot practically plays what is deemed as 'bios' in our 'legacy' PCs and notebook PCs for these boards https://source.denx.de/u-boot/u-boot/ part of the role of 'bios' are encoded as DTS templates, so that the kernel can configure the drivers it needs at boot

note that i agree with @Stephen Graf viewpoint that overlays are specific, and worse not only to a board but to particular use case. take for example the 'bigtreetech cb1' board which may coincidentally be using a soc in the H616/H618 family, lets just say that the CB1 dts (note not overlay) declares that 'ws2812' (addressable led matrix), spi tft lcd, mcp, light are part of accessible devices connected to (an) SPI port. this scenario didn't only address the board, it address the use case as well, e.g. a 3d printer with those additional devices connected. it isn't to say that it is 'incorrect' nor 'inappropriate', but that the same SPI port on the same board can just as well be connected to *different peripherals and/or devices*. and that supposing that you have at least 2 different uses for the same board that would take at least 2 different dts templates and/or overlays, in fact there can be 'infinite' permutations of use cases for the same SPI port, and that practically means *infinite* permutations of overlays for *all possible* devices connected in some ways to a SPI port. hence, for dtsi (DTS includes) and dts (device tree source) templates, they work more like 'object oriented' inheritance hierarchies, e.g. that the most general, say at the soc level may be declared, e.g. the SPI ports. but that further down at the use cases e.g. the devices attached to spi ports, especially those can literally change on the fly, those would inevitably need to be declared in *specific* overlays addressed to the use case e.g. a 3d printer (or any appliance for that matter, e.g. a TV / media streaming box) - this goes beyond just that board. Note however, that there are *well defined* use cases e.g. particular leds on the board, those can probably be defined and enabled ('okay') in the board specific dts template. in a sense, every board with at least a difference in configuration, say for that matter led at a different pin and/or pull-up/pull-down would have a different dts template for the board. this would be the same say fixed on board pheriperials say connnected to spi ports (say the spi flash boot rom) --- then that there is a different problem (addressed a few comments earlier), about many alternate functions on the same pin and pin mux e.g. that a same pin can have gpio + spi + uart + i2c + pwm + ... I'm not sure if declaring all the functions being enabled (i.e. 'okay') would result in conflicts, or that if they are enabled means that the function becomes 'configured' and *active* and hence draw power. But that i'd guess even if 'everything enabled ('okay')' there is still the pin mux which ultimately selects the function that is seen at the pin. just that in this case if all the functions (e.g. gpio + spi + uart + i2c + pwm) are concurrently 'okay' and if it cause it to draw power, the soc / chip will likely run *hot* even if it does 'nothing' (note I'm not sure if this is after all true). If this is indeed the case, and that we only want specific pheriperials to be 'enabled' if it is used, we may end up having to define all the on chip/soc pheriperials and *test them*, but in the 'production' version mark them as 'disabled' so that specific (custom) overlays are subsequently added to address the *use case* for every particular scenario. 'research' https://course.ece.cmu.edu/~ece742/S20/slides/Dark Silicon_ The Beginning of the End.pdf well it matters, as in that if it is 'disabled' by default, chances are that the chip may run a degree or 2 cooler. but that the 'inconvenience' is that anyone who wants to use those ports ( gpio + spi + uart + i2c + pwm + ...) would need to enable them themselves by means of dts overlays it probably also address pinmux conflict issues the hard part is to decide on *well defined* use cases, e.g. that the debug uart port is *mostly necessary* (i.e. a must, so that probably has to be configured 'okay' by default on every (different) board in its board specific dts. these days more than ever, SBC no longer have the 'luxury' of its own hdmi monitors and even for that matter with a full suite of usb keyboard and mouse (as like a desktop / notebook computer), and the 'debug uart port', is the only system console, to fix every other network problems ethernet / wifi, hdmi, display, etc. or e.g. the 'alive' led status, blinking the leds is the most primitive (g)ui to tell the user that their board with the os is 'alive', never mind that they have serious network connectivity issues, but the board and os is running !

i think we are dealing with dilemmas which evolves since when 'early' arm boards evolves with device trees, e.g. beagle bone black - the 1st to use device trees. https://elinux.org/images/f/f9/Petazzoni-device-tree-dummies_0.pdf if we want to be generic and yet safe, my guess is for a lot of the 'soc' level stuff, we'd probably declare all the peripherals / devices (e.g. spi / i2c / uart / pwm / gpio / usb etc) properly in the dtsi / dts, but perhaps 'disabled'. this is probably safe, but that 'switching on' things would then take *custom overlays* for all various permutations. then that for things that are 'common' (or commonly used or has a well defined use case) e.g. leds, spi flash boot roms (probabbly better 'disabled') those would/could be enabled ('okay') by default. But that this would be for each board. it may take 'tutorials' pages to educate the audience about dts overlays etc going forward.

@Gunjan Gupta my apologies, I don't mean to address 'bigtreetech' rather I'm saying that the board is intended for a particular use case, and hence the dts is designed as such. but that as the soc shares similar dts or dtsi templates, would there be overlapping concerns here?

@pixdrift, @Stephen Graf, @Gunjan Gupta, all for the DTS, I'm slowly seeing the dilemma, on the soc some of the pheriperials are normally deemed 'fixed', but that pin mux means that the same pin has multiple alternate functions - e.g. gpio + spi + i2c + uart + pwm etc 'slave' / 'child' functions are a pain to deal with. 'slave' / 'child' functions are like for spi or i2c, some boards has external devices connected on them. e.g. on orangepi zero 3, I think the boot spi flash is likely connected to a spi flash, I'm not sure about others (this is deemded a 'slave' or 'child' device of the spi) the trouble is those 'slave' devices can be arbitrary e.g. one board may have that spi flash, another don't, or some others has other different device(s) connected at different ports. even gpios is not spared, as for gpios some pins are *leds* and again this vary from board to board or even arbitrary e.g. anyone can use any gpio pin as a led pin and the drive pull up or pull down differs. I'm not sure how in particular dts overlays can represented case (2), is it practically feasible to declare 'soc' level includes that says declare the spi or i2c port dtsi, and that subsequent per board dts include the 'soc' dtsi for the spi and i2c ports and further declare the slave / child devices attached? And that there are further problems, e.g. that 'bigtreetech' board may declare non existent devices as being connected e.g. addressable led strips e.g. ws8212, tft3 lcd, mcp and light (leds). That in part as the eventual use could be a 3d printer which has those things connected, they are literally external and nowhere on the board. then circling back to point (1), do declaring pheriperials as 'ok' necessary cause conflicts between the alternate functions? e.g. gpio + spi + i2c + uart + pwm all set to 'okay'? the notion is that the alternate functions being the alternate functions themselves, and the pin mux being pin mux, .e.g pin mux selects the alternate functions and not the other way round. the catch here probably is, if just say that there is *no conflict*, then that if all the alternate functions are 'ON' the soc would likely run hotter consume more power, but that pin mux may determine what is there at the output at the pin. the big catch here is that, if we are concerned about these issues, we may end up setting everything disabled by default ! and that every permutation of alternate functions thereafter requires a *custom overlay* ! Actually, I think it is a limitation of today's kernel design, alternate functions could hopefully become 'dynamically configurable' at some future linux versions, e.g. that an app make calls to the kernel to setup particular peripherals at run time e.g. changing that from 'disabled' to 'okay' at run time. if imagine an fpga is connected at some arbitrary gpio, that fpga can warp into spi, i2c, uart, ethernet, scsi, a cpu, an npu, a gpu practically anything on the fly by fpga programming. we live in a wrold where hardware is software is partially true.

@Gunjan Gupta Thanks !

ouch, those things gets tricky really, in the way that the 2 spi interfaces are declared, it is correct to say that one of the spi goes to the spi flash (e.g. an MTD) device. while the other is possibly simply on the headers? I'm not familiar with dts really, but that the first declaration would 'chain' another driver say the spi flash driver that uses it? but I'd imagine that the spi are at the 'same level' as mentioned, just that for instance maybe the orange pis possibly use a SPI flash for the boot rom, while it may be different or even possibly just a different port say on the bigtreetech board? and so I went googling again, and stumbled into this https://elinux.org/Device_Tree_Usage#Non_Memory_Mapped_Devices Non Memory Mapped Devices Other devices are not memory mapped on the processor bus. They can have address ranges, but they are not directly accessible by the CPU. Instead the parent device's driver would perform indirect access on behalf of the CPU. To take the example of i2c devices, each device is assigned an address, but there is no length or range associated with it. This looks much the same as CPU address assignments. i2c@1,0 { compatible = "acme,a1234-i2c-bus"; #address-cells = <1>; #size-cells = <0>; reg = <1 0 0x1000>; rtc@58 { compatible = "maxim,ds1338"; reg = <58>; }; }; https://android.googlesource.com/kernel/msm/+/android-wear-5.0.2_r0.1/Documentation/devicetree/bindings/spi/spi-bus.txt another example found here for stm32 https://wiki.st.com/stm32mpu/wiki/SPI_device_tree_configuration based on those hints, my guess &spi0 { status = "okay"; #address-cells = <1>; //one number to indicate the chip select pin #size-cells = <0>; //zero as given in the blurb from google android pinctrl-names = "default"; pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>; flash@0 { compatible = "jedec,spi-nor"; reg = <0>; //chip select of '0'(zero) spi-max-frequency = <40000000>; }; }; &spi1 { status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; pinctrl-names = "default"; pinctrl-0 = <&spi1_pins &spi1_cs0_pin>; spidev@0 { compatible = "rohm,dh2228fv"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; };

hi all, I'd just like to say that it is now possible to build Armbian for Orangepi Zero 3 from source from the trunk https://github.com/armbian/build https://docs.armbian.com/Developer-Guide_Build-Preparation/ select bookworm edge 6.7 for the build but that it is necessary to run with compile.sh EXPERT=yes special thanks goes to @pixdrift @Gunjan Gupta and the armbian maintainers many @Igor et.al https://github.com/armbian/build/graphs/contributors in case anyone is curious about the resulting built image for tests, etc- note *unsupported* *use at your own risk* Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.1_minimal20240122.img is an **unsupported** Armbian image build from the trunk (i.e. main branch) from https://github.com/armbian/build from 20240122 for Orangepi Zero3 - Debian Bookworm image https://www.mediafire.com/file/5kqetzxkqe2kk5i/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.1_minimal20240122.7z/file this won't be there permanently note that as @Gunjan Gupta mentions (below), actually there are nightly builds. It is recommended to use those instead for tests. https://github.com/armbian/os/releases/latest

hi I've been using the flag compile.sh PREFER_DOCKER=no while building in a systemd-nspawn container: Building Armbian using Ubuntu (jammy) in a systemd-nspawn container This time I managed to make a complete successful build with my work arounds for loop devices in systemd nspawn. However, the flag PREFER_DOCKER=no Didn't seem to be documented in the build options https://docs.armbian.com/Developer-Guide_Build-Options/ can the documentation be updated to add PREFER_DOCKER=no flag (at least under 'advanced users') ? note that it isn't possible to run docker normally within systemd-nspawn or that it'd require all those workarounds such as patching and using the host docker server which defeats the purpose of using docker. rather systemd-nspawn is the container to at least decouple the build environment from the host os environment (which can be a different linux distribution, I'm doing so from OpenSuse https://www.opensuse.org/), with the unfortunate caveat that loop devices still requires a workaround.

I don't have this board, but hoping to help, I did a bit of googling and stumbled into the following: https://www.google.com/search?q=orange+pi+5b+ap6275+site:forum.armbian.com ^ from this : etc --- others http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5B.html https://www.cnx-software.com/2022/11/11/orange-pi-5-most-affordable-rockchip-rk3588s-sbc/ http://www.orangepi.org/orangepiwiki/index.php?title=How_to_use_AP6275P_PCIe_network_card&mobileaction=toggle_view_desktop https://datasheet.lcsc.com/lcsc/2203281730_AMPAK-Tech-AP6275P_C2984107.pdf hope it could provide some leads to a solution

some additional off-topic blurbs about NPU etc. https://www.intc.com/news-events/press-releases/detail/1663/intel-accelerates-ai-everywhere-with-launch-of-powerful https://arstechnica.com/gadgets/2023/12/amds-new-ryzen-8040-laptop-chips-look-a-lot-like-the-ryzen-7040-cpus/ https://www.amd.com/en/technologies/xdna.html https://coral.ai/ https://developers.googleblog.com/2022/05/coral-googles-platform-for-edge-ai.html https://www.nvidia.com/en-sg/ai-data-science/ https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78 https://wiki.t-firefly.com/en/ROC-RK3588S-PC/usage_npu.html https://semiconductor.samsung.com/news-events/news/samsung-electronics-to-strengthen-its-neural-processing-capabilities-for-future-ai-applications/ https://www.qualcomm.com/news/onq/2023/10/introducing-our-next-gen-intelligent-pc-platforms-the-snapdragon-x-series https://www.nxp.com/company/blog/introducing-the-nxp-eiq-neutron-neural-processing-unit-npu:BL-INTRODUCING-THE-NXP-EIQ-NPU https://blog.st.com/stm32n6/ erh, it is getting pretty crowded? and that one can likely be assured none of the offerings are the same in anyway. if one has a board and wanted to try those NPU stuff, one is most welcomed to go ahead and try and perhaps tell the world what you achieved. there would be many keen audiences who would like to look at what you did and at least 'wow' about it. And by the way all that 'neural' stuff can mostly run on the *CPU*, and that there are plenty of accelerators for that AVX2, AVX512, SSE2, NEON, SIMD, GPGPU etc and that *GPUs* (Nvidia) has been around and has been the *industrial workhorse* for 'AI' stuff. there is also some thoughts about the NPU cacophony as above, while one start developing say on an NPU, no sooner than one gets started, another 10 competitors released another 20 NPUs and AI accelerators for your to try, and even then while you gets started, your SOC company release a new chip and a *brand new* NPU, obseleting your 'old' NPU while you are just about to 'get started' with you NPU stuff.

here is some 2 cents comments, if you are meaning NPUs like these: https://github.com/rockchip-linux/rknpu2 - hardware interfaces are kept as trade secrets and not published anywhere 1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source) and there is no hardware documentation any where about the technical details, registers etc. if that at least those are published, one could possibly start coding something to test things on the NPU. then that for things like ethos-n78 https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78 you can find some info here https://developer.arm.com/Processors/Ethos-N78 but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them. - IO / cpu scheduling cpu frequency scaling / governors are well documented https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt https://docs.kernel.org/scheduler/schedutil.html https://www.kernel.org/doc/html/latest/scheduler/ and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain. but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer. and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well. Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate. and if one wants to do some manual scheduling there is the plain old "nice" command https://www.scaler.com/topics/linux-nice/ ---- well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues. The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them. You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions. This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling). And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.