[yocto] Board files vs. device tree

Fabian Schwartau fabian at opencode.eu
Sun Dec 21 09:56:49 PST 2014


Am 21.12.2014 um 18:08 schrieb Maciek Borzecki:
 > On 12/21 16:32, Fabian Schwartau wrote:
 >> Hi,
 >>
 >> I am building a system with yocto for a board which is similar to
 >> Beagleboard-xM. So I used beagleboard as a starter. However, the 
kernel is
 >> not booting. Uboot just tells me that he is starting the kernel and then
 >> nothing happens any more.
 >> So I guess there is something wrong with the pin muxing as my board is a
 >> little different from Beagleboard.
 >> At the moment I am using the device tree file for beagleboard-xm by 
passing
 >> it with the uboot command
 >> bootm ${loadaddr} - ${dtbaddr}
 >> I looked around in the kernel and had to notice that there are still 
several
 >> board  files build in the kernel.
 >> When there are several board files compiled into the kernel, how 
does the
 >> kernel determine the right one at boot time?
 >
 > U-boot does that, based on what is found at runtime. Typically this
 > would employ checks for CPU IDs, EEPROM contents, GPIO line states
 > etc. then at some point the could would set board_name to some
 > value. IIRC the exact model of Beagle Bone is determined based on system
 > EEPROM contents. Then the default uboot script would check board_name
 > and pick proper *.dtb based on some hardcoded names.
OK, but there he is only creating the default configuration I guess. As 
I am using my own uboot configuration file, this does not matter to me 
and I will load the dtb file my own using the mentioned uboot command. 
Is that correct?
 >
 > The actual checks are here:
 > 
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;h=560e3bf7755d55d37c1e5e9fb5de162568d9cc9f;hb=HEAD#l176
 >
 > Board checks here:
 > http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/am335x/board.h
 >
 >> What does the kernel do if there are board files activated and I am also
 >> passing a device tree?
 >
 > What do you mean by activated?
Well, they are activated in the kernel configuration by default. So 
there are several board files compiled into the kernel. I was wondering 
how the kernel will pick the correct one at boot time.
So if I choose the dtb manually, how is the kernel supposed to know 
which board file to use?
 >
 >> Why are there still board files when the specific board has already 
a device
 >> tree file?
 >
 > Because DTB defines what things are in the system and now how to operate
 > them. There still has to be some code that brings the system up for you
 > based on the board config. It's just that if you have a DTB, there's no
 > longer need to hardcode things such as CPU count, amount of RAM, flash
 > layout and so on. Off the top of my head, low level init or system reset
 > might be one of the things that end up in board specific code within the
 > kernel.
 >
 > Also, IIRC dts is mandatory for all new ARM board being added to the
 > kernel. It has not always been like this, there's still a bunch of older
 > or obscure boards that do not have a dts at all.
 >
 > --
 > Maciej Borzęcki
 > Senior Software Developer at Open-RnD Sp. z o.o., Poland
 > www.open-rnd.pl
 > mobile: +48 889 117 365, fax: +48 42 657 9079
 >
 >
 > Niniejsza wiadomość wraz z załącznikami może
 > zawierać chronione prawem lub poufne informacje i została
 > wysłana wyłącznie do wiadomości i użytku osób, do których
 > została zaadresowana. Jeśli wiadomość została otrzymana
 > przypadkowo zabrania się jej kopiowania lub rozsyłania do osób
 > trzecich. W takim przypadku uprasza się o natychmiastowe
 > zniszczenie wiadomości oraz poinformowanie nadawcy o
 > zaistniałej sytuacji za pomocą wiadomości zwrotnej.
 > Dziękujemy.
 >
 > This message, including any attachments hereto,
 > may contain privileged or confidential information and is sent
 > solely for the attention and use of the intended addressee(s).
 > If you are not an intended addressee, you may neither use this
 > message nor copy or deliver it to anyone. In such case, you
 > should immediately destroy this message and kindly notify the
 > sender by reply email. Thank you.
 >



More information about the yocto mailing list