hexdump

  • Content Count

    355
  • Joined

  • Last visited

2 Followers

About hexdump

  • Rank
    Embedded member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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 al
  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://
  3. @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
  4. @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
  5. 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
  6. @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
  7. there was another thread regarding rk3318 here: might be worth a look ...
  8. @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
  9. @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
  10. @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.
  11. @XFer012 - oh - if you have the 512mb version then it might get a bit short on memory maybe, 1gb should be fine ...
  12. @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
  13. @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
  14. 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
  15. 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 ...