01:07 <macromorgan> early on I had logic that fell back to the "old" way of doing things when the first bank didn't end at 0xf0000000. I wonder if I should go back to that...

01:09 <macromorgan> dumb question, but what if I just took the banks as they were and explicitly hard coded holes for 0x0 to 0x20000 and 0xf0000000 to 0xffffffff. Would anything upstream or downstream care about memory holes "where the banks don't always go"?

07:39 <Kwiboo> macromorgan: yes, we always need to exclude 0-2 MiB and SDRAM_MAX_SIZE - 4 GiB

15:06 <macromorgan> Kwiboo: Right, but what I'm getting at is would it be appropriate to set the RAM bank as it is (without reservations), and then simply hard code reserved/nomap blocks. So your bank would start at 0x0 (instead of 0x20000), but there would be a reserved node telling you not to mess with 0x0 - 0x20000 (or 0xf000000 0xfffffff)

15:06 <macromorgan> dumb down the logic, so to speak

15:07 <macromorgan> like for the 8GB board I dont' know what would happen if we simply had 0x0 - 0x20000000 open, and then put our reserved nodes in

15:27 <qschulz> macromorgan: do you think we can have a reserved memory node in <SoC>-u-boot.dtsi?

15:30 <qschulz> macromorgan: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml

17:44 <macromorgan> setting it in the U-Boot tree doesn't appear to have worked (reserved memory). I'll see what other options I have...

17:48 <qschulz> macromorgan: we would probably need to read those reserved-memory nodes from U-Boot though

17:48 <macromorgan> yeah, that's what I'm trying to look at

17:48 <macromorgan> basically a way to define them as reserved in U-Boot and pass that along to Linux proper

17:51 <macromorgan> maybe just set the reserved memory in the u-boot.dtsi files for the rk3568 and rk3588, then do a SoC specific carveout using fdtdec_add_reserved_memory

17:51 <macromorgan> when I set the reserved memory in the u-boot.dtsi I can clearly see the bdinfo shows it as reserved

18:56 <macromorgan> qschulz... what happens to your boot if you temporarily put reserved memory nodes in your Linux DT to prevent it from reading the spots it's not supposed to. Basically from 0 to 0x1fffff and another one from 0xf0000000 to 0xffffffff?

18:57 <qschulz> macromorgan: isn't this what U-Boot is supposed to do to the DT passed to Linux anyway?

18:57 <macromorgan> I'm testing putting the reserved-memory in U-Boot under the rk3588s-u-boot.dtsi and using the ft_system_setup() to set the stuff

18:59 <macromorgan> What I'm trying to do is avoid a bunch of unnecessary processing... if U-Boot can pass the memory banks as-is from the ATAGS and we can simply create reserved nodes that are always true it should work for all cases. Otherwise we'll have to make special logic for the 8GB boards

18:59 <macromorgan> every board I have on hand the ATAGs creates a correct hole though at 0xf0000000, I'm trying to see how it works on your board that doesn't

19:00 <qschulz> macromorgan: it's Kwiboo who has an issue with their board, not me (though I haven't gotten my hands on 8/16GB RK3588 devices yet....)

19:00 <macromorgan> sorry, got it mixed up

20:49 <macromorgan> okay that didn't work (just setting the nomap stuff). I think I'll just skip the new logic unless the size of the first bank is equal to the max_ram stuff.

20:55 <Kwiboo> macromorgan: sounds like a good option, I have been too busy with my day job to test anything yet, but should have some time to test tomorrow

20:55 <macromorgan> okay... I'm trying to put together another revision with the input from the mailing list

20:55 <macromorgan> I'm going to skip the logic in the event that the first RAM bank is bigger than SDRAM_MAX_SIZE

20:56 <macromorgan> that way it will fall back to the old way of doing things

20:56 <macromorgan> I honestly believe (unless there's a reason I don't know about) that 8GB thing is a bug in the ram init code

20:57 <macromorgan> because the RAM init code also costs you 256MB of RAM on an 8GB board that it doesn't cost you on a 16GB board

21:09 <Kwiboo> I fully agree, the reported banks on 8gb rk356x seem like a bug, it is the only one that behaves differently

21:17 <diederik> One of the 'latest' commits in the rkbin repo fixed an issue with 6GB, maybe 8GB is next? ;)