device tree support

GoogleGroups
1

Hello,

I have a beagleboard-xM revB. Does the board have device tree support?If so,where can I find the sources and/or pre-built images for uImage, u-boot.bin, MLO, device tree and root-file system. Is the board support for BB-xm available in mainline along with device tree support?

Thank You…

2

Device tree is SW. If it you use a 3.8 kernel or later, then yes it has DT support.

What we provide on the board when it ships, i snot a 3.8 Kernel.

Gerald

3

For the "xM B" mainline device tree kernel still doesn't properly set
the usb reset pin, so you will still need kernel patches. (it's
polarity is also inverted with respect to the xM C)

Just follow the guide here, with the "v3.11.x" kernel branch path.
(you could also use v3.12.x, as rc2 is in pretty good shape at the
moment)..

http://eewiki.net/display/linuxonarm/BeagleBoard

Regards,

4

Thanks Gerald for the quick reply.
I am a newbie and have a few doubts:

  • A different u-boot that supports device tree loading will be needed.Does u-boot 2013.07 has the support for BB-xm?
  • Is there any change in the MLO if we use device tree binary?
    Thanks in advance…
5

I will let Robert or someone else answer that.

Gerald

6

Thanks Gerald for the quick reply.
I am a newbie and have a few doubts:

A different u-boot that supports device tree loading will be needed.

Doesn't matter, if u-boot doesn't support loading the device tree, you
use the appended device tree method.

Does
u-boot 2013.07 has the support for BB-xm?

You should check the u-boot git tree as my memory is not that good,
but BB-xm support was added to the u-boot tree pretty soon after it
was released.. So let's say 2011...

Is there any change in the MLO if we use device tree binary?

MLO, runs from sram and just initializes a few things including the
ddr to load "u-boot.img" and run it... It has nothing to do with later
loading the kernel, other then it's built from the same source that
built u-boot.img..

Regards,

7

BTW: in any case, u-boot v2013.07 or mainline will load a beagle xm
device tree kernel just fine.. Although the patches i have on my wiki
page help things out by pulling a few things from mainline to v2013.07
to make it much easier.

Regards,

8

Thanks RobertCNelson,

I will follow the link you gave and see if I am able to boot the board.Just few questions:

  • In the link you mentioned it seems you use zimage for the linux kernel?Is there any way to use uimage?
  • Also previously on a different board I remember using u-boot.bin while in the guide you are using u-boot.img.What is the difference between these two files?

Thank You

9

Thanks RobertCNelson,

I will follow the link you gave and see if I am able to boot the board.Just
few questions:

In the link you mentioned it seems you use zimage for the linux kernel?Is
there any way to use uimage?

What for? zImage (raw kernel output) are way more useful then the
uImage's. The uImage format is just a zImage with a u-boot wrapper
with a specific SOC zreladdress hardcoded.. Thus you can't share a
uImage binary between an omap/imx/etc device...

Also previously on a different board I remember using u-boot.bin while in
the guide you are using u-boot.img.What is the difference between these two
files?

If your using "u-boot.bin" then the MLO you used is from a long
abandoned "x-loader" project.. Of which all functionally was moved
into u-boot a few years back.

Thus, I'm going to advise you to follow the wiki to a T, as it sounds
like you might have been out of the beagleboard
bootloader/kernel/rootfilesystem build process for awhile. As the
directions work as written..

Regards,

10

Thanks RobertCNelson

I asked for uimage because I also wanted to try booting using tftp which requires transferring uimage and device tree to the ram.Can I use zimage instead of uimage for tftpboot?If so,is there any change in the command for boot?
Also I am not sure how the boot using uimage and zimage takes place and what difference does it make in u-boot.You said that the uimage has a load address hardcoded.So how does zimage gets the load address?Can you please elaborate? Thanks for the help…

11

Thanks RobertCNelson

I asked for uimage because I also wanted to try booting using tftp which
requires transferring uimage and device tree to the ram.Can I use zimage
instead of uimage for tftpboot?If so,is there any change in the command for
boot?

tftpboot is just a media transfer command.. You just going to tfpboot
some binary from a server to an andress. zImage just needs to be
called by "bootz <address>" where as uImage needs "bootm <address>"

Also I am not sure how the boot using uimage and zimage takes place and
what difference does it make in u-boot.You said that the uimage has a load
address hardcoded.So how does zimage gets the load address?Can you please
elaborate? Thanks for the help.....

Well, the soc already knows the address...

Regards,

12

Hello RobertCNelson,

I may be wrong here, but I thought that u-boot was responsible for the loadaddress of the zimage.In the u-boot patches. there is a loadzimage command which has the loadaddress as one of its arguments.So how does the soc know the address?
Also if this is the case the only problem I see with uImage is one extra step of making it.
Kindly clarify this…I am really confused

13

Hello RobertCNelson,

I am sorry for my previous post.I did some research on uimage and zimage and I think I may have misunderstood a few things you told.Can you please confirm if I am right now?

  • The zreladdress is the address for the uncompressed kernel image.

  • The loadaddress in loadzimage command is the address for compressed kernel image.

  • The problem in using u-image for multi-platforms is that it needs an entry addres which can be outside the sdram on different platforms.

  • The base address of the sdram for loading the uncompressed image is given to the kernel using device tree.

There is a file named Makefile.boot in arch/arm/mach-omap2. This file defines zreladdr.Is this file necessary(for zImage booting)?

14

just FYI, TI's tom rini recently submitted a patch to u-boot,
replacing the uImage values in am335x_evm.h with references to zImage,
thus making zImage the default image format. AFAIK, there is no
downside to using zImage from now on.

rday

15

Hello RobertCNelson,

I am sorry for my previous post.I did some research on uimage and zimage and
I think I may have misunderstood a few things you told.Can you please
confirm if I am right now?

The zreladdress is the address for the uncompressed kernel image.
The loadaddress in loadzimage command is the address for compressed kernel
image.
The problem in using u-image for multi-platforms is that it needs an entry
addres which can be outside the sdram on different platforms.
The base address of the sdram for loading the uncompressed image is given to
the kernel using device tree.

All this research and it basicly boils down to one problem.. Say you
are supporting two boards with different silicon vendors..

For board A, what was the zreladdress so you can build a "uImage" with mkimage??

Or do you just copy zImage and work on your real application?

There is a file named Makefile.boot in arch/arm/mach-omap2. This file
defines zreladdr.Is this file necessary(for zImage booting)?

No, that variable was "only" used in the non-multiarch case when
calling "make uImage" to create the "uImage" file correctly..

Regards,

16

i used the address 80008000 (-a option in mkimage) for the uImage.i used the same address as the entry address(-e option).

Also can you confirm the points i said in the previous post.That would clarify a lot to me.

I believe that the -a option in mkimage is irrelevant.I think the relevent address in the mkimage command is the entry image address(-e option).This address is used by u-boot to copy the compressed uimage(but without the 64k header i.e zImage only).After this the process is the same as zimage as there is no 64k header.Can you also confirm this.

about the multi-arch thing I think that the problem with using uImage is that the entry address may not lie in the ram space of all the boards that the kernel can support.Right???
But if this is the case the we will have to change the bootenv of u-boot as we need to load the compressed zimage/uimage somewhere in the ram first.Am I correct?

17

i used the address 80008000 (-a option in mkimage) for the uImage.i used the
same address as the entry address(-e option).

Also can you confirm the points i said in the previous post.That would
clarify a lot to me.

I'll leave that issue to someone else...

I believe that the -a option in mkimage is irrelevant.I think the relevent
address in the mkimage command is the entry image address(-e option).This
address is used by u-boot to copy the compressed uimage(but without the 64k
header i.e zImage only).After this the process is the same as zimage as
there is no 64k header.Can you also confirm this.

All mkimage does it put a 64k wrapper header on zImage... Nothing
more, nothing less..

about the multi-arch thing I think that the problem with using uImage is
that the entry address may not lie in the ram space of all the boards that
the kernel can support.Right???

It's not "lieing" it's just that each vendor is free to implements it
at a different address, or where ever they want..

See my small list here:

But if this is the case the we will have to change the bootenv of u-boot as
we need to load the compressed zimage/uimage somewhere in the ram first.Am I
correct?

Why change bootenv, the default settings in u-boot for the particular
target already work out of the box..

Regards,

18

Thanks RobertCNelson…

Leaving the rest of the things,can you tell where does the zImage get the base address of the RAM.Is it the device tree??

19

shouldn't that be just "64-byte wrapper"?

rday

20

It does not get the address from zImage/device tree as u-boot
"already" knows the address, as you built it for a specific target.

Regards,