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