Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Mon, Jul 15, 2013 at 07:50:46PM +0100, Rob Herring wrote: On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote: On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote: On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. I had to ask Russell again to drop the bindings patches from the patch system, and this is not acceptable since two months have passed and the entire series was reviewed, acked and partially merged. I will review these bindings again but I would like to understand who should give the final go ahead to get these patches queued for upstreaming, I can't continue updating this stuff forever. Most of my comments are for 64-bit. So don't blame me that it had to be reverted. I said up front I was concerned about this change breaking things and it appears it did. New kernels must not require a new DT. The patches in Russell's tree do not break anything, I asked him to drop them since, if we change the bindings again, those patches change and have to be reworked. It was not meant to blame you at all, just saying that the process to get this stuff in the kernel should be defined properly and patches reviewed in a timely fashion. And for legacy reasons the situation related to cpu/cpus node bindings is a complicated one, there are bindings in the ePAPR, bindings in the kernel, people are confused and with this set we wanted to draw a line. For arm64 this is an absolute must. I disagree with you on the new kernels must not require a new DT. That's true if bindings are well defined, not for a mix of legacy ePAPR and bindings-in-the-kernel. What's the DT standard for ARM cpu/cpus node ? ePAPR ? In kernel docs ? A combination thereof ? Things are not clear cut and I do not like that, it is confusing. But yes, this should have been reviewed more quickly. We're working on a plan to help address DT binding reviews. We have not enforced that Grant and I must ack all bindings, but in this case you certainly need mine since I have reviewed it and if you want to me to pull it. Good, that's all I wanted to know, thanks. Main changes: - adds 64-bit bindings - define usage of #address-cells - define 32/64 dts compatibility settings - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) [snip] + # On ARM v8 64-bit systems, where the reg property + size can be 1 or 2 cells (as defined by cpus node's + #address-cells property), this property is + required and matches: + + - On systems running the OS in AArch32: The DTS cannot change based on 32-bit or 64-bit OS. On systems running the OS in AArch32 implies a dependency on the HW execution state. Since the DT is used to configure OSs I thought that could be a valid sentence. Unfortunately this stuff is not C, so I reiterate my point above, before changing it I would like to understand who should say the wording is ok otherwise we could argue forever. It does configure the OS, but not for 32 vs. 64 bit. That is more of a problem for the bootloader to know which mode to boot in and covered under something like Documentation/arm/Booting. Booting ARM vs. Thumb mode would be similar situation. Think about how your PC boots and add to that having a DTB as part of the firmware shipped with your PC. Then the end user can install a 32-bit or 64-bit OS on it. That is the usecase that needs to be supported and having different DTB for 32 and 64 bit is totally broken and doesn't even help solve that problem. I will give it more thought, point taken. + + - cpu-release-addr + Usage: required for systems that have an enable-method + property value of spin-table. + Value type: prop-encoded-array + Definition: + # On ARM v8 64-bit systems must be a two cell + property identifying a 64-bit zero-initialised + memory location. As I mentioned previously, isn't some wake-up method needed? Most systems will be in wfi or wfe rather than continuously spinning. Mmm...this can become a minefield, wfe, wfi, CPU in reset..this needs some thought. Yes, it is today and standardizing this is a good thing.
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Fri, Jul 12, 2013 at 09:47:17AM -0500, Rob Herring wrote: On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. Main changes: - adds 64-bit bindings - define usage of #address-cells - define 32/64 dts compatibility settings - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) [snip] + # On ARM v8 64-bit systems, where the reg property + size can be 1 or 2 cells (as defined by cpus node's + #address-cells property), this property is + required and matches: + + - On systems running the OS in AArch32: The DTS cannot change based on 32-bit or 64-bit OS. + + * If the cpus node's #address-cells value is 2: + + The first reg cell must be set to 0. + + The second reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cells must be set to 0. + + * If the cpus node's #address-cells value is 1: + + Bits [23:0] in the reg cell must be set to + bits [23:0] in MPIDR_EL1. + + All other bits in the reg cell must be 0. + + - On systems running the OS in AArch64: + + * If the cpus node's #address-cells value is 2: + + The first reg cell bits [7:0] must be set to + bits [39:32] of MPIDR_EL1. + + The second reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cells must be set to 0. + + * If the cpus node's #address-cells value is 1: + + MPIDR_EL1[63:32] is 0 on all processors in the + system. Your logic is backwards here. If the MPIDR_EL1[63:32] is 0, then #address-cells can be 1. You could say the upper bits are ignored and treated as 0. However, you should simplify all this and just mandate that #address-cells must be 2 for ARMv8 or more generally must match the size of the MPIDR. If we want to boot a 32-bit kernel, then the kernel will have to adapt to support this. I'd support this, opting for a clean split. Strictly speaking, it should be this: AArch64-capable hardware: #address-cells = 2 non-AArch64-capable hardware: #address-cells = 1 The only time it is valid to have #address-cells = 1 on AArch64-capable hardware is in an AArch32 virtual machine (in which case, the DT anyway describes the VM and not the real hardware). However, due to the awkwardness of defining precisely what AArch64- capable hardware means in a world containing firmware and hypervisors, it might be better (if slightly less correct) to go with: v8 hardware: #address-cells must be 2 =v7 hardware: #address-cells must be 1 If the firmware boots an AArch32 payload natively on AArch64-capable v8 hardware, it's the firmware's job to ensure that non-addressable CPUs are properly quiesced and shut down, otherwise the setup is pretty broken -- DT can't solve that one, nor can Linux, so we shouldn't try. Linux just needs to discard the non-addressable CPUs and maybe print out a warning. Cheers ---Dave ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On 07/16/2013 04:45 AM, Lorenzo Pieralisi wrote: On Mon, Jul 15, 2013 at 07:50:46PM +0100, Rob Herring wrote: On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote: On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote: On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. I had to ask Russell again to drop the bindings patches from the patch system, and this is not acceptable since two months have passed and the entire series was reviewed, acked and partially merged. I will review these bindings again but I would like to understand who should give the final go ahead to get these patches queued for upstreaming, I can't continue updating this stuff forever. Most of my comments are for 64-bit. So don't blame me that it had to be reverted. I said up front I was concerned about this change breaking things and it appears it did. New kernels must not require a new DT. The patches in Russell's tree do not break anything, I asked him to drop them since, if we change the bindings again, those patches change and have to be reworked. It was not meant to blame you at all, just saying that the process to get this stuff in the kernel should be defined properly and patches reviewed in a timely fashion. And for legacy reasons the situation related to cpu/cpus node bindings is a complicated one, there are bindings in the ePAPR, bindings in the kernel, people are confused and with this set we wanted to draw a line. For arm64 this is an absolute must. I disagree with you on the new kernels must not require a new DT. That's true if bindings are well defined, not for a mix of legacy ePAPR and bindings-in-the-kernel. Well defined depends on the platform. For purposes of a single cluster ARM system, the ePAPR was pretty much sufficient for cpu node description. The initial discussion was whether we even needed cpu nodes at all. We're always going to have something new that we did not account for. So even for well defined bindings, we'll have to make changes/extensions at some point. It just needs to be years, not months for changes. What's the DT standard for ARM cpu/cpus node ? ePAPR ? In kernel docs ? A combination thereof ? Things are not clear cut and I do not like that, it is confusing. ePAPR is a guideline, but in the end it is a PowerPC document. In some cases we can just use what it defines and in others we need to deviate. In an ideal world, we would create the equivalent for ARM or figure out how to merge ARM requirements with ePAPR. However, since UEFI and ACPI are going to solve all our problems, no one seems interested in defining a more formal document. To further complicate things, there is also the original OF specification to follow as well. So I would say all the docs apply and the order of priority is DT binding docs, ePAPR, OF specs. The DT binding docs need to be complete enough to avoid confusion. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote: On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. I had to ask Russell again to drop the bindings patches from the patch system, and this is not acceptable since two months have passed and the entire series was reviewed, acked and partially merged. I will review these bindings again but I would like to understand who should give the final go ahead to get these patches queued for upstreaming, I can't continue updating this stuff forever. Main changes: - adds 64-bit bindings - define usage of #address-cells - define 32/64 dts compatibility settings - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) [snip] + # On ARM v8 64-bit systems, where the reg property + size can be 1 or 2 cells (as defined by cpus node's + #address-cells property), this property is + required and matches: + + - On systems running the OS in AArch32: The DTS cannot change based on 32-bit or 64-bit OS. On systems running the OS in AArch32 implies a dependency on the HW execution state. Since the DT is used to configure OSs I thought that could be a valid sentence. Unfortunately this stuff is not C, so I reiterate my point above, before changing it I would like to understand who should say the wording is ok otherwise we could argue forever. + + * If the cpus node's #address-cells value is 2: + + The first reg cell must be set to 0. + + The second reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cells must be set to 0. + + * If the cpus node's #address-cells value is 1: + + Bits [23:0] in the reg cell must be set to + bits [23:0] in MPIDR_EL1. + + All other bits in the reg cell must be 0. + + - On systems running the OS in AArch64: + + * If the cpus node's #address-cells value is 2: + + The first reg cell bits [7:0] must be set to + bits [39:32] of MPIDR_EL1. + + The second reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cells must be set to 0. + + * If the cpus node's #address-cells value is 1: + + MPIDR_EL1[63:32] is 0 on all processors in the + system. Your logic is backwards here. If the MPIDR_EL1[63:32] is 0, then #address-cells can be 1. You could say the upper bits are ignored and treated as 0. However, you should simplify all this and just mandate that #address-cells must be 2 for ARMv8 or more generally must match the size of the MPIDR. If we want to boot a 32-bit kernel, then the kernel will have to adapt to support this. Fair enough I will see how I can reword it. + + The reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cell must be set to 0. + + - compatible: + Usage: required + Value type: string + Definition: should be one of: + arm,arm710t + arm,arm720t + arm,arm740t + arm,arm7ej-s + arm,arm7tdmi + arm,arm7tdmi-s + arm,arm9es + arm,arm9ej-s + arm,arm920t + arm,arm922t + arm,arm925 + arm,arm926e-s + arm,arm926ej-s + arm,arm940t + arm,arm946e-s + arm,arm966e-s +
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote: On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote: On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. I had to ask Russell again to drop the bindings patches from the patch system, and this is not acceptable since two months have passed and the entire series was reviewed, acked and partially merged. I will review these bindings again but I would like to understand who should give the final go ahead to get these patches queued for upstreaming, I can't continue updating this stuff forever. Most of my comments are for 64-bit. So don't blame me that it had to be reverted. I said up front I was concerned about this change breaking things and it appears it did. New kernels must not require a new DT. But yes, this should have been reviewed more quickly. We're working on a plan to help address DT binding reviews. We have not enforced that Grant and I must ack all bindings, but in this case you certainly need mine since I have reviewed it and if you want to me to pull it. Main changes: - adds 64-bit bindings - define usage of #address-cells - define 32/64 dts compatibility settings - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) [snip] + # On ARM v8 64-bit systems, where the reg property + size can be 1 or 2 cells (as defined by cpus node's + #address-cells property), this property is + required and matches: + + - On systems running the OS in AArch32: The DTS cannot change based on 32-bit or 64-bit OS. On systems running the OS in AArch32 implies a dependency on the HW execution state. Since the DT is used to configure OSs I thought that could be a valid sentence. Unfortunately this stuff is not C, so I reiterate my point above, before changing it I would like to understand who should say the wording is ok otherwise we could argue forever. It does configure the OS, but not for 32 vs. 64 bit. That is more of a problem for the bootloader to know which mode to boot in and covered under something like Documentation/arm/Booting. Booting ARM vs. Thumb mode would be similar situation. Think about how your PC boots and add to that having a DTB as part of the firmware shipped with your PC. Then the end user can install a 32-bit or 64-bit OS on it. That is the usecase that needs to be supported and having different DTB for 32 and 64 bit is totally broken and doesn't even help solve that problem. + + - cpu-release-addr + Usage: required for systems that have an enable-method + property value of spin-table. + Value type: prop-encoded-array + Definition: + # On ARM v8 64-bit systems must be a two cell + property identifying a 64-bit zero-initialised + memory location. As I mentioned previously, isn't some wake-up method needed? Most systems will be in wfi or wfe rather than continuously spinning. Mmm...this can become a minefield, wfe, wfi, CPU in reset..this needs some thought. Yes, it is today and standardizing this is a good thing. Which is what PSCI does. So why are you adding the spintable at all? Are you trying to set this as the standard for non-PSCI enabled platforms? Why not just say v8 boot interface is PSCI. Sure, we'll probably have to deal with other methods, but documenting something else here is not going to prevent that problem. I don't think a simple spintable would even work for any/most current platforms. I'd think we'd want to define something that would work for existing platforms (chances are new platforms will work like vendors' existing 32-bit platforms). Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Sorry for the long delay on this, but I'm still not happy with the binding here. Main changes: - adds 64-bit bindings - define usage of #address-cells - define 32/64 dts compatibility settings - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) [snip] + # On ARM v8 64-bit systems, where the reg property + size can be 1 or 2 cells (as defined by cpus node's + #address-cells property), this property is + required and matches: + + - On systems running the OS in AArch32: The DTS cannot change based on 32-bit or 64-bit OS. + + * If the cpus node's #address-cells value is 2: + + The first reg cell must be set to 0. + + The second reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cells must be set to 0. + + * If the cpus node's #address-cells value is 1: + + Bits [23:0] in the reg cell must be set to + bits [23:0] in MPIDR_EL1. + + All other bits in the reg cell must be 0. + + - On systems running the OS in AArch64: + + * If the cpus node's #address-cells value is 2: + + The first reg cell bits [7:0] must be set to + bits [39:32] of MPIDR_EL1. + + The second reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cells must be set to 0. + + * If the cpus node's #address-cells value is 1: + + MPIDR_EL1[63:32] is 0 on all processors in the + system. Your logic is backwards here. If the MPIDR_EL1[63:32] is 0, then #address-cells can be 1. You could say the upper bits are ignored and treated as 0. However, you should simplify all this and just mandate that #address-cells must be 2 for ARMv8 or more generally must match the size of the MPIDR. If we want to boot a 32-bit kernel, then the kernel will have to adapt to support this. + + The reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + All other bits in the reg cell must be set to 0. + + - compatible: + Usage: required + Value type: string + Definition: should be one of: + arm,arm710t + arm,arm720t + arm,arm740t + arm,arm7ej-s + arm,arm7tdmi + arm,arm7tdmi-s + arm,arm9es + arm,arm9ej-s + arm,arm920t + arm,arm922t + arm,arm925 + arm,arm926e-s + arm,arm926ej-s + arm,arm940t + arm,arm946e-s + arm,arm966e-s + arm,arm968e-s + arm,arm9tdmi + arm,arm1020e + arm,arm1020t + arm,arm1022e + arm,arm1026ej-s + arm,arm1136j-s + arm,arm1136jf-s + arm,arm1156t2-s + arm,arm1156t2f-s + arm,arm1176jzf + arm,arm1176jz-s + arm,arm1176jzf-s + arm,arm11mpcore + arm,cortex-a5 + arm,cortex-a7 + arm,cortex-a8 + arm,cortex-a9 + arm,cortex-a15 + arm,cortex-a53 + arm,cortex-a57 + arm,cortex-m0 +
Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates
On Fri, 17 May 2013, Lorenzo Pieralisi wrote: In order to extend the current cpu nodes bindings to newer CPUs inclusive of AArch64 and to update support for older ARM CPUs this patch updates device tree documentation for the cpu nodes bindings. Main changes: - adds 64-bit bindings - define usage of #address-cells - define 32/64 dts compatibility settings - defines behaviour on pre and post v7 uniprocessor systems - adds ARM 11MPcore specific reg property definition Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com Acked-by: Nicolas Pitre n...@linaro.org --- Documentation/devicetree/bindings/arm/cpus.txt | 459 ++--- 1 file changed, 412 insertions(+), 47 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index f32494d..3fc0c11 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -1,77 +1,442 @@ -* ARM CPUs binding description += +ARM CPUs bindings += The device tree allows to describe the layout of CPUs in a system through the cpus node, which in turn contains a number of subnodes (ie cpu) defining properties for every cpu. -Bindings for CPU nodes follow the ePAPR standard, available from: - -http://devicetree.org - -For the ARM architecture every CPU node must contain the following properties: - -- device_type: must be cpu -- reg: property matching the CPU MPIDR[23:0] register bits - reg[31:24] bits must be set to 0 -- compatible:should be one of: - arm,arm1020 - arm,arm1020e - arm,arm1022 - arm,arm1026 - arm,arm720 - arm,arm740 - arm,arm7tdmi - arm,arm920 - arm,arm922 - arm,arm925 - arm,arm926 - arm,arm940 - arm,arm946 - arm,arm9tdmi - arm,cortex-a5 - arm,cortex-a7 - arm,cortex-a8 - arm,cortex-a9 - arm,cortex-a15 - arm,arm1136 - arm,arm1156 - arm,arm1176 - arm,arm11mpcore - faraday,fa526 - intel,sa110 - intel,sa1100 - marvell,feroceon - marvell,mohawk - marvell,xsc3 - marvell,xscale - -Example: +Bindings for CPU nodes follow the ePAPR v1.1 standard, available from: + +https://www.power.org/documentation/epapr-version-1-1/ + +with updates for 32-bit and 64-bit ARM systems provided in this document. + + +Convention used in this document + + +This document follows the conventions described in the ePAPR v1.1, with +the addition: + +- square brackets define bitfields, eg reg[7:0] value of the bitfield in + the reg property contained in bits 7 down to 0 + += +cpus and cpu node bindings definition += + +The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu +nodes to be present and contain the properties described below. + +- cpus node + + Description: Container of cpu nodes + + The node name must be cpus. + + A cpus node must define the following properties: + + - #address-cells + Usage: required + Value type: u32 + + Definition depends on ARM architecture version and + configuration: + + # On uniprocessor ARM architectures previous to v7 + value must be 0. + # On 32-bit ARM 11 MPcore, ARM v7 or later systems + value must be 1. + # On ARM v8 64-bit systems value must be set to 1 + or 2. Refer to the cpu node's reg property + description for allowed configurations. + + - #size-cells + Usage: required + Value type: u32 + Definition: must be set to 0 + +- cpu node + + Description: Describes a CPU in an ARM based system + + PROPERTIES + + - device_type + Usage: required + Value type: string + Definition: must be cpu + - reg + Usage and definition depend on ARM architecture version and + configuration: + + # On uniprocessor ARM architectures previous to v7 + this property is optional since they do not define + any register that provides a CPU identifier. + Any value set in the reg property for these CPUs + should be ignored. + + # On ARM 11
