[U-Boot-Users] libfdt release?

[Kumar Gala]

On Oct 15, 2007, at 2:23 PM, Jerry Van Baren wrote:

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

A mix.  I grabbed some functions out of David's libfdt to get the  
name of the node based on offset.  Thus my desire to get david's  
libfdt into u-boot.

> 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 one problem I had with direct calls is you really need/want to  
iterate over a set of nodes not just a single one in some cases (like  
fixing up CPU nodes).

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

It was RFC for anyone and everyone to comment on :)

The fixup code itself was generic, the table was specific to 85xx.

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

agreed.

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

Agreed.

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

good try :)

- k