On Fri, 8 May 2020, Chris Brandt wrote: > The big argument was always that "XIP cannot be multi-platform by > definition because RAM/ROM always resides at different addresses in different > devices". And as you know, the physical address for RAM and ROM have to > be hard coded in the kernel binary. Exact. So what is the problem? > At an ELC a while back, I talked to Arnd and his suggestion was to put > the base addresses for RAM and ROM at a fixed location in the kernel > binary. Then for each SoC, you manually modify those values in the each > binary to match your board. This means there is 'technically' a single build > that will support all boards. The very reason for using XIP in the first place is to maximize resource savings on constrained platforms. Any notion of a multi-platform kernel is completely contrary to this goal. This is even more true for no-MMU platforms where you can't abstract physical address differences behind a page table. Multi-platform kernel supporting all boards make sense for generic distros and/or build coverage tests. But a multi-platform XIP kernel is a nonsense. Trying to make XIP multi-platform might be a nice intellectual challenge but that has zero value for actual deployment and usage. Given that there isn't a lot of such platforms anyway, it should be possible to carry a few kconfig entries outside of the multi-platform menu for XIP targets and live with possible kconfig duplicates. That shouldn't be such a maintenance burden. Nicolas
