Open benpoulson opened 2 years ago
Setting the mem
env to 1024M
in uboot does stop the issue. Going to slowly increment back towards 2048M to see where the issue starts again.
@benpoulson - this is one of the things i planned to suggest to you (besides disabling the higher frequency opp points in the dtb): i guess the box simply just has 1gb of ram - android tv boxes are quite known for fake specs and it goes so far even that the fake specs are shown in android and sometimes even the chip labels are modified to pretend a better chip on the board ... this unpredictable quality and unreliable specs of tv boxes is the reason why i nearly gave up on them (nowadays they are even as expensive as regular sbc's so one reason less to use tv boxes instead of those) - there were even boxes with a different soc in it than printed on the box ... and specs can be way off: i have one 4/32gb box which was 1/8gb in the end and you can even buy multiple boxes at the same time from the same seller and get some with different specs and boards :)
Unsure if you've done anything more than disable the hardware acceleration within the xorg environment; but I can confirm the WIP bookworm debian install runs FLAWLESSLY on the x96q and doesn't run into any of the above memory issues. (can address all 2GB of RAM)
I'm even able to modify the device tree to clock up to 1.60ghz without any reliability problems. Been running a cpu+memory stresstest for the last week without any fault.
@benpoulson - this is very good news - what exactly did you use for this? an imagebulder built bookworm image with v5.18.1 kernel or the latest bullseye image updated to bookworm or something else?
@hexdump0815 - I used the bookworm image built by imagebuilder. Completely standard setup, no other changes (except the device tree CPU clock changes)
allwinner_h616_release_version="5.18.1-stb-616%2B"
allwinner_h616_uboot_version="211126-01"
mesa_release_version="22.1.1"
Zero issues at all. I just finished the stress test and it's still completely stable.
I've not checked the repo in the last few days, but I'm on commit:
commit ff682b751971786043c9186177eb28276011394b (HEAD -> main, origin/main, origin/HEAD)
Author: hexdump <hexdump0815@googlemail.com>
Date: Tue Aug 30 22:14:28 2022 +0200
@benpoulson - once more thanks a lot for this info ... i think there were no other changes - i'm meanwhile updating my bullseye systems more and more to bookworm as it simply runs much better and is meanwhile way more up to date and still useable stable ... btw. the imagebuilder puts the git commit hash it was built from in /etc/imagebuilder-info - just in case you were not aware of it yet
best wishes - hexdump
Hey,
I have the 2GB RAM 16GB Storage model of the x96q; and it's currently failing on all builds you've published (220618-02, 211204-03 on focal, bullseye and jammy) so far for the h616 chipset.
Sometimes you can reach the desktop, sometimes you fail even before the uart console can present a login, but it always fails with the following error when put under any amount of load.
[ 5.740570] Unable to handle kernel paging request at virtual address ffff8bffeffd0680
I'm not sure if you previously only tested on the 4GB model, but I don't have access to one yet; but I'm assuming this issue will probably be down to my 2GB model.
I've tried modifying and recompiling the memory settings in the DTBs found in both uboot and the kernel with some memory values I found in the official sun50iw9p1 DTBs to attempt to get around the issue, but with no luck. I'm not skilled enough to track down the root of the issue.
Hopefully you can shine some light on this issue!
Here's the full console dump: x86q_error.log
Lastly, I'd like to say thanks for the brilliant work you've put into this project. It's infinitely useful.