Jump to content

hexdump

Members
  • Posts

    457
  • Joined

  • Last visited

Posts posted by hexdump

  1. @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

  2. 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 ...

  3. 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

  4. 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

  5.  @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

  6. @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

  7. @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

  8. @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

  9. 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 :)

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines