[U-Boot-Users] Imminent u-boot-fdt pull request

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Kim Phillips wrote:
> On Fri, 25 May 2007 13:33:49 -0400
> Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
> 
>> Kim Phillips wrote:
>>> On Fri, 25 May 2007 12:56:13 -0400
>>> Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
>> [snip]
>>
>>> please do not ask Wolfgang to pull patches to files in mpc83xx and
>>> related directories (cpu.c, board configs, etc.) from your tree; they
>>> should go through the mpc83xx tree from now on.
>>>
>>> Kim
>> In retrospect, that was impolite and I apologize for the crossover. :-(
>>
>> The 83xx changes were necessary to make the bootm using libfdt work (I 
>> have a 8360 board).  If I don't push the necessary changes through 
>> u-boot-fdt, u-boot-fdt will be impossible to use until you add the 
>> necessary changes in the 83xx repo (and possibly vice versa).  In 
>> addition, Wolfgang would have to coordinate his pulls into the main repo 
>> or it would break.
>>
>> The cross coupling is unfortunate, but we have to have one example of a 
>> CPU/board and libfdt coupled in order to test the libfdt changes.
>>
>> I would prefer to fix the problems noted (which really are not as bad as 
>> they look IMHO) to make one CPU+board+libfdt example work and push those 
>> changes to Wolfgang via the u-boot-fdt repo.  If you are opposed to 
>> this, I can back out the 83xx changes and push just libfdt stuff to 
>> Wolfgang and supply you with the set of 83xx patches which you can push 
>> through your repo, but it will tough for others to use/test since they 
>> will get only half a picture from each repo.
>>
> 
> nothing would have broken if LIBFDT were not turned on by default.

Yup, I screwed that up in my first pull request to Wolfgang. :-/

> the only reason nothing seemed broken in the first place was the
> coincidence that the board you developed on is one of a handful of
> boards with valid (non-zero) default -frequency values in its dts (in
> Linux).
> 
> anyone can just as easily pull the mpc83xx git tree on top of the fdt
> tree, or vice-versa, as clone Wolfgang's stable or testing tree.
> Wolfgang doesn't ever have to do anything except respond to our pull
> requests.  You and I can coordinate pull requests if you think it's
> necessary (I don't think it will be in the long term).

I agree with this in the long term.  I screwed up enabling LIBFDT by 
default and got carried away making bootm work... but those are excuses.

> I don't see any reason why any mpc83xx specific patches should bypass
> the mpc83xx tree, and any libfdt specific patches bypass the fdt tree,
> for that matter. If you want, you can put your mpc83xx specific patches
> on a mpc83xx branch on your tree, and ask me to pull from your tree,
> after having posted the patches on u-boot-users, if you think it's more
> convenient.
 >
> Let's concentrate on getting things fixed; I'm not going to post a patch
> to turn off LIBFDT on the MPC8360EMDS unless Wolfgang informs me of an
> imminent release or something.  In fact, the reason this came about was
> because I'm adding a new board, and I thought it be good if it used
> libfdt.  I like libfdt, but it needs to work, be readable, and be easy
> to use.

Just quibbling, I consider libfdt/* and cmd_fdt.c to be good quality. 
The cmd_bootm.c and associated code (fdt_chosen(), fdt_env(), 
fdt_bd_t(), ft_cpu_setup(), and ft_pci_setup()) is what is rough.

Part of that is my inattention to detail (hacking without understanding 
the code first), part of that is my lack of "big picture" understanding 
of what the blob contents /should/ look like, and part of that is my 
small sample size (one) that just happens to work. :-(

> btw, I'll try to be more prompt with my testing in the future; please
> be more thorough with yours.

Fair enough.

> Thanks,
> Kim

Thanks in turn,
gvb