diff options
Diffstat (limited to 'Documentation/powerpc/booting-without-of.txt')
| -rw-r--r-- | Documentation/powerpc/booting-without-of.txt | 43 |
1 files changed, 21 insertions, 22 deletions
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 5c0ba235f5a..1ccc8a515b4 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -145,7 +145,7 @@ it with special cases. in case you are entering the kernel with MMU enabled and a non-1:1 mapping. - r5 : NULL (as to differenciate with method a) + r5 : NULL (as to differentiate with method a) Note about SMP entry: Either your firmware puts your other CPUs in some sleep loop or spin loop in ROM where you can get @@ -245,7 +245,7 @@ the block to RAM before passing it to the kernel. --------- The kernel is entered with r3 pointing to an area of memory that is - roughtly described in include/asm-powerpc/prom.h by the structure + roughly described in include/asm-powerpc/prom.h by the structure boot_param_header: struct boot_param_header { @@ -335,7 +335,7 @@ struct boot_param_header { "compact" format for the tree itself that is however not backward compatible. You should always generate a structure of the highest version defined at the time of your implementation. Currently - that is version 16, unless you explicitely aim at being backward + that is version 16, unless you explicitly aim at being backward compatible. - last_comp_version @@ -418,9 +418,9 @@ zero terminated string and is mandatory for version 1 to 3 of the format definition (as it is in Open Firmware). Version 0x10 makes it optional as it can generate it from the unit name defined below. -There is also a "unit name" that is used to differenciate nodes with +There is also a "unit name" that is used to differentiate nodes with the same name at the same level, it is usually made of the node -name's, the "@" sign, and a "unit address", which definition is +names, the "@" sign, and a "unit address", which definition is specific to the bus type the node sits on. The unit name doesn't exist as a property per-se but is included in @@ -550,11 +550,11 @@ Here's the basic structure of a single node: * [child nodes if any] * token OF_DT_END_NODE (that is 0x00000002) -So the node content can be summmarised as a start token, a full path, -a list of properties, a list of child node and an end token. Every +So the node content can be summarised as a start token, a full path, +a list of properties, a list of child nodes, and an end token. Every child node is a full node structure itself as defined above. -4) Device tree 'strings" block +4) Device tree "strings" block In order to save space, property names, which are generally redundant, are stored separately in the "strings" block. This block is simply the @@ -573,7 +573,7 @@ implementation of Open Firmware or an implementation compatible with the Open Firmware client interface, those properties will be created by the trampoline code in the kernel's prom_init() file. For example, that's where you'll have to add code to detect your board model and -set the platform number. However, when using the flatenned device-tree +set the platform number. However, when using the flattened device-tree entry point, there is no prom_init() pass, and thus you have to provide those properties yourself. @@ -630,12 +630,11 @@ like address space bits, you'll have to add a bus translator to the prom_parse.c file of the recent kernels for your bus type. The "reg" property only defines addresses and sizes (if #size-cells -is -non-0) within a given bus. In order to translate addresses upward +is non-0) within a given bus. In order to translate addresses upward (that is into parent bus addresses, and possibly into cpu physical addresses), all busses must contain a "ranges" property. If the "ranges" property is missing at a given level, it's assumed that -translation isn't possible. The format of the "ranges" proprety for a +translation isn't possible. The format of the "ranges" property for a bus is a list of: bus address, parent bus address, size @@ -689,7 +688,7 @@ is present). 4) Note about node and property names and character set ------------------------------------------------------- -While open firmware provides more flexibe usage of 8859-1, this +While open firmware provides more flexible usage of 8859-1, this specification enforces more strict rules. Nodes and properties should be comprised only of ASCII characters 'a' to 'z', '0' to '9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally @@ -732,12 +731,12 @@ address which can extend beyond that limit. that typically get driven by the same platform code in the kernel, you would use a different "model" property but put a value in "compatible". The kernel doesn't directly use that - value (see /chosen/linux,platform for how the kernel choses a + value (see /chosen/linux,platform for how the kernel chooses a platform type) but it is generally useful. The root node is also generally where you add additional properties specific to your board like the serial number if any, that sort of - thing. it is recommended that if you add any "custom" property whose + thing. It is recommended that if you add any "custom" property whose name may clash with standard defined ones, you prefix them with your vendor name and a comma. @@ -817,7 +816,7 @@ address which can extend beyond that limit. your board. It's a list of addresses/sizes concatenated together, with the number of cells of each defined by the #address-cells and #size-cells of the root node. For example, - with both of these properties beeing 2 like in the example given + with both of these properties being 2 like in the example given earlier, a 970 based machine with 6Gb of RAM could typically have a "reg" property here that looks like: @@ -970,7 +969,7 @@ device-tree in another format. The currently supported formats are: - "asm": assembly language file. This is a file that can be sourced by gas to generate a device-tree "blob". That file can then simply be added to your Makefile. Additionally, the - assembly file exports some symbols that can be use + assembly file exports some symbols that can be used. The syntax of the dtc tool is @@ -984,10 +983,10 @@ generated. Supported versions are 1,2,3 and 16. The default is currently version 3 but that may change in the future to version 16. Additionally, dtc performs various sanity checks on the tree, like the -uniqueness of linux,phandle properties, validity of strings, etc... +uniqueness of linux, phandle properties, validity of strings, etc... The format of the .dts "source" file is "C" like, supports C and C++ -style commments. +style comments. / { } @@ -1069,13 +1068,13 @@ while all this has been defined and implemented. around. It contains no internal offsets or pointers for this purpose. - - An example of code for iterating nodes & retreiving properties + - An example of code for iterating nodes & retrieving properties directly from the flattened tree format can be found in the kernel file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function, - it's usage in early_init_devtree(), and the corresponding various + its usage in early_init_devtree(), and the corresponding various early_init_dt_scan_*() callbacks. That code can be re-used in a GPL bootloader, and as the author of that code, I would be happy - do discuss possible free licencing to any vendor who wishes to + to discuss possible free licencing to any vendor who wishes to integrate all or part of this code into a non-GPL bootloader. |