All Activity

I gave some information ..... Hit:8 http://fi.mirror.armbian.de/beta bookworm InRelease ? 🙂

For those with a Radxa Cubie A7A, I made a custom Armbian Build using the BSP kernel. The framebuffer console doesn't work right now. So you will need a usb serial device for user setup. After that HDMI works fine. https://github.com/NickAlilovic/build/tree/Radxa-A7A

I tried rebuilding the Device Tree as suggested in other forums. No Joy!! Still can't get it to work. Also added i2c-dev module but that isn't showing in lsmod. Help appreciated. Clearly I am missing something here. This shouldn't be difficult. :-)

Ok, looks like I just missed the special instructions about the recovery button. ☹️

Apparently, there are more versions of the box. One has two stars on the nameplate and "V 1.4" printed on the PCB. Although WiFi works on version 1.2, if does not work on this version V1.4 has a different Wi-Fi chip: EA6521. dmesg | grep 'SDIO' gives: [ 9.621165] mmc2: new ultra high speed SDR104 SDIO card at address 8800

https://paste.armbian.com/qocicuyote.yaml <-- captured from debug UART Brand new odroid-m1, Samsung Pro Endurance 256GB; and a brand-new/uninitialized Samsung PM9A1 256GB NVMe. It drops me to a shell [presumably the initramfs]. Note: I'm not out of options yet, I can try building my own image with newer current or edge kernels. Edited to add: I think it's booting me to the petitboot env, not even attempting to boot the SD card,

> drop them. > drop it. sorry. Someone is dropping something here I'm not sure if support was ever better or downgraded at one point because it never had it's own page on the site, it's just a mention of a device tree file swap under orange pi 5, which is listed as standard. If it's not different enough to warrant it's own page, it's entirely reasonable to think it is supported as much as the orange pi 5, under which it can be found. The max, plus and pro variants all have their own pages. 🤷‍♂️ I do understand how tooling works, as I've spend enormous amounts of time digging through the repo and modifying it. Mix and matching patches, modules, or loaders from other projects where their stuff works , and armbian's doesnt or visa versa, to get full functionality images across for the 6 different sbcs I've got. Often times certain projects will have things like vpu figured out way before other projects.

@emor acid The build system downloads the original uboot and kernel sources. Then it applies the patches on top. Whatever you edited will be erased. The only way around this is to create a patch with your changes. You could use dtc to compile your dts file into a binary dtb. Then copy it into your sdcard.

Thanks for the update. I really appreciate your help.

I have a question. After making the modifications as described above and executing the `compile.sh` script, the file `arch/arm64/boot/dts/allwinner/sun50i-h618-x98h.dts` reverts to its original state. Is this normal? How can I determine if my changes have been compiled into the image? @Nick A

Yesterday I did start to install armbian trixie iot on my Pinebook. Second part in debian - after the u-boot) starts, but then the Pinebook shuts off, because of a low battery(?) I did charge the whole day and powered off in the evening. Today the Pinebook stand on my table with a swollen battery. I removed it and happily it doesnt crash anything else than the battery holder. But now it doenst boot up complete like with a low battery. After the u-boot debian trixie does boot , but at the middle of the messages it does shutdown Can it run completly without battery? I have normally a 5V/2Ah power-supply connected and that did work the last years. Now I can only try to use a 5V/60W quick-charge Power-Supply. Anyone has experiences with that? Thanks for info in advance...

Continuing the story. Or 4pda (Russian).

If you have patience, CEC may work at some point with mainline kernel. There is not fast solution.

See There is an issue with the build framework that prevents base-files from being built for the arm64 target. At present time the issue is unresolved, and the root cause might be still unknown.

I ran into the same problem when setting up a retroarch based gaming system with Armbian Debian Trixie. I wanted to use my Dualsense 4 controller with it but couldn't get it to work on Vendor or Current. I later realized that you need to enable `LEDS_CLASS_MULTICOLOR` and `HID_PLAYSTATION` for it to work with the controller. This was only present from the kernel 6.2 and involved compiling the kernel after enabling those flags. I got that working in current and edge but I lost HDMI-CEC. The edge kernel at the time is 6.18.0 for rock 5b. Is there any way forward to get both functionalities working? I see that HDMI-CEC is listed as `n/a` under rock 5b here: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md.

didn't even realize you were on beta repo. Well when you use bleeding edge, you have to be prepared for breakage since it is expected ;).

https://github.com/armbian/os/commits/25.11.0-trunk.367/git_sources.json This file determine state (hash) of sources. It's not a straightforward process, but one can recreate exact image (except userspace packages, which versions are not stored) This file has to be here https://github.com/armbian/build/commit/31e82512cc60a74f56b710aa2971d7dc2beec9b9 One day, this will be done better Sadly there is too much of such e-waste and way way too little people willing to maintain them in their limited private time. I am sure you can find a working image somewhere in our archives so you don't need to throw it away, but we cannot fool you & ourselves to be able to keep this board maintained.

I came from 4pda to armbian and I came from there already being a prejudiced person. this is just another normal day in the TV box section. Many other users have already encountered similar problems with Chinese boxes. you can solder a better module like @Deoptim

This is the hint I got from AI 🙂 I changed the repositories from beta to stable and installed: sudo sed -i 's|beta.armbian.com|apt.armbian.com|g' /etc/apt/sources.list.d/armbian.list and sudo apt download armbian-bsp-cli-orangepi3-lts-current sudo dpkg --install --ignore-depends=base-files armbian-bsp-cli-orangepi3-lts-current_25.8.2_arm64.deb Now it's OK....but is this the right approach?

How did you determine this without holding the board in your hands? Without connecting the uart? The chips are located on both sides of the board. Assuming that h5anag8najr-wmc is a fake label and that the chip is 1Gbx8, the u-boot output on the uart should be Row=17 CS=2, not ROW=16 CS=1. Or am I wrong? If the board allows you to work with two ranks and the CS-1, A14, and A16 are present (on the board), then u-boot should display ROW=17, CS=2 Size=4096MB. BUT, the bootloader does not recognize the 2nd memory rank. https://github.com/hqnicolas/Rockchip-Library/tree/main/RK356x/rkbin - It is not possible to build rk356x_spl_loader_v1.xxx.bin, also known as the miniloader, using this link. There is no tools directory in this section. I managed to figure out how to assemble rk356x_spl_loader_v1.xxx.bin using different (rk3566_ddr_528MHz_ultra_v1.10, rk3566_ddr_780MHz_ultra_v1.10, rk3566_ddr_920MHz_ultra_v1.10, rk3566_ddr_1056MHz_ultra_v1.20, as well as rk3566_ddr_920MHz_v1.23, rk3566_ddr_1056MHz_v1.23.) I also managed to build u-boot - I'll have time to test it all. It's a pity that few people share information. P.S. If you look at https://github.com/hqnicolas/Rockchip-Library/blob/main/RK356x/u-boot/socfpga/rk3568_common.h, you'll see #define SDRAM_MAX_SIZE 0xf0000000, which limits the size to 4GB. Therefore, it is possible that u-boot is built with a 4GB SDRAM limit. However, I also assume that the memory could have been tampered with. I would benefit from obtaining U-boot's UART output from those with NT5AD1024M8A3 memory. Currently, I am considering three options. 1. U-boot is built with SDRAM_MAX_SIZE 0xf0000000 limitation 2. rk3566_ddr_xxxMHz_v1.xxx.bin - does not recognize the 2nd rank (2R) of Hynix h5anag8najr-wmc memory 3. Memory labeling is still fake

@erebus041 @Nick AOne small detail: I've used etchdroid and drofus to burn my sd card.

Well, the source code is still on github so you could try building it. I can't find that tag in `armbian/build`, but did find `v24.11.0-trunk.303` It does build [I guessed at jammy, maybe it should be noble] time ./compile.sh build BOARD=jetson-nano BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=yes RELEASE=jammy KERNEL_CONFIGURE=no KERNEL_GIT=full ARTIFACT_IGNORE_CACHE=yes [🐳|🌱] Fast-moving file to output/images [ -> Armbian-unofficial_24.11.0-trunk_Jetson-nano_jammy_current_6.6.116_minimal.img (4.07GiB) ] [🐳|🌱] Fast-moving file to output/images [ -> Armbian-unofficial_24.11.0-trunk_Jetson-nano_jammy_current_6.6.116_minimal.img.sha (202.00B) ] [🐳|🌱] Fast-moving file to output/images [ -> Armbian-unofficial_24.11.0-trunk_Jetson-nano_jammy_current_6.6.116_minimal.img.txt (19.29KiB) ]

@erebus041can you please provide the link of Yuzuki Chameleon images?

Ok. Also I think these are wrong for the PI5: dtoverlay=disable-wifi dtoverlay=disable-bt I believe it's: dtoverlay=disable-wifi-pi5 dtoverlay=disable-bt-pi5 My notes on this: # Pi3 / ZERO2W dtoverlay=pi3-disable-wifi dtoverlay=pi3-disable-bt # PI5 dtoverlay=disable-wifi-pi5 dtoverlay=disable-bt-pi5 # Everything else dtoverlay=disable-wifi dtoverlay=disable-bt Back in the day, I read somewhere that Bluetooth can inhibit serial from functioning correctly on the Pi's. I've never seen it happen, but maybe using the wrong overlay is hindering it in some way? Worth looking into.

I just noticed from your screenshot that you aren't using Armbian. You need to ask support questions for non-armbian software from where you got your software. Ophub is a fork of Armbian that used the Armbian name without permission. They do not contribute to Armbian development nor do they contribute the these forums.