00:08 <macromorgan> diederik: CMA? Should only be a 256MB hole that we know of.

00:09 <macromorgan> Kwiboo: I was doing a grep to find 3588 boards that have holes defined so I can remove them and let the auto-detect find them instead. Sounds like since 356x can't do more than 8GB we don't have any existing hole carveouts to remove

00:16 <HeyMeco> Hey everybody I was connecting different PCIe devices to RK3588 and with an Nvidia GPU Linux ignores the 64-bit pref window and also wants 16 MB of 32-bit memory for BAR0 which is split into different subregions like for I/O space in the current mainline dts. Dmesg and other infos are here https://github.com/HeyMeco/Rockchip-pcie-devices/issues/2 .

00:16 <HeyMeco> Any ideas on how to get it working?

00:19 <macromorgan> also when I kill the holes, should I flat out delete the entire whatever-rk3588.c file for each board (since that's all they do)? I was just thinking to essentially delete all the reserved memory node stuff and make the main ft_board_setup() routine return 0.

00:19 <vagrantc> /18/20

00:39 <diederik> macromorgan: the default value for CMA on Debian is 64MB

00:41 <diederik> and then still, doesn't it reserve a piece of RAM and thus should not be subtracted from the 8GB?

00:42 <diederik> "Memory: 3861596K/8124416K available (14336K kernel code, 3022K rwdata, 10352K rodata, 7552K init, 628K bss, 290996K reserved, 65536K cma-reserved)"

02:11 <macromorgan> well I'll push some new patches tomorrow, try them and see if it helps once I'm done

10:05 <Kwiboo> diederik: what does U-Boot report on the "DRAM: 8 GiB (effective 7.7 GiB)" line?, possible linux reserve some more than just the 2+256 MiB that is reported reserved/not usable from U-Boot

10:07 <Kwiboo> macromorgan: I would remove the entire .c-file and probably also the Makefile, and I can test your patches as soon as you have something new to test

11:53 <diederik> Kwiboo: Is there a way I can retrieve that from a running system? It's currently compiling a kernel ;)

15:24 <diederik> Kwiboo: I'll check when the build is done which shouldn't be too long now (I hope). I'm running v2023.10 due to the network issue. Does that matter? I can make a newer one with the network commit reverted

18:22 <macromorgan> RAM bank code take 3 (or 2 or whatever): https://lore.kernel.org/u-boot/20240401181435.553351-1-macroalpha82@gmail.com/

18:22 <macromorgan> this is for both the RK356x and RK3588

19:19 <diederik> Kwiboo: It reports as you said: "DRAM: 8 GiB (effective 7.7 GiB)" (full log: https://paste.debian.net/1312713/)

19:47 <diederik> macromorgan: your 1st patch has 'V1' instead of 'V2' and I guess that's why b4 didn't find it?

20:09 <macromorgan> damn

20:09 <macromorgan> always make a mistake :-(