[U-Boot] [PATCH v3 6/6] fdt: add decode helper library

[Aaron Williams <Aaron.Williams@cavium.com>]

Hi,

On Friday, October 14, 2011 11:21:54 AM Simon Glass wrote:
> Hi Kumar,
> 
> On Fri, Oct 14, 2011 at 11:12 AM, Kumar Gala <galak@kernel.crashing.org> 
wrote:
> > On Oct 11, 2011, at 5:26 PM, Simon Glass wrote:
> >> This library provides useful functions to drivers which want to use
> >> the fdt to control their operation. Functions are provided to:
> >> 
> >> - look up and enumerate a device type (for example assigning i2c bus 0,
> >> i2c bus 1, etc.)
> >> - decode basic types from the fdt, like addresses and integers
> >> 
> >> While this library is not strictly necessary, it helps to minimise the
> >> changes to a driver, in order to make it work under fdt control. Less
> >> code is required, and so the barrier to switch drivers over is lower.
> >> 
> >> Additional functions to read arrays and GPIOs could be made available
> >> here also.
> >> 
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >> ---
> >> Changes in v2:
> >> - Add example proposed decode helper library
> >> 
> >> Changes in v3:
> >> - Simplify decode library to remove provide only primitive functions
> >> - Remove i2c decode function
> >> - Rename fdt_decode to fdtdec, since it will be used a lot
> >> - Moved fdt_decode.c to /lib
> >> - Export almost all functions from fdtdec, to allow widespread use
> >> - Remove use of FDT_ERR_MISSING which is not strictly needed now
> >> 
> >> include/fdtdec.h |  122
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++ lib/Makefile     |  
> >>  1 +
> >> lib/fdtdec.c     |  131
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed,
> >> 254 insertions(+), 0 deletions(-)
> >> create mode 100644 include/fdtdec.h
> >> create mode 100644 lib/fdtdec.c
> > 
> > I think this is the wrong approach.  If we intend to go down the path of
> > embedded a device tree we should look at produce a live tree structure
> > that can be used like Linux has.
> 
> The intent of this patch set is to provide U-Boot with a simple
> run-time configuration system.
> 
> Can you please explain why you want a live tree for use by U-Boot?
> U-Boot already has one that it passes on to Linux, and this is under
> control of scripts, etc., quite separate from this.
> 
> This fdt is for configuration of devices used by U-Boot itself.
> 
> What can U-Boot find out that it would want to put into this private
> fdt? Are you thinking of probing for devices early on and then using
> them later in U-Boot? If so, surely no code can exist which does this
> now, since this patch set is new.
> 
> > There are a lot of places we are manipulate device tree blobs that would
> > be more efficient if we had a live tree structure in place.
> 
> Please can you point to these? Are you sure you are not referring to
> the working_fdt? As I understand it this is already a live structure.
> 
> > I think that will only get worse with the addition of embedding a tree.
> 
> I need a bit more info / understanding before I can respond to this
> email properly.
> 
> Regards,
> Simon
> 
> > - k
> 
This would actually be helpful for us. We have switched our bootloader to make 
use of the FDT and use it both within our common SOC code which is linked to 
our U-Boot image as well as what we pass to the Linux kernel.

We use a single FDT image for both.

We currently have our FDT for each board contain all possible options and then 
at runtime trim the parts that are not detected at runtime. Many of our boards 
have pluggable networking modules for example which are supported by our U-
Boot image.

-Aaron

-- 
Aaron Williams <Aaron.Williams@cavium.com>
 (408) 943-7198