Hi guys, I have a Espressobin V7_2-1 Model: Marvell Armada 3720 Community Board ESPRESSOBin (eMMC) CPU 1000 [MHz] L2 800 [MHz] TClock 200 [MHz] DDR 800 [MHz] DRAM: 1 GiB Would you be so kind as to make the flash-image-DDR4-1g_1cs_5-1000_800.bin?

Bluetooth now working, no compiling required via hciattach. I don't know how much of this is necessary because I generally don't know what I'm doing. But here goes. Apparently hciattach is a legacy app that requires the firmware to be in /etc/firmware so I made a folder and setup a symlink before running the hciattach. sudo mkdir -p /etc/firmware sudo ln -sf /lib/firmware/aic8800_sdio/*.* /etc/firmware sudo hciattach -s 1500000 /dev/ttyS1 any 1500000 flow nosleep sudo hciconfig hci0 up Bluetooth should be available now. You can test it with sudo hcitool -i hci0 scan This will display any devices in the area the bluetooth adapter has detected. I had installed armbian-firmware package so that might also be required but I doubt it. I will flash a new image and start from scratch just to make sure everything I've stated works on a fresh install and then update the thread. The hciattach commands do not persist through a reboot so I need to figure out how to get this to run on startup, hopefully the easy part. Thanks for all the help. Hard to beat that feeling when you spend hours troubleshooting something and it fires up for the first time!

Some context: https://docs.armbian.com/User-Guide_FAQ/#why-things-stop-working The hardest part and expensive for time is keeping functions working while kernel changes, goes up. Image you are referring too is probably a demo image with some ancient kernel that will never be changed. This is usual way to sell hardware. It is made to work, but you will stay at this very old SW stack without any real option to change or fix anything. All functions on 300+ boards, which on top of extreme diversity, have also different revisions, quality issue ... is already not possible to keep up by entire open source community. Armbian is small part focused into SBCs and we do what we can. Work we are doing is never complete, we (nobody) can't solve bugs and especially not near to (expected) real-time. We (or community open source in total) can address a problem within weeks or months fastest as resources are tiny compared to problems that are constantly found in open source code that somebody else made. We have no option to expand the team / project as users don't care about well being of SW developers. We can only try to keep SW stack operational on a best effort principle. Once this job becomes too expensive (<1% of costs share is on users side), we have to step back and declare support as "community". We will continue to build and ship images as they might still work for some use cases and as downstream projects will provide those Armbian images anyway.

A month ago when doing test boots and power measurements, see I discovered that when using the RPL 27W 'Pi5' PSU, the NanoPi-R6C with the indicated bootloader(s) and kernel(s) sticks to 5V. But when using a 45W USB-C PD PSU from a HP laptop or 60W USB-C PD PSU white-label, switch is made I saw on a USB-C PD power measurement device that was also in the chain. More detailed USB-C PD protocol analysis seems to be needed in order to figure out what happens. One could guess 3A is requested at highest possible voltage as with the 45W PSU, I saw 15V. 9V or 12V would also be OK, but the PD handler cannot be 100% sure I think, depends also what is inserted in USB type-A ports on device etc.

does emmc working yet?