hexdump

@SteeMan - there is no pressure to do it quickly or at all ... if you should look at it and have questions, just ask me here (i'm reading here regularly, but sometimes with a few days delay) or create an issue in my github repo. i'm always happy to see that you are keeping the amlogic boxes stuff alive pretty well in armbian.

you might try to write (after gunzip) this u-boot boot-amlogic_gxl_a95x-r2-atf-aarch64.dd.gz from https://github.com/hexdump0815/u-boot-misc/releases/tag/250629-01 which i built some time ago via "dd if=boot-amlogic_gxl_a95x-r2-atf-aarch64.dd of=/dev/your-sd-card bs=512 seek=1 skip=1" to the sd-card to which you wrote the armbian image before and see if it boots (never tested it with armbian) - build instructions for that u-boot are here: https://github.com/hexdump0815/u-boot-misc/blob/wip-v2025-04/readme.gxl ... alternatively you might try to boot this (non armbian) image to see if that u-boot works at all on your device: https://github.com/velvet-os/imagebuilder-testimages/releases/download/autumn-release-2025-testimages/aarch64_mbr_uefi-aarch64-trixie-251016.img.gz (please keep in mind that anything around that image is not related to armbian and thus should not be discussed here as i do not want to hijack this armbian thread) @SteeMan - in case you are interested in getting some of this into armbian, maybe have a look at it and i can try to answer potential questions around it - this was just some experiment to boot amlogic via the u-boot uefi implementation and grub which worked out quite well - as a result an amlogic tv box feels a bit like a pc with a normal grub boot on the screen ... should be possible to make that work for many of the supported amlogic socs - i simply do not have the time to look further into this right now ...

not sure what the current state of this is, but i think megi always had a hack to make it working in their trees - maybe just try to apply the corresponding patch from the last commits of https://codeberg.org/megi/linux/commits/branch/pbp-6.18 to your kernel build and see if it works? good luck and best wishes - hexdump

@pochopsp - you can buy two tv-boxes of the same type at once from the same seller and they might have different hardware internally still - that is the reason why it is not prossible to provide really good images for tv boxes: the hardware is simply too random and often also low quality

@pochopsp - as you contacted me via message directly, let me respond here: i can only repeat what @SteeMan already said - you can either do your own research and experiments if you get some newer u-boot built and working (which will be a lot of learning and effort and can also fail in the end) or you accept that running from emmc will not work on your box and continue to use an sd card (which should work nearly as good as running from internal storage) - there is no easy tutorial to get it working, either it works out of the box (as the box is closer to one of the supported and tested ones) or you have to find your own way to get it working with those tv boxes ...

i think there is not even useable nand support in the mainline allwinner kernel, so chances are close to zero to get this working currently

maybe its related to the kernel config parameter CONFIG_HZ_xyz - depending on which of them is set for the different kernels?

i'm writing this from an aarch64 chromebook running mainline linux with 32gb of emmc (usually 90+ % full) which i'm using as daily driver for over two years now with firefox having many dozens of active tabs open all the time, so that its usually about 1gb into swap with its 4gb of ram (despite using zswap memory/swap compression) and so far it is running fine without problems und due to the btrfs internal checksumming on read those would be visible immediately ... same applies to a few small servers with a similar setup running from a1 rated sd cards, all fine as well ... this is not armbian, but btrfs (which should be the same everywhere) - maybe formatting with "-m single" and mounting with "ssd" option might be a good idea (at least this is what i use on above mentioned systems).

besides that there is no armbian support for it yet, do not exepect anything useful linux-wise on this kind of boxes for the next months - h728/a523/t527 are all very similar (i.e. in large parts identical) allwinner socs, so the same as applies here as well best wishes - hexdump

it should be noted that all this is very very early bringup work not really useable for anything - iirc. no display, no cpu frequency scaling, no emmc etc. - all is still very much hacked together etc. ... it is good for people interested and having the skills to help in bringing this platform up but nothing yet for people wanting to really use this hardware ... this should be kept in mind when playing around with those patches ...

@A.Rahman - this is the armbian forum here and thus the wrong place to discuss this, so if you want to discuss something about my (non armbian) images, then please better open a github issue or discussion in the repo of those images

@jock - are you aware of https://github.com/jefflessard/tm16xx-display/ via ?

@MMorales - be careful with using the original android as some of those boxes are full of malware - see: https://github.com/DesktopECHO/T95-H616-Malware best wishes - hexdump

@embedder_dev - there is no proper u-boot for s805 and the u-boot (plus other bootloader parts) are somewhere in the middle of the emmc (if it even is emmc and not nand) - so better do not touch the emmc if you are not very familiar with such topics and stay on the sd card to avoid accidently bricking the box

@Bartel Eerdekens - just pure guessing as all this was quite some time ago: i think it does not matter as the chainloaded u-boot will be just loaded to some other address and when executed there via "go" command of the legacy u-boot it will relocate itself to where it is supposed to live and the legacy u-boot does not play any role anymore at that point - but all this might also be completely wrong ...