Jump to content

hexdump

Members
  • Posts

    457
  • Joined

  • Last visited

Posts posted by hexdump

  1. hi @pista - you'll have to be very careful trying to boot s905 from emmc as the boot block structure for this soc does not cooperate very well with the partition table on the disk (both live mostly in the same area) - i'm actually surprised that you can still boot, as your partitions on the emmc most probably already have overwritten regions which are required for the legacy u-boot to work (the dtb for the legacy u-boot is usually somewhere in the middle of the emc - see the "libfdt fdt_check_header(): FDT_ERR_BADMAGIC" message and that it cannot find its logo bmp) - i would recommend you to use a hybrid mode to boot from sd card and maybe have the rootfs on emmc and better keep the first 700mb (this is the size balbes used successfully on older s905x boards) on the emmc unused to maybe not overwrite more essential parts required for booting ... the error you get seems to result from the u-boot.ext having a different device numbering of mmc, emmc etc. than the legacy boot (they all can have a different numbering: legacy u-boot, different maninline u-boot's and the kernel), but as said - better do not try to do the first stages of the boot from emmc on s905 as there is a very high risk to brick the box hard this way ...

     

    good luck and best wishes - hexdump

  2. panfrost is not working yet on the t62x mali and its not sure if it ever will as the focus currently is on keeping the supported hardware working and add newer mali support to it right now - so the only thing you can do is to hope for it to get done some day. for that reason panfrost is still disabled by default in mesa for it.

     

    best wishes - hexdump

  3. looks like the s905l3 is another of those amlogic socs where they did reduce the hw even further to bring down the price - for the s905l2 this one helped for me: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av8/dtb/meson-gxl-s905l2-x7-5g.dts but your trace looks different ... good luck for finding out what they changed this time :)

     

    p.s.: it looks like the above change is needed there too, but looks like they even crippled the vpu and/or hdmi hw as well ...

  4. the ssv6x5x chips are not supported in mainline or with anything else than the meanwhile quite dated rockchip legacy tree and as the existing sources and docs for them are so bad (and i guess the hardware design as well) they most probably never will be supported in mainline.

     

    mxq boxes can have everything in them: they exist with allwinner, amlogic and rockchip socs in them combined with a large variety of wifi chips. tv boxes can be fun to play with but never expect anything to be too well - you might win the lottery and get a really good one with supported wifi,good case, power supply and heat sink etc. and you can end up on the other end where the 4gb/32gb emmc box you bought in reality is just a1gb/8gb nand box with unsupported wifi there the first components fall off the board after a few weeks. i think the second option get more and more likely nowadays :)

     

    enjoy those toys if you run across them, but better do not trust in or rely on them ...

     

    best wishes - hexdump

  5. i saw things like this too - easy workaround is to put a usb to serial converter there and plug it into one of the usb connectors of the box - i guess its a problem with proper grounding resulting in noise on the serial line

     

    best wishes - hexdump

  6. @fizban - for me those cheap pcm2704 adapters usually gave much better latency than the other cheap usb audio adapters: https://github.com/hexdump0815/sonaremin/blob/master/images/pcm2704-01.jpg

     

    maybe have a look at sfizz as a sampler - it allows to use sfz files (much better than simple sound fonts) of which there are quite a few amazing ones around on the net (quite a few on pianobook for instance):

    https://github.com/sfztools/sfizz/

    https://github.com/hexdump0815/sfizz-arm-build (my notes on building it on arm)

     

    if you want to go a bit furher, you can even run a full modular synth with around 2k avaiable modules (vcvrack) on your qplus - i did builds for h6 tv boxes for an older version - for instance here: https://github.com/hexdump0815/sonaremin/releases/tag/v1.1.6_8 but not yet on the latest improved version https://github.com/hexdump0815/sonaremin-ng ... but for vcvrack you'll have to add a fan to your box as it otherwise will get too hot and throttle the cpu

     

    good luck and best wishes - hexdump

  7. @Zhexue. - did you install the latest jetpack from nvidia first (it just needs to be installed and booted once - as part of it it will ask you if its ok to update the boot firmare)? it is required to get a boot loader onto the board which is able to boot those images.

     

    best wishes and good luck - hexdump

  8. @jock - just an idea regarding the low ui performance with mali: maybe something like "xrandr --output HDMI-1 --mode 1920x1080 --panning 1280x720 --scale 0.6666x0.6666" (to scale 1920x1080 down) or "xrandr --output HDMI-1 --mode 1920x1200 --panning 1280x800 --scale 0.6666x0.6666" (to scale 1920x1200 down) or similar commands for other resolutions might help to bring the on screen resolutions into more managable regions for the little gpu and mem bw? at least i noticed that smaller resolution monitors were working quite a bit better) ... just an idea ...

  9. @kruzer - iirc this change was done intentionally by @jock - he'll most probably reply soon himself regarding this ... there is btw. a kernel cmdline parameter to extend the timeout: "lima.sched_timeout_ms=1000" and depending on how old your mesa is, it might maybe miss this fix: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10121 - also interesting in this context maybe: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3467 which resulted in that fix ... not sure, maybe your problem is a different one ...

     

    best wishes and good luck - hexdump

  10. as far as i understand it not - i think if encryption for the boot process is enabled, then some fuses are being burned in the soc to switch into that mode and a key for decryption and/or checking the signature is also stored in there and i think this is a non reversible process in the hardware (at least not trivially to work around)

  11. @Generic_user - to find out if the bootloader is encrypted you should maybe try to make a backup of the emmc via rkdeveloptool as described by @jock... then you can do a "hexdump -C your-emmc-dump | less" and if you only see random data and no structure at all on the first screen pages then the boot stuff is most probably encrypted - to give some examples how that looks like, just run the below two files through "zcat bootblock.gz | hexdump -C | less" and you should see the difference:

     

    normal boot block: https://github.com/hexdump0815/u-boot-misc/raw/master/misc.rk3328/boot-block.dd/boot-h96max-rk3318-original-emmc.dd.gz

    encrypted boot block: https://github.com/hexdump0815/u-boot-misc/raw/master/misc.gxy/dump-in.dd/s905x2-s10-max-plus.dd.gz

     

    i never saw an encrypted boot block on any rk3318/rk3328 tv box yet (only rk3288 and amlogic s905x and s905x2 so far), but with tv boxes everything is possible :) ... the bad news is: in case it is encrypted, there is nothing you can do - for my rk3288 there was luckily a proper boot block around which was able to boot a regular kernel, but i think this was a very special situation.

     

    best wishes - hexdump

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines