Dear Rob Herring,
In message 5123E311.1070607@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