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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E7B6C433EF for ; Tue, 2 Nov 2021 16:03:37 +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 72636610FD for ; Tue, 2 Nov 2021 16:03:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 72636610FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 2CE4083201; Tue, 2 Nov 2021 17:03:34 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="munGYbhV"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id F2FCE82051; Tue, 2 Nov 2021 17:03:31 +0100 (CET) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 06D2182051 for ; Tue, 2 Nov 2021 17:03:24 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=francois.ozog@linaro.org Received: by mail-ed1-x531.google.com with SMTP id r4so76986746edi.5 for ; Tue, 02 Nov 2021 09:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AF1xF8FqbiqLx4vgqB2UFjS+4kCfCSm9GleuUzOoh3k=; b=munGYbhV8WXV+wqz5hsJ/jBmEWram7zDENMiNdvXpMUZEE5wIeN8TNOamKz1FAszr2 kRPjgCB3B6xgRsK8vALjXTLxgDgJr03UMulbxbYfjuGiFKOkxYcVs1Yt7Q//rpKmSabf e+urtrbbXaRAtWVIYjDu+MO2RmTvNLdbYYvXUg3jJxKiiVaE1JNh3u7Om4zkxq7MyooF i70qUB8kCwaUT+HuIcYCg6ISscK/TaqjlK4g2VfckPcGsX3apkf20Mq99jlvUcL/RVyP mqX4uMoq523Vq9Cy3BdwWAQXkg9HxQhSCUyXIIWYcl1xSjk5gsojAZsbjAfyi3YV6QVY cvDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AF1xF8FqbiqLx4vgqB2UFjS+4kCfCSm9GleuUzOoh3k=; b=FMiERtKoUHh21kBDvs6nC/GF99N17lVFYLQ/UQwUACn09mkrcF3XaN30hOSw4pYoIq aNAbpMIeONlHz9It9KxRrQthqnclKmH3bQ/R1LpUAOTePl6PqLjQN/caVYcamZZGVW4X dEr20y1p9sVdIwSp8jhtLvPfZ9ZGGkWraGV6KaBkktiWG3cGFga1+7ogIEgOyNdYKVB3 vw80lAoNBbNX5xVesrGwjhEC8/Sn/wx6ax5vCjf5tYk9ZAO1gld8WQQmysJFc9MvgO7X kmN/fc1wpk4apH2zayc3KYRX9p4i1uS7E5qqlBhxHrOuG8xY1Mv2f4Ds6urn4Cqnza6s fnkQ== X-Gm-Message-State: AOAM5337WmsgGAhxMHnBG/bjvCfGO7aPuEYcngKuAt2ZFEAbve/XoNp0 0JIxtaqDO9PQh5uxYUBsY0X++ITqGJpEqJJyAW2Q2w== X-Google-Smtp-Source: ABdhPJyAqjX0REgv4i+5CRcN/c8qJCstNpMfYiE5moh1FVRXTQ7MgZ7kbkss1bXTMzkvjGsCFmsHy1s4Dmh+cK4NTLM= X-Received: by 2002:a17:906:5d11:: with SMTP id g17mr46671400ejt.175.1635869003382; Tue, 02 Nov 2021 09:03:23 -0700 (PDT) MIME-Version: 1.0 References: <20211101011734.1614781-1-sjg@chromium.org> In-Reply-To: From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Tue, 2 Nov 2021 17:03:12 +0100 Message-ID: Subject: Re: [PATCH 00/31] passage: Define a standard for firmware data flow To: Simon Glass Cc: U-Boot Mailing List , Tom Rini , Bin Meng , Ilias Apalodimas , Bill Mills , Heinrich Schuchardt , Albert Aribaud , Jerry Van Baren , Marek Vasut , Masahiro Yamada , Pavel Herrmann , QEMU Developers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 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 Hi Simon, On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: > Hi Fran=C3=A7ois, > > On Mon, 1 Nov 2021 at 02:53, Fran=C3=A7ois Ozog > wrote: > > > > Hi Simon, > > > > this seems a great endeavor. I'd like to better understand the scope of > it. > > > > Is it to be used as part of what could become a U-Boot entry ABI scheme= ? > By that I mean giving some fixed aspects > > to U-Boot entry while letting boards to have flexibility (say for > instance that the first 5 architecture ABI > > parameter registers are reserved for U-Boot), and the Passage is about > specifying either those reserved registers > > or one of them? > > The goal is to provide a standard entry scheme for all firmware > binaries. Whether it achieves that (or can with some mods) is up for > discussion. > > If you say a) define a U-Boot entry ABI and providing a firmware-to-firmware information passing facility which would be part of all firmware ABIs (as the projects decide to define their own ABI) it looks good. but If you say b) define a standard entry scheme (register map, processor state, MMU state, SMMU state, GIC state...) that does not look realistic. I think you mean a) but just want to be sure. > Re the registers, do you think we need 5? > > > > > Thinking entry ABI, here is what I observed on Arm: > > > > Linux has two entry ABIs: > > - plain: x0 =3D dtb; > > command line =3D dtb:/chosen/bootargs; initrd =3D > dtb:/chosen/linux,initrd-* > > - EFI: x0=3Dhandle, x1=3Dsystemtable, x30=3Dreturn address; > > dtb =3D EFI_UUID config table; initrd =3D efi: vendor media UUID); command line =3D efi: image_protocol::load_options > > > > U-Boot (proper) has plenty of schemes: > > - dtb is passed as either x0, x1, fixed memory area (Qemu which is bad > in itself), or other registers > > - additional information passing: board specific register scheme, SMC > calls > > - U-Boot for RPI boards implement a Linux shaped entry ABI to be > launched by Videocore firmware > > > > Based on all the above, I would tend to think that RPI scheme is a good > idea but also > > shall not prevent additional schemes for the boards. > > I was not actually considering Linux since I believe/assume its entry > scheme is fixed and not up for discussion. > > I also did not think about the EFI case. As I understand it we cannot > touch it as it is used by UEFI today. Maybe it is even in the > standard? > It is in the spec and we are making it evolve, or its understanding evolve (jurisprudence) for instance on initrd standard handling. > > Really I am hoping we can start afresh...? > > > > > What about a U-Boot Arm entry ABI like: > > - plain: x0=3Ddtb, x1=3D, x2-x5 =3D , other > registers are per platform, SMC calls allowed too > > Hmm we don't actually need the dtb as it is available in the bloblist. > If you don't have x0=3Ddtb, then you will not be able to use U-Boot on RPI4= . Unless you want to redo everything the RPI firmware is doing. > But I added an offset to it as a convenience. > > > - EFI: x0=3Dhandle, x1=3Dsystemtable, x30=3Dreturn address; (when U-Bo= ot is > launched as an EFI app) > > dtb =3D EFI_UUID config table, + Passage =3D Passage UUID config= table > > I don't understand the last line. Where is the passage info / > bloblist? Do you mean it goes in the HOB list with a UUID? I suppose > that is the most EFI-compatible way. > The Passage config table could just contain the "head" of the bloblist/Passage information. > > What do you think about the idea of using an offset into the bloblist > for the dtb? It is possible but as I said, failing to mimic Linux entry ABI would miss the opportunity to just boot without changes on RPI4. > Also, can we make the standard passage ABI a build-time > option, so it is deterministic? > > Looks good. I would look into stating that for SystemReady we would advis= e to use that option and make it standard for Trusted Substrate (Linaro recipes that we upstreaming to make SystemReady compliance easy and consistent across platforms). > > > > We could further leverage Passage to pass Operating Systems parameters > that could be removed from device tree (migration of /chosen to Passage). > Memory inventory would still be in DT but allocations for CMA or GPUs wou= ld > be in Passage. This idea is to reach a point where device tree is a > "pristine" hardware description. > > I'm worried about this becoming a substitute for devicetree. Really my > intent is to provide a way to pass simple info, whereas what you talk > about there seems like something that should be DT, just that it might > need suitable bindings. > > I see your point and I agree It should not be a substitute. here is an expanded version of what I had in mind when I wrote those lines. cma, initrd and other Linux kernel parameters can be conveyed either through command line or DT. When using the non UEFI Linux entry ABI, you need to use the DT to pass those parameters. When using the UEFI Linux entry ABI, you *can* (not must) use the command line to pass all information, leaving the DT passed to the OS without any /chosen. When introducing Passage, I was wondering if we could pass command line to Linux and, same as UEFI, leave the DT free from /chosen. I am not sure it is a good goal though. I may be too pushing for a DT free from parameters. > As you know I have more expansive views about what should be in DT. > I think both of us are huge supporters of DT format and self describing capabilities. I am inclined to put rules into what fits into what lands in the DT that is passed to the OS. I am a fan of having DT used more in ad-hoc files. > > > > Cheers > > > > PS: as Ilias mentions, this patch set contains bug fixes, non > immediately related additional functions (DM stats). It would be great to > carve those out to fast path them and keep this one with the very core of > your idea. > > The DM stats is used in 'passage: Report the devicetree source'. I > know it is sideways but I think it is better to make the output line > more useful than just reporting the devicetree source. > > I believe the DM stats has merits in its own. You could upstream this independently and then Passage would be yet another "customer" of the feature. > The first patch is indeed unrelated. I will pick it up so we can drop > it for the next rev. > > Regards, > Simon > > > > > > On Mon, 1 Nov 2021 at 02:17, Simon Glass wrote: > >> > >> > >> This series adds a standard way of passing information between differe= nt > >> firmware phases. This already exists in U-Boot at a very basic level, = in > >> the form of a bloblist containing an spl_handoff structure, but the > intent > >> here is to define something useful across projects. > >> > >> The need for this is growing as firmware fragments into multiple > binaries > >> each with its own purpose. Without any run-time connection, we must re= ly > >> on build-time settings which are brittle and painful to keep in sync. > >> > >> This feature is named 'standard passage' since the name is more unique > >> than many others that could be chosen, it is a passage in the sense th= at > >> information is flowing from one place to another and it is standard, > >> because that is what we want to create. > >> > >> The implementation is simply a pointer to a bloblist in a register, wi= th > >> an extra register to point to a devicetree, for more complex data, if > one > >> is present in the bloblist. This should cover all cases (small memory > >> footprint as well as complex data flow) and be easy enough to implemen= t > on > >> all architectures. > >> > >> The core bloblist code is relicensed to BSD-3-Clause in case it is > useful > >> in non-GPL projects but there is no requirement to use the same code. > >> > >> This series includes tweaks to the bloblist implementation in U-Boot t= o > >> make it more suitable for the task, including: > >> > >> - Allocate tags explicitly in the enum > >> - Put the magic number first > >> - Define a process for adding tags > >> > >> The emphasis is on enabling open communcation between binaries, not > >> enabling passage of secret, undocumented data, although this is possib= le > >> in a private environment. > >> > >> This series is built on the OF_BOARD series It is available at > >> u-boot-dm/pass-working or: > >> > >> > https://source.denx.de/u-boot/custodians/u-boot-dm/-/commit/073b5c156f222= c69a98b8ebcaa563d1ff10eb217 > >> > >> > >> Simon Glass (31): > >> Makefile: Correct TPL rule for OF_REAL > >> kconfig: Add support for conditional values > >> dm: core: Allow getting some basic stats > >> stddef: Avoid warning with clang with offsetof() > >> fdt: Drop SPL_BUILD macro > >> bloblist: Put the magic number first > >> bloblist: Rename the SPL tag > >> bloblist: Drop unused tags > >> bloblist: Use explicit numbering for the tags > >> bloblist: Support allocating the bloblist > >> bloblist: Use LOG_CATEGORY to simply logging > >> bloblist: Use 'phase' consistently for bloblists > >> bloblist: Refactor Kconfig to support alloc or fixed > >> arm: qemu: Add an SPL build > >> bloblist: Add functions to obtain base address and size > >> passage: Support an incoming passage > >> passage: Support a control devicetree > >> passage: arm: Accept a passage from the previous phase > >> passage: spl: Support adding the dtb to the passage bloblist > >> passage: spl: Support passing the passage to U-Boot > >> passage: Record where the devicetree came from > >> passage: Report the devicetree source > >> passage: Add a qemu test for ARM > >> bloblist: doc: Bring in the API documentation > >> bloblist: Relicense to allow BSD-3-Clause > >> sandbox: Add a way of checking structs for standard passage > >> passage: Add documentation > >> passage: Add docs for spl_handoff > >> x86: Move Intel GNVS file into the common include directory > >> passage: Add checks for pre-existing blobs > >> WIP: RFC: Add a gitlab test > >> > >> .gitlab-ci.yml | 6 + > >> MAINTAINERS | 10 + > >> Makefile | 2 +- > >> arch/arm/cpu/armv7/start.S | 7 +- > >> arch/arm/dts/qemu-arm-u-boot.dtsi | 22 ++ > >> arch/arm/lib/crt0.S | 4 + > >> arch/arm/mach-qemu/Kconfig | 9 + > >> arch/sandbox/cpu/spl.c | 2 +- > >> arch/x86/cpu/apollolake/acpi.c | 2 +- > >> arch/x86/cpu/broadwell/cpu_from_spl.c | 4 +- > >> arch/x86/cpu/intel_common/acpi.c | 2 +- > >> .../include/asm/arch-apollolake/global_nvs.h | 2 +- > >> arch/x86/lib/spl.c | 2 +- > >> arch/x86/lib/tpl.c | 2 +- > >> board/emulation/qemu-arm/Kconfig | 23 +- > >> board/emulation/qemu-arm/MAINTAINERS | 1 + > >> board/emulation/qemu-arm/Makefile | 1 + > >> board/emulation/qemu-arm/spl.c | 27 ++ > >> board/google/chromebook_coral/coral.c | 2 +- > >> board/sandbox/Makefile | 3 +- > >> board/sandbox/stdpass_check.c | 107 ++++++ > >> cmd/bdinfo.c | 2 + > >> common/Kconfig | 161 ++++++++- > >> common/bloblist.c | 124 +++++-- > >> common/board_f.c | 48 ++- > >> common/board_r.c | 18 + > >> common/spl/spl.c | 74 +++- > >> configs/qemu_arm_spl_defconfig | 78 +++++ > >> doc/board/emulation/qemu-arm.rst | 38 +++ > >> doc/develop/bloblist.rst | 28 +- > >> doc/develop/index.rst | 1 + > >> doc/develop/std_passage.rst | 319 +++++++++++++++++= + > >> drivers/core/device.c | 11 + > >> drivers/core/root.c | 7 + > >> drivers/core/uclass.c | 13 + > >> drivers/serial/serial-uclass.c | 3 +- > >> dts/Kconfig | 12 + > >> include/asm-generic/global_data.h | 35 ++ > >> include/bloblist.h | 175 +++++++--- > >> include/dm/device.h | 11 +- > >> include/dm/root.h | 8 + > >> include/dm/uclass-internal.h | 7 + > >> include/fdtdec.h | 40 ++- > >> include/handoff.h | 8 +- > >> .../x86/include/asm =3D> include}/intel_gnvs.h | 0 > >> include/linux/kconfig.h | 18 + > >> include/linux/stddef.h | 8 +- > >> include/spl.h | 15 + > >> include/stdpass/README | 4 + > >> include/stdpass/tpm2_eventlog.h | 42 +++ > >> include/stdpass/vboot_ctx.h | 267 +++++++++++++++ > >> lib/asm-offsets.c | 5 + > >> lib/fdtdec.c | 65 +++- > >> scripts/config_whitelist.txt | 1 + > >> test/bloblist.c | 21 +- > >> test/dm/core.c | 41 +++ > >> test/py/tests/test_passage.py | 11 + > >> 57 files changed, 1798 insertions(+), 161 deletions(-) > >> create mode 100644 arch/arm/dts/qemu-arm-u-boot.dtsi > >> create mode 100644 board/emulation/qemu-arm/spl.c > >> create mode 100644 board/sandbox/stdpass_check.c > >> create mode 100644 configs/qemu_arm_spl_defconfig > >> create mode 100644 doc/develop/std_passage.rst > >> rename {arch/x86/include/asm =3D> include}/intel_gnvs.h (100%) > >> create mode 100644 include/stdpass/README > >> create mode 100644 include/stdpass/tpm2_eventlog.h > >> create mode 100644 include/stdpass/vboot_ctx.h > >> create mode 100644 test/py/tests/test_passage.py > >> > >> -- > >> 2.33.1.1089.g2158813163f-goog > >> > > > > > > -- > > Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | Director Business Development > > T: +33.67221.6485 > > francois.ozog@linaro.org | Skype: ffozog > > > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90817C433EF for ; Tue, 2 Nov 2021 16:09:17 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 11B76604DC for ; Tue, 2 Nov 2021 16:09:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 11B76604DC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:33052 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mhwLc-0004QV-73 for qemu-devel@archiver.kernel.org; Tue, 02 Nov 2021 12:09:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52222) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhwG2-00050L-Hg for qemu-devel@nongnu.org; Tue, 02 Nov 2021 12:03:30 -0400 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]:40795) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mhwFx-0002ZP-Db for qemu-devel@nongnu.org; Tue, 02 Nov 2021 12:03:29 -0400 Received: by mail-ed1-x52d.google.com with SMTP id 5so76588289edw.7 for ; Tue, 02 Nov 2021 09:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AF1xF8FqbiqLx4vgqB2UFjS+4kCfCSm9GleuUzOoh3k=; b=munGYbhV8WXV+wqz5hsJ/jBmEWram7zDENMiNdvXpMUZEE5wIeN8TNOamKz1FAszr2 kRPjgCB3B6xgRsK8vALjXTLxgDgJr03UMulbxbYfjuGiFKOkxYcVs1Yt7Q//rpKmSabf e+urtrbbXaRAtWVIYjDu+MO2RmTvNLdbYYvXUg3jJxKiiVaE1JNh3u7Om4zkxq7MyooF i70qUB8kCwaUT+HuIcYCg6ISscK/TaqjlK4g2VfckPcGsX3apkf20Mq99jlvUcL/RVyP mqX4uMoq523Vq9Cy3BdwWAQXkg9HxQhSCUyXIIWYcl1xSjk5gsojAZsbjAfyi3YV6QVY cvDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AF1xF8FqbiqLx4vgqB2UFjS+4kCfCSm9GleuUzOoh3k=; b=070v/qs73beWnoq8imYZvs6VziwGSW9rPe5Gpl6qSmplnnGAqdgEI3m5yIY+idx+QC vqGuEYzvQHnTjufXXfP7xy/WTkUN78/N1u18MZ+AwPK3UYIKSdp62aq2rl9CQBSpRb2X eLBIjxjxvDO62Hr3X7b+I+S5HPrR+pI31+qk6pujYsiJMaQpWXdkOuWlVWnCneG6xaSD fjpeBssM5JvHgJyxspDEqqca8zElWEswi3mP+juxfE0Lp1wDUzpCG5RmX/fGqOs8ZRds LTmWT+JNGGI9WN6hZYPjaat8z+QGlYAuHXx8JKBZW9EEG6dUMnspk6yi67OVLuMQuA5+ P+ZQ== X-Gm-Message-State: AOAM530vbUAvHv/WWWdyNdJYnn+i9n6o97Pc1mctV7+xPoe2SRCqG8aB Np1NG7aQoPymS7MmAYgbbQU27+0ZZIPin8rteec/bw== X-Google-Smtp-Source: ABdhPJyAqjX0REgv4i+5CRcN/c8qJCstNpMfYiE5moh1FVRXTQ7MgZ7kbkss1bXTMzkvjGsCFmsHy1s4Dmh+cK4NTLM= X-Received: by 2002:a17:906:5d11:: with SMTP id g17mr46671400ejt.175.1635869003382; Tue, 02 Nov 2021 09:03:23 -0700 (PDT) MIME-Version: 1.0 References: <20211101011734.1614781-1-sjg@chromium.org> In-Reply-To: From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Tue, 2 Nov 2021 17:03:12 +0100 Message-ID: Subject: Re: [PATCH 00/31] passage: Define a standard for firmware data flow To: Simon Glass Content-Type: multipart/alternative; boundary="000000000000d8a59e05cfd06ec7" Received-SPF: pass client-ip=2a00:1450:4864:20::52d; envelope-from=francois.ozog@linaro.org; helo=mail-ed1-x52d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marek Vasut , Tom Rini , Albert Aribaud , Masahiro Yamada , Heinrich Schuchardt , Bill Mills , Ilias Apalodimas , QEMU Developers , U-Boot Mailing List , Jerry Van Baren , Bin Meng , Pavel Herrmann Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000d8a59e05cfd06ec7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Simon, On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: > Hi Fran=C3=A7ois, > > On Mon, 1 Nov 2021 at 02:53, Fran=C3=A7ois Ozog > wrote: > > > > Hi Simon, > > > > this seems a great endeavor. I'd like to better understand the scope of > it. > > > > Is it to be used as part of what could become a U-Boot entry ABI scheme= ? > By that I mean giving some fixed aspects > > to U-Boot entry while letting boards to have flexibility (say for > instance that the first 5 architecture ABI > > parameter registers are reserved for U-Boot), and the Passage is about > specifying either those reserved registers > > or one of them? > > The goal is to provide a standard entry scheme for all firmware > binaries. Whether it achieves that (or can with some mods) is up for > discussion. > > If you say a) define a U-Boot entry ABI and providing a firmware-to-firmware information passing facility which would be part of all firmware ABIs (as the projects decide to define their own ABI) it looks good. but If you say b) define a standard entry scheme (register map, processor state, MMU state, SMMU state, GIC state...) that does not look realistic. I think you mean a) but just want to be sure. > Re the registers, do you think we need 5? > > > > > Thinking entry ABI, here is what I observed on Arm: > > > > Linux has two entry ABIs: > > - plain: x0 =3D dtb; > > command line =3D dtb:/chosen/bootargs; initrd =3D > dtb:/chosen/linux,initrd-* > > - EFI: x0=3Dhandle, x1=3Dsystemtable, x30=3Dreturn address; > > dtb =3D EFI_UUID config table; initrd =3D efi: vendor media UUID); command line =3D efi: image_protocol::load_options > > > > U-Boot (proper) has plenty of schemes: > > - dtb is passed as either x0, x1, fixed memory area (Qemu which is bad > in itself), or other registers > > - additional information passing: board specific register scheme, SMC > calls > > - U-Boot for RPI boards implement a Linux shaped entry ABI to be > launched by Videocore firmware > > > > Based on all the above, I would tend to think that RPI scheme is a good > idea but also > > shall not prevent additional schemes for the boards. > > I was not actually considering Linux since I believe/assume its entry > scheme is fixed and not up for discussion. > > I also did not think about the EFI case. As I understand it we cannot > touch it as it is used by UEFI today. Maybe it is even in the > standard? > It is in the spec and we are making it evolve, or its understanding evolve (jurisprudence) for instance on initrd standard handling. > > Really I am hoping we can start afresh...? > > > > > What about a U-Boot Arm entry ABI like: > > - plain: x0=3Ddtb, x1=3D, x2-x5 =3D , other > registers are per platform, SMC calls allowed too > > Hmm we don't actually need the dtb as it is available in the bloblist. > If you don't have x0=3Ddtb, then you will not be able to use U-Boot on RPI4= . Unless you want to redo everything the RPI firmware is doing. > But I added an offset to it as a convenience. > > > - EFI: x0=3Dhandle, x1=3Dsystemtable, x30=3Dreturn address; (when U-Bo= ot is > launched as an EFI app) > > dtb =3D EFI_UUID config table, + Passage =3D Passage UUID config= table > > I don't understand the last line. Where is the passage info / > bloblist? Do you mean it goes in the HOB list with a UUID? I suppose > that is the most EFI-compatible way. > The Passage config table could just contain the "head" of the bloblist/Passage information. > > What do you think about the idea of using an offset into the bloblist > for the dtb? It is possible but as I said, failing to mimic Linux entry ABI would miss the opportunity to just boot without changes on RPI4. > Also, can we make the standard passage ABI a build-time > option, so it is deterministic? > > Looks good. I would look into stating that for SystemReady we would advis= e to use that option and make it standard for Trusted Substrate (Linaro recipes that we upstreaming to make SystemReady compliance easy and consistent across platforms). > > > > We could further leverage Passage to pass Operating Systems parameters > that could be removed from device tree (migration of /chosen to Passage). > Memory inventory would still be in DT but allocations for CMA or GPUs wou= ld > be in Passage. This idea is to reach a point where device tree is a > "pristine" hardware description. > > I'm worried about this becoming a substitute for devicetree. Really my > intent is to provide a way to pass simple info, whereas what you talk > about there seems like something that should be DT, just that it might > need suitable bindings. > > I see your point and I agree It should not be a substitute. here is an expanded version of what I had in mind when I wrote those lines. cma, initrd and other Linux kernel parameters can be conveyed either through command line or DT. When using the non UEFI Linux entry ABI, you need to use the DT to pass those parameters. When using the UEFI Linux entry ABI, you *can* (not must) use the command line to pass all information, leaving the DT passed to the OS without any /chosen. When introducing Passage, I was wondering if we could pass command line to Linux and, same as UEFI, leave the DT free from /chosen. I am not sure it is a good goal though. I may be too pushing for a DT free from parameters. > As you know I have more expansive views about what should be in DT. > I think both of us are huge supporters of DT format and self describing capabilities. I am inclined to put rules into what fits into what lands in the DT that is passed to the OS. I am a fan of having DT used more in ad-hoc files. > > > > Cheers > > > > PS: as Ilias mentions, this patch set contains bug fixes, non > immediately related additional functions (DM stats). It would be great to > carve those out to fast path them and keep this one with the very core of > your idea. > > The DM stats is used in 'passage: Report the devicetree source'. I > know it is sideways but I think it is better to make the output line > more useful than just reporting the devicetree source. > > I believe the DM stats has merits in its own. You could upstream this independently and then Passage would be yet another "customer" of the feature. > The first patch is indeed unrelated. I will pick it up so we can drop > it for the next rev. > > Regards, > Simon > > > > > > On Mon, 1 Nov 2021 at 02:17, Simon Glass wrote: > >> > >> > >> This series adds a standard way of passing information between differe= nt > >> firmware phases. This already exists in U-Boot at a very basic level, = in > >> the form of a bloblist containing an spl_handoff structure, but the > intent > >> here is to define something useful across projects. > >> > >> The need for this is growing as firmware fragments into multiple > binaries > >> each with its own purpose. Without any run-time connection, we must re= ly > >> on build-time settings which are brittle and painful to keep in sync. > >> > >> This feature is named 'standard passage' since the name is more unique > >> than many others that could be chosen, it is a passage in the sense th= at > >> information is flowing from one place to another and it is standard, > >> because that is what we want to create. > >> > >> The implementation is simply a pointer to a bloblist in a register, wi= th > >> an extra register to point to a devicetree, for more complex data, if > one > >> is present in the bloblist. This should cover all cases (small memory > >> footprint as well as complex data flow) and be easy enough to implemen= t > on > >> all architectures. > >> > >> The core bloblist code is relicensed to BSD-3-Clause in case it is > useful > >> in non-GPL projects but there is no requirement to use the same code. > >> > >> This series includes tweaks to the bloblist implementation in U-Boot t= o > >> make it more suitable for the task, including: > >> > >> - Allocate tags explicitly in the enum > >> - Put the magic number first > >> - Define a process for adding tags > >> > >> The emphasis is on enabling open communcation between binaries, not > >> enabling passage of secret, undocumented data, although this is possib= le > >> in a private environment. > >> > >> This series is built on the OF_BOARD series It is available at > >> u-boot-dm/pass-working or: > >> > >> > https://source.denx.de/u-boot/custodians/u-boot-dm/-/commit/073b5c156f222= c69a98b8ebcaa563d1ff10eb217 > >> > >> > >> Simon Glass (31): > >> Makefile: Correct TPL rule for OF_REAL > >> kconfig: Add support for conditional values > >> dm: core: Allow getting some basic stats > >> stddef: Avoid warning with clang with offsetof() > >> fdt: Drop SPL_BUILD macro > >> bloblist: Put the magic number first > >> bloblist: Rename the SPL tag > >> bloblist: Drop unused tags > >> bloblist: Use explicit numbering for the tags > >> bloblist: Support allocating the bloblist > >> bloblist: Use LOG_CATEGORY to simply logging > >> bloblist: Use 'phase' consistently for bloblists > >> bloblist: Refactor Kconfig to support alloc or fixed > >> arm: qemu: Add an SPL build > >> bloblist: Add functions to obtain base address and size > >> passage: Support an incoming passage > >> passage: Support a control devicetree > >> passage: arm: Accept a passage from the previous phase > >> passage: spl: Support adding the dtb to the passage bloblist > >> passage: spl: Support passing the passage to U-Boot > >> passage: Record where the devicetree came from > >> passage: Report the devicetree source > >> passage: Add a qemu test for ARM > >> bloblist: doc: Bring in the API documentation > >> bloblist: Relicense to allow BSD-3-Clause > >> sandbox: Add a way of checking structs for standard passage > >> passage: Add documentation > >> passage: Add docs for spl_handoff > >> x86: Move Intel GNVS file into the common include directory > >> passage: Add checks for pre-existing blobs > >> WIP: RFC: Add a gitlab test > >> > >> .gitlab-ci.yml | 6 + > >> MAINTAINERS | 10 + > >> Makefile | 2 +- > >> arch/arm/cpu/armv7/start.S | 7 +- > >> arch/arm/dts/qemu-arm-u-boot.dtsi | 22 ++ > >> arch/arm/lib/crt0.S | 4 + > >> arch/arm/mach-qemu/Kconfig | 9 + > >> arch/sandbox/cpu/spl.c | 2 +- > >> arch/x86/cpu/apollolake/acpi.c | 2 +- > >> arch/x86/cpu/broadwell/cpu_from_spl.c | 4 +- > >> arch/x86/cpu/intel_common/acpi.c | 2 +- > >> .../include/asm/arch-apollolake/global_nvs.h | 2 +- > >> arch/x86/lib/spl.c | 2 +- > >> arch/x86/lib/tpl.c | 2 +- > >> board/emulation/qemu-arm/Kconfig | 23 +- > >> board/emulation/qemu-arm/MAINTAINERS | 1 + > >> board/emulation/qemu-arm/Makefile | 1 + > >> board/emulation/qemu-arm/spl.c | 27 ++ > >> board/google/chromebook_coral/coral.c | 2 +- > >> board/sandbox/Makefile | 3 +- > >> board/sandbox/stdpass_check.c | 107 ++++++ > >> cmd/bdinfo.c | 2 + > >> common/Kconfig | 161 ++++++++- > >> common/bloblist.c | 124 +++++-- > >> common/board_f.c | 48 ++- > >> common/board_r.c | 18 + > >> common/spl/spl.c | 74 +++- > >> configs/qemu_arm_spl_defconfig | 78 +++++ > >> doc/board/emulation/qemu-arm.rst | 38 +++ > >> doc/develop/bloblist.rst | 28 +- > >> doc/develop/index.rst | 1 + > >> doc/develop/std_passage.rst | 319 +++++++++++++++++= + > >> drivers/core/device.c | 11 + > >> drivers/core/root.c | 7 + > >> drivers/core/uclass.c | 13 + > >> drivers/serial/serial-uclass.c | 3 +- > >> dts/Kconfig | 12 + > >> include/asm-generic/global_data.h | 35 ++ > >> include/bloblist.h | 175 +++++++--- > >> include/dm/device.h | 11 +- > >> include/dm/root.h | 8 + > >> include/dm/uclass-internal.h | 7 + > >> include/fdtdec.h | 40 ++- > >> include/handoff.h | 8 +- > >> .../x86/include/asm =3D> include}/intel_gnvs.h | 0 > >> include/linux/kconfig.h | 18 + > >> include/linux/stddef.h | 8 +- > >> include/spl.h | 15 + > >> include/stdpass/README | 4 + > >> include/stdpass/tpm2_eventlog.h | 42 +++ > >> include/stdpass/vboot_ctx.h | 267 +++++++++++++++ > >> lib/asm-offsets.c | 5 + > >> lib/fdtdec.c | 65 +++- > >> scripts/config_whitelist.txt | 1 + > >> test/bloblist.c | 21 +- > >> test/dm/core.c | 41 +++ > >> test/py/tests/test_passage.py | 11 + > >> 57 files changed, 1798 insertions(+), 161 deletions(-) > >> create mode 100644 arch/arm/dts/qemu-arm-u-boot.dtsi > >> create mode 100644 board/emulation/qemu-arm/spl.c > >> create mode 100644 board/sandbox/stdpass_check.c > >> create mode 100644 configs/qemu_arm_spl_defconfig > >> create mode 100644 doc/develop/std_passage.rst > >> rename {arch/x86/include/asm =3D> include}/intel_gnvs.h (100%) > >> create mode 100644 include/stdpass/README > >> create mode 100644 include/stdpass/tpm2_eventlog.h > >> create mode 100644 include/stdpass/vboot_ctx.h > >> create mode 100644 test/py/tests/test_passage.py > >> > >> -- > >> 2.33.1.1089.g2158813163f-goog > >> > > > > > > -- > > Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | Director Business Development > > T: +33.67221.6485 > > francois.ozog@linaro.org | Skype: ffozog > > > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog --000000000000d8a59e05cfd06ec7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Simon,

On Tue, 2 Nov 2021 at 15:59, Sim= on Glass <sjg@chromium.org> w= rote:
Hi Fran=C3=A7ois,

On Mon, 1 Nov 2021 at 02:53, Fran=C3=A7ois Ozog <francois.ozog@linaro.org> wro= te:
>
> Hi Simon,
>
> this seems a great endeavor. I'd like to better understand the sco= pe of it.
>
> Is it to be used as part of what could become a U-Boot entry ABI schem= e? By that I mean giving some fixed aspects
> to U-Boot entry while letting boards to have flexibility (say for inst= ance that the first 5 architecture ABI
> parameter registers are reserved for U-Boot), and the Passage is about= specifying either those reserved registers
> or one of them?

The goal is to provide a standard entry scheme for all firmware
binaries. Whether it achieves that (or can with some mods) is up for
discussion.

If you say
a) define a U-Boot entry ABI and= providing a firmware-to-firmware information passing facility which would = be part of all firmware ABIs (as the projects decide to define their own AB= I) it looks good.
but If you say=C2=A0
b) define a stan= dard entry scheme (register map, processor state, MMU state, SMMU state, GI= C state...) that does not look realistic.=C2=A0
I think you mean = a) but just want to be sure.
Re the registers, do you think we need 5?

>
> Thinking entry ABI, here is what I observed on Arm:
>
> Linux has two entry ABIs:
> - plain: x0 =3D dtb;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0command line =3D dtb:/chosen/b= ootargs; initrd =3D dtb:/chosen/linux,initrd-*
> - EFI: x0=3Dhandle, x1=3Dsystemtable, x30=3Dreturn address;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dtb =3D EFI_UUID config table= ; initrd =3D efi:<loadfile2(INITRD vendor media UUID); command line =3D = efi: image_protocol::load_options
>
> U-Boot (proper) has plenty of schemes:
> - dtb is passed as either x0, x1, fixed memory area (Qemu which is bad= in itself), or other registers
> - additional information passing: board specific register scheme, SMC = calls
> - U-Boot for RPI boards implement a Linux shaped entry ABI to be launc= hed by Videocore firmware
>
> Based on all the above, I would tend to think that RPI scheme is a goo= d idea but also
> shall not prevent additional schemes for the boards.

I was not actually considering Linux since I believe/assume its entry
scheme is fixed and not up for discussion.

I also did not think about the EFI case. As I understand it we cannot
touch it as it is used by UEFI today. Maybe it is even in the
standard?
It is in the spec and we are making it evolv= e, or its understanding evolve (jurisprudence) for instance on initrd stand= ard handling.=C2=A0

Really I am hoping we can start afresh...?

>
> What about a U-Boot Arm entry ABI like:
> - plain: x0=3Ddtb, x1=3D<Passage defined>, x2-x5 =3D <reserve= d>, other registers are per platform, SMC calls allowed too

Hmm we don't actually need the dtb as it is available in the bloblist.<= br>
If you don't have x0=3Ddtb, then you will not be a= ble to use U-Boot on RPI4.
Unless you want to redo everything the= RPI firmware is doing.
But I added an offset to it as a convenience.

> - EFI: x0=3Dhandle, x1=3Dsystemtable, x30=3Dreturn address;=C2=A0 (whe= n U-Boot is launched as an EFI app)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 dtb =3D EFI_UUID config table, + Passage = =3D Passage UUID config table

I don't understand the last line. Where is the passage info /
bloblist? Do you mean it goes in the HOB list with a UUID? I suppose
that is the most EFI-compatible way.
The Passage confi= g table =C2=A0could just contain the "head" of the bloblist/Passa= ge information.

What do you think about the idea of using an offset into the bloblist
for the dtb?
It is possible but as I said, failing to mim= ic Linux entry ABI would miss the opportunity to just boot without changes = on RPI4. =C2=A0
Also, can we make the standard passag= e ABI a build-time
option, so it is deterministic?

Looks good. I would look into stating that for System= Ready we would advise to use that option and make it standard for Trusted S= ubstrate (Linaro recipes that we upstreaming to make SystemReady compliance= easy and consistent across platforms).=C2=A0
>
> We could further leverage Passage to pass Operating Systems parameters= that could be removed from device tree (migration of /chosen to Passage). = Memory inventory would still be in DT but allocations for CMA or GPUs would= be in Passage. This idea is to reach a point where=C2=A0 device tree is a = "pristine" hardware description.

I'm worried about this becoming a substitute for devicetree. Really my<= br> intent is to provide a way to pass simple info, whereas what you talk
about there seems like something that should be DT, just that it might
need suitable bindings.

I see your point and I agree It should not be a subst= itute.
here is an expanded version of what I had in mind when I w= rote those lines.
cma, initrd and other Linux kernel parameters c= an be conveyed either through command line or DT.
When using the = non UEFI Linux entry ABI, you need to use the DT to pass those parameters.<= /div>
When using the UEFI Linux entry ABI, you *can* (not must) use the= command line to pass all information, leaving the DT passed to the OS with= out any /chosen.
When introducing Passage, I was wondering if we = could pass command line to Linux and, same as UEFI, leave the DT free from = /chosen.
I am not sure it is a good goal though. I may be too pus= hing for a DT free from parameters.
As you know I have more expansive views about what should be in DT.=C2=A0
I think both of us are huge supporters of DT format and= self describing capabilities.=C2=A0
I am inclined to put rules i= nto what fits into what lands in the DT that is passed to the OS.
I am a fan of having DT used more in ad-hoc files.
>
> Cheers
>
> PS: as Ilias mentions, this patch set contains bug fixes, non immediat= ely related additional functions (DM stats). It would be great to carve tho= se out to fast path them and keep this one with the very core of your idea.=

The DM stats is used in 'passage: Report the devicetree source'. I<= br> know it is sideways but I think it is better to make the output line
more useful than just reporting the devicetree source.

I believe the DM stats has merits in its own. You cou= ld upstream this independently and then Passage would be yet another "= customer" of the feature.=C2=A0
The first patch is indeed unrelated. I will pick it up so we can drop
it for the next rev.

Regards,
Simon


>
> On Mon, 1 Nov 2021 at 02:17, Simon Glass <sjg@chromium.org> wrote:
>>
>>
>> This series adds a standard way of passing information between dif= ferent
>> firmware phases. This already exists in U-Boot at a very basic lev= el, in
>> the form of a bloblist containing an spl_handoff structure, but th= e intent
>> here is to define something useful across projects.
>>
>> The need for this is growing as firmware fragments into multiple b= inaries
>> each with its own purpose. Without any run-time connection, we mus= t rely
>> on build-time settings which are brittle and painful to keep in sy= nc.
>>
>> This feature is named 'standard passage' since the name is= more unique
>> than many others that could be chosen, it is a passage in the sens= e that
>> information is flowing from one place to another and it is standar= d,
>> because that is what we want to create.
>>
>> The implementation is simply a pointer to a bloblist in a register= , with
>> an extra register to point to a devicetree, for more complex data,= if one
>> is present in the bloblist. This should cover all cases (small mem= ory
>> footprint as well as complex data flow) and be easy enough to impl= ement on
>> all architectures.
>>
>> The core bloblist code is relicensed to BSD-3-Clause in case it is= useful
>> in non-GPL projects but there is no requirement to use the same co= de.
>>
>> This series includes tweaks to the bloblist implementation in U-Bo= ot to
>> make it more suitable for the task, including:
>>
>>=C2=A0 =C2=A0 - Allocate tags explicitly in the enum
>>=C2=A0 =C2=A0 - Put the magic number first
>>=C2=A0 =C2=A0 - Define a process for adding tags
>>
>> The emphasis is on enabling open communcation between binaries, no= t
>> enabling passage of secret, undocumented data, although this is po= ssible
>> in a private environment.
>>
>> This series is built on the OF_BOARD series It is available at
>> u-boot-dm/pass-working or:
>>
>> https://source.denx.de/u-boot/custodians/u-boot-dm/-/commit/073b5c= 156f222c69a98b8ebcaa563d1ff10eb217
>>
>>
>> Simon Glass (31):
>>=C2=A0 =C2=A0Makefile: Correct TPL rule for OF_REAL
>>=C2=A0 =C2=A0kconfig: Add support for conditional values
>>=C2=A0 =C2=A0dm: core: Allow getting some basic stats
>>=C2=A0 =C2=A0stddef: Avoid warning with clang with offsetof()
>>=C2=A0 =C2=A0fdt: Drop SPL_BUILD macro
>>=C2=A0 =C2=A0bloblist: Put the magic number first
>>=C2=A0 =C2=A0bloblist: Rename the SPL tag
>>=C2=A0 =C2=A0bloblist: Drop unused tags
>>=C2=A0 =C2=A0bloblist: Use explicit numbering for the tags
>>=C2=A0 =C2=A0bloblist: Support allocating the bloblist
>>=C2=A0 =C2=A0bloblist: Use LOG_CATEGORY to simply logging
>>=C2=A0 =C2=A0bloblist: Use 'phase' consistently for bloblis= ts
>>=C2=A0 =C2=A0bloblist: Refactor Kconfig to support alloc or fixed >>=C2=A0 =C2=A0arm: qemu: Add an SPL build
>>=C2=A0 =C2=A0bloblist: Add functions to obtain base address and siz= e
>>=C2=A0 =C2=A0passage: Support an incoming passage
>>=C2=A0 =C2=A0passage: Support a control devicetree
>>=C2=A0 =C2=A0passage: arm: Accept a passage from the previous phase=
>>=C2=A0 =C2=A0passage: spl: Support adding the dtb to the passage bl= oblist
>>=C2=A0 =C2=A0passage: spl: Support passing the passage to U-Boot >>=C2=A0 =C2=A0passage: Record where the devicetree came from
>>=C2=A0 =C2=A0passage: Report the devicetree source
>>=C2=A0 =C2=A0passage: Add a qemu test for ARM
>>=C2=A0 =C2=A0bloblist: doc: Bring in the API documentation
>>=C2=A0 =C2=A0bloblist: Relicense to allow BSD-3-Clause
>>=C2=A0 =C2=A0sandbox: Add a way of checking structs for standard pa= ssage
>>=C2=A0 =C2=A0passage: Add documentation
>>=C2=A0 =C2=A0passage: Add docs for spl_handoff
>>=C2=A0 =C2=A0x86: Move Intel GNVS file into the common include dire= ctory
>>=C2=A0 =C2=A0passage: Add checks for pre-existing blobs
>>=C2=A0 =C2=A0WIP: RFC: Add a gitlab test
>>
>>=C2=A0 .gitlab-ci.yml=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A06 +
>>=C2=A0 MAINTAINERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 10 +
>>=C2=A0 Makefile=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A02 +-
>>=C2=A0 arch/arm/cpu/armv7/start.S=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A07 +-
>>=C2=A0 arch/arm/dts/qemu-arm-u-boot.dtsi=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 22 ++
>>=C2=A0 arch/arm/lib/crt0.S=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A04 + >>=C2=A0 arch/arm/mach-qemu/Kconfig=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A09 +
>>=C2=A0 arch/sandbox/cpu/spl.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A02 +-
>>=C2=A0 arch/x86/cpu/apollolake/acpi.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A02 +-
>>=C2=A0 arch/x86/cpu/broadwell/cpu_from_spl.c=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A04 +-
>>=C2=A0 arch/x86/cpu/intel_common/acpi.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A02 +-
>>=C2=A0 .../include/asm/arch-apollolake/global_nvs.h=C2=A0 |=C2=A0 = =C2=A02 +-
>>=C2=A0 arch/x86/lib/spl.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A02 +-<= br> >>=C2=A0 arch/x86/lib/tpl.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A02 +-<= br> >>=C2=A0 board/emulation/qemu-arm/Kconfig=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 23 +-
>>=C2=A0 board/emulation/qemu-arm/MAINTAINERS=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A01 +
>>=C2=A0 board/emulation/qemu-arm/Makefile=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A01 +
>>=C2=A0 board/emulation/qemu-arm/spl.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 27 ++
>>=C2=A0 board/google/chromebook_coral/coral.c=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A02 +-
>>=C2=A0 board/sandbox/Makefile=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A03 +-
>>=C2=A0 board/sandbox/stdpass_check.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 107 ++++++
>>=C2=A0 cmd/bdinfo.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A02 +
>>=C2=A0 common/Kconfig=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 161 ++= ++++++-
>>=C2=A0 common/bloblist.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 124 +++++--=
>>=C2=A0 common/board_f.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 48 += +-
>>=C2=A0 common/board_r.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 18 +=
>>=C2=A0 common/spl/spl.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 74 += ++-
>>=C2=A0 configs/qemu_arm_spl_defconfig=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 78 +++++
>>=C2=A0 doc/board/emulation/qemu-arm.rst=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 38 +++
>>=C2=A0 doc/develop/bloblist.rst=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 28 +-
>>=C2=A0 doc/develop/index.rst=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A01 +
>>=C2=A0 doc/develop/std_passage.rst=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 319 ++++++++++++++++++
>>=C2=A0 drivers/core/device.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 11 +
>>=C2=A0 drivers/core/root.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A07 + >>=C2=A0 drivers/core/uclass.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 13 +
>>=C2=A0 drivers/serial/serial-uclass.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A03 +-
>>=C2=A0 dts/Kconfig=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 12 +
>>=C2=A0 include/asm-generic/global_data.h=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 35 ++
>>=C2=A0 include/bloblist.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 175 +++++++--- >>=C2=A0 include/dm/device.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 11 +-
>>=C2=A0 include/dm/root.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A08 +
>>=C2=A0 include/dm/uclass-internal.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A07 +
>>=C2=A0 include/fdtdec.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 40 += +-
>>=C2=A0 include/handoff.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A08 +-
>>=C2=A0 .../x86/include/asm =3D> include}/intel_gnvs.h=C2=A0 |=C2= =A0 =C2=A00
>>=C2=A0 include/linux/kconfig.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 18 +
>>=C2=A0 include/linux/stddef.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A08 +-
>>=C2=A0 include/spl.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 15 +
>>=C2=A0 include/stdpass/README=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A04 +
>>=C2=A0 include/stdpass/tpm2_eventlog.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 42 +++
>>=C2=A0 include/stdpass/vboot_ctx.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 267 +++++++++++++++
>>=C2=A0 lib/asm-offsets.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A05 +
>>=C2=A0 lib/fdtdec.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 65 +++-
>>=C2=A0 scripts/config_whitelist.txt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A01 +
>>=C2=A0 test/bloblist.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 2= 1 +-
>>=C2=A0 test/dm/core.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = 41 +++
>>=C2=A0 test/py/tests/test_passage.py=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 11 +
>>=C2=A0 57 files changed, 1798 insertions(+), 161 deletions(-)
>>=C2=A0 create mode 100644 arch/arm/dts/qemu-arm-u-boot.dtsi
>>=C2=A0 create mode 100644 board/emulation/qemu-arm/spl.c
>>=C2=A0 create mode 100644 board/sandbox/stdpass_check.c
>>=C2=A0 create mode 100644 configs/qemu_arm_spl_defconfig
>>=C2=A0 create mode 100644 doc/develop/std_passage.rst
>>=C2=A0 rename {arch/x86/include/asm =3D> include}/intel_gnvs.h (= 100%)
>>=C2=A0 create mode 100644 include/stdpass/README
>>=C2=A0 create mode 100644 include/stdpass/tpm2_eventlog.h
>>=C2=A0 create mode 100644 include/stdpass/vboot_ctx.h
>>=C2=A0 create mode 100644 test/py/tests/test_passage.py
>>
>> --
>> 2.33.1.1089.g2158813163f-goog
>>
>
>
> --
> Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | Director Business Development<= br> > T: +33.67221.6485
> francois= .ozog@linaro.org | Skype: ffozog
>


--
=
=
Fran=C3=A7ois-Fr=C3= =A9d=C3=A9ric Ozog=C2=A0|=C2=A0Director Business Development
T:=C2=A0+33.67221.6485
francois.ozog@linaro.org=C2=A0|=C2=A0Skype:=C2=A0ffozog

--000000000000d8a59e05cfd06ec7--