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. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
