Using Device Tree Compiler

Get the dtc compiler and build it:

From your favorite working directory:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/galak/dtc.git

$ cd dtc

$ make

$ sudo make install

To generate dtb source from the binary blob (dtb)

$ dtc -I dtb -O dts /tftpboot/mpc8349.dtb >/tftpboot/mpc8349.dts

To generate the dtb binary blob from source:

dtc -O dtb arch/powerpc/boot/dts/mpc8349emitx.dts -S 20000 > /tftpboot/mpc8349emitx.dtb

-S argument sets some spare space for the u-boot to add /choosen (and
some other) nodes.

If you get an error like this when you try to boot a kernel using U-Boot:
ERROR: /chosen node create failed - must RESET the board to recover.

It generally means that you need to add some padding to your device tree binary (blob!). U-Boot tries to create nodes in your dtb, and if there is no room to create these nodes, it fails with an error similar to this one.

Use -S as above, to add additional padding to the dtb.

Hey Chris, this a great forum! having completed past embedded linux projects including embedded powerpc 405 on Virtex 4 I have a dogeared copy of the Primer and am a big FAN.

Now I'm working with a freescale mpc8349e-mitx development system and in the process
of upgrading the kernel from 2.6.13.4 to 2.6.25. This led me to u-boot upgrades and
DTS->DTC->DTB

I'm new to DTC but am now somewhat up to speed after searching in LTIB bitshrine and freescale forums. once I complete the upgrade I'll try to summarize what I found out along the way.

well up until this point things have been going along pretty much as expected.
I'm using a standalone DTC build of mpc8349emitx.dts. after loading the kernel, dtb, and ramdisk on the target, bootm launches to the point where ramdisk loads.
the the target HANGS :-o

without any trace log of any sort its hard to tell where the problem lies. is it a problem with the handoff of the device tree block to linux? or perhaps there might be a problem with the way the uImage is built that ignores the dtb?

any ideas on how to isolate this or where to look would be very appreciated!

/steverino2

I'm not a big fan of DTB. I understand why it exists, and what problems the PPC developers were trying to solve, but in my experience, it's all very fragile. One of the initial reasons cited for its use was to eliminate the need to upgrade the bootloader for different kernel/hardware versions. Unfortunately, it doesn't seem that goal was reached. I have the same board, 8349-mITX, and currently it's "broken" because I upgraded to U-Boot 1.3.2 and latest kernel, and have the same issue. I'm doing this work in preparation for my second edition, which I've just signed a contract on. Trouble is, I haven't had the time to roll up my sleeves and dive in!

In any case, try looking at the printk log buffer, as described in Embedded Linux Primer. It works well on this platform, as I've used that trick many times. After it hangs, hit reset (don't power down, obviously) and then using System.map to locate the address of the log buffer, display the contents of log_buf using the U-Boot md command. There are often signs of what happened there.

Many thanks for your contribution here!!