hexdump

Members
  • Content Count

    237
  • Joined

  • Last visited

1 Follower

About hexdump

  • Rank
    Elite member

Recent Profile Visitors

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

  1. @jock - that approach with erasing the emmc might work quite well for some boxes, but not for others: i have an rk3318 box where i was not able to get mainline u-boot+atf running at all and was relying on the first stage of the original bootloader ... there are allwinner boxes where mainline u-boot is not able to get the memory timing right - the only option there is to build a hacked non-redistributable u-boot using an allwinner blob and on amlogic it is even more complex: here u-boot uses binary blobs for the memory timing etc. which are often specific to a certain box, so that you'll have to first extract the original boot blocks from the box, extract those sections from it and and build a mainline u-boot with them following the for sure not trivial build procedure for the amlogic u-boot - it can be done if one is used to doing such things but i think it will fail as a generic solution for everyone ... best wishes - hexdump
  2. @Miguel Moyano - give this one a try, it should work i think: make sure to read the instructions of the first post carefully to not skip some important step good luck and best wishes - hexdump
  3. @balbes150 - how exactly is this working technically? isn't in theory the mbr part occupied by the bootloader as well on s905? a lot of thanks in advance and best wishes - hexdump
  4. @Italo Felipe - somewhere in this thread i also posted a t9 dtb for mainline, which should work for 5.x - not sure if i already had wifi working with it but i think i had ... good luck and best wishes - hexdump
  5. @Italo Felipe - i think there is a newer version of the t9 box which has a rk3318 instead of the rk3328 in the original one - maybe your box is one of those? i think the old one came with android 8 and the new one with android 9 ... if you have the newer one, you may try the things mentioned in this thread and other on this forum about getting rk3318 boxes working ... good luck - hexdump
  6. i guess this is on s905 - right? this is due to bad design of the s905 - if booting from emmc it expects its boot sectors at the beginning of the disk (compared to if booting from sd card where it expects them to start later) - you can find more information about this from here on in that thread: i think there is no really easy way around it on s905 best wishes - hexdump
  7. @Nuno Cruz - it is sometimes possible to extract some information from the original dtb and use it to adjust a mainline one, but its not easy and not always possible ...
  8. @Nuno Cruz - the original dtb is for android and most probably for another kernel version too, so there is no way to make it work without a lot of adaption work
  9. allwinner h616 is not supported yet by linux, so no way forward here ...
  10. @jock - your theory sounds good i think - might be the case ... the 4.4.189 kernel config i used as starting point was the one from your last 4.4.189 based images ... this is the one i used then after a "make oldconfig" which resulted in the working 4.4.194 kernel: https://github.com/hexdump0815/linux-rockchip-rk322x-kernel/blob/96bf87bd0014f2d5a17ddcd1202980d2023d2302/config.322 best wishes - hexdump
  11. @fabiobassa - good point - i now used the config from the 4.4.189 kernel plus make oldconfig for building 4.4.194 and the resulting kernel now boots and works perfectly fine update: i did not yet find the console connector on this box, but of all the librelec images it only booted the ddr2 one, so i assume it has dd2 memory ... about the rk3228: the funny thing is that it runs nicely with the 1.4ghz clock speed of the rk3229-xt-mx4vr-v01.dtb ... @jock - maybe your 4.4.194 kernel config should be reviewed and potentially adjusted? btw. i can confirm that your above suggested cursor fix for your armsoc xorg server works well ... a lot of thanks and best wishes - hexdump
  12. as said this is still very much work in progress i guess ...
  13. @jock - i tried reducing the opp tables on mainline to 1.2ghz and to lower the opp and gpu clocks on the rockchip kernel - nothing changed. also with the working 4.4.189 kernel it works with the full opp and gpu clocks without any problem. @fabiobassa - here is the efuse content: root@r39-4k:~# hexdump -C /sys/bus/nvmem/devices/rockchip-efuse0/nvmem 00000000 52 4b 23 82 81 d4 70 55 52 4b 4e 30 39 30 32 35 |RK#...pURKN09025| 00000010 00 00 00 00 01 2c 15 03 00 03 81 00 00 80 00 00 |.....,..........| how to interpret this? update: i also tried to boot the 4.4.194 kernel with the 4.4.189 dtb to rule out potential dtb changes - it does not work the same way the 4.4.194 kernel with its own dtb does not work, so the reason for the problems should be somewhere in code changes between 4.4.189 and 4.4.194 i guess ... a lot of thanks in advance and best wishes - hexdump
  14. gles3.0 is not ready yet - you might give this a try: https://www.phoronix.com/scan.php?page=news_item&px=Panfrost-Gallium3D-GLES-3.0
  15. @jock - i did some more tests: i build a kernel myself based on your sources and patches but with HIGHMEM disabled again and the 4.4.194 kernel still hangs in the middle of the boot on my 2gb r39-4k rk3229 box (4.4.189 works fine with just showing 1gb ram and 4.4.194 works well on my 1gb mk809iv rk3228 box) - does it work for you on any rk3229 2gb box? do you have an idea which of the patches between your 4.4.189 and 4.4.194 kernels might trigger this hanging? i also built a 5.4.22 mainline kernel based on your patches - it boots further (i can get into x11 even with it) but starts to be quite erratic and eventually hangs later - but it at least discovers the 2gb ram properly according to the logs best wishes - hexdump