[U-Boot-Users] How to add device tree support to a board?

[Jerry Van Baren]

Gerhard Pircher wrote:
> Hi,
> 
> -------- Original-Nachricht --------
> Datum: Thu, 21 Jun 2007 21:22:06 -0400
> Von: Jerry Van Baren <gvb.uboot at gmail.com>
> An: Gerhard Pircher <gerhard_pircher at gmx.net>
> CC: u-boot-users at lists.sourceforge.net
> Betreff: Re: [U-Boot-Users] How to add device tree support to a board?
> 
>> It is hard to say.  I've done the Freescale MPC8360EMDS eval board, 
>> which is a whole different animal than an AmigaOneG3SE (and I don't know 
>> exactly what an AmigaOneG3SE is).
> Sorry! My fault. Well, the AmigaOne is a ATX motherboard with a G3/G4 PPC
> CPU, a common VIA 82C686B southbridge (with an i8259 interrupt controller,
> IDE, USB, etc.), an onboard ethernet controller and a number of PCI/AGP
> slots.

I meant more that I couldn't give you much concrete information.  I 
still cannot since I don't know (and don't want to know ;-) the details. 
As they say, the devil is in the details. :-/  Your job, should you 
chose to accept it, is to conquer that devil.  ;-)

>> If you don't have any fixups/additions necessary for the fdt, then it
>> theoretically is "enable and it just works" but you will be blazing new
>> ground and I wouldn't bet on it being quite that simple. It never seems
>> to be. :-/
> That depends on what U-boot automatically adds to the device tree. I don't
> think that U-boot adds nodes for every ISA device found in the PCI2ISA
> bridge, right? If so, I have to do some fixups anyway, either in U-boot
> or in the Linux kernel.

Any fixups you would need to add.  Welcome to the bleeding edge.

There are two ways to go: if there is sufficient stable (constant) 
information, you can build a static tree.  If you (linux) needs 
information from the tree that isn't static, you (u-boot) will have to 
add/fix properties with those values.  If linux can probe for the 
values, you should be OK without having them in the tree.

On the eval boards, this is the case with clocks, for instance.  There 
are jumpers and/or hardware config words that set frequencies that get 
communicated to the linux kernel via the fdt.  The linux kernel cannot 
probe (or would be nasty to probe) for these values, so they get added 
and/or updated in the fdt.

Be aware, I don't know much about the ISA stuff, how it is set up, 
configured, probed, etc. so the above could be a bunch of BS.

>> If you look at my page FDT page, you will see a table of known 
>> conversions, most of which have not happened yet (only the MPC8360 
>> family has been worked on).
>>    <http://www.denx.de/wiki/UBoot/UBootFdtInfo#adapt>
> Thanks! I was searching through the U-boot documentation on www.denx.de,
> but didn't find anything about Fdt yet.

More bleeding. :-/

>> There are three areas that fix up fdt entries: board setup, CPU setup, 
>> and PCI setup.  These do fixups on things like ethernet MAC addresses 
>> (set them from the env variables) and clock frequencies.  I would guess 
>> that your AmigaOneG3SE won't need these fixed up, with the possible 
>> exception of the MAC addresses.  The current boards that have fixups 
>> have different boards and/or configurations that can run with different 
>> PCI and CPU clock frequencies, for instance, so the fdt property has to 
>> be fixed up with the correct frequency for the given configuration.
> Looks like the AmigaOne U-boot code has to do a lot fixups (for different
> CPU frequencies, resource fixups for invisible PCI I/O bars, ISA devices,
> etc.).

Sounds like a big ouch.  My 2c is to make as much static in the fdt as 
possible.

>> FWIIW, I'm coming out of my busy cycle of the month (first 2+ weeks) and 
>> am getting ready to update the u-boot-fdt fork with respins of some of 
>> the existing patches and some improvements (primarily addressing Kim's 
>> concerns).  I hope to get this published and pushed to the u-boot-fdt 
>> repo this week, probably spilling into next week.
> BTW: As far as I understand there are two implementations for flattened
> device trees in U-boot.

Yes, CONFIG_OF_FLAT_TREE is the original fdt implementation that I'm 
working on supplanting with a more elaborate implementation (including 
the "fdt" command) based on libfdt which is controlled via CONFIG_OF_LIBFDT.

> Is libfdt compatible with operating systems that expect only the old
> bd_t stucture? AFAIK the other implementation is deprecated, but can
> be switched off by setting an environment variable.

The bd_t structure is tacked onto the end of the fdt blob (strictly 
speaking, the fdt blob is put in front of the bd_t structure).  This is 
done in the cmd_bootm.c code.

In addition, if you enable CONFIG_OF_HAS_BD_T, the bd_t structure gets 
recreated as a blob node with properties.

I don't know how well the above work, I presume as well as before.  I 
inherited it and did not change it in my LIBFDT modifications.

>> Good luck,
> Thanks!
> 
> Gerhard

gvb