From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5FC8C4743C for ; Mon, 21 Jun 2021 10:32:58 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2D84461108 for ; Mon, 21 Jun 2021 10:32:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D84461108 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=csgraf.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id F363682935; Mon, 21 Jun 2021 12:32:53 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=csgraf.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 94ABF82946; Mon, 21 Jun 2021 12:32:52 +0200 (CEST) Received: from zulu616.server4you.de (mail.csgraf.de [85.25.223.15]) by phobos.denx.de (Postfix) with UTF8SMTP id AF7B080C72 for ; Mon, 21 Jun 2021 12:32:49 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=csgraf.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=agraf@csgraf.de Received: from [192.168.106.194] (ec2-3-122-114-9.eu-central-1.compute.amazonaws.com [3.122.114.9]) by csgraf.de (Postfix) with UTF8SMTPSA id D67E36080436; Mon, 21 Jun 2021 12:32:48 +0200 (CEST) Message-ID: <1e947a09-e149-a746-cc6a-f6bd83cde80c@csgraf.de> Date: Mon, 21 Jun 2021 12:32:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:90.0) Gecko/20100101 Thunderbird/90.0 Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages Content-Language: en-US To: Simon Glass , Julian Hall Cc: Ed Stuber , Boot Architecture Mailman List , Okash Khawaja , Harb Abdulhamid OS , U-Boot Mailing List , Joanna Farley , Arjun Khare , Madhukar Pappireddy , Paul Isaac's , Ron Minnich , Moe Ammar , Loic Pallardy References: <010001785912437d-ab3ef3d5-960c-4f85-bd2c-7f7853900e7a-000000@email.amazonses.com> <010001786743a2ac-3d2da6df-c6f2-4e19-acaa-628ff7d466c2-000000@email.amazonses.com> <01000178b1570317-d1af5a40-d575-49ef-9b91-06abe8d04f4b-000000@email.amazonses.com> <010001793ebb08a4-29440b1d-778d-4a80-8def-619c2946e275-000000@email.amazonses.com> <010001796adacdd6-3f239ac5-27bb-4c79-a878-30592929b893-000000@email.amazonses.com> <0100017974aff4fb-0af45782-0b60-4724-b300-822f8fe4b799-000000@email.amazonses.com> <0100017982591630-15bf1d32-8f0b-4b2a-bb4d-a2ba39760820-000000@email.amazonses.com> From: Alexander Graf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 20.05.21 18:42, Simon Glass wrote: > Hi, > > Re Jeremy's comment: >> Using DT to pass platform info at this level is sort of crazy on an ACPI >> machine which won't have native DTs. Meaning there is an additional >> level of unnecessary indirection that needs to be converted back into a >> format which can be utilized by AML and other parts of the ACPI stack. > U-Boot has to generate part of the ACPI tables programmatically, using info > from the DT to do so. In other words, U-Boot supports DT but must also > support generating AML, etc. I don't see a particular problem with that. > > I don't think it makes any sense to use ACPI tables to pass data between > boot phases, but if that is being proposed, I'd like to understand the > reason. I also wonder why people are using UEFI on rpi, but that's a > different topic. Reading the conversation, I believe the main confusion is about what "use DT to pass data" means. There are fundamentally two ways to think of this: 1) Take a standard Linux device tree as input. Use exactly that to pass data between stages. Go through the LKML to define pre-Linux bindings. Implement a full DT parser to enumerate hardware. 2) Use DT purely as opaque data transfer mechanism and reuse simple parts (directories, compatible strings, etc) but leave out the complicated ones (recursive #address-cells, interrupt-map, etc). Use it to pass data privately between components. Be self-consistent, self-documenting and self-backwards-compatible. Which one of them do you mean Simon? I'd be super happy to see option 2. DT as a data container is so much nicer than opaque binary blobs. At the same time, I can see how people feel like option 1 would tie them into an ecosystem dependency they don't want to be in. Thanks, Alex