On 05/05/2014 11:17 AM, Doug Anderson wrote: > On Fri, May 2, 2014 at 7:00 PM, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote: >> Well, if you can use the device tree of peach-pit board and boot peach-pi >> and vice-versa and it won't cause any hardware failures then I guess it's >> fine to keep this string. > > I believe you can actually make it a good portion of the way through > boot, though a bunch of things (including graphics) won't work. I > general I don't think it's all that different from "exynos5". > > >>>> I don't think this is a good idea, because this is basically rendering >>>> this >>>> dts file useless, unless used with a bootloader that can actually inject >>>> correct values. I believe that some generic setup could be provided in >>>> the >>>> dts, so you could at least get the board running. >>> >>> >>> I won't say that I care a whole lot, but I think that was what was >>> agreed upon the other day. Specifically Tom Rini of U-Boot was >>> worried about the fact that U-Boot will read the memory node and >>> totally clobber it. He thought there might be cases where someone >>> might _purposely_ not want U-Boot to do that. >>> >>> ...I would wonder what alternate bootloader you're imagining will >>> actually run on this board and not do this? >> >> >> People should have the freedom to choose anything they want. We have also >> barebox and coreboot with ARM and even Exynos5 support (in coreboot), but >> people might want to use something completely exotic as well and the device >> tree should let them do so. > > Fair enough. Unless Tom cares about this enough to throw his opinion > in here, I guess our answer is that the memory node should have a sane > default and we'll expect the bootloader to put something better in if > it can properly probe memory. > > In this case I guess it would be 2GB. So, a memory node that says a size of 0 is a valid and long standing (see PowerPC folks) way of saying "please fill in my memory node value for me" due to any number of reasons for not knowing before hand how much memory there is. Any boot loader which cannot fill in the memory node is going to have problems with the various boards (PowerPC, ARM and other) which say "my memory size is 0, I want this fixed up at run time". The problem I was raising at the ELC BoF is that today we can't just stop overwriting values in the non-zero case as many boards lie about their memory size, in non-zero ways, but no one noticed as they only tested with U-Boot which was performing the fixup. -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html