All Activity

I believe renegade uses a diff bootloader but seems logical that firmwares would be different given different hardware

@Nick A do you know how to remove key ring error? [🐳|🌱] git: Fetch from remote completed, rev-parsing... [ 'debootstrap-debian-devel' 'master' 'FETCH_HEAD' ] [🐳|🌱] Debootstrap version [ '1.0.142' for /armbian/cache/sources/debootstrap-debian-devel/debootstrap ] [🐳|🌱] Installing base system with 5 packages [ Stage 1/2 ] [🐳|🔨] I: Retrieving InRelease [🐳|🔨] I: Checking Release signature [🐳|🔨] E: Release signed by unknown key (key id F8D2585B8783D481) [🐳|🔨] The specified keyring /usr/share/keyrings/debian-archive-keyring.gpg may be incorrect or out of date. [🐳|🔨] You can find the latest Debian release key at https://ftp-master.debian.org/keys.html [🐳|💥] error! [ Debootstrap first stage failed /armbian/cache/sources/debootstrap-debian-devel/debootstrap bookworm yes ]

Thanks a lot @Nick A I will give a try now. I see few more device support added on your fork https://github.com/NickAlilovic/build Can I get the change log only for IK316/H616 with LPDDR2 RAM support? I would like to sync those changes with the most recent upstream source code.

This is confusing for me. What are you actually trying to achieve? What is on Renegade that is not on Rpi?

Even just someone kicking in with yes I think it's possible but not sure how or whatever I'd been thinking to ad the armbian repo hosting firmware files but I doubt it's so simple in practice

@Jeeva Kandasamy I noticed the same problem with my older builds. Should be fixed now. You'll need to install Docker. Also, if you see the build-root errors. Run the same compile options again and it continue where you left off.

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

Apologies! I managed to find another post after a while and the answer was to untick the panthor device tree! It works now, amazing!

Was on the edge vendor kernel and now swapped to 6.1.115-vendor-rk35xx And i just cant seem to get full hardware functionality with Jellyfin, Specifically tone mapping and subtitle burning crash. Atleast the tone mapping seems to be a lack of /dev/mali0 Is there a kernal or version that has all the drivers / firmware support for a fully jellyfin use? Sorry if I'm mincing words.

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