hexdump

in case you already have one and want to get started, this is a bootable sd card image working on some rk3288 chromebooks: https://github.com/hexdump0815/imagebuilder/releases/tag/200526-01 - maybe you can use it as a starting point for a proper armbian port (the image is just plain debian/ubuntu and not armbian) some more relevant info about getting linux working or making it nicer on such chromebooks: https://github.com/hexdump0815/imagebuilder/tree/master/files/chromebook-boot https://github.com/hexdump0815/imagebuilder/blob/master/boot/boot-chromebook_veyron-armv7l/chromebook-boot/cbr.dd-secondary-gpt.readme https://github.com/hexdump0815/u-boot-chainloading-for-arm-chromebooks https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/readme.cbr best wishes - hexdump

there is no discussion yet - i just ment if you want to discuss that in detail, then better as a github issue on the mentioned repo ... if you are not familiar with github issues then it can be easily googled how it works and it is not really complicated

maybe try another keyboard or usb port

maybe that was me - it was not the colorful edition but the h2 ... it is long ago, but i recently tried to dump my steps here: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.rk3328-no-sd-boot ... in case you want to try it i can try to help if you have concrete questions, but you should be somewhat familiar with the steps described in the readme at least ... as i do not want to hijack the armbian forum for this it might be better to do any possible discussion as a github issue on that repo good luck - hexdump

where you most probably have the readme from, which contains the lines you tried: https://github.com/hexdump0815/u-boot-misc as this is not really armbian related, lets better do any potential follow up discussion as an issue in this github repo

my dtb might be too outdated meanwhile and my u-boot might not work well with your box - in general i can only recommend you to get another better supported box - rk3318 is not really supported, gives a lot of trouble and is very low end ... i got mine working and as it seems a few others too, but there is no guarantee that it will work for other boxes ... minimum to debug is to solder a serial console to the box to see what the problem is and even then its not sure if it can be made working ...

this is where i have the patches located when compiling my own kernel or u-boot

@Reddwarf please keep on the subjects of the threads - this one here is about rk322x and not rk3328 ... to me it looks like you are trying to compile arm code on an intel machine maybe - for that you'll need to cross compile or compile native on an arm machine ... followup if needed please in a separate thread best wishes - hexdump

@jock - missing opengl can be worked around quite well with gl4es: https://github.com/ptitSeb/gl4es

@jock @fabiobassa - to explain the difference between the addresses by the maskrom vs loader mode makes sense ... i think i did this hybrid setup with original initial boot blocks and mainline u-boot back then because i was thinking that this is the only way to get it working with the existing trust image ... where is it actually defined if trust images will be used or not - is it somewhere fused in the hw or is it just a matter of the initial boot blocks? if its just a matter of the boot blocks, then i should even be able to replace the entire boot with something adjusted self compiled maybe ... another reason i did it that way was that shortly before i did something similar for a rk3318 box for which there was no atf i could build myself (rk3328 one did not work) so i had to keep the original initial boot blocks there ... best wishes - hexdump

it does not work as the cpu frequencies are controlled by a non open source binary blob firmware running on an invisible m3 core in your soc - hardkernel had created a special blob for the c2 which was dongled to their stuff and quite unstable at higher freqs with all cores on - so no way for mainline

you might have a look at this, but you are on your own then (no warranties or support from my side) - for me it worked to get my h96max h2 which cannot boot from sd card too working by installing an adjusted u-boot - https://github.com/hexdump0815/u-boot-misc/blob/master/readme.rk3328-no-sd-boot

@Turgus - no there is no hdmi support in u-boot for allwinner h6 ... as far as i know only for amlogic gxbb, gxl+gxm, g12, sm1 (not sure about the last two as i did not test them yet), rockchip rk3288 and rk3399 and allwinner h3 seems to have some hdmi console mode as well @balbes150 - i think its good to have something like armbianEnv or uEnv.txt as an option around as this is the only way to fix an ethernet address in an easy way when u-boot for the board will always generate a new one on each boot as you cannot set the mac addr in extlinux.conf best wishes - hexdump

yes - syslinux is enabled ... @balbes150 - i did not think about this, you are right: you can with this simply offer multiple menu entries using different dtbs to make it even easier for people to use it

@Turgus - if you are playing around with my u-boot, then you'll have to copy the armbianEnv file to uEnv.txt to be recognized - it is not fully adapted to armbian yet ...

sure - feel free to include it - i would recommend you to build your own version as my version is currently using uEnv.txt instead of armbianEnv ... patches are in the misc.gxl and misc.gxb subdirs and in the readme.gxl and readme.gxb is described how i patched and built them ... maybe best would be to offer two versions in your image: one for the serial console and one for hdmi/usb boot as i had to disable serial console input on the hdmi/usb version as it sometimes created noise in the early boot when no serial console was connected which stopped u-boot at the prompt so that it did not boot ... in theory something like this should also be possible for rk3288 and rk3399 (next to the already mentioned amlogic g12/sm1), but i did not yet have the time to play around with those best wishes - hexdump

@balbes150 - as you have changed to use a chainloaded u-boot.bin on amlogic now everywhere, maybe have a look at https://github.com/hexdump0815/u-boot-misc - the gxl and gxb u-boots i got to the point that they display properly on hdmi from the beginning on and can be used with a usb keyboard - so no more serial console required ... i guess gxm should be possible too (not yet tested) and g12/sm1 look like they support it too (not tested yet neither) ... in case you want to play around with it, here are some precompiled binaries with that functionality: https://github.com/hexdump0815/u-boot-misc/releases/download/200718-01/gxl-u-boot.bin.gz https://github.com/hexdump0815/u-boot-misc/releases/download/200718-01/gxb-u-boot.bin.gz while i'm at it: i think i also got native installation of u-boot (i.e. wiping the legacy u-boot) working quite reliable on gxl, but i'll have to test that on more boxes and the procedure is not really trivial ... best wishes - hexdump

@balbes150 - are you aware of this one? (but maybe this is what you added): https://github.com/hexdump0815/linux-mainline-and-mali-rockchip-rk33xx-kernel/blob/master/misc.rkc/rk3328-add-dmc-driver.patch

@heroes1412 - see:

@balbes150 - what exactly did you change for that version - opp points in dtb and memory timing or more?

@Rajesh - if you really reach > 130 c celsius then i think either the thermal sensor is not properly calibrated and/or the cpu-throttle-cooling-device is not/not properly defined in the dtb - usually the cpu clock is reduced when the cpu gets too hot to cool down ... on the h6 without proper cpu voltage handling (like in tv boxes) this down clocking might not be aggressive enough ... not sure if something like this: is in @balbes150 tree already and if it is it might still be not aggressive enough for h6 tv boxes as they have to be clocked down massively to really get the temperature down a bit as the voltage stays by cheap design the same all the time ...

@Yeoj Henrie Sayadi - it might be due to the restriction of the voltage range of the voltage provider for the cpu in case you also increased the voltage for the higher opp points ...

@Rajesh - regarding your temperature issue on the tx6: this is a general problem for most (if not all) h6 tv boxes as they do not seem to have any proper voltage control over the cpu (at least none useable with the mainline kernel - they are missing the usual axp805 pmic which is supported by the kernel) so they run at the same (high) voltage for all frequencies which limits the thermal savings by lowering the cpu freq (usually the voltage goes down in parallel too which reduces temperature way more) ... so in the end the only option you have on a h6 tv box if you want to put real load onto it is to cool it properly, i.e. a fan is required or a really huge heat sink (although in my tests a fan is definitely required if you have constant high load as then the heat sink simply warms up over time independent of how big it is as long as its not extremely big) best wishes - hexdump

the legacy u-boot in those boxes is usually allocating away quite a bit of memory which you'll have to live with or your can try chainloading a mainline u-boot (which is what the u-boot.ext display hack is doing - on boxes where this is used there should be more memory available on average i guess) best wishes - hexdump

@Rajesh - regarding the display: this might be a good start for research (it might work or not work in a similar way and there are some other vfd drivers in github too to play around with) good luck - hexdump update: another link with useful info regarding those display drivers: http://www.rvq.fr/linux/tanix-vfd.php (the page is in french)