From patchwork Wed May 29 13:55:57 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Grant Likely X-Patchwork-Id: 2629871 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by patchwork2.kernel.org (Postfix) with ESMTP id 4BCF4DF24C for ; Wed, 29 May 2013 13:56:39 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Uhgrl-00086T-SL; Wed, 29 May 2013 13:56:38 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Uhgri-0006ym-Uz; Wed, 29 May 2013 13:56:34 +0000 Received: from mail-wi0-f171.google.com ([209.85.212.171]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Uhgrf-0006xp-8x for linux-arm-kernel@lists.infradead.org; Wed, 29 May 2013 13:56:32 +0000 Received: by mail-wi0-f171.google.com with SMTP id hq7so3554826wib.16 for ; Wed, 29 May 2013 06:56:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:cc:subject:date:message-id:x-mailer :x-gm-message-state; bh=FrQXA+jrN+iZq67v2xjRu39lsWF7XtSrqEppeutYCtg=; b=BvtrLMv0NLJeQI9+sy29PVPt34+vOESBiUq/Q/2PG+SAmlNc/rrzFjRifyoW0412z8 eKwoUhC/FF8O3ZoDOmyGVrQ2K20kR8TjhygrPnUSO/n7yF7NrcSl4/KO78BP3sifR0zk sxquqfpYe91yegBsvqBLdUvQZceNfvPFuiQCvqPv7eMjeNbamlp899rhJcqAQgs7vdPc zukQkivmgj3x3XupUfdJsW2eyUz/WtyWrqGhPDfs4jXJCEZzYXOyDneqUeoikYtO/lbM T48QBTO46sN4qe5q5+Cr7seGfhd1VdVjDEHCjGe4hxQIK2PF2lcrDmy1CZi3hE2K751s FRGg== X-Received: by 10.194.8.163 with SMTP id s3mr1776978wja.41.1369835766566; Wed, 29 May 2013 06:56:06 -0700 (PDT) Received: from localhost (host86-179-79-222.range86-179.btcentralplus.com. [86.179.79.222]) by mx.google.com with ESMTPSA id w8sm36065404wiz.0.2013.05.29.06.56.04 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 06:56:05 -0700 (PDT) Received: by localhost (Postfix, from userid 1000) id 83E033E131B; Wed, 29 May 2013 14:56:04 +0100 (BST) From: Grant Likely To: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [RFC] arm: Update Booting document for FDT placement and reserved map Date: Wed, 29 May 2013 14:55:57 +0100 Message-Id: <1369835757-16371-1-git-send-email-grant.likely@linaro.org> X-Mailer: git-send-email 1.8.1.2 X-Gm-Message-State: ALoCoQlwcN9wp0RIbWvNvQA00gZjhefHoQZE/7JgWYCmUwzTCdnUdwNOxR0OqyXNZffqs1fktRyk X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130529_095631_406799_F3EEEB00 X-CRM114-Status: GOOD ( 23.31 ) X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.212.171 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Russell King , Olivier Martin , Nicolas Pitre , Marc Zyngier , Catalin Marinas , Leif Lindholm , Grant Likely X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org The Booting document isn't very clear about what a bootloader is required to do when booting with an FDT. First, the placement of the FDT isn't as strict as the document suggests. It can actually appear anywhere in RAM and the decompressor will relocated if it absolutely needs to (but it is better if it doesn't have to). Second, the bootloader is expected to update the reserved map if there are any memory regions that are hands-off for the firmware. While this has always been the case, such as when an initrd is provided, it became more obvious when starting to work with UEFI. UEFI may provide additional data to the OS like a block of SMBIOS tables, but if those regions aren't described in the reserved map then the kernel will happily reclaim that memory for it's own purposes. It is possible in the future when the kernel is able to parse UEFI memory maps directly that we'll relax the requirement for UEFI regions, but it is safe and pragmatic to be strict about it now, and it really doesn't cause any new hardship. The existing UEFI LinuxLoader already update the FDT reserved map. Signed-off-by: Grant Likely Cc: Russell King Cc: Catalin Marinas Cc: Nicolas Pitre Cc: Leif Lindholm Cc: Olivier Martin Cc: Marc Zyngier --- In this patch I've stated that the initrd doesn't need to be included in the reserved map. However, should this be changed? Right now the decompressor doesn't actually look at the reserved map when decompressing and moving things around. If I'm reading the code correctly it is possible that the decompressor will overwrite the initrd if it gets placed too close to the kernel. So, my question is this; would it be better to require (or strongly recommend) the initrd be included in the reserved map and make the zImage wrapper aware of mem regions that is must not touch. Or should I leave well enough alone because in practical terms it's working fine as-is? Documentation/arm/Booting | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting index 0c1f475..1ea5020 100644 --- a/Documentation/arm/Booting +++ b/Documentation/arm/Booting @@ -118,13 +118,28 @@ physical address to determine if a dtb has been passed instead of a tagged list. The boot loader must pass at a minimum the size and location of the -system memory, and the root filesystem location. The dtb must be +system memory, and the root filesystem location. The dtb should be placed in a region of memory where the kernel decompressor will not -overwrite it. The recommended placement is in the first 16KiB of RAM -with the caveat that it may not be located at physical address 0 since -the kernel interprets a value of 0 in r2 to mean neither a tagged list +overwrite it. The decompressor will relocate an inconveniently placed +DTB, but it is better if it doesn't have to. The recommended placement +is either in the first 16KiB of RAM with the caveat that it may not be +located at physical address 0[1], or several megabytes past the end of the +kernel image. + +[1] the kernel interprets a value of 0 in r2 to mean neither a tagged list nor a dtb were passed. +The boot loader must also ensure that the FDT reserve memory map covers +all areas of main memory that must not be overwritten. This includes +firmware runtime support data[2], fixed framebuffers and DMA buffers. +However the initrd does not need to be included as the kernel already +knows how to protect the initrd location. + +[2] In particular when booting from UEFI the OS loader is expected to retrieve the +UEFI memory map and add all UEFI runtime memory regions to the reserved +map. This include UEFI runtime services, SMBIOS tables and ACPI tables +if they exist. + 5. Calling the kernel image ---------------------------