[U-Boot-Users] [PATCH libfdt 0/3] Fix CONFIG_OF_LIBFDT problems discussed yesterday

[Jerry Van Baren]

Hi Kim et al.

I dug into the CONFIG_OF_LIBFDT issue discussed 2007-05-25 and it turns
out that my guess that OF_CPU was undefined was wrong.  The problem was
actually errors in my adapting of the original code to LIBFDT.  This is
a 3x patch set, the first two patches fix the problems that Kim noted
and the third is a related clean up of cmd_bootm.c

An explanation of what when wrong, starting with some historical
background: the original CONFIG_OF_FLAT_TREE has a utility routine
ft_setup() which it calls just before booting the linux kernel.
This routine does some significant modifications to the fdt blob and
then starts the kernel.  The only way to see what it did to the fdt was
to uncomment a fdt printout call which dumped the blob out the console
and then started the kernel.  NOT friendly.

With the libfdt utilities and the "fdt" command, I modified this rather
nasty behavior to give the user the ability to do the modifications
of the fdt blob at the command line, observe what was done, hand edit it,
and _then_ boot linux.  Much friendlier.

In order to do this, I had to break up what ft_setup() was doing in
one unobservable step into three functions, fdt_chosen(), fdt_env(),
and fdt_bd_t() which I then was able to invoke for the "fdt chosen",
"fdt env", and "fdt bd_t" commands.

There also is a ft_board() utility (which potentially calls ft_cpu_setup()
and ft_pci_setup() functions) that does (board, CPU, PCI)-specific
fdt fixups.  I adapted the versions used by the MPC8360EMDS (the board I
have) to use libfdt.  So far, so good.

The problem was that, in my adaption (breaking up) of ft_setup(), I
missed the call to ft_board() and thus the (board, CPU, PCI)-specific
fdt modifications were not done.  IIRC, factoring into this omision was
the fact that ft_setup() does /some/ of the CPU-specific modifications
itself (improperly IMHO).  This confused me and I made two errors:
1) I didn't call ft_board() to properly do the (board, CPU,
     PCI)-specific modifications and, worse, 
2) I adapted the (misplaced IMHO) duplicated fdt modifications
     INCORRECTLY.
This is why/where "clock-frequency" was incorrectly set as
"/cpu/clock-frequency" instead of "/cpu/PowerPC,8360 at 0/clock-frequency"
(I lost the OF_CPU part of the node path when I did the adaption).

Once I figured out my errors (above), I changed fdt_chosen() to remove
the erroneous sets and, instead, call ft_board() to properly set the
(board, CPU, PCI)-specific fdt values.  This turned up some errors in
the table fixup_props[] property strings: I had some trailing "/"s on
node paths and some node paths still had the property name appended.
Sloppy coding that makes me ashamed to have my --signed-off-by on. :-(
Because of my other errors (previous paragraph), these functions were
never called and thus I did not detect the errors in my testing. :-(

Anyway, this above novelette could have been more concisely written
"I'm sorry and ashamed, please accept the following patches as an
indication of my resolve to be more thorough in the future."

Best regards,
gvb