[U-Boot-Users] libfdt release?

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Kumar Gala wrote:
> 
> 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.

I've seen it and filed it for When I Have Time.  I agree with the 
concept but have not had time to look at it in detail.  I would like to 
unfork libfdt first... do your changes work with David's current libfdt? 
  Do they work with the current u-boot libfdt?

Your RFC is based off the 83xx method.  Grant Likely convinced me that 
his method of fixup in the 5xxx tree is better (cut the table 
indirection as unnecessary obfuscation, do direct calls instead).  Your 
removal of direct references to CPU and SOC nodes still applies, but I 
have a goal of switching to Grant's direct call methodology.  Perhaps 
you can reroll your patch to use 5xxx as the template and kill two 
bugs^W birds with one patch?

The FDT fixup that your RFC addresses is actually part of the 
CPU-specific code (83xx, 85xx, 5xxx, etc.) and your RFC really should be 
aimed at those custodians (Kim, Jon, Grant, etc.).

Depending on the state of u-boot libfdt and the DTC libfdt, it may also 
require coordination with and update via u-boot-fdt.

>> 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 would like to see libfdt unforked first before we pile a bunch more 
dependencies on top of libfdt, increasing the unforking work.

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

Dang, called my bluff.  ;-)

gvb