hexdump

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

@ljones0 - before you dump it, then maybe give this image a try: https://github.com/hexdump0815/imagebuilder/tree/main/systems/orbsmart_s92_beelink_r89 if it worked with the old linuxium image, there is a good chance that it might work good luck and best wishes - hexdump

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

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

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

i think this does not make that much sense, as you can buy two boxes of the same brand from the same seller and get two different wifi chips: one working and one not - tv boxes are and will remain just a lottery

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

@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

@Onemanpeloton Onemanpeloton - maybe have a careful look at https://github.com/hexdump0815/u-boot-misc/issues/2 before you start - good luck

looks like either bad memory or wrong boot loader as it cannot train the memory timing properly as either the memory is broken or the boot loader has the wrong timing parameters ...

@Dragao - dying emmc is something which happens from time to time with tv boxes - i had it on an amlogic box and i think @jock and @fabiobassa can sing a song about this topic too ... i think tv boxes are sometimes assembled from very low quality components to push prices down ...

@Gustavo A. Díaz - maybe have a look at: https://forum.pine64.org/showthread.php?tid=11209 and https://forum.pine64.org/showthread.php?tid=7387

@phier i it would be good if you would write some more details - otherwise its hard to help - for instance what system and what image you are using and what exactly you want to adjust/change ...

@phier - boot.scr is reading and evaluating armbianEnv.txt - so armbianEnv.txt it the proper file to change it good luck and best wishes - hexdump

@elbuit - if nothing else works, this should usually work to get the device tree from a running android: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy best wishes and good luck - hexdump

@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

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

@jock - could it be that the sd card is not connected to the proper mmc slot - i have seen this on rk3328 boxes - for instance https://github.com/hexdump0815/u-boot-misc/issues/2

@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

@lanefu - as you mentioned the m1 mac: there is a very nice brew package around, which gives you a qemu there which even sends opengl via virgl and angle to the m1 gpu - not the fastest in the world, but better and more cpu saving than software rendering - https://github.com/knazarov/homebrew-qemu-virgl

@jock - just in case: the slick greeter is also working well on armhf

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)

@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

@Generic_user - the rk3318 is most probably only a lower quality rk3328, but otherwise identical ... you should give the rk3318 images from @jock a try: good luck and best wishes - hexdump

... but galliumos does not support arm chromebooks ...