User: Password:
|
|
Subscribe / Log in / New account

Platform devices and device trees

Platform devices and device trees

Posted Jun 23, 2011 15:14 UTC (Thu) by krisis (guest, #70792)
In reply to: Platform devices and device trees by etienne
Parent article: Platform devices and device trees

I'm not entirely familiar with device trees, so don't take anything I say as gospel, but I believe there is a binary format for device trees that is compiled from the traditional device tree, that the kernel can also take.


(Log in to post comments)

Platform devices and device trees

Posted Jun 23, 2011 19:33 UTC (Thu) by glikely (subscriber, #39601) [Link]

The kernel only accepts the tokenized (dtb) from produced by the device tree compiler. The textual source form (dts) is designed to be editable by mere mortals.

Platform devices and device trees

Posted Jun 23, 2011 22:07 UTC (Thu) by krisis (guest, #70792) [Link]

Continuing the subject of me not knowing enough about device trees, Now that there is a knowledgeable person present, I might as well ask :)

I work on an embedded platform with a DM9000 ethernet controller. This particular controller can either get its MAC address from an attached EEPROM or it can be set via the platform_data mechanism. As a cost saving measure, there is no EEPROM attached to the controller on this board, so in order to get a MAC address, we pull the die ID from the CPU during boot and use that to initialize the MAC address in the device struct before we pass it to the driver core.

Is there a mechanism to enable these sort of hacks with device trees and if so, how?

Platform devices and device trees

Posted Jun 23, 2011 22:11 UTC (Thu) by glikely (subscriber, #39601) [Link]

In the device tree node for the MAC, add a "local-mac-address" property containing the desired MAC address. The DM9000 driver can be easily modified to obtain this value at .probe time by calling of_get_mac_address().

Platform devices and device trees

Posted Jun 23, 2011 22:28 UTC (Thu) by krisis (guest, #70792) [Link]

Wouldn't that just set the MAC address to a fixed value for all of my boards?

The hack is that I'm getting a unique MAC address for each of the boards by using the unique-per-cpu die ID, which I pull during board setup.

(The code for this hack is in arch/arm/mach-omap2/board-devkit8000.c if anyone wants to have a look. It's the omap_dm9000_init function)

Platform devices and device trees

Posted Jun 23, 2011 22:37 UTC (Thu) by glikely (subscriber, #39601) [Link]

Wouldn't that just set the MAC address to a fixed value for all of my boards? The hack is that I'm getting a unique MAC address for each of the boards by using the unique-per-cpu die ID, which I pull during board setup.

The model pretty much assumes that the DT data is complete and accurate by the time it is passed to the kernel. If you need to do machine-specific hacks, there is little recourse but but to have machine specific setup code. DT doesn't change the situation in that regard. If really necessary, there is a way to attach supplemental platform_data to devices registered from the DT, but it is discouraged.

However, the DT can be dynamically modified to squirt in the mac address either by the boot loader (U-Boot) or when the .dtb is installed on the board. You don't need to have a separate .dts for each board with a different MAC address.

(The code for this hack is in arch/arm/mach-omap2/board-devkit8000.c if anyone wants to have a look. It's the omap_dm9000_init function)
Nice. I have a devkit8000, but I could never get a modern kernel to boot on the thing.

Platform devices and device trees

Posted Jun 24, 2011 0:28 UTC (Fri) by dlang (subscriber, #313) [Link]

this is a common enough issue that it may be worth defining a 'magic' MAC address (all 0's??) and if you see that going through a list of steps to create a MAC address (ending with generate something random). Ideally each step on this list could fail cleanly so all such checks could be gathered into one 'I have no real MAC address, generate one' routine.

Platform devices and device trees

Posted Jun 24, 2011 18:47 UTC (Fri) by broonie (subscriber, #7078) [Link]

It's extremely common and the kernel is already doing stuff to handle the case where it can't get a MAC address at all. The issue here is not that there's no MAC address, it's that the MAC is being shipped in a non-standard location (eg, a bootloader variable) and we need a way to hand that value to the chip. Once the kernel has the data there's not much problem.

Platform devices and device trees

Posted Jun 24, 2011 22:17 UTC (Fri) by dlang (subscriber, #313) [Link]

in reading the post, it sounded to me like he had special code in the driver so that if there was no eeprom with the MAC address, he would generate it from the cpuid.

yes, it would be nice for the code to look in the device tree to see if there is a MAC address provided.

but if there isn't, he shouldn't have special case code in that one driver to calculate the MAC, he should call the general case code to handle the case where there is no MAC (and come to think of it, that general case code should probably be what is taught to look in the device tree for the MAC)

Platform devices and device trees

Posted Jun 24, 2011 11:13 UTC (Fri) by etienne (guest, #25256) [Link]

I have to admit that my comment was not knowledgeable enough, my device tree memory from the PPC world is already old, and I am currently bothered by this ARM demo board refusing to boot (i.e. display the first line) of a Linux kernel compiled from the kernel.org tree.
Last time it happened in the PPC world was when the device tree file was not correctly loaded in memory or loaded to the wrong RAM address/from the wrong FLASH address or corrupted.
I have read here on LVN about a patch to insert the device tree in the kernel file, so that would sort out this kind of problem.
I am still puzzled by the fact that the ARM processor I am using is completely defined, all its device address are fixed - up to the point that I have a CPU choice in the kernel menuconfig (CONFIG_ARCH_TI816X=y), yet the future would be a kernel file with variable device addresses to be resolved at run time from another file. (resolving at link time would be fine)
Now I shut up, my current problem is obviously not device tree - I have to look again at u-boot config.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds