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

[Simon Glass]

Hi Aaron,

On Fri, Oct 14, 2011 at 6:42 PM, Aaron Williams
<Aaron.Williams at cavium.com> wrote:
> 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 at 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 at 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.

Do you like the fdt with U-Boot or find it in flash somewhere?

>
> We use a single FDT image for both.

This is easy enough with the current patch set in that the build
system can provide the same fdt to both U-Boot and the kernel. It
would also be possible to make a copy of the U-Boot one (through some
new 'fdt' command), update it and pass it to the kernel. It might be a
little early to do that though - at least on the ARM side many fdt
things in the kernel are still in flux and there might be a desire to
limit the U-Boot changes (dealing with changed fdt definitions for
peripherals, etc.) forced by changes in the kernel.

>
> 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.

Sounds great. On ARM SOCs there is often not much interest in probing
since it either isn't possible or isn't useful (since things are known
at build time anyway). So far my patch set does not deal with a
dynamic fdt - it is just a basic implementation to get started. I'm
sure it can expand as need dictates.

Regards,
Simon

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