Re: [PATCH v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On Fri, Aug 17, 2012 at 02:13:59PM +0100, Tony Lindgren wrote:
> * Shilimkar, Santosh  [120817 03:11]:
> > On Fri, Aug 17, 2012 at 3:35 PM, Catalin Marinas
> >  wrote:
> > >
> > > On Fri, Aug 17, 2012 at 10:41:10AM +0100, Santosh Shilimkar wrote:
> > > >
> > > > So you expect all the secondary CPUs to be in wakeup state and probably
> > > > looping in WFE for a signal from kernel to boot. There is one issue
> > > > with this requirement though. For large CPU system, you need to reset
> > > > all the CPUs and hit this waiting loop. This will lead to large inrush
> > > > current need at bootup which may be not be supported. To avoid this
> > > > issue, secondary CPUs are kept in OFF state and then they are woken
> > > > up from kernel one by one whenever they need to be brought into the
> > > > system. This requirement should be considered.
> > >
> > > I agree, this part will be extended. That's one method that we currently
> > > support and suitable to the model.
> > >
> > > The better method is the SMC standardisation that Charles Garcia-Tobin
> > > has written (to be made available soon) and was presented at the last
> > > Linaro Connect in HK. Given that the CPU power is usually controlled by
> > > the secure side, we'll ask for an SMC to be issued for waking up
> > > secondary CPUs, so it's up to the secure firmware to write the correct
> > > hardware registers.
> > >
> > Thanks for the information. SMC standardization would indeed help
> > to overcome some of these. Will wait for that information before
> > next set of questions.
> 
> Yes please. If the SMC is not standardized for most calls at least,
> we'll end up with a horrible mess of SoC specific calls like we
> currently have. Related to that, the virtualization calls should be
> also standardized so we don't end up with multiple different hypervisors
> with different calls.

The Power State Coordination Interface initial proposal has been
published here:

http://infocenter.arm.com/help/topic/com.arm.doc.den0022a/index.html

(as with other ARM documents, they are public but free registration
required).

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On Fri, Aug 17, 2012 at 02:13:59PM +0100, Tony Lindgren wrote:
 * Shilimkar, Santosh santosh.shilim...@ti.com [120817 03:11]:
  On Fri, Aug 17, 2012 at 3:35 PM, Catalin Marinas
  catalin.mari...@arm.com wrote:
  
   On Fri, Aug 17, 2012 at 10:41:10AM +0100, Santosh Shilimkar wrote:
   
So you expect all the secondary CPUs to be in wakeup state and probably
looping in WFE for a signal from kernel to boot. There is one issue
with this requirement though. For large CPU system, you need to reset
all the CPUs and hit this waiting loop. This will lead to large inrush
current need at bootup which may be not be supported. To avoid this
issue, secondary CPUs are kept in OFF state and then they are woken
up from kernel one by one whenever they need to be brought into the
system. This requirement should be considered.
  
   I agree, this part will be extended. That's one method that we currently
   support and suitable to the model.
  
   The better method is the SMC standardisation that Charles Garcia-Tobin
   has written (to be made available soon) and was presented at the last
   Linaro Connect in HK. Given that the CPU power is usually controlled by
   the secure side, we'll ask for an SMC to be issued for waking up
   secondary CPUs, so it's up to the secure firmware to write the correct
   hardware registers.
  
  Thanks for the information. SMC standardization would indeed help
  to overcome some of these. Will wait for that information before
  next set of questions.
 
 Yes please. If the SMC is not standardized for most calls at least,
 we'll end up with a horrible mess of SoC specific calls like we
 currently have. Related to that, the virtualization calls should be
 also standardized so we don't end up with multiple different hypervisors
 with different calls.

The Power State Coordination Interface initial proposal has been
published here:

http://infocenter.arm.com/help/topic/com.arm.doc.den0022a/index.html

(as with other ARM documents, they are public but free registration
required).

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Nicolas Pitre]

On Fri, 17 Aug 2012, Arnd Bergmann wrote:

> On Thursday 16 August 2012, Nicolas Pitre wrote:
> > Some people will want to use bzip2 or whatever other decompressor du 
> > jour.  Maybe this shouldn't be gzip specific, or just presented as a 
> > possible option?
> 
> Good point. Whether this should be part of this document depends on
> what assumptions we make about the boot loader getting the image
> in the first place.
> 
> In the strict sense, we are documenting the interface between the boot
> loader and the kernel here, which already specifies that  the kernel
> must be uncompressed by the time we enter it. If the boot loader wants
> to add its own encryption or compression methods, or its own headers
> in front of the binary, the boot protocol isn't really impacted.

Right.  And someone else will insist on wrapping the kernel into a boot 
loader specific image format e.g. u-Boot.  If all those variations could 
be kept out of the kernel build that would be a good thing.

That means the kernel should be wrapped/compressed/scrambled at 
installation time, not at build time.  This way the kernel image remains 
universal and flexibility in its installation is possible.

> That said, I think it's a good idea to also specify what kind of 
> format we want to be used, e.g. a stripped ELF Image compressed with 
> one of gzip/bzip2/lzo/xz and with no other headers added, on a 
> vfat/ext4/btrfs formatted file system. There are probably a lot of 
> other things one might want to specify if we go down this route. Or we 
> could refer to the UEFI spec and mandate that the same format that 
> UEFI uses should be used here independent of what boot loader is used. 
> I think we can still allow other ways to get to the image for deeply 
> embedded systems, e.g. linking the kernel into the boot loader as a 
> blob on tightly constrained systems. For that case, we'd only specify 
> the interface between boot loader and kernel as described above.

I don't think we'll have to concern ourselves with tightly constrained 
systems that much on ARM64.


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 v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On Fri, Aug 17, 2012 at 02:13:59PM +0100, Tony Lindgren wrote:
> * Shilimkar, Santosh  [120817 03:11]:
> > On Fri, Aug 17, 2012 at 3:35 PM, Catalin Marinas
> >  wrote:
> > >
> > > On Fri, Aug 17, 2012 at 10:41:10AM +0100, Santosh Shilimkar wrote:
> > > >
> > > > So you expect all the secondary CPUs to be in wakeup state and probably
> > > > looping in WFE for a signal from kernel to boot. There is one issue
> > > > with this requirement though. For large CPU system, you need to reset
> > > > all the CPUs and hit this waiting loop. This will lead to large inrush
> > > > current need at bootup which may be not be supported. To avoid this
> > > > issue, secondary CPUs are kept in OFF state and then they are woken
> > > > up from kernel one by one whenever they need to be brought into the
> > > > system. This requirement should be considered.
> > >
> > > I agree, this part will be extended. That's one method that we currently
> > > support and suitable to the model.
> > >
> > > The better method is the SMC standardisation that Charles Garcia-Tobin
> > > has written (to be made available soon) and was presented at the last
> > > Linaro Connect in HK. Given that the CPU power is usually controlled by
> > > the secure side, we'll ask for an SMC to be issued for waking up
> > > secondary CPUs, so it's up to the secure firmware to write the correct
> > > hardware registers.
> > >
> > Thanks for the information. SMC standardization would indeed help
> > to overcome some of these. Will wait for that information before
> > next set of questions.
> 
> Yes please. If the SMC is not standardized for most calls at least,
> we'll end up with a horrible mess of SoC specific calls like we
> currently have. Related to that, the virtualization calls should be
> also standardized so we don't end up with multiple different hypervisors
> with different calls.

For hypervisor, there are two kinds of API - one meant for power
management that is pretty much the same as the SMC and another specific
to the hypervisor solution (KVM, Xen etc.). The latter is specific to
the host kernel that's running as we start it at EL2 but it's not
standardised. It would be good indeed and there are other advantages
like self-virtualisation but it needs the KVM and Xen guys to come to a
common definition.

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On Fri, Aug 17, 2012 at 12:20:40PM +0100, Arnd Bergmann wrote:
> On Thursday 16 August 2012, Nicolas Pitre wrote:
> > > +3. Decompress the kernel image
> > > +--
> > > +
> > > +Requirement: OPTIONAL
> > > +
> > > +The AArch64 kernel does not provide a decompressor and therefore
> > > +requires gzip decompression to be performed by the boot loader if the
> > > +default Image.gz target is used.  For bootloaders that do not implement
> > > +this requirement, the larger Image target is available instead.
> > 
> > Some people will want to use bzip2 or whatever other decompressor du 
> > jour.  Maybe this shouldn't be gzip specific, or just presented as a 
> > possible option?
> 
> Good point. Whether this should be part of this document depends on
> what assumptions we make about the boot loader getting the image
> in the first place.

It ended up here because there is a Makefile target, Image.gz, though I
haven't used it at all. I'll expand the text so that it is not
restricted to gzip.

> In the strict sense, we are documenting the interface between the boot
> loader and the kernel here, which already specifies that  the kernel
> must be uncompressed by the time we enter it. If the boot loader wants
> to add its own encryption or compression methods, or its own headers
> in front of the binary, the boot protocol isn't really impacted.

Yes.

> That said, I think it's a good idea to also specify what kind of
> format we want to be used, e.g. a stripped ELF Image compressed
> with one of gzip/bzip2/lzo/xz and with no other headers added,
> on a vfat/ext4/btrfs formatted file system. There are probably a
> lot of other things one might want to specify if we go down this
> route. Or we could refer to the UEFI spec and mandate that the
> same format that UEFI uses should be used here independent of
> what boot loader is used. I think we can still allow other ways to
> get to the image for deeply embedded systems, e.g. linking the
> kernel into the boot loader as a blob on tightly constrained
> systems. For that case, we'd only specify the interface between
> boot loader and kernel as described above.

At least the latter case is used on the model. For the other cases, it's
quite early to clearly specify what is needed as we don't currently have
a boot-loader other than UEFI. We may expect GRUB as well.

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Tony Lindgren]

* Shilimkar, Santosh  [120817 03:11]:
> On Fri, Aug 17, 2012 at 3:35 PM, Catalin Marinas
>  wrote:
> >
> > On Fri, Aug 17, 2012 at 10:41:10AM +0100, Santosh Shilimkar wrote:
> > >
> > > So you expect all the secondary CPUs to be in wakeup state and probably
> > > looping in WFE for a signal from kernel to boot. There is one issue
> > > with this requirement though. For large CPU system, you need to reset
> > > all the CPUs and hit this waiting loop. This will lead to large inrush
> > > current need at bootup which may be not be supported. To avoid this
> > > issue, secondary CPUs are kept in OFF state and then they are woken
> > > up from kernel one by one whenever they need to be brought into the
> > > system. This requirement should be considered.
> >
> > I agree, this part will be extended. That's one method that we currently
> > support and suitable to the model.
> >
> > The better method is the SMC standardisation that Charles Garcia-Tobin
> > has written (to be made available soon) and was presented at the last
> > Linaro Connect in HK. Given that the CPU power is usually controlled by
> > the secure side, we'll ask for an SMC to be issued for waking up
> > secondary CPUs, so it's up to the secure firmware to write the correct
> > hardware registers.
> >
> Thanks for the information. SMC standardization would indeed help
> to overcome some of these. Will wait for that information before
> next set of questions.

Yes please. If the SMC is not standardized for most calls at least,
we'll end up with a horrible mess of SoC specific calls like we
currently have. Related to that, the virtualization calls should be
also standardized so we don't end up with multiple different hypervisors
with different calls.

Regards,

Tony
--
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 v2 02/31] arm64: Kernel booting and initialisation

[Arnd Bergmann]

On Thursday 16 August 2012, Nicolas Pitre wrote:
> > +3. Decompress the kernel image
> > +--
> > +
> > +Requirement: OPTIONAL
> > +
> > +The AArch64 kernel does not provide a decompressor and therefore
> > +requires gzip decompression to be performed by the boot loader if the
> > +default Image.gz target is used.  For bootloaders that do not implement
> > +this requirement, the larger Image target is available instead.
> 
> Some people will want to use bzip2 or whatever other decompressor du 
> jour.  Maybe this shouldn't be gzip specific, or just presented as a 
> possible option?

Good point. Whether this should be part of this document depends on
what assumptions we make about the boot loader getting the image
in the first place.

In the strict sense, we are documenting the interface between the boot
loader and the kernel here, which already specifies that  the kernel
must be uncompressed by the time we enter it. If the boot loader wants
to add its own encryption or compression methods, or its own headers
in front of the binary, the boot protocol isn't really impacted.

That said, I think it's a good idea to also specify what kind of
format we want to be used, e.g. a stripped ELF Image compressed
with one of gzip/bzip2/lzo/xz and with no other headers added,
on a vfat/ext4/btrfs formatted file system. There are probably a
lot of other things one might want to specify if we go down this
route. Or we could refer to the UEFI spec and mandate that the
same format that UEFI uses should be used here independent of
what boot loader is used. I think we can still allow other ways to
get to the image for deeply embedded systems, e.g. linking the
kernel into the boot loader as a blob on tightly constrained
systems. For that case, we'd only specify the interface between
boot loader and kernel as described above.

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 v2 02/31] arm64: Kernel booting and initialisation

[Shilimkar, Santosh]

On Fri, Aug 17, 2012 at 3:35 PM, Catalin Marinas
 wrote:
>
> On Fri, Aug 17, 2012 at 10:41:10AM +0100, Santosh Shilimkar wrote:
> > On Tuesday 14 August 2012 11:22 PM, Catalin Marinas wrote:
> > > +The boot loader is expected to enter the kernel on each CPU in the
> > > +following manner:
> > > +
> > > +- 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.
> >
> > So you expect all the secondary CPUs to be in wakeup state and probably
> > looping in WFE for a signal from kernel to boot. There is one issue
> > with this requirement though. For large CPU system, you need to reset
> > all the CPUs and hit this waiting loop. This will lead to large inrush
> > current need at bootup which may be not be supported. To avoid this
> > issue, secondary CPUs are kept in OFF state and then they are woken
> > up from kernel one by one whenever they need to be brought into the
> > system. This requirement should be considered.
>
> I agree, this part will be extended. That's one method that we currently
> support and suitable to the model.
>
> The better method is the SMC standardisation that Charles Garcia-Tobin
> has written (to be made available soon) and was presented at the last
> Linaro Connect in HK. Given that the CPU power is usually controlled by
> the secure side, we'll ask for an SMC to be issued for waking up
> secondary CPUs, so it's up to the secure firmware to write the correct
> hardware registers.
>
Thanks for the information. SMC standardization would indeed help
to overcome some of these. Will wait for that information before
next set of questions.

> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/head.S
> > [..]
> > > +   /*
> > > +* DO NOT MODIFY. Image header expected by Linux boot-loaders.
> > > +*/
> > > +   b   stext   // branch to kernel start,
> > > magic
> > > +   .long   0   // reserved
> > > +   .quad   TEXT_OFFSET // Image load offset from
> > > start of RAM
> > > +   .quad   0   // reserved
> > > +   .quad   0   // reserved
> > > +
> >
> > Minor nit. Avoid C++ commenting style "//"  here and rest of the patch.
>
> That's not C++ comment style, it's the *official* assembly comment style
> for AArch64 ('@' is no longer supported).
>
Ok. Thanks for clarifying.

Regards
Santosh
--
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 v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On Fri, Aug 17, 2012 at 10:41:10AM +0100, Santosh Shilimkar wrote:
> On Tuesday 14 August 2012 11:22 PM, Catalin Marinas wrote:
> > +The boot loader is expected to enter the kernel on each CPU in the
> > +following manner:
> > +
> > +- 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.
> 
> So you expect all the secondary CPUs to be in wakeup state and probably
> looping in WFE for a signal from kernel to boot. There is one issue
> with this requirement though. For large CPU system, you need to reset
> all the CPUs and hit this waiting loop. This will lead to large inrush
> current need at bootup which may be not be supported. To avoid this
> issue, secondary CPUs are kept in OFF state and then they are woken
> up from kernel one by one whenever they need to be brought into the
> system. This requirement should be considered.

I agree, this part will be extended. That's one method that we currently
support and suitable to the model.

The better method is the SMC standardisation that Charles Garcia-Tobin
has written (to be made available soon) and was presented at the last
Linaro Connect in HK. Given that the CPU power is usually controlled by
the secure side, we'll ask for an SMC to be issued for waking up
secondary CPUs, so it's up to the secure firmware to write the correct
hardware registers.

> > --- /dev/null
> > +++ b/arch/arm64/kernel/head.S
> [..]
> > +   /*
> > +* DO NOT MODIFY. Image header expected by Linux boot-loaders.
> > +*/
> > +   b   stext   // branch to kernel start, magic
> > +   .long   0   // reserved
> > +   .quad   TEXT_OFFSET // Image load offset from start 
> > of RAM
> > +   .quad   0   // reserved
> > +   .quad   0   // reserved
> > +
> 
> Minor nit. Avoid C++ commenting style "//"  here and rest of the patch.

That's not C++ comment style, it's the *official* assembly comment style
for AArch64 ('@' is no longer supported).

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Santosh Shilimkar]

On Tuesday 14 August 2012 11:22 PM, 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
---
  Documentation/arm64/booting.txt |  141 +++
  arch/arm64/include/asm/setup.h  |   26 ++
  arch/arm64/kernel/head.S|  521 +++
  arch/arm64/kernel/setup.c   |  357 +++
  4 files changed, 1045 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..3197820
--- /dev/null
+++ b/Documentation/arm64/booting.txt


[...]


+
+The boot loader is expected to enter the kernel on each CPU in the
+following manner:
+
+- 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.


So you expect all the secondary CPUs to be in wakeup state and probably
looping in WFE for a signal from kernel to boot. There is one issue
with this requirement though. For large CPU system, you need to reset
all the CPUs and hit this waiting loop. This will lead to large inrush
current need at bootup which may be not be supported. To avoid this
issue, secondary CPUs are kept in OFF state and then they are woken
up from kernel one by one whenever they need to be brought into the
system. This requirement should be considered.



diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
new file mode 100644
index 000..d766493
--- /dev/null
+++ b/arch/arm64/include/asm/setup.h
@@ -0,0 +1,26 @@
+/*
+ * Based on arch/arm/include/asm/setup.h
+ *
+ * Copyright (C) 1997-1999 Russell King
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see.
+ */
+#ifndef __ASM_SETUP_H
+#define __ASM_SETUP_H
+
+#include
+
+#define COMMAND_LINE_SIZE 1024
+
+#endif
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
new file mode 100644
index 000..34ccdc0
--- /dev/null
+++ b/arch/arm64/kernel/head.S
@@ -0,0 +1,521 @@
+/*
+ * Low-level CPU initialisation
+ * Based on arch/arm/kernel/head.S
+ *
+ * Copyright (C) 1994-2002 Russell King
+ * Copyright (C) 2003-2012 ARM Ltd.
+ * Authors:Catalin Marinas
+ * Will Deacon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see.
+ */
+


[..]


+
+   /*
+* DO NOT MODIFY. Image header expected by Linux boot-loaders.
+*/
+   b   stext   // branch to kernel start, magic
+   .long   0   // reserved
+   .quad   TEXT_OFFSET

Re: [PATCH v2 02/31] arm64: Kernel booting and initialisation

[Tony Lindgren]

* Catalin Marinas  [120814 11:00]:
> +3. Decompress the kernel image
> +--
> +
> +Requirement: OPTIONAL
> +
> +The AArch64 kernel does not provide a decompressor and therefore
> +requires gzip decompression to be performed by the boot loader if the
> +default Image.gz target is used.  For bootloaders that do not implement
> +this requirement, the larger Image target is available instead.

Maybe add something here about why AArch64 does not provide a
decompressor? That's something everybody will wonder while reading
this part.

> +- Caches, MMUs
> +  The MMU must be off.
> +  Instruction cache may be on or off.
> +  Data cache must be off and invalidated.

External caches must be configured by bootloader but set to disabled
state?

Other than that:

Acked-by: Tony Lindgren 
--
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 v2 02/31] arm64: Kernel booting and initialisation

[Tony Lindgren]

* Catalin Marinas catalin.mari...@arm.com [120814 11:00]:
 +3. Decompress the kernel image
 +--
 +
 +Requirement: OPTIONAL
 +
 +The AArch64 kernel does not provide a decompressor and therefore
 +requires gzip decompression to be performed by the boot loader if the
 +default Image.gz target is used.  For bootloaders that do not implement
 +this requirement, the larger Image target is available instead.

Maybe add something here about why AArch64 does not provide a
decompressor? That's something everybody will wonder while reading
this part.

 +- Caches, MMUs
 +  The MMU must be off.
 +  Instruction cache may be on or off.
 +  Data cache must be off and invalidated.

External caches must be configured by bootloader but set to disabled
state?

Other than that:

Acked-by: Tony Lindgren t...@atomide.com
--
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 v2 02/31] arm64: Kernel booting and initialisation

[Santosh Shilimkar]

On Tuesday 14 August 2012 11:22 PM, 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 Deaconwill.dea...@arm.com
Signed-off-by: Catalin Marinascatalin.mari...@arm.com
---
  Documentation/arm64/booting.txt |  141 +++
  arch/arm64/include/asm/setup.h  |   26 ++
  arch/arm64/kernel/head.S|  521 +++
  arch/arm64/kernel/setup.c   |  357 +++
  4 files changed, 1045 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..3197820
--- /dev/null
+++ b/Documentation/arm64/booting.txt


[...]


+
+The boot loader is expected to enter the kernel on each CPU in the
+following manner:
+
+- 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.


So you expect all the secondary CPUs to be in wakeup state and probably
looping in WFE for a signal from kernel to boot. There is one issue
with this requirement though. For large CPU system, you need to reset
all the CPUs and hit this waiting loop. This will lead to large inrush
current need at bootup which may be not be supported. To avoid this
issue, secondary CPUs are kept in OFF state and then they are woken
up from kernel one by one whenever they need to be brought into the
system. This requirement should be considered.



diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
new file mode 100644
index 000..d766493
--- /dev/null
+++ b/arch/arm64/include/asm/setup.h
@@ -0,0 +1,26 @@
+/*
+ * Based on arch/arm/include/asm/setup.h
+ *
+ * Copyright (C) 1997-1999 Russell King
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, seehttp://www.gnu.org/licenses/.
+ */
+#ifndef __ASM_SETUP_H
+#define __ASM_SETUP_H
+
+#includelinux/types.h
+
+#define COMMAND_LINE_SIZE 1024
+
+#endif
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
new file mode 100644
index 000..34ccdc0
--- /dev/null
+++ b/arch/arm64/kernel/head.S
@@ -0,0 +1,521 @@
+/*
+ * Low-level CPU initialisation
+ * Based on arch/arm/kernel/head.S
+ *
+ * Copyright (C) 1994-2002 Russell King
+ * Copyright (C) 2003-2012 ARM Ltd.
+ * Authors:Catalin Marinascatalin.mari...@arm.com
+ * Will Deaconwill.dea...@arm.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, seehttp://www.gnu.org/licenses/.
+ */
+


[..]


+
+   /*
+* DO NOT MODIFY. Image header expected by Linux boot-loaders.
+*/
+   b   stext   // branch to kernel start, magic

Re: [PATCH v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On Fri, Aug 17, 2012 at 10:41:10AM +0100, Santosh Shilimkar wrote:
 On Tuesday 14 August 2012 11:22 PM, Catalin Marinas wrote:
  +The boot loader is expected to enter the kernel on each CPU in the
  +following manner:
  +
  +- 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.
 
 So you expect all the secondary CPUs to be in wakeup state and probably
 looping in WFE for a signal from kernel to boot. There is one issue
 with this requirement though. For large CPU system, you need to reset
 all the CPUs and hit this waiting loop. This will lead to large inrush
 current need at bootup which may be not be supported. To avoid this
 issue, secondary CPUs are kept in OFF state and then they are woken
 up from kernel one by one whenever they need to be brought into the
 system. This requirement should be considered.

I agree, this part will be extended. That's one method that we currently
support and suitable to the model.

The better method is the SMC standardisation that Charles Garcia-Tobin
has written (to be made available soon) and was presented at the last
Linaro Connect in HK. Given that the CPU power is usually controlled by
the secure side, we'll ask for an SMC to be issued for waking up
secondary CPUs, so it's up to the secure firmware to write the correct
hardware registers.

  --- /dev/null
  +++ b/arch/arm64/kernel/head.S
 [..]
  +   /*
  +* DO NOT MODIFY. Image header expected by Linux boot-loaders.
  +*/
  +   b   stext   // branch to kernel start, magic
  +   .long   0   // reserved
  +   .quad   TEXT_OFFSET // Image load offset from start 
  of RAM
  +   .quad   0   // reserved
  +   .quad   0   // reserved
  +
 
 Minor nit. Avoid C++ commenting style //  here and rest of the patch.

That's not C++ comment style, it's the *official* assembly comment style
for AArch64 ('@' is no longer supported).

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Shilimkar, Santosh]

On Fri, Aug 17, 2012 at 3:35 PM, Catalin Marinas
catalin.mari...@arm.com wrote:

 On Fri, Aug 17, 2012 at 10:41:10AM +0100, Santosh Shilimkar wrote:
  On Tuesday 14 August 2012 11:22 PM, Catalin Marinas wrote:
   +The boot loader is expected to enter the kernel on each CPU in the
   +following manner:
   +
   +- 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.
 
  So you expect all the secondary CPUs to be in wakeup state and probably
  looping in WFE for a signal from kernel to boot. There is one issue
  with this requirement though. For large CPU system, you need to reset
  all the CPUs and hit this waiting loop. This will lead to large inrush
  current need at bootup which may be not be supported. To avoid this
  issue, secondary CPUs are kept in OFF state and then they are woken
  up from kernel one by one whenever they need to be brought into the
  system. This requirement should be considered.

 I agree, this part will be extended. That's one method that we currently
 support and suitable to the model.

 The better method is the SMC standardisation that Charles Garcia-Tobin
 has written (to be made available soon) and was presented at the last
 Linaro Connect in HK. Given that the CPU power is usually controlled by
 the secure side, we'll ask for an SMC to be issued for waking up
 secondary CPUs, so it's up to the secure firmware to write the correct
 hardware registers.

Thanks for the information. SMC standardization would indeed help
to overcome some of these. Will wait for that information before
next set of questions.

   --- /dev/null
   +++ b/arch/arm64/kernel/head.S
  [..]
   +   /*
   +* DO NOT MODIFY. Image header expected by Linux boot-loaders.
   +*/
   +   b   stext   // branch to kernel start,
   magic
   +   .long   0   // reserved
   +   .quad   TEXT_OFFSET // Image load offset from
   start of RAM
   +   .quad   0   // reserved
   +   .quad   0   // reserved
   +
 
  Minor nit. Avoid C++ commenting style //  here and rest of the patch.

 That's not C++ comment style, it's the *official* assembly comment style
 for AArch64 ('@' is no longer supported).

Ok. Thanks for clarifying.

Regards
Santosh
--
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 v2 02/31] arm64: Kernel booting and initialisation

[Arnd Bergmann]

On Thursday 16 August 2012, Nicolas Pitre wrote:
  +3. Decompress the kernel image
  +--
  +
  +Requirement: OPTIONAL
  +
  +The AArch64 kernel does not provide a decompressor and therefore
  +requires gzip decompression to be performed by the boot loader if the
  +default Image.gz target is used.  For bootloaders that do not implement
  +this requirement, the larger Image target is available instead.
 
 Some people will want to use bzip2 or whatever other decompressor du 
 jour.  Maybe this shouldn't be gzip specific, or just presented as a 
 possible option?

Good point. Whether this should be part of this document depends on
what assumptions we make about the boot loader getting the image
in the first place.

In the strict sense, we are documenting the interface between the boot
loader and the kernel here, which already specifies that  the kernel
must be uncompressed by the time we enter it. If the boot loader wants
to add its own encryption or compression methods, or its own headers
in front of the binary, the boot protocol isn't really impacted.

That said, I think it's a good idea to also specify what kind of
format we want to be used, e.g. a stripped ELF Image compressed
with one of gzip/bzip2/lzo/xz and with no other headers added,
on a vfat/ext4/btrfs formatted file system. There are probably a
lot of other things one might want to specify if we go down this
route. Or we could refer to the UEFI spec and mandate that the
same format that UEFI uses should be used here independent of
what boot loader is used. I think we can still allow other ways to
get to the image for deeply embedded systems, e.g. linking the
kernel into the boot loader as a blob on tightly constrained
systems. For that case, we'd only specify the interface between
boot loader and kernel as described above.

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 v2 02/31] arm64: Kernel booting and initialisation

[Tony Lindgren]

* Shilimkar, Santosh santosh.shilim...@ti.com [120817 03:11]:
 On Fri, Aug 17, 2012 at 3:35 PM, Catalin Marinas
 catalin.mari...@arm.com wrote:
 
  On Fri, Aug 17, 2012 at 10:41:10AM +0100, Santosh Shilimkar wrote:
  
   So you expect all the secondary CPUs to be in wakeup state and probably
   looping in WFE for a signal from kernel to boot. There is one issue
   with this requirement though. For large CPU system, you need to reset
   all the CPUs and hit this waiting loop. This will lead to large inrush
   current need at bootup which may be not be supported. To avoid this
   issue, secondary CPUs are kept in OFF state and then they are woken
   up from kernel one by one whenever they need to be brought into the
   system. This requirement should be considered.
 
  I agree, this part will be extended. That's one method that we currently
  support and suitable to the model.
 
  The better method is the SMC standardisation that Charles Garcia-Tobin
  has written (to be made available soon) and was presented at the last
  Linaro Connect in HK. Given that the CPU power is usually controlled by
  the secure side, we'll ask for an SMC to be issued for waking up
  secondary CPUs, so it's up to the secure firmware to write the correct
  hardware registers.
 
 Thanks for the information. SMC standardization would indeed help
 to overcome some of these. Will wait for that information before
 next set of questions.

Yes please. If the SMC is not standardized for most calls at least,
we'll end up with a horrible mess of SoC specific calls like we
currently have. Related to that, the virtualization calls should be
also standardized so we don't end up with multiple different hypervisors
with different calls.

Regards,

Tony
--
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 v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On Fri, Aug 17, 2012 at 12:20:40PM +0100, Arnd Bergmann wrote:
 On Thursday 16 August 2012, Nicolas Pitre wrote:
   +3. Decompress the kernel image
   +--
   +
   +Requirement: OPTIONAL
   +
   +The AArch64 kernel does not provide a decompressor and therefore
   +requires gzip decompression to be performed by the boot loader if the
   +default Image.gz target is used.  For bootloaders that do not implement
   +this requirement, the larger Image target is available instead.
  
  Some people will want to use bzip2 or whatever other decompressor du 
  jour.  Maybe this shouldn't be gzip specific, or just presented as a 
  possible option?
 
 Good point. Whether this should be part of this document depends on
 what assumptions we make about the boot loader getting the image
 in the first place.

It ended up here because there is a Makefile target, Image.gz, though I
haven't used it at all. I'll expand the text so that it is not
restricted to gzip.

 In the strict sense, we are documenting the interface between the boot
 loader and the kernel here, which already specifies that  the kernel
 must be uncompressed by the time we enter it. If the boot loader wants
 to add its own encryption or compression methods, or its own headers
 in front of the binary, the boot protocol isn't really impacted.

Yes.

 That said, I think it's a good idea to also specify what kind of
 format we want to be used, e.g. a stripped ELF Image compressed
 with one of gzip/bzip2/lzo/xz and with no other headers added,
 on a vfat/ext4/btrfs formatted file system. There are probably a
 lot of other things one might want to specify if we go down this
 route. Or we could refer to the UEFI spec and mandate that the
 same format that UEFI uses should be used here independent of
 what boot loader is used. I think we can still allow other ways to
 get to the image for deeply embedded systems, e.g. linking the
 kernel into the boot loader as a blob on tightly constrained
 systems. For that case, we'd only specify the interface between
 boot loader and kernel as described above.

At least the latter case is used on the model. For the other cases, it's
quite early to clearly specify what is needed as we don't currently have
a boot-loader other than UEFI. We may expect GRUB as well.

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On Fri, Aug 17, 2012 at 02:13:59PM +0100, Tony Lindgren wrote:
 * Shilimkar, Santosh santosh.shilim...@ti.com [120817 03:11]:
  On Fri, Aug 17, 2012 at 3:35 PM, Catalin Marinas
  catalin.mari...@arm.com wrote:
  
   On Fri, Aug 17, 2012 at 10:41:10AM +0100, Santosh Shilimkar wrote:
   
So you expect all the secondary CPUs to be in wakeup state and probably
looping in WFE for a signal from kernel to boot. There is one issue
with this requirement though. For large CPU system, you need to reset
all the CPUs and hit this waiting loop. This will lead to large inrush
current need at bootup which may be not be supported. To avoid this
issue, secondary CPUs are kept in OFF state and then they are woken
up from kernel one by one whenever they need to be brought into the
system. This requirement should be considered.
  
   I agree, this part will be extended. That's one method that we currently
   support and suitable to the model.
  
   The better method is the SMC standardisation that Charles Garcia-Tobin
   has written (to be made available soon) and was presented at the last
   Linaro Connect in HK. Given that the CPU power is usually controlled by
   the secure side, we'll ask for an SMC to be issued for waking up
   secondary CPUs, so it's up to the secure firmware to write the correct
   hardware registers.
  
  Thanks for the information. SMC standardization would indeed help
  to overcome some of these. Will wait for that information before
  next set of questions.
 
 Yes please. If the SMC is not standardized for most calls at least,
 we'll end up with a horrible mess of SoC specific calls like we
 currently have. Related to that, the virtualization calls should be
 also standardized so we don't end up with multiple different hypervisors
 with different calls.

For hypervisor, there are two kinds of API - one meant for power
management that is pretty much the same as the SMC and another specific
to the hypervisor solution (KVM, Xen etc.). The latter is specific to
the host kernel that's running as we start it at EL2 but it's not
standardised. It would be good indeed and there are other advantages
like self-virtualisation but it needs the KVM and Xen guys to come to a
common definition.

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Nicolas Pitre]

On Fri, 17 Aug 2012, Arnd Bergmann wrote:

 On Thursday 16 August 2012, Nicolas Pitre wrote:
  Some people will want to use bzip2 or whatever other decompressor du 
  jour.  Maybe this shouldn't be gzip specific, or just presented as a 
  possible option?
 
 Good point. Whether this should be part of this document depends on
 what assumptions we make about the boot loader getting the image
 in the first place.
 
 In the strict sense, we are documenting the interface between the boot
 loader and the kernel here, which already specifies that  the kernel
 must be uncompressed by the time we enter it. If the boot loader wants
 to add its own encryption or compression methods, or its own headers
 in front of the binary, the boot protocol isn't really impacted.

Right.  And someone else will insist on wrapping the kernel into a boot 
loader specific image format e.g. u-Boot.  If all those variations could 
be kept out of the kernel build that would be a good thing.

That means the kernel should be wrapped/compressed/scrambled at 
installation time, not at build time.  This way the kernel image remains 
universal and flexibility in its installation is possible.

 That said, I think it's a good idea to also specify what kind of 
 format we want to be used, e.g. a stripped ELF Image compressed with 
 one of gzip/bzip2/lzo/xz and with no other headers added, on a 
 vfat/ext4/btrfs formatted file system. There are probably a lot of 
 other things one might want to specify if we go down this route. Or we 
 could refer to the UEFI spec and mandate that the same format that 
 UEFI uses should be used here independent of what boot loader is used. 
 I think we can still allow other ways to get to the image for deeply 
 embedded systems, e.g. linking the kernel into the boot loader as a 
 blob on tightly constrained systems. For that case, we'd only specify 
 the interface between boot loader and kernel as described above.

I don't think we'll have to concern ourselves with tightly constrained 
systems that much on ARM64.


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 v2 02/31] arm64: Kernel booting and initialisation

[Nicolas Pitre]

On Tue, 14 Aug 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 

A few minor comments below, otherwise...

Acked-by: Nicolas Pitre 

> ---
>  Documentation/arm64/booting.txt |  141 +++
>  arch/arm64/include/asm/setup.h  |   26 ++
>  arch/arm64/kernel/head.S|  521 
> +++
>  arch/arm64/kernel/setup.c   |  357 +++
>  4 files changed, 1045 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..3197820
> --- /dev/null
> +++ b/Documentation/arm64/booting.txt
> @@ -0,0 +1,141 @@
> + Booting AArch64 Linux
> + =
> +
> +Author: Will Deacon 
> +Date  : 25 April 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.

It might be a good idea to specify the minimum information that should 
be contained in the DTB.  Memory size is certainly one such item.

> +3. Decompress the kernel image
> +--
> +
> +Requirement: OPTIONAL
> +
> +The AArch64 kernel does not provide a decompressor and therefore
> +requires gzip decompression to be performed by the boot loader if the
> +default Image.gz target is used.  For bootloaders that do not implement
> +this requirement, the larger Image target is available instead.

Some people will want to use bzip2 or whatever other decompressor du 
jour.  Maybe this shouldn't be gzip specific, or just presented as a 
possible option?

> +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 */
> +
> +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.
> +
> +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.

I think you should mandate that some additional registers be explicitly 
initialized to 0 for possible future usage (and also mentioned in the 
corresponding code comment).  We have that 

Re: [PATCH v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On Wed, Aug 15, 2012 at 02:20:02PM +0100, Arnd Bergmann wrote:
> On Tuesday 14 August 2012, Catalin Marinas wrote:
> 
> > +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.
> 
> I'm always confused by a description like this. It sounds like you cannot
> have a hypervisor if you have code running in secure mode in EL3. What
> I instead understand is that you enter non-secure mode by going from
> EL3 into EL2.

>From EL3 you can drop to either EL2 (non-secure) or EL1 (secure or
non-secure), it's the highest privilege level. But we don't support the
kernel entering at EL3, the SoC firmware runs in this mode. I'll try to
make it clearer.

> > +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.
> 
> I've seen people put firmware for some peripherals into the device tree,
> so that a device driver can grab a blob from there and load it into the
> device, rather than calling request_firmware() which would fail if the
> OS running on the system does not contain the blob. If such firmware is
> too large, you end up violating the 2 MB limit you impose here.
> 
> Should we keep that limit and declare those use cases as invalid, or
> should we try to make the boot protocol more flexible?

I would be ok to allowing larger range here but we currently don't get
the information about the size of the dtb early enough to know how much
to map. We could make some other arbitrary choice if needed like being
in the first 16MB of RAM and we map this range.

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On Wed, Aug 15, 2012 at 02:20:02PM +0100, Arnd Bergmann wrote:
 On Tuesday 14 August 2012, Catalin Marinas wrote:
 
  +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.
 
 I'm always confused by a description like this. It sounds like you cannot
 have a hypervisor if you have code running in secure mode in EL3. What
 I instead understand is that you enter non-secure mode by going from
 EL3 into EL2.

From EL3 you can drop to either EL2 (non-secure) or EL1 (secure or
non-secure), it's the highest privilege level. But we don't support the
kernel entering at EL3, the SoC firmware runs in this mode. I'll try to
make it clearer.

  +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.
 
 I've seen people put firmware for some peripherals into the device tree,
 so that a device driver can grab a blob from there and load it into the
 device, rather than calling request_firmware() which would fail if the
 OS running on the system does not contain the blob. If such firmware is
 too large, you end up violating the 2 MB limit you impose here.
 
 Should we keep that limit and declare those use cases as invalid, or
 should we try to make the boot protocol more flexible?

I would be ok to allowing larger range here but we currently don't get
the information about the size of the dtb early enough to know how much
to map. We could make some other arbitrary choice if needed like being
in the first 16MB of RAM and we map this range.

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Nicolas Pitre]

On Tue, 14 Aug 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

A few minor comments below, otherwise...

Acked-by: Nicolas Pitre n...@linaro.org

 ---
  Documentation/arm64/booting.txt |  141 +++
  arch/arm64/include/asm/setup.h  |   26 ++
  arch/arm64/kernel/head.S|  521 
 +++
  arch/arm64/kernel/setup.c   |  357 +++
  4 files changed, 1045 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..3197820
 --- /dev/null
 +++ b/Documentation/arm64/booting.txt
 @@ -0,0 +1,141 @@
 + Booting AArch64 Linux
 + =
 +
 +Author: Will Deacon will.dea...@arm.com
 +Date  : 25 April 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.

It might be a good idea to specify the minimum information that should 
be contained in the DTB.  Memory size is certainly one such item.

 +3. Decompress the kernel image
 +--
 +
 +Requirement: OPTIONAL
 +
 +The AArch64 kernel does not provide a decompressor and therefore
 +requires gzip decompression to be performed by the boot loader if the
 +default Image.gz target is used.  For bootloaders that do not implement
 +this requirement, the larger Image target is available instead.

Some people will want to use bzip2 or whatever other decompressor du 
jour.  Maybe this shouldn't be gzip specific, or just presented as a 
possible option?

 +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 */
 +
 +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.
 +
 +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.

I think you should mandate that some additional registers be explicitly 
initialized to 0 for possible future usage (and also mentioned in the 
corresponding code comment).  We have that issue on ARM32 where it is 
unclear 

Re: [PATCH v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On 15 August 2012 20:03, Olof Johansson  wrote:
> On Wed, Aug 15, 2012 at 06:37:11PM +0100, Catalin Marinas wrote:
>> If we add machine_desc structure back, we could print which machine was
>> matched. But so far I try to keep the SoC code to a minimum and just do
>> the probing later in the SoC code (of_find_matching_node). Ideally we
>> shouldn't have any SoC code and just keep code in drivers but we'll see
>> how far we can get. We can discuss more details at the KS as I would
>> like the arm-soc team to get involved here.
>
> Interesting approach, I wonder if it'll scale, in particular if it comes
> to needing to do early setup and init. For device-level setup, generic
> will probably work just fine. And if it doesn't, things can be changed
> later. So it sounds like a good start.
>
> Definitely something we should discuss. I suggest not doing it at KS
> though, since only half of the arm-soc team is invited there. So the
> ARM mini-summit or hallway around LPC is a better venue.

I was indeed thinking of the ARM mini-summit or hallway discussions.
The KS has different topics and it wouldn't have been of wide interest
anyway.

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Olof Johansson]

Hi,

On Wed, Aug 15, 2012 at 06:37:11PM +0100, Catalin Marinas wrote:
> Hi Olof,
> 
> > Given the recent development of ARM platforms, you might want to mandate
> > the state of IOMMUs as well (they should probably be off, since there
> > should be no active DMA activity). Graphics would be the exception to
> > this, since if you want to keep scanning out a splash screen, you'll
> > have to keep doing DMA...
> 
> We'll enhance this document as we get hardware as it's not clear whether
> we can simply mandate it to be off. We may have situations with some
> simple IOMMU that is previously set up by the firmware and the kernel
> doesn't get access to it. One example is the System MMU from ARM that
> supports stage 2 (hypervisor) translations and you just run a guest
> kernel without any control of the IOMMU.

Ok, fair enough.

> > > +/*
> > > + * Setup common bits before finally enabling the MMU. Essentially this 
> > > is just
> > > + * loading the page table pointer and vector base registers.
> > > + *
> > > + * On entry to this code, x0 must contain the SCTLR_EL1 value for 
> > > turning on
> > > + * the MMU.
> > > + */
> > > +__enable_mmu:
> > 
> > ENTRY()?
> 
> __enable_mmu is not used outside this file, so no need for ENTRY().
> 
> > > + ldr x5, =vectors
> > > + msr vbar_el1, x5
> > > + msr ttbr0_el1, x25  // load TTBR0
> > > + msr ttbr1_el1, x26  // load TTBR1
> > > + isb
> > > + b   __turn_mmu_on
> > > +ENDPROC(__enable_mmu)
> > 
> > ...or just END()? Same for a few of the other functions below.
> 
> ENDPROC() gives us ".type @function" in addition to END(). This proved
> to be useful in the past for debugging symbols, unwind table (though we
> don't have the latter on AArch64).

A good as reason as any, sounds good.

> > > +static void __init setup_processor(void)
> > > +{
> > > + struct proc_info_list *list;
> > > +
> > > + /*
> > > +  * locate processor in the list of supported processor
> > > +  * types.  The linker builds this table for us from the
> > > +  * entries in arch/arm/mm/proc.S
> > > +  */
> > 
> > Probably from arch/arm64/... somewhere?
> 
> Yes, I did a grep and found a few more.

Yeah, I pointed out some other stale ARM-derived comments in other patches.

> > > + printk("CPU: %s [%08x] revision %d\n",
> > > +cpu_name, read_cpuid_id(), read_cpuid_id() & 15);
> > > +
> > > + sprintf(init_utsname()->machine, "aarch64");
> > 
> > > + initial_boot_params = devtree;
> > > + dt_root = of_get_flat_dt_root();
> > > +
> > > + machine_name = of_get_flat_dt_prop(dt_root, "model", NULL);
> > > + if (!machine_name)
> > > + machine_name = of_get_flat_dt_prop(dt_root, "compatible", NULL);
> > > + if (!machine_name)
> > > + machine_name = "";
> > > + pr_info("Machine: %s\n", machine_name);
> > 
> > This property is an array of strings. It would be more valuable to print out
> > the entry that was matched for a platform instead of the provided one from 
> > the
> > device tree.
> 
> If we add machine_desc structure back, we could print which machine was
> matched. But so far I try to keep the SoC code to a minimum and just do
> the probing later in the SoC code (of_find_matching_node). Ideally we
> shouldn't have any SoC code and just keep code in drivers but we'll see
> how far we can get. We can discuss more details at the KS as I would
> like the arm-soc team to get involved here.

Interesting approach, I wonder if it'll scale, in particular if it comes
to needing to do early setup and init. For device-level setup, generic
will probably work just fine. And if it doesn't, things can be changed
later. So it sounds like a good start.

Definitely something we should discuss. I suggest not doing it at KS
though, since only half of the arm-soc team is invited there. So the
ARM mini-summit or hallway around LPC is a better venue.


-Olof

--
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 v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

Hi Olof,

On Wed, Aug 15, 2012 at 12:06:45AM +0100, Olof Johansson wrote:
> On Tue, Aug 14, 2012 at 06:52:03PM +0100, 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.
> > +
> > +- 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.
> > +
> > +- 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.
> > +
> > +- Coherency
> > +  All CPUs to be booted by the kernel must be part of the same coherency
> > +  domain on entry to the kernel.  This may require IMPLEMENTATION DEFINED
> > +  initialisation to enable the receiving of maintenance operations on
> > +  each CPU.
> > +
> > +- System registers
> > +  All writable architected system registers at the exception level where
> > +  the kernel image will be entered must be initialised by software at a
> > +  higher exception level to prevent execution in an UNKNOWN state.
> 
> Given the recent development of ARM platforms, you might want to mandate
> the state of IOMMUs as well (they should probably be off, since there
> should be no active DMA activity). Graphics would be the exception to
> this, since if you want to keep scanning out a splash screen, you'll
> have to keep doing DMA...

We'll enhance this document as we get hardware as it's not clear whether
we can simply mandate it to be off. We may have situations with some
simple IOMMU that is previously set up by the firmware and the kernel
doesn't get access to it. One example is the System MMU from ARM that
supports stage 2 (hypervisor) translations and you just run a guest
kernel without any control of the IOMMU.

> > +- 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.
> 
> These would be good to have documented in the
> Documentation/devicetree/bindings hierarchy as well.

OK.

> > index 000..d766493
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/setup.h
> > @@ -0,0 +1,26 @@
> > +/*
> > + * Based on arch/arm/include/asm/setup.h
> > + *
> > + * Copyright (C) 1997-1999 Russell King
> > + * Copyright (C) 2012 ARM Ltd.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program.  If not, see .
> > + */
> > +#ifndef __ASM_SETUP_H
> > +#define __ASM_SETUP_H
> > +
> > +#include 
> > +
> > +#define COMMAND_LINE_SIZE 1024
> 
> Probably not a huge deal, and other architectures seem to be all over
> the map on this, but you might want to go with a larger value now rather
> than later. 2048 or 4096 perhaps?

It looks like there are many different values, including the asm-generic
one which is 512. I'm happy to follow the x86 example and change it to
2048, it doesn't really matter.

> > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > new file mode 100644
> > index 000..34ccdc0
> > --- /dev/null
> > +++ b/arch/arm64/kernel/head.S
> 
> [...]
> 
> > +/*
> > + * Setup common bits before finally enabling the MMU. Essentially this is 
> > just
> > + * loading the page table pointer and vector base registers.
> > + *
> > + * On entry to this code, x0 must contain the SCTLR_EL1 value for turning 
> > on
> > + * the MMU.
> > + */
> > +__enable_mmu:
> 
> ENTRY()?

__enable_mmu is not used outside this file, so no need for ENTRY().

> > +   ldr x5, =vectors
> > +   msr vbar_el1, x5
> > +   msr ttbr0_el1, x25  // load TTBR0
> > +   msr 

Re: [PATCH v2 02/31] arm64: Kernel booting and initialisation

[Olof Johansson]

On Wed, Aug 15, 2012 at 01:20:02PM +, Arnd Bergmann wrote:
> On Tuesday 14 August 2012, Catalin Marinas wrote:
> 
> > +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.
> 
> I'm always confused by a description like this. It sounds like you cannot
> have a hypervisor if you have code running in secure mode in EL3. What
> I instead understand is that you enter non-secure mode by going from
> EL3 into EL2.
> 
> > +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.
> 
> I've seen people put firmware for some peripherals into the device tree,
> so that a device driver can grab a blob from there and load it into the
> device, rather than calling request_firmware() which would fail if the
> OS running on the system does not contain the blob. If such firmware is
> too large, you end up violating the 2 MB limit you impose here.
> 
> Should we keep that limit and declare those use cases as invalid, or
> should we try to make the boot protocol more flexible?
> 
> > diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
> > new file mode 100644
> > index 000..d766493
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/setup.h
> > @@ -0,0 +1,26 @@
> > +#ifndef __ASM_SETUP_H
> > +#define __ASM_SETUP_H
> > +
> > +#include 
> > +
> > +#define COMMAND_LINE_SIZE 1024
> > +
> > +#endif
> 
> Is this necessary? The asm-generic version of this file allows 512 bytes,
> which seems plenty.

Chrome OS on my system today uses a 553 character cmdline, in particular
because some of the device mapper arguments are in there (since we boot without
ramdisk). It adds up quickly.

I suggest keeping it common with x86 since those limits are what people
will be used to (2048).


-Olof
--
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 v2 02/31] arm64: Kernel booting and initialisation

[Arnd Bergmann]

On Tuesday 14 August 2012, Catalin Marinas wrote:

> +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.

I'm always confused by a description like this. It sounds like you cannot
have a hypervisor if you have code running in secure mode in EL3. What
I instead understand is that you enter non-secure mode by going from
EL3 into EL2.

> +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.

I've seen people put firmware for some peripherals into the device tree,
so that a device driver can grab a blob from there and load it into the
device, rather than calling request_firmware() which would fail if the
OS running on the system does not contain the blob. If such firmware is
too large, you end up violating the 2 MB limit you impose here.

Should we keep that limit and declare those use cases as invalid, or
should we try to make the boot protocol more flexible?

> diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
> new file mode 100644
> index 000..d766493
> --- /dev/null
> +++ b/arch/arm64/include/asm/setup.h
> @@ -0,0 +1,26 @@
> +#ifndef __ASM_SETUP_H
> +#define __ASM_SETUP_H
> +
> +#include 
> +
> +#define COMMAND_LINE_SIZE 1024
> +
> +#endif

Is this necessary? The asm-generic version of this file allows 512 bytes,
which seems plenty.

> +unsigned int processor_id;
> +EXPORT_SYMBOL(processor_id);
> +
> +unsigned int elf_hwcap __read_mostly;
> +EXPORT_SYMBOL(elf_hwcap);

EXPORT_SYMBOL_GPL?

Neither of these looks like they should be used in drivers.

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 v2 02/31] arm64: Kernel booting and initialisation

[Arnd Bergmann]

On Tuesday 14 August 2012, Catalin Marinas wrote:

 +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.

I'm always confused by a description like this. It sounds like you cannot
have a hypervisor if you have code running in secure mode in EL3. What
I instead understand is that you enter non-secure mode by going from
EL3 into EL2.

 +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.

I've seen people put firmware for some peripherals into the device tree,
so that a device driver can grab a blob from there and load it into the
device, rather than calling request_firmware() which would fail if the
OS running on the system does not contain the blob. If such firmware is
too large, you end up violating the 2 MB limit you impose here.

Should we keep that limit and declare those use cases as invalid, or
should we try to make the boot protocol more flexible?

 diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
 new file mode 100644
 index 000..d766493
 --- /dev/null
 +++ b/arch/arm64/include/asm/setup.h
 @@ -0,0 +1,26 @@
 +#ifndef __ASM_SETUP_H
 +#define __ASM_SETUP_H
 +
 +#include linux/types.h
 +
 +#define COMMAND_LINE_SIZE 1024
 +
 +#endif

Is this necessary? The asm-generic version of this file allows 512 bytes,
which seems plenty.

 +unsigned int processor_id;
 +EXPORT_SYMBOL(processor_id);
 +
 +unsigned int elf_hwcap __read_mostly;
 +EXPORT_SYMBOL(elf_hwcap);

EXPORT_SYMBOL_GPL?

Neither of these looks like they should be used in drivers.

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 v2 02/31] arm64: Kernel booting and initialisation

[Olof Johansson]

On Wed, Aug 15, 2012 at 01:20:02PM +, Arnd Bergmann wrote:
 On Tuesday 14 August 2012, Catalin Marinas wrote:
 
  +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.
 
 I'm always confused by a description like this. It sounds like you cannot
 have a hypervisor if you have code running in secure mode in EL3. What
 I instead understand is that you enter non-secure mode by going from
 EL3 into EL2.
 
  +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.
 
 I've seen people put firmware for some peripherals into the device tree,
 so that a device driver can grab a blob from there and load it into the
 device, rather than calling request_firmware() which would fail if the
 OS running on the system does not contain the blob. If such firmware is
 too large, you end up violating the 2 MB limit you impose here.
 
 Should we keep that limit and declare those use cases as invalid, or
 should we try to make the boot protocol more flexible?
 
  diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
  new file mode 100644
  index 000..d766493
  --- /dev/null
  +++ b/arch/arm64/include/asm/setup.h
  @@ -0,0 +1,26 @@
  +#ifndef __ASM_SETUP_H
  +#define __ASM_SETUP_H
  +
  +#include linux/types.h
  +
  +#define COMMAND_LINE_SIZE 1024
  +
  +#endif
 
 Is this necessary? The asm-generic version of this file allows 512 bytes,
 which seems plenty.

Chrome OS on my system today uses a 553 character cmdline, in particular
because some of the device mapper arguments are in there (since we boot without
ramdisk). It adds up quickly.

I suggest keeping it common with x86 since those limits are what people
will be used to (2048).


-Olof
--
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 v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

Hi Olof,

On Wed, Aug 15, 2012 at 12:06:45AM +0100, Olof Johansson wrote:
 On Tue, Aug 14, 2012 at 06:52:03PM +0100, 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.
  +
  +- 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.
  +
  +- 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.
  +
  +- Coherency
  +  All CPUs to be booted by the kernel must be part of the same coherency
  +  domain on entry to the kernel.  This may require IMPLEMENTATION DEFINED
  +  initialisation to enable the receiving of maintenance operations on
  +  each CPU.
  +
  +- System registers
  +  All writable architected system registers at the exception level where
  +  the kernel image will be entered must be initialised by software at a
  +  higher exception level to prevent execution in an UNKNOWN state.
 
 Given the recent development of ARM platforms, you might want to mandate
 the state of IOMMUs as well (they should probably be off, since there
 should be no active DMA activity). Graphics would be the exception to
 this, since if you want to keep scanning out a splash screen, you'll
 have to keep doing DMA...

We'll enhance this document as we get hardware as it's not clear whether
we can simply mandate it to be off. We may have situations with some
simple IOMMU that is previously set up by the firmware and the kernel
doesn't get access to it. One example is the System MMU from ARM that
supports stage 2 (hypervisor) translations and you just run a guest
kernel without any control of the IOMMU.

  +- 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.
 
 These would be good to have documented in the
 Documentation/devicetree/bindings hierarchy as well.

OK.

  index 000..d766493
  --- /dev/null
  +++ b/arch/arm64/include/asm/setup.h
  @@ -0,0 +1,26 @@
  +/*
  + * Based on arch/arm/include/asm/setup.h
  + *
  + * Copyright (C) 1997-1999 Russell King
  + * Copyright (C) 2012 ARM Ltd.
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License version 2 as
  + * published by the Free Software Foundation.
  + *
  + * This program is distributed in the hope that it will be useful,
  + * but WITHOUT ANY WARRANTY; without even the implied warranty of
  + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  + * GNU General Public License for more details.
  + *
  + * You should have received a copy of the GNU General Public License
  + * along with this program.  If not, see http://www.gnu.org/licenses/.
  + */
  +#ifndef __ASM_SETUP_H
  +#define __ASM_SETUP_H
  +
  +#include linux/types.h
  +
  +#define COMMAND_LINE_SIZE 1024
 
 Probably not a huge deal, and other architectures seem to be all over
 the map on this, but you might want to go with a larger value now rather
 than later. 2048 or 4096 perhaps?

It looks like there are many different values, including the asm-generic
one which is 512. I'm happy to follow the x86 example and change it to
2048, it doesn't really matter.

  diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
  new file mode 100644
  index 000..34ccdc0
  --- /dev/null
  +++ b/arch/arm64/kernel/head.S
 
 [...]
 
  +/*
  + * Setup common bits before finally enabling the MMU. Essentially this is 
  just
  + * loading the page table pointer and vector base registers.
  + *
  + * On entry to this code, x0 must contain the SCTLR_EL1 value for turning 
  on
  + * the MMU.
  + */
  +__enable_mmu:
 
 ENTRY()?

__enable_mmu is not used outside this file, so no need for ENTRY().

  +   ldr x5, =vectors
  +   msr vbar_el1, x5
  +   msr ttbr0_el1, x25  // load TTBR0
  +   msr ttbr1_el1, x26  // load TTBR1
  +   isb
  +   b   __turn_mmu_on
  +ENDPROC(__enable_mmu)
 
 ...or just END()? Same for a few of the other functions below.

ENDPROC() gives us 

Re: [PATCH v2 02/31] arm64: Kernel booting and initialisation

[Olof Johansson]

Hi,

On Wed, Aug 15, 2012 at 06:37:11PM +0100, Catalin Marinas wrote:
 Hi Olof,
 
  Given the recent development of ARM platforms, you might want to mandate
  the state of IOMMUs as well (they should probably be off, since there
  should be no active DMA activity). Graphics would be the exception to
  this, since if you want to keep scanning out a splash screen, you'll
  have to keep doing DMA...
 
 We'll enhance this document as we get hardware as it's not clear whether
 we can simply mandate it to be off. We may have situations with some
 simple IOMMU that is previously set up by the firmware and the kernel
 doesn't get access to it. One example is the System MMU from ARM that
 supports stage 2 (hypervisor) translations and you just run a guest
 kernel without any control of the IOMMU.

Ok, fair enough.

   +/*
   + * Setup common bits before finally enabling the MMU. Essentially this 
   is just
   + * loading the page table pointer and vector base registers.
   + *
   + * On entry to this code, x0 must contain the SCTLR_EL1 value for 
   turning on
   + * the MMU.
   + */
   +__enable_mmu:
  
  ENTRY()?
 
 __enable_mmu is not used outside this file, so no need for ENTRY().
 
   + ldr x5, =vectors
   + msr vbar_el1, x5
   + msr ttbr0_el1, x25  // load TTBR0
   + msr ttbr1_el1, x26  // load TTBR1
   + isb
   + b   __turn_mmu_on
   +ENDPROC(__enable_mmu)
  
  ...or just END()? Same for a few of the other functions below.
 
 ENDPROC() gives us .type @function in addition to END(). This proved
 to be useful in the past for debugging symbols, unwind table (though we
 don't have the latter on AArch64).

A good as reason as any, sounds good.

   +static void __init setup_processor(void)
   +{
   + struct proc_info_list *list;
   +
   + /*
   +  * locate processor in the list of supported processor
   +  * types.  The linker builds this table for us from the
   +  * entries in arch/arm/mm/proc.S
   +  */
  
  Probably from arch/arm64/... somewhere?
 
 Yes, I did a grep and found a few more.

Yeah, I pointed out some other stale ARM-derived comments in other patches.

   + printk(CPU: %s [%08x] revision %d\n,
   +cpu_name, read_cpuid_id(), read_cpuid_id()  15);
   +
   + sprintf(init_utsname()-machine, aarch64);
  
   + initial_boot_params = devtree;
   + dt_root = of_get_flat_dt_root();
   +
   + machine_name = of_get_flat_dt_prop(dt_root, model, NULL);
   + if (!machine_name)
   + machine_name = of_get_flat_dt_prop(dt_root, compatible, NULL);
   + if (!machine_name)
   + machine_name = unknown;
   + pr_info(Machine: %s\n, machine_name);
  
  This property is an array of strings. It would be more valuable to print out
  the entry that was matched for a platform instead of the provided one from 
  the
  device tree.
 
 If we add machine_desc structure back, we could print which machine was
 matched. But so far I try to keep the SoC code to a minimum and just do
 the probing later in the SoC code (of_find_matching_node). Ideally we
 shouldn't have any SoC code and just keep code in drivers but we'll see
 how far we can get. We can discuss more details at the KS as I would
 like the arm-soc team to get involved here.

Interesting approach, I wonder if it'll scale, in particular if it comes
to needing to do early setup and init. For device-level setup, generic
will probably work just fine. And if it doesn't, things can be changed
later. So it sounds like a good start.

Definitely something we should discuss. I suggest not doing it at KS
though, since only half of the arm-soc team is invited there. So the
ARM mini-summit or hallway around LPC is a better venue.


-Olof

--
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 v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

On 15 August 2012 20:03, Olof Johansson o...@lixom.net wrote:
 On Wed, Aug 15, 2012 at 06:37:11PM +0100, Catalin Marinas wrote:
 If we add machine_desc structure back, we could print which machine was
 matched. But so far I try to keep the SoC code to a minimum and just do
 the probing later in the SoC code (of_find_matching_node). Ideally we
 shouldn't have any SoC code and just keep code in drivers but we'll see
 how far we can get. We can discuss more details at the KS as I would
 like the arm-soc team to get involved here.

 Interesting approach, I wonder if it'll scale, in particular if it comes
 to needing to do early setup and init. For device-level setup, generic
 will probably work just fine. And if it doesn't, things can be changed
 later. So it sounds like a good start.

 Definitely something we should discuss. I suggest not doing it at KS
 though, since only half of the arm-soc team is invited there. So the
 ARM mini-summit or hallway around LPC is a better venue.

I was indeed thinking of the ARM mini-summit or hallway discussions.
The KS has different topics and it wouldn't have been of wide interest
anyway.

-- 
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 v2 02/31] arm64: Kernel booting and initialisation

[Olof Johansson]

Hi,


On Tue, Aug 14, 2012 at 06:52:03PM +0100, 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.
> +
> +- 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.
> +
> +- 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.
> +
> +- Coherency
> +  All CPUs to be booted by the kernel must be part of the same coherency
> +  domain on entry to the kernel.  This may require IMPLEMENTATION DEFINED
> +  initialisation to enable the receiving of maintenance operations on
> +  each CPU.
> +
> +- System registers
> +  All writable architected system registers at the exception level where
> +  the kernel image will be entered must be initialised by software at a
> +  higher exception level to prevent execution in an UNKNOWN state.

Given the recent development of ARM platforms, you might want to mandate
the state of IOMMUs as well (they should probably be off, since there
should be no active DMA activity). Graphics would be the exception to
this, since if you want to keep scanning out a splash screen, you'll
have to keep doing DMA...

> +- 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.

These would be good to have documented in the
Documentation/devicetree/bindings hierarchy as well.

> index 000..d766493
> --- /dev/null
> +++ b/arch/arm64/include/asm/setup.h
> @@ -0,0 +1,26 @@
> +/*
> + * Based on arch/arm/include/asm/setup.h
> + *
> + * Copyright (C) 1997-1999 Russell King
> + * Copyright (C) 2012 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +#ifndef __ASM_SETUP_H
> +#define __ASM_SETUP_H
> +
> +#include 
> +
> +#define COMMAND_LINE_SIZE 1024

Probably not a huge deal, and other architectures seem to be all over
the map on this, but you might want to go with a larger value now rather
than later. 2048 or 4096 perhaps?

> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> new file mode 100644
> index 000..34ccdc0
> --- /dev/null
> +++ b/arch/arm64/kernel/head.S

[...]

> +/*
> + * Setup common bits before finally enabling the MMU. Essentially this is 
> just
> + * loading the page table pointer and vector base registers.
> + *
> + * On entry to this code, x0 must contain the SCTLR_EL1 value for turning on
> + * the MMU.
> + */
> +__enable_mmu:

ENTRY()?

> + ldr x5, =vectors
> + msr vbar_el1, x5
> + msr ttbr0_el1, x25  // load TTBR0
> + msr ttbr1_el1, x26  // load TTBR1
> + isb
> + b   __turn_mmu_on
> +ENDPROC(__enable_mmu)

...or just END()? Same for a few of the other functions below.

> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> new file mode 100644
> index 000..f25186f
> --- /dev/null
> +++ b/arch/arm64/kernel/setup.c

[...]

> +static void __init setup_processor(void)
> +{
> + struct proc_info_list *list;
> +
> + /*
> +  * locate processor in the list of supported processor
> +  * types.  The linker builds this table for us from the
> +  * entries in arch/arm/mm/proc.S
> +  */

Probably from arch/arm64/... somewhere?


[...]

> + printk("CPU: %s [%08x] revision %d\n",
> +cpu_name, read_cpuid_id(), read_cpuid_id() & 15);
> +
> + sprintf(init_utsname()->machine, "aarch64");

> + initial_boot_params = devtree;
> + dt_root = 

[PATCH v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

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 
---
 Documentation/arm64/booting.txt |  141 +++
 arch/arm64/include/asm/setup.h  |   26 ++
 arch/arm64/kernel/head.S|  521 +++
 arch/arm64/kernel/setup.c   |  357 +++
 4 files changed, 1045 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..3197820
--- /dev/null
+++ b/Documentation/arm64/booting.txt
@@ -0,0 +1,141 @@
+   Booting AArch64 Linux
+   =
+
+Author: Will Deacon 
+Date  : 25 April 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.
+
+
+3. Decompress the kernel image
+--
+
+Requirement: OPTIONAL
+
+The AArch64 kernel does not provide a decompressor and therefore
+requires gzip decompression to be performed by the boot loader if the
+default Image.gz target is used.  For bootloaders that do not implement
+this requirement, the larger 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 */
+
+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.
+
+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.
+
+- 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.
+
+- 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.
+
+- Coherency
+  All CPUs to be booted by the kernel must be part of the same coherency
+  domain on entry to the kernel.  This may require IMPLEMENTATION DEFINED
+  initialisation to enable the receiving of maintenance operations on
+  each CPU.
+
+- System registers
+  

[PATCH v2 02/31] arm64: Kernel booting and initialisation

[Catalin Marinas]

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
---
 Documentation/arm64/booting.txt |  141 +++
 arch/arm64/include/asm/setup.h  |   26 ++
 arch/arm64/kernel/head.S|  521 +++
 arch/arm64/kernel/setup.c   |  357 +++
 4 files changed, 1045 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..3197820
--- /dev/null
+++ b/Documentation/arm64/booting.txt
@@ -0,0 +1,141 @@
+   Booting AArch64 Linux
+   =
+
+Author: Will Deacon will.dea...@arm.com
+Date  : 25 April 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.
+
+
+3. Decompress the kernel image
+--
+
+Requirement: OPTIONAL
+
+The AArch64 kernel does not provide a decompressor and therefore
+requires gzip decompression to be performed by the boot loader if the
+default Image.gz target is used.  For bootloaders that do not implement
+this requirement, the larger 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 */
+
+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.
+
+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.
+
+- 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.
+
+- 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.
+
+- Coherency
+  All CPUs to be booted by the kernel must be part of the same coherency
+  domain on entry to the kernel.  This may require IMPLEMENTATION DEFINED
+  initialisation to enable the receiving of 

Re: [PATCH v2 02/31] arm64: Kernel booting and initialisation

[Olof Johansson]

Hi,


On Tue, Aug 14, 2012 at 06:52:03PM +0100, 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.
 +
 +- 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.
 +
 +- 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.
 +
 +- Coherency
 +  All CPUs to be booted by the kernel must be part of the same coherency
 +  domain on entry to the kernel.  This may require IMPLEMENTATION DEFINED
 +  initialisation to enable the receiving of maintenance operations on
 +  each CPU.
 +
 +- System registers
 +  All writable architected system registers at the exception level where
 +  the kernel image will be entered must be initialised by software at a
 +  higher exception level to prevent execution in an UNKNOWN state.

Given the recent development of ARM platforms, you might want to mandate
the state of IOMMUs as well (they should probably be off, since there
should be no active DMA activity). Graphics would be the exception to
this, since if you want to keep scanning out a splash screen, you'll
have to keep doing DMA...

 +- 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.

These would be good to have documented in the
Documentation/devicetree/bindings hierarchy as well.

 index 000..d766493
 --- /dev/null
 +++ b/arch/arm64/include/asm/setup.h
 @@ -0,0 +1,26 @@
 +/*
 + * Based on arch/arm/include/asm/setup.h
 + *
 + * Copyright (C) 1997-1999 Russell King
 + * Copyright (C) 2012 ARM Ltd.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + */
 +#ifndef __ASM_SETUP_H
 +#define __ASM_SETUP_H
 +
 +#include linux/types.h
 +
 +#define COMMAND_LINE_SIZE 1024

Probably not a huge deal, and other architectures seem to be all over
the map on this, but you might want to go with a larger value now rather
than later. 2048 or 4096 perhaps?

 diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
 new file mode 100644
 index 000..34ccdc0
 --- /dev/null
 +++ b/arch/arm64/kernel/head.S

[...]

 +/*
 + * Setup common bits before finally enabling the MMU. Essentially this is 
 just
 + * loading the page table pointer and vector base registers.
 + *
 + * On entry to this code, x0 must contain the SCTLR_EL1 value for turning on
 + * the MMU.
 + */
 +__enable_mmu:

ENTRY()?

 + ldr x5, =vectors
 + msr vbar_el1, x5
 + msr ttbr0_el1, x25  // load TTBR0
 + msr ttbr1_el1, x26  // load TTBR1
 + isb
 + b   __turn_mmu_on
 +ENDPROC(__enable_mmu)

...or just END()? Same for a few of the other functions below.

 diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
 new file mode 100644
 index 000..f25186f
 --- /dev/null
 +++ b/arch/arm64/kernel/setup.c

[...]

 +static void __init setup_processor(void)
 +{
 + struct proc_info_list *list;
 +
 + /*
 +  * locate processor in the list of supported processor
 +  * types.  The linker builds this table for us from the
 +  * entries in arch/arm/mm/proc.S
 +  */

Probably from arch/arm64/... somewhere?


[...]

 + printk(CPU: %s [%08x] revision %d\n,
 +cpu_name, read_cpuid_id(), read_cpuid_id()  15);
 +
 + sprintf(init_utsname()-machine, aarch64);

 + initial_boot_params = devtree;
 + dt_root = of_get_flat_dt_root();
 +
 + machine_name = of_get_flat_dt_prop(dt_root, model, NULL);
 + if (!machine_name)
 +