Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Thu, Sep 13, 2012 at 04:56:11PM +0100, Christopher Covington wrote: > On 09/12/2012 09:49 AM, Catalin Marinas wrote: > > On Wed, Sep 12, 2012 at 01:08:58PM +0100, Jean-Christophe PLAGNIOL-VILLARD > > wrote: > >> On 17:11 Mon 10 Sep , Catalin Marinas wrote: > >>> On Sun, Sep 09, 2012 at 06:20:46PM +0100, Jean-Christophe > >>> PLAGNIOL-VILLARD wrote: > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > +Before jumping into the kernel, the following conditions must be met: > > + > > +- Quiesce all DMA capable devices so that memory does not get > > + corrupted by bogus network packets or disk data. This will save > > + you many hours of debug. > > + > > +- Primary CPU general-purpose register settings > > + x0 = physical address of device tree blob (dtb) in system RAM. > > + x1 = 0 (reserved for future use) > > + x2 = 0 (reserved for future use) > > + x3 = 0 (reserved for future use) > > + > > +- CPU mode > > + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, > > + IRQ and FIQ). > > + The CPU must be in either EL2 (RECOMMENDED in order to have access to > > + the virtualisation extensions) or non-secure EL1. > > + > > +- Caches, MMUs > > + The MMU must be off. > > + Instruction cache may be on or off. > > + Data cache must be off and invalidated. > > + External caches (if present) must be configured and disabled. > > + > > +- Architected timers > > + CNTFRQ must be programmed with the timer frequency. > > + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) > > + set where available. > can you explain why? > >>> > >>> Otherwise the kernel cannot access the generic timer registers (it is > >>> described in the AArch64 exception model which isn't public yet). > >> I do not like the idea to do too much in the boot loader > > I agree that where possible we should minimize the amount of work required of > bootloaders. I'm not sure that the percentage of work we might be able to trim > away on hardware would be significant, but on simulators I think we might be > able to get to the point where, if you can specify the r0 reset value to be > the dtb pointer, you can just load a devicetree blob and kernel image into > memory and start executing the kernel, no boot wrapper required. The boot wrapper is *only* required on our software model because this model does not have any firmware and it simply starts at EL3. We do not have this behaviour on real hardware where there is firmware to initialise the hardware, memory controller, secure world etc. before a normal boot loader can be loaded. Many of the requirements would be part of the board firmware rather than boot loader, so the boot loader would just need to deal with the usual cache maintenance and turning the MMU off. The conditions above are not really much in addition to what we require on 32-bit. > I don't know if Jean-Christophe was commenting on just the EL1PCTEN bit or The EL1PCTEN requirement is pretty clearly described above - only if Linux is started at EL1 (e.g. guest OS), since the CNTHCTL_EL2 register is an EL2 only register and not accessible at EL1. > also the CNTFRQ register, but with regard to the latter, it appears to me that > the timer code actually reads the frequency primarily from the devicetree and > only reads CNTFRQ if the "clock-frequency" property is unspecified or > specified as zero. Linus W has a few more suggestions here but I didn't get to implementing them. > I suggest that the kernel calling requirements be modified to communicate this > fallback, rather than mandatory, status, unless some not-yet-released part of > the arm64 kernel needs it. If userspace code will need to use CNTFRQ at some > point then perhaps that should be mentioned in an informational note rather > than being presented as a kernel booting requirement. In general, we would like the firmware to write the correct value into the CNTFRQ register, as specified in the generic timers spec, or maybe hard-wire the register to the correct value. However, in case some firmware gets it wrong or a read-only register is not hard-wired we want to override the value with the FDT. A historical reason for this was that the software model we use doesn't have any firmware. But primarily we should use the hardware value. So far we don't export the CNTFRQ to user because of the possibility to override the value via other means. That's pretty much a read-only or EL3 writable only register. > > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git > > The UART and GIC stuff is board-specific, and I don't currently have any > suggestions about the multicore initialization, but would you object to the > kernel eventually being equipped to make the descent from EL3 itself? I'm strongly pushing for single Image support from the beginning and this would require a
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
Hi Catalin and Will, On 09/12/2012 09:49 AM, Catalin Marinas wrote: > On Wed, Sep 12, 2012 at 01:08:58PM +0100, Jean-Christophe PLAGNIOL-VILLARD > wrote: >> On 17:11 Mon 10 Sep , Catalin Marinas wrote: >>> On Sun, Sep 09, 2012 at 06:20:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD >>> wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: > +Before jumping into the kernel, the following conditions must be met: > + > +- Quiesce all DMA capable devices so that memory does not get > + corrupted by bogus network packets or disk data. This will save > + you many hours of debug. > + > +- Primary CPU general-purpose register settings > + x0 = physical address of device tree blob (dtb) in system RAM. > + x1 = 0 (reserved for future use) > + x2 = 0 (reserved for future use) > + x3 = 0 (reserved for future use) > + > +- CPU mode > + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, > + IRQ and FIQ). > + The CPU must be in either EL2 (RECOMMENDED in order to have access to > + the virtualisation extensions) or non-secure EL1. > + > +- Caches, MMUs > + The MMU must be off. > + Instruction cache may be on or off. > + Data cache must be off and invalidated. > + External caches (if present) must be configured and disabled. > + > +- Architected timers > + CNTFRQ must be programmed with the timer frequency. > + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) > + set where available. can you explain why? >>> >>> Otherwise the kernel cannot access the generic timer registers (it is >>> described in the AArch64 exception model which isn't public yet). >> I do not like the idea to do too much in the boot loader I agree that where possible we should minimize the amount of work required of bootloaders. I'm not sure that the percentage of work we might be able to trim away on hardware would be significant, but on simulators I think we might be able to get to the point where, if you can specify the r0 reset value to be the dtb pointer, you can just load a devicetree blob and kernel image into memory and start executing the kernel, no boot wrapper required. I don't know if Jean-Christophe was commenting on just the EL1PCTEN bit or also the CNTFRQ register, but with regard to the latter, it appears to me that the timer code actually reads the frequency primarily from the devicetree and only reads CNTFRQ if the "clock-frequency" property is unspecified or specified as zero. I suggest that the kernel calling requirements be modified to communicate this fallback, rather than mandatory, status, unless some not-yet-released part of the arm64 kernel needs it. If userspace code will need to use CNTFRQ at some point then perhaps that should be mentioned in an informational note rather than being presented as a kernel booting requirement. > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git The UART and GIC stuff is board-specific, and I don't currently have any suggestions about the multicore initialization, but would you object to the kernel eventually being equipped to make the descent from EL3 itself? Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
Hi Catalin and Will, On 09/12/2012 09:49 AM, Catalin Marinas wrote: On Wed, Sep 12, 2012 at 01:08:58PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:11 Mon 10 Sep , Catalin Marinas wrote: On Sun, Sep 09, 2012 at 06:20:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +Before jumping into the kernel, the following conditions must be met: + +- Quiesce all DMA capable devices so that memory does not get + corrupted by bogus network packets or disk data. This will save + you many hours of debug. + +- Primary CPU general-purpose register settings + x0 = physical address of device tree blob (dtb) in system RAM. + x1 = 0 (reserved for future use) + x2 = 0 (reserved for future use) + x3 = 0 (reserved for future use) + +- CPU mode + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, + IRQ and FIQ). + The CPU must be in either EL2 (RECOMMENDED in order to have access to + the virtualisation extensions) or non-secure EL1. + +- Caches, MMUs + The MMU must be off. + Instruction cache may be on or off. + Data cache must be off and invalidated. + External caches (if present) must be configured and disabled. + +- Architected timers + CNTFRQ must be programmed with the timer frequency. + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) + set where available. can you explain why? Otherwise the kernel cannot access the generic timer registers (it is described in the AArch64 exception model which isn't public yet). I do not like the idea to do too much in the boot loader I agree that where possible we should minimize the amount of work required of bootloaders. I'm not sure that the percentage of work we might be able to trim away on hardware would be significant, but on simulators I think we might be able to get to the point where, if you can specify the r0 reset value to be the dtb pointer, you can just load a devicetree blob and kernel image into memory and start executing the kernel, no boot wrapper required. I don't know if Jean-Christophe was commenting on just the EL1PCTEN bit or also the CNTFRQ register, but with regard to the latter, it appears to me that the timer code actually reads the frequency primarily from the devicetree and only reads CNTFRQ if the clock-frequency property is unspecified or specified as zero. I suggest that the kernel calling requirements be modified to communicate this fallback, rather than mandatory, status, unless some not-yet-released part of the arm64 kernel needs it. If userspace code will need to use CNTFRQ at some point then perhaps that should be mentioned in an informational note rather than being presented as a kernel booting requirement. git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git The UART and GIC stuff is board-specific, and I don't currently have any suggestions about the multicore initialization, but would you object to the kernel eventually being equipped to make the descent from EL3 itself? Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Thu, Sep 13, 2012 at 04:56:11PM +0100, Christopher Covington wrote: On 09/12/2012 09:49 AM, Catalin Marinas wrote: On Wed, Sep 12, 2012 at 01:08:58PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:11 Mon 10 Sep , Catalin Marinas wrote: On Sun, Sep 09, 2012 at 06:20:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +Before jumping into the kernel, the following conditions must be met: + +- Quiesce all DMA capable devices so that memory does not get + corrupted by bogus network packets or disk data. This will save + you many hours of debug. + +- Primary CPU general-purpose register settings + x0 = physical address of device tree blob (dtb) in system RAM. + x1 = 0 (reserved for future use) + x2 = 0 (reserved for future use) + x3 = 0 (reserved for future use) + +- CPU mode + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, + IRQ and FIQ). + The CPU must be in either EL2 (RECOMMENDED in order to have access to + the virtualisation extensions) or non-secure EL1. + +- Caches, MMUs + The MMU must be off. + Instruction cache may be on or off. + Data cache must be off and invalidated. + External caches (if present) must be configured and disabled. + +- Architected timers + CNTFRQ must be programmed with the timer frequency. + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) + set where available. can you explain why? Otherwise the kernel cannot access the generic timer registers (it is described in the AArch64 exception model which isn't public yet). I do not like the idea to do too much in the boot loader I agree that where possible we should minimize the amount of work required of bootloaders. I'm not sure that the percentage of work we might be able to trim away on hardware would be significant, but on simulators I think we might be able to get to the point where, if you can specify the r0 reset value to be the dtb pointer, you can just load a devicetree blob and kernel image into memory and start executing the kernel, no boot wrapper required. The boot wrapper is *only* required on our software model because this model does not have any firmware and it simply starts at EL3. We do not have this behaviour on real hardware where there is firmware to initialise the hardware, memory controller, secure world etc. before a normal boot loader can be loaded. Many of the requirements would be part of the board firmware rather than boot loader, so the boot loader would just need to deal with the usual cache maintenance and turning the MMU off. The conditions above are not really much in addition to what we require on 32-bit. I don't know if Jean-Christophe was commenting on just the EL1PCTEN bit or The EL1PCTEN requirement is pretty clearly described above - only if Linux is started at EL1 (e.g. guest OS), since the CNTHCTL_EL2 register is an EL2 only register and not accessible at EL1. also the CNTFRQ register, but with regard to the latter, it appears to me that the timer code actually reads the frequency primarily from the devicetree and only reads CNTFRQ if the clock-frequency property is unspecified or specified as zero. Linus W has a few more suggestions here but I didn't get to implementing them. I suggest that the kernel calling requirements be modified to communicate this fallback, rather than mandatory, status, unless some not-yet-released part of the arm64 kernel needs it. If userspace code will need to use CNTFRQ at some point then perhaps that should be mentioned in an informational note rather than being presented as a kernel booting requirement. In general, we would like the firmware to write the correct value into the CNTFRQ register, as specified in the generic timers spec, or maybe hard-wire the register to the correct value. However, in case some firmware gets it wrong or a read-only register is not hard-wired we want to override the value with the FDT. A historical reason for this was that the software model we use doesn't have any firmware. But primarily we should use the hardware value. So far we don't export the CNTFRQ to user because of the possibility to override the value via other means. That's pretty much a read-only or EL3 writable only register. git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git The UART and GIC stuff is board-specific, and I don't currently have any suggestions about the multicore initialization, but would you object to the kernel eventually being equipped to make the descent from EL3 itself? I'm strongly pushing for single Image support from the beginning and this would require a few things to be initialised by the firmware (on a case by case basis). The secondary CPU release also needs to be handled by the firmware. For example, in a standard system you would want to run the kernel in non-secure mode to
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Wed, Sep 12, 2012 at 01:08:58PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 17:11 Mon 10 Sep , Catalin Marinas wrote: > > On Sun, Sep 09, 2012 at 06:20:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD > > wrote: > > > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > > > +Before jumping into the kernel, the following conditions must be met: > > > > + > > > > +- Quiesce all DMA capable devices so that memory does not get > > > > + corrupted by bogus network packets or disk data. This will save > > > > + you many hours of debug. > > > > + > > > > +- Primary CPU general-purpose register settings > > > > + x0 = physical address of device tree blob (dtb) in system RAM. > > > > + x1 = 0 (reserved for future use) > > > > + x2 = 0 (reserved for future use) > > > > + x3 = 0 (reserved for future use) > > > > + > > > > +- CPU mode > > > > + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, > > > > + IRQ and FIQ). > > > > + The CPU must be in either EL2 (RECOMMENDED in order to have access to > > > > + the virtualisation extensions) or non-secure EL1. > > > > + > > > > +- Caches, MMUs > > > > + The MMU must be off. > > > > + Instruction cache may be on or off. > > > > + Data cache must be off and invalidated. > > > > + External caches (if present) must be configured and disabled. > > > > + > > > > +- Architected timers > > > > + CNTFRQ must be programmed with the timer frequency. > > > > + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) > > > > + set where available. > > > can you explain why? > > > > Otherwise the kernel cannot access the generic timer registers (it is > > described in the AArch64 exception model which isn't public yet). > I do not like the idea to do too much in the boot loader > > can we drop it and do it the head.S or find an other way No. The kernel expects some sane setup before it can start. That's the case already on AArch32. With AArch64 we also mandate single Image from start. You can have a look at an example boot wrapper that creates an environment for the AArch64 kernel: git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git > > > > +- The primary CPU must jump directly to the first instruction of the > > > > + kernel image. The device tree blob passed by this CPU must contain > > > > + for each CPU node: > > > > + > > > > +1. An 'enable-method' property. Currently, the only supported value > > > > + for this field is the string "spin-table". > > > > + > > > > +2. A 'cpu-release-addr' property identifying a 64-bit, > > > > + zero-initialised memory location. > > > > + > > > > + It is expected that the bootloader will generate these device tree > > > > + properties and insert them into the blob prior to kernel entry. > > > > + > > > > +- Any secondary CPUs must spin outside of the kernel in a reserved area > > > > + of memory (communicated to the kernel by a /memreserve/ region in the > > > > + device tree) polling their cpu-release-addr location, which must be > > > > + contained in the reserved region. A wfe instruction may be inserted > > > > + to reduce the overhead of the busy-loop and a sev will be issued by > > > > + the primary CPU. When a read of the location pointed to by the > > > > + cpu-release-addr returns a non-zero value, the CPU must jump directly > > > > + to this value. > > > do you plan AMP boot? > > > > What do you mean by AMP? > > > > If you only want to use 3 CPUs out of 4 for example, you change the FDT > > information that gets passed to the kernel accordingly. So the kernel > > wouldn't touch the 4th one. > I mean boot a different kernel in each core as example That's not on my plan. It may be doable but I don't see any need for it. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On 17:11 Mon 10 Sep , Catalin Marinas wrote: > On Sun, Sep 09, 2012 at 06:20:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD > wrote: > > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > > +The device tree blob (dtb) must be no bigger than 2 megabytes in size > > > +and placed at a 2-megabyte boundary within the first 512 megabytes from > > > +the start of the kernel image. This is to allow the kernel to map the > > > +blob using a single section mapping in the initial page tables. > > why do you want to restrict the DT to be less tahn 2MiB? > > That's a restriction due on the initial memory map. At some point we may > add support in head.S to parse the dtb and extract the size information. > Not critical at this stage. > > > > +Before jumping into the kernel, the following conditions must be met: > > > + > > > +- Quiesce all DMA capable devices so that memory does not get > > > + corrupted by bogus network packets or disk data. This will save > > > + you many hours of debug. > > > + > > > +- Primary CPU general-purpose register settings > > > + x0 = physical address of device tree blob (dtb) in system RAM. > > > + x1 = 0 (reserved for future use) > > > + x2 = 0 (reserved for future use) > > > + x3 = 0 (reserved for future use) > > > + > > > +- CPU mode > > > + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, > > > + IRQ and FIQ). > > > + The CPU must be in either EL2 (RECOMMENDED in order to have access to > > > + the virtualisation extensions) or non-secure EL1. > > > + > > > +- Caches, MMUs > > > + The MMU must be off. > > > + Instruction cache may be on or off. > > > + Data cache must be off and invalidated. > > > + External caches (if present) must be configured and disabled. > > > + > > > +- Architected timers > > > + CNTFRQ must be programmed with the timer frequency. > > > + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) > > > + set where available. > > can you explain why? > > Otherwise the kernel cannot access the generic timer registers (it is > described in the AArch64 exception model which isn't public yet). I do not like the idea to do too much in the boot loader can we drop it and do it the head.S or find an other way > > > > +- The primary CPU must jump directly to the first instruction of the > > > + kernel image. The device tree blob passed by this CPU must contain > > > + for each CPU node: > > > + > > > +1. An 'enable-method' property. Currently, the only supported value > > > + for this field is the string "spin-table". > > > + > > > +2. A 'cpu-release-addr' property identifying a 64-bit, > > > + zero-initialised memory location. > > > + > > > + It is expected that the bootloader will generate these device tree > > > + properties and insert them into the blob prior to kernel entry. > > > + > > > +- Any secondary CPUs must spin outside of the kernel in a reserved area > > > + of memory (communicated to the kernel by a /memreserve/ region in the > > > + device tree) polling their cpu-release-addr location, which must be > > > + contained in the reserved region. A wfe instruction may be inserted > > > + to reduce the overhead of the busy-loop and a sev will be issued by > > > + the primary CPU. When a read of the location pointed to by the > > > + cpu-release-addr returns a non-zero value, the CPU must jump directly > > > + to this value. > > do you plan AMP boot? > > What do you mean by AMP? > > If you only want to use 3 CPUs out of 4 for example, you change the FDT > information that gets passed to the kernel accordingly. So the kernel > wouldn't touch the 4th one. I mean boot a different kernel in each core as example Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On 17:11 Mon 10 Sep , Catalin Marinas wrote: On Sun, Sep 09, 2012 at 06:20:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +The device tree blob (dtb) must be no bigger than 2 megabytes in size +and placed at a 2-megabyte boundary within the first 512 megabytes from +the start of the kernel image. This is to allow the kernel to map the +blob using a single section mapping in the initial page tables. why do you want to restrict the DT to be less tahn 2MiB? That's a restriction due on the initial memory map. At some point we may add support in head.S to parse the dtb and extract the size information. Not critical at this stage. +Before jumping into the kernel, the following conditions must be met: + +- Quiesce all DMA capable devices so that memory does not get + corrupted by bogus network packets or disk data. This will save + you many hours of debug. + +- Primary CPU general-purpose register settings + x0 = physical address of device tree blob (dtb) in system RAM. + x1 = 0 (reserved for future use) + x2 = 0 (reserved for future use) + x3 = 0 (reserved for future use) + +- CPU mode + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, + IRQ and FIQ). + The CPU must be in either EL2 (RECOMMENDED in order to have access to + the virtualisation extensions) or non-secure EL1. + +- Caches, MMUs + The MMU must be off. + Instruction cache may be on or off. + Data cache must be off and invalidated. + External caches (if present) must be configured and disabled. + +- Architected timers + CNTFRQ must be programmed with the timer frequency. + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) + set where available. can you explain why? Otherwise the kernel cannot access the generic timer registers (it is described in the AArch64 exception model which isn't public yet). I do not like the idea to do too much in the boot loader can we drop it and do it the head.S or find an other way +- The primary CPU must jump directly to the first instruction of the + kernel image. The device tree blob passed by this CPU must contain + for each CPU node: + +1. An 'enable-method' property. Currently, the only supported value + for this field is the string spin-table. + +2. A 'cpu-release-addr' property identifying a 64-bit, + zero-initialised memory location. + + It is expected that the bootloader will generate these device tree + properties and insert them into the blob prior to kernel entry. + +- Any secondary CPUs must spin outside of the kernel in a reserved area + of memory (communicated to the kernel by a /memreserve/ region in the + device tree) polling their cpu-release-addr location, which must be + contained in the reserved region. A wfe instruction may be inserted + to reduce the overhead of the busy-loop and a sev will be issued by + the primary CPU. When a read of the location pointed to by the + cpu-release-addr returns a non-zero value, the CPU must jump directly + to this value. do you plan AMP boot? What do you mean by AMP? If you only want to use 3 CPUs out of 4 for example, you change the FDT information that gets passed to the kernel accordingly. So the kernel wouldn't touch the 4th one. I mean boot a different kernel in each core as example Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Wed, Sep 12, 2012 at 01:08:58PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:11 Mon 10 Sep , Catalin Marinas wrote: On Sun, Sep 09, 2012 at 06:20:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +Before jumping into the kernel, the following conditions must be met: + +- Quiesce all DMA capable devices so that memory does not get + corrupted by bogus network packets or disk data. This will save + you many hours of debug. + +- Primary CPU general-purpose register settings + x0 = physical address of device tree blob (dtb) in system RAM. + x1 = 0 (reserved for future use) + x2 = 0 (reserved for future use) + x3 = 0 (reserved for future use) + +- CPU mode + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, + IRQ and FIQ). + The CPU must be in either EL2 (RECOMMENDED in order to have access to + the virtualisation extensions) or non-secure EL1. + +- Caches, MMUs + The MMU must be off. + Instruction cache may be on or off. + Data cache must be off and invalidated. + External caches (if present) must be configured and disabled. + +- Architected timers + CNTFRQ must be programmed with the timer frequency. + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) + set where available. can you explain why? Otherwise the kernel cannot access the generic timer registers (it is described in the AArch64 exception model which isn't public yet). I do not like the idea to do too much in the boot loader can we drop it and do it the head.S or find an other way No. The kernel expects some sane setup before it can start. That's the case already on AArch32. With AArch64 we also mandate single Image from start. You can have a look at an example boot wrapper that creates an environment for the AArch64 kernel: git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git +- The primary CPU must jump directly to the first instruction of the + kernel image. The device tree blob passed by this CPU must contain + for each CPU node: + +1. An 'enable-method' property. Currently, the only supported value + for this field is the string spin-table. + +2. A 'cpu-release-addr' property identifying a 64-bit, + zero-initialised memory location. + + It is expected that the bootloader will generate these device tree + properties and insert them into the blob prior to kernel entry. + +- Any secondary CPUs must spin outside of the kernel in a reserved area + of memory (communicated to the kernel by a /memreserve/ region in the + device tree) polling their cpu-release-addr location, which must be + contained in the reserved region. A wfe instruction may be inserted + to reduce the overhead of the busy-loop and a sev will be issued by + the primary CPU. When a read of the location pointed to by the + cpu-release-addr returns a non-zero value, the CPU must jump directly + to this value. do you plan AMP boot? What do you mean by AMP? If you only want to use 3 CPUs out of 4 for example, you change the FDT information that gets passed to the kernel accordingly. So the kernel wouldn't touch the 4th one. I mean boot a different kernel in each core as example That's not on my plan. It may be doable but I don't see any need for it. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On 13:51 Mon 10 Sep , Catalin Marinas wrote: > On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD > wrote: > > On 19:29 Sun 09 Sep , Nicolas Pitre wrote: > > > On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > > > > +The image must be placed at the specified offset (currently 0x8) > > > > > +from the start of the system RAM and called there. The start of the > > > > > +system RAM must be aligned to 2MB. > > > > can we drop this > > > > > > Drop what? > > > And why? > > This contrain the must be loadable at any address > > You can't easily load the kernel image at any address, unless it can > relocate itself and you have a way to specify PHYS_OFFSET. We don't want > a compile-time PHYS_OFFSET, the kernel detects it at boot time based on > the load address. so NACK kexec and other boot loaders require it Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On 09/10/2012 01:53 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: On 19:29 Sun 09 Sep , Nicolas Pitre wrote: On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +4. Call the kernel image + + +Requirement: MANDATORY + +The decompressed kernel image contains a 32-byte header as follows: + + u32 magic= 0x1408; /* branch to stext, little-endian */ + u32 res0 = 0;/* reserved */ + u64 text_offset; /* Image load offset */ + u64 res1 = 0;/* reserved */ + u64 res2 = 0;/* reserved */ we need to have a magic to known it's a arm64 kernel You have it: it's 0x1408 at the beginning. fragile Others have commented on the relocatable kernel non-issue. But to this part, also bear in mind that Catalin pointed out boot standardization work may change how some AArch64 systems ultimately end up booting. Thanks, Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, 10 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 13:51 Mon 10 Sep , Catalin Marinas wrote: > > On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD > > wrote: > > > On 19:29 Sun 09 Sep , Nicolas Pitre wrote: > > > > On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > > > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > > > > > +The image must be placed at the specified offset (currently > > > > > > 0x8) > > > > > > +from the start of the system RAM and called there. The start of the > > > > > > +system RAM must be aligned to 2MB. > > > > > can we drop this > > > > > > > > Drop what? > > > > And why? > > > This contrain the must be loadable at any address > > > > You can't easily load the kernel image at any address, unless it can > > relocate itself and you have a way to specify PHYS_OFFSET. We don't want > > a compile-time PHYS_OFFSET, the kernel detects it at boot time based on > > the load address. > so NACK kexec and other boot loaders require it I think you might have misunderstood something. What's there now is perfectly sane. SO I must NACK your NACK. :-) Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Sun, Sep 09, 2012 at 06:20:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > +The device tree blob (dtb) must be no bigger than 2 megabytes in size > > +and placed at a 2-megabyte boundary within the first 512 megabytes from > > +the start of the kernel image. This is to allow the kernel to map the > > +blob using a single section mapping in the initial page tables. > why do you want to restrict the DT to be less tahn 2MiB? That's a restriction due on the initial memory map. At some point we may add support in head.S to parse the dtb and extract the size information. Not critical at this stage. > > +Before jumping into the kernel, the following conditions must be met: > > + > > +- Quiesce all DMA capable devices so that memory does not get > > + corrupted by bogus network packets or disk data. This will save > > + you many hours of debug. > > + > > +- Primary CPU general-purpose register settings > > + x0 = physical address of device tree blob (dtb) in system RAM. > > + x1 = 0 (reserved for future use) > > + x2 = 0 (reserved for future use) > > + x3 = 0 (reserved for future use) > > + > > +- CPU mode > > + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, > > + IRQ and FIQ). > > + The CPU must be in either EL2 (RECOMMENDED in order to have access to > > + the virtualisation extensions) or non-secure EL1. > > + > > +- Caches, MMUs > > + The MMU must be off. > > + Instruction cache may be on or off. > > + Data cache must be off and invalidated. > > + External caches (if present) must be configured and disabled. > > + > > +- Architected timers > > + CNTFRQ must be programmed with the timer frequency. > > + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) > > + set where available. > can you explain why? Otherwise the kernel cannot access the generic timer registers (it is described in the AArch64 exception model which isn't public yet). > > +- The primary CPU must jump directly to the first instruction of the > > + kernel image. The device tree blob passed by this CPU must contain > > + for each CPU node: > > + > > +1. An 'enable-method' property. Currently, the only supported value > > + for this field is the string "spin-table". > > + > > +2. A 'cpu-release-addr' property identifying a 64-bit, > > + zero-initialised memory location. > > + > > + It is expected that the bootloader will generate these device tree > > + properties and insert them into the blob prior to kernel entry. > > + > > +- Any secondary CPUs must spin outside of the kernel in a reserved area > > + of memory (communicated to the kernel by a /memreserve/ region in the > > + device tree) polling their cpu-release-addr location, which must be > > + contained in the reserved region. A wfe instruction may be inserted > > + to reduce the overhead of the busy-loop and a sev will be issued by > > + the primary CPU. When a read of the location pointed to by the > > + cpu-release-addr returns a non-zero value, the CPU must jump directly > > + to this value. > do you plan AMP boot? What do you mean by AMP? If you only want to use 3 CPUs out of 4 for example, you change the FDT information that gets passed to the kernel accordingly. So the kernel wouldn't touch the 4th one. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, Sep 10, 2012 at 04:21:02PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 13:51 Mon 10 Sep , Catalin Marinas wrote: > > On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD > > wrote: > > > On 19:29 Sun 09 Sep , Nicolas Pitre wrote: > > > > On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > > > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > > > > > +The image must be placed at the specified offset (currently > > > > > > 0x8) > > > > > > +from the start of the system RAM and called there. The start of the > > > > > > +system RAM must be aligned to 2MB. > > > > > can we drop this > > > > > > > > Drop what? > > > > And why? > > > This contrain the must be loadable at any address > > > > You can't easily load the kernel image at any address, unless it can > > relocate itself and you have a way to specify PHYS_OFFSET. We don't want > > a compile-time PHYS_OFFSET, the kernel detects it at boot time based on > > the load address. > so NACK kexec and other boot loaders require it Just in case it wasn't clear, the kernel can be loaded at any address in RAM (and the RAM can start at any sane address). The way the kernel calculates PHYS_OFFSET is (load address - TEXT_OFFSET) unless we pass it by other means (none currently specified). For a kdump kernel, it just assumes that its PHYS_OFFSET is higher but it can ioremap the crashed kernel memory. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, 10 Sep 2012, Arnd Bergmann wrote: > On Monday 10 September 2012, Nicolas Pitre wrote: > > On Mon, 10 Sep 2012, Arnd Bergmann wrote: > > > On Monday 10 September 2012, Catalin Marinas wrote: > > > > On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe > > > > PLAGNIOL-VILLARD wrote: > > > I think a bunch of other architectures can have relocatable kernels, which > > > is useful e.g. for kdump. It does imply a small runtime cost and may have > > > other disadvantages though. > > > > Relocatable in physical space is what kdump actually needs, and that's > > what we already have here (as well as on ARM32 for that matter with > > CONFIG_ARM_PATCH_PHYS_VIRT). Relocatable in the virtual space is costly > > and we shouldn't need to go there. > > Ah, I see. I thought that the other architectures (powerpc and x86) > doing this were actually building with -fPIC, but they do the same > kind of early patching that we do. This being said, on ARM we don't take advantage of this physically relocatable attribute with kdump. Granted, PATCH_PHYS_VIRT was introduced after kdump support, therefore the kernel had to be copied at its expected physical location after the memory content there had been preserved. These days the only thing that kdump would need to do is to just boot the kdump kernel in place with its reserved memory range and let it ioremap the previous kernel's memory for analysis. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, Sep 10, 2012 at 03:48:20PM +0100, Arnd Bergmann wrote: > On Monday 10 September 2012, Nicolas Pitre wrote: > > On Mon, 10 Sep 2012, Arnd Bergmann wrote: > > > On Monday 10 September 2012, Catalin Marinas wrote: > > > > On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe > > > > PLAGNIOL-VILLARD wrote: > > > I think a bunch of other architectures can have relocatable kernels, which > > > is useful e.g. for kdump. It does imply a small runtime cost and may have > > > other disadvantages though. > > > > Relocatable in physical space is what kdump actually needs, and that's > > what we already have here (as well as on ARM32 for that matter with > > CONFIG_ARM_PATCH_PHYS_VIRT). Relocatable in the virtual space is costly > > and we shouldn't need to go there. > > Ah, I see. I thought that the other architectures (powerpc and x86) > doing this were actually building with -fPIC, but they do the same > kind of early patching that we do. On arm64 I don't have run-time code patching (yet) but a PHYS_OFFSET variable set at boot time. It may prove useful to have run-time code patching but that's just an optimisation that can be added later. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Monday 10 September 2012, Nicolas Pitre wrote: > On Mon, 10 Sep 2012, Arnd Bergmann wrote: > > On Monday 10 September 2012, Catalin Marinas wrote: > > > On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe > > > PLAGNIOL-VILLARD wrote: > > I think a bunch of other architectures can have relocatable kernels, which > > is useful e.g. for kdump. It does imply a small runtime cost and may have > > other disadvantages though. > > Relocatable in physical space is what kdump actually needs, and that's > what we already have here (as well as on ARM32 for that matter with > CONFIG_ARM_PATCH_PHYS_VIRT). Relocatable in the virtual space is costly > and we shouldn't need to go there. Ah, I see. I thought that the other architectures (powerpc and x86) doing this were actually building with -fPIC, but they do the same kind of early patching that we do. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, 10 Sep 2012, Arnd Bergmann wrote: > On Monday 10 September 2012, Catalin Marinas wrote: > > On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD > > wrote: > > > On 19:29 Sun 09 Sep , Nicolas Pitre wrote: > > > > On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > > > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > > > > > +The image must be placed at the specified offset (currently > > > > > > 0x8) > > > > > > +from the start of the system RAM and called there. The start of the > > > > > > +system RAM must be aligned to 2MB. > > > > > can we drop this > > > > > > > > Drop what? > > > > And why? > > > This contrain the must be loadable at any address > > > > You can't easily load the kernel image at any address, unless it can > > relocate itself and you have a way to specify PHYS_OFFSET. We don't want > > a compile-time PHYS_OFFSET, the kernel detects it at boot time based on > > the load address. > > I think a bunch of other architectures can have relocatable kernels, which > is useful e.g. for kdump. It does imply a small runtime cost and may have > other disadvantages though. Relocatable in physical space is what kdump actually needs, and that's what we already have here (as well as on ARM32 for that matter with CONFIG_ARM_PATCH_PHYS_VIRT). Relocatable in the virtual space is costly and we shouldn't need to go there. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Monday 10 September 2012, Catalin Marinas wrote: > On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD > wrote: > > On 19:29 Sun 09 Sep , Nicolas Pitre wrote: > > > On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > > > > +The image must be placed at the specified offset (currently 0x8) > > > > > +from the start of the system RAM and called there. The start of the > > > > > +system RAM must be aligned to 2MB. > > > > can we drop this > > > > > > Drop what? > > > And why? > > This contrain the must be loadable at any address > > You can't easily load the kernel image at any address, unless it can > relocate itself and you have a way to specify PHYS_OFFSET. We don't want > a compile-time PHYS_OFFSET, the kernel detects it at boot time based on > the load address. I think a bunch of other architectures can have relocatable kernels, which is useful e.g. for kdump. It does imply a small runtime cost and may have other disadvantages though. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 19:29 Sun 09 Sep , Nicolas Pitre wrote: > > On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > > > +The image must be placed at the specified offset (currently 0x8) > > > > +from the start of the system RAM and called there. The start of the > > > > +system RAM must be aligned to 2MB. > > > can we drop this > > > > Drop what? > > And why? > This contrain the must be loadable at any address You can't easily load the kernel image at any address, unless it can relocate itself and you have a way to specify PHYS_OFFSET. We don't want a compile-time PHYS_OFFSET, the kernel detects it at boot time based on the load address. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 19:29 Sun 09 Sep , Nicolas Pitre wrote: On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +The image must be placed at the specified offset (currently 0x8) +from the start of the system RAM and called there. The start of the +system RAM must be aligned to 2MB. can we drop this Drop what? And why? This contrain the must be loadable at any address You can't easily load the kernel image at any address, unless it can relocate itself and you have a way to specify PHYS_OFFSET. We don't want a compile-time PHYS_OFFSET, the kernel detects it at boot time based on the load address. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Monday 10 September 2012, Catalin Marinas wrote: On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 19:29 Sun 09 Sep , Nicolas Pitre wrote: On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +The image must be placed at the specified offset (currently 0x8) +from the start of the system RAM and called there. The start of the +system RAM must be aligned to 2MB. can we drop this Drop what? And why? This contrain the must be loadable at any address You can't easily load the kernel image at any address, unless it can relocate itself and you have a way to specify PHYS_OFFSET. We don't want a compile-time PHYS_OFFSET, the kernel detects it at boot time based on the load address. I think a bunch of other architectures can have relocatable kernels, which is useful e.g. for kdump. It does imply a small runtime cost and may have other disadvantages though. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, 10 Sep 2012, Arnd Bergmann wrote: On Monday 10 September 2012, Catalin Marinas wrote: On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 19:29 Sun 09 Sep , Nicolas Pitre wrote: On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +The image must be placed at the specified offset (currently 0x8) +from the start of the system RAM and called there. The start of the +system RAM must be aligned to 2MB. can we drop this Drop what? And why? This contrain the must be loadable at any address You can't easily load the kernel image at any address, unless it can relocate itself and you have a way to specify PHYS_OFFSET. We don't want a compile-time PHYS_OFFSET, the kernel detects it at boot time based on the load address. I think a bunch of other architectures can have relocatable kernels, which is useful e.g. for kdump. It does imply a small runtime cost and may have other disadvantages though. Relocatable in physical space is what kdump actually needs, and that's what we already have here (as well as on ARM32 for that matter with CONFIG_ARM_PATCH_PHYS_VIRT). Relocatable in the virtual space is costly and we shouldn't need to go there. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Monday 10 September 2012, Nicolas Pitre wrote: On Mon, 10 Sep 2012, Arnd Bergmann wrote: On Monday 10 September 2012, Catalin Marinas wrote: On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: I think a bunch of other architectures can have relocatable kernels, which is useful e.g. for kdump. It does imply a small runtime cost and may have other disadvantages though. Relocatable in physical space is what kdump actually needs, and that's what we already have here (as well as on ARM32 for that matter with CONFIG_ARM_PATCH_PHYS_VIRT). Relocatable in the virtual space is costly and we shouldn't need to go there. Ah, I see. I thought that the other architectures (powerpc and x86) doing this were actually building with -fPIC, but they do the same kind of early patching that we do. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, Sep 10, 2012 at 03:48:20PM +0100, Arnd Bergmann wrote: On Monday 10 September 2012, Nicolas Pitre wrote: On Mon, 10 Sep 2012, Arnd Bergmann wrote: On Monday 10 September 2012, Catalin Marinas wrote: On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: I think a bunch of other architectures can have relocatable kernels, which is useful e.g. for kdump. It does imply a small runtime cost and may have other disadvantages though. Relocatable in physical space is what kdump actually needs, and that's what we already have here (as well as on ARM32 for that matter with CONFIG_ARM_PATCH_PHYS_VIRT). Relocatable in the virtual space is costly and we shouldn't need to go there. Ah, I see. I thought that the other architectures (powerpc and x86) doing this were actually building with -fPIC, but they do the same kind of early patching that we do. On arm64 I don't have run-time code patching (yet) but a PHYS_OFFSET variable set at boot time. It may prove useful to have run-time code patching but that's just an optimisation that can be added later. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, 10 Sep 2012, Arnd Bergmann wrote: On Monday 10 September 2012, Nicolas Pitre wrote: On Mon, 10 Sep 2012, Arnd Bergmann wrote: On Monday 10 September 2012, Catalin Marinas wrote: On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: I think a bunch of other architectures can have relocatable kernels, which is useful e.g. for kdump. It does imply a small runtime cost and may have other disadvantages though. Relocatable in physical space is what kdump actually needs, and that's what we already have here (as well as on ARM32 for that matter with CONFIG_ARM_PATCH_PHYS_VIRT). Relocatable in the virtual space is costly and we shouldn't need to go there. Ah, I see. I thought that the other architectures (powerpc and x86) doing this were actually building with -fPIC, but they do the same kind of early patching that we do. This being said, on ARM we don't take advantage of this physically relocatable attribute with kdump. Granted, PATCH_PHYS_VIRT was introduced after kdump support, therefore the kernel had to be copied at its expected physical location after the memory content there had been preserved. These days the only thing that kdump would need to do is to just boot the kdump kernel in place with its reserved memory range and let it ioremap the previous kernel's memory for analysis. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, Sep 10, 2012 at 04:21:02PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 13:51 Mon 10 Sep , Catalin Marinas wrote: On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 19:29 Sun 09 Sep , Nicolas Pitre wrote: On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +The image must be placed at the specified offset (currently 0x8) +from the start of the system RAM and called there. The start of the +system RAM must be aligned to 2MB. can we drop this Drop what? And why? This contrain the must be loadable at any address You can't easily load the kernel image at any address, unless it can relocate itself and you have a way to specify PHYS_OFFSET. We don't want a compile-time PHYS_OFFSET, the kernel detects it at boot time based on the load address. so NACK kexec and other boot loaders require it Just in case it wasn't clear, the kernel can be loaded at any address in RAM (and the RAM can start at any sane address). The way the kernel calculates PHYS_OFFSET is (load address - TEXT_OFFSET) unless we pass it by other means (none currently specified). For a kdump kernel, it just assumes that its PHYS_OFFSET is higher but it can ioremap the crashed kernel memory. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Sun, Sep 09, 2012 at 06:20:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +The device tree blob (dtb) must be no bigger than 2 megabytes in size +and placed at a 2-megabyte boundary within the first 512 megabytes from +the start of the kernel image. This is to allow the kernel to map the +blob using a single section mapping in the initial page tables. why do you want to restrict the DT to be less tahn 2MiB? That's a restriction due on the initial memory map. At some point we may add support in head.S to parse the dtb and extract the size information. Not critical at this stage. +Before jumping into the kernel, the following conditions must be met: + +- Quiesce all DMA capable devices so that memory does not get + corrupted by bogus network packets or disk data. This will save + you many hours of debug. + +- Primary CPU general-purpose register settings + x0 = physical address of device tree blob (dtb) in system RAM. + x1 = 0 (reserved for future use) + x2 = 0 (reserved for future use) + x3 = 0 (reserved for future use) + +- CPU mode + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, + IRQ and FIQ). + The CPU must be in either EL2 (RECOMMENDED in order to have access to + the virtualisation extensions) or non-secure EL1. + +- Caches, MMUs + The MMU must be off. + Instruction cache may be on or off. + Data cache must be off and invalidated. + External caches (if present) must be configured and disabled. + +- Architected timers + CNTFRQ must be programmed with the timer frequency. + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) + set where available. can you explain why? Otherwise the kernel cannot access the generic timer registers (it is described in the AArch64 exception model which isn't public yet). +- The primary CPU must jump directly to the first instruction of the + kernel image. The device tree blob passed by this CPU must contain + for each CPU node: + +1. An 'enable-method' property. Currently, the only supported value + for this field is the string spin-table. + +2. A 'cpu-release-addr' property identifying a 64-bit, + zero-initialised memory location. + + It is expected that the bootloader will generate these device tree + properties and insert them into the blob prior to kernel entry. + +- Any secondary CPUs must spin outside of the kernel in a reserved area + of memory (communicated to the kernel by a /memreserve/ region in the + device tree) polling their cpu-release-addr location, which must be + contained in the reserved region. A wfe instruction may be inserted + to reduce the overhead of the busy-loop and a sev will be issued by + the primary CPU. When a read of the location pointed to by the + cpu-release-addr returns a non-zero value, the CPU must jump directly + to this value. do you plan AMP boot? What do you mean by AMP? If you only want to use 3 CPUs out of 4 for example, you change the FDT information that gets passed to the kernel accordingly. So the kernel wouldn't touch the 4th one. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Mon, 10 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: On 13:51 Mon 10 Sep , Catalin Marinas wrote: On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 19:29 Sun 09 Sep , Nicolas Pitre wrote: On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +The image must be placed at the specified offset (currently 0x8) +from the start of the system RAM and called there. The start of the +system RAM must be aligned to 2MB. can we drop this Drop what? And why? This contrain the must be loadable at any address You can't easily load the kernel image at any address, unless it can relocate itself and you have a way to specify PHYS_OFFSET. We don't want a compile-time PHYS_OFFSET, the kernel detects it at boot time based on the load address. so NACK kexec and other boot loaders require it I think you might have misunderstood something. What's there now is perfectly sane. SO I must NACK your NACK. :-) Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On 09/10/2012 01:53 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: On 19:29 Sun 09 Sep , Nicolas Pitre wrote: On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +4. Call the kernel image + + +Requirement: MANDATORY + +The decompressed kernel image contains a 32-byte header as follows: + + u32 magic= 0x1408; /* branch to stext, little-endian */ + u32 res0 = 0;/* reserved */ + u64 text_offset; /* Image load offset */ + u64 res1 = 0;/* reserved */ + u64 res2 = 0;/* reserved */ we need to have a magic to known it's a arm64 kernel You have it: it's 0x1408 at the beginning. fragile Others have commented on the relocatable kernel non-issue. But to this part, also bear in mind that Catalin pointed out boot standardization work may change how some AArch64 systems ultimately end up booting. Thanks, Jon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On 13:51 Mon 10 Sep , Catalin Marinas wrote: On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 19:29 Sun 09 Sep , Nicolas Pitre wrote: On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +The image must be placed at the specified offset (currently 0x8) +from the start of the system RAM and called there. The start of the +system RAM must be aligned to 2MB. can we drop this Drop what? And why? This contrain the must be loadable at any address You can't easily load the kernel image at any address, unless it can relocate itself and you have a way to specify PHYS_OFFSET. We don't want a compile-time PHYS_OFFSET, the kernel detects it at boot time based on the load address. so NACK kexec and other boot loaders require it Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On 19:29 Sun 09 Sep , Nicolas Pitre wrote: > On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > > +4. Call the kernel image > > > + > > > + > > > +Requirement: MANDATORY > > > + > > > +The decompressed kernel image contains a 32-byte header as follows: > > > + > > > + u32 magic = 0x1408; /* branch to stext, little-endian */ > > > + u32 res0 = 0;/* reserved */ > > > + u64 text_offset; /* Image load offset */ > > > + u64 res1 = 0;/* reserved */ > > > + u64 res2 = 0;/* reserved */ > > we need to have a magic to known it's a arm64 kernel > > You have it: it's 0x1408 at the beginning. fragile > > > > + > > > +The image must be placed at the specified offset (currently 0x8) > > > +from the start of the system RAM and called there. The start of the > > > +system RAM must be aligned to 2MB. > > can we drop this > > Drop what? > And why? This contrain the must be loadable at any address Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 17:26 Fri 07 Sep , Catalin Marinas wrote: > > +4. Call the kernel image > > + > > + > > +Requirement: MANDATORY > > + > > +The decompressed kernel image contains a 32-byte header as follows: > > + > > + u32 magic= 0x1408; /* branch to stext, little-endian */ > > + u32 res0 = 0;/* reserved */ > > + u64 text_offset; /* Image load offset */ > > + u64 res1 = 0;/* reserved */ > > + u64 res2 = 0;/* reserved */ > we need to have a magic to known it's a arm64 kernel You have it: it's 0x1408 at the beginning. > > + > > +The image must be placed at the specified offset (currently 0x8) > > +from the start of the system RAM and called there. The start of the > > +system RAM must be aligned to 2MB. > can we drop this Drop what? And why? Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On 17:26 Fri 07 Sep , Catalin Marinas wrote: > The patch adds the kernel booting and the initial setup code. > Documentation/arm64/booting.txt describes the booting protocol on the > AArch64 Linux kernel. This is subject to change following the work on > boot standardisation, ACPI. > > Signed-off-by: Will Deacon > Signed-off-by: Catalin Marinas > Acked-by: Nicolas Pitre > Acked-by: Tony Lindgren > --- > Documentation/arm64/booting.txt | 152 > arch/arm64/include/asm/setup.h | 26 ++ > arch/arm64/kernel/head.S| 510 > +++ > arch/arm64/kernel/setup.c | 351 +++ > 4 files changed, 1039 insertions(+), 0 deletions(-) > create mode 100644 Documentation/arm64/booting.txt > create mode 100644 arch/arm64/include/asm/setup.h > create mode 100644 arch/arm64/kernel/head.S > create mode 100644 arch/arm64/kernel/setup.c > > diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt > new file mode 100644 > index 000..9c4d388 > --- /dev/null > +++ b/Documentation/arm64/booting.txt > @@ -0,0 +1,152 @@ > + Booting AArch64 Linux > + = > + > +Author: Will Deacon > +Date : 07 September 2012 > + > +This document is based on the ARM booting document by Russell King and > +is relevant to all public releases of the AArch64 Linux kernel. > + > +The AArch64 exception model is made up of a number of exception levels > +(EL0 - EL3), with EL0 and EL1 having a secure and a non-secure > +counterpart. EL2 is the hypervisor level and exists only in non-secure > +mode. EL3 is the highest priority level and exists only in secure mode. > + > +For the purposes of this document, we will use the term `boot loader' > +simply to define all software that executes on the CPU(s) before control > +is passed to the Linux kernel. This may include secure monitor and > +hypervisor code, or it may just be a handful of instructions for > +preparing a minimal boot environment. > + > +Essentially, the boot loader should provide (as a minimum) the > +following: > + > +1. Setup and initialise the RAM > +2. Setup the device tree > +3. Decompress the kernel image > +4. Call the kernel image > + > + > +1. Setup and initialise RAM > +--- > + > +Requirement: MANDATORY > + > +The boot loader is expected to find and initialise all RAM that the > +kernel will use for volatile data storage in the system. It performs > +this in a machine dependent manner. (It may use internal algorithms > +to automatically locate and size all RAM, or it may use knowledge of > +the RAM in the machine, or any other method the boot loader designer > +sees fit.) > + > + > +2. Setup the device tree > +- > + > +Requirement: MANDATORY > + > +The device tree blob (dtb) must be no bigger than 2 megabytes in size > +and placed at a 2-megabyte boundary within the first 512 megabytes from > +the start of the kernel image. This is to allow the kernel to map the > +blob using a single section mapping in the initial page tables. why do you want to restrict the DT to be less tahn 2MiB? > + > + > +3. Decompress the kernel image > +-- > + > +Requirement: OPTIONAL > + > +The AArch64 kernel does not currently provide a decompressor and > +therefore requires decompression (gzip etc.) to be performed by the boot > +loader if a compressed Image target (e.g. Image.gz) is used. For > +bootloaders that do not implement this requirement, the uncompressed > +Image target is available instead. > + > + > +4. Call the kernel image > + > + > +Requirement: MANDATORY > + > +The decompressed kernel image contains a 32-byte header as follows: > + > + u32 magic = 0x1408; /* branch to stext, little-endian */ > + u32 res0 = 0;/* reserved */ > + u64 text_offset; /* Image load offset */ > + u64 res1 = 0;/* reserved */ > + u64 res2 = 0;/* reserved */ we need to have a magic to known it's a arm64 kernel > + > +The image must be placed at the specified offset (currently 0x8) > +from the start of the system RAM and called there. The start of the > +system RAM must be aligned to 2MB. can we drop this > + > +Before jumping into the kernel, the following conditions must be met: > + > +- Quiesce all DMA capable devices so that memory does not get > + corrupted by bogus network packets or disk data. This will save > + you many hours of debug. > + > +- Primary CPU general-purpose register settings > + x0 = physical address of device tree blob (dtb) in system RAM. > + x1 = 0 (reserved for future use) > + x2 = 0 (reserved for future use) > + x3 = 0 (reserved for future use) > + > +- CPU mode > + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, > + IRQ and FIQ). > + The CPU must be in either EL2 (RECOMMENDED in order to have access to > + the
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On 17:26 Fri 07 Sep , Catalin Marinas wrote: The patch adds the kernel booting and the initial setup code. Documentation/arm64/booting.txt describes the booting protocol on the AArch64 Linux kernel. This is subject to change following the work on boot standardisation, ACPI. Signed-off-by: Will Deacon will.dea...@arm.com Signed-off-by: Catalin Marinas catalin.mari...@arm.com Acked-by: Nicolas Pitre n...@linaro.org Acked-by: Tony Lindgren t...@atomide.com --- Documentation/arm64/booting.txt | 152 arch/arm64/include/asm/setup.h | 26 ++ arch/arm64/kernel/head.S| 510 +++ arch/arm64/kernel/setup.c | 351 +++ 4 files changed, 1039 insertions(+), 0 deletions(-) create mode 100644 Documentation/arm64/booting.txt create mode 100644 arch/arm64/include/asm/setup.h create mode 100644 arch/arm64/kernel/head.S create mode 100644 arch/arm64/kernel/setup.c diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt new file mode 100644 index 000..9c4d388 --- /dev/null +++ b/Documentation/arm64/booting.txt @@ -0,0 +1,152 @@ + Booting AArch64 Linux + = + +Author: Will Deacon will.dea...@arm.com +Date : 07 September 2012 + +This document is based on the ARM booting document by Russell King and +is relevant to all public releases of the AArch64 Linux kernel. + +The AArch64 exception model is made up of a number of exception levels +(EL0 - EL3), with EL0 and EL1 having a secure and a non-secure +counterpart. EL2 is the hypervisor level and exists only in non-secure +mode. EL3 is the highest priority level and exists only in secure mode. + +For the purposes of this document, we will use the term `boot loader' +simply to define all software that executes on the CPU(s) before control +is passed to the Linux kernel. This may include secure monitor and +hypervisor code, or it may just be a handful of instructions for +preparing a minimal boot environment. + +Essentially, the boot loader should provide (as a minimum) the +following: + +1. Setup and initialise the RAM +2. Setup the device tree +3. Decompress the kernel image +4. Call the kernel image + + +1. Setup and initialise RAM +--- + +Requirement: MANDATORY + +The boot loader is expected to find and initialise all RAM that the +kernel will use for volatile data storage in the system. It performs +this in a machine dependent manner. (It may use internal algorithms +to automatically locate and size all RAM, or it may use knowledge of +the RAM in the machine, or any other method the boot loader designer +sees fit.) + + +2. Setup the device tree +- + +Requirement: MANDATORY + +The device tree blob (dtb) must be no bigger than 2 megabytes in size +and placed at a 2-megabyte boundary within the first 512 megabytes from +the start of the kernel image. This is to allow the kernel to map the +blob using a single section mapping in the initial page tables. why do you want to restrict the DT to be less tahn 2MiB? + + +3. Decompress the kernel image +-- + +Requirement: OPTIONAL + +The AArch64 kernel does not currently provide a decompressor and +therefore requires decompression (gzip etc.) to be performed by the boot +loader if a compressed Image target (e.g. Image.gz) is used. For +bootloaders that do not implement this requirement, the uncompressed +Image target is available instead. + + +4. Call the kernel image + + +Requirement: MANDATORY + +The decompressed kernel image contains a 32-byte header as follows: + + u32 magic = 0x1408; /* branch to stext, little-endian */ + u32 res0 = 0;/* reserved */ + u64 text_offset; /* Image load offset */ + u64 res1 = 0;/* reserved */ + u64 res2 = 0;/* reserved */ we need to have a magic to known it's a arm64 kernel + +The image must be placed at the specified offset (currently 0x8) +from the start of the system RAM and called there. The start of the +system RAM must be aligned to 2MB. can we drop this + +Before jumping into the kernel, the following conditions must be met: + +- Quiesce all DMA capable devices so that memory does not get + corrupted by bogus network packets or disk data. This will save + you many hours of debug. + +- Primary CPU general-purpose register settings + x0 = physical address of device tree blob (dtb) in system RAM. + x1 = 0 (reserved for future use) + x2 = 0 (reserved for future use) + x3 = 0 (reserved for future use) + +- CPU mode + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, + IRQ and FIQ). + The CPU must be in either EL2 (RECOMMENDED in order to have access to + the virtualisation extensions) or
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +4. Call the kernel image + + +Requirement: MANDATORY + +The decompressed kernel image contains a 32-byte header as follows: + + u32 magic= 0x1408; /* branch to stext, little-endian */ + u32 res0 = 0;/* reserved */ + u64 text_offset; /* Image load offset */ + u64 res1 = 0;/* reserved */ + u64 res2 = 0;/* reserved */ we need to have a magic to known it's a arm64 kernel You have it: it's 0x1408 at the beginning. + +The image must be placed at the specified offset (currently 0x8) +from the start of the system RAM and called there. The start of the +system RAM must be aligned to 2MB. can we drop this Drop what? And why? Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On 19:29 Sun 09 Sep , Nicolas Pitre wrote: On Sun, 9 Sep 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:26 Fri 07 Sep , Catalin Marinas wrote: +4. Call the kernel image + + +Requirement: MANDATORY + +The decompressed kernel image contains a 32-byte header as follows: + + u32 magic = 0x1408; /* branch to stext, little-endian */ + u32 res0 = 0;/* reserved */ + u64 text_offset; /* Image load offset */ + u64 res1 = 0;/* reserved */ + u64 res2 = 0;/* reserved */ we need to have a magic to known it's a arm64 kernel You have it: it's 0x1408 at the beginning. fragile + +The image must be placed at the specified offset (currently 0x8) +from the start of the system RAM and called there. The start of the +system RAM must be aligned to 2MB. can we drop this Drop what? And why? This contrain the must be loadable at any address Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Friday 07 September 2012, Catalin Marinas wrote: > > The patch adds the kernel booting and the initial setup code. > Documentation/arm64/booting.txt describes the booting protocol on the > AArch64 Linux kernel. This is subject to change following the work on > boot standardisation, ACPI. > > Signed-off-by: Will Deacon > Signed-off-by: Catalin Marinas > Acked-by: Nicolas Pitre > Acked-by: Tony Lindgren Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
On Friday 07 September 2012, Catalin Marinas wrote: The patch adds the kernel booting and the initial setup code. Documentation/arm64/booting.txt describes the booting protocol on the AArch64 Linux kernel. This is subject to change following the work on boot standardisation, ACPI. Signed-off-by: Will Deacon will.dea...@arm.com Signed-off-by: Catalin Marinas catalin.mari...@arm.com Acked-by: Nicolas Pitre n...@linaro.org Acked-by: Tony Lindgren t...@atomide.com Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
