[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

Wolfgang Denk wd at denx.de
Wed Feb 20 00:14:28 CET 2013


Dear Rob Herring,

In message <5123E311.1070607 at 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: wd at denx.de
I've got a bad feeling about this.


More information about the U-Boot mailing list