From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8954421E1DB35 for ; Sun, 30 Jul 2017 10:08:11 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id m85so152439875wma.1 for ; Sun, 30 Jul 2017 10:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2l6F9uaumyw8uUh47/l2WYPcJNMWr1fHTvzOJVQaRzo=; b=YsdjFrDBTh5uO1C9RnwK/x2O+4u1nMYHQTtg0gfAAUhDSgM+B8zkwi7YLt68sFnnXr pyxUjYtTc4o45rTMOD/O4T9ICm175Yv8roO+Lim2lOTNiXXgKVg5YITixhQ+gTlgJWHY xvARXFHCeM0ZnmqDUJi96tMQDFs6Zo5H3o4XU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2l6F9uaumyw8uUh47/l2WYPcJNMWr1fHTvzOJVQaRzo=; b=NxvLFkiRVePpWfirMg8ckWbixOC1+YWsMEkdZw8DBA5UL+QYlsDaTCiD8+uQgs83wg 5QUodGRMuScn1B8dkYACM1cIKEBQRNkvwWmJWPM2ctttIYARrMpuuwfvgtZki3yxMQhF 9fM+xcyUCrNsyu0gZMAfWGCHqke791eSTsXfCe0svFxsRv85ftScEaZQq/vbwUxagZZ0 pi5xvqS5YgUxnorpwm7fkdOgflaw+VOfJz9EuY0DuDiC1OJKjrsR8ybdyedCXKUyQfBl r34ttNCtcsWI4cWL8LDJeFKV3+eUp7XcOYQg57jOJ94YQGCkX9yFhbx+EqJffYFJCeKg R+Iw== X-Gm-Message-State: AIVw111vSlKKNzNzpegRaHwnZMdv3enaZ/C0sSJuZGIlsM9aFZixG/VM EWOIFbe0lzDSvXbJ X-Received: by 10.28.71.91 with SMTP id u88mr9734745wma.44.1501434617191; Sun, 30 Jul 2017 10:10:17 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id 1sm20807427wmn.32.2017.07.30.10.10.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jul 2017 10:10:16 -0700 (PDT) Date: Sun, 30 Jul 2017 18:10:14 +0100 From: Leif Lindholm To: Jun Nie Cc: Haojian Zhuang , Ard Biesheuvel , edk2-devel@lists.01.org, linaro-uefi@lists.linaro.org, Shawn Guo , Jason Liu Message-ID: <20170730171014.GA1501@bivouac.eciton.net> References: <1501150040-32613-1-git-send-email-jun.nie@linaro.org> <20170727140859.GL1501@bivouac.eciton.net> <8033c2f9-cfbb-e879-22d7-a0f484d2d4dd@linaro.org> <20170728130643.GP1501@bivouac.eciton.net> <96dd3ea5-b99e-5b12-ed47-160310156ab9@linaro.org> <20170728145222.GQ1501@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [PATCH v3 1/2] EmbeddedPkg/AndroidBoot: boot android kernel from storage X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 17:08:12 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jul 30, 2017 at 10:22:15PM +0800, Jun Nie wrote: > >> >>>>+ Status = EfiGetSystemConfigurationTable (&gFdtTableGuid, (VOID **)&FdtBase); > >> >>>>+ if (!EFI_ERROR (Status)) { > >> >>> > >> >>>Should this not be > >> >>> if (EFI_ERROR (Status) && Status != EFI_NOT_FOUND) > >> >>>? > >> >> > >> >>I mean, if fdt is found, we shall return to avoid installing another fdt. > >> > > >> >An FDT presented to you by firmware is just the hardware description. > >> >Any command line or initrd updates that are required will still need > >> >to happen in order to boot. So the same manipulations that happen to > >> >the DT embedded in boot.img need to happen to one presented via a > >> >configuration table. > >> > > >> >>But actually, I expect fdt is tied with kernel in Android boot image in > >> >>standard Android boot image usage cases. > >> >>Though it is agreed to decouple fdt and kernel in community in 2013, > >> >>Android boot image format has been decided several years before that :) . > >> >> > >> >>We can make change in future if Android boot image usage case changes. > >> >>Maybe I can add a warning message to highlight the new case. > >> > > >> >No. > >> > > >> >We can tolerate booting broken existing images, but we should not > >> >design to intentionally break things ourselves. > >> > > >> >I guess as this is an application, you could even add a command-line > >> >option to let you override an existing registered DT with one embedded > >> >in boot.img. > >> > > >> >But ignoring an existing registered DT is not an option. > >> > >> So you suggest to override existing registered fdt data with the one in > >> boot.img. > > > > No, I think that is a horrible idea, but you are saying that some > > platforms are so fundamentally broken as to need a different DT for > > every different kernel image. > > > > If this is the case, I can stretch to accepting a mechanism to > > override the sane default behaviour of using the existing device tree > > provided by the platform. > > > > But the platform registered device tree will still need the same > > chosen node updates as the one extracted from boot.img. > > > >> How to add a command-line, in kernel argument that is embedded in > >> boot.img? It is a bit strange if so. > > > > The command line argument would be to AndroidBootApp, not the kernel. > > > >> I prefer to override existing registered fdt data directly in current > >> Android boot image usage. > > > > The alternative to using the registered device tree by default, with a > > mechanism to override, is to always use the registered device tree and > > always ignore anything provided in boot.img. > > So the solution should be like this. the existing registered device tree will be > used and chosen node will be updated. If no existing registered device tree > is found, the one provided by boot.img will be used. As I do not expect > existing registered device tree case for Android boot usage, fdt in boot.img > will be used in most cases. If exception happens, we can check the detail > situation. Sure, that works for me. / Leif