All Activity

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.

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

yes!

@erebus041Thanks for the details.I'll try and i hope it works.

So you are saying that when you copy the working SD card install (by working I mean that it has the correct memory amount) to emmc that the problem occurs?

@c0rnelius I will try that too, along with some other ideas that I came across. I won't have time to work on this during the weekend, but I will get back to you early next week. Appreciate your patience!

Hi. I installed Armbian Server on my TV box (Ugoos X3 Pro 4/64 x905x3) to the NAND, and I have some trouble with the RAM size in the system. I use meson-sm1-ugoos-x3.dtb. It turns out that only 1.8GB of 4GB RAM is available in the system. On the Russian forum 4PDA, I found some information on how to fix this. I repacked the DTB file and changed memory@ from 0x40000000 to 0xFF000000. After that, 3.8GB RAM appeared in the system, but it turned out the system was unstable and randomly froze. However, when I installed Armbian from an SD card, all 3.8GB RAM was available in the system, and the system worked fine and stable. I also used meson-sm1-ugoos-x3.dtb. Is it possible to fix this and use all available RAM?