All Activity

@Ducdanh Nguyenyour axp chip should look similar to this

fully agree with author statement. The same as change from ethx to endx is a step in wrong direction. Somebody was using windows too much. ifconfig is not even installed by default because of ip command. Distribution managers should be forced to stop such things. @laibsch "when you bring a network interface up or down that can obviously affect firewall rules" Is it a joke?

@Ducdanh Nguyen H313 is basically the same chip as H616.

@Nick Ai don't see any h313 on the page, maybe i will just tear it down again

i should add some details: minimal version which is from yesterday for download, which has short description: "optimised for automation and production deployments" doesn't say too much. No idea what it means without better description. it's not in any of defined categories defined in faq. Is there any specs how to get sources and compile it for my small server with sata drive? I was not compiling kernel for about 30yrs+ however could do it with good specs . Many things changed... like even sources are not accessible as they were in the past. Naturally specs which i've seen is not the way to go.

Yes, but since this created device isn't mounted anywhere it makes no sense - no service or whatever could use it anyway, what definitely turns this creature into just waste of RAM for nothing, am I wrong?

I explained above what zram is created for. OPi3LTS should have 2G of memory, so having 1G of zram makes perfect sense here.

@fevangelou nice guide. THX! but maybe it would be best to have the instruction in an separate topic! in best case it gets also pinned. so new users can find it much easier than scrolling though 18 pages (in this thread. there is also the 4gb thread) to find it......

@Ducdanh Nguyen you should be able to see it on the board https://linux-sunxi.org/AXP_PMICs

You are completely right - at least 50MB one is there /dev/zram1 on /var/log type ext4 (rw,nosuid,nodev,noexec,relatime,discard) But big 987MB /dev/zram0 isn't at all - so it looks like it's useless and could be removed from zram config, right? Both mystic /dev/mmcblk2bootX are still in question

Hi All What is current working image for banana pi pro? Can't find any except one in archive (bookworm) which is not perfect.

Have you checked "mount" command to list actualy mounts? I am quite confident mount is happening by the ramlog service and is not integrated into fstab. some more background: sdcards have a limited amount of writes until its cells die. Since everytime some service or whatever writes some logs this issues a write event. To drastically increase the lifespan of the microsd log entries are buffered to (compressed) memory and then recurringly written all at once.

In fact in image's default fstab they aren't mounted so those probably could be assumed as a kind of waste of RAM this way? Or there is chance that they actually mounted somewhere else but fstab? root@heaven:~# cat /etc/fstab # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 00 UUID=fb077685-a428-49f2-b013-287dc5fc9672 / ext4 defaults,noatime,commit=120,errors=remount-ro,x-gvfs-hide 0 1 Thank you for tip regarding /var/log, I was suspecting that it should be there as soon as device created. Do you mean to inspect with binwalk/strngs those devices in hope to find out what is there? I'd gave a try - there is nothing: root@heaven:~# binwalk /dev/mmcblk2boot0 DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- root@heaven:~# binwalk /dev/mmcblk2boot1 DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- root@heaven:~# strings /dev/mmcblk2boot0 root@heaven:~# They also can't be mounted - dmesg excerpt: [390869.014377] F2FS-fs (mmcblk2boot0): Magic Mismatch, valid(0xf2f52010) - read(0x0) [390869.014508] F2FS-fs (mmcblk2boot0): Can't find valid F2FS filesystem in 1th superblock Magic mismatch - mystic things unsolved)

Yes I'm aware that I can only rely on the community for any help or tip. I'm now considering to revert back to a bullseye setup with a 5.10 Radxa kernel, but I was kind of reluctant to keep an old version of Debian as my Rockpi is accessible from ouside my network... The Rockpi is powered by a PoE hat, it never had any issue so far but maybe the PoE management is the culprit. I'll try an use the Rockpi with a traditional power supply, but in any case if this is the issue it won't be a sustainable solution for my target setup.

Thanks @eselarm for the input that this should work. So I tested it. And it does! I leave a few hints for anyone who wants to replicate. When creating a new image layout working directly with the image files was the fastest for me. So you need to download one original Armbian image. I used a minimal cli image. Image preparations Create a new image file (e.g. with dd) that will be partitioned like described above. Copy all the first sectors until the first partition starts from the original image to the new image. This will copy the original partition table but more importantly also the uboot bootloader into the new image (32768 sectors = 16MB). Partitioning Partition the new image as described above (e.g. with fdisk/sfdisk) and format the new partitions. One smaller boot partition (e.g. 512MB, ext4) and two bigger root partitions (e.g. 3GB, ext4). I will use the terms rootA and rootB for the two new root partitions in the new image from here on. Get the UUIDs of the newly created boot and rootA partition of the new image (e.g. lsblk/blkid). Most likely instead of using two separate ext4 rootA and rootB partitions one bigger btrfs partition and the usage of subvolumes could be possible. But I did not test this. Copy boot and adjust Mount the new boot partition and create directories bootA and bootB and a relative symlink boot pointing to bootA. Place all files from the original image’s /boot directory into bootA of the new image. Adjust the UUID line in armbianEnv.txt that still points to the original image’s root partition to the rootA UUID from the new image. Copy root and adjust Mount rootA and copy all the files from the original image into it. Remove all files from the /boot directory in rootA as we will mount the boot partition into this directory anyway and do not want to get mixed up. Create a new directory /rawBoot in rootA. Edit the fstab of rootA and change the UUID that still points to the original image’s root partition to the rootA UUID. Add a line to fstab to mount the boot partition of the new image into /rawBoot. Add a line to fstab to bind mount the directory /boot of /rawBoot into /boot of rootA. Add an empty file /root/.no_rootfs_resize in rootA to avoid the partitions being changed if the original image was never booted before. I did all of the above also with an archived older Armbian image and put that into rootB (and bootB). With this setup we now have two separated OS versions. They can be switched by simply changing the boot symlink to bootA or bootB and reboot. Because we used bind mount we can also do kernel upgrades which end up in the correct directory. As all of the steps are easily automatable by a shell script we can now download a new earlier prepared update package place its content into the other boot directory and partition adjust their UUIDs (and maybe copy SSH keys and machine-id if we want to keep system identity) and change a symlink. If we need to go back to the older image just the symlink needs to changed back. Either from within a running system or if that is not possible by taking the card out and doing this externally. As I said earlier this A+B update scheme is not as robust as other tools. But we can stay with prebuilt images from Armbian that can be locally configured the way we want it. After this an update package can be created and distributed which could also contain a new uboot. If this is tested well before distribution I guess most errors that make the other tools so robust can be avoided.

Good question. Have you tried to use binwalk oder strings on it? One is for ramlog and should be mounted to /var/log. The other is zram which by default is half of your actual memory. In the early days SBCs hat very limited memory, so using zram was a simple way to increase that by sacrificing some cpu resources. Nowadays SBCs come with a lot more memory and some may not even need zram anymore. Depending on your setup you can disable it as well. Check /etc/default/armbian-* files.

Please give me a tip - what is purpose of /dev/mmcblk2boot block devices created? Quite small size - 4MB - ones, do they serve to something u-boot needs at boot time? There are no records for them in fstab so I assume they are created by zram, but what happens to them after boot when they aren't needed anymore? Board Orangepi 3LTS with bookworm minimal Also as a matter of wondering - why there are two zram devices: one of 1/2 of RAM (as usual) and another of quite small 50MB only, what is it for? root@heaven:~# fdisk -l <redacted> Disk /dev/mmcblk2boot0: 4 MiB, 4194304 bytes, 8192 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mmcblk2boot1: 4 MiB, 4194304 bytes, 8192 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes <redacted> Disk /dev/zram0: 987,53 MiB, 1035497472 bytes, 252807 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes

I Did It! I Got It Working!! ES8388 Analog Audio Output Here's How (this is very easy to do): It just involves making one simple modification to the devicetree. Note: I did this with the Edge kernel. My guess is that it will also work with the Current kernel. You can also try the Vendor kernel if its devicetree has the same code. I manually applied this patch: https://patchwork.kernel.org/project/linux-rockchip/patch/20250823-orangepi5-v1-1-ae77dd0e06d7@hotmail.com/ If you scroll to the bottom where it gives the patch, the GPIO_ACTIVE_LOW needs to be changed to GPIO_ACTIVE_HIGH in the given section of the devicetree. Here's the simple / quick way to fix it, without having to go through any lengthy (re)builds. Modify the already installed devicetree file (/boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb). 1. Install the package: device-tree-compiler 2. Backup the original, and convert to .dts format as follows: # Go to your devicetree directory cd /boot/dtb/rockchip/ # Make a backup of your original devicetree: sudo cp rk3588-orangepi-5-plus.dtb rk3588-orangepi-5-plus.dtb.bak # Use device-tree-compiler to convert the file from the binary .dtb format to textual .dts format (ignore the warnings) sudo dtc -I dtb -O dts -o rk3588-orangepi-5-plus.dts rk3588-orangepi-5-plus.dtb # Safety-Check Part 1: Convert right back to .dtb format (another filename), ignore the warnings. sudo dtc -O dtb -I dts -o rk3588-orangepi-5-plus-test.dtb rk3588-orangepi-5-plus.dts # Safety-Check Part 2: Compare the newly converted file with the original. They should be identical (this command should produce no output) cmp -l rk3588-orangepi-5-plus-test.dtb rk3588-orangepi-5-plus.dtb 3. Using a text editor in sudo mode, edit the text file: rk3588-orangepi-5-plus.dts Search for this phrase: simple-audio-card,hp-det-gpios I should appear exactly once in the file. # Here is what that line looks like (for me): simple-audio-card,hp-det-gpios = <0x133 0x1b 0x01>; # This is that same line before original compilation simple-audio-card,hp-det-gpios = <&gpio1 RK_PD3 GPIO_ACTIVE_LOW>; 4. Notice between the brackets, there are 3 values, separated by spaces. The third value is the value to modify from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH, or for us, from 0x01 to 0x00. 5. Convert your modified .dts file to a .dtb file (ignore the warnings): sudo dtc -O dtb -I dts -o rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dts # Optional: Quick Comparison Check (this should output exactly 1 line with 3 numbers: [big number] 0 1) cmp -l rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dtb 6. Copy the new fixed file to (overwriting) your original: sudo cp rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dtb 7. Reboot (and have ES8388 analog audio out). Note: Whenever you do a kernel change or update, you will need to repeat this process until the Armbian kernel updates catch up with this patch. Here's the lengthier explanation (this is repeatable if you want to check it out yourself) 1. I downloaded the source code for version 25.8.1: https://github.com/armbian/build/releases/tag/v25.8.1 2. I extracted the archive and started the building process (./compile.sh) with the edge kernel (and a desktop image). It would not build because it rejected two of the kernel patches, but it did download everything into the cache. 3. I then found the file described in the patch: ./build-25.8.1/cache/sources/linux-kernel-worktree/6.16__rockchip64__arm64/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts 4. In that file, I searched for the line indicated in the patch, just prior to the line to modify: simple-audio-card,aux-devs = <&speaker_amp>, <&headphone_amp>; ...and found the appropriate section. I confirmed the line that followed matched the original (incorrect) version mentioned in the patch entry. 5. I then scrolled to the top of the .dts file and looked at the files #included, to find where the GPIO_ACTIVE_LOW macro was defined. I figured dt-bindings/gpio/gpio.h was a reasonable place to look first. I found it here: ./build-25.8.1/cache/sources/linux-kernel-worktree/6.16__rockchip64__arm64/include/dt-bindings/gpio/gpio.h Near the top of the file were these #defines: /* Bit 0 express polarity */ #define GPIO_ACTIVE_HIGH 0 #define GPIO_ACTIVE_LOW 1 6. See the simple fix above for the rest. Tags: @Werner, @Igor, @laibsch @dimaxus, @EricaLina, @ricardo_brz, @eselarm

@Nick A sorry, i haven't got any information about the axp chip, i will do the reseacrch

@Ducdanh Nguyenthe secure boot patch is safe it doesn’t burn any fuses on your SOC. you still haven’t answered the axp chip question. If it doesn’t have one then it’s not a h313. The newer allwinner SOC’s use a axp chip for power management. If I don’t have that information then I don’t know which image to recommend.

@Nick A oh yea i used aida64 all the time (and with alot of command line commands), that's where i came up with h313 since it uses cortex-a53, the clock speed and the arch is 64bit armv8 (on 32bit mode) and about the secure boot patch, i think it's too risky (since it is a fake box and diffrent dram settings, etc,....) and i think i will buy a cable and test the su command, if it works, i will dump the boot.img and extract it

I had the precise information about data-offset from "--examine" mdadm command, and also I was in raid1, that's far less sensitive to error than raid5 or raid0 for example. I would not have been surprised that the resync, if taken to the end, would have worked... But I will never know. As far as I know, I get the data back and I'm very lucky and happy. Thank you

It's already been my intention to do so.

well, I'm certainly happy to hear the good news. consider yourself lucky. creating a raid with mdadm should certainly overwrite all your data. Maybe you got lucky, maybe because you recreated it in the exact same way as before. who knows. what counts is that you did not loose everything after all. because that sucks.

Hello and thanks for your answer. Seems that no, I'm trying R-studio now and it's finding 7 superblocks, and for now it has found 5000+ files... Will try to get this back after the scanning.