hexdump

  • Content Count

    350
  • Joined

  • Last visited

Everything posted by hexdump

  1. @Sevillano - as said: you may try around more if you like, but i think the only chance you have is to find the original firmware for your box, as it is the only one which was build with the proper keys - this box (and very few others as well - a95xf2, mi-box, ...) is special as the boot process is locked
  2. there was another thread regarding rk3318 here: might be worth a look ...
  3. @Sevillano - as far as i remember the a95x max is one of the rare cases of using a signed/encrypted boot block, so erasing the emmc is not a good idea as you'll not be able to create any boot block with the proper keys to be loaded by the box - reinstallling the original firmware is your only option i guess and then bootiing via legacy u-boot and the regular balbes150 script and maybe chainloaded mainline u-boot good luck and best wishes - hexdump
  4. @XFer012 - in case you run into any problems while trying get it working based on my notes, just open an issue on that git repo and i may try to help you to resolve them good luck - hexdump
  5. @XFer012 - those files are not intended to be used in the armbian build system, but when building a kernel standalone. they are basically just my notes on getting the kernel compiled and working and not intended to be just dropped into an armbian build.
  6. @XFer012 - oh - if you have the 512mb version then it might get a bit short on memory maybe, 1gb should be fine ...
  7. @XFer012 - you can also build a kernel directly on the box - takes a bit of time, but works well - i'm building all my arm kernels on arm devices
  8. @XFer012 - i think the best approach might be to build your own kernel and then you can change the original dts and dtsi files directly (with labels etc.) instead of dealing only with the compiled versions ... maybe my notes from playing around with the h616 on tv boxes might be helpful for you: https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel i also built a kernel with working usb and early hdmi (based on the code of @jernej): https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/tag/5.11.0-rc1-stb-616%2B - i did not test it
  9. just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3 so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sy
  10. that log looks like my mainline u-boot is not chainloaded but has replaced the legacy u-boot (as there is no sign of a legacy u-boot in the log) ... this works quite well for me but is not tested too well and worst case you can brick the box - but looks like you got it working well too maybe you wiped your emmc (accidently?) and by chance had the proper u-boot at the proper place on the sd card ... if the box does not find a boot loader on emmc then it will try to boot from sd card ... or you even by chance replaced the bootloader on emmc with my mainline u-boot ...
  11. the situation for the 32bit amlogic socs (like the odroid c1) is that there is essentially just one single person working on them whenever time permits it ... so the only two options are to be patient or to help (which is not an easy option) or of course to forget about the board ...
  12. i don't think that this will help - your only chance is to search for potentially fitting stock images and try them until one works ... otherwise you have a nice little s905x doorstop only ...
  13. this should work actually as your boot block sees and reads from the sd card (SD:0;READ:0) ... there is one thing which might explain it: encrypted boot loader - very few boxes have it (for gxl for instance the mi box, s905x2 the a95xf2 for instance - or was it a95xf3 maybe ...) - in that case the only chance you have is trying to find some original firmware for the box with the proper signing and encryption - everything else will not work ... i think the reason why it ended up in this state is that someone installed another unsigned/not encrypted image on it ...
  14. maybe upgraded or downgraded android on the box, i.e. different version of the legacy u-boot? - in case both of you have a serial console connected you might compare the u-boot version strings from early boot ...
  15. @lcapriotti - could you maybe upload your uboot.emmc somewhere so that we can run some strings and/or hexdump on it to find out what version it is?
  16. h6 tv boxes are usually running very hot and require a fan if you want to run them at full speed without thermal throttling in my experience ...
  17. @N3bi2 - you may try to dd this (gunzipped): https://github.com/hexdump0815/u-boot-misc/releases/download/200718-01/boot-amlogic_gxb_atf-aarch64-serial.dd.gz to the beginning of an sd card - this should at least give you a working and booting mainline u-boot from sd card ...
  18. @lanefu - for those amlogic tv boxes chainloading u-boot means the old legacy u-boot on the box is loading a mainline u-boot.bin (which has nice features like extlinux.conf support and allocates less memory for itself) which is then loading the kernel @SteeMan - this looks a bit like this box has a non standard mmc setup which might be not so easy to track down (one would need to extract the android dtb from the box - see: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy and then the mmc entries should be compared to the android dtbs
  19. ... and be aware that there are quite a few fake tv boxes around (very popular for q+ too) which are sold as 4gb (and in android they even hacked it to look like this), but only have 2gb of memory built in ... so it can be that the box simply only has 2gb in the end ... maybe do an "apt-get install memtester" followed by "memtester 2500M" on the box with your 3072M setting - if it runs through stable you seem to really have 3gb, if it hangs or crashes doing so you most probably only have 2gb good luck and best wishes - hexdump
  20. @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 thr
  21. yes - i'll try all those options step by step over the next days i think
  22. 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 ...
  23. 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 i
  24. 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
  25. @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)