On Wed, Apr 09, 2014 at 11:39:10PM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20140409182426.GV23803@bill-the-cat> you wrote: > > > > > I understand what you mean and what you want, but I'm not really > > > happy about it. > > > > Code or comment wise? > > Both...
OK, concept wise? > > Right, so we have a mismatch between function name > > (fdt_fixup_memory_bank) and function of the node > > (Documentation/devicetree/booting-without-of.txt in the kernel is, > > sadly, the best description I can find of the memory node bindings). We > > itterate over the number of "banks" passed in (1 on PowerPC, > > CONFIG_NR_DRAM_BANKS on ARM, which is between 1 and 4) and do, as the > > If I u nderstand correctly, CONFIG_NR_DRAM_BANKS gives only the > maximum possible number of banks. On the actual system less banks may > be present. If I recall correctly, when we have less populated banks than CONFIG_NR_DRAM_BANKS we set size to 0, but I'll have to double check the omap3 sdrc and emif code. > > binding expects, set the reg property correctly (base, size) for each > > "bank". It would be more correct to call this "ranges" rather than > > "banks", or perhaps "nr_ranges". > > Yes, ture. But then, AFAICT ARM has never made such clear definition > of terms, and for the tyical ARM memory controllers "range" and "bank" > are actually synonyms, so this never bothered anybody. Well, the binding means "range" not "bank". The usage of CONFIG_NR_DRAM_BANKS within U-Boot is used to check for actual banks. I'm not aware off-hand, but it's not impossible that we have discontiguous DRAM chunks. I know on omap3 we make sure to map them contiguously. The high level point here is to get things to the point of having a single call we use for setting the /memory node for the kernel so that we can then easily enough change things so that this depends on CONFIG_something_or_another so that cases where we know we don't want to modify the /memory node (it contains more memory than we can probe or discontiguous ranges that again, we can't probe), we don't. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
