hexdump

i would say that the amlogic mainline support is not that bad: http://linux-meson.com/doku.php - i think a few developers from baylibre were even paid to mainline stuff (not sure by whom) and there is still active development ongoing if you look at the linux-amlogic kernel maliniglist ... where amlogic is quite bad is the booting: there is no way around certain binary blobs to boot them and the way to build the boot blocks is simply crazy ... beyond that you can really brick an amlogic box quite easily, as it boots by default from emmc (but at least there are some tricks possible like https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle ) the reason why rockchip (especially rk3288 and rk3399) is so well supported is mainly because google pushed them as those chips were used in chromebooks ... for the same reason some newer mediatek (mt8173, mt8183 and in a few months maybe also mt8192 and mt8195) and snapdragon (7180c) socs are surprisingly well supported in mainline i would say allwinner has the nicest and most active developer community around it and most of the allwinner mainline code is coming from this community and some of the allwinner boards and even tv boxes can be run completely blob free even (a few rockchip ones too) best wishes - hexdump

@lucky62@kruzer@jock - problems with lightdm on arm systems ring a bell for me: can you maybe try to install and use the slick-greeter for lightdm instead of the default one? this solved some trouble for me and maybe it helps in this case too? good luck and best wishes - hexdump

@crr - if you try my image, please put your findings into a github issue of the corresponding repo ... there is another quite up to date try to get linux working on chromebooks here as well: https://github.com/Maccraft123/Cadmium - might be worth to have a look at this one too good luck and best wishes - hexdump

i think only very few came from me (most probably only the ones with hdmi output, which i mentioned to him and suggested that he might use them in his images if he likes them) ... i think most of the other u-boot.ext files in his images were either built or extraced by @balbes150 himself

@Sevillano - as said: you may try around more if you like, but i think the only chance you have is to find the original firmware for your box, as it is the only one which was build with the proper keys - this box (and very few others as well - a95xf2, mi-box, ...) is special as the boot process is locked

there was another thread regarding rk3318 here: might be worth a look ...

@Sevillano - as far as i remember the a95x max is one of the rare cases of using a signed/encrypted boot block, so erasing the emmc is not a good idea as you'll not be able to create any boot block with the proper keys to be loaded by the box - reinstallling the original firmware is your only option i guess and then bootiing via legacy u-boot and the regular balbes150 script and maybe chainloaded mainline u-boot good luck and best wishes - hexdump

@XFer012 - in case you run into any problems while trying get it working based on my notes, just open an issue on that git repo and i may try to help you to resolve them good luck - hexdump

@XFer012 - those files are not intended to be used in the armbian build system, but when building a kernel standalone. they are basically just my notes on getting the kernel compiled and working and not intended to be just dropped into an armbian build.

@XFer012 - oh - if you have the 512mb version then it might get a bit short on memory maybe, 1gb should be fine ...

@XFer012 - you can also build a kernel directly on the box - takes a bit of time, but works well - i'm building all my arm kernels on arm devices

@XFer012 - i think the best approach might be to build your own kernel and then you can change the original dts and dtsi files directly (with labels etc.) instead of dealing only with the compiled versions ... maybe my notes from playing around with the h616 on tv boxes might be helpful for you: https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel i also built a kernel with working usb and early hdmi (based on the code of @jernej): https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/tag/5.11.0-rc1-stb-616%2B - i did not test it on a orange pi zero 2 myself (as i only tried it on a h616 tv box), but at least i tried to keep the opi zero 2 dtb up to date, so it might just work all that is not a perfect solution, but maybe its helpful for you on your way good luck and best wishes - hexdump

just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3 so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?) i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs

that log looks like my mainline u-boot is not chainloaded but has replaced the legacy u-boot (as there is no sign of a legacy u-boot in the log) ... this works quite well for me but is not tested too well and worst case you can brick the box - but looks like you got it working well too maybe you wiped your emmc (accidently?) and by chance had the proper u-boot at the proper place on the sd card ... if the box does not find a boot loader on emmc then it will try to boot from sd card ... or you even by chance replaced the bootloader on emmc with my mainline u-boot ...

the situation for the 32bit amlogic socs (like the odroid c1) is that there is essentially just one single person working on them whenever time permits it ... so the only two options are to be patient or to help (which is not an easy option) or of course to forget about the board ...

i don't think that this will help - your only chance is to search for potentially fitting stock images and try them until one works ... otherwise you have a nice little s905x doorstop only ...

this should work actually as your boot block sees and reads from the sd card (SD:0;READ:0) ... there is one thing which might explain it: encrypted boot loader - very few boxes have it (for gxl for instance the mi box, s905x2 the a95xf2 for instance - or was it a95xf3 maybe ...) - in that case the only chance you have is trying to find some original firmware for the box with the proper signing and encryption - everything else will not work ... i think the reason why it ended up in this state is that someone installed another unsigned/not encrypted image on it ...

maybe upgraded or downgraded android on the box, i.e. different version of the legacy u-boot? - in case both of you have a serial console connected you might compare the u-boot version strings from early boot ...

@lcapriotti - could you maybe upload your uboot.emmc somewhere so that we can run some strings and/or hexdump on it to find out what version it is?

h6 tv boxes are usually running very hot and require a fan if you want to run them at full speed without thermal throttling in my experience ...

@N3bi2 - you may try to dd this (gunzipped): https://github.com/hexdump0815/u-boot-misc/releases/download/200718-01/boot-amlogic_gxb_atf-aarch64-serial.dd.gz to the beginning of an sd card - this should at least give you a working and booting mainline u-boot from sd card ...

@lanefu - for those amlogic tv boxes chainloading u-boot means the old legacy u-boot on the box is loading a mainline u-boot.bin (which has nice features like extlinux.conf support and allocates less memory for itself) which is then loading the kernel @SteeMan - this looks a bit like this box has a non standard mmc setup which might be not so easy to track down (one would need to extract the android dtb from the box - see: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy and then the mmc entries should be compared to the android dtbs of other boxes where emmc works - here is for instance my h96max-x3 android dtb: https://github.com/hexdump0815/linux-mainline-and-mali-amlogic-kernel/blob/master/misc.aml/dtb/meson-sm1-h96max-x3.dts.android - this is a big puzzle and a lot of trial and error might be required without the guarantee to get it working) the patch is to remove some code which will not work in our scenario (getting linux working on it) - it looks like the mainline u-boot code for the s905x3 i used as a base was only done for android which has a different partition (+table) setup than what we plan to use the uEnv.txt file is read before extlinux.conf, so things can be set there which partially cannot be defined in the extlinux.conf (which is quite limited) - in armbian that file usually is called armbianEnv.txt i think, so you should maybe adjust the filename to be in sync with armbian if you want to get it closer to a standard armbian setup just an idea: you might also try the newer u-boot 2021.01 or soon the upcoming 2021.04, but i think nothing really changed in there for amlogic @lcapriotti - it would be very helpful if you could find out how you got it to work on your box - this might getting this resolved easier for @SteeMan maybe good luck and best wishes - hexdump

... and be aware that there are quite a few fake tv boxes around (very popular for q+ too) which are sold as 4gb (and in android they even hacked it to look like this), but only have 2gb of memory built in ... so it can be that the box simply only has 2gb in the end ... maybe do an "apt-get install memtester" followed by "memtester 2500M" on the box with your 3072M setting - if it runs through stable you seem to really have 3gb, if it hangs or crashes doing so you most probably only have 2gb good luck and best wishes - hexdump

@SteeMan - on my s905x3 box the emmc has died, so i cannot test it there right now, but i'm very sure that it was working before at some point ... it might be that the mmc/emmc setup of your box is a bit different than normal and thus the chainloaded u-boot fails ... what you can try is to interrupt the chainloaded u-boot and then play around with the mmc command - "mmc list" might be a good start and list you all the mmc devices u-boot knows about and which can be sd card, emmc and sdio (which is usually the wifi card using the mmc connection as well) - after you have that list you can go through them and see which are discovered as sd/emmc via "mmc dev 0" (same for 1 and 2 if they are shown with mmc list) and then "mmc info" - sd card and emmc you can then usually distinguish by the size shown if you have different sized ones (the sdio port usually does not respond, so you should end up with two working mmc info, one for sd and one for emmc) - if you only get one working here then emmc is indeed not detected properly and you'll have to look deeper - if all are well, then maybe somewhere in the boot scripts an id number is wrong? i can only encourage you to try to build your own u-boot - this is how i started as well ... you just need patience and time to move forward ... building amlogic u-boot is not really easy and a lot of steps are required (this is actually the reason why i started this u-boot repo to kind of document all the info, which is usually spread across many places in once place), but the good thing is that the u-boot binary you need for chainloading is just the result of a simple u-boot compile and you can ignore all those many signing etc. steps required if you want to build a full mainline u-boot for amlogic ... this (full mainline u-boot) is working too but far from easy and there is always the risk to brick the box if it is too non-standard - i have a few amlogic boxes working this way, but this approach is nothing i would recommend in general, especially as the chainloading is working quite well. good luck on your path and if you run into concrete problems let me know either here if it has some direct relation to your armbian setup or just create an issue in my u-boot repo in case it is a bit too off topic for here. best wishes - hexdump

yes - i'll try all those options step by step over the next days i think