Jump to content

hexdump

Members
  • Posts

    457
  • Joined

  • Last visited

Everything posted by hexdump

  1. @Jeremiah Cornelius - for your lightdm issue, maybe give the slick greeter for lightdm a try - it fixed my problems with non working lightdm on 32bit arm - might be worth a try best wishes and good luck - hexdump
  2. @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
  3. 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
  4. @lucky62@kruzer@jock - problems with lightdm on arm systems ring a bell for me: can you maybe try to install and use the slick-greeter for lightdm instead of the default one? this solved some trouble for me and maybe it helps in this case too? good luck and best wishes - hexdump
  5. @crr - if you try my image, please put your findings into a github issue of the corresponding repo ... there is another quite up to date try to get linux working on chromebooks here as well: https://github.com/Maccraft123/Cadmium - might be worth to have a look at this one too good luck and best wishes - hexdump
  6. i think only very few came from me (most probably only the ones with hdmi output, which i mentioned to him and suggested that he might use them in his images if he likes them) ... i think most of the other u-boot.ext files in his images were either built or extraced by @balbes150 himself
  7. @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
  8. there was another thread regarding rk3318 here: might be worth a look ...
  9. @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
  10. @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
  11. @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.
  12. @XFer012 - oh - if you have the 512mb version then it might get a bit short on memory maybe, 1gb should be fine ...
  13. @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
  14. @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
  15. 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
  16. 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 ...
  17. 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 ...
  18. 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 ...
  19. 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 ...
  20. 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 ...
  21. @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?
  22. 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 ...
  23. @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 ...
  24. @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
  25. ... 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