Jump to content

hexdump

Members
  • Posts

    457
  • Joined

  • Last visited

Posts posted by hexdump

  1. @jock - i think amlogic (the company) still is not very good regarding open source, but at least linux mainline is quite useable on their chips

     

    the emmc clk pin trick works for amlogic too (if one finds it :) ) and wiping the emmc results in a boot from sd card ... the main problem is that the legacy u-boot reads its dtb from a later partition on the emmc and fails if it cannot find it - this is a problem if one for instance fdisk's and mkfs the emmc: the u-boot itself can still be intact, but it is bricked as it can no longer find its dtb (this is why the balbes150 amlogic images always kept 700mb and later more of the emmc in place when installing onto emmc to avoid overwriting this sensitive information) ... putting a mainline u-boot on amlogic boxes is possible but due to the complex boot structure and the required fitting blobs way more complicated than on rockchip and allwinner ... in summary: if amlogic then best is a properly supported sbc (odroid etc.) - unsupported stuff like tv boxes can result in quite a bit of extra work and unwanted surprises with those socs

  2. i would say that the amlogic mainline support is not that bad: http://linux-meson.com/doku.php - i think a few developers from baylibre were even paid to mainline stuff (not sure by whom) and there is still active development ongoing if you look at the linux-amlogic kernel maliniglist ... where amlogic is quite bad is the booting: there is no way around certain binary blobs to boot them and the way to build the boot blocks is simply crazy ... beyond that you can really brick an amlogic box quite easily, as it boots by default from emmc (but at least there are some tricks possible like https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle :))

     

    the reason why rockchip (especially rk3288 and rk3399) is so well supported is mainly because google pushed them as those chips were used in chromebooks ... for the same reason some newer mediatek (mt8173, mt8183 and in a few months maybe also mt8192 and mt8195) and snapdragon (7180c) socs are surprisingly well supported in mainline

     

    i would say allwinner has the nicest and most active developer community around it and most of the allwinner mainline code is coming from this community and some of the allwinner boards and even tv boxes can be run completely blob free even (a few rockchip ones too)

     

    best wishes - hexdump

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

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

  5. @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 on a orange pi zero 2 myself (as i only tried it on a h616 tv box), but at least i tried to keep the opi zero 2 dtb up to date, so it might just work

     

    all that is not a perfect solution, but maybe its helpful for you on your way

     

    good luck and best wishes - hexdump

  6. 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 /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?)

     

    i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce

     

    all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs

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

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

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

  10. @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 of other boxes where emmc works - here is for instance my h96max-x3 android dtb: https://github.com/hexdump0815/linux-mainline-and-mali-amlogic-kernel/blob/master/misc.aml/dtb/meson-sm1-h96max-x3.dts.android - this is a big puzzle and a lot of trial and error might be required without the guarantee to get it working)

     

    the patch is to remove some code which will not work in our scenario (getting linux working on it) - it looks like the mainline u-boot code for the s905x3 i used as a base was only done for android which has a different partition (+table) setup than what we plan to use

     

    the uEnv.txt file is read before extlinux.conf, so things can be set there which partially cannot be defined in the extlinux.conf (which is quite limited) - in armbian that file usually is called armbianEnv.txt i think, so you should maybe adjust the filename to be in sync with armbian if you want to get it closer to a standard armbian setup

     

    just an idea: you might also try the newer u-boot 2021.01 or soon the upcoming 2021.04, but i think nothing really changed in there for amlogic

     

    @lcapriotti - it would be very helpful if you could find out how you got it to work on your box - this might getting this resolved easier for @SteeMan maybe

     

    good luck and best wishes - hexdump

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

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines