From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation
Date: Wed, 12 Sep 2012 14:08:58 +0200 [thread overview]
Message-ID: <20120912120858.GI31430@game.jcrosoft.org> (raw)
In-Reply-To: <20120910161159.GH27042@arm.com>
On 17:11 Mon 10 Sep , Catalin Marinas wrote:
> On Sun, Sep 09, 2012 at 06:20:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 17:26 Fri 07 Sep , Catalin Marinas wrote:
> > > +The device tree blob (dtb) must be no bigger than 2 megabytes in size
> > > +and placed at a 2-megabyte boundary within the first 512 megabytes from
> > > +the start of the kernel image. This is to allow the kernel to map the
> > > +blob using a single section mapping in the initial page tables.
> > why do you want to restrict the DT to be less tahn 2MiB?
>
> That's a restriction due on the initial memory map. At some point we may
> add support in head.S to parse the dtb and extract the size information.
> Not critical at this stage.
>
> > > +Before jumping into the kernel, the following conditions must be met:
> > > +
> > > +- Quiesce all DMA capable devices so that memory does not get
> > > + corrupted by bogus network packets or disk data. This will save
> > > + you many hours of debug.
> > > +
> > > +- Primary CPU general-purpose register settings
> > > + x0 = physical address of device tree blob (dtb) in system RAM.
> > > + x1 = 0 (reserved for future use)
> > > + x2 = 0 (reserved for future use)
> > > + x3 = 0 (reserved for future use)
> > > +
> > > +- CPU mode
> > > + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
> > > + IRQ and FIQ).
> > > + The CPU must be in either EL2 (RECOMMENDED in order to have access to
> > > + the virtualisation extensions) or non-secure EL1.
> > > +
> > > +- Caches, MMUs
> > > + The MMU must be off.
> > > + Instruction cache may be on or off.
> > > + Data cache must be off and invalidated.
> > > + External caches (if present) must be configured and disabled.
> > > +
> > > +- Architected timers
> > > + CNTFRQ must be programmed with the timer frequency.
> > > + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0)
> > > + set where available.
> > can you explain why?
>
> Otherwise the kernel cannot access the generic timer registers (it is
> described in the AArch64 exception model which isn't public yet).
I do not like the idea to do too much in the boot loader
can we drop it and do it the head.S or find an other way
>
> > > +- The primary CPU must jump directly to the first instruction of the
> > > + kernel image. The device tree blob passed by this CPU must contain
> > > + for each CPU node:
> > > +
> > > + 1. An 'enable-method' property. Currently, the only supported value
> > > + for this field is the string "spin-table".
> > > +
> > > + 2. A 'cpu-release-addr' property identifying a 64-bit,
> > > + zero-initialised memory location.
> > > +
> > > + It is expected that the bootloader will generate these device tree
> > > + properties and insert them into the blob prior to kernel entry.
> > > +
> > > +- Any secondary CPUs must spin outside of the kernel in a reserved area
> > > + of memory (communicated to the kernel by a /memreserve/ region in the
> > > + device tree) polling their cpu-release-addr location, which must be
> > > + contained in the reserved region. A wfe instruction may be inserted
> > > + to reduce the overhead of the busy-loop and a sev will be issued by
> > > + the primary CPU. When a read of the location pointed to by the
> > > + cpu-release-addr returns a non-zero value, the CPU must jump directly
> > > + to this value.
> > do you plan AMP boot?
>
> What do you mean by AMP?
>
> If you only want to use 3 CPUs out of 4 for example, you change the FDT
> information that gets passed to the kernel accordingly. So the kernel
> wouldn't touch the 4th one.
I mean boot a different kernel in each core as example
Best Regards,
J.
next prev parent reply other threads:[~2012-09-12 12:11 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-07 16:26 [PATCH v3 00/31] AArch64 Linux kernel port Catalin Marinas
2012-09-07 16:26 ` [PATCH v3 01/31] arm64: Assembly macros and definitions Catalin Marinas
2012-09-07 16:26 ` [PATCH v3 02/31] arm64: Kernel booting and initialisation Catalin Marinas
2012-09-07 19:07 ` Arnd Bergmann
2012-09-09 17:20 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-09 23:29 ` Nicolas Pitre
2012-09-10 5:53 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-10 12:51 ` Catalin Marinas
2012-09-10 13:53 ` Arnd Bergmann
2012-09-10 14:12 ` Nicolas Pitre
2012-09-10 14:48 ` Arnd Bergmann
2012-09-10 14:53 ` Catalin Marinas
2012-09-10 15:00 ` Nicolas Pitre
2012-09-10 15:21 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-10 16:08 ` Catalin Marinas
2012-09-10 16:29 ` Nicolas Pitre
2012-09-10 20:28 ` Jon Masters
2012-09-10 16:11 ` Catalin Marinas
2012-09-12 12:08 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2012-09-12 13:49 ` Catalin Marinas
2012-09-13 15:56 ` Christopher Covington
2012-09-13 17:11 ` Catalin Marinas
2012-09-07 16:26 ` [PATCH v3 03/31] arm64: Exception handling Catalin Marinas
2012-09-07 19:09 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 04/31] arm64: MMU definitions Catalin Marinas
2012-09-07 19:10 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 05/31] arm64: MMU initialisation Catalin Marinas
2012-09-07 19:10 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 06/31] arm64: MMU fault handling and page table management Catalin Marinas
2012-09-07 19:11 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 07/31] arm64: Process management Catalin Marinas
2012-09-07 19:20 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 08/31] arm64: CPU support Catalin Marinas
2012-09-07 19:24 ` Arnd Bergmann
2012-09-10 16:43 ` Catalin Marinas
2012-09-07 16:26 ` [PATCH v3 09/31] arm64: Cache maintenance routines Catalin Marinas
2012-09-07 19:28 ` Arnd Bergmann
2012-09-10 16:48 ` Catalin Marinas
2012-09-10 17:29 ` Nicolas Pitre
2012-09-14 16:53 ` Catalin Marinas
2012-09-07 19:35 ` Simon Baatz
2012-09-12 9:29 ` Catalin Marinas
2012-09-12 21:55 ` Simon Baatz
2012-09-13 12:38 ` Catalin Marinas
2012-09-13 20:14 ` Simon Baatz
2012-09-07 16:26 ` [PATCH v3 10/31] arm64: TLB maintenance functionality Catalin Marinas
2012-09-07 19:28 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 11/31] arm64: IRQ handling Catalin Marinas
2012-09-07 19:37 ` Arnd Bergmann
2012-09-12 10:24 ` Catalin Marinas
2012-09-07 16:26 ` [PATCH v3 12/31] arm64: Atomic operations Catalin Marinas
2012-09-07 19:37 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 13/31] arm64: Device specific operations Catalin Marinas
2012-09-07 16:26 ` [PATCH v3 14/31] arm64: DMA mapping API Catalin Marinas
2012-09-07 19:38 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 15/31] arm64: SMP support Catalin Marinas
2012-09-07 19:39 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 16/31] arm64: ELF definitions Catalin Marinas
2012-09-07 19:40 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 17/31] arm64: System calls handling Catalin Marinas
2012-09-07 19:43 ` Arnd Bergmann
2012-09-07 19:54 ` Al Viro
2012-09-10 9:56 ` Catalin Marinas
2012-09-10 13:51 ` Arnd Bergmann
2012-09-10 14:01 ` Catalin Marinas
2012-09-10 14:24 ` Arnd Bergmann
2012-09-10 15:50 ` Catalin Marinas
2012-09-07 16:26 ` [PATCH v3 18/31] arm64: VDSO support Catalin Marinas
2012-09-07 19:44 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 19/31] arm64: Signal handling support Catalin Marinas
2012-09-07 16:26 ` [PATCH v3 20/31] arm64: User access library functions Catalin Marinas
2012-09-07 19:46 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 21/31] arm64: 32-bit (compat) applications support Catalin Marinas
2012-09-07 19:47 ` Arnd Bergmann
2012-09-13 9:07 ` Catalin Marinas
2012-09-13 11:03 ` Arnd Bergmann
2012-09-13 15:50 ` Catalin Marinas
2012-09-07 16:26 ` [PATCH v3 22/31] arm64: Floating point and SIMD Catalin Marinas
2012-09-07 16:26 ` [PATCH v3 23/31] arm64: Debugging support Catalin Marinas
2012-09-07 19:49 ` Arnd Bergmann
2012-09-07 16:26 ` [PATCH v3 24/31] arm64: Add support for /proc/sys/debug/exception-trace Catalin Marinas
2012-09-07 16:27 ` [PATCH v3 25/31] arm64: Performance counters support Catalin Marinas
2012-09-07 16:27 ` [PATCH v3 26/31] arm64: Miscellaneous library functions Catalin Marinas
2012-09-07 19:52 ` Arnd Bergmann
2012-09-12 21:12 ` Catalin Marinas
2012-09-13 10:48 ` Arnd Bergmann
2012-09-07 16:27 ` [PATCH v3 27/31] arm64: Loadable modules Catalin Marinas
2012-09-07 19:52 ` Arnd Bergmann
2012-09-07 16:27 ` [PATCH v3 28/31] arm64: Generic timers support Catalin Marinas
2012-09-07 19:53 ` Arnd Bergmann
2012-09-08 8:28 ` Shilimkar, Santosh
2012-09-07 16:27 ` [PATCH v3 29/31] arm64: Miscellaneous header files Catalin Marinas
2012-09-07 19:54 ` Arnd Bergmann
2012-09-07 16:27 ` [PATCH v3 30/31] arm64: Build infrastructure Catalin Marinas
2012-09-07 19:55 ` Arnd Bergmann
2012-09-07 16:27 ` [PATCH v3 31/31] arm64: MAINTAINERS update Catalin Marinas
2012-09-09 16:31 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-10 17:57 ` Nicolas Pitre
2012-09-10 21:17 ` Russell King - ARM Linux
2012-09-10 23:31 ` Nicolas Pitre
2012-09-07 23:25 ` [PATCH v3 00/31] AArch64 Linux kernel port Olof Johansson
2012-09-12 14:54 ` Catalin Marinas
2012-09-08 9:18 ` Santosh Shilimkar
2012-09-08 13:59 ` Nicolas Pitre
2012-09-08 14:42 ` Shilimkar, Santosh
2012-09-10 17:53 ` Nicolas Pitre
2012-09-10 20:22 ` Jon Masters
2012-09-12 11:54 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120912120858.GI31430@game.jcrosoft.org \
--to=plagnioj@jcrosoft.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).