Dear Rob Herring, In message <5123e311.1070...@gmail.com> you wrote: > > > I dislike this. If you want to make a property of your device tree > > "immutable", then you should mark it there as such. Instead of > > removing the code here, U-Boot should then check for such a property > > and leave the value unchanged. > > There is no such way defined to flag that and I'm not going to invent > one. It's not that the memory node is immutable, but the default should > not be "needs fixups". No one puts purposely wrong data in their DT. So > therefore all data should be immutable? What happens when we need to > fixup immutable data?
There is for example the "status" property, which can take the values "okay" or "disabled". This is used in other places for not so unsimilar purposes. > What I would really prefer to do is like powerpc where platforms > override this if they need the fixup and the default behavior is no > fixup. But that would require knowing which platforms do and don't need > the fixup. It only going to get harder to change that. Normally we use get_ramsize() to check / verify the amount of available RAM. And on PPC, we nearly always set the ram size in the DT. I don't know why you think the default was no fixup; this is not true. It's the other way round. > > Actually you are reaching here a point where it seems necessary that > > U-Boot itself is able to read the DT to configure itself correctly, > > i. e. the memory size information it holds should then also be > > extracted from the DT. > > I thought about doing this. That's really an orthogonal issue. The > problem is you cannot adjust the amount of memory u-boot uses to be > different than the amount of RAM in the /memory node. If you adjust the > size in u-boot, the adjusted size is passed to the kernel no matter what. > > There's issues with LPAE systems having >4GB of RAM as all the size and > address values are 32-bit. This could be fixed, but I'm not sure there > is much value in u-boot knowing about memory above 4GB as it can't > really access all of it and it would be purely informational. Well, let's face it - no matter what you do, if the RAM sizes as used in U-Boot and in Linux differ, at least one of these is wrong. This is a bug that should be fixed. What you attempt to do is implementing a method to paper over such bugs. This is not a good thing to do. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I've got a bad feeling about this. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
