于 2018年4月3日 GMT+08:00 下午7:34:55, Maxime Ripard <maxime.rip...@bootlin.com> 写到: >On Tue, Apr 03, 2018 at 11:13:17AM +0100, Andre Przywara wrote: >> >>>> For hacking it, see my implementation in v1, which assumes the >> >>>> only size supported bigger than 2GiB is 3GiB (which is >> >>>> acceptable on sunxi, but might not work on other platforms). >> >>>> >> >>>> As Andre said, that function has another big problem -- it >detects >> >>>> memory with writing to it. This is risky. >> >>> >> >>> How is it risky when it's done by the SPL? >> >> >> >> Originally that was my confusion as well: It's not the SPL calling >that >> >> function. The DRAM controller init function in there knows very >> >> precisely how much DRAM we have, but we don't communicate this to >U-Boot >> >> proper. So U-Boot *proper* goes ahead and probes the DRAM. This >means it >> >> could step into secure memory, for instance. On sunxi64 we have >the ATF >> >> running between SPL and U-Boot, also all kind of secure payloads >could >> >> already have been registered. >> >> So I wonder if it would be easier to somehow pass on this *one* >word of >> >> information between SPL and U-Boot proper to avoid calling this >function >> >> altogether? >> > >> > That would definitely make sense yes. >> >> So since the SPL loads the DT anyway (from the FIT image) and puts it >at >> the end of the U-Boot (proper) binary, wouldn't it be the easiest to >> just patch the actual DRAM size in there? >> IIRC we don't have any FDT write code in the SPL at the moment, and >> pulling it in would probably push it over the edge again, but: > >That assumes that you are loading a FIT image, which might or might >not be the case, and on most arm32 chips, most likely won't. > >I guess we'd need to find another way (put some information in an >SRAM somewhere?) to try to do that for all variants.
Extend the SPL header again? If we found SPL v3+, use the DRAM size encoded and bypass ram_get_size, otherwise fallback to ram_get_size? (Although it will lead to some days of mess on sunxi-tools, this is a reasonable choice.) > >Maxime _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot