David Gibson wrote: > On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote: >> Grant Likely wrote: >>> On 10/25/07, Martin Krause <[EMAIL PROTECTED]> wrote: > [snip] >>>> On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc" >>>> partition could not be used. "big-fs", because the memory is too small >>>> (which is OK) and "misc", because it overlaps 1 MiB over the physikal >>>> flash border. So only the first 9 MiB of the flash could be used in Linux. >>>> The remaining 7 MiB couldn't be accessed. >>> Perhaps it would be better to drop the flash layout from the in-kernel >>> dts files entirely since flash layout can be a fluid thing. >> Well, but that would not be really user friendly, I'd rather stick >> with some default config. > > Strictly speaking the device-tree is not the right place for flash > partitioning information. We put it there because it's preferable to > having hardcoded per-board flash layouts in the code itself. > > It only really works well, though, when there are strong conventions > (shared with the firmware) about how to partition the flash. > > Where it's really up to the user to determine how they want to lay out > their flash, putting things in the device tree isn't a really good > idea.
In principle, you are right, we should not be putting a user dependent configuration into .dts files. But on the other hand, bindings have been defined for flash-like devices and their partition layouts and physmap_of device driver is expecting to get this information from the blob. So, it is the place for it. But if we are not to put partition layouts into the default kernel .dts files then we should provide/maintain some examples an that may be a even bigger mess. > Incidentally, it's not required that *all* the flash address space be > in partitions, so it is possible only give partitions for those flash > chunks which the firmware needs to know about. That might be nicer solution but different variants of TQM5200 boards do not share the same subset of partitions (default u-boot partitions at least), so it will not help much. Cheers, m. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
