All Activity

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

It looks to me like the upgrade is uninstalling the kernel, dtb and likely other armbian packages. Likely because it thinks they are extra for some reason. During the upgrade are you seeing an option to remove old packages? If so look at that list and see if there are any Armbian packages in that list (there shouldn't be) (specifically anything with Armbian in the name as well as linux-image-* and linux-dtb-*) I think successful upgrades disable the Armbian apt repository which should leave all the armbian packages untouched. Then after the upgrade, you manually enable the armbian apt repository for the correct release and then do an apt update/upgrade of the armbian packages.

This is how healthy starting system looks like And the serial output when starting this older backup: Shall I now just give up and do a clean install? This time I made a backup of failed installation too.

WOW! huge thanks! I didn't know about image generation, I believe that now everything will flow better here.

So, upgraded and bricked again armbianEnv: fstab /boot seems to be populated And According to boot script, it seems that /boot/dtb directory is missing and this is causing the whole havoc?

This option can only be used when you have already done the build once. The sources in the cache folder have been updated or created. By applying this parameter, the build system should not update local sources and their state should not change. In this case, it is possible to achieve repeatability of the assembly. But this is only local. It is not possible to re-build a package that exists in a remote repository.

Ambiguity of the translation Unfortunately, it is not possible to build a specific version or, in other words, repeat the build. Let's assume that I'm building all the packages and installing them in a future image. I have made my custom changes in the kernel package and in two other packages. And I don't want these packages of mine to be updated when the OS is updated. In this case, I install a version larger than the latest version in the Armbian repository. Another case. I've put together three packages and just want to install them into an already running OS on the device. I'm doing the same thing with the version. That's what I meant.

Linux 6.6.27 is not stable on my system - with or without the modifications (hs400 speed and cache awareness). I will switch back to 6.6.8 now. # kernel oops 2024-04-17T20:45:02.182350+02:00 helios64 kernel: [20582.266022] Unable to handle kernel paging request at virtual address ffff800481075118 2024-04-17T20:45:02.182405+02:00 helios64 kernel: [20582.266042] Mem abort info: 2024-04-17T20:45:02.182409+02:00 helios64 kernel: [20582.266047] ESR = 0x0000000086000005 2024-04-17T20:45:02.182413+02:00 helios64 kernel: [20582.266053] EC = 0x21: IABT (current EL), IL = 32 bits 2024-04-17T20:45:02.182416+02:00 helios64 kernel: [20582.266062] SET = 0, FnV = 0 2024-04-17T20:45:02.182421+02:00 helios64 kernel: [20582.266068] EA = 0, S1PTW = 0 2024-04-17T20:45:02.182424+02:00 helios64 kernel: [20582.266073] FSC = 0x05: level 1 translation fault 2024-04-17T20:45:02.182428+02:00 helios64 kernel: [20582.266080] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000037b7000 2024-04-17T20:45:02.182432+02:00 helios64 kernel: [20582.266088] [ffff800481075118] pgd=10000000f7fff003, p4d=10000000f7fff003, pud=0000000000000000 2024-04-17T20:45:02.182436+02:00 helios64 kernel: [20582.266111] Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP 2024-04-17T20:45:02.182440+02:00 helios64 kernel: [20582.266686] Modules linked in: xt_comment xt_tcpudp nft_compat nf_tables nfnetlink eq3_char_loop(O) rpi_rf_mod_led(O) dummy_rx8130(O) hb_rf_eth(O) generic_raw_uart(O) sunrpc lz4hc lz4 zram binfmt_misc cp210x us> 2024-04-17T20:45:02.182445+02:00 helios64 kernel: [20582.273976] CPU: 5 PID: 13764 Comm: kworker/5:2 Tainted: G C O 6.6.27-current-rockchip64 #2 2024-04-17T20:45:02.182450+02:00 helios64 kernel: [20582.274829] Hardware name: Helios64 (DT) 2024-04-17T20:45:02.182453+02:00 helios64 kernel: [20582.275191] Workqueue: events dbs_work_handler 2024-04-17T20:45:02.182457+02:00 helios64 kernel: [20582.275626] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) 2024-04-17T20:45:02.182461+02:00 helios64 kernel: [20582.276247] pc : 0xffff800481075118 2024-04-17T20:45:02.182464+02:00 helios64 kernel: [20582.276567] lr : 0xffff800481075118 2024-04-17T20:45:02.182467+02:00 helios64 kernel: [20582.276882] sp : ffff800088b23530 2024-04-17T20:45:02.182472+02:00 helios64 kernel: [20582.277182] x29: ffff800088b23530 x28: ffff800081c4d090 x27: ffff0000040a8080 2024-04-17T20:45:02.182499+02:00 helios64 kernel: [20582.277830] x26: 000000003b9aca00 x25: ffff0000040a84f8 x24: 0000000000000000 2024-04-17T20:45:02.182503+02:00 helios64 kernel: [20582.278474] x23: ffff800081a47000 x22: ffff8000816f8008 x21: ffff800088b23578 2024-04-17T20:45:02.182507+02:00 helios64 kernel: [20582.279118] x20: 00000000000000fa x19: 00000001004d6073 x18: 0000000000000000 2024-04-17T20:45:02.182510+02:00 helios64 kernel: [20582.279762] x17: 000000040044ffff x16: 00100074b5503510 x15: 0000000000000000 2024-04-17T20:45:02.182513+02:00 helios64 kernel: [20582.280404] x14: 00000000000000c9 x13: 0000000000000002 x12: 0000000000000000 2024-04-17T20:45:02.182516+02:00 helios64 kernel: [20582.281048] x11: 0000000000000400 x10: 0000000000000a90 x9 : ffff800088b23450 2024-04-17T20:45:02.182520+02:00 helios64 kernel: [20582.281691] x8 : ffff000006da46f0 x7 : 0000000000000000 x6 : 0000000000000070 2024-04-17T20:45:02.182523+02:00 helios64 kernel: [20582.282333] x5 : 00000000410fd080 x4 : 0000000000f0000f x3 : 0000000000000002 2024-04-17T20:45:02.182527+02:00 helios64 kernel: [20582.282976] x2 : 0000000000000000 x1 : ffff000006da3c00 x0 : 00000000124a8be7 2024-04-17T20:45:02.182530+02:00 helios64 kernel: [20582.283621] Call trace: 2024-04-17T20:45:02.182533+02:00 helios64 kernel: [20582.283846] 0xffff800481075118 2024-04-17T20:45:02.182536+02:00 helios64 kernel: [20582.284136] rk3x_i2c_xfer_common.isra.0+0x32c/0x438 2024-04-17T20:45:02.182539+02:00 helios64 kernel: [20582.284589] rk3x_i2c_xfer+0x18/0x24 2024-04-17T20:45:02.182543+02:00 helios64 kernel: [20582.284917] __i2c_transfer+0x1ec/0x80c 2024-04-17T20:45:02.182546+02:00 helios64 kernel: [20582.285269] i2c_transfer+0x60/0x128 2024-04-17T20:45:02.182549+02:00 helios64 kernel: [20582.285598] i2c_transfer_buffer_flags+0x5c/0x90 2024-04-17T20:45:02.182552+02:00 helios64 kernel: [20582.286017] regmap_i2c_write+0x20/0x58 2024-04-17T20:45:02.182556+02:00 helios64 kernel: [20582.286370] _regmap_raw_write_impl+0x7ac/0x8f8 2024-04-17T20:45:02.182559+02:00 helios64 kernel: [20582.286778] _regmap_bus_raw_write+0x60/0x7c 2024-04-17T20:45:02.182563+02:00 helios64 kernel: [20582.287163] _regmap_write+0x60/0x188 2024-04-17T20:45:02.182567+02:00 helios64 kernel: [20582.287496] _regmap_update_bits+0x114/0x134 2024-04-17T20:45:02.182570+02:00 helios64 kernel: [20582.287881] regmap_update_bits_base+0x64/0x98 2024-04-17T20:45:02.182573+02:00 helios64 kernel: [20582.288282] regulator_set_voltage_sel_regmap+0x50/0x9c 2024-04-17T20:45:02.182577+02:00 helios64 kernel: [20582.288759] _regulator_call_set_voltage_sel+0x74/0xc8 2024-04-17T20:45:02.182580+02:00 helios64 kernel: [20582.289224] _regulator_do_set_voltage+0x47c/0x58c 2024-04-17T20:45:02.182584+02:00 helios64 kernel: [20582.289660] regulator_set_voltage_rdev+0x64/0x258 2024-04-17T20:45:02.182586+02:00 helios64 kernel: [20582.290096] regulator_do_balance_voltage+0x1f4/0x428 2024-04-17T20:45:02.182590+02:00 helios64 kernel: [20582.290553] regulator_balance_voltage+0x50/0x9c 2024-04-17T20:45:02.182593+02:00 helios64 kernel: [20582.290974] regulator_set_voltage_unlocked+0xa8/0x12c 2024-04-17T20:45:02.182597+02:00 helios64 kernel: [20582.291438] regulator_set_voltage+0x50/0x98 2024-04-17T20:45:02.182600+02:00 helios64 kernel: [20582.291828] _opp_config_regulator_single+0x50/0x19c 2024-04-17T20:45:02.182603+02:00 helios64 kernel: [20582.292281] _set_opp+0xd8/0x4bc 2024-04-17T20:45:02.182607+02:00 helios64 kernel: [20582.292577] dev_pm_opp_set_rate+0x18c/0x280 2024-04-17T20:45:02.182610+02:00 helios64 kernel: [20582.292963] set_target+0x30/0x3c [cpufreq_dt] 2024-04-17T20:45:02.182613+02:00 helios64 kernel: [20582.293377] __cpufreq_driver_target+0x1d0/0x344 2024-04-17T20:45:02.182616+02:00 helios64 kernel: [20582.293797] od_dbs_update+0xbc/0x1ac 2024-04-17T20:45:02.182620+02:00 helios64 kernel: [20582.294133] dbs_work_handler+0x40/0x7c 2024-04-17T20:45:02.182623+02:00 helios64 kernel: [20582.294486] process_one_work+0x160/0x3a8 2024-04-17T20:45:02.182626+02:00 helios64 kernel: [20582.294854] worker_thread+0x32c/0x438 2024-04-17T20:45:02.182630+02:00 helios64 kernel: [20582.295197] kthread+0x114/0x118 2024-04-17T20:45:02.182633+02:00 helios64 kernel: [20582.295494] ret_from_fork+0x10/0x20 2024-04-17T20:45:02.182636+02:00 helios64 kernel: [20582.295835] Code: ???????? ???????? ???????? ???????? (????????) 2024-04-17T20:45:02.182640+02:00 helios64 kernel: [20582.296383] ---[ end trace 0000000000000000 ]---

@A9 they are not errors, just missing firmware files for various wifi devices that you don't really need

Ok so RE the builds: That means that if you want to build an image that corresponds to one of versions listed here (https://docs.armbian.com/Release_Changelog/) you pretty much need to build on release day. Otherwise it is possible that some commits for the next version are already merged in and will be part of the build, right? What kind of work is needed for specific version builds to work? I guess the build scripts need to also checkout that version from other repos and today it just takes the latest of everything? And RE the version file: What do you mean with "If you want the packages you have collected to be installed..."? Is that for the OFFLINE_WORK=yes option so that the current online version appears older than the local build?

moved

I have a orange pi3 lts. I tried to install either minimal ether gnome version. Wireless is configured and working . I tried to execute command sudo systemctl enable ssh and reboot but sshd is down always and screen show always desktop orange PI without any network connection. I tried to use also u armbian-config but ssh is always down and network is down . Any attempts is not working . In addition thr desktop interface is the same in minimal and gnome version .... very strange

No clue as I don't have that box. Search the forums for information. As far as build goes, you should be reading the FAQ posts: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first https://forum.armbian.com/topic/33676-installation-instructions-for-tv-boxes-with-amlogic-cpus

With weekly image builds located here: https://github.com/armbian/community And daily rolling release apt packages (kernel and other armbian packages) located at: beta.armbian.com

Sorry didn't see your response. 24.2.1_Orangepi5-plus_jammy_legacy_5.10.160_gnome-amazingfated_desktop It runs really smoothly as is so I'm considering just leaving it.

Oh ok Now i understand. Coreelec affects armbian but still runs stock android. I'll try to reset the device to original stock firmware then. So, do you know any working armbian image for this KM1 box? I'll try armbian as soon as I restore the device.

Hi, My test parttern run and i do: helios64@helios64:~$ for i in $(seq 1 100);do python3 -c "import pkg_resources" || break;done helios64@helios64:~$ No crash to my side 😉 I never had until today my helios64 stable with 400-1800MHZ stable with my pattern test and podman container run. I think i am dreaming.... yes? not? Helios64 stable is AMAZING !!!!!

Pull Request was approved today on Github we can now clone from main. git clone https://github.com/armbian/build.git The H96-max Files can be fount at https://github.com/hqnicolas/ArmBoardBringUp

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

Monado, the cross-platform open source XR runtime, has recently received significant updates to align with the features and specifications of OpenXR 1.1, ensuring compatibility and optimal performance for developers and users alike. View the full article

I also am trying to change RasPi device tree, see my post: What I've discovered thus far: Overlays are not enabled for RasPi, if you try to do an "armbian-add-overlay" you get an error. Only way I know at this point for kernel mods that works is to change "/boot/firmware/config.txt" and "/boot/firmware/armbian.txt" . But what you can do there is very limited. Also as an aside the overlays are @ "/boot/firmware/overlays" , and "/boot/dtb/overlays". Root device tree @ "/boot/dtb/broadcom/", but I have not gotten any to load as of yet.

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

other option would be to enable DT overlays, but at present those are disabled as well.

Hello, Well, ladies and gentlemen, I done it, becoz I can't live without it when quitting cinnamon for xfce. It is like the thunar-archive-plugin (file-roller equivalent) that should be enabled by default imho. I decided to release it here , this is my gift to armbian team to thanks for their work. INSTALLATION If you follow the README.md, you will have the magic custom action added The demo: Enjoy SoSie thunar-open-as-root-plugin.zip

Worked fine 👍 Thank you. I've forwarded my Internet with a Banana Pi M3 from Eth0 to Enx00.... . It has the IP 172.x.x.1. On Enx00.... is a router with the IP 172.x.x.2 connected. But my Banana Pi isn't listed in the routers network. Is it possible to add my router to this second network?