All Activity

These are forums for Armbian Linux, not Android.

I'm looking for an Android 10 image but I haven't been able to find one, but I still need to do the cut to know.

What image are you trying to load?

Thanks for replying, I hadn't noticed the android thing, I have two sd cards one with the radxa android 14 and the other with the debian bullseye from radxa. I didn't mess with the SPI flash because both work correctly, does android flash the spi when booting, I don't understand how it works with the default debian but not here? I will try to maskrom mode and update. Btw here is the whole boot sequence in case it helps (I tried an older armbian build here but still the same). serial_log.txt

Did someone managed to make it work on this model below? I tried creating the image with different allwinner chips but its not booting when I burn the sd and insert on the device. The tv box is a Mortal T1 Android 13 2gb ram and 16gb rom

I am glad that you have the first 15% done: get your kernel module in the OS, and the uboot accepting the DTBO Now you are stuck in correcting the DTS, so that it configures the SPI pins correctly. My last advice for you (through this stage) is: make sure you don't have anything else using SPI pins. Deactivate "spi_dev" in armbian-config. Since I only had experience with H3 and H618 CPUs, I can't help with confidence. Post your question in the appropriate Rockchip forum section for up-to-date reliable advice. I can say that Radxa/Waveshare DTS is very out of date: it uses the fb_ili9486, which is "framebuffer" (poor fps), instead of the modern "DRM" display driver (high fps, will allow wayland). You should stay with that DTS with fb_ili9486, because it is still the closest starting point for you, and when you have it working, claiming all the GPIO pins needed, I can help again to use the DRM driver panel-mipi-dbi. Regarding MISO and MOSI, I only meant to change that nomenclature in the graphic that you show in the forum. I did't mean to change it in the DTS, if that's how other people make it work. Maybe you need to have the full linux source, so you can decompile the DTBO correctly, showing the gpio pin addresses or symbols. Is it possible that you get the Radxa/Waveshare original DTS?

@laibsch: Thanks, but your objections are worthless. You have zero sense of humor, son. @esalarm: As a Debian user since 1997 I did an aptitude purge between trying daemons. I can not make any of them set the time, as they usually do in normal Debian. There is something missing in the most current stable Armbian. I wish you would try it on an N2+. I am happy to use chrony, as I have for several years, although in this case it has no effect. But the new Debians seem to be moving to systemd for everything such as this, so I adapted. But that didn't work either. I can't be the only one; maybe the first?

Thanks @dale I'll test it out on my box first and add it later on today.

Hi, I've attached a photo so you can help me figure out where to connect it to create the short circuit and get the USB Burning Tool (Maskrom Mode) to recognize it. https://ibb.co/xKPt529n I couldn't upload the image, error -200

Thanks for the reply! I'll address everything one by one: I am using the generic red ili9488 3.5inch TFT available everywhere, in this case at this link. I also have a generic red ili9341 2.4 inch TFT I purchased years ago to also test with. Neither seem to work with the DTS. It is definitely not the blue 3.5 inch waveshare screen which looks significantly different. Yes, uboot messages through serial console confirm my dtbo is found and applied without errors. No FDT errors. Applying user provided DT overlay spi1-correctedgpio.dtbo panel-mipi-dbi.ko exists in /lib/modules on the custom compiled armbian running kernel 6.18, but not on the unmodified armbian provided image running kernel 6.12. When building armbian for panel-mipi I confirmed it was selected and it was marked "M" according to the github instructions. Here's the interesting one - basically every GPIO is unclaimed including the ones I have hooked up for the display when doing Here's the link to the rock3c DTS I'm referencing. The Rock 3 pins are named very differently so I translated as best as I could to my rock 4, but I believe they are correct as I found that Radxa distributes a waveshare clone DTS for the rock pi 4 and the pins are named as I have named them. I've pasted the waveshare clone DTS distributed by Radxa below for reference. Using MOSI and MISO do not work, and according to the waveshare DTS I should be using spi_tx and spi_rx. Will continue trying MISO and MOSI in future edits though as it doesn't hurt. You mentioning the waveshare display made me look into the DTBO distributed by radxa OS, I copied it to armbian and tried using it with the red display, and while it expectedly does not work, the pins I expect show up EXCEPT for touch IRQ, which is still unclaimed. I labelled touch, DC/RS, and reset pins for ease of reading in parenthesis. This makes me think I might have success formatting your ili9486 DTS to be similar with the waveshare DTS to get panel-mipi-dbi working on my red LCD. I get dmesg messages so its definitely closer. Here's the full waveshare DTS, note because I decompiled the DTBO with the dtc command, it looks like it lost the target pointers so I'm unsure (but can guess) what they point to. The GPIO pins are also lost but I know what pins they refer to as their pin number is in hex and I can narrow them down to the only pins available according to the pinout diagram. This doesn't affect the DTBO function as I paste the DTBO directly without decompiling, so in theory that should be unchanged and fully functional. At the very least, it claims the GPIO correctly.

@thanh_tan You found one armbian image to boot on Orangepi4A?

Still not. Debian starts to load but then gets stuck (see photo above). I have tested again with a bookworm image and it worked. So there may be something wrong with the trixie image unfortunately 😕

We don't deal with Android here. Ask vendor or at some place like xda developer forums.

Hi @djurny, Yes it’s nice to tinker just so busy/tired that I’m not even doing that on the Windows side anymore. Still like the helios64 and would love to bring it up and running stable when needed, was just curious if worth the effort so looking for some success stories. I only plan to use it as a handy backup device which does sound strange for something unsupported. I think I’m still on buster as well on the sd card and never had the instability issues discussed around here (I think I mostly let it run 3 or 4 days at once in the first couple of years just to see if anything happens and did not). But I do read around here every couple of weeks. Thank you for your time!

Try from here: https://fi.mirror.armbian.de/dl/rock-5b-plus/archive/

I can't mount the SD card to do the modification... It says the GPT table is corrupt. Well that may explains why belenaEtcher throws an error. I used USBImage instead, it doesn't throw an error but the main GPT table is still corrupt. I have tested with 2 different SD cards. I believe there is a problem with these Trixie (Desktop) images for Rock 5b+. (Yes I have checked the checksum after the download) I'm currently downloading the older bookworm image to check if it works, and that there is no hardware issue.

hello please need the stock firmware to reflash please

edit /boot/armbianEnv.txt and set verbosity to 7 to get an idea about what happens inside.

I have erased the SPI ROM. It boots from the SD Card now, thanks :-) But now I have another problem 😕 It boots, it start to load Trixie, but after 30s it get stuck here:

This should work too. Debug boot issues: https://debug.armbian.de Related perhaps: https://github.com/armbian/build/pull/8994

Logs from what? It doesn't boot from SD, I have a blank screen. Should I erase the SPI ROM to make it boot from the SD again? https://docs.radxa.com/en/rock5/rock5b/low-level-dev/install-os/rkdevtool_spi

Can you provide logs?

But it doesn't boot from the SD card anymore 😕 The bootloader is expecting the OS on the NVME drive.

Just boot from microsd and then use armbian-install to move image to spi/nvme directly attached?

Hello I have burned bookworm onto a sd card,booted on it with a Rock 5B+ and installed the bootloader on the SPI flash of the board and transferred the OS to the nvme drive. Now I I'm trying to install the new trixie image, but I can't burn it on my nvme drive. With USBImage it does not work. It doesn't detect my nvme drive installed on my USB adapter. With belena Etcher it throws an error during the validation of the image. Win32Imager doesn't load at all on Windows 11. I don't know which other tool (Windows) I could use. I'm stuck. How can I boot again from my SD card on a Rock 5b+?