[U-Boot-Users] libfdt release?

[Kumar Gala]

On Oct 15, 2007, at 1:51 PM, Jerry Van Baren wrote:

> Kumar Gala wrote:
>> Guys,
>>
>> Can you tell me where we stand on changes/additions to libfdt vs u-
>> boot.  I'd really like to see an updated libfdt imported into u-boot
>> for the next window and am happy to work on the u-boot modifications
>> as long as I understand what exactly they are.
>>
>> Having fdt_get_name() and fdt_get_path() will be really useful for
>> some fixup of device node code I've got and will allow us to drop the
>> hard coded/explicit PATHs to nodes from <config.h>.
>>
>> I'd rather see us take a clean libfdt drop rather than pulling in
>> bits and pieces.
>>
>> - k
>
> Hi Kumar,
>
> My plan for the next merge window is to pull a fresh copy of The
> Official LIBFDT into u-boot-fdt.  From what David has said, libfdt has
> been filled out with some functions that we independently invented
> and/or there are better ways of doing things, if only we were smarter.
>
> I have not had time to actually pull a copy of the current libfdt from
> the kernel/dtc repository and evaluate where we stand.
>
> I would also like to see improvements to the 83xx CPU handling to  
> match
> what Grant did on the 5xxx sub-repo.

Have you looked at my post: RFC: flat dev tree fixup code?

It takes the 83xx style and removes the hard coded paths.  This could  
easily be converted into explicit function calls if desired, with  
some caveats.  My biggest issue is wanting to remove OF_CPU, OF_SOC,  
etc. from u-boot.

> My problem is that I had zero "u-boot" time available last month.  I
> have hopes for some time this month, but it is questionable.  Maybe
> November...

I understand, and thus my offer of trying to help out.  I dont know  
all the history of what we have in u-boot today vs the libfdt that  
was imported.  Once someone can clearly say here are some things that  
we need to handle in u-boot based I'm happy to try and work on those  
items.

> I don't anticipate a problem unforking libfdt, but it all takes time.
> Whatever you can contribute towards this, I'm happy to queue up for  
> the
> next merge window.  If you have the time and desire to take over
> custodian responsibilities for u-boot-fdt, we can discuss that too.

I don't really have time to be custodian.  The linuxppc stuff takes  
up more than enough time.

- k