Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp160642imm; Mon, 14 May 2018 23:05:21 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo2oIFenahtOotpJT/VS2LHbcAOXE35Uq69230m8vjKkY9qpqeDzO/suo/d8onUJGi/nR+t X-Received: by 2002:a62:303:: with SMTP id 3-v6mr13604913pfd.255.1526364320975; Mon, 14 May 2018 23:05:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526364320; cv=none; d=google.com; s=arc-20160816; b=tUlU5EDfkEaSMvvEXP5H7teFjhyIrFMUw84e8hXtCxd8Fe8UKnOh0R94qge5yxC4Le 6Wr0Xoe8bI809+hw1ObL5v7weOaS452LhL37PCSslaoCKoc9h3vGkEBScKgo4t8aj0fr Lhmc4Md0lJEUqoXfjFFKke1mUYUWEfnYy0WiojmZ/0uFNsN7JVDW7NZpz0Vyy59xJLhW DBuYSn7XLkogN9vqIIAno07mDJfF0I4st/0eKu35etz1VC2H45PGX3+ATPLzOSrFusXO SoF0/Fk1Igo8LbEGqa43Iamng6NjdUrC3Wytf9RDnM+uWWXHeDlKjrZFsjSOERHdNTyx KKmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=OfINDra8/qVWahRF7YyNEYuwvWuo8LKKGz+XKlqe/m8=; b=o/H0OYsT08pNj3l0rc1wC7F4zcLR5BvVyokVjsltR/hhJQ2cvU6iIVUjMGTSLCGXKK XqATZ+mciGi7c94vkrMbi8TDxb8B+55aM9mAYoMH76BAeoItVyKQeKHGo2EE0ROEjbvB j9H20NwDlOxipxsAHmzXeIxpzV0hboxyuzh4PLStkEdxmnPsO+jU7ollUM0Ti3H7t9vb no3n+5iKT51mPqxKa+n0ewIXHl6HeEZSQb+JZ4xlcxHWWPhzHiEfUvPuxElf4mf3rMwt Q17Y0Ctj5yfKUpV0rCfKV5mGSZo2ePaFoidQM+GTGZHWc7uHhcWDlye6l1ottw/5n5zj 9FdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MYWLWV9P; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 63-v6si11840026plf.524.2018.05.14.23.05.05; Mon, 14 May 2018 23:05:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MYWLWV9P; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752200AbeEOGEz (ORCPT + 99 others); Tue, 15 May 2018 02:04:55 -0400 Received: from mail-qt0-f196.google.com ([209.85.216.196]:39264 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752135AbeEOGEx (ORCPT ); Tue, 15 May 2018 02:04:53 -0400 Received: by mail-qt0-f196.google.com with SMTP id f1-v6so19373236qtj.6; Mon, 14 May 2018 23:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OfINDra8/qVWahRF7YyNEYuwvWuo8LKKGz+XKlqe/m8=; b=MYWLWV9PSA//yT6oZ4XsyFZZpPdNXObIpGhkdxTLRpGdITIzdNexOt2XgGkjLLQegH //Q57q+jWRWDqo7Ivy77askfvTvW52J3Wc0+rtRX0/ZUUjF7S1K+K8qIgfOKkLEimiq1 Dnl6y0SbQZUXvcedCQ1X/ItRphP0VCNtqkz8Lmd3O37jJ8j32hWQcVhCGnZmOnYLDfzX X/d3I3SLwCsxVsVM8vN3VnsNnAMDX7Hddjfv4nHUvistTOFfptSamhQTOfMNZMGV6myh hoMO1lN6KDRKpsrJPag3TK8hDBeUGSqkGBJTe+pPX+wIxxYuiBjCLLWNHIr7/Nn09/w7 YFUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OfINDra8/qVWahRF7YyNEYuwvWuo8LKKGz+XKlqe/m8=; b=r52LzGgoCeQkeIAaeP6l2YhrZDzbPQvUcpHek+36Ljwa0bJbNw1YTLBiRDxPLZE6WK vSEs7dVVgcaI2H9wRxGHHKC1sC2rzv/B21dgBMd64afdxonRl1UWdsV58EsCXMoINkea p+TwoZ3BNkUDOkFuRqJq88sRiNGkhmiK3x3MbBfSqXv+sepud++pt/m24FchO8KI5wTL wlqbK/44u6hKAiiFbXNujVuWD1v5WkJG1dLc7gUliTnmb6965hySl1rrqDA3ztL9LHiu 9rVPnyTzO46m1FdJyMcS5YmI9V+WRQYdMc1ZLz/seDWYHuMqJpV1Phbv/Nb/kdq2HAFA N1EA== X-Gm-Message-State: ALKqPwc9tMsoi4qUizQ5ZmuAMMeaMhhW8GnblZ7RFbhGeU7t/DUznNcg N0sgB8b1qNmUwtos5XdJfogIXpaOOSk= X-Received: by 2002:ac8:6d2:: with SMTP id j18-v6mr11779741qth.306.1526364292434; Mon, 14 May 2018 23:04:52 -0700 (PDT) Received: from ?IPv6:2601:18d:4600:e68c:feaa:14ff:fe71:bf72? ([2601:18d:4600:e68c:feaa:14ff:fe71:bf72]) by smtp.googlemail.com with ESMTPSA id j12-v6sm9005186qtf.10.2018.05.14.23.04.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 May 2018 23:04:51 -0700 (PDT) Subject: Re: [PATCH] ARM: dts: chromecast: override bad bootloader memory info To: Jisheng Zhang Cc: linux-kernel@vger.kernel.org, Sebastian Hesselbarth , Rob Herring , Mark Rutland , "moderated list:ARM/Synaptics Berlin SoC support" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" References: <20180514215645.17592-2-tommyhebb@gmail.com> <20180515102939.3ab8797c@xhacker.debian> From: Tom Hebb Message-ID: <9d800fe2-6c59-1125-5d05-9ca0faa95150@gmail.com> Date: Tue, 15 May 2018 02:04:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180515102939.3ab8797c@xhacker.debian> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 05/14/2018 10:29 PM, Jisheng Zhang wrote: > Hi, > > On Mon, 14 May 2018 17:56:45 -0400 Thomas Hebb wrote: > >> On the Chromecast, the bootloader provides us with an ATAG_MEM of >> start=0x01000000 and size=0x3eff8000. This is clearly incorrect, as the >> range given encompasses nearly a GiB but the Chromecast only has 512MiB >> of RAM! Additionally, this causes the kernel to be decompressed at >> 0x00008000, below the claimed beginning of RAM, and so the boot fails. >> >> Since the existing ATAG parsing code runs before the kernel is even >> decompressed and irrevocably patches the device tree, don't even try > > This means you enabled ARM_ATAG_DTB_COMPAT. could we disable it instead? > The ATAG is useless when we provide dtb. And IIRC, the ATAG is provided due > to legacy history code. > > Thanks Thanks for the quick review! It's true that compiling without ARM_ATAG_DTB_COMPAT will prevent ATAG_MEM from getting parsed at all. However, it will also prevent ATAG_CMDLINE from getting parsed, and the command line from the Chromecast's bootloader does actually contain some useful information--notably the mode in which the system was booted (normal or recovery). Userspace could conceivably want this information, so it's preferable for the kernel to boot regardless of whether ARM_ATAG_DTB_COMPAT is enabled. That's the intent of this patch. I do agree in principle that ARM_ATAG_DTB_COMPAT should be disabled whenever possible. >> to bypass it. Instead, use the "linux,usable-memory" property instead >> of the "reg" property to define the real range. The ATAG code only >> overwrites reg, but linux,usable-memory is checked first in the OF >> driver, so the fact that reg gets changed makes no difference. >> >> Signed-off-by: Thomas Hebb >> --- >> arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 12 +++++++++++- >> 1 file changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts >> index 20f31cdeaf38..54221f55bfa2 100644 >> --- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts >> +++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts >> @@ -52,7 +52,17 @@ >> >> memory@0 { >> device_type = "memory"; >> - reg = <0x00000000 0x20000000>; /* 512 MB */ >> + >> + /* >> + * We're using "linux,usable-memory" instead of "reg" here >> + * because the (signed and encrypted) bootloader that shipped >> + * with this device provides an incorrect memory range in >> + * ATAG_MEM. Linux helpfully overrides the "reg" property with >> + * data from the ATAG, so we can't specify the proper range >> + * normally. Fortunately, this alternate property is checked >> + * first by the OF driver, so we can (ab)use it instead. >> + */ >> + linux,usable-memory = <0x00000000 0x20000000>; /* 512 MB */ >> }; >> >> leds { >