On Thu, Feb 19, 2015 at 10:25:56AM +0100, Jan Kiszka wrote:
On 2015-02-19 10:19, Ian Campbell wrote:
On Thu, 2015-02-19 at 09:28 +0100, Thierry Reding wrote:
On Tue, Feb 17, 2015 at 11:55:24AM +0000, Mark Rutland wrote:
[...]
> This is getting invasive: > > If I add carveouts via adjusting memory banks, I need to account for the > case that an existing bank is split into two halves, creating additional > banks this way. But then current fdt_fixup_memory_banks will no longer > work due to its limitation to the number of physical banks. I could > always add one spare bank to that service, ok, but then the next use > case for carveouts will hit the wall again. So I better double that > limit, or so.
Yeah, not fun.
If the code is position-independent then you might be able to simply carve out a sufficient proportion from the start of the first entry or the end of the last one, which would avoid splitting. If either of said regions are too small for the monitor code then it's questionable as to whether the OS can make use of it.
The code /seems/ to be position-independent, but locations are so far hard-coded in those places that prepare it and move it around. Maybe we can decide about the location at runtime, maybe we can simply demand it to be at the end or the beginning of some bank.
If it's possible to do so, it would seem like the nicest option to me.
Using the top of memory for this seems like the most natural choice,
I think it needs to still be below 4G, doesn't it? So on large mem/LPAE systems some care might be needed.
Argh. That would likely mean we had to split a bank (unless >2G comes in multiple banks), something I'd like to avoid having to implement.
So if we wanted to (properly) support systems with more than 2 GiB of RAM we'd need to make U-Boot LPAE aware. That would cause other kinds of problems, though, and I'm not sure that it's even possible. Looking at the register sets involved it seems like we can't have a reset vector pointing at anything beyond the 4 GiB boundary anyway. It would also mean that a bunch of things might break since I think there are many occurrences in U-Boot where pointers are assumed to be 32-bit.
Perhaps a compromise for now would be to truncate the amount of available memory to 2 GiB if PSCI is used? That's not really optimal but should give us something to experiment. I don't think any of the boards supported upstream have more than 2 GiB, though I'm sure there will be in the not-so-distant future. Most of those may be 64-bit ARM, though, in which case the problem goes away somewhat.
Unfortunately it seems like even for 64-bit SoCs the 32-bit registers for the reset vectors remain, so it would seem like at least for Tegra we're going to need code to split up the memory node eventually. Either that or we move the monitor to the beginning of RAM. But I don't think we can do that either because the Linux kernel will decompress to an offset of 0x00008000 after the start of RAM.
Thierry