hexdump

@jock- most probably not related, but maybe worth a try: there is at least one allwinner h6 tv box which requires it to force hdmi to on via "video=HDMI-A-1:e" on the kernel cmdline to get any output on hdmi - so far nothing else has made it working than this little hack ... good luck

@constantius - just two little notes: to upgrade your u-boot which can then boot other systems you'll have to install the latest jetpack image once (it will do the upgrade as part of the installation) and to wipe the disk "sgdisk -Z /dev/xyz" might be helpful - it will destroy all former gpt partition information (also the backup copy at the end of the disk) and is very fast best wishes - hexdump

@dotbg - oh i just reread you initial post - this looks a bit like the mem is limited in the dtb then maybe? looking for "Memory limited to" in the kernel sources brings up arch/arm64/mm/init.c and that looks like dtb driven: https://github.com/torvalds/linux/blob/master/arch/arm64/mm/init.c#L177-L190 - but at least the upstream dtb does not contain such a limitation - maybe yours does? the reason for the limitation most probably is like i mentioned it above: there are some boxes (i have an eachlink one for instance) where u-boot cannot detect the memory size properly (or the hardware is setup in a strange or broken way) and as a safety measure it is limited to 2gb to make linux boot and run well on those too.

@Dan MacDonald - i think its limited to 2gb on the kernel cmdline and the reason for that is that there are some devices which have problems with memory detection and will not work if the mem is not limited to 2gb - just remove the 2gb limit from the kernel cmdline and see if your system is still running stable ... h6 can only deal with 3gb, so even boards which have 4gb can only use 3gb of them

@ArkhanLK - i played around with an h313 x96q box - it was working as well as a h616 box, but maybe the h313 are the lower quality ones as i was not able to reach as high cpu clocks with it like with h616 and it also got hotter - so maybe h313 are the lower quality binned versions of the h616 (similar to rk3318 vs rk3328 for rockchip) best wishes - hexdump

that would be at about the level of the mediatek mt8192 which is expected to arrive in some chromebooks during the next weeks (asurada) ... important to keep in mind: the score mentioned is geekbench v4 and not the currently common v5

@meadrocks - in xorg something called glamor is used to do acceleration of things you mentioned and glamor is using the opengl functionality of mesa - you can see something like "glamor initialized" in the xorg logs if it was properly enabled best wishes - hexdump ps: in case you want to look deeper into this, then having a look at the following links might be interesting https://forum.odroid.com/viewtopic.php?p=335755&sid=636e08b7c2fd692b0b6a81dbc318741f#p335755 https://github.com/tobetter/linux/commit/a026e2e9f55116e81ed49f48d918fdb91e28eff6 not sure if this will work on the c4 too ...

@chinhhut - this might be some interesting reading too regarding boxes, which cannot boot from sd card: https://github.com/hexdump0815/u-boot-misc/issues/2 best wishes - hexdump

@jock - thanks for the info and the links ... yes it is possible to get it working (got it working too - here are my notes: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.gxb plus some more readme.g* around for the other amlogic socs), but its more complicated than the other socs in my opinion ... yes odroid c2 has boot blobs which are locked to odroid hw, but there are other blobs available which work ... booting from emmc is even more complicated as the boot block starts from sector 0 and covers the partition table area (as it seems the first sector is even checksummed in the bl2, so no way to even put a partition table in there by hand as @pista has found out) - at least @pista found a clever way to make it work somehow still in this thread ... some amlogic boxes (mi box II and a95x f2 or f3 i think) even have an encrypted boot block, so there is no chance at all to get anything working except using legacy u-boot and maybe chainloading mainline u-boot from it ... afaik amlogic cannot boot from usb storage but you can supply it a boot block, kernel etc. via usb - see: https://github.com/superna9999/pyamlboot

@jock - there is no really useable mainline u-boot for the amlogic boxes (actually one can build one for one of the amlogic dev boards in u-boot - p201 or similar and they kind of work, but sometimes the dtb's do not match the hardware well enough) and those boxes are very easy to brick, plus default boot is from emmc. on top of that a few boxes even have nand instead of emmc. oh - and the memory timinig is done by blobs which seem to not be that interchangeable between different boxes plus it is a very complex procedure (in no way comparable to the easiness of rockchip - its more onion style with checksums on each layer - https://github.com/repk/gxlimg helps a lot for the s905x here) of many steps to build the final u-boot from the blobs and the compiled u-boot. due to this i think balbes150 (or maybe it was initially someone else) had the idea to just supply the legacy u-boot with a proper boot.scr style script to boot mainline linux kernels in a somewhat flexible way from sd card or usb. based on that i moved on one step by chainloading mainline u-boot from legacy u-boot, so that you get the features and flexibility of mainline u-boot (like extlinux.conf etc.) without the risk to brick the box. but even this is quite complicated as you better do not touch the first 700mb (older) to 1.5gb (newer) of the emmc as legacy u-boot reads a dtb from somewhere inbetween there and is very unhappy if it does not find it. rockchip and allwinner are really a dream compared to this mess best wishes - hexdump ps: another thing is that there is no usb tool comparable in power to what is there for rockchip for instance pps: i have some s905x, s905x2, s905x3 and s912 boxes running with native mainline u-boot but gave up on trying to generalize this setup as there is so much which can go wrong - s905 is even worse as there is no such tool as gxlimg to disassemble (to get the memory training info) and reassemble the blobs

@pista - i enjoyed this conversation a lot too and i agree with you that we have reached a point now at which your solution simply seems to be the best of the available ones - trying to hack the gpt option to make it work will in the end not end up in a solution which is really more simple thanks a lot for sharing your solution, which is at least a possible solution and for doing all those experiments best wishes - hexdump

@pista - there seems to be some backup gpt code in there - https://github.com/hexdump0815/u-boot-chainloading-for-arm-chromebooks/blob/master/misc.cbr/supress-efi-errors-v2021.01.patch#L44 ... did you get any gpt errors from u-boot? - the above patch is removing all the errors from u-boot which were spamming my console on this chromebook, so you should see them as well in theory i guess. looking roughly at the u-boot efi code at https://source.denx.de/u-boot/u-boot/-/blob/master/disk/part_efi.c#L676-711 i'm not sure if it really works with the backup gpt only - maybe on the chromebook part of the primary gpt sturcture is still there and only parts are broken, so that the backup gpt is then used ... will have to look closer at the u-boot source for this.

@pista - it looks like this should have some good information in it: https://source.denx.de/u-boot/u-boot/-/blob/master/doc/README.gpt it looks like the gpt stuff is not defined in my s905 u-boot build - the chromebook config ( https://source.denx.de/u-boot/u-boot/-/blob/master/configs/chromebook_speedy_defconfig ) has CONFIG_CMD_GPT=y set (and i guess this one then pulls in CONFIG_EFI_PARTITION) and the s905 config i used ( https://source.denx.de/u-boot/u-boot/-/blob/master/configs/p201_defconfig ) not looks like a new u-boot is required for this to be able to work: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.gxb best wishes - hexdump

@pista - i guess your theory about the checksum is correct then ... which linux version of the usb burning tool for amlogic did you use btw.? do you have to ground the emmc clock pin to get it recognized there or is it recognized if bricked even without that?

@pista - just to mention it here: i'm aware of one other type of system with a strange boot setup: the rk3288 based chromebooks (veyron) are using gpt partitoning, which consists of the primary gpt partition table at the beginning of the disk (and spanning even more space then the traditional mbr partition table) and a backup gpt partition table at the end of the disk (a normal redunadancy measure of gpt partioning) ... the strange thing on those chromebooks is that you can create a gpt partition table successflly, but if you try to read it back it tells you that the primary gpt table is corrupted (not sure where this gets lost, but its consistent) ... the way i got it working was to write the gpt table and then boot the kernel with the "gpt" option, which tells it to use the backup gpt table if the primary one is corrupted - u-boot is complaining a lot about the broken primary gpt, but works in this case (i just commented out those warning from u.boot for it) ... i think there are patches for those chromebooks, which put the primare gpt table to another place, but my approach works without those patches maybe an approach like this might work for the s905 too - not sure, but your approach is fine too i guess (maybe the gpt one would be a bit more standard - if it works at all in this case ) https://github.com/hexdump0815/u-boot-chainloading-for-arm-chromebooks/blob/master/misc.cbr/supress-efi-errors-v2021.01.patch https://github.com/hexdump0815/imagebuilder/blob/main/systems/chromebook_veyron/extra-files/boot/extlinux/extlinux.conf#L13

@pista- this is interesting - to me it looks like this in theory should really work the way you did it ... so in result it did not even start to boot then in this case? which boot blocks are you using - the ones i built or built them yourself?

@jock - i can confirm that those old mx10 boxes were rk3328 and they were the only ones i saw, which had a proper cpu voltage control ... i once had one of those some time ago @Matteo Venturi - i think there are at least two versions of this box: an older rk3328 one which should work very nice out of the box (i have one of those) and a newer rk3318 one which might have a few surprises in it resulting in it no longer working that easily best wishes and good luck - hexdump

@pista - congratulations - this is a very clever approach ... i had "blkdevparts" still on my list of things to check out one day, but i think i would have never gotten to the idea of the mmc read to read all the stuff in one row into memory - really really clever one other thing i once noticed (not 100% sure anymore, so it might also be just wrong memory) was, that it looked like the boot block for the first sector for the s905 seemed to have an empty area where the actual fat partition table lives in the first sector (i think i saw it when doing a hexdump -C of a self built s905 boot block) ... in case my memory is right and there is no checksumming involved it would even be possible to get a boot block together which has a proper fat partition table in it and still works ... but maybe i just dreamed it once and its not really true best wishes - hexdump ps: i just did some recheck of my theory - if you hexdump -C this one: https://github.com/hexdump0815/u-boot-misc/releases/download/200718-01/boot-amlogic_gxb_atf-aarch64-serial.dd.gz which is a boot block for sd card, i.e. starting at block 1 then it looks like only the area from 0x0 to 0x70 (after dropping the first 512 bytes) is really used and the partition entries are usually living between 0x1be and 0x1fe (see https://www.easeus.com/resource/fat32-disk-structure.htm) - so maybe there is a chance to get it working? but so far i never tried it

@pista - i must admit that i have lost the overview a bit about what your current setup and your goal is ... what did you manage to install to emmc and why do you use "mmc read" instead of "load/fatlload"? yes, the initial env is hardcoded into u-boot.

@Dan MacDonald - iirc the open source driver has to exist so that the kernel driver they use for their own blob driver has any open source consumer and i guess this is why it is slowed down so much: its there as it has to exist for the kernel driver not to be thrown out of the kernel and otherwise nobody really cares about it ...

@Sameer9793 - amlogic socs by default always boot from emmc if emmc is there (which is always the case for tv boxes) - best for you is to look at the multiboot script from the old images of balbes150 - this one uses the legacy u-boot of the box to boot an own kernel or to chainload a mainline u-boot to boot it - those options should be quite safe as everything else which does not write anything to emmc

@Sameer9793- i collected some notes around mainline u-boot for amlogic in the readme.gxb (gxbb), readme.gxl (gxl) and readme.gxy (g12a, g12b, sm-1) in this repo: https://github.com/hexdump0815/u-boot-misc - but i would recommend you to play around with that stuff only if you really know what you are doing as you can very easily brick your box this way and then nobody can help you ... good luck and best wishes - hexdump

@vilodeid - in case you really want to play around with panfrost on h616, then maybe have a look at this https://oftc.irclog.whitequark.org/linux-sunxi/2021-05-27#29961750 and the irc logs from the following days ... a lot to read and not really easy stuff, but i think this the most detailed information which is there so far regarding this topic happy reading and best wishes - hexdump

@jock - do you have this extracted ddrbin somewhere in your repos already? i was not able to find it yet ...

@pista - i do not remember exactly, but usb storage in u-boot is often not really working (for instance due to confusion regarding initialization of hardware between legacy and chainloaded u-boot but maybe even due to other reasons too), so it might be the case here even in case it would have been enabled (not sure about that) - what you can do is to have some small sd card (or even later regions on emmc) for the kernel etc., load it from there and then use usb as root fs (for this only the kernel needs to know it) ... alternative option is to hack on u-boot and find out - all the steps which lead to my u-boot binary are noted down in the file readme.gxb in that repo ... please let me know either via github issue or here in case you get anything working best wishes and good luck - hexdump