<mmind00>
macromorgan: interesting ... but also why this the patch you linked to is specific to the rock5b at all ... so yes, if that is an issue specific to all rk3588, I'd think we shouldn't require each board to copy that
dsimic has quit [Ping timeout: 264 seconds]
dsimic has joined #linux-rockchip
<Kwiboo->
macromorgan: yes such fixup should be moved and applied for all rk3588 boards, at least any board with 16gb+ ram, the ddr init blob report following ddr banks in atags for e.g. a 32gb board:
<macromorgan>
so how does that work then? bank[0] is the start and bank[4] is the size?
hipboi has joined #linux-rockchip
<Kwiboo->
based on my testing and observation the holes have always been the same, even with different ddr blob versions and always near ~16gb mark on rk3588
<Kwiboo->
yes, there is a count, and first count values = start address for 0 - count, and then size follows
<macromorgan>
not following... so count = 0x4 means there are 4 holes
qschulz has joined #linux-rockchip
hipboi has quit [Ping timeout: 264 seconds]
<Kwiboo->
count = number of banks of usable memory, for count = 2 => [0] = start of bank 1, [1] = start of bank 2, [3] = size of bank 1, [4] size of bank 2
<qschulz>
Kwiboo-: this doesn't seem to match what rock5b has in upstream U-Boot though?
<qschulz>
rock5b_add_reserved_memory_fdt_nodes
<Kwiboo->
qschulz: I think it should match, rang = start+size until next start, hole1: (0x100000000 + 0x2fc000000) to 0x3fc500000 and hole2: (0x3fc500000 + 0x3a00000) to 0x400000000
<Kwiboo->
the hw reg range between 0xf0000000 and 0x100000000 is handled differently, u-boot report two banks of memory to linux, first bank is all memory in 2MB-4GB range (exkluding hw reg range) and the second bank with any memory above 4GB (after hw regs range)
<qschulz>
mmmm it only reports 3840MiB for me on Jaguar
<macromorgan>
identical bootloader, running mainline U-Boot (modified Rock 5B for the moment, will mainline the Indiedroid once I figure this stuff out)
<qschulz>
macromorgan: just to be sure, the 4GiB device does report only 3.8GiB in Linux right?
<qschulz>
trying to figure out if I botched my U-Boot patches or if anyone has the same issue :)
<macromorgan>
let's find out
<qschulz>
if you have MEMORY_HOTPLUG enabled in your kernel, run lsmem --output SIZE --bytes --json
<qschulz>
I only have one bank there with upstream U-boot, but two with Rockchip's downstream U-Boot
<qschulz>
(and the addition of the two banks give me the expected 4GiB obiously :)
hipboi has joined #linux-rockchip
<macromorgan>
let me recompile real quick
hipboi has quit [Ping timeout: 255 seconds]
<macromorgan>
{"memory": [{"size": 4026531840}]}
<macromorgan>
3.8GB it looks like
<qschulz>
yup, thx for the confirmation
<macromorgan>
so I hate to be thick, but what am I looking at here?
<macromorgan>
so for the 4GB I have a bank starting at 0 of size 0xf0000000, and a bank starting at 0x1f0000000 of size 0x10000000?
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 264 seconds]
<Kwiboo>
qschulz: macromorgan: intereseting and good to know about the full 4gb with downstream u-boot
<Kwiboo>
that seemed to be what was done for rk356x, downstream seemed to report ram below hw regs, based on boot logs seen online, I do not think I have ever run vendor u-boot on any of my rk35xx boards ;-)
<macromorgan>
right... I'm not either. Other than the ram init code anyway.
hipboi has joined #linux-rockchip
<Kwiboo>
I was thinking there should be some memory remapping done to make full use, but did not seem to be done on rk356x and have not taken a closer look at rk35xx, only looked little bit closer at the rk atags last week too see what regions atf/optee reported
<Kwiboo>
rk3588*
hipboi has quit [Ping timeout: 240 seconds]
raster has quit [Quit: Gettin' stinky!]
eballetbo has quit [Quit: Connection closed for inactivity]
hipboi has joined #linux-rockchip
<macromorgan>
I guess I'm still not understanding how the ATAG values become memory holes (or rather the correct formula for making them as such)
hipboi has quit [Ping timeout: 255 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 272 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 255 seconds]
hipboi has joined #linux-rockchip
stikonas has joined #linux-rockchip
hipboi has quit [Ping timeout: 272 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 264 seconds]
hipboi has joined #linux-rockchip
<macromorgan>
the last bit I'm strugging with is how the 2nd gap is calculated. why does the hole stop at 0x3ffffffff instead of going all the way to 0x4f0000000? https://paste.debian.net/1307442/
hipboi has quit [Ping timeout: 252 seconds]
<macromorgan>
or rather all the way to 0x4efffffff
psydroid has quit [Remote host closed the connection]
hipboi has quit [Ping timeout: 264 seconds]
<Kwiboo>
that gist would amount to range1 = 0x0-0xefffffff, gap0 = 0xf0000000-0xffffffff, range2 = 0x100000000-0x3fbffffff, gap1 = 0x3fc000000-0x3fc4fffff, range3 = 0x3fc500000-0x3ffefffff, gap2 = 0x3fff00000-0x3ffffffff, range4 = 0x400000000-0x7ffffffff
<Kwiboo>
macromorgan: ohh, I see now that your report bank[3] = 0x4f0000000, instead of bank[3] = 0x400000000, what happen if you use different/newer ddr blob?, what version did you use?
<macromorgan>
I think I used the latest, hang on
<Kwiboo>
rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.15.bin is the one I used