Run-time configuration of U-Boot via a flat device tree (fdt)

This adds a device tree pointer to the global data. It can be set by board code. A later commit will add support for embedding it in U-Boot.

Signed-off-by Simon Glass <[email protected]>

---
 README                             |   11 +++++++++++
 arch/arm/include/asm/global_data.h |    1 +
 2 files changed, 12 insertions(+), 0 deletions(-)

Quoted 9 lines · Simon Glass

This adds a device tree pointer to the global data. It can be set by board code. A later commit will add support for embedding it in U-Boot.

Signed-off-by Simon Glass <[email protected]>

---
?README ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 11 +++++++++++ ?arch/arm/include/asm/global_data.h | ? ?1 + ?2 files changed, 12 insertions(+), 0 deletions(-)

Hi,

do you actually intend to introduce some kind of a driver model to uboot ?

Hi Merek,

Quoted 10 lines · Marek Vasut

Quoted 8 lines · Simon Glass

This adds a device tree pointer to the global data. It can be set by board code. A later commit will add support for embedding it in U-Boot.

Signed-off-by Simon Glass <[email protected]>

---
 README                             |   11 +++++++++++
 arch/arm/include/asm/global_data.h |    1 +
 2 files changed, 12 insertions(+), 0 deletions(-)

Quoted 4 lines

Hi,

do you actually intend to introduce some kind of a driver model to uboot ?

I would love to, yes. To some extent there is a bit of this already, at least for specific subsystems. Clearly the fdt would work better if we could just hand U-Boot the fdt and say 'init yourself'. It would then scan the tree and init all the drivers for all active devices.

However, we can achieve most of the aims using something along the lines of what I have proposed, where the existing call (say to nand_init()) can look up the fdt for its node, and then get the information it needs. The only really difference is the explicit hard-coded call to nand_init, rather than a general purpose routine to find a nand node and then locate a driver for it.

To some extent that way of doing things would invert the way U-Boot currently works. It would also introduce questions about dealing with multiple devices of the same type (e.g. two different i2c controllers (not just instances) or driving two displays. These sorts of things are tricky in U-Boot at the moment.

So overall I think a unified driver model is a separate problem, and one that we should discuss and perhaps move forward on separately.

Regards.
Simon

I would love to, yes. To some extent there is a bit of this already, at least for specific subsystems. Clearly the fdt would work better if we could just hand U-Boot the fdt and say 'init yourself'. It would then scan the tree and init all the drivers for all active devices.

However, we can achieve most of the aims using something along the lines of what I have proposed, where the existing call (say to nand_init()) can look up the fdt for its node, and then get the information it needs. The only really difference is the explicit hard-coded call to nand_init, rather than a general purpose routine to find a nand node and then locate a driver for it.

To some extent that way of doing things would invert the way U-Boot currently works. It would also introduce questions about dealing with multiple devices of the same type (e.g. two different i2c controllers (not just instances) or driving two displays. These sorts of things are tricky in U-Boot at the moment.

So overall I think a unified driver model is a separate problem, and one that we should discuss and perhaps move forward on separately.

Dear Simon Glass,

Quoted 5 lines · In message <CAPnjgZ3kZJoAGJFkPkxQp+-jnztYECUaEtLZ0nvgzV1f-xUQgQ@mail.gmail.com>…

I would love to, yes. To some extent there is a bit of this already, at least for specific subsystems. Clearly the fdt would work better if we could just hand U-Boot the fdt and say 'init yourself'. It would then scan the tree and init all the drivers for all active devices.

No, it would definitely not do that.

U-Boot shall not initialize all possible available devices, but always only those that it needs itself to perform it's task, which usually is just to load and start an OS. ?It makes no sense to initialize all network interfaces (and eventually wait for the link to come up), to initialize all attached disk drives (and wait for them to spin up) or to scan the whole USB bus and initialize all attached devices when we don't need any of these to boot the OS.

Suchinitializations shall always be done on demand only, i. e. when a command is run that accesses any such device.

Quoted 7 lines

However, we can achieve most of the aims using something along the lines of what I have proposed, where the existing call (say to nand_init()) can look up the fdt for its node, and then get the information it needs. The only really difference is the explicit hard-coded call to nand_init, rather than a general purpose routine to find a nand node and then locate a driver for it.

I can;t parse that. ?Why cannot nand_init() do exactly what you suggest, i. e. find a nand node and then locate a driver for it? OK, by then it will probably be something like driver_init("nand") or the like, but that's just a detail.

Quoted 6 lines

To some extent that way of doing things would invert the way U-Boot currently works. It would also introduce questions about dealing with multiple devices of the same type (e.g. two different i2c controllers (not just instances) or driving two displays. These sorts of things are tricky in U-Boot at the moment.

Keep in mind that devices are always accessedonly on demand, so you will have the needed information which device needs to be opened.

Quoted 3 lines

So overall I think a unified driver model is a separate problem, and one that we should discuss and perhaps move forward on separately.

Agreed.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de If you want strict real-time behavior, run in the real ?time ?schedu- ling class. ?But there are no seatbelts or airbags; ?main(){for(;;);} can hard hang your system. ? ? ? ? ? ? ? ? ? ? ? ? ?-- Bart Smaalders

Quoted 9 lines

U-Boot shall not initialize all possible available devices, but always only those that it needs itself to perform it's task, which usually is just to load and start an OS. =A0It makes no sense to initialize all network interfaces (and eventually wait for the link to come up), to initialize all attached disk drives (and wait for them to spin up) or to scan the whole USB bus and initialize all attached devices when we don't need any of these to boot the OS.

Quoted 2 lines

Suchinitializations shall always be done on demand only, i. e. when a command is run that accesses any such device.

Yes thanks for pointing that out. I am really thinking of the init sequence in board_init_r() where we init NAND, MMC and the like. So

On the other hand I think serial could benefit from a unified driver model quite nicely :-)

OK good. There seem to be a lot of different activities going on, as Graeme says in the other thread.

Dear Simon,

Quoted 9 lines · In message <CAPnjgZ1y+i0FdawcbBuOi0+SC+Xq3AS=ZZtTi1tVjv8CcNw6Og@mail.gmail.com>…

Quoted 9 lines

U-Boot shall not initialize all possible available devices, but always only those that it needs itself to perform it's task, which usually is just to load and start an OS. =A0It makes no sense to initialize all network interfaces (and eventually wait for the link to come up), to initialize all attached disk drives (and wait for them to spin up) or to scan the whole USB bus and initialize all attached devices when we don't need any of these to boot the OS.

Quoted 5 lines

Quoted 2 lines

Suchinitializations shall always be done on demand only, i. e. when a command is run that accesses any such device.

Yes thanks for pointing that out. I am really thinking of the init sequence in board_init_r() where we init NAND, MMC and the like. So

I'm thinking of that, too. ?This list initializes a lot of things it actually should not. ?When this code got written, we had only a few boards, an all init steps took just a few milliseconds, so it appeared a good idea to print a "complete" system status at boot - always.

Now we don't consider this approach practical any more, especially when targetting for short boot times.

When introducing a device model, one of the tasks will be to change this part, too.

Quoted 3 lines

On the other hand I think serial could benefit from a unified driver model quite nicely :-)

Agreed, and not only serial.

Quoted 3 lines

OK good. There seem to be a lot of different activities going on, as Graeme says in the other thread.

Indeed. ?I'm actually amazed how many different things suddenly start moving :-)

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de There are no data that cannot be plotted on a straight ?line ?if ?the axis are chosen correctly.

Oh OK, well that's actually quite good then. For one thing it means that the idea of init order is perhaps not so critical, since we actually want to remove most of this mandatory init. I mean that if we are not trying to replicate the init sequence in board_init_r (but in fact remove most of it) then things are simpler, and perhaps even fall back to a call to the board code and not much else.

arch/arm/include/asm/global_data.h

Quoted 4 lines · On Monday, September 12, 2011 18:04:22 Simon Glass wrote:

arch/arm/include/asm/global_data.h +1 -0

 
+ ? ? const void ? ? ?*blob; ? ? ? ? ?/* Our device tree, NULL if none */

still "blob" and not "fdt_blob" ? ?one man's blob is another man's blub ;) -mike

This device tree is for U-Boot's own use and is not necessarily the same one as is passed to the kernel.

Quoted 2 lines · Simon Glass

This device tree is for U-Boot's own use and is not necessarily the same one as is passed to the kernel.

Are there plans to keepup with being able to use a kernel generated fdt? eg effectively ignoring things we don't care about like sound cards and wifi?

I can see definite advantages for manufacturers to be able to roll one kernel and one bootloader across a product line, then one fdt per model. It almost makes this whole mess make sense. :-) ?The kirkwood SoC would be a good example.

Do you have a git tree up that I could base off of? ?git.chromium.org's version of u-boot doesn't seem to have your code...

thx,

Jason.

Quoted 2 lines · Jason

Do you have a git tree up that I could base off of? ?git.chromium.org's version of u-boot doesn't seem to have your code...

You probably need to look at a branch:

http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=shortlog;h=refs/heads/chromeos-v2011.06

This is based on U-Boot 2011.06.

Quoted 6 lines · Simon Glass

Quoted 2 lines · Jason

Do you have a git tree up that I could base off of? ?git.chromium.org's version of u-boot doesn't seem to have your code...

You probably need to look at a branch:

Quoted 3 lines

http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=shortlog;h=refs/heads/chromeos-v2011.06

This is based on U-Boot 2011.06.

Added the remote, thanks. ?Once we figure out the mach-types thing, I'll try using the Marvell integrated RTC driver as a real-world example of a conversion to fdt. ?I'll probably have questions ;-)

thx,

Jason.

Hi Jason,

Quoted 11 lines · Jason

Quoted 9 lines · Simon Glass

Quoted 2 lines · Jason

Do you have a git tree up that I could base off of? ?git.chromium.org's version of u-boot doesn't seem to have your code...

You probably need to look at a branch:

http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=shortlog;h=refs/heads/chromeos-v2011.06

This is based on U-Boot 2011.06.

Quoted 3 lines

Added the remote, thanks. ?Once we figure out the mach-types thing, I'll try using the Marvell integrated RTC driver as a real-world example of a conversion to fdt. ?I'll probably have questions ;-)

That sounds great. I've tried to make it fair straightforward - with an option for building an fdt into U-Boot itself (i.e. don't define CONFIG_OF_SEPARATE). This should allow you to use your current dev flow.

Simon,

Quoted 18 lines · Simon Glass

Hi Jason,

Quoted 14 lines · Jason

Quoted 9 lines · Simon Glass

Quoted 2 lines · Jason

Do you have a git tree up that I could base off of? ?git.chromium.org's version of u-boot doesn't seem to have your code...

You probably need to look at a branch:

http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=shortlog;h=refs/heads/chromeos-v2011.06

This is based on U-Boot 2011.06.

Added the remote, thanks. ?Once we figure out the mach-types thing, I'll try using the Marvell integrated RTC driver as a real-world example of a conversion to fdt. ?I'll probably have questions ;-)

Quoted 4 lines

That sounds great. I've tried to make it fair straightforward - with an option for building an fdt into U-Boot itself (i.e. don't define CONFIG_OF_SEPARATE). This should allow you to use your current dev flow.

Okay, I have an initial version that compiles, but doesn't work. ?Which, surprisingly, is progress. ?;-) ?I'll post the patch a little bit later after I make sure I'm not missing something dumb.

I'll also post some comments to your patch series in a moment.

thx,

Jason.

Quoted 6 lines · Jason

Quoted 5 lines · Simon Glass

Quoted 3 lines · Jason

Added the remote, thanks. ?Once we figure out the mach-types thing, I'll try using the Marvell integrated RTC driver as a real-world example of a conversion to fdt. ?I'll probably have questions ;-)

Quoted 8 lines

Quoted 4 lines

That sounds great. I've tried to make it fair straightforward - with an option for building an fdt into U-Boot itself (i.e. don't define CONFIG_OF_SEPARATE). This should allow you to use your current dev flow.

Okay, I have an initial version that compiles, but doesn't work. ?Which, surprisingly, is progress. ?;-) ?I'll post the patch a little bit later after I make sure I'm not missing something dumb.

A few hints:

- define CONFIG_OF_EMBED to start with, since it will embed the fdt inside U-Boot which is a good check that all is well. You can move to the more useful CONFIG_OF_SEPARATE when you get that working
- there is a check in board.c that the fdt is accessible - if it is dying early then it might be that (early board panic patch is still in flight)

Simon,

Quoted 16 lines · Simon Glass

Quoted 6 lines · Jason

Quoted 5 lines · Simon Glass

Quoted 3 lines · Jason

Added the remote, thanks. ?Once we figure out the mach-types thing, I'll try using the Marvell integrated RTC driver as a real-world example of a conversion to fdt. ?I'll probably have questions ;-)

Quoted 8 lines

Quoted 4 lines

That sounds great. I've tried to make it fair straightforward - with an option for building an fdt into U-Boot itself (i.e. don't define CONFIG_OF_SEPARATE). This should allow you to use your current dev flow.

Okay, I have an initial version that compiles, but doesn't work. ?Which, surprisingly, is progress. ?;-) ?I'll post the patch a little bit later after I make sure I'm not missing something dumb.

Quoted 8 lines

A few hints:

- define CONFIG_OF_EMBED to start with, since it will embed the fdt inside U-Boot which is a good check that all is well. You can move to the more useful CONFIG_OF_SEPARATE when you get that working
- there is a check in board.c that the fdt is accessible - if it is dying early then it might be that (early board panic patch is still in flight)

Frustrating morning. ?Mainly due to the fact that I've been working with device trees all of two days.

Here's what I did:
1.) applied your patches against v2011.09-rc1 (to get mvrtc.c) 2.) applied my dreamplug support patch
3.) modified drivers/rtc/mvrtc.c for OF support
4.) compile
5.) run, then 'date' fails like so:

find_alias_node: rtc0
fdt_decode_next_alias failed.
Error decoding fdt for mvrtc.
## Get date failed

Obviously, I've hacked it up abit to get more error reporting out. Here's my kirkwood-dreamplug.dts:

##### kirkwood-dreamplug.dts ####
/dts-v1/;

/include/ "kirkwood.dtsi"

/ {
? ? ? ?model = "Marvell Dreamplug";
? ? ? ?compatible = "marvell,dreamplug", "marvell,kirkwood";

? ? ? ?rtc at 0xf1010300 {
? ? ? ? ? ? ? ?status = "ok";
? ? ? ?};
};
#################################

And the kirkwood.dtsi

#### kirkwood.dtsi ####
/ {
? ? ? ?model = "Marvell Kirkwood";
? ? ? ?compatible = "marvell,kirkwood";
? ? ? ?#address-cells = <1>;
? ? ? ?#size-cells = <1>;

? ? ? ?cpus {
? ? ? ? ? ? ? ?#address-cells = <1>;
? ? ? ? ? ? ? ?#size-cells = <0>;
? ? ? ? ? ? ? ?cpu at 0 {
? ? ? ? ? ? ? ? ? ? ? ?compatible = "arm,arm926ejs"; ? ? ? ? ? ? ? ? ? ? ? ?reg = <0>;
? ? ? ? ? ? ? ?};
? ? ? ?};

? ? ? ?rtc at 0xf1010300 {
? ? ? ? ? ? ? ?compatible = "marvell,kirkwood-rtc"; ? ? ? ? ? ? ? ?reg = <0xf1010300 0x02>;
? ? ? ? ? ? ? ?status = "disabled";
? ? ? ?};
};
#######################

I'd like to make sure my dts files are correct before I get to debugging code. ;-)

A few notes:

If I compile with '#define DEBUG' in my board config, it builds, but doesn't run, or at least, there's no output on the serial port.

I had the remove your fdt_decode_i2c() and clock.h include. ?The clock.h include seems to be specific to the tegra2 and doesn't exist for kirkwood.

thx,

Jason.

Quoted 36 lines · Jason

Quoted 16 lines · Simon Glass

Quoted 6 lines · Jason

Quoted 5 lines · Simon Glass

Quoted 3 lines · Jason

Added the remote, thanks. ?Once we figure out the mach-types thing, I'll try using the Marvell integrated RTC driver as a real-world example of a conversion to fdt. ?I'll probably have questions ;-)

Quoted 8 lines

Quoted 4 lines

That sounds great. I've tried to make it fair straightforward - with an option for building an fdt into U-Boot itself (i.e. don't define CONFIG_OF_SEPARATE). This should allow you to use your current dev flow.

Okay, I have an initial version that compiles, but doesn't work. ?Which, surprisingly, is progress. ?;-) ?I'll post the patch a little bit later after I make sure I'm not missing something dumb.

Quoted 8 lines

A few hints:

- define CONFIG_OF_EMBED to start with, since it will embed the fdt inside U-Boot which is a good check that all is well. You can move to the more useful CONFIG_OF_SEPARATE when you get that working
- there is a check in board.c that the fdt is accessible - if it is dying early then it might be that (early board panic patch is still in flight)

Frustrating morning. ?Mainly due to the fact that I've been working with device trees all of two days.

Here's what I did:
1.) applied your patches against v2011.09-rc1 (to get mvrtc.c) 2.) applied my dreamplug support patch
3.) modified drivers/rtc/mvrtc.c for OF support
4.) compile
5.) run, then 'date' fails like so:

Quoted 4 lines

find_alias_node: rtc0
fdt_decode_next_alias failed.
Error decoding fdt for mvrtc.
## Get date failed

I don't actually see an alias in your fdt. And actually I left it out of mine, so that is understandable. For i2c I have:

...

	aliases {
		i2c0 = "/i2c at 0x7000d000";
		i2c1 = "/i2c at 0x7000c000";
		i2c2 = "/i2c at 0x7000c400";
		i2c3 = "/i2c at 0x7000c500";
	};

So I think you need to add a /alias node and try again. I can submit a new patch set with this and a couple of other things I want to change, but it would be good if you can get to the end first, in case you find other problems.

Quoted 48 lines

Obviously, I've hacked it up abit to get more error reporting out. Here's my kirkwood-dreamplug.dts:

##### kirkwood-dreamplug.dts ####
/dts-v1/;

/include/ "kirkwood.dtsi"

/ {
? ? ? ?model = "Marvell Dreamplug";
? ? ? ?compatible = "marvell,dreamplug", "marvell,kirkwood";

? ? ? ?rtc at 0xf1010300 {
? ? ? ? ? ? ? ?status = "ok";
? ? ? ?};
};
#################################

And the kirkwood.dtsi

#### kirkwood.dtsi ####
/ {
? ? ? ?model = "Marvell Kirkwood";
? ? ? ?compatible = "marvell,kirkwood";
? ? ? ?#address-cells = <1>;
? ? ? ?#size-cells = <1>;

? ? ? ?cpus {
? ? ? ? ? ? ? ?#address-cells = <1>;
? ? ? ? ? ? ? ?#size-cells = <0>;
? ? ? ? ? ? ? ?cpu at 0 {
? ? ? ? ? ? ? ? ? ? ? ?compatible = "arm,arm926ejs"; ? ? ? ? ? ? ? ? ? ? ? ?reg = <0>;
? ? ? ? ? ? ? ?};
? ? ? ?};

? ? ? ?rtc at 0xf1010300 {
? ? ? ? ? ? ? ?compatible = "marvell,kirkwood-rtc"; ? ? ? ? ? ? ? ?reg = <0xf1010300 0x02>;
? ? ? ? ? ? ? ?status = "disabled";
? ? ? ?};
};
#######################

I'd like to make sure my dts files are correct before I get to debugging code. ;-)

Quoted 4 lines

A few notes:

If I compile with '#define DEBUG' in my board config, it builds, but doesn't run, or at least, there's no output on the serial port.

That's because you are getting output prior to relocation. Graeme has a patch for that, and I also sent a patch for pre-console panic (which I will update once his patch goes in).

Quoted 3 lines

I had the remove your fdt_decode_i2c() and clock.h include. ?The clock.h include seems to be specific to the tegra2 and doesn't exist for kirkwood.

Yes that's right, it is just an example at this stage, and the idea of a periph_id is specific to Tegra at present. Patches 5 and 6 are just an example to show how to use it in code.

Simon,

On Wed, Sep 14, 2011 at 10:45:59AM -0700, Simon Glass wrote:

Quoted 10 lines

Quoted 6 lines

5.) run, then 'date' fails like so:

find_alias_node: rtc0
fdt_decode_next_alias failed.
Error decoding fdt for mvrtc.
## Get date failed

I don't actually see an alias in your fdt. And actually I left it out of mine, so that is understandable. For i2c I have:

Quoted 7 lines

...
? ? ? aliases {
? ? ? ? ? ? ? i2c0 = "/i2c at 0x7000d000";
? ? ? ? ? ? ? i2c1 = "/i2c at 0x7000c000";
? ? ? ? ? ? ? i2c2 = "/i2c at 0x7000c400";
? ? ? ? ? ? ? i2c3 = "/i2c at 0x7000c500";
? ? ? };

That worked!

Marvell>> date
find_alias_node: rtc0
Date: 2011-09-14 (Wednesday) ? ?Time: 14:04:54
Marvell>>

Quoted 4 lines

So I think you need to add a /alias node and try again. I can submit a new patch set with this and a couple of other things I want to change, but it would be good if you can get to the end first, in case you find other problems.

I'll clean up what I have and post it RFC.

Quoted 7 lines

Quoted 3 lines

I had the remove your fdt_decode_i2c() and clock.h include. ?The clock.h include seems to be specific to the tegra2 and doesn't exist for kirkwood.

Yes that's right, it is just an example at this stage, and the idea of a periph_id is specific to Tegra at present. Patches 5 and 6 are just an example to show how to use it in code.

Ok, I'll drop those from my branch to make a cleaner example.

thx,

Jason.

Quoted 1 line · Jason

On Wed, Sep 14, 2011 at 10:45:59AM -0700, Simon Glass wrote:

[snip]

Quoted 18 lines

Quoted 10 lines

Quoted 6 lines

5.) run, then 'date' fails like so:

find_alias_node: rtc0
fdt_decode_next_alias failed.
Error decoding fdt for mvrtc.
## Get date failed

I don't actually see an alias in your fdt. And actually I left it out of mine, so that is understandable. For i2c I have:

Quoted 7 lines

...
? ? ? aliases {
? ? ? ? ? ? ? i2c0 = "/i2c at 0x7000d000";
? ? ? ? ? ? ? i2c1 = "/i2c at 0x7000c000";
? ? ? ? ? ? ? i2c2 = "/i2c at 0x7000c400";
? ? ? ? ? ? ? i2c3 = "/i2c at 0x7000c500";
? ? ? };

Quoted 7 lines

That worked!

Marvell>> date
find_alias_node: rtc0
Date: 2011-09-14 (Wednesday) ? ?Time: 14:04:54
Marvell>>

Great!

Quoted 6 lines

Quoted 4 lines

So I think you need to add a /alias node and try again. I can submit a new patch set with this and a couple of other things I want to change, but it would be good if you can get to the end first, in case you find other problems.

I'll clean up what I have and post it RFC.

OK good

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

I had the remove your fdt_decode_i2c() and clock.h include. ?The clock.h include seems to be specific to the tegra2 and doesn't exist for kirkwood.

Yes that's right, it is just an example at this stage, and the idea of a periph_id is specific to Tegra at present. Patches 5 and 6 are just an example to show how to use it in code.

Quoted 1 line

Ok, I'll drop those from my branch to make a cleaner example.

Yes, ideally I would like to keep SOC-specific things out of it at this stage, but I was asked for an example and had to choose something! My hope is that we can have the base patch and then a couple of architecture patches.

Quoted 49 lines · Simon Glass

Quoted 1 line · Jason

On Wed, Sep 14, 2011 at 10:45:59AM -0700, Simon Glass wrote:

[snip]

Quoted 18 lines

Quoted 10 lines

Quoted 6 lines

5.) run, then 'date' fails like so:

find_alias_node: rtc0
fdt_decode_next_alias failed.
Error decoding fdt for mvrtc.
## Get date failed

I don't actually see an alias in your fdt. And actually I left it out of mine, so that is understandable. For i2c I have:

Quoted 7 lines

...
? ? ? aliases {
? ? ? ? ? ? ? i2c0 = "/i2c at 0x7000d000";
? ? ? ? ? ? ? i2c1 = "/i2c at 0x7000c000";
? ? ? ? ? ? ? i2c2 = "/i2c at 0x7000c400";
? ? ? ? ? ? ? i2c3 = "/i2c at 0x7000c500";
? ? ? };

Quoted 7 lines

That worked!

Marvell>> date
find_alias_node: rtc0
Date: 2011-09-14 (Wednesday) ? ?Time: 14:04:54
Marvell>>

Great!

Quoted 6 lines

Quoted 4 lines

So I think you need to add a /alias node and try again. I can submit a new patch set with this and a couple of other things I want to change, but it would be good if you can get to the end first, in case you find other problems.

I'll clean up what I have and post it RFC.

OK good

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

I had the remove your fdt_decode_i2c() and clock.h include. ?The clock.h include seems to be specific to the tegra2 and doesn't exist for kirkwood.

Yes that's right, it is just an example at this stage, and the idea of a periph_id is specific to Tegra at present. Patches 5 and 6 are just an example to show how to use it in code.

Quoted 6 lines

Quoted 1 line

Ok, I'll drop those from my branch to make a cleaner example.

Yes, ideally I would like to keep SOC-specific things out of it at this stage, but I was asked for an example and had to choose something! My hope is that we can have the base patch and then a couple of architecture patches.

Yes, I don't like putting fdt_decode_i2c() or fdt_decode_rtc() in common/fdt_decode.c ... ?The current implementation of fdt...i2c() is arch specific, and fdt...rtc() I know will only work for the simple integrated rtc with two registers.

Let me rework it to the appropriate place and then I'll post. ?I'll also remove the fdt...i2c().

thx,

Jason.

Quoted 1 line · Jason

On Wed, Sep 14, 2011 at 01:05:58PM -0700, Simon Glass wrote:

Quoted 9 lines

Quoted 4 lines

Yes, ideally I would like to keep SOC-specific things out of it at this stage, but I was asked for an example and had to choose something! My hope is that we can have the base patch and then a couple of architecture patches.

Yes, I don't like putting fdt_decode_i2c() or fdt_decode_rtc() in common/fdt_decode.c ... ?The current implementation of fdt...i2c() is arch specific, and fdt...rtc() I know will only work for the simple integrated rtc with two registers.

This is one of the things to resolve. I think we need an fdt_decode to lighten the load of finding aliases, decoding addresses and the like, but a bigger question is whether we want the various i2c drivers to share decode logic. It will help make the drivers more similar, but clearly means that they have to follow the lowest common denominator. This is a bit like CONFIG_ works at present - and we are replacing the CONFIG_ items. For i2c the configs might be CONFIG_SYS_I2C_SPEED and the controller address (and maybe CONFIG_SYS_I2C_SLAVE). But we don't deal with particular i2c config like pinmux settings etc. which are not common across a lot of boards. So fdt_decode would deal with these few common settings and leave specific drivers to do the rest.

But if people are happy with the idea of fdt decode code bleeding more into each driver, then fdt_decode just becomes a low-level helper library, and does not have specific functions for decoding an i2c node, a uart, etc.

That is perhaps more pure - my main concerns with
this are uptake (too hard to swtich a board over to fdt) and consistency (everyone will use their own way of doing the same thing - and we have enough of that in U-Boot already :-)

This new option allows U-Boot to embed a binary device tree into its image to allow run-time control of peripherals. This device tree is for U-Boot's own use and is not necessarily the same one as is passed to the kernel.

The device tree compiler output should be placed in the $(obj) rooted tree. Since $(OBJCOPY) insists on adding the path to the generated symbol names, to ensure consistency it should be invoked from the directory where the .dtb file is located and given the input file name without the path.

This commit contains my entry for the ugliest Makefile / shell interaction competition.

Signed-off-by Simon Glass <[email protected]>

---
 Makefile         |    4 ++
 README           |   11 +++++-
 config.mk        |    1 +
 dts/Makefile     |  100 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/common.h |    1 +
 5 files changed, 115 insertions(+), 2 deletions(-)
 create mode 100644 dts/Makefile

Makefile +4 -0

index d5a1f0a..658a622 100644
@@ -224,6 +224,9 @@ endif
 ifeq ($(CPU),ixp)
 LIBS += arch/arm/cpu/ixp/npe/libnpe.o
 endif
+ifeq ($(CONFIG_OF_EMBED),y)
+LIBS += dts/libdts.o
+endif
 LIBS += arch/$(ARCH)/lib/lib$(ARCH).o
 LIBS += fs/cramfs/libcramfs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o \
 	fs/reiserfs/libreiserfs.o fs/ext2/libext2fs.o fs/yaffs2/libyaffs2.o \

@@ -962,6 +965,7 @@ clobber:	clean
 	@rm -f $(obj)u-boot.kwb
 	@rm -f $(obj)u-boot.imx
 	@rm -f $(obj)u-boot.ubl
+	@rm -f $(obj)u-boot.dtb
 	@rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
 	@rm -f $(obj)arch/powerpc/cpu/mpc824x/bedbug_603e.c
 	@rm -fr $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm

README +9 -2

index 812805f..5a2f060 100644
@@ -803,8 +803,15 @@ The following options need to be configured:
 		experimental and only available on a few boards. The device
 		tree is available in the global data as gd->blob.
 
-		U-Boot needs to get its device tree from somewhere. This will
-		be enabled in a future patch.
+		U-Boot needs to get its device tree from somewhere. At present
+		the only way is to embed it in the image with CONFIG_OF_EMBED.
+
+		CONFIG_OF_EMBED
+		If this variable is defined, U-Boot will embed a device tree
+		binary in its image. This device tree file should be in the
+		board directory and called <soc>-<board>.dts. The binary file
+		is then picked up in board_init_f() and made available through
+		the global data structure as gd->blob.
 
 - Watchdog:
 		CONFIG_WATCHDOG

config.mk +1 -0

index e2b440d..6e61eb6 100644
@@ -124,6 +124,7 @@ STRIP	= $(CROSS_COMPILE)strip
 OBJCOPY = $(CROSS_COMPILE)objcopy
 OBJDUMP = $(CROSS_COMPILE)objdump
 RANLIB	= $(CROSS_COMPILE)RANLIB
+DTC	= dtc
 
 #########################################################################
 

dts/Makefile new file +42 -0

new file mode 100644
index 0000000..e70a16b
@@ -0,0 +1,100 @@
+#
+# Copyright (c) 2011 The Chromium OS Authors.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundatio; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+# This Makefile builds the internal U-Boot fdt if CONFIG_OF_CONTROL is
+# enabled. See doc/README.fdt-control for more details.
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)libdts.o
+
+$(if $(CONFIG_DEFAULT_DEVICE_TREE),,\
+$(error Please define CONFIG_DEFAULT_DEVICE_TREE in your board header file))
+DEVICE_TREE = $(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE))
+
+all:	$(obj).depend $(LIB)
+
+# Use a constant name for this so we can access it from C code.
+# objcopy doesn't seem to allow us to set the symbol name independently of
+# the filename.
+DT_BIN	:= $(obj)dt.dtb
+
+$(DT_BIN): $(TOPDIR)/board/$(BOARDDIR)/$(DEVICE_TREE).dts
+	$(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $<

dts/Makefile new file +12 -0

+	# We look in the LDSCRIPT first.
+	# Then try the linker which should give us the answer.
+	# Then check it worked.
+	oformat=`$(call process_lds,cat $(LDSCRIPT),FORMAT)` ;\
+	oarch=`$(call process_lds,cat $(LDSCRIPT),ARCH)` ;\
+	\
+	[ -z $${oformat} ] && \
+		oformat=`$(call process_lds,$(GET_LDS),FORMAT)` ;\
+	[ -z $${oarch} ] && \
+		oarch=`$(call process_lds,$(GET_LDS),ARCH)` ;\
+	\
+	[ -z $${oformat} ] && \

dts/Makefile new file +26 -0

+
+OBJS-$(CONFIG_OF_EMBED)	:= dt.o
+
+COBJS	:= $(OBJS-y)
+
+OBJS	:= $(addprefix $(obj),$(COBJS))
+
+binary:	$(DT_BIN)
+
+$(LIB):	$(OBJS) $(DTB)
+	$(call cmd_link_o_target, $(OBJS))
+
+clean:
+	rm -f $(OBJS) $(LIB)
+	rm -f $(DT_BIN)
+
+distclean:	clean
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################

include/common.h +1 -0

index bd10f31..6cdcc50 100644
@@ -249,6 +249,7 @@ int	checkdram     (void);
 int	last_stage_init(void);
 extern ulong monitor_flash_len;
 int mac_read_from_eeprom(void);
+extern u8 _binary_dt_dtb_start[];	/* embedded device tree blob */
 
 /* common/flash.c */
 void flash_perror (int);

Signature · 1 line

1.7.3.1

Quoted 13 lines · Simon Glass

This new option allows U-Boot to embed a binary device tree into its image to allow run-time control of peripherals. This device tree is for U-Boot's own use and is not necessarily the same one as is passed to the kernel.

The device tree compiler output should be placed in the $(obj) rooted tree. Since $(OBJCOPY) insists on adding the path to the generated symbol names, to ensure consistency it should be invoked from the directory where the .dtb file is located and given the input file name without the path.

This commit contains my entry for the ugliest Makefile / shell interaction competition.

Quoted 1 line

Signed-off-by Simon Glass <[email protected]>

May I suggest an alternate approach? ?Rather than hard linking the dtb into the u-boot image, this would be so much more useful if the dtb can be concatenated to the u-boot binary so that it can be configured at install time. ?Otherwise, switching to .dtb doesn't seem to actually buy much when it still requires a recompile of u-boot to change the dtb configuration data.

The linker script would need to be modified to make sure the end of the binary image is aligned, and that there is a label indicating the beginning of the .dtb section. ?The init code will also need to read the .dtb header to get the dtb length so that it can be relocated into RAM with the rest of u-boot.

Targets could even be added as u-boot.%.bin so that a single build could spit out several variants as needed, but still produce a bare u-boot.bin binary that can have the .dtb appended manually.

Using CONFIG_OF_EMBED may actually be harmful if it starts encouraging developers to put .dts files into the u-boot tree. ?Especially when right now the plan for the kernel is to actually move .dts file out of the Linux tree and into a separate & neutral repository.

Quoted 10 lines

---

?Makefile ? ? ? ? | ? ?4 ++
?README ? ? ? ? ? | ? 11 +++++-
?config.mk ? ? ? ?| ? ?1 +
?dts/Makefile ? ? | ?100 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
?include/common.h | ? ?1 +

?5 files changed, 115 insertions(+), 2 deletions(-) ?create mode 100644 dts/Makefile

if the fdt is not in the U-Boot tree, where does it go? When will the kernel fdt be set up? That sounds very promising.

Quoted 2 lines · Simon Glass

if the fdt is not in the U-Boot tree, where does it go? When will the kernel fdt be set up? That sounds very promising.

Into a separate git tree. ?Possibly on devicetree.org, git.secretlab.ca, or git.linaro.org. ?I don't really want it on linaro or kernel.org though because I want to make it clear that it is absolutely not intended to be Linux-specific.

g.

May I suggest an alternate approach? Rather than hard linking the dtb into the u-boot image, this would be so much more useful if the dtb can be concatenated to the u-boot binary so that it can be configured at install time. Otherwise, switching to .dtb doesn't seem to

Dear Grant Likely,

Quoted 5 lines · In message <[email protected]> you wrote:

May I suggest an alternate approach? ?Rather than hard linking the dtb into the u-boot image, this would be so much more useful if the dtb can be concatenated to the u-boot binary so that it can be configured at install time. ?Otherwise, switching to .dtb doesn't seem to

Actually the DTB address should _always_ be taken from an environment variable, so we have full flexibility.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de In the beginning there was nothing.
And the Lord said "Let There Be Light!"
And still there was nothing, but at least now you could see it.

Dear Grant Likely,

Quoted 5 lines · In message <[email protected]> you wrote:

May I suggest an alternate approach? ?Rather than hard linking the dtb into the u-boot image, this would be so much more useful if the dtb can be concatenated to the u-boot binary so that it can be configured at install time. ?Otherwise, switching to .dtb doesn't seem to

Actually the DTB address should _always_ be taken from an environment variable, so we have full flexibility.

This adds support for an FDT to be build as a separate binary file called u-boot.dtb. This can be concatenated with the U-Boot binary to provide a device tree located at run-time by U-Boot.

Signed-off-by Simon Glass <[email protected]>

---
 .gitignore             |    1 +
 Makefile               |    5 ++
 README                 |   11 +++-
 doc/README.fdt-control |  168 ++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 183 insertions(+), 2 deletions(-)
 create mode 100644 doc/README.fdt-control

.gitignore +1 -0

index dbf545f..c4ebd34 100644
@@ -34,6 +34,7 @@
 /u-boot.dis
 /u-boot.lds
 /u-boot.ubl
+/u-boot.dtb
 
 #
 # Generated files

Makefile +5 -0

index 658a622..d73efa1 100644
@@ -352,9 +352,14 @@ ALL-$(CONFIG_ONENAND_U_BOOT) += $(obj)u-boot-onenand.bin
 ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
 ALL-$(CONFIG_MMC_U_BOOT) += $(obj)mmc_spl/u-boot-mmc-spl.bin
 ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin
+ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb
 
 all:		$(ALL-y)
 
+$(obj)u-boot.dtb:	$(obj)u-boot
+		$(MAKE) -C dts binary
+		mv $(obj)dts/dt.dtb $@
+
 $(obj)u-boot.hex:	$(obj)u-boot
 		$(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@
 

README +9 -2

index 5a2f060..0b8f338 100644
@@ -803,8 +803,8 @@ The following options need to be configured:
 		experimental and only available on a few boards. The device
 		tree is available in the global data as gd->blob.
 
-		U-Boot needs to get its device tree from somewhere. At present
-		the only way is to embed it in the image with CONFIG_OF_EMBED.
+		U-Boot needs to get its device tree from somewhere. This can
+		be done using one of the two options below:
 
 		CONFIG_OF_EMBED
 		If this variable is defined, U-Boot will embed a device tree

@@ -813,6 +813,13 @@ The following options need to be configured:
 		is then picked up in board_init_f() and made available through
 		the global data structure as gd->blob.
 
+		CONFIG_OF_SEPARATE
+		If this variable is defined, U-Boot will build a device tree
+		binary. It will be called u-boot.dtb. Architecture-specific
+		code will locate it at run-time. Generally this works by:
+
+			cat u-boot.bin u-boot.dtb >image.bin
+
 - Watchdog:
 		CONFIG_WATCHDOG
 		If this variable is defined, it enables watchdog

doc/README.fdt-control new file +168 -0

new file mode 100644
index 0000000..dfc8f06
@@ -0,0 +1,168 @@
+#
+# Copyright (c) 2011 The Chromium OS Authors.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundatio; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+Device Tree Control in U-Boot
+=============================
+
+This feature provides for run-time configuration of U-Boot via a flat
+device tree (fdt). U-Boot configuration has traditionally been done
+using CONFIG options in the board config file. This feature aims to
+make it possible for a single U-Boot binary to support multiple boards,
+with the exact configuration of each board controlled by a flat device
+tree (fdt). This is the approach recently taken by the ARM Linux kernel
+and has been used by PowerPC for some time.
+
+The fdt is a convenient vehicle for implementing run-time configuration
+for three reasons. Firstly it is easy to use, being a simple text file.
+It is extensible since it consists of nodes and properties in a nice
+hierarchical format.
+
+Finally, there is already excellent infrastructure for the fdt: a
+compiler checks the text file and converts it to a compact binary
+format, and a library is already available in U-Boot (libfdt) for
+handling this format.
+
+The dts directory contains a Makefile for building the device tree blob
+and embedding it in your U-Boot image. This is useful since it allows
+U-Boot to configure itself according to what it finds there. If you have
+a number of similar boards with different peripherals, you can describe
+the features of each board in the device tree file, and have a single
+generic source base.
+
+To enable this feature, add CONFIG_OF_CONTROL to your board config file.
+
+
+What is a Flat Device Tree?
+---------------------------
+
+An fdt can be specified in source format as a text file. To read about
+the fdt syntax, take a look at the specification here:
+
+https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
+
+You also might find this section of the Linux kernel documentation
+useful: (access this in the Linux kernel source code)
+
+	Documentation/devicetree/booting-without-of.txt
+
+There is also a mailing list:
+
+	http://lists.ozlabs.org/listinfo/devicetree-discuss
+
+In case you are wondering, OF stands for Open Firmware.
+
+
+Tools
+-----
+
+To use this feature you will need to get the device tree compiler here:
+
+	git://jdl.com/software/dtc.git
+
+For example:
+
+	$ git clone git://jdl.com/software/dtc.git
+	$ cd dtc
+	$ make
+	$ sudo make install
+
+Then run the compiler (your version will vary):
+
+	$ dtc -v
+	Version: DTC 1.2.0-g2cb4b51f
+	$ make tests
+	$ cd tests
+	$ ./run_tests.sh
+	********** TEST SUMMARY
+	*     Total testcases:	1371
+	*                PASS:	1371
+	*                FAIL:	0
+	*   Bad configuration:	0
+	* Strange test result:	0
+
+You will also find a useful ftdump utility for decoding a binary file.
+
+
+Where do I get an fdt file for my board?
+----------------------------------------
+
+You may find that the Linux kernel has a suitable file. Look in the
+kernel source in arch/<arch>/boot/dts.
+
+If not you might find other boards with suitable files that you can
+modify to your needs. Look in the board directories for files with a
+.dts extension.
+
+Failing that, you could write one from scratch yourself!
+
+
+Configuration
+-------------
+
+Use:
+
+#define CONFIG_DEFAULT_DEVICE_TREE	"<name>"
+
+to set the filename of the device tree source. Then put your device tree
+file into
+
+	board/<vendor>/<board>/<name>.dts
+
+If CONFIG_OF_EMBED is defined, then it will be picked up and built into
+the U-Boot image (including u-boot.bin).
+
+If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
+a u-boot.dtb file alongside u-boot.bin. A common approach is then to
+join the two:
+
+	cat u-boot.bin u-boot.dtb >image.bin
+
+and then flash image.bin onto your board.
+
+You cannot use both of these options at the same time.
+
+
+Limitations
+-----------
+
+U-Boot is designed to build with a single architecture type and CPU
+type. So for example it is not possible to build a single ARM binary
+which runs on your AT91 and OMAP boards, relying on an fdt to configure
+the various features. This is because you must select one of
+the CPU families within arch/arm/cpu/arm926ejs (omap or at91) at build
+time. Similarly you cannot build for multiple cpu types or
+architectures.
+
+That said the complexity reduction by using fdt to support variants of
+boards which use the same SOC / CPU can be substantial.
+
+It is important to understand that the fdt only selects options
+available in the platform / drivers. It cannot add new drivers (yet). So
+you must still have the CONFIG option to enable the driver. For example,
+you need to define CONFIG_SYS_NS16550 to bring in the NS16550 driver,
+but can use the fdt to specific the UART clock, peripheral address, etc.
+In very broad terms, the CONFIG options in general control *what* driver
+files are pulled in, and the fdt controls *how* those files work.
+
+--
+Simon Glass <[email protected]>
+1-Sep-11

Signature · 1 line

1.7.3.1

Quoted 3 lines · Simon Glass

This adds support for an FDT to be build as a separate binary file called u-boot.dtb. This can be concatenated with the U-Boot binary to provide a device tree located at run-time by U-Boot.

Hahaha, I should the entire thread of patches before commenting. ?I strongly feel that this should be the only method and that CONFIG_OF_EMBED should be dropped.

Quoted 248 lines

Signed-off-by Simon Glass <[email protected]>

---

?.gitignore ? ? ? ? ? ? | ? ?1 +
?Makefile ? ? ? ? ? ? ? | ? ?5 ++
?README ? ? ? ? ? ? ? ? | ? 11 +++-
?doc/README.fdt-control | ?168 ++++++++++++++++++++++++++++++++++++++++++++++++

?4 files changed, 183 insertions(+), 2 deletions(-) ?create mode 100644 doc/README.fdt-control

.gitignore +0 -0

index dbf545f..c4ebd34 100644
@@ -34,6 +34,7 @@

?/u-boot.dis
?/u-boot.lds
?/u-boot.ubl
+/u-boot.dtb

?#
?# Generated files

Makefile +0 -0

index 658a622..d73efa1 100644
@@ -352,9 +352,14 @@ ALL-$(CONFIG_ONENAND_U_BOOT) += $(obj)u-boot-onenand.bin

?ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin ?ALL-$(CONFIG_MMC_U_BOOT) += $(obj)mmc_spl/u-boot-mmc-spl.bin ?ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin +ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb

?all: ? ? ? ? $(ALL-y)

+$(obj)u-boot.dtb: ? ?$(obj)u-boot
+ ? ? ? ? ? ? $(MAKE) -C dts binary
+ ? ? ? ? ? ? mv $(obj)dts/dt.dtb $@
+
?$(obj)u-boot.hex: ? ?$(obj)u-boot
? ? ? ? ? ? ? $(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@

README +0 -0

index 5a2f060..0b8f338 100644
@@ -803,8 +803,8 @@ The following options need to be configured:

? ? ? ? ? ? ? experimental and only available on a few boards. The device ? ? ? ? ? ? ? tree is available in the global data as gd->blob.

- ? ? ? ? ? ? U-Boot needs to get its device tree from somewhere. At present
- ? ? ? ? ? ? the only way is to embed it in the image with CONFIG_OF_EMBED.
+ ? ? ? ? ? ? U-Boot needs to get its device tree from somewhere. This can
+ ? ? ? ? ? ? be done using one of the two options below:

? ? ? ? ? ? ? CONFIG_OF_EMBED
? ? ? ? ? ? ? If this variable is defined, U-Boot will embed a device tree

README +0 -0

@@ -813,6 +813,13 @@ The following options need to be configured:

? ? ? ? ? ? ? is then picked up in board_init_f() and made available through ? ? ? ? ? ? ? the global data structure as gd->blob.

+ ? ? ? ? ? ? CONFIG_OF_SEPARATE
+ ? ? ? ? ? ? If this variable is defined, U-Boot will build a device tree
+ ? ? ? ? ? ? binary. It will be called u-boot.dtb. Architecture-specific
+ ? ? ? ? ? ? code will locate it at run-time. Generally this works by:

README +3 -0

+
+ ? ? ? ? ? ? ? ? ? ? cat u-boot.bin u-boot.dtb >image.bin
+

?- Watchdog:
? ? ? ? ? ? ? CONFIG_WATCHDOG
? ? ? ? ? ? ? If this variable is defined, it enables watchdog

doc/README.fdt-control new file +168 -1

new file mode 100644
index 0000000..dfc8f06
@@ -0,0 +1,168 @@
+#
+# Copyright (c) 2011 The Chromium OS Authors.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundatio; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ? ? ? See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+Device Tree Control in U-Boot
+=============================
+
+This feature provides for run-time configuration of U-Boot via a flat
+device tree (fdt). U-Boot configuration has traditionally been done
+using CONFIG options in the board config file. This feature aims to
+make it possible for a single U-Boot binary to support multiple boards,
+with the exact configuration of each board controlled by a flat device
+tree (fdt). This is the approach recently taken by the ARM Linux kernel
+and has been used by PowerPC for some time.
+
+The fdt is a convenient vehicle for implementing run-time configuration
+for three reasons. Firstly it is easy to use, being a simple text file.
+It is extensible since it consists of nodes and properties in a nice
+hierarchical format.
+
+Finally, there is already excellent infrastructure for the fdt: a
+compiler checks the text file and converts it to a compact binary
+format, and a library is already available in U-Boot (libfdt) for
+handling this format.
+
+The dts directory contains a Makefile for building the device tree blob
+and embedding it in your U-Boot image. This is useful since it allows
+U-Boot to configure itself according to what it finds there. If you have
+a number of similar boards with different peripherals, you can describe
+the features of each board in the device tree file, and have a single
+generic source base.
+
+To enable this feature, add CONFIG_OF_CONTROL to your board config file.
+
+
+What is a Flat Device Tree?
+---------------------------
+
+An fdt can be specified in source format as a text file. To read about
+the fdt syntax, take a look at the specification here:
+
+https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
+
+You also might find this section of the Linux kernel documentation
+useful: (access this in the Linux kernel source code)
+
+ ? ? Documentation/devicetree/booting-without-of.txt
+
+There is also a mailing list:
+
+ ? ? http://lists.ozlabs.org/listinfo/devicetree-discuss
+
+In case you are wondering, OF stands for Open Firmware.
+
+
+Tools
+-----
+
+To use this feature you will need to get the device tree compiler here:
+
+ ? ? git://jdl.com/software/dtc.git
+
+For example:
+
+ ? ? $ git clone git://jdl.com/software/dtc.git
+ ? ? $ cd dtc
+ ? ? $ make
+ ? ? $ sudo make install
+
+Then run the compiler (your version will vary):
+
+ ? ? $ dtc -v
+ ? ? Version: DTC 1.2.0-g2cb4b51f
+ ? ? $ make tests
+ ? ? $ cd tests
+ ? ? $ ./run_tests.sh
+ ? ? ********** TEST SUMMARY
+ ? ? * ? ? Total testcases: ?1371
+ ? ? * ? ? ? ? ? ? ? ?PASS: ?1371
+ ? ? * ? ? ? ? ? ? ? ?FAIL: ?0
+ ? ? * ? Bad configuration: ?0
+ ? ? * Strange test result: ?0
+
+You will also find a useful ftdump utility for decoding a binary file.
+
+
+Where do I get an fdt file for my board?
+----------------------------------------
+
+You may find that the Linux kernel has a suitable file. Look in the
+kernel source in arch/<arch>/boot/dts.
+
+If not you might find other boards with suitable files that you can
+modify to your needs. Look in the board directories for files with a
+.dts extension.
+
+Failing that, you could write one from scratch yourself!
+
+
+Configuration
+-------------
+
+Use:
+
+#define CONFIG_DEFAULT_DEVICE_TREE ? "<name>"
+
+to set the filename of the device tree source. Then put your device tree
+file into
+
+ ? ? board/<vendor>/<board>/<name>.dts
+
+If CONFIG_OF_EMBED is defined, then it will be picked up and built into
+the U-Boot image (including u-boot.bin).
+
+If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
+a u-boot.dtb file alongside u-boot.bin. A common approach is then to
+join the two:
+
+ ? ? cat u-boot.bin u-boot.dtb >image.bin
+
+and then flash image.bin onto your board.
+
+You cannot use both of these options at the same time.
+
+
+Limitations
+-----------
+
+U-Boot is designed to build with a single architecture type and CPU
+type. So for example it is not possible to build a single ARM binary
+which runs on your AT91 and OMAP boards, relying on an fdt to configure
+the various features. This is because you must select one of
+the CPU families within arch/arm/cpu/arm926ejs (omap or at91) at build
+time. Similarly you cannot build for multiple cpu types or
+architectures.
+
+That said the complexity reduction by using fdt to support variants of
+boards which use the same SOC / CPU can be substantial.
+
+It is important to understand that the fdt only selects options
+available in the platform / drivers. It cannot add new drivers (yet). So
+you must still have the CONFIG option to enable the driver. For example,
+you need to define CONFIG_SYS_NS16550 to bring in the NS16550 driver,
+but can use the fdt to specific the UART clock, peripheral address, etc.
+In very broad terms, the CONFIG options in general control *what* driver
+files are pulled in, and the fdt controls *how* those files work.
+
+--
+Simon Glass <[email protected]>
+1-Sep-11
--

1.7.3.1

At present in U-Boot configuration is mostly done using CONFIG options in the board file. This patch set aims to make it possible for a single U-Boot binary to support multiple boards, with the exact configuration of each board controlled by a flat device tree (fdt). This is the approach recently taken by the ARM Linux kernel and has been used by PowerPC for some time.

The fdt is a convenient vehicle for implementing run-time configuration for three reasons. Firstly it is easy to use, being a simple text file. It is extensible since it consists of nodes and properties in a nice hierarchical format.

?arch/arm/include/asm/global_data.h ? ? ? ?| ? ?1 + ?arch/arm/lib/board.c ? ? ? ? ? ? ? ? ? ? ?| ? 22 ++++

Signed-off-by Jason Cooper <[email protected]>

---

common/fdt_decode.c  |   14 --------------
include/fdt_decode.h |   32 --------------------------------
2 files changed, 0 insertions(+), 46 deletions(-)

Quoted 6 lines · Jason Cooper

Signed-off-by Jason Cooper <[email protected]>

---

common/fdt_decode.c  |   14 --------------
include/fdt_decode.h |   32 --------------------------------
2 files changed, 0 insertions(+), 46 deletions(-)

Did I miss where these files were added to u-boot?

Probably good in general to have some commit message so someone in the future has some idea why this change was made.

Signed-off-by Jason Cooper <[email protected]>

---
?common/fdt_decode.c ?| ? 11 +++++------ ?include/fdt_decode.h | ? 13 +++++++++++++ ?2 files changed, 18 insertions(+), 6 deletions(-)

common/fdt_decode.c +0 -0

index cd7a071..0f13089 100644
@@ -33,7 +33,7 @@

?* turn this into a sparse list later, and keeps the ID with the name. ?*/
?#define COMPAT(id, name) name

common/fdt_decode.c +1 -1

-static const char *compat_names[COMPAT_COUNT] = {
+const char *compat_names[COMPAT_COUNT] = {

?};

?/**

common/fdt_decode.c +0 -0

@@ -43,7 +43,7 @@ static const char *compat_names[COMPAT_COUNT] = {

?* @param name alias name to look up
?* @return node offset if found, or an error code < 0 otherwise ?*/

?{
? ? ? ?const char *path;
? ? ? ?int alias_node;

common/fdt_decode.c +0 -0

@@ -68,7 +68,7 @@ static int find_alias_node(const void *blob, const char *name)

?* @param prop_name ? ?name of property to find ?* @return address, if found, or ADDR_T_NONE if not ?*/

common/fdt_decode.c +1 -1

-static addr_t get_addr(const void *blob, int node, const char *prop_name)
+addr_t get_addr(const void *blob, int node, const char *prop_name)

?{
? ? ? ?const addr_t *cell;
? ? ? ?int len;

common/fdt_decode.c +0 -0

@@ -91,7 +91,7 @@ static addr_t get_addr(const void *blob, int node, const char *prop_name)

?* @param default_val ?default value to return if the property is not found ?* @return integer value, if found, or default_val if not
?*/

common/fdt_decode.c +1 -1

-static s32 get_int(const void *blob, int node, const char *prop_name,
+s32 get_int(const void *blob, int node, const char *prop_name,

? ? ? ? ? ? ? ?s32 default_val)
?{
? ? ? ?const s32 *cell;

common/fdt_decode.c +0 -0

@@ -115,7 +115,7 @@ static s32 get_int(const void *blob, int node, const char *prop_name,

?* @param default_val ?default value to return if no 'status' property exists ?* @return integer value 0/1, if found, or default_val if not
?*/

common/fdt_decode.c +1 -1

-static int get_is_enabled(const void *blob, int node, int default_val)
+int get_is_enabled(const void *blob, int node, int default_val)

?{
? ? ? ?const char *cell;

common/fdt_decode.c +0 -1

@@ -160,4 +160,3 @@ int fdt_decode_next_alias(const void *blob, const char *name,
 ? ? ? ? ? ? ? ?return err;
 ? ? ? ?return err ? -FDT_ERR_MISSING : node;
 ?}
-

include/fdt_decode.h +0 -0

index ba3c15b..4264e3b 100644
@@ -19,6 +19,8 @@

?* MA 02111-1307 USA
?*/

include/fdt_decode.h +2 -0

+#ifndef _FDT_DECODE_H_
+#define _FDT_DECODE_H_

?/*
?* This file contains convenience functions for decoding useful and

include/fdt_decode.h +11 -1

@@ -55,4 +57,15 @@ enum fdt_compat_id {
 ? ? ? ?COMPAT_COUNT,
 ?};
 
+int find_alias_node(const void *blob, const char *name);
+addr_t get_addr(const void *blob, int node, const char *prop_name);
+s32 get_int(const void *blob, int node, const char *prop_name,
+ ? ? ? s32 default_val);
+int get_is_enabled(const void *blob, int node, int default_val);
+enum fdt_compat_id fdt_decode_lookup(const void *blob, int node);
+int fdt_decode_next_compatible(const void *blob, int node,
+ ? ? ? ? ? ? ? enum fdt_compat_id id);
+int fdt_decode_next_alias(const void *blob, const char *name,
+ ? ? ? ? ? ? ? enum fdt_compat_id id, int *upto);
 
+#endif
--

1.7.0.4

Quoted 24 lines · Jason Cooper

Signed-off-by Jason Cooper <[email protected]>

---
?common/fdt_decode.c ?| ? 11 +++++------ ?include/fdt_decode.h | ? 13 +++++++++++++ ?2 files changed, 18 insertions(+), 6 deletions(-)

common/fdt_decode.c +0 -0

index cd7a071..0f13089 100644
@@ -33,7 +33,7 @@

?* turn this into a sparse list later, and keeps the ID with the name. ?*/
?#define COMPAT(id, name) name

common/fdt_decode.c +1 -1

-static const char *compat_names[COMPAT_COUNT] = {
+const char *compat_names[COMPAT_COUNT] = {

?};

?/**

common/fdt_decode.c +0 -0

@@ -43,7 +43,7 @@ static const char *compat_names[COMPAT_COUNT] = {

?* @param name alias name to look up
?* @return node offset if found, or an error code < 0 otherwise ?*/

common/fdt_decode.c static const char *compat_names[COMPAT_COUNT] = { · line 46

Quoted 2 lines

common/fdt_decode.c +1 -1

-static int find_alias_node(const void *blob, const char *name)
+int find_alias_node(const void *blob, const char *name)

If we are going to export these (which I agree we must if we are to move this code into drivers), then it should have the fdt_decode_ prefix.

Perhaps this is too verbose? I would be happy with fdtdec_find_alias_node() if that sounds better?

Quoted 68 lines

?{
? ? ? ?const char *path;
? ? ? ?int alias_node;

common/fdt_decode.c +0 -0

@@ -68,7 +68,7 @@ static int find_alias_node(const void *blob, const char *name)

?* @param prop_name ? ?name of property to find ?* @return address, if found, or ADDR_T_NONE if not ?*/

common/fdt_decode.c +1 -1

-static addr_t get_addr(const void *blob, int node, const char *prop_name)
+addr_t get_addr(const void *blob, int node, const char *prop_name)

?{
? ? ? ?const addr_t *cell;
? ? ? ?int len;

common/fdt_decode.c +0 -0

@@ -91,7 +91,7 @@ static addr_t get_addr(const void *blob, int node, const char *prop_name)

?* @param default_val ?default value to return if the property is not found ?* @return integer value, if found, or default_val if not
?*/

common/fdt_decode.c +1 -1

-static s32 get_int(const void *blob, int node, const char *prop_name,
+s32 get_int(const void *blob, int node, const char *prop_name,

? ? ? ? ? ? ? ?s32 default_val)
?{
? ? ? ?const s32 *cell;

common/fdt_decode.c +0 -0

@@ -115,7 +115,7 @@ static s32 get_int(const void *blob, int node, const char *prop_name,

?* @param default_val ?default value to return if no 'status' property exists ?* @return integer value 0/1, if found, or default_val if not
?*/

common/fdt_decode.c +1 -1

-static int get_is_enabled(const void *blob, int node, int default_val)
+int get_is_enabled(const void *blob, int node, int default_val)

?{
? ? ? ?const char *cell;

common/fdt_decode.c +0 -1

@@ -160,4 +160,3 @@ int fdt_decode_next_alias(const void *blob, const char *name,
 ? ? ? ? ? ? ? ?return err;
 ? ? ? ?return err ? -FDT_ERR_MISSING : node;
 ?}
-

include/fdt_decode.h +0 -0

index ba3c15b..4264e3b 100644
@@ -19,6 +19,8 @@

?* MA 02111-1307 USA
?*/

include/fdt_decode.h +2 -0

+#ifndef _FDT_DECODE_H_
+#define _FDT_DECODE_H_

?/*
?* This file contains convenience functions for decoding useful and

include/fdt_decode.h +11 -1

@@ -55,4 +57,15 @@ enum fdt_compat_id {
 ? ? ? ?COMPAT_COUNT,
 ?};
 
+int find_alias_node(const void *blob, const char *name);
+addr_t get_addr(const void *blob, int node, const char *prop_name);
+s32 get_int(const void *blob, int node, const char *prop_name,
+ ? ? ? s32 default_val);
+int get_is_enabled(const void *blob, int node, int default_val);
+enum fdt_compat_id fdt_decode_lookup(const void *blob, int node);
+int fdt_decode_next_compatible(const void *blob, int node,
+ ? ? ? ? ? ? ? enum fdt_compat_id id);
+int fdt_decode_next_alias(const void *blob, const char *name,
+ ? ? ? ? ? ? ? enum fdt_compat_id id, int *upto);
 
+#endif
--

1.7.0.4

Signed-off-by Jason Cooper <[email protected]>

---

?common/fdt_decode.c ?| ? ?1 +
?drivers/rtc/mvrtc.c ?| ? 62 +++++++++++++++++++++++++++++++++++++++++++++++--
?drivers/rtc/mvrtc.h ?| ? ?7 +++++
?include/fdt_decode.h | ? ?1 +

?4 files changed, 68 insertions(+), 3 deletions(-)

common/fdt_decode.c +0 -0

index 0f13089..1a0dcf4 100644
@@ -34,6 +34,7 @@

?*/
?#define COMPAT(id, name) name
?const char *compat_names[COMPAT_COUNT] = {
+ ? ? ? COMPAT(MARVELL_KIRKWOOD_RTC, "marvell,kirkwood-rtc"), ?};

?/**

drivers/rtc/mvrtc.c +0 -0

index ccc573a..ce2dc3d 100644
@@ -28,18 +28,62 @@

?#include <common.h>
?#include <command.h>
?#include <rtc.h>

drivers/rtc/mvrtc.c +3 -0

+#ifdef CONFIG_OF_CONTROL
+#include <fdt_decode.h>
+#endif

?#include "mvrtc.h"

drivers/rtc/mvrtc.c +2 -0

+DECLARE_GLOBAL_DATA_PTR;
+

?/* This RTC does not support century, so we assume 20 */ ?#define CENTURY 20

+#ifndef CONFIG_OF_CONTROL

drivers/rtc/mvrtc.c +32 -0

+struct mvrtc_registers *mvrtc_get_config(void) {
+ ? ? ? return (struct mvrtc_registers *)KW_RTC_BASE;
+}
+
+#else
+int fdt_decode_rtc(const void *blob, int node, struct fdt_rtc *config)
+{
+ ? ? ? config->reg = get_addr(blob, node, "reg");
+ ? ? ? config->enabled = get_is_enabled(blob, node, 0);
+
+ ? ? ? return 0;
+}
+
+struct mvrtc_registers *mvrtc_get_config(void) {
+ ? ? ? const void ? ? *blob = gd->blob;
+ ? ? ? struct fdt_rtc config;
+ ? ? ? int ? ? ? ? ? ?node;
+ ? ? ? int ? ? ? ? ? ?index=0;
+
+ ? ? ? node = fdt_decode_next_alias(blob, "rtc",
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?COMPAT_MARVELL_KIRKWOOD_RTC, &index);
+
+ ? ? ? if (node < 0)
+ ? ? ? ? ? ? ? return NULL;
+
+ ? ? ? if (fdt_decode_rtc(blob, node, &config))
+ ? ? ? ? ? ? ? return NULL;
+
+ ? ? ? return config.enabled ? (struct mvrtc_registers *)config.reg : NULL;
+}
+#endif
+

?int rtc_get(struct rtc_time *t)
?{
? ? ? ?u32 time;
? ? ? ?u32 date;
? ? ? ?struct mvrtc_registers *mvrtc_regs;

- ? ? ? mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
+ ? ? ? mvrtc_regs = mvrtc_get_config();

drivers/rtc/mvrtc.c +6 -0

+#ifdef CONFIG_OF_CONTROL
+ ? ? ? if (mvrtc_regs == NULL) {
+ ? ? ? ? ? ? ? printf("Error decoding fdt for mvrtc.\n");
+ ? ? ? ? ? ? ? return -1;
+ ? ? ? }
+#endif

? ? ? ?/* read the time register */
? ? ? ?time = readl(&mvrtc_regs->time);

drivers/rtc/mvrtc.c +7 -1

@@ -79,7 +123,13 @@ int rtc_set(struct rtc_time *t)
 ? ? ? ?u32 date = 0;
 ? ? ? ?struct mvrtc_registers *mvrtc_regs;
 
- ? ? ? mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
+ ? ? ? mvrtc_regs = mvrtc_get_config();
+#ifdef CONFIG_OF_CONTROL
+ ? ? ? if (mvrtc_regs == NULL) {
+ ? ? ? ? ? ? ? printf("Error decoding fdt for mvrtc.\n");
+ ? ? ? ? ? ? ? return -1;
+ ? ? ? }
+#endif
 

? ? ? ?/* check that this code isn't 80+ years old ;-) */ ? ? ? ?if ((t->tm_year / 100) != CENTURY)

drivers/rtc/mvrtc.c +7 -1

@@ -111,7 +161,13 @@ void rtc_reset(void)
 ? ? ? ?u32 sec;
 ? ? ? ?struct mvrtc_registers *mvrtc_regs;
 
- ? ? ? mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
+ ? ? ? mvrtc_regs = mvrtc_get_config();
+#ifdef CONFIG_OF_CONTROL
+ ? ? ? if (mvrtc_regs == NULL) {
+ ? ? ? ? ? ? ? printf("Error decoding fdt for mvrtc.\n");
+ ? ? ? ? ? ? ? return;
+ ? ? ? }
+#endif
 

? ? ? ?/* no init routine for this RTC needed, just check that it's working */

? ? ? ?time = readl(&mvrtc_regs->time);

drivers/rtc/mvrtc.h +0 -0

index b9d5c6f..56b09f2 100644

drivers/rtc/mvrtc.h +2 -0

+#endif
+

?/* time register */
?#define MVRTC_SEC_SFT ? ? ? ? ?0
?#define MVRTC_SEC_MSK ? ? ? ? ?0x7f

include/fdt_decode.h +0 -0

index 4264e3b..f236643 100644
@@ -54,6 +54,7 @@ struct fdt_memory {

?*/
?enum fdt_compat_id {
? ? ? ?COMPAT_UNKNOWN,
+ ? ? ? COMPAT_MARVELL_KIRKWOOD_RTC,

? ? ? ?COMPAT_COUNT,
?};

--
1.7.0.4

Quoted 34 lines · Jason Cooper

Signed-off-by Jason Cooper <[email protected]>

---

?common/fdt_decode.c ?| ? ?1 +
?drivers/rtc/mvrtc.c ?| ? 62 +++++++++++++++++++++++++++++++++++++++++++++++--
?drivers/rtc/mvrtc.h ?| ? ?7 +++++
?include/fdt_decode.h | ? ?1 +

?4 files changed, 68 insertions(+), 3 deletions(-)

common/fdt_decode.c +0 -0

index 0f13089..1a0dcf4 100644
@@ -34,6 +34,7 @@

?*/
?#define COMPAT(id, name) name
?const char *compat_names[COMPAT_COUNT] = {
+ ? ? ? COMPAT(MARVELL_KIRKWOOD_RTC, "marvell,kirkwood-rtc"), ?};

?/**

drivers/rtc/mvrtc.c +0 -0

index ccc573a..ce2dc3d 100644
@@ -28,18 +28,62 @@

?#include <common.h>
?#include <command.h>
?#include <rtc.h>

drivers/rtc/mvrtc.c +3 -0

+#ifdef CONFIG_OF_CONTROL
+#include <fdt_decode.h>
+#endif

?#include "mvrtc.h"

Quoted 6 lines

drivers/rtc/mvrtc.c +2 -0

+DECLARE_GLOBAL_DATA_PTR;
+

?/* This RTC does not support century, so we assume 20 */ ?#define CENTURY 20

+#ifndef CONFIG_OF_CONTROL

Perhaps #ifdef and put the fdt code first?

Quoted 77 lines

drivers/rtc/mvrtc.c +32 -0

+struct mvrtc_registers *mvrtc_get_config(void) {
+ ? ? ? return (struct mvrtc_registers *)KW_RTC_BASE;
+}
+
+#else
+int fdt_decode_rtc(const void *blob, int node, struct fdt_rtc *config)
+{
+ ? ? ? config->reg = get_addr(blob, node, "reg");
+ ? ? ? config->enabled = get_is_enabled(blob, node, 0);
+
+ ? ? ? return 0;
+}
+
+struct mvrtc_registers *mvrtc_get_config(void) {
+ ? ? ? const void ? ? *blob = gd->blob;
+ ? ? ? struct fdt_rtc config;
+ ? ? ? int ? ? ? ? ? ?node;
+ ? ? ? int ? ? ? ? ? ?index=0;
+
+ ? ? ? node = fdt_decode_next_alias(blob, "rtc",
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?COMPAT_MARVELL_KIRKWOOD_RTC, &index);
+
+ ? ? ? if (node < 0)
+ ? ? ? ? ? ? ? return NULL;
+
+ ? ? ? if (fdt_decode_rtc(blob, node, &config))
+ ? ? ? ? ? ? ? return NULL;
+
+ ? ? ? return config.enabled ? (struct mvrtc_registers *)config.reg : NULL;
+}
+#endif
+

?int rtc_get(struct rtc_time *t)
?{
? ? ? ?u32 time;
? ? ? ?u32 date;
? ? ? ?struct mvrtc_registers *mvrtc_regs;

- ? ? ? mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
+ ? ? ? mvrtc_regs = mvrtc_get_config();

drivers/rtc/mvrtc.c +6 -0

+#ifdef CONFIG_OF_CONTROL
+ ? ? ? if (mvrtc_regs == NULL) {
+ ? ? ? ? ? ? ? printf("Error decoding fdt for mvrtc.\n");
+ ? ? ? ? ? ? ? return -1;
+ ? ? ? }
+#endif

? ? ? ?/* read the time register */
? ? ? ?time = readl(&mvrtc_regs->time);

drivers/rtc/mvrtc.c +7 -1

@@ -79,7 +123,13 @@ int rtc_set(struct rtc_time *t)
 ? ? ? ?u32 date = 0;
 ? ? ? ?struct mvrtc_registers *mvrtc_regs;
 
- ? ? ? mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
+ ? ? ? mvrtc_regs = mvrtc_get_config();
+#ifdef CONFIG_OF_CONTROL
+ ? ? ? if (mvrtc_regs == NULL) {
+ ? ? ? ? ? ? ? printf("Error decoding fdt for mvrtc.\n");
+ ? ? ? ? ? ? ? return -1;
+ ? ? ? }
+#endif
 

? ? ? ?/* check that this code isn't 80+ years old ;-) */ ? ? ? ?if ((t->tm_year / 100) != CENTURY)

drivers/rtc/mvrtc.c +7 -1

@@ -111,7 +161,13 @@ void rtc_reset(void)
 ? ? ? ?u32 sec;
 ? ? ? ?struct mvrtc_registers *mvrtc_regs;
 
- ? ? ? mvrtc_regs = (struct mvrtc_registers *)KW_RTC_BASE;
+ ? ? ? mvrtc_regs = mvrtc_get_config();
+#ifdef CONFIG_OF_CONTROL
+ ? ? ? if (mvrtc_regs == NULL) {
+ ? ? ? ? ? ? ? printf("Error decoding fdt for mvrtc.\n");
+ ? ? ? ? ? ? ? return;
+ ? ? ? }
+#endif
 

Quoted 1 line

? ? ? ?/* no init routine for this RTC needed, just check that it's working */

Hmm I think it would be better to decode the fdt once in init, and store it in your structure. It seems like you are doing it each time the driver is called.

Quoted 9 lines

? ? ? ?time = readl(&mvrtc_regs->time);

drivers/rtc/mvrtc.h +0 -0

index b9d5c6f..56b09f2 100644
@@ -37,6 +37,13 @@ struct mvrtc_registers {
 ? ? ? ?u32 date;
 ?};
 

drivers/rtc/mvrtc.h struct mvrtc_registers { · line 44

Quoted 5 lines

drivers/rtc/mvrtc.h +5 -0

+#ifdef CONFIG_OF_CONTROL
+struct fdt_rtc {
+ ? ? ? addr_t reg; ?/* address of the registers */
+ ? ? ? int enabled; /* 1 if enabled, 0 if disabled */
+};

It seems to be that this structure should generally only be needed in the C file, so should perhaps go there.

Quoted 10 lines

drivers/rtc/mvrtc.h +2 -0

+#endif
+

?/* time register */
?#define MVRTC_SEC_SFT ? ? ? ? ?0
?#define MVRTC_SEC_MSK ? ? ? ? ?0x7f

include/fdt_decode.h +0 -0

index 4264e3b..f236643 100644
@@ -54,6 +54,7 @@ struct fdt_memory {

Quoted 4 lines

?*/
?enum fdt_compat_id {
? ? ? ?COMPAT_UNKNOWN,
+ ? ? ? COMPAT_MARVELL_KIRKWOOD_RTC,

My cunning plan is that this can be some sort of driver ID and could serve as a lead in to a unified device model (it provides a simple enumeration of available drivers).

However, perhaps we should discuss this separately.

Signed-off-by Jason Cooper <[email protected]>

---
 common/fdt_decode.c  |    1 +
 drivers/rtc/mvrtc.c  |   62 +++++++++++++++++++++++++++++++++++++++++++++++--
 drivers/rtc/mvrtc.h  |    7 +++++
 include/fdt_decode.h |    1 +
 4 files changed, 68 insertions(+), 3 deletions(-)

Dear Jason Cooper,

Quoted 8 lines · In message <6d40c2a90839e1f8dae389a562ea20ed2bd15083.1316092940.git.u-boot@lake…

Signed-off-by Jason Cooper <[email protected]>

---

?common/fdt_decode.c ?| ? ?1 +
?drivers/rtc/mvrtc.c ?| ? 62 +++++++++++++++++++++++++++++++++++++++++++++++--
?drivers/rtc/mvrtc.h ?| ? ?7 +++++
?include/fdt_decode.h | ? ?1 +

?4 files changed, 68 insertions(+), 3 deletions(-)

Checkpatch says:

total: 3 errors, 0 warnings, 118 lines checked

Please clean up and resubmit. ?Thanks.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The Buddha, the Godhead, resides quite as comfortably in the circuits of a digital computer or the gears of a cycle transmission as he does at the top of a mountain or in the petals of a flower.
? ? ? ? ? ?- R. ?Pirsig, "Zen and the Art of Motorcycle Maintenance"

Hi Wolfgang,

Quoted 12 lines · Wolfgang Denk

Dear Jason Cooper,

Quoted 8 lines · In message <6d40c2a90839e1f8dae389a562ea20ed2bd15083.1316092940.git.u-boot@lake…

Signed-off-by Jason Cooper <[email protected]>

---

?common/fdt_decode.c ?| ? ?1 +
?drivers/rtc/mvrtc.c ?| ? 62 +++++++++++++++++++++++++++++++++++++++++++++++--
?drivers/rtc/mvrtc.h ?| ? ?7 +++++
?include/fdt_decode.h | ? ?1 +

?4 files changed, 68 insertions(+), 3 deletions(-)

FYI I plan to do a new version of the base fdt patch in the next few days which addresses comments, etc.

Quoted 20 lines

Checkpatch says:

total: 3 errors, 0 warnings, 118 lines checked

Please clean up and resubmit. ?Thanks.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The Buddha, the Godhead, resides quite as comfortably in the circuits of a digital computer or the gears of a cycle transmission as he does at the top of a mountain or in the petals of a flower.
? ? ? ? ? ?- R. ?Pirsig, "Zen and the Art of Motorcycle Maintenance"

Signed-off-by Jason Cooper <[email protected]>

---

?board/Marvell/dreamplug/kirkwood-dreamplug.dts | ? 12 +++++++++++
?board/Marvell/dreamplug/kirkwood.dtsi ? ? ? ? ?| ? 25 ++++++++++++++++++++++++
?include/configs/dreamplug.h ? ? ? ? ? ? ? ? ? ?| ? ?5 ++++

?3 files changed, 42 insertions(+), 0 deletions(-) ?create mode 100644 board/Marvell/dreamplug/kirkwood-dreamplug.dts ?create mode 100644 board/Marvell/dreamplug/kirkwood.dtsi

board/Marvell/dreamplug/kirkwood-dreamplug.dts new file +12 -0

new file mode 100644
index 0000000..eb900c3
@@ -0,0 +1,12 @@
+/dts-v1/;
+
+/include/ "kirkwood.dtsi"
+
+/ {
+ ? ? ? model = "Marvell Dreamplug";
+ ? ? ? compatible = "marvell,dreamplug", "marvell,kirkwood";
+
+ ? ? ? rtc at 0xf1010300 {
+ ? ? ? ? ? ? ? status = "ok";
+ ? ? ? };
+};

board/Marvell/dreamplug/kirkwood.dtsi new file +25 -0

new file mode 100644
index 0000000..15e52bd
@@ -0,0 +1,25 @@
+/ {
+ ? ? ? model = "Marvell Kirkwood";
+ ? ? ? compatible = "marvell,kirkwood";
+ ? ? ? #address-cells = <1>;
+ ? ? ? #size-cells = <1>;
+
+ ? ? ? cpus {
+ ? ? ? ? ? ? ? #address-cells = <1>;
+ ? ? ? ? ? ? ? #size-cells = <0>;
+ ? ? ? ? ? ? ? cpu at 0 {
+ ? ? ? ? ? ? ? ? ? ? ? compatible = "arm,arm926ejs";
+ ? ? ? ? ? ? ? ? ? ? ? reg = <0>;
+ ? ? ? ? ? ? ? };
+ ? ? ? };
+
+ ? ? ? rtc at 0xf1010300 {
+ ? ? ? ? ? ? ? compatible = "marvell,kirkwood-rtc";
+ ? ? ? ? ? ? ? reg = <0xf1010300 0x02>;
+ ? ? ? ? ? ? ? status = "disabled";
+ ? ? ? };
+
+ ? ? ? aliases {
+ ? ? ? ? ? ? ? rtc0 = "/rtc at 0xf1010300";
+ ? ? ? };
+};

include/configs/dreamplug.h +0 -0

index 8d1b935..9960d35 100644
@@ -50,6 +50,11 @@

?#define CONFIG_MACH_TYPE ? ? ? MACH_TYPE_DREAMPLUG
?#define CONFIG_SKIP_LOWLEVEL_INIT ? ? ?/* disable board lowlevel_init */

include/configs/dreamplug.h +3 -0

+#define CONFIG_OF_CONTROL
+#define CONFIG_OF_LIBFDT
+

?/*
?* Commands configuration
?*/
--
1.7.0.4

Quoted 67 lines · Jason Cooper

Signed-off-by Jason Cooper <[email protected]>

---

?board/Marvell/dreamplug/kirkwood-dreamplug.dts | ? 12 +++++++++++
?board/Marvell/dreamplug/kirkwood.dtsi ? ? ? ? ?| ? 25 ++++++++++++++++++++++++
?include/configs/dreamplug.h ? ? ? ? ? ? ? ? ? ?| ? ?5 ++++

?3 files changed, 42 insertions(+), 0 deletions(-) ?create mode 100644 board/Marvell/dreamplug/kirkwood-dreamplug.dts ?create mode 100644 board/Marvell/dreamplug/kirkwood.dtsi

board/Marvell/dreamplug/kirkwood-dreamplug.dts new file +12 -0

new file mode 100644
index 0000000..eb900c3
@@ -0,0 +1,12 @@
+/dts-v1/;
+
+/include/ "kirkwood.dtsi"
+
+/ {
+ ? ? ? model = "Marvell Dreamplug";
+ ? ? ? compatible = "marvell,dreamplug", "marvell,kirkwood";
+
+ ? ? ? rtc at 0xf1010300 {
+ ? ? ? ? ? ? ? status = "ok";
+ ? ? ? };
+};

board/Marvell/dreamplug/kirkwood.dtsi new file +25 -0

new file mode 100644
index 0000000..15e52bd
@@ -0,0 +1,25 @@
+/ {
+ ? ? ? model = "Marvell Kirkwood";
+ ? ? ? compatible = "marvell,kirkwood";
+ ? ? ? #address-cells = <1>;
+ ? ? ? #size-cells = <1>;
+
+ ? ? ? cpus {
+ ? ? ? ? ? ? ? #address-cells = <1>;
+ ? ? ? ? ? ? ? #size-cells = <0>;
+ ? ? ? ? ? ? ? cpu at 0 {
+ ? ? ? ? ? ? ? ? ? ? ? compatible = "arm,arm926ejs";
+ ? ? ? ? ? ? ? ? ? ? ? reg = <0>;
+ ? ? ? ? ? ? ? };
+ ? ? ? };
+
+ ? ? ? rtc at 0xf1010300 {
+ ? ? ? ? ? ? ? compatible = "marvell,kirkwood-rtc";
+ ? ? ? ? ? ? ? reg = <0xf1010300 0x02>;
+ ? ? ? ? ? ? ? status = "disabled";
+ ? ? ? };
+
+ ? ? ? aliases {
+ ? ? ? ? ? ? ? rtc0 = "/rtc at 0xf1010300";
+ ? ? ? };
+};

include/configs/dreamplug.h +0 -0

index 8d1b935..9960d35 100644
@@ -50,6 +50,11 @@

?#define CONFIG_MACH_TYPE ? ? ? MACH_TYPE_DREAMPLUG
?#define CONFIG_SKIP_LOWLEVEL_INIT ? ? ?/* disable board lowlevel_init */

include/configs/dreamplug.h line 54

Quoted 2 lines

include/configs/dreamplug.h +2 -0

+#define CONFIG_OF_EMBED
+#define CONFIG_DEFAULT_DEVICE_TREE "kirkwood-dreamplug"

One of my experiments was to create this automatically from <vendor>-<board>.dts, so that this isn't needed explicitly. Is it better to require a CONFIG for this, or just use the expected name?

Simon, All,

This patch series is my attempt to learn device tree with a driver I'm familiar with. ?Also, to create a real, working example for fdt in U-boot.

To make this work, I applied v2 of Simon Glass' patch series (what this email is in reply to) against v2011.09-rc1. ?I then cherry picked my dreamplug board support patch. ?Last, I applied the following series.

It works, although with CONFIG_OF_EMBED. ?I haven't tried _SEPARATE yet.

Some thoughts:

1.) 'kirkwood-dreamplug.dts' can be renamed 'dreamplug.dts'. ?Due to ? ?machine_is_XXX 'dreamplug' will be unique, concise, and descriptive. ? ?This requires changes to Simon Glass' patchset.

2.) The fdt files should be moved up one directory level, in the end, it ? ?should look like:

? ?board/Marvell/armada100-dt.c
? ?board/Marvell/armada100-dt.h
? ?board/Marvell/armada100.dtsi
? ?board/Marvell/dreamplug.dts
? ?board/Marvell/gplugd.dts ? ? ?# this includes armada100.dtsi ? ?board/Marvell/guruplug.dts
? ?board/Marvell/kirkwood.dtsi
? ?board/Marvell/kirkwood-dt.c
? ?board/Marvell/kirkwood-dt.h
? ?board/Marvell/openrd.dts
? ?board/Marvell/sheevaplug.dts
? ?...
? ?board/Marvell/<other boards>.dts

? ?This also requires changes to Simon's patchset.

3.) Since mach names (dreamplug) and SoC names (kirkwood) are unique, ? ?should we put all .dts and .dtsi files in one dir? ?eg /dts ? ?This ? ?would facilitate migration to Grant Likely's device-tree.git ? ?whereever and whenever it lands. ?This is also similar to how Linux ? ?currently does it (arch/arm/boot/dts/)

Jason Cooper (4):
?fdt: remove i2c example code.
?fdt_decode: make more available.
?mvrtc: add fdt support.
?dreamplug: enable fdt

?board/Marvell/dreamplug/kirkwood-dreamplug.dts | ? 12 +++++
?board/Marvell/dreamplug/kirkwood.dtsi ? ? ? ? ?| ? 25 ++++++++++
?common/fdt_decode.c ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 26 ++--------
?drivers/rtc/mvrtc.c ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 62 ++++++++++++++++++++++-
?drivers/rtc/mvrtc.h ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?7 +++
?include/configs/dreamplug.h ? ? ? ? ? ? ? ? ? ?| ? ?5 ++
?include/fdt_decode.h ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 46 +++++------------

?7 files changed, 128 insertions(+), 55 deletions(-) ?create mode 100644 board/Marvell/dreamplug/kirkwood-dreamplug.dts ?create mode 100644 board/Marvell/dreamplug/kirkwood.dtsi

Quoted 5 lines · Jason Cooper

To make this work, I applied v2 of Simon Glass' patch series (what this email is in reply to) against v2011.09-rc1. ?I then cherry picked my dreamplug board support patch. ?Last, I applied the following series.

It works, although with CONFIG_OF_EMBED. ?I haven't tried _SEPARATE yet.

Please do, as that is what we really want people to use.

Quoted 1 line

Some thoughts:

Quoted 5 lines

3.) Since mach names (dreamplug) and SoC names (kirkwood) are unique, ? ?should we put all .dts and .dtsi files in one dir? ?eg /dts ? ?This ? ?would facilitate migration to Grant Likely's device-tree.git ? ?whereever and whenever it lands. ?This is also similar to how Linux ? ?currently does it (arch/arm/boot/dts/)

It does have advantages, although (hopefully) the number of files will grow quite large. But bear in mind that people will create their own .dtsi files, so we will need a strong naming convention there also (always use the board prefix perhaps).

If we want to be similar to Linux they should go in arch/<arch>/dts, but then we are putting board description files outside the board/ structure, which doesn't seem right. The arch/arm/ subdir is supposed to be for arch-specific code which is generic across boards. Remember that the dts will include board things, not just SOC things.

Clearly we don't want .dts files in boards/ and even boards/dts seems odd since all the other files are in board/<vendor>. Hmm I quite like having them in board/<vendor>/dts.