On Thu, Apr 17, 2014 at 04:18:45PM -0500, Rob Herring wrote: > The problem here is more than just the TEXT_OFFSET changed. From what > I've heard, there are some QC chips which need much more reserved RAM > than the 2MB discussed here. Changing the TEXT_OFFSET is a hack that > doesn't scale. You may think it's a hack, but we really can't get around this. There really are platforms out there where we must do this kind of stuff. I invite you next time you meet up to talk to Michal Simek. There's no way they can load the kernel at 32K into RAM. > A simple issue is you are now wasting 2MB of low memory on every > platform. Not such a big deal I guess. But what if more is needed? Why do you think it's wasted in the general case? Do you think the first 16K is ignored by Linux? All memory will be freed to the Linux page allocator unless it has an explicit reservation in memblock. So the 2MB won't be wasted - it will be freed as before to the page allocator. > The zImage requires that the kernel be placed at a 128M aligned > address plus TEXT_OFFSET. The v2p patching then requires the kernel to > be located within the first 16MB of RAM. So the Image can only ever be > placed at 0x8000 - 15.?MB from a 128MB aligned address. You can never > have the first 16-127MB of RAM reserved. Wrong. You can have as much RAM as you want reserved, you just can't manage it with Linux memory allocators if you go over 16MB. Remember that the virtual address space PAGE_OFFSET...kernel corresponds with PHYS_OFFSET...kernel. So, if you have 16MB between PHYS_OFFSET and the kernel, then you have 16MB between PAGE_OFFSET and the kernel. Your modules are looking very distant, and PCREL24 relocations become troublesome. > The only way to have reserved > memory (in chucks of 16MB) is by loading an Image file directly > instead. The bootloaders will know the start of RAM and any reserved > memory size because they can simply parse DT. > > Bootloaders are going to have to change for arm64 Image support > anyway, so we should have an aligned solution here. No. You simply can't eliminate any of the above - each one has been negotiated through quite an amount of discussion with relevant parties and/or due to technical requirements and they just can't be magic'd away. Plus the ARM64 image format is different from our zImage format. It would make far *more* sense to align our Image format with our zImage format so existing boot loaders which look for the zImage magic numbers can boot plain Image files too. Moreover, since we could *never* align zImage with the ARM64 format, why on earth would we want to start using the ARM64 format for the Image format? If you say, we should just break the existing zImage format, my response will be: who the hell are you to decide to break 20 odd years of boot ABI in a way which *stops* platforms from booting on such a pathetic whim. No, this is *not* going to happen. It is either the zImage format or no special format at all. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
