hexdump

i did some more research and for sure the nvidia gpu firmware is missing in the armbian-firmware - https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia/gm20b/gr - it is part of the regular linux-firmware package but even with that we are not there yet - i tried both xorg and wayland and both times ended up with GL_OUT_OF_MEMORY errors which i do not understand yet, but large parts of the probing looks good ... looks like nouveau.modeset=1 parameter might be required on boot as well ... will have to investigate things further ...

ok - false alarm ... looks like something was still wrong with my u-boot ... rerunning the jetpack image once more seems to have fixed it and now the image is booting fine also on the 2gb model gpu acceleration is not working yet (llvmpipe is used instead), but in general it looks quite good: the tegra and nouveau drm drivers are properly loaded without errors ... according to https://github.com/NVIDIA/tegra-nouveau-rootfs and https://github.com/NVIDIA/tegra-rootfs-scripts it looks like maybe some special xorg server and/or mesa needs to be compiled ... will maybe have a look at it over the weekend btw. have any kernel patches been required to make it work with mainline or is the mainline support that good meanwhile that it just works? best wishes - hexdump

did anyone already test to boot this image on the 2gb model of the jetson nano? i just tried it and it does not boot - the nano already has the new u-boot in the spi ... looks like i have to connect a serial console when i find some time

@balbes150 - is the nouveau/tegra gpu acceleration actually working with this mainline kernel? (glxgears -info should show nouveau or tegra as driver instead of llvmpipe)

@gounthar - i think you do not need esxi as kvm and maybe xen (and some other free hypervisors) are working quite well on aarch64 already ...

congratulations! ... the u-boot is still the original nvidia one from spl then? or a recompiled nvidia u-boot? or mainline u-boot (i guess not as v2020.04 looks too old for that)? are you able to use mbr partitions or do you have to use the usual jetson gpt partition setup?

@Piezo - did you already try "sysctl -w kernel.sched_rt_runtime_us=-1" - it works well for me for jackd ... best wishes and good luck - hexdump

@Seth - it might be good to get the dtb from the box - in case no other way works, this approach so far worked for nearly every android tv box for me: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy good luck - hexdump

@SteeMan - just to come back to what you said about the jock builds for rk3288 and rk322x: i think the only way to get the amlogic tv boxes somehow supported in armbian is that someone is or even better a few people are starting to setup and maintain a proper csc line for them like jock did for rk3288 and rk322x - it will not work in the long term to try to support them based on old balbes150 images and a lot of hacks around them ... i'm not having the time and energy to step in here, but i think all the information should be there based on the research balbes150, various others and me have done around those boxes over the last years, there is just someone needed to sort all this information properly and bring it into the armbian build system

@jernej - well done! - it works well on my h313 x96q box

@SteeMan - but it is important to be aware that the boot process for rockchip, allwinner and especially amlogic is very different in the detail and for amlogic there is a high risk to brick a box if you try to completely replace the boot loader like it can be done quite easily for allwinner or rockchip. it could even be done for amlogic (i'm running several boxes this way) but its too complicated and risky to do it this way. btw. when installing to emmc it is very important to not overwrite the beginning of the emmc as the legacy u-boot searches for its dtb somewhere there and will not work if it cannot find it. this is why balbes150 did always ignore the first 700 mb of the emmc and later even over a gb to avoid this potential problem. regarding the emmc boot hang if the bootloader is called from emmc there might be some strange interconnection between legacy u-boot and chainloaded u-boot which is hard to impossible to track down as there are too many unknowns (most probably legacy u-boot leaves something around the emmc in a state which is confusing the chainloaded mainline u-boot afterwards). in this situation the only option might be to boot from a small sd card and put the root fs onto emmc. best wishes - hexdump

@jernej - from irc i remember that some special u-boot hack was required for you to enable hdmi - is this still required or did you find another way to get it working? will have a look at your code over the weekend.

@SteeMan already explained very well how my u-boot files are supposed to be used ... some notes regarding those u-boot files: for most of them i built two versions: one with "-serial" in the name - they have serial console support enabled and hdmi/usb kbd support disabled and the other version is without "-serial" and has the serial console disabled and hdmi/usb kbd enabled. i built those two versions as i noted that leaving both consoles (serial plus hdmi/usbkbd) enabled together did not work reliable - it looks like noise on the serial line in this case can confuse u-boot (so that it hangs), especially if wires are connected to the serial console ports on the board but no serial console being connected to them. it might be that the g12a and sm1 version still have the serial port enabled in the hdmi versions - i do not remember exactly anymore if i rebuilt them completely - an easy test would be to check if there is still serial output while booting. an easy cure to avoid serial noise problems in such cases is to simply connect a serial port to usb adapter to them and plug the usb part of that adapter into the box - this way everything is grounded properly and and there is no noise anymore - this works very well for me for my test boxes with serial ports soldered onto them. something which is a bit different with those u-boots is also that they read a files call uEnv.txt instead of the armbianEnv file. best wishes and good luck - hexdump

@robertoenr - it might be related or it might be not - i think there is just one way to find it out and that is to try it good luck and best wishes - hexdump

@nightguest - if you want to seriously put some effort into getting your h96max h2 to boot then here is how to get there: https://github.com/hexdump0815/u-boot-misc/issues/2 - but be warned this is not easy, so if you just want to get linux on it the easy way then it might be better to search for another box best wishes - hexdump

@SteeMan - nice to hear that the u-boot images are working well - regarding your ethernet problem please give this patch a try: http://lists.infradead.org/pipermail/linux-amlogic/2020-December/009360.html - it fixes some messed up clocks as soon as audio is compiled into the kernel on boxes with gbit ethernet good luck and best wishes - hexdump

@SteeMan - in case you want to experiment (i.e. not sure if it really works), you might play around with chainloading the g12a-u-boot.bin (s905x2) and sm1-u-boot.bin (s905x3) from https://github.com/hexdump0815/u-boot-misc/releases/tag/200926-01 or gxb-u-boot.bin (s905) or gxl-u-boot.bin (s905x) from https://github.com/hexdump0815/u-boot-misc/releases/tag/200718-01 ... basic chainloading goes like this - https://github.com/hexdump0815/imagebuilder/blob/master/boot/boot-amlogic_gx-aarch64/s905_autoscript.txt - maybe compare it to the balbes150 boot scripts for fancier ways and most probably better armbian integration ... the files mostly exist in a serial version for serial console and another one for hdmi output and usb keyboard input (which sometimes works and sometimes not) ... better ignore the boot-xyz.dd file at the links above - they are for booting amlogic boxes without the legacy u-boot, but using them is quite complicated and risky (you can seriously brick the box worst case) as mentioned all this is without any warranty or support, but it might be a good starting point for experiments good luck and best wishes - hexdump

@Werner - it might be better (at least in the beginning) to use a plain mainline as a base as i guess this is what the authors of the patches use when creating them ... mixing it with another tree with lots of own patches in them might make it harder to debug problems

but those are fixed ip cores in the hardware and not loaded later - if you want to get rid of those i think you have no chance to get a useable system going at all ...

i think you can run some allwinner socs (at least the h6) and some rockchip socs nearly blob free as they do the memory setup themself, have open source atf (and sometimes optee too) and u-boot. maybe a free usb wifi might be required as boards sometimes come with wifi requiring blobs. this way one might even be able to make a cheap h6 tv box into a blob free system

i agree with @jock - rk3318/rk3328 usually use pwm for voltage control, so it should and i guess will work - at least for us it did for all the boxes we ran across

@Lambert or some moderator: i think what is ment here is rk3318 and not rk3188 - it might be good to adjust the title ...

@jock regarding rk3566: pine64 is planning something for next year - see https://www.pine64.org/2020/11/15/november-update-kde-pinephone-ce-and-a-peek-into-the-future/

it was supposed to be released by now already and looks like its delayed by another year now ... announcements are one thing and real hardware with good software support another

that one is not really armbian - but you can try it as a start - not sure if it will boot out of the box on an asus c100pa, but with some dtb trying/tweaking it might work ... it works for me on a medion s2013 chromebook ... in case you get it booting, do not expect wlan etc. to work out of the box for sure good luck and best wishes - hexdump