I just tried this. Nothing happens after “starting graphical target”. So i assume it is not your monitor.
About RPI 500. There are so much better SBCs in the market now. There is this guy:
https://www.aliexpress.us/item/3256807330556447.html
It is cheaper and has a N100 on it. I’d put my money on that one.
I have pushed rpi4/5-eeprom-20241207 that enables NUMA by default. I did some research the other day on NUMA and one article said that it had 2 parts 1 hardware being compatible and 2nd the software being made aware. So if that being the case I am really at a loss which software to test it on. Looking at handbrake code the other day I accidentally ran across where you can enable NUMA.
[ray@jellyfin ~]$ uname -r
6.13.0-rc2-1-MANJARO-RPI5
[ray@jellyfin ~]$ numactl --show
policy: interleave
preferred node: 7 (interleave next)
interleavemask: 0 1 2 3 4 5 6 7
interleavenode: 7
physcpubind: 0 1 2 3
cpubind: 0 1 2 3 4 5 6 7
nodebind: 0 1 2 3 4 5 6 7
membind: 0 1 2 3 4 5 6 7
preferred: 0 1 2 3 4 5 6 7
I may be wrong, but I don’t understand your eagerness to switch to Numa by default. Because, from my point of view, it doesn’t suit well with RPI CPUs which are less complex than the x86_64. And your previous benchmark didn’t seem convincing…
I did not do it. RPi did in their eeprom images.
https://github.com/raspberrypi/rpi-eeprom/commit/fe7bfc720165464d9dfe2f85fe090ca22a625bd7
Same bug with your test kernel. I have seen that graysky has release news 6.12 and 6.13 with a few changes in config and a patch cpuinfo.
For NUMA all the tests including Geekbench 6 seems better:
Single=923, Multi:1767 (without SDRAM_BANKLOW=1)
Single=1020, Multi: 2259 (with SDRAM_BANKLOW=1)
And the problem with the gpu seems to be found https://github.com/raspberrypi/linux/commit/1348250af3db7537fa9e85afb85f63e8ac514d69
Have you tested the new mesa 24.3 because with it i have glitches with webgl aquarium under chromium or with earth google and twitter with firefox.
Thanks for testing.I have not heard back from RPi yet. I hope they get it fixed soon. I do not believe they have upgraded in their firmware git with the latest .dtb’s but if they do I feel like arch-arm will start complaining. They pretty much follow the 6.6 kernel there and what is in the raspberrypi-firmware repo.
Pi4/6.13-rc2, can log into Plasma fresh install & scx_rusty, no *dtb issue Acer monitor, others APP not test.
edit,
update Pi4/eeprom, now scx + NUMA.
build scx-shaeds-git + youtube + mpv play H265, 30 mins, running…
test2,
H265 + youtube + yquake2, a bit slow but running…
Now that is interesting. Thanks for testing.
you might buy a Pi 15.6" monitor for Xmas 
Sorry if I misunderstood but I think that my question is still valid. What would be the rationale of enabling Numa as the default option?
Edit: I’ve also read more and it seems tobe the balance between SMP and clusters design. It might take advantage of both worlds and leverage cache to remove contingency access. Let’s see what happens with benchmarks.
Btw, I don’t have time to test it directly but I can see changes in RPI repos and I guess they will figure out soon how to fix “DBT” Issue and be able to provide 6.13.4…
quote=“Rip2, post:1174, topic:84885, full:true”]
you might buy a Pi 15.6" monitor for Xmas
[/quote]
Do you want us to create a Kickstarter campaign? 
PI 500, does not include a built-in M.2 slot, sucks.
The pads are there but they ain’t populated.
https://www.jeffgeerling.com/blog/2024/pi-500-much-faster-lacks-m2
the idea is plus $20 next version, they are IPO company after all.
I tested today on my pi400 with v6.13-rc2 and it also booted up ok. So looking like the dtb issues is pi5 only.
I had forgotten how much I disliked the pi400. The key presses are horrible. Some times I have to press a key multiple times. The show stopper for me is 4G ram, Some of the things I do I run out of ram.
@Rip2 I discovered with the eeprom NUMA upgrade for the pi4 they put it in the beta image if you did not know.
[tv@manjaro-arm ~]$ uname -r
6.13.0-rc2-1-MANJARO-RPI4
[tv@manjaro-arm ~]$ sudo rpi-eeprom-update -a
BOOTLOADER: up to date
CURRENT: Sat Dec 7 12:39:28 PM UTC 2024 (1733575168)
LATEST: Sat Dec 7 12:39:28 PM UTC 2024 (1733575168)
RELEASE: beta (/lib/firmware/raspberrypi/bootloader/beta)
VL805_FW: Using bootloader EEPROM
VL805: up to date
CURRENT: 000138c0
LATEST: 000138c0
[tv@manjaro-arm ~]$ numactl --show
policy: interleave
preferred node: 0 (interleave next)
interleavemask: 0 1
interleavenode: 0
physcpubind: 0 1 2 3
cpubind: 0 1
nodebind: 0 1
membind: 0 1
preferred: 0 1
v6.12.4 is out with some patches
here is mine,
CURRENT: 西元2024年12月07日 (週六) 12時39分28秒 UTC (1733575168)
LATEST: 西元2024年12月07日 (週六) 12時39分28秒 UTC (1733575168)
RELEASE: latest (/lib/firmware/raspberrypi/bootloader/latest)
Looks good but really weird that I had to use RELEASE: beta (/lib/firmware/raspberrypi/bootloader/beta) to get that same image on my pi400.
@Dulbi Since @Rip2 and I tested on pi4 and pi400 it appears that the pi4’s are not affected with the .dtb issue so I have pushed pi4/v6.12.4 kernels to unstable.
Here is a link to the pi5/v6.12.4 kernels that one has to use their old .dtbs. I hate to do it but I guess in the future I will start providing the old .dtb’s in the pi5 kernel packages until they fix things.
https://drive.google.com/file/d/1DTcDevlzNKXmR_mX_GfH6uorSDjJ0G7Z/view?usp=sharing
saw 6.13-rc2 patched 2712 *dts issue.
Where did you see that?