Re: [PATCH] riscv: ae350: Use #if defined instead of CONFIG_IS_ENABLED

2021-10-31 Thread Rick Chen
> From: Leo Yu-Chi Liang(梁育齊) 
> Sent: Wednesday, October 27, 2021 4:59 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> 
> Cc: u-boot@lists.denx.de
> Subject: [PATCH] riscv: ae350: Use #if defined instead of CONFIG_IS_ENABLED
>
> According to ./include/linux/kconfig.h,
> CONFIG_IS_ENABLED(OF_BOARD) expands to 0 when CONFIG_SPL_BUILD is defined 
> because there is no CONFIG_SPL_OF_BOARD.
>
> Use #if defined instead.
>
> Signed-off-by: Leo Yu-Chi Liang 
> ---
>  board/AndesTech/ax25-ae350/ax25-ae350.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH 07/10] Convert CONFIG_OF_EMBED to Kconfig

2021-10-31 Thread Rick Chen
> From: U-Boot  On Behalf Of Tom Rini
> Sent: Sunday, October 31, 2021 11:04 AM
> To: u-boot@lists.denx.de
> Subject: [PATCH 07/10] Convert CONFIG_OF_EMBED to Kconfig
>
> This converts the following to Kconfig:
>CONFIG_OF_EMBED
>
> Signed-off-by: Tom Rini 
> ---
>  README| 7 ---
>  configs/adp-ae3xx_defconfig   | 1 +
>  configs/adp-ag101p_defconfig  | 1 +
>  include/configs/adp-ae3xx.h   | 1 -
>  include/configs/adp-ag101p.h  | 1 -
>  include/configs/cgtqmx8.h | 2 --
>  include/configs/imx8qm_mek.h  | 2 --
>  include/configs/imx8qxp_mek.h | 2 --
>  8 files changed, 2 insertions(+), 15 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH 1/2] test/dm: fix watchdog test

2021-10-31 Thread Heinrich Schuchardt



Am 1. November 2021 00:46:49 MEZ schrieb Simon Glass :
>On Thu, 28 Oct 2021 at 04:16, Heinrich Schuchardt
> wrote:
>>
>> Avoid a build failure for CONFIG_WDT_GPIO=n.
>>
>> We need this setting to test watchdog based system reset.
>
>watchdog-based
>
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  test/dm/wdt.c | 4 
>>  1 file changed, 4 insertions(+)
>
>Reviewed-by: Simon Glass 
>
>>
>> diff --git a/test/dm/wdt.c b/test/dm/wdt.c
>> index ee615f0e14..07a8eb0e7a 100644
>> --- a/test/dm/wdt.c
>> +++ b/test/dm/wdt.c
>> @@ -44,6 +44,7 @@ static int dm_test_wdt_base(struct unit_test_state *uts)
>>  }
>>  DM_TEST(dm_test_wdt_base, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
>>
>> +#ifdef CONFIG_WDT_GPIO
>>  static int dm_test_wdt_gpio(struct unit_test_state *uts)
>>  {
>> /*
>> @@ -75,6 +76,7 @@ static int dm_test_wdt_gpio(struct unit_test_state *uts)
>> return 0;
>>  }
>>  DM_TEST(dm_test_wdt_gpio, UT_TESTF_SCAN_FDT);
>> +#endif
>>
>>  static int dm_test_wdt_watchdog_reset(struct unit_test_state *uts)
>>  {
>> @@ -86,9 +88,11 @@ static int dm_test_wdt_watchdog_reset(struct 
>> unit_test_state *uts)
>> uint reset_count;
>> int val;
>>
>> +#ifdef CONFIG_WDT_GPIO
>
>The #ifdef is unfortunate but I believe it is needed due to
>DM_DRIVER_GET. You could get by name perhaps, or just get the first
>device?

Thanks for reviewing

We could move the GPIO test to a separate file and make the decision in 
Makefile. This would avoid #ifdef.

Best regards 
Heinrich 


>
>> ut_assertok(uclass_get_device_by_driver(UCLASS_WDT,
>> DM_DRIVER_GET(wdt_gpio), 
>> _wdt));
>> ut_assertnonnull(gpio_wdt);
>> +#endif
>> ut_assertok(uclass_get_device_by_driver(UCLASS_WDT,
>> DM_DRIVER_GET(wdt_sandbox), 
>> _wdt));
>> ut_assertnonnull(sandbox_wdt);
>> --
>> 2.32.0
>>
>
>Regards,
>Simon


[PATCH] dts: rockchip: rk3399: enable emmc phy for spl

2021-10-31 Thread Yifeng Zhao
adapting commit ac804143cf ("mmc: rockchip_sdhci: add phy and clock
config for rk3399") to fix the issue "Not found emmc phy device".

Signed-off-by: Yifeng Zhao 
---

 arch/arm/dts/rk3399-u-boot.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 73922c328a..716b9a433a 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -88,6 +88,10 @@
u-boot,dm-pre-reloc;
 };
 
+_phy {
+   u-boot,dm-pre-reloc;
+};
+
  {
u-boot,dm-pre-reloc;
 };
-- 
2.17.1





Please pull u-boot-x86

2021-10-31 Thread Bin Meng
Hi Tom,

This PR includes the following x86 changes for v2022.01:

- Fixes for x86 build with Clang/LLVM compiler
- Tangier ACPI changes
- Edison SD card detect pin fix
- EFI on x86 doc update with latest instructions
- PXE utility fixes to align with latest x86 zboot implementation

Azure results: PASS
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=462=results

The following changes since commit 360e392274e3bfeda3b7226d2cac7514774d0da1:

  Merge tag 'dm-pull-boo21' of
https://source.denx.de/u-boot/custodians/u-boot-dm (2021-10-31
15:48:43 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-x86

for you to fetch changes up to 5270bee9b27cf63251696916e4b5a5d4412d3a2d:

  x86: tangier: pinmux: Move error message to the caller (2021-11-01
10:19:05 +0800)


Alistair Delva (2):
  x86: chromebook_coral: fix C block comment
  x86: Fix i8254 ifdef include guard

Andy Shevchenko (5):
  x86: tangier: Replace Method() by Name() for _STA object
  x86: tangier: Enable support for SD/SDIO family in the pinmux driver
  x86: edison: Don't take SD card detect pin into consideration
  x86: tangier: pinmux: Move is_protected assignment closer to its user
  x86: tangier: pinmux: Move error message to the caller

Bin Meng (1):
  docs: uefi: Update stale U-Boot on EFI doc

Zhaofeng Li (2):
  pxe_utils: Fix arguments to x86 zboot
  pxe_utils: Clean up {bootm,zboot}_argv generation

 arch/x86/cpu/tangier/pinmux.c   | 48

 arch/x86/dts/chromebook_coral.dts   |  1 +
 arch/x86/dts/edison.dts | 17 +
 arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 81
+
 arch/x86/include/asm/i8254.h|  4 ++--
 cmd/pxe_utils.c | 45
-
 doc/develop/uefi/u-boot_on_efi.rst  | 12 +++-
 7 files changed, 112 insertions(+), 96 deletions(-)

Regards,
Bin


RE: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES

2021-10-31 Thread Roman Kopytin
Hi, all
Currently I am waiting some help from our IT infrastructure department.

-Original Message-
From: Simon Glass  
Sent: Tuesday, October 26, 2021 4:28 AM
To: Rasmus Villemoes 
Cc: U-Boot Mailing List ; Alex Kiernan 
; Roman Kopytin ; Masahiro 
Yamada 
Subject: Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES

Hi Rasmus,

On Tue, 28 Sept 2021 at 02:57, Rasmus Villemoes  
wrote:
>
> The build system already automatically looks for and includes an 
> in-tree *-u-boot.dtsi when building the control .dtb. However, there 
> are some things that are awkward to maintain in such an in-tree file, 
> most notably the metadata associated to public keys used for verified 
> boot.
>
> The only "official" API to get that metadata into the .dtb is via 
> mkimage, as a side effect of building an actual signed image. But 
> there are multiple problems with that. First of all, the final U-Boot 
> (be it U-Boot proper or an SPL) image is built based on a binary 
> image, the .dtb, and possibly some other binary artifacts. So 
> modifying the .dtb after the build requires the meta-buildsystem 
> (Yocto, buildroot, whatnot) to know about and repeat some of the steps 
> that are already known to and handled by U-Boot's build system, 
> resulting in needless duplication of code. It's also somewhat annoying 
> and inconsistent to have a .dtb file in the build folder which is not 
> generated by the command listed in the corresponding .cmd file (that 
> of course applies to any generated file).
>
> So the contents of the /signature node really needs to be baked into 
> the .dtb file when it is first created, which means providing the 
> relevant data in the form of a .dtsi file. One could in theory put 
> that data into the *-u-boot.dtsi file, but it's more convenient to be 
> able to provide it externally: For example, when developing for a 
> customer, it's common to use a set of dummy keys for development, 
> while the consultants do not (and should not) have access to the 
> actual keys used in production. For such a setup, it's easier if the 
> keys used are chosen via the meta-buildsystem and the path(s) patched 
> in during the configure step. And of course, nothing prevents anybody 
> from having DEVICE_TREE_INCLUDES point at files maintained in git, or 
> for that matter from including the public key metadata in the 
> *-u-boot.dtsi directly and ignore this feature.
>
> There are other uses for this, e.g. in combination with ENV_IMPORT_FDT 
> it can be used for providing the contents of the /config/environment 
> node, so I don't want to tie this exclusively to use for verified 
> boot.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>
> Getting the public key metadata into .dtsi form can be done with a 
> little scripting (roughly 'mkimage -K' of a dummy image followed by 
> 'dtc -I dtb -O dts'). I have a script that does that, along with 
> options to set 'required' and 'required-mode' properties, include 
> u-boot,dm-spl properties in case one wants to check U-Boot proper from 
> SPL with the verified boot mechanism, etc. I'm happy to share that 
> script if this gets accepted, but it's moot if this is rejected.
>
> I have previously tried to get an fdt_add_pubkey tool accepted [1,2] 
> to disentangle the kernel and u-boot builds (or u-boot and SPL builds 
> for that matter!), but as I've since realized, that isn't quite enough
> - the above points re modifying the .dtb after it is created but 
> before that is used to create further build artifacts still stand. 
> However, such a tool could still be useful for creating the .dtsi info 
> without the private keys being present, and my key2dtsi.sh script 
> could easily be modified to use a tool like that should it ever 
> appear.
>
> [1] 
> https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villemoes
> @prevas.dk/ [2] 
> https://lore.kernel.org/u-boot/2184f1e6dd6247e48133c76205feeabe@kasper
> sky.com/
>
>  dts/Kconfig  | 9 +
>  scripts/Makefile.lib | 2 ++
>  2 files changed, 11 insertions(+)

Reviewed-by: Simon Glass 

I suggest adding this to the documentation somewhere in doc/develop/devicetree/

Getting the key into the U-Boot .dtb is normally done with mkimage, as you say. 
I don't really understand why this approach is easier.

Also, is there any interest in using binman? It is designed to do the 
'packaging' step right at the end, when all the bits are available and just 
need to be put together.

I am trying to encourage people to move away from building from source always, 
to a two-step process:

- build all the bits
- package them, update devicetree, etc.

https://u-boot.readthedocs.io/en/latest/develop/package/index.html

BTW if Roman can figure out how to send the patches I think that tool would be 
useful too.

Regards,
Simon



>
> diff --git a/dts/Kconfig b/dts/Kconfig index dabe0080c1..593dddbaf0 
> 100644
> --- a/dts/Kconfig
> +++ b/dts/Kconfig
> @@ -139,6 +139,15 @@ config DEFAULT_DEVICE_TREE
>   It can be 

[RFC PATCH] RFC: Sketch of dm event notification

2021-10-31 Thread Simon Glass
This is a patch for Takahiro to look at, just for illustration. Not ready
for review.

To run the test:

./u-boot -T -c "ut common test_event_probe"

Signed-off-by: Simon Glass 
---

 common/Kconfig|  11 
 common/Makefile   |   2 +
 common/board_f.c  |   2 +
 common/event.c| 103 ++
 common/log.c  |   1 +
 drivers/core/device.c |  14 
 include/asm-generic/global_data.h |   3 +
 include/event.h   | 103 ++
 include/event_internal.h  |  34 ++
 include/log.h |   2 +
 test/common/Makefile  |   1 +
 test/common/event.c   |  85 
 test/test-main.c  |   5 ++
 13 files changed, 366 insertions(+)
 create mode 100644 common/event.c
 create mode 100644 include/event.h
 create mode 100644 include/event_internal.h
 create mode 100644 test/common/event.c

diff --git a/common/Kconfig b/common/Kconfig
index d6f77ab7b9c..54d0adaa8d5 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -484,6 +484,17 @@ config DISPLAY_BOARDINFO_LATE
 
 menu "Start-up hooks"
 
+config EVENT
+   bool "General-purpose event-handling mechanism"
+   default y if SANDBOX
+   help
+ This enables sending and processing of events, to allow interested
+ parties to be alerted when something happens. This is an attempt to
+ step the flow of weak functions, hooks, functions in board_f.c
+ and board_r.c and the Kconfig options below.
+
+ See doc/develop/event.rst for more information.
+
 config ARCH_EARLY_INIT_R
bool "Call arch-specific init soon after relocation"
help
diff --git a/common/Makefile b/common/Makefile
index e7839027b6c..1b4601ac13f 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -101,6 +101,8 @@ obj-y += malloc_simple.o
 endif
 endif
 
+obj-$(CONFIG_EVENT) += event.o
+
 obj-y += image.o image-board.o
 obj-$(CONFIG_$(SPL_TPL_)HASH) += hash.o
 obj-$(CONFIG_ANDROID_AB) += android_ab.o
diff --git a/common/board_f.c b/common/board_f.c
index 3dc0eaa59c5..faf262d564c 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -820,6 +821,7 @@ static const init_fnc_t init_sequence_f[] = {
initf_malloc,
log_init,
initf_bootstage,/* uses its own timer, so does not need DM */
+   event_init,
 #ifdef CONFIG_BLOBLIST
bloblist_init,
 #endif
diff --git a/common/event.c b/common/event.c
new file mode 100644
index 000..428628da44d
--- /dev/null
+++ b/common/event.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Events provide a general-purpose way to react to / subscribe to changes
+ * within U-Boot
+ *
+ * Copyright 2021 Google LLC
+ * Written by Simon Glass 
+ */
+
+#define LOG_CATEGORY   LOGC_EVENT
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static void spy_free(struct event_spy *spy)
+{
+   list_del(>sibling_node);
+}
+
+int event_register(const char *id, enum event_t type, event_handler_t func, 
void *ctx)
+{
+   struct event_state *state = gd->event_state;
+   struct event_spy *spy;
+
+   spy = malloc(sizeof(*spy));
+   if (!spy)
+   return log_msg_ret("alloc", -ENOMEM);
+
+   spy->id = id;
+   spy->type = type;
+   spy->func = func;
+   spy->ctx = ctx;
+   list_add_tail(>sibling_node, >spy_head);
+
+   return 0;
+}
+
+int event_notify(enum event_t type, void *data, int size)
+{
+   struct event_state *state = gd->event_state;
+   struct event_spy *spy, *next;
+   struct event event;
+
+   event.type = type;
+   if (size > sizeof(event.data))
+   return log_msg_ret("size", -E2BIG);
+   memcpy(, data, size);
+   list_for_each_entry_safe(spy, next, >spy_head, sibling_node) {
+   if (spy->type == type) {
+   int ret;
+
+   log_debug("Sending event %x to spy '%s'\n", type,
+ spy->id);
+   ret = spy->func(spy->ctx, );
+
+   /*
+* TODO: Handle various return codes to
+*
+* - claim an event (no others will see it)
+* - return an error from the event
+*/
+   if (ret)
+   return log_msg_ret("spy", ret);
+   }
+   }
+
+   return 0;
+}
+
+int event_uninit(void)
+{
+   struct event_state *state = gd->event_state;
+   struct event_spy *spy, *next;
+
+   if (!state)
+   return 0;
+   list_for_each_entry_safe(spy, next, >spy_head, sibling_node)
+   

Re: [RFC 14/22] dm: blk: call efi's device-probe hook

2021-10-31 Thread Simon Glass
Hi Takahiro,

On Mon, 11 Oct 2021 at 08:54, Simon Glass  wrote:
>
> Hi Takahiro,
>
> On Sun, 10 Oct 2021 at 21:15, AKASHI Takahiro
>  wrote:
> >
> > Hi Simon,
> >
> > On Sun, Oct 10, 2021 at 08:14:23AM -0600, Simon Glass wrote:
> > > Hi Takahiro,
> > >
> > > On Thu, 30 Sept 2021 at 23:04, AKASHI Takahiro
> > >  wrote:
> > > >
> > > > Adding this callback function, efi_disk_create() in block devices's
> > > > post_probe hook will allows for automatically creating efi_disk objects
> > > > per block device.
> > > >
> > > > This will end up not only eliminating efi_disk_register() called in UEFI
> > > > initialization, but also enabling detections of new block devices even
> > > > after the initialization.
> > > >
> > > > Signed-off-by: AKASHI Takahiro 
> > > > ---
> > > >  drivers/block/blk-uclass.c | 10 ++
> > > >  1 file changed, 10 insertions(+)
> > >
> > > This is where events come in. We need a way to notify things when
> > > devices go through different stages, etc.
> >
> > I favor your idea of event notification to decouple subsystems from
> > the core block layer.
> >
> > > I am thinking of:
> > >
> > > enum dm_event_t {
> > >DMEVT_PROBE,
> > >DMEVT_POST_PROBE,
> > > ...
> > > };
> > >
> > > struct dm_event {
> > > enum dm_event_t type;
> > > union {
> > > // add data for different event types in here
> > > } data;
> > > }
> > >
> > > int (*dm_handler_t)(void *ctx, struct dm_event *event);
> > >
> > > int dm_register(enum dm_event_t evtype, dm_handler_t func, void *ctx)
> > >
> > > int dm_notify(struct udevice *dev, enum dm_event_t type, void *data);
> > >
> > > Then the code below becomes:
> > >
> > > dm_notify(struct udevice *dev, DMEVT_POST_PROBE, NULL);
> > >
> > > the implementation of which will call the handler.
> > >
> > > If you like I could create an impl of the above as a separate patch
> > > for discussion.
> >
> > Yes, please.
> > I'm willing to rebase my code on top of your patch.
>
> OK I will give it a crack, hopefully around the end of the week.

Well that didn't happen as the two things ahead of it expanded.

I'll send a patch with a sketch soon, for you to look at.

Regards,
Simon


Re: [PATCH] Azure: Move to windows-2019

2021-10-31 Thread Bin Meng
On Mon, Nov 1, 2021 at 1:25 AM Tom Rini  wrote:
>
> As per https://github.com/actions/virtual-environments/issues/4312 the
> Windows-2016 environments are scheduled for deprecation and removal in
> early 2022.  Move to windows-2019 now to avoid this (Visual Studio 2019
> is included here, hence the tag naming scheme change).
>
> Signed-off-by: Tom Rini 
> ---
>  .azure-pipelines.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1 2/2] x86: tangier: pinmux: Move error message to the caller

2021-10-31 Thread Bin Meng
On Mon, Nov 1, 2021 at 10:18 AM Bin Meng  wrote:
>
> On Wed, Oct 27, 2021 at 10:23 PM Andy Shevchenko
>  wrote:
> >
> > Move error message to the caller of mrfld_pinconfig*() in order
> > to unify them in the future.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/cpu/tangier/pinmux.c | 10 +++---
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v1 2/2] x86: tangier: pinmux: Move error message to the caller

2021-10-31 Thread Bin Meng
On Wed, Oct 27, 2021 at 10:23 PM Andy Shevchenko
 wrote:
>
> Move error message to the caller of mrfld_pinconfig*() in order
> to unify them in the future.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/cpu/tangier/pinmux.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION

2021-10-31 Thread Simon Glass
Hi Takahiro,

On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro
 wrote:
>
> On Sun, Oct 31, 2021 at 07:15:17PM -0600, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Sun, 31 Oct 2021 at 18:36, AKASHI Takahiro
> >  wrote:
> > >
> > > On Sat, Oct 30, 2021 at 07:45:14AM +0200, Heinrich Schuchardt wrote:
> > > >
> > > >
> > > > Am 29. Oktober 2021 23:17:56 MESZ schrieb Simon Glass 
> > > > :
> > > > >Hi,
> > > > >
> > > > >On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt  
> > > > >wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >> Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takahiro 
> > > > >> :
> > > > >> >On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote:
> > > > >> >>
> > > > >> >>
> > > > >> >> > I agree with Heinrich that we are better to leave BLK as it is, 
> > > > >> >> > both
> > > > >> >> > in name and meaning. I think maybe I am missing the gist of your
> > > > >> >> > argument.
> > > > >> >> >
> > > > >> >> > If we use UCLASS_PART, for example, can we have that refer to 
> > > > >> >> > both s/w
> > > > >> >> > and h/w partitions, as Herinch seems to allude to below? What 
> > > > >> >> > would
> > > > >> >> > the picture look like the, and would it get us closer to 
> > > > >> >> > agreement?
> > > > >> >>
> > > > >> >> In the driver model:
> > > > >> >>
> > > > >> >> A UCLASS is a class of drivers that share the same interface.
> > > > >> >> A UDEVICE is a logical device that belongs to exactly one UCLASS 
> > > > >> >> and is
> > > > >> >> accessed through this UCLASS's interface.
> > > > >> >
> > > > >> >Please be careful about "accessed through" which is a quite 
> > > > >> >confusing
> > > > >> >expression. I don't always agree with this view.
> > > > >> >
> > > > >> >> A hardware partition is an object that exposes only a single 
> > > > >> >> interface
> > > > >> >> for block IO.
> > > > >> >>
> > > > >> >> A software partition is an object that may expose two interfaces: 
> > > > >> >> one
> > > > >> >> for block IO, the other for file IO.
> > > > >> >
> > > > >> >Are you talking about UEFI world or U-Boot?
> > > > >> >Definitely, a hw partitions can provide a file system
> > > > >> >if you want.
> > > > >> >It's a matter of usage.
> > > > >> >
> > > > >> >I remember that we had some discussion about whether block devices
> > > > >> >on UEFI system should always have a (sw) partition table or not.
> > > > >> >But it is a different topic.
> > > > >> >
> > > > >> >> The UEFI model does not have a problem with this because on a 
> > > > >> >> handle you
> > > > >> >> can install as many different protocols as you wish. But U-Boot's 
> > > > >> >> driver
> > > > >> >> model only allows a single interface per device. Up to now U-Boot 
> > > > >> >> has
> > > > >> >> overcome this limitation by creating child devices for the extra 
> > > > >> >> interfaces.
> > > > >> >
> > > > >> >> We have the following logical levels:
> > > > >> >>
> > > > >> >> Controller  | Block device | Software Partition| File system
> > > > >> >> +--+---+
> > > > >> >> NVMe Drive  | Namespace| Partition 1..n| FAT, EXT4
> > > > >> >> ATA Controller  | ATA-Drive|   |
> > > > >> >> SCSI Controller | LUN  |   |
> > > > >> >> MMC Controller  | HW-Partition |   |
> > > > >> >> MMC Controller  | SD-Card  |   |
> > > > >> >> USB-Node| USB-Drive|   |
> > > > >> >>
> > > > >> >> In the device tree this could be modeled as:
> > > > >> >>
> > > > >> >> |-- Controller (UCLASS_CTRL)
> > > > >> >> | |-- Block device / HW Partition (UCLASS_BLK)(A)
> > > > >> >> | | |-- Partition table (UCLASS_PARTITION_TABLE)  (B)
> > > > >> >> | |   |-- Software Partition (UCLASS_BLK)
> > > > >> >> | | |-- File system (UCLASS_FS)
> > > > >> >> | |
> > > > >> >> | |-- Block device (UCLASS_BLK)
> > > > >> >> |   |-- File system (UCLASS_FS)
> > > > >> >
> > > > >> >I don't know why we expect PARTITION_TABLE and FS to appear in DM 
> > > > >> >tree.
> > > > >> >What is the benefit?
> > > > >> >(A) and (B) always have 1:1 relationship.
> > > > >>
> > > > >> No. You can have a bare device without a partition table.
> > > > >
> > > > >I can have a DOS partition that covers the whole device, without a
> > > > >partition table. This is supported in U-Boot and Linux.
> > > > >
> > > > >>
> > > > >> We have several partition table drivers: DOS, GPT, OSX, ... . In 
> > > > >> future we should also have one for the NOR Flash partitions. All of 
> > > > >> these drivers have a common interface. As the partition table type 
> > > > >> is mostly independent of the block device type we should use 
> > > > >> separate uclasses and udevices.
> > > > >>
> > > > >> >I also remember that you claimed that not all efi objects(handles 
> > > > >> >and
> > > > >> >protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have 
> > > > >> >corresponding
> > > > >> >U-Boot 

Re: [PATCH v1 1/2] x86: tangier: pinmux: Move is_protected assignment closer to its user

2021-10-31 Thread Bin Meng
On Mon, Nov 1, 2021 at 10:05 AM Bin Meng  wrote:
>
> On Wed, Oct 27, 2021 at 10:23 PM Andy Shevchenko
>  wrote:
> >
> > Move is_protected assignment closer to its user.
> > This increases readability and makes maintenance easier.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/cpu/tangier/pinmux.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v1 1/2] x86: tangier: pinmux: Move is_protected assignment closer to its user

2021-10-31 Thread Bin Meng
On Wed, Oct 27, 2021 at 10:23 PM Andy Shevchenko
 wrote:
>
> Move is_protected assignment closer to its user.
> This increases readability and makes maintenance easier.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/cpu/tangier/pinmux.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION

2021-10-31 Thread AKASHI Takahiro
On Sun, Oct 31, 2021 at 07:15:17PM -0600, Simon Glass wrote:
> Hi Takahiro,
> 
> On Sun, 31 Oct 2021 at 18:36, AKASHI Takahiro
>  wrote:
> >
> > On Sat, Oct 30, 2021 at 07:45:14AM +0200, Heinrich Schuchardt wrote:
> > >
> > >
> > > Am 29. Oktober 2021 23:17:56 MESZ schrieb Simon Glass :
> > > >Hi,
> > > >
> > > >On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt  
> > > >wrote:
> > > >>
> > > >>
> > > >>
> > > >> Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takahiro 
> > > >> :
> > > >> >On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote:
> > > >> >>
> > > >> >>
> > > >> >> > I agree with Heinrich that we are better to leave BLK as it is, 
> > > >> >> > both
> > > >> >> > in name and meaning. I think maybe I am missing the gist of your
> > > >> >> > argument.
> > > >> >> >
> > > >> >> > If we use UCLASS_PART, for example, can we have that refer to 
> > > >> >> > both s/w
> > > >> >> > and h/w partitions, as Herinch seems to allude to below? What 
> > > >> >> > would
> > > >> >> > the picture look like the, and would it get us closer to 
> > > >> >> > agreement?
> > > >> >>
> > > >> >> In the driver model:
> > > >> >>
> > > >> >> A UCLASS is a class of drivers that share the same interface.
> > > >> >> A UDEVICE is a logical device that belongs to exactly one UCLASS 
> > > >> >> and is
> > > >> >> accessed through this UCLASS's interface.
> > > >> >
> > > >> >Please be careful about "accessed through" which is a quite confusing
> > > >> >expression. I don't always agree with this view.
> > > >> >
> > > >> >> A hardware partition is an object that exposes only a single 
> > > >> >> interface
> > > >> >> for block IO.
> > > >> >>
> > > >> >> A software partition is an object that may expose two interfaces: 
> > > >> >> one
> > > >> >> for block IO, the other for file IO.
> > > >> >
> > > >> >Are you talking about UEFI world or U-Boot?
> > > >> >Definitely, a hw partitions can provide a file system
> > > >> >if you want.
> > > >> >It's a matter of usage.
> > > >> >
> > > >> >I remember that we had some discussion about whether block devices
> > > >> >on UEFI system should always have a (sw) partition table or not.
> > > >> >But it is a different topic.
> > > >> >
> > > >> >> The UEFI model does not have a problem with this because on a 
> > > >> >> handle you
> > > >> >> can install as many different protocols as you wish. But U-Boot's 
> > > >> >> driver
> > > >> >> model only allows a single interface per device. Up to now U-Boot 
> > > >> >> has
> > > >> >> overcome this limitation by creating child devices for the extra 
> > > >> >> interfaces.
> > > >> >
> > > >> >> We have the following logical levels:
> > > >> >>
> > > >> >> Controller  | Block device | Software Partition| File system
> > > >> >> +--+---+
> > > >> >> NVMe Drive  | Namespace| Partition 1..n| FAT, EXT4
> > > >> >> ATA Controller  | ATA-Drive|   |
> > > >> >> SCSI Controller | LUN  |   |
> > > >> >> MMC Controller  | HW-Partition |   |
> > > >> >> MMC Controller  | SD-Card  |   |
> > > >> >> USB-Node| USB-Drive|   |
> > > >> >>
> > > >> >> In the device tree this could be modeled as:
> > > >> >>
> > > >> >> |-- Controller (UCLASS_CTRL)
> > > >> >> | |-- Block device / HW Partition (UCLASS_BLK)(A)
> > > >> >> | | |-- Partition table (UCLASS_PARTITION_TABLE)  (B)
> > > >> >> | |   |-- Software Partition (UCLASS_BLK)
> > > >> >> | | |-- File system (UCLASS_FS)
> > > >> >> | |
> > > >> >> | |-- Block device (UCLASS_BLK)
> > > >> >> |   |-- File system (UCLASS_FS)
> > > >> >
> > > >> >I don't know why we expect PARTITION_TABLE and FS to appear in DM 
> > > >> >tree.
> > > >> >What is the benefit?
> > > >> >(A) and (B) always have 1:1 relationship.
> > > >>
> > > >> No. You can have a bare device without a partition table.
> > > >
> > > >I can have a DOS partition that covers the whole device, without a
> > > >partition table. This is supported in U-Boot and Linux.
> > > >
> > > >>
> > > >> We have several partition table drivers: DOS, GPT, OSX, ... . In 
> > > >> future we should also have one for the NOR Flash partitions. All of 
> > > >> these drivers have a common interface. As the partition table type is 
> > > >> mostly independent of the block device type we should use separate 
> > > >> uclasses and udevices.
> > > >>
> > > >> >I also remember that you claimed that not all efi objects(handles and
> > > >> >protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corresponding
> > > >> >U-Boot counterparts in our 2019 discussion.
> > > >> >
> > > >> >If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TABLE,
> > > >> >which should support other type of hw partitions as well?
> > > >>
> > > >> How hardware partitions, LUNs, ATA drives are enumerated is specific 
> > > >> to the type of controller while the type of software 

[PATCH 22/31] passage: Report the devicetree source

2021-10-31 Thread Simon Glass
It can be confusing to figure out where the devicetree came from. It seems
important enough to warrant a message during boot. Add information about
the number of devices and uclasses too since it is helpful to have some
idea what is going on with driver model.

Report the devicetree source in bdinfo too.

This looks something like this, with > marking the new line.

   U-Boot 2021.10-00190 (Oct 30 2021 - 09:01:29 -0600)

   DRAM:  128 MiB
>  Core:  42 devices, 11 uclasses, devicetree: passage
   Flash: 64 MiB

Signed-off-by: Simon Glass 
---

 cmd/bdinfo.c |  2 ++
 common/board_r.c | 18 ++
 lib/fdtdec.c | 14 ++
 3 files changed, 34 insertions(+)

diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index bf63cc6d649..c56b3f4f6ec 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -128,6 +128,8 @@ int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
 
lmb_init_and_reserve(, gd->bd, (void *)gd->fdt_blob);
lmb_dump_all_force();
+   if (IS_ENABLED(CONFIG_OF_REAL))
+   printf("devicetree  = %s\n", fdtdec_get_srcname());
}
 
arch_print_bdinfo();
diff --git a/common/board_r.c b/common/board_r.c
index 31a59c585a8..99adff14b39 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -586,6 +586,23 @@ int initr_mem(void)
 }
 #endif
 
+static int dm_announce(void)
+{
+   int device_count;
+   int uclass_count;
+
+   if (IS_ENABLED(CONFIG_DM)) {
+   dm_get_stats(_count, _count);
+   printf("Core:  %d devices, %d uclasses", device_count,
+  uclass_count);
+   if (CONFIG_IS_ENABLED(OF_REAL))
+   printf(", devicetree: %s", fdtdec_get_srcname());
+   printf("\n");
+   }
+
+   return 0;
+}
+
 static int run_main_loop(void)
 {
 #ifdef CONFIG_SANDBOX
@@ -661,6 +678,7 @@ static init_fnc_t init_sequence_r[] = {
stdio_init_tables,
serial_initialize,
initr_announce,
+   dm_announce,
 #if CONFIG_IS_ENABLED(WDT)
initr_watchdog,
 #endif
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 0a6e195f8ba..3b2de717592 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -79,6 +79,20 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(ALTERA_SOCFPGA_CLK_INIT, "altr,socfpga-a10-clk-init")
 };
 
+static const char *const fdt_src_name[] = {
+   [FDTSRC_SEPARATE] = "separate",
+   [FDTSRC_PASSAGE] = "passage",
+   [FDTSRC_FIT] = "fit",
+   [FDTSRC_BOARD] = "board",
+   [FDTSRC_EMBED] = "embed",
+   [FDTSRC_ENV] = "env",
+};
+
+const char *fdtdec_get_srcname(void)
+{
+   return fdt_src_name[gd->fdt_src];
+}
+
 const char *fdtdec_get_compatible(enum fdt_compat_id id)
 {
/* We allow reading of the 'unknown' ID for testing purposes */
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 25/31] bloblist: Relicense to allow BSD-3-Clause

2021-10-31 Thread Simon Glass
This implementation is intended to be copied to other projects and
modified, to as to foster a standard means of communcating runtime
information between firmware projects.

The GPL-2 license is too restrictive for some projects, e.g. those
intended as reference implementations rather than designed for
collaborative open-source development.

Update the license to make this easier to share.

Signed-off-by: Simon Glass 
---

 common/bloblist.c  | 2 +-
 include/bloblist.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index 310ca87dbc4..d068adacf7e 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0+
+// SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause
 /*
  * Copyright 2018 Google, Inc
  * Written by Simon Glass 
diff --git a/include/bloblist.h b/include/bloblist.h
index 8303f712087..c0045572275 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+/* SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause */
 /*
  * This provides a standard way of passing information between boot phases
  * (TPL -> SPL -> U-Boot proper.)
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 14/31] arm: qemu: Add an SPL build

2021-10-31 Thread Simon Glass
Add an SPL build for qemu so we can test the standard passage feature.

Include a binman definition so that SPL and U-Boot are in the same image.

For now this just boots to a prompt.

Signed-off-by: Simon Glass 
---

 arch/arm/dts/qemu-arm-u-boot.dtsi| 22 +
 arch/arm/mach-qemu/Kconfig   |  9 
 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 +++
 configs/qemu_arm_spl_defconfig   | 72 
 doc/board/emulation/qemu-arm.rst | 38 +++
 8 files changed, 189 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/dts/qemu-arm-u-boot.dtsi
 create mode 100644 board/emulation/qemu-arm/spl.c
 create mode 100644 configs/qemu_arm_spl_defconfig

diff --git a/arch/arm/dts/qemu-arm-u-boot.dtsi 
b/arch/arm/dts/qemu-arm-u-boot.dtsi
new file mode 100644
index 000..2c5c7df62b4
--- /dev/null
+++ b/arch/arm/dts/qemu-arm-u-boot.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm
+
+ * Copyright 2021 Google LLC
+ */
+
+/ {
+   binman {
+   u-boot-spl {
+   size = <0x1>;
+   };
+
+   u-boot {
+   };
+   };
+
+   pl011@900 {
+   u-boot,dm-spl;
+   };
+
+};
diff --git a/arch/arm/mach-qemu/Kconfig b/arch/arm/mach-qemu/Kconfig
index 186c3582ebf..ab0651ce0b1 100644
--- a/arch/arm/mach-qemu/Kconfig
+++ b/arch/arm/mach-qemu/Kconfig
@@ -20,6 +20,15 @@ config TARGET_QEMU_ARM_32BIT
select CPU_V7A
select SYS_ARCH_TIMER
 
+config TARGET_QEMU_ARM_32BIT_SPL
+   bool "ARMv7-A, 32bit with SPL"
+   select ARCH_SUPPORT_PSCI
+   select BOARD_LATE_INIT
+   select CPU_V7A
+   select SYS_ARCH_TIMER
+   select SPL
+   select BINMAN
+
 config TARGET_QEMU_ARM_64BIT
bool "ARMv8, 64bit"
select ARM64
diff --git a/board/emulation/qemu-arm/Kconfig b/board/emulation/qemu-arm/Kconfig
index 95dbefa78ba..85fbe7a9a35 100644
--- a/board/emulation/qemu-arm/Kconfig
+++ b/board/emulation/qemu-arm/Kconfig
@@ -1,12 +1,10 @@
-if TARGET_QEMU_ARM_32BIT || TARGET_QEMU_ARM_64BIT
-
-config SYS_TEXT_BASE
-   default 0x
+if ARCH_QEMU
 
 config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select CMD_QFW
select QFW_MMIO
+   select SUPPORT_SPL
imply VIRTIO_MMIO
imply VIRTIO_PCI
imply VIRTIO_NET
@@ -14,6 +12,13 @@ config BOARD_SPECIFIC_OPTIONS # dummy
 
 endif
 
+if TARGET_QEMU_ARM_32BIT || TARGET_QEMU_ARM_64BIT
+
+config SYS_TEXT_BASE
+   default 0x
+
+endif
+
 if TARGET_QEMU_ARM_64BIT && !TFABOOT
 config BOARD_SPECIFIC_OPTIONS
imply SYS_MTDPARTS_RUNTIME
@@ -21,3 +26,13 @@ config BOARD_SPECIFIC_OPTIONS
 
 source "board/emulation/common/Kconfig"
 endif
+
+if TARGET_QEMU_ARM_32BIT_SPL
+
+config SPL_TEXT_BASE
+   default 0x
+
+config SYS_TEXT_BASE
+   default 0x0001
+
+endif
diff --git a/board/emulation/qemu-arm/MAINTAINERS 
b/board/emulation/qemu-arm/MAINTAINERS
index e757ffc64f1..b79d4ab85b2 100644
--- a/board/emulation/qemu-arm/MAINTAINERS
+++ b/board/emulation/qemu-arm/MAINTAINERS
@@ -4,4 +4,5 @@ S:  Maintained
 F: board/emulation/qemu-arm/
 F: include/configs/qemu-arm.h
 F: configs/qemu_arm_defconfig
+F: configs/qemu_arm_spl_defconfig
 F: configs/qemu_arm64_defconfig
diff --git a/board/emulation/qemu-arm/Makefile 
b/board/emulation/qemu-arm/Makefile
index a22d1237ff4..54635646e07 100644
--- a/board/emulation/qemu-arm/Makefile
+++ b/board/emulation/qemu-arm/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 obj-y  += qemu-arm.o
+obj-$(CONFIG_SPL_BUILD)+= spl.o
diff --git a/board/emulation/qemu-arm/spl.c b/board/emulation/qemu-arm/spl.c
new file mode 100644
index 000..785177a6c8d
--- /dev/null
+++ b/board/emulation/qemu-arm/spl.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Google LLC
+ * Written by Simon Glass 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+u32 spl_boot_device(void)
+{
+   return BOOT_DEVICE_BOARD;
+}
+
+static int spl_qemu_load_image(struct spl_image_info *spl_image,
+  struct spl_boot_device *bootdev)
+{
+   spl_image->name = "U-Boot";
+   spl_image->load_addr = spl_get_image_pos();
+   spl_image->entry_point = spl_get_image_pos();
+   flush_cache(spl_image->load_addr, spl_get_image_size());
+
+   return 0;
+}
+SPL_LOAD_IMAGE_METHOD("QEMU", 0, BOOT_DEVICE_BOARD, spl_qemu_load_image);
diff --git a/configs/qemu_arm_spl_defconfig b/configs/qemu_arm_spl_defconfig
new file mode 100644
index 000..a6950584542
--- /dev/null
+++ b/configs/qemu_arm_spl_defconfig
@@ -0,0 +1,72 @@
+CONFIG_ARM=y
+CONFIG_SYS_ICACHE_OFF=y
+CONFIG_SYS_DCACHE_OFF=y
+CONFIG_ARM_SMCCC=y
+CONFIG_ARCH_QEMU=y

[PATCH 12/31] bloblist: Use 'phase' consistently for bloblists

2021-10-31 Thread Simon Glass
We typically refer to the different U-Boot builds that a board runs
through as phases. This avoids confusion with the word 'stage' which is
used with bootstage, for example. Fix up some bloblist Kconfig help
which uses the wrong term.

Signed-off-by: Simon Glass 
---

 common/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index 00ccaf59fa4..4cf1831f599 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -700,7 +700,7 @@ config BLOBLIST
  from TPL to SPL to U-Boot proper (and potentially to Linux). The
  blob list supports multiple binary blobs of data, each with a tag,
  so that different U-Boot components can store data which can survive
- through to the next stage of the boot.
+ through to the next phase of the boot.
 
 config SPL_BLOBLIST
bool "Support for a bloblist in SPL"
@@ -729,7 +729,7 @@ config BLOBLIST_SIZE
  Sets the size of the bloblist in bytes. This must include all
  overhead (alignment, bloblist header, record header). The bloblist
  is set up in the first part of U-Boot to run (TPL, SPL or U-Boot
- proper), and this sane bloblist is used for subsequent stages.
+ proper), and this sane bloblist is used for subsequent phases.
 
 config BLOBLIST_ALLOC
bool "Allocate bloblist"
@@ -743,7 +743,7 @@ config BLOBLIST_ADDR
default 0xc000 if SANDBOX
help
  Sets the address of the bloblist, set up by the first part of U-Boot
- which runs. Subsequent U-Boot stages typically use the same address.
+ which runs. Subsequent U-Boot phases typically use the same address.
 
  This is not used if BLOBLIST_ALLOC is selected.
 
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 30/31] passage: Add checks for pre-existing blobs

2021-10-31 Thread Simon Glass
Add checks / documentation for blobs which are already in the list. This
brings U-Boot up to the standard required by the standard-passage
documentation.

Signed-off-by: Simon Glass 
---

 board/sandbox/stdpass_check.c   |  71 -
 include/stdpass/tpm2_eventlog.h |  42 +
 include/stdpass/vboot_ctx.h | 267 
 3 files changed, 379 insertions(+), 1 deletion(-)
 create mode 100644 include/stdpass/tpm2_eventlog.h
 create mode 100644 include/stdpass/vboot_ctx.h

diff --git a/board/sandbox/stdpass_check.c b/board/sandbox/stdpass_check.c
index 9c015b6783e..1db9ad357ee 100644
--- a/board/sandbox/stdpass_check.c
+++ b/board/sandbox/stdpass_check.c
@@ -29,10 +29,79 @@ void check_struct_name(void)
/* __maybe_unused struct struct_name check; */
 }
 
+/* BLOBLISTT_CONTROL_DTB */
+void check_control_dtb(void)
+{
+   /*
+* Defined by devicetree specification
+* 
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3
+*/
+};
+
+/* BLOBLISTT_ACPI_GNVS */
+#include 
+void check_acpi_gnvs(void)
+{
+   __maybe_unused struct acpi_global_nvs check;
+}
+
+/* BLOBLISTT_INTEL_VBT */
+void check_intel_vbt(void)
+{
+   /*
+* Pre-existing Intel blob, defined by source code
+*
+* 
https://github.com/freedesktop/xorg-intel-gpu-tools/blob/master/tools/intel_vbt_defs.h
+* 
https://github.com/freedesktop/xorg-intel-gpu-tools/blob/master/tools/intel_vbt_decode.c
+*/
+}
+
+/* BLOBLISTT_TPM2_TCG_LOG */
+#include 
+void check_tpm2_tcg_log(void)
+{
+   /* Struct for each record */
+   __maybe_unused struct tpm2_eventlog_context check;
+}
+
+/* BLOBLISTT_TCPA_LOG */
+#include 
+void check_tcpa_log(void)
+{
+   __maybe_unused struct acpi_tcpa check;
+};
+
+/* BLOBLISTT_ACPI_TABLES */
+void check_acpi_tables(void)
+{
+   /*
+* Defined by UEFI Advanced Configuration and Power Interface (ACPI)
+* Specification, Version 6.3, January 2019
+* 
https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
+*/
+}
+
+/* BLOBLISTT_SMBIOS_TABLES */
+void check_smbios_tables(void)
+{
+   /*
+* Defined by System Management BIOS (SMBIOS) Reference Specification
+* v3.5.0
+* https://www.dmtf.org/standards/smbios
+*/
+}
+
+/* BLOBLISTT_VBOOT_CTX */
+#include 
+void check_vboot_ctx(void)
+{
+   __maybe_unused struct vb2_shared_data check;
+
+}
+
 /* BLOBLISTT_U_BOOT_SPL_HANDOFF */
 #include 
 void check_spl_handoff(void)
 {
__maybe_unused struct spl_handoff check;
 };
-
diff --git a/include/stdpass/tpm2_eventlog.h b/include/stdpass/tpm2_eventlog.h
new file mode 100644
index 000..6b258609149
--- /dev/null
+++ b/include/stdpass/tpm2_eventlog.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+
+/* taken from 
https://github.com/tpm2-software/tpm2-tss/blob/master/include/tss2/tss2_tpm2_types.h
 */
+#define TPM2_MAX_PCRS   32
+
+/* Hash algorithm sizes */
+#define TPM2_SHA_DIGEST_SIZE 20
+#define TPM2_SHA1_DIGEST_SIZE20
+#define TPM2_SHA256_DIGEST_SIZE  32
+#define TPM2_SHA384_DIGEST_SIZE  48
+#define TPM2_SHA512_DIGEST_SIZE  64
+#define TPM2_SM3_256_DIGEST_SIZE 32
+
+/* taken from 
https://github.com/tpm2-software/tpm2-tools/blob/master/lib/tpm2_eventlog.h#L14 
*/
+
+typedef bool (*digest2_callback)(void const *digest, size_t size, void *data);
+typedef bool (*event2_callback)(void const *event_hdr, size_t size, void 
*data);
+typedef bool (*event2data_callback)(void const *event, u32 type, void *data,
+   u32 eventlog_version);
+typedef bool (*specid_callback)(void const *event, void *data);
+typedef bool (*log_event_callback)(void const *event_hdr, size_t size,
+  void *data);
+
+struct tpm2_eventlog_context {
+   void *data;
+   specid_callback specid_cb;
+   log_event_callback log_eventhdr_cb;
+   event2_callback event2hdr_cb;
+   digest2_callback digest2_cb;
+   event2data_callback event2_cb;
+   u32 sha1_used;
+   u32 sha256_used;
+   u32 sha384_used;
+   u32 sha512_used;
+   u32 sm3_256_used;
+   u8 sha1_pcrs[TPM2_MAX_PCRS][TPM2_SHA1_DIGEST_SIZE];
+   u8 sha256_pcrs[TPM2_MAX_PCRS][TPM2_SHA256_DIGEST_SIZE];
+   u8 sha384_pcrs[TPM2_MAX_PCRS][TPM2_SHA384_DIGEST_SIZE];
+   u8 sha512_pcrs[TPM2_MAX_PCRS][TPM2_SHA512_DIGEST_SIZE];
+   u8 sm3_256_pcrs[TPM2_MAX_PCRS][TPM2_SM3_256_DIGEST_SIZE];
+   u32 eventlog_version;
+};
diff --git a/include/stdpass/vboot_ctx.h b/include/stdpass/vboot_ctx.h
new file mode 100644
index 000..ff74e8ba709
--- /dev/null
+++ b/include/stdpass/vboot_ctx.h
@@ -0,0 +1,267 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+
+/*
+ * Taken from https://chromium.googlesource.com/chromiumos/platform/vboot
+ *
+ * Copyright (c) 2014 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a 

[PATCH 27/31] passage: Add documentation

2021-10-31 Thread Simon Glass
Add documentation about standard passage and update the maintainers.

Signed-off-by: Simon Glass 
---

 MAINTAINERS   |  10 ++
 board/sandbox/stdpass_check.c |  10 +-
 doc/develop/bloblist.rst  |   4 +-
 doc/develop/index.rst |   1 +
 doc/develop/std_passage.rst   | 319 ++
 5 files changed, 334 insertions(+), 10 deletions(-)
 create mode 100644 doc/develop/std_passage.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 5069f188065..4981e4d67a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1124,6 +1124,16 @@ F:   common/stackprot.c
 F: cmd/stackprot_test.c
 F: test/py/tests/test_stackprotector.py
 
+STANDARD PASSAGE
+M: Simon Glass 
+F: board/sandbox/stdpass_check.c
+F: cmd/bloblist.c
+F: common/bloblist.c
+F: doc/develop/std_passage.rst
+F: include/bloblist.h
+F: include/stdpass/
+F: test/bloblist.c
+
 TARGET_BCMNS3
 M: Bharat Gooty 
 M: Rayagonda Kokatanur 
diff --git a/board/sandbox/stdpass_check.c b/board/sandbox/stdpass_check.c
index 565124e1564..8391c7a4aed 100644
--- a/board/sandbox/stdpass_check.c
+++ b/board/sandbox/stdpass_check.c
@@ -8,13 +8,6 @@
 
 #include 
 
-/* BLOBLISTT_U_BOOT_SPL_HANDOFF */
-#include 
-void check_spl_handoff(void)
-{
-   __maybe_unused struct spl_handoff check;
-};
-
 /*
  * See also doc/develop/std_passage.rst
  *
@@ -23,7 +16,8 @@ void check_spl_handoff(void)
  * 1. Add your header file to U-Boot, or to include/stdpass if it is not used 
in
  * U-Boot
  *
- * 2. Add a function below to include the header and use the struct
+ * 2. Add a function below to include the header and use the struct. Please put
+ * your function in order of tag ID (see bloblist.h)
  *
  * Template follows, see above for example
  */
diff --git a/doc/develop/bloblist.rst b/doc/develop/bloblist.rst
index 572aa65d764..e819c6dc76b 100644
--- a/doc/develop/bloblist.rst
+++ b/doc/develop/bloblist.rst
@@ -1,7 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0+
 
-Blob Lists - bloblist
-=
+Bloblist
+
 
 Introduction
 
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 5e064a4dac1..6b79045a1a8 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -19,6 +19,7 @@ Implementation
logging
makefiles
menus
+   std_passage
uefi/index
version
 
diff --git a/doc/develop/std_passage.rst b/doc/develop/std_passage.rst
new file mode 100644
index 000..9c938636972
--- /dev/null
+++ b/doc/develop/std_passage.rst
@@ -0,0 +1,319 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Standard Passage
+
+
+Introduction
+
+
+It is sometimes necessary for SPL to communicate information to U-Boot proper,
+such as the RAM size. This can sometimes be handled by adding the value to a
+Kconfig which both SPL and U-Boot proper can use. But this does not work for
+values which are detected at runtime.
+
+In some cases other firmware binaries are used alongside U-Boot and these may
+need to pass information to U-Boot or receive information from it. In this case
+there is no shared build system and it is clumsy so have to specify matching
+build options across projects.
+
+U-Boot provides a standard way of passing information between different phases
+(TPL, SPL, U-Boot). This is called `standard passage` since it creates a
+standard passage through which any sort of information can flow.
+
+
+How it works
+
+
+The standard passage is very simple. It is really just a way of sending a
+bloblist between programs, either at a fixed address, or using registers to
+indicate the location.
+
+A :doc:`bloblist` is a simple, contiguous data structure containing a number of
+blobs. Each blob has a tag to indicate what it contains. It is designed for
+simple information, like a small C struct. For more complex data, a devicetree
+is preferred since it has bindings and is extensible.
+
+The bloblist is typically set up initially by one of the early phases of 
U-Boot,
+such as TPL. It starts either at a fixed address or is allocated in memory 
using
+malloc(). After that, TPL passes the location of the bloblist to SPL (using
+machine register in an architecture-specific way) and SPL passes it to U-Boot
+proper. It is possible to add new blobs to the bloblist at each phase. U-Boot
+proper relocates the bloblist so can expand it if desired.
+
+
+Use by other projects
+-
+
+The standard passage is also intended to be used by other firmware projects,
+particularly if they interface with U-Boot. It allows that project's firmware
+binaries to pass information to U-Boot (if they run before U-Boot) or receive
+information from U-Boot (if they run afterwards).
+
+These projects can copy and modify the bloblist code provided they have a
+compatible license.
+
+
+Allocating tags
+---
+
+Tags are defined in the `bloblist.h` header file. For the moment, the U-Boot
+tree is the upstream repository for 

[PATCH 29/31] x86: Move Intel GNVS file into the common include directory

2021-10-31 Thread Simon Glass
Move this so we can include it from sandbox, needed since it is in a
bloblist and must have a check.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/apollolake/acpi.c| 2 +-
 arch/x86/cpu/intel_common/acpi.c  | 2 +-
 arch/x86/include/asm/arch-apollolake/global_nvs.h | 2 +-
 board/google/chromebook_coral/coral.c | 2 +-
 {arch/x86/include/asm => include}/intel_gnvs.h| 0
 5 files changed, 4 insertions(+), 4 deletions(-)
 rename {arch/x86/include/asm => include}/intel_gnvs.h (100%)

diff --git a/arch/x86/cpu/apollolake/acpi.c b/arch/x86/cpu/apollolake/acpi.c
index fd21c0b4968..2822b8d06d1 100644
--- a/arch/x86/cpu/apollolake/acpi.c
+++ b/arch/x86/cpu/apollolake/acpi.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -21,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/cpu/intel_common/acpi.c b/arch/x86/cpu/intel_common/acpi.c
index 15f19da2067..4a288e85252 100644
--- a/arch/x86/cpu/intel_common/acpi.c
+++ b/arch/x86/cpu/intel_common/acpi.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/include/asm/arch-apollolake/global_nvs.h 
b/arch/x86/include/asm/arch-apollolake/global_nvs.h
index ef8eb228dbe..639d8f2de78 100644
--- a/arch/x86/include/asm/arch-apollolake/global_nvs.h
+++ b/arch/x86/include/asm/arch-apollolake/global_nvs.h
@@ -10,6 +10,6 @@
 #ifndef _GLOBAL_NVS_H_
 #define _GLOBAL_NVS_H_
 
-#include 
+#include 
 
 #endif /* _GLOBAL_NVS_H_ */
diff --git a/board/google/chromebook_coral/coral.c 
b/board/google/chromebook_coral/coral.c
index 53c5171d02b..ca63cf4ef51 100644
--- a/board/google/chromebook_coral/coral.c
+++ b/board/google/chromebook_coral/coral.c
@@ -11,13 +11,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/include/asm/intel_gnvs.h b/include/intel_gnvs.h
similarity index 100%
rename from arch/x86/include/asm/intel_gnvs.h
rename to include/intel_gnvs.h
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 28/31] passage: Add docs for spl_handoff

2021-10-31 Thread Simon Glass
This tag already exists in U-Boot. Add documentation, following the
format set out.

Signed-off-by: Simon Glass 
---

 board/sandbox/stdpass_check.c | 8 
 include/handoff.h | 8 +---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/board/sandbox/stdpass_check.c b/board/sandbox/stdpass_check.c
index 8391c7a4aed..9c015b6783e 100644
--- a/board/sandbox/stdpass_check.c
+++ b/board/sandbox/stdpass_check.c
@@ -28,3 +28,11 @@ void check_struct_name(void)
 {
/* __maybe_unused struct struct_name check; */
 }
+
+/* BLOBLISTT_U_BOOT_SPL_HANDOFF */
+#include 
+void check_spl_handoff(void)
+{
+   __maybe_unused struct spl_handoff check;
+};
+
diff --git a/include/handoff.h b/include/handoff.h
index 070a79c1b97..30203033ec9 100644
--- a/include/handoff.h
+++ b/include/handoff.h
@@ -9,16 +9,20 @@
 #define __HANDOFF_H
 
 #if CONFIG_IS_ENABLED(HANDOFF)
-
 #include 
+#endif
 
 /**
  * struct spl_handoff - information passed from SPL to U-Boot proper
  *
+ * bloblist_tag: BLOBLISTT_U_BOOT_SPL_HANDOFF
+ *
  * @ram_size: Value to use for gd->ram_size
  */
 struct spl_handoff {
+#if CONFIG_IS_ENABLED(HANDOFF)
struct arch_spl_handoff arch;
+#endif
u64 ram_size;
struct {
u64 start;
@@ -43,5 +47,3 @@ void handoff_load_dram_banks(struct spl_handoff *ho);
 int handoff_arch_save(struct spl_handoff *ho);
 
 #endif
-
-#endif
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 24/31] bloblist: doc: Bring in the API documentation

2021-10-31 Thread Simon Glass
FIx up various minor errors and add the API documentation to the bloblist
docs, since it is quite useful to see it in the same place.

Signed-off-by: Simon Glass 
---

 doc/develop/bloblist.rst |  8 +++-
 include/bloblist.h   | 88 
 2 files changed, 52 insertions(+), 44 deletions(-)

diff --git a/doc/develop/bloblist.rst b/doc/develop/bloblist.rst
index 47274cf8e26..572aa65d764 100644
--- a/doc/develop/bloblist.rst
+++ b/doc/develop/bloblist.rst
@@ -31,7 +31,7 @@ Blobs
 While each blob in the bloblist can be of any length, bloblists are designed to
 hold small amounts of data, typically a few KB at most. It is not possible to
 change the length of a blob once it has been written. Each blob is normally
-created from a C structure which can beused to access its fields.
+created from a C structure which can be used to access its fields.
 
 
 Blob tags
@@ -93,6 +93,12 @@ This should move to using bloblist, to avoid having its own 
mechanism for
 passing information between U-Boot parts.
 
 
+API documentation
+-
+
+.. kernel-doc:: include/bloblist.h
+
+
 Simon Glass
 s...@chromium.org
 12-Aug-2018
diff --git a/include/bloblist.h b/include/bloblist.h
index 607e42129d4..8303f712087 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -87,8 +87,8 @@ enum bloblist_tag_t {
  * same place in memory as SPL and U-Boot execute, but it can be safely moved
  * around.
  *
- * None of the bloblist structures contain pointers but it is possible to put
- * pointers inside a bloblist record if desired. This is not encouraged,
+ * None of the bloblist headers themselves contain pointers but it is possible
+ * to put pointers inside a bloblist record if desired. This is not encouraged,
  * since it can make part of the bloblist inaccessible if the pointer is
  * no-longer valid. It is better to just store all the data inside a bloblist
  * record.
@@ -100,7 +100,7 @@ enum bloblist_tag_t {
  * @version: BLOBLIST_VERSION
  * @hdr_size: Size of this header, normally sizeof(struct bloblist_hdr). The
  * first bloblist_rec starts at this offset from the start of the header
- * @flags: Space for BLOBLISTF_... flags (none yet)
+ * @flags: Space for BLOBLISTF... flags (none yet)
  * @size: Total size of the bloblist (non-zero if valid) including this header.
  * The bloblist extends for this many bytes from the start of this header.
  * When adding new records, the bloblist can grow up to this size.
@@ -111,8 +111,8 @@ enum bloblist_tag_t {
  * @chksum: CRC32 for the entire bloblist allocated area. Since any of the
  * blobs can be altered after being created, this checksum is only valid
  * when the bloblist is finalised before jumping to the next stage of boot.
- * Note: @chksum is last to make it easier to exclude it from the checksum
- * calculation.
+ * Note that chksum is last to make it easier to exclude it from the
+ * checksum calculation.
  */
 struct bloblist_hdr {
u32 magic;
@@ -129,11 +129,11 @@ struct bloblist_hdr {
 /**
  * struct bloblist_rec - record for the bloblist
  *
- * NOTE: Only exported for testing purposes. Do not use this struct.
- *
  * The bloblist contains a number of records each consisting of this record
  * structure followed by the data contained. Each records is 16-byte aligned.
  *
+ * NOTE: Only exported for testing purposes. Do not use this struct.
+ *
  * @tag: Tag indicating what the record contains
  * @hdr_size: Size of this header, normally sizeof(struct bloblist_rec). The
  * record's data starts at this offset from the start of the record
@@ -152,7 +152,7 @@ struct bloblist_rec {
  * bloblist_check_magic() - return a bloblist if the magic matches
  *
  * @addr: Address to check
- * @return pointer to bloblist, if the magic matches, else NULL
+ * Return: pointer to bloblist, if the magic matches, else NULL
  */
 static inline void *bloblist_check_magic(ulong addr)
 {
@@ -174,8 +174,8 @@ static inline void *bloblist_check_magic(ulong addr)
  *
  * @tag:   Tag to search for (enum bloblist_tag_t)
  * @size:  Expected size of the blob, or 0 for any size
- * @return pointer to blob if found, or NULL if not found, or a blob was found
- * but it is the wrong size
+ * Return: pointer to blob if found, or NULL if not found, or a blob was found
+ * but it is the wrong size
  */
 void *bloblist_find(uint tag, int size);
 
@@ -191,8 +191,8 @@ void *bloblist_find(uint tag, int size);
  * @tag:   Tag to add (enum bloblist_tag_t)
  * @size:  Size of the blob
  * @align: Alignment of the blob (in bytes), 0 for default
- * @return pointer to the newly added block, or NULL if there is not enough
- * space for the blob
+ * Return: pointer to the newly added block, or NULL if there is not enough
+ * space for the blob
  */
 void *bloblist_add(uint tag, int size, int align);
 
@@ -205,8 +205,8 @@ void *bloblist_add(uint tag, int size, int align);
  * @size:  Size of 

[PATCH 31/31] WIP: RFC: Add a gitlab test

2021-10-31 Thread Simon Glass
This needs fixing up once the new hooks land as well as adding an
azure rule.

Signed-off-by: Simon Glass 
---

 .gitlab-ci.yml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index e7c65ebbcef..33466ec2a8a 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -240,6 +240,12 @@ qemu_arm64 test.py:
 TEST_PY_TEST_SPEC: "not sleep"
   <<: *buildman_and_testpy_dfn
 
+#qemu_arm spl_test.py:
+#  variables:
+#TEST_PY_BD: "qemu_arm_spl"
+#TEST_PY_TEST_SPEC: "not sleep"
+#  <<: *buildman_and_testpy_dfn
+
 qemu_malta test.py:
   variables:
 TEST_PY_BD: "malta"
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 21/31] passage: Record where the devicetree came from

2021-10-31 Thread Simon Glass
Keep track of where the devicetree came from, so we can report this later.

Signed-off-by: Simon Glass 
---

 include/asm-generic/global_data.h |  4 
 include/fdtdec.h  | 36 +++
 lib/fdtdec.c  | 21 +-
 3 files changed, 56 insertions(+), 5 deletions(-)

diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index 6aba74dac10..d998581e179 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -265,6 +265,10 @@ struct global_data {
 * @fdt_size: space reserved for relocated device space
 */
unsigned long fdt_size;
+   /**
+* @fdt_src: Source of FDT
+*/
+   enum fdt_source_t fdt_src;
 #if CONFIG_IS_ENABLED(OF_LIVE)
/**
 * @of_root: root node of the live tree
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 24992baed8b..b4e452326b3 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -49,6 +49,35 @@ struct fdt_memory {
 
 struct bd_info;
 
+/**
+ * enum fdt_source_t - indicates where the devicetree came from
+ *
+ * These are listed in approximate order of desirability after FDTSRC_NONE
+ *
+ * @FDTSRC_SEPARATE: Appended to U-Boot. This is the normal approach if U-Boot
+ * is the only firmware being booted
+ * @FDTSRC_PASSAGE: From the standard passage (passed in from previous
+ * phase/stage). This is the normal approach if prior-stage firmware is
+ * used, such as TF-A
+ * @FDTSRC_FIT: Found in a multi-dtb FIT. This should be used when U-Boot must
+ * select a devicetree from many options
+ * @FDTSRC_BOARD: Located by custom board code. This should only be used when
+ * the prior stage does not support FDTSRC_PASSAGE
+ * @FDTSRC_EMBED: Embedded into U-Boot executable. This should onyl be used 
when
+ * U-Boot is packaged as an ELF file, e.g. for debugging purposes
+ * @FDTSRC_ENV: Provided by the fdtcontroladdr environment variable. This 
should
+ * be used for debugging/development only
+ * @FDTSRC_NONE: No devicetree at all
+ */
+enum fdt_source_t {
+   FDTSRC_SEPARATE,
+   FDTSRC_PASSAGE,
+   FDTSRC_FIT,
+   FDTSRC_BOARD,
+   FDTSRC_EMBED,
+   FDTSRC_ENV,
+};
+
 /*
  * Information about a resource. start is the first address of the resource
  * and end is the last address (inclusive). The length of the resource will
@@ -1209,4 +1238,11 @@ int fdtdec_decode_ram_size(const void *blob, const char 
*area, int board_id,
   phys_addr_t *basep, phys_size_t *sizep,
   struct bd_info *bd);
 
+/**
+ * fdtdec_get_srcname() - Get the name of where the devicetree comes from
+ *
+ * @return source name
+ */
+const char *fdtdec_get_srcname(void);
+
 #endif
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 4ca56e06b2f..0a6e195f8ba 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1621,6 +1621,7 @@ static void setup_multi_dtb_fit(void)
if (blob) {
gd_set_multi_dtb_fit(gd->fdt_blob);
gd->fdt_blob = blob;
+   gd->fdt_src = FDTSRC_FIT;
}
 }
 
@@ -1629,10 +1630,13 @@ int fdtdec_setup(void)
int ret;
 
/* The devicetree is typically appended to U-Boot */
-   if (IS_ENABLED(CONFIG_OF_SEPARATE))
+   if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
gd->fdt_blob = fdt_find_separate();
-   else /* embed dtb in ELF file for testing / development */
+   gd->fdt_src = FDTSRC_SEPARATE;
+   } else { /* embed dtb in ELF file for testing / development */
gd->fdt_blob = dtb_dt_embedded();
+   gd->fdt_src = FDTSRC_EMBED;
+   }
 
/* Passed in via the standard passage */
if (IS_ENABLED(CONFIG_OF_PASSAGE) && gd->passage_dtb_off) {
@@ -1657,6 +1661,7 @@ int fdtdec_setup(void)
}
if (fdt) {
gd->fdt_blob = fdt;
+   gd->fdt_src = FDTSRC_PASSAGE;
log_debug("passage: Found control dtb at %p\n", fdt);
}
}
@@ -1666,12 +1671,18 @@ int fdtdec_setup(void)
gd->fdt_blob = board_fdt_blob_setup();
if (ret)
return ret;
+   gd->fdt_src = FDTSRC_BOARD;
}
 
+   /* Allow the early environment to override the fdt address */
if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
-   /* Allow the early environment to override the fdt address */
-   gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16,
-  (unsigned long)map_to_sysmem(gd->fdt_blob)), 0);
+   ulong addr;
+
+   addr = env_get_hex("fdtcontroladdr", 0);
+   if (addr) {
+   gd->fdt_blob = map_sysmem(addr, 0);
+   gd->fdt_src = FDTSRC_ENV;
+   }
}
 
if (CONFIG_IS_ENABLED(MULTI_DTB_FIT))
-- 

[PATCH 26/31] sandbox: Add a way of checking structs for standard passage

2021-10-31 Thread Simon Glass
Add a file which can be used to check that structs used in standard
passage do compile. No other validation is done at present, but could be
considered later.

Signed-off-by: Simon Glass 
---

 board/sandbox/Makefile|  3 ++-
 board/sandbox/stdpass_check.c | 36 +++
 include/stdpass/README|  4 
 3 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 board/sandbox/stdpass_check.c
 create mode 100644 include/stdpass/README

diff --git a/board/sandbox/Makefile b/board/sandbox/Makefile
index 411b53c2b8d..d9b56adbbb8 100644
--- a/board/sandbox/Makefile
+++ b/board/sandbox/Makefile
@@ -2,4 +2,5 @@
 #
 # Copyright (c) 2011 The Chromium OS Authors.
 
-obj-y  := sandbox.o
+obj-y  += sandbox.o
+obj-y  += stdpass_check.o
diff --git a/board/sandbox/stdpass_check.c b/board/sandbox/stdpass_check.c
new file mode 100644
index 000..565124e1564
--- /dev/null
+++ b/board/sandbox/stdpass_check.c
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * This file compiles all the struct definitions for standard passage, to 
ensure
+ * there are no errors
+ *
+ * Copyright 2021 Google LLC
+ */
+
+#include 
+
+/* BLOBLISTT_U_BOOT_SPL_HANDOFF */
+#include 
+void check_spl_handoff(void)
+{
+   __maybe_unused struct spl_handoff check;
+};
+
+/*
+ * See also doc/develop/std_passage.rst
+ *
+ * Instructions:
+ *
+ * 1. Add your header file to U-Boot, or to include/stdpass if it is not used 
in
+ * U-Boot
+ *
+ * 2. Add a function below to include the header and use the struct
+ *
+ * Template follows, see above for example
+ */
+
+/* BLOBLISTT_tag here */
+/* #include  if not used in U-Boot*/
+void check_struct_name(void)
+{
+   /* __maybe_unused struct struct_name check; */
+}
diff --git a/include/stdpass/README b/include/stdpass/README
new file mode 100644
index 000..a972121f40c
--- /dev/null
+++ b/include/stdpass/README
@@ -0,0 +1,4 @@
+This directory contains standard passage structures
+
+See doc/develop/std_passage.rst for instructions
+
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 23/31] passage: Add a qemu test for ARM

2021-10-31 Thread Simon Glass
Check that the standard passage works on ARM, by setting it up in SPL
and making sure that it comes through correctly in U-Boot proper.

Signed-off-by: Simon Glass 
---

 configs/qemu_arm_spl_defconfig |  8 +++-
 test/py/tests/test_passage.py  | 11 +++
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 test/py/tests/test_passage.py

diff --git a/configs/qemu_arm_spl_defconfig b/configs/qemu_arm_spl_defconfig
index a6950584542..6ca47ef4200 100644
--- a/configs/qemu_arm_spl_defconfig
+++ b/configs/qemu_arm_spl_defconfig
@@ -12,6 +12,7 @@ CONFIG_SYS_MALLOC_LEN=0x100
 CONFIG_DEFAULT_DEVICE_TREE="qemu-arm"
 CONFIG_TARGET_QEMU_ARM_32BIT_SPL=y
 CONFIG_SPL_SERIAL=y
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x6000
 CONFIG_DEBUG_UART_BASE=0x900
 CONFIG_DEBUG_UART_CLOCK=0
 CONFIG_ARMV7_LPAE=y
@@ -28,6 +29,11 @@ CONFIG_USE_PREBOOT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_PCI_INIT_R=y
+CONFIG_BLOBLIST=y
+CONFIG_BLOBLIST_PASSAGE=y
+CONFIG_SPL_BLOBLIST_ALLOC=y
+CONFIG_SPL_BLOBLIST_SIZE=0x4000
+CONFIG_PASSAGE_IN=y
 CONFIG_SPL_FRAMEWORK_BOARD_INIT_F=y
 CONFIG_CMD_BOOTEFI_SELFTEST=y
 CONFIG_CMD_NVEDIT_EFI=y
@@ -37,7 +43,7 @@ CONFIG_CMD_PCI=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_SPL_OF_CONTROL=y
-CONFIG_OF_BOARD=y
+CONFIG_OF_PASSAGE=y
 CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_ENV_ADDR=0x400
 CONFIG_SPL_DM=y
diff --git a/test/py/tests/test_passage.py b/test/py/tests/test_passage.py
new file mode 100644
index 000..594dc3cc685
--- /dev/null
+++ b/test/py/tests/test_passage.py
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright 2021 Google LLC
+
+import pytest
+
+@pytest.mark.buildconfigspec('target_qemu_arm_32bit_spl')
+def test_passage(u_boot_console):
+"""Test that the standard passage on ARM from SPL to U-Boot works."""
+
+response = u_boot_console.run_command('bdinfo')
+assert 'devicetree  = passage' in response
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 20/31] passage: spl: Support passing the passage to U-Boot

2021-10-31 Thread Simon Glass
Update the jump routine to support passing three parameters instead of
one. The two new parameters are the bloblist address and the offset from
there to the devicetree.

Add an accessor for gd->bloblist to avoid needing #ifdefs in the C code.

Note that this renames jump_to_image_no_args() to jump_to_image(), so will
not work on boards which have overridden that weak function. This can be
tided up by maintainers as they enable the standard passage. Fix up a
few that definitely need a tweak.

Signed-off-by: Simon Glass 
---

 arch/sandbox/cpu/spl.c|  2 +-
 arch/x86/lib/spl.c|  2 +-
 arch/x86/lib/tpl.c|  2 +-
 common/spl/spl.c  | 30 +-
 include/asm-generic/global_data.h |  6 ++
 include/spl.h | 13 +
 6 files changed, 47 insertions(+), 8 deletions(-)

diff --git a/arch/sandbox/cpu/spl.c b/arch/sandbox/cpu/spl.c
index 650bdb0a701..7047613517b 100644
--- a/arch/sandbox/cpu/spl.c
+++ b/arch/sandbox/cpu/spl.c
@@ -87,7 +87,7 @@ void spl_board_init(void)
}
 }
 
-void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
+void __noreturn jump_to_image(struct spl_image_info *spl_image)
 {
const char *fname = spl_image->arg;
 
diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
index b18c1cd6092..c51514bfeb8 100644
--- a/arch/x86/lib/spl.c
+++ b/arch/x86/lib/spl.c
@@ -238,7 +238,7 @@ int spl_spi_load_image(void)
 }
 
 #ifdef CONFIG_X86_RUN_64BIT
-void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
+void __noreturn jump_to_image(struct spl_image_info *spl_image)
 {
int ret;
 
diff --git a/arch/x86/lib/tpl.c b/arch/x86/lib/tpl.c
index 5b57e53c2dd..b334f70e83e 100644
--- a/arch/x86/lib/tpl.c
+++ b/arch/x86/lib/tpl.c
@@ -110,7 +110,7 @@ int spl_spi_load_image(void)
return -EPERM;
 }
 
-void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
+void __noreturn jump_to_image(struct spl_image_info *spl_image)
 {
debug("Jumping to %s at %lx\n", spl_phase_name(spl_next_phase()),
  (ulong)spl_image->entry_point);
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 7a9df9aaece..a226c2a2488 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -394,13 +394,33 @@ int spl_parse_image_header(struct spl_image_info 
*spl_image,
 
 __weak void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
 {
-   typedef void __noreturn (*image_entry_noargs_t)(void);
+   jump_to_image(spl_image);
+}
+
+__weak void __noreturn jump_to_image(struct spl_image_info *spl_image)
+{
+   typedef void __noreturn (*image_entry_t)(ulong bloblist,
+ulong dtb_offset);
+   ulong bloblist = 0;
+   ulong dtb_offset = 0;
 
-   image_entry_noargs_t image_entry =
-   (image_entry_noargs_t)spl_image->entry_point;
+   image_entry_t image_entry = (image_entry_t)spl_image->entry_point;
 
debug("image entry point: 0x%lx\n", spl_image->entry_point);
-   image_entry();
+
+   if (CONFIG_IS_ENABLED(PASSAGE_OUT)) {
+   const void *fdt;
+
+   bloblist = bloblist_get_base();
+   fdt = bloblist_find(BLOBLISTT_CONTROL_DTB, 0);
+   if (fdt)
+   dtb_offset = (ulong)fdt - (ulong)gd_bloblist();
+
+   log_debug("passage: sending bloblist at %lx, dtb offset %lx\n",
+ bloblist, dtb_offset);
+   }
+
+   image_entry(bloblist, dtb_offset);
 }
 
 #if CONFIG_IS_ENABLED(HANDOFF)
@@ -862,7 +882,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 #endif
 
spl_board_prepare_for_boot();
-   jump_to_image_no_args(_image);
+   jump_to_image(_image);
 }
 
 /*
diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index 717fe2edb46..6aba74dac10 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -541,6 +541,12 @@ static_assert(sizeof(struct global_data) == GD_SIZE);
 #define gd_set_multi_dtb_fit(_dtb)
 #endif
 
+#if CONFIG_IS_ENABLED(BLOBLIST)
+#define gd_bloblist()  gd->bloblist
+#else
+#define gd_bloblist()  NULL
+#endif
+
 /**
  * enum gd_flags - global data flags
  *
diff --git a/include/spl.h b/include/spl.h
index 7da8f7f92ab..3292ddeb512 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -581,6 +581,19 @@ int spl_load_image_fat(struct spl_image_info *spl_image,
 int spl_load_image_fat_os(struct spl_image_info *spl_image,
  struct blk_desc *block_dev, int partition);
 
+/**
+ * jump_to_image() - Jump to image, using standard passage if enabled
+ *
+ * This sets the machine registers correctly if standard passage is enabled for
+ * output. This allows the target image to read the info using the standard
+ * passage protocol
+ *
+ * This is a weak function, so may be overriddden
+ *
+ * @spl_image: Image to jump to
+ */
+void 

[PATCH 16/31] passage: Support an incoming passage

2021-10-31 Thread Simon Glass
Plumb in the ability for U-Boot proper to accept an incoming standard
passage from a previous phase, such as SPL or TF-A. This allows data to
be passed from binary to binary when firmware is booting.

Signed-off-by: Simon Glass 
---

 common/Kconfig| 31 ++
 common/bloblist.c |  4 
 common/board_f.c  | 32 ---
 include/asm-generic/global_data.h | 21 
 include/bloblist.h|  9 +
 lib/asm-offsets.c |  5 +
 6 files changed, 87 insertions(+), 15 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index 2c6f5901c8a..fa7915d2acc 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -740,6 +740,14 @@ config BLOBLIST_ALLOC
  specify a fixed address on systems where this is unknown or can
  change at runtime.
 
+config BLOBLIST_PASSAGE
+   bool "Obtain bloblist from standard passage information"
+   help
+ Rather than allocating the bloblist, get it from the standard
+ passage provided by an earlier phase, e.g. SPL. The bloblist address
+ and size are used as is, except that the bloblist is of course
+ relocated when U-Boot relocates.
+
 endchoice
 
 config BLOBLIST_ADDR
@@ -798,6 +806,13 @@ config SPL_BLOBLIST_ALLOC
  specify a fixed address on systems where this is unknown or can
  change at runtime.
 
+config SPL_BLOBLIST_PASSAGE
+   bool "Obtain bloblist from standard passage information"
+   help
+ Rather than allocating the bloblist, get it from the standard
+ passage provided by an earlier phase, e.g. TPL. The bloblist address
+ and size are used as is within SPL, then passed on to U-Boot.
+
 endchoice
 
 endif # SPL_BLOBLIST
@@ -833,6 +848,22 @@ endif # TPL_BLOBLIST
 
 endmenu
 
+config PASSAGE_IN
+   bool "Support the standard-passage protocol (in)"
+   help
+ This enables a standard protocol for entering U-Boot, providing
+ parameters in a bloblist with a devicetree. It allows the various
+ firmware phases to communicate state and settings to following
+ phases.
+
+config SPL_PASSAGE_IN
+   bool "Support the standard-passage protocol in SPL (in)"
+   help
+ This enables a standard protocol for entering SPL, providing
+ parameters in a bloblist and a devicetree. It allows the various
+ firmware phases to communicate state and settings to following
+ phases.
+
 source "common/spl/Kconfig"
 
 config IMAGE_SIGN_INFO
diff --git a/common/bloblist.c b/common/bloblist.c
index 29164c9b901..d36e0a94dff 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -444,6 +444,10 @@ int bloblist_init(void)
addr = IF_ENABLED_INT(CONFIG_BLOBLIST_FIXED, CONFIG_BLOBLIST_ADDR);
size = CONFIG_BLOBLIST_SIZE;
if (expected) {
+   if (CONFIG_IS_ENABLED(BLOBLIST_PASSAGE)) {
+   addr = gd->passage_bloblist;
+   size = 0;
+   }
ret = bloblist_check(addr, size);
if (ret) {
log_warning("Expected bloblist at %lx not found 
(err=%d)\n",
diff --git a/common/board_f.c b/common/board_f.c
index 14e9286a70f..86c77a42847 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -570,11 +570,13 @@ static int reserve_stacks(void)
 static int reserve_bloblist(void)
 {
 #ifdef CONFIG_BLOBLIST
+   int new_size = CONFIG_BLOBLIST_SIZE_RELOC;
+
+   if (!new_size)
+   new_size = bloblist_get_size();
/* Align to a 4KB boundary for easier reading of addresses */
-   gd->start_addr_sp = ALIGN_DOWN(gd->start_addr_sp -
-  CONFIG_BLOBLIST_SIZE_RELOC, 0x1000);
-   gd->new_bloblist = map_sysmem(gd->start_addr_sp,
- CONFIG_BLOBLIST_SIZE_RELOC);
+   gd->start_addr_sp = ALIGN_DOWN(gd->start_addr_sp - new_size, 0x1000);
+   gd->new_bloblist = map_sysmem(gd->start_addr_sp, new_size);
 #endif
 
return 0;
@@ -655,21 +657,21 @@ static int reloc_bootstage(void)
 static int reloc_bloblist(void)
 {
 #ifdef CONFIG_BLOBLIST
-   /*
-* Relocate only if we are supposed to send it
-*/
-   if ((gd->flags & GD_FLG_SKIP_RELOC) &&
-   CONFIG_BLOBLIST_SIZE == CONFIG_BLOBLIST_SIZE_RELOC) {
+   int size = bloblist_get_size();
+   int new_size = CONFIG_BLOBLIST_SIZE_RELOC;
+
+   if (!new_size)
+   new_size = size;
+
+   /* Relocate only if we are supposed to send it */
+   if ((gd->flags & GD_FLG_SKIP_RELOC) && size == new_size) {
debug("Not relocating bloblist\n");
return 0;
}
if (gd->new_bloblist) {
-   int size = CONFIG_BLOBLIST_SIZE;
-
-   debug("Copying bloblist from %p to %p, size %x\n",
- gd->bloblist, 

[PATCH 19/31] passage: spl: Support adding the dtb to the passage bloblist

2021-10-31 Thread Simon Glass
Add an option for SPL to add a devicetree to the passage bloblist, so
SPL can provide the devicetree to U-Boot.

Signed-off-by: Simon Glass 
---

 common/Kconfig   | 20 
 common/spl/spl.c | 44 ++--
 include/spl.h|  2 ++
 3 files changed, 64 insertions(+), 2 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index fa7915d2acc..e0d7ee28c4d 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -864,6 +864,26 @@ config SPL_PASSAGE_IN
  firmware phases to communicate state and settings to following
  phases.
 
+config SPL_PASSAGE_OUT
+   bool "Support the standard-passage protocol in SPL (out)"
+   depends on SPL_BLOBLIST
+   default y if PASSAGE_IN
+   help
+ This enables a standard protocol for entering U-Boot, providing
+ parameters in a bloblist and a devicetree. It allows the various
+ firmware stages to communicate state and settings to following
+ stages.
+
+config SPL_PASSAGE_ADD_DTB
+   bool "Add devicetree to the outgoing passage"
+   depends on SPL_PASSAGE_OUT
+   default y if SPL_PASSAGE_OUT && !SPL_PASSAGE_IN
+   help
+ Add the devicetree into the bloblist in SPL (it is assumed to not
+ already be there) so that the next phase (U-Boot) can find it.
+
+ This option should be enabled in the phase that sets up the passage.
+
 source "common/spl/Kconfig"
 
 config IMAGE_SIGN_INFO
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 55e33d2fc44..7a9df9aaece 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -58,6 +58,11 @@ binman_sym_declare(ulong, spl, image_pos);
 binman_sym_declare(ulong, spl, size);
 #endif
 
+#if CONFIG_IS_ENABLED(PASSAGE_ADD_DTB)
+binman_sym_declare(ulong, u_boot_dtb, image_pos);
+binman_sym_declare(ulong, u_boot_dtb, size);
+#endif
+
 /* Define board data structure */
 static struct bd_info bdata __attribute__ ((section(".data")));
 
@@ -408,7 +413,8 @@ static int setup_spl_handoff(void)
 {
struct spl_handoff *ho;
 
-   ho = bloblist_ensure(BLOBLISTT_U_BOOT_SPL_HANDOFF, sizeof(struct 
spl_handoff));
+   ho = bloblist_ensure(BLOBLISTT_U_BOOT_SPL_HANDOFF,
+sizeof(struct spl_handoff));
if (!ho)
return -ENOENT;
 
@@ -425,7 +431,8 @@ static int write_spl_handoff(void)
struct spl_handoff *ho;
int ret;
 
-   ho = bloblist_find(BLOBLISTT_U_BOOT_SPL_HANDOFF, sizeof(struct 
spl_handoff));
+   ho = bloblist_find(BLOBLISTT_U_BOOT_SPL_HANDOFF,
+  sizeof(struct spl_handoff));
if (!ho)
return -ENOENT;
handoff_save_dram(ho);
@@ -442,6 +449,33 @@ static inline int write_spl_handoff(void) { return 0; }
 
 #endif /* HANDOFF */
 
+/**
+ * Write the devicetree for the next phase into the passage
+ *
+ * For now we assume the next phase is U-Boot proper
+ *
+ * @return 0 on success,  -ENOSPC if it is missing and could not be added due 
to
+ * lack of space, or -ESPIPE it exists but has the wrong size
+ */
+static int passage_write_dtb(void)
+{
+#if CONFIG_IS_ENABLED(PASSAGE_ADD_DTB)
+   ulong start = binman_sym(ulong, u_boot_dtb, image_pos);
+   ulong size = binman_sym(ulong, u_boot_dtb, size);
+   void *dtb;
+   int ret;
+
+   log_debug("passage: Adding control dtb size %lx\n", size);
+   ret = bloblist_ensure_size(BLOBLISTT_CONTROL_DTB, size, 0,
+  (void **));
+   if (ret)
+   return ret;
+   memcpy(dtb, map_sysmem(start, size), size);
+#endif
+
+   return 0;
+}
+
 /**
  * get_bootstage_id() - Get the bootstage ID to emit
  *
@@ -763,6 +797,12 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
printf(SPL_TPL_PROMPT
   "SPL hand-off write failed (err=%d)\n", ret);
}
+   if (CONFIG_IS_ENABLED(PASSAGE_ADD_DTB)) {
+   ret = passage_write_dtb();
+   if (ret)
+   printf(SPL_TPL_PROMPT
+  "Write DTB failed (err=%d)\n", ret);
+   }
if (CONFIG_IS_ENABLED(BLOBLIST)) {
ret = bloblist_finish();
if (ret)
diff --git a/include/spl.h b/include/spl.h
index 0af0ee30034..7da8f7f92ab 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -270,6 +270,8 @@ binman_sym_extern(ulong, u_boot_any, image_pos);
 binman_sym_extern(ulong, u_boot_any, size);
 binman_sym_extern(ulong, spl, image_pos);
 binman_sym_extern(ulong, spl, size);
+binman_sym_extern(ulong, u_boot_dtb, image_pos);
+binman_sym_extern(ulong, u_boot_dtb, size);
 
 /**
  * spl_get_image_pos() - get the image position of the next phase
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 17/31] passage: Support a control devicetree

2021-10-31 Thread Simon Glass
Add support for accepting a control devicetree from the incoming passage.
This allows SPL (or some other program) to pass a devicetree to U-Boot
proper in a standard way.

Pass the devicetree through the early parts of U-Boot needs a list care.
If it is in the bloblist, there is no need to reserve a separate space for
it to relocate into, since it will be relocated as part of the bloblist.

Also we must init the bloblist before calling fdtdec_setup(), so the
devicetree can be read from the bloblist*. This is not normally safe,
since malloc() is be called by bloblist_init() if CONFIG_BLOBLIST_ALLOC
is enabled. But in the case of a devicetree in the incoming passage, we
know we won't need to allocate the bloblist, since the previous phase has
set it up for us.

Finally, move the reloc_fdt() call after the reloc_bloblist() since, as
mentioned above, when the passage is used there is no need to relocate the
devicetree.

There is one subtlety here. If bloblist support is not enabled in U-Boot,
it can still receive a control devicetree, using the passage_dtb_off value
added to passage_bloblist. This allows the devicetree passing to work
even if the bloblist itself is ignored. In that case we do need to
relocate the devicetree. Use a global_data flag for this case.

* Actually we could init the bloblist later, since we have the offset of
the devicetree in a register, but that seems like an extreme measure,
bypassing U-Boot's own bloblist implementation to get at the data.

Signed-off-by: Simon Glass 
---

 common/bloblist.c |  1 +
 common/board_f.c  | 16 
 dts/Kconfig   | 12 
 include/asm-generic/global_data.h |  4 
 include/bloblist.h|  1 +
 lib/fdtdec.c  | 30 ++
 6 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index d36e0a94dff..310ca87dbc4 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -39,6 +39,7 @@ static struct tag_name {
{ BLOBLISTT_NONE, "(none)" },
 
/* BLOBLISTT_AREA_FIRMWARE_TOP */
+   { BLOBLISTT_CONTROL_DTB, "Control DTB" },
 
/* BLOBLISTT_AREA_FIRMWARE */
{ BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
diff --git a/common/board_f.c b/common/board_f.c
index 86c77a42847..3684c21a0f7 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -517,7 +517,7 @@ static int reserve_global_data(void)
 
 static int reserve_fdt(void)
 {
-   if (!IS_ENABLED(CONFIG_OF_EMBED)) {
+   if (!IS_ENABLED(CONFIG_OF_EMBED) && !(gd->flags & GD_FLG_OF_PASSAGE)) {
/*
 * If the device tree is sitting immediately above our image
 * then we must relocate it. If it is embedded in the data
@@ -622,7 +622,12 @@ static int init_post(void)
 
 static int reloc_fdt(void)
 {
-   if (!IS_ENABLED(CONFIG_OF_EMBED)) {
+   if (IS_ENABLED(CONFIG_OF_PASSAGE) && (gd->flags & GD_FLG_OF_PASSAGE)) {
+   void *blob = bloblist_find(BLOBLISTT_CONTROL_DTB, 0);
+
+   log_info("passage: Control dtb relocated to %p\n", blob);
+   gd->fdt_blob = blob;
+   } else if (!IS_ENABLED(CONFIG_OF_EMBED)) {
if (gd->flags & GD_FLG_SKIP_RELOC)
return 0;
if (gd->new_fdt) {
@@ -819,6 +824,9 @@ __weak int clear_bss(void)
 
 static const init_fnc_t init_sequence_f[] = {
setup_mon_len,
+#ifdef CONFIG_OF_PASSAGE
+   bloblist_init,
+#endif
 #ifdef CONFIG_OF_CONTROL
fdtdec_setup,
 #endif
@@ -828,7 +836,7 @@ static const init_fnc_t init_sequence_f[] = {
initf_malloc,
log_init,
initf_bootstage,/* uses its own timer, so does not need DM */
-#ifdef CONFIG_BLOBLIST
+#if !defined(CONFIG_OF_PASSAGE) && defined(CONFIG_BLOBLIST)
bloblist_init,
 #endif
setup_spl_handoff,
@@ -938,9 +946,9 @@ static const init_fnc_t init_sequence_f[] = {
setup_bdinfo,
display_new_sp,
INIT_FUNC_WATCHDOG_RESET
-   reloc_fdt,
reloc_bootstage,
reloc_bloblist,
+   reloc_fdt,
setup_reloc,
 #if defined(CONFIG_X86) || defined(CONFIG_ARC)
copy_uboot_to_ram,
diff --git a/dts/Kconfig b/dts/Kconfig
index 5dcc79d5192..7e4d9852a44 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -96,6 +96,18 @@ config OF_EMBED
 
 endchoice
 
+config OF_PASSAGE
+   bool "Devicetree provided by the standard passage protocol"
+   help
+ If this option is enabled, the device tree may be provided by the
+ standard passage, meaning that a previous phase/stage passes a
+ bloblist containing this. This is the standard way to pass a
+ devicetree between firmware components at runtime. The device tree
+ bundled with the image (if any) will be overridden / ignored.
+
+ Note: If BLOBLIST is not enabled, this does not decode the
+ bloblist, but just picks up the 

[PATCH 18/31] passage: arm: Accept a passage from the previous phase

2021-10-31 Thread Simon Glass
Accept a bloblist and control devicetree from a previous phase in
registers r0 and r1

Signed-off-by: Simon Glass 
---

 arch/arm/cpu/armv7/start.S | 7 ++-
 arch/arm/lib/crt0.S| 4 
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 698e15b8e18..5ebe2c26693 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -36,6 +36,10 @@
 #endif
 
 reset:
+   # Keep passage information in case it is provided
+   mov r6, r0
+   mov r7, r1
+
/* Allow the board to save important registers */
b   save_boot_params
 save_boot_params_ret:
@@ -124,7 +128,8 @@ switch_to_hypervisor_ret:
bl  cpu_init_crit
 #endif
 #endif
-
+   # Note: r6 and r7 are available to _main in case standard passage is
+   # used
bl  _main
 
 
/*--*/
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 956d258c9da..f5343b22683 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -113,6 +113,10 @@ ENTRY(_main)
CLEAR_BSS
 #endif
 
+#if CONFIG_IS_ENABLED(PASSAGE_IN)
+   str r6, [r9, GD_PASSAGE_BLOBLIST]
+   str r7, [r9, GD_PASSAGE_DTB_OFF]
+#endif
mov r0, #0
bl  board_init_f
 
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 15/31] bloblist: Add functions to obtain base address and size

2021-10-31 Thread Simon Glass
Add a few convenience functions to obtain useful information about the
bloblist.

Signed-off-by: Simon Glass 
---

 common/bloblist.c  | 12 
 include/bloblist.h | 14 ++
 test/bloblist.c|  2 ++
 3 files changed, 28 insertions(+)

diff --git a/common/bloblist.c b/common/bloblist.c
index 6e7f813db94..29164c9b901 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -367,6 +367,18 @@ int bloblist_finish(void)
return 0;
 }
 
+ulong bloblist_get_base(void)
+{
+   return map_to_sysmem(gd->bloblist);
+}
+
+ulong bloblist_get_size(void)
+{
+   struct bloblist_hdr *hdr = gd->bloblist;
+
+   return hdr->size;
+}
+
 void bloblist_get_stats(ulong *basep, ulong *sizep, ulong *allocedp)
 {
struct bloblist_hdr *hdr = gd->bloblist;
diff --git a/include/bloblist.h b/include/bloblist.h
index 5de4545160e..88c62b54c54 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -292,6 +292,20 @@ int bloblist_finish(void);
  */
 void bloblist_get_stats(ulong *basep, ulong *sizep, ulong *allocedp);
 
+/**
+ * bloblist_get_base() - Get the base address of the bloblist
+ *
+ * @returns base address of bloblist
+ */
+ulong bloblist_get_base(void);
+
+/**
+ * bloblist_get_size() - Get the size of the bloblist
+ *
+ * @returns the size in bytes
+ */
+ulong bloblist_get_size(void);
+
 /**
  * bloblist_show_stats() - Show information about the bloblist
  *
diff --git a/test/bloblist.c b/test/bloblist.c
index c5788d5cd82..720be7e244f 100644
--- a/test/bloblist.c
+++ b/test/bloblist.c
@@ -107,6 +107,8 @@ static int bloblist_test_blob(struct unit_test_state *uts)
hdr = clear_bloblist();
ut_assertnull(bloblist_find(TEST_TAG, TEST_BLOBLIST_SIZE));
ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
+   ut_asserteq(TEST_BLOBLIST_SIZE, bloblist_get_size());
+   ut_asserteq(TEST_ADDR, bloblist_get_base());
ut_asserteq(map_to_sysmem(hdr), TEST_ADDR);
 
/* Add a record and check that we can find it */
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 11/31] bloblist: Use LOG_CATEGORY to simply logging

2021-10-31 Thread Simon Glass
Use the convenience functions to improve readability.

Signed-off-by: Simon Glass 
---

 common/bloblist.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index baf1d371b71..b5fea12b697 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -4,6 +4,8 @@
  * Written by Simon Glass 
  */
 
+#define LOG_CATEGORY   LOGC_BLOBLIST
+
 #include 
 #include 
 #include 
@@ -133,9 +135,8 @@ static int bloblist_addrec(uint tag, int size, int align,
new_alloced = data_start + ALIGN(size, align);
 
if (new_alloced > hdr->size) {
-   log(LOGC_BLOBLIST, LOGL_ERR,
-   "Failed to allocate %x bytes size=%x, need size=%x\n",
-   size, hdr->size, new_alloced);
+   log_err("Failed to allocate %x bytes size=%x, need size=%x\n",
+   size, hdr->size, new_alloced);
return log_msg_ret("bloblist add", -ENOSPC);
}
rec = (void *)hdr + hdr->alloced;
@@ -249,14 +250,13 @@ static int bloblist_resize_rec(struct bloblist_hdr *hdr,
expand_by = ALIGN(new_size - rec->size, BLOBLIST_ALIGN);
new_alloced = ALIGN(hdr->alloced + expand_by, BLOBLIST_ALIGN);
if (new_size < 0) {
-   log(LOGC_BLOBLIST, LOGL_DEBUG,
-   "Attempt to shrink blob size below 0 (%x)\n", new_size);
+   log_debug("Attempt to shrink blob size below 0 (%x)\n",
+ new_size);
return log_msg_ret("size", -EINVAL);
}
if (new_alloced > hdr->size) {
-   log(LOGC_BLOBLIST, LOGL_ERR,
-   "Failed to allocate %x bytes size=%x, need size=%x\n",
-   new_size, hdr->size, new_alloced);
+   log_err("Failed to allocate %x bytes size=%x, need size=%x\n",
+   new_size, hdr->size, new_alloced);
return log_msg_ret("alloc", -ENOSPC);
}
 
@@ -347,8 +347,7 @@ int bloblist_check(ulong addr, uint size)
return log_msg_ret("Bad size", -EFBIG);
chksum = bloblist_calc_chksum(hdr);
if (hdr->chksum != chksum) {
-   log(LOGC_BLOBLIST, LOGL_ERR, "Checksum %x != %x\n", hdr->chksum,
-   chksum);
+   log_err("Checksum %x != %x\n", hdr->chksum, chksum);
return log_msg_ret("Bad checksum", -EIO);
}
gd->bloblist = hdr;
@@ -446,7 +445,7 @@ int bloblist_init(void)
}
ret = bloblist_new(addr, CONFIG_BLOBLIST_SIZE, 0);
} else {
-   log(LOGC_BLOBLIST, LOGL_DEBUG, "Found existing bloblist\n");
+   log_debug("Found existing bloblist\n");
}
 
return ret;
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 13/31] bloblist: Refactor Kconfig to support alloc or fixed

2021-10-31 Thread Simon Glass
At present we do support allocating the bloblist but the Kconfig is a bit
strange, since we still have to specify an address in that case. Partly
this is because it is a pain to have CONFIG options that disappears when
its dependency is enabled. It means that we must have #ifdefs in the code,
either in the C code or header file.

Make use of IF_ENABLED_INT() and its friend to solve that problem, so we
can separate out the location of bloblist into a choice. Put the address
and size into variables so we can log the result.

Add the options for SPL as well, so we can use CONFIG_IS_ENABLED().

Signed-off-by: Simon Glass 
---

 common/Kconfig| 91 ++-
 common/bloblist.c | 39 
 2 files changed, 106 insertions(+), 24 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index 4cf1831f599..2c6f5901c8a 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -721,15 +721,17 @@ config TPL_BLOBLIST
 
 if BLOBLIST
 
-config BLOBLIST_SIZE
-   hex "Size of bloblist"
-   depends on BLOBLIST
-   default 0x400
+choice
+   prompt "Bloblist location"
help
- Sets the size of the bloblist in bytes. This must include all
- overhead (alignment, bloblist header, record header). The bloblist
- is set up in the first part of U-Boot to run (TPL, SPL or U-Boot
- proper), and this sane bloblist is used for subsequent phases.
+ Select the location of the bloblist, via various means.
+
+config BLOBLIST_FIXED
+   bool "Place bloblist at a fixed address in memory"
+   help
+ Select this to used a fixed memory address for the bloblist. If the
+ bloblist exists at this address from a previous phase, it used as is.
+ If not it is created at this address in U-Boot.
 
 config BLOBLIST_ALLOC
bool "Allocate bloblist"
@@ -738,18 +740,31 @@ config BLOBLIST_ALLOC
  specify a fixed address on systems where this is unknown or can
  change at runtime.
 
+endchoice
+
 config BLOBLIST_ADDR
hex "Address of bloblist"
default 0xc000 if SANDBOX
+   depends on BLOBLIST_FIXED
help
  Sets the address of the bloblist, set up by the first part of U-Boot
  which runs. Subsequent U-Boot phases typically use the same address.
 
  This is not used if BLOBLIST_ALLOC is selected.
 
+config BLOBLIST_SIZE
+   hex "Size of bloblist"
+   default 0x400
+   help
+ Sets the size of the bloblist in bytes. This must include all
+ overhead (alignment, bloblist header, record header). The bloblist
+ is set up in the first part of U-Boot to run (TPL, SPL or U-Boot
+ proper), and this sane bloblist is used for subsequent phases.
+
 config BLOBLIST_SIZE_RELOC
hex "Size of bloblist after relocation"
-   default BLOBLIST_SIZE
+   default BLOBLIST_SIZE if BLOBLIST_FIXED || BLOBLIST_ALLOC
+   default 0 if BLOBLIST_PASSAGE
help
  Sets the size of the bloblist in bytes after relocation. Since U-Boot
  has a lot more memory available then, it is possible to use a larger
@@ -758,6 +773,64 @@ config BLOBLIST_SIZE_RELOC
 
 endif # BLOBLIST
 
+if SPL_BLOBLIST
+
+choice
+   prompt "Bloblist location in SPL"
+   help
+ Select the location of the bloblist, via various means. Typically
+ you should use the same value for SPL as for U-Boot, since they need
+ to look in the same place. But if BLOBLIST_ALLOC is used, then a
+ fresh bloblist will be created each time, since there is no shared
+ address (between phases) for the bloblist.
+
+config SPL_BLOBLIST_FIXED
+   bool "Place bloblist at a fixed address in memory"
+   help
+ Select this to used a fixed memory address for the bloblist. If the
+ bloblist exists at this address from a previous phase, it used as is.
+ If not it is created at this address in SPL.
+
+config SPL_BLOBLIST_ALLOC
+   bool "Allocate bloblist"
+   help
+ Allocate the bloblist using malloc(). This avoids the need to
+ specify a fixed address on systems where this is unknown or can
+ change at runtime.
+
+endchoice
+
+endif # SPL_BLOBLIST
+
+if TPL_BLOBLIST
+
+choice
+   prompt "Bloblist location in TPL"
+   help
+ Select the location of the bloblist, via various means. Typically
+ you should use the same value for SPL as for U-Boot, since they need
+ to look in the same place. But if BLOBLIST_ALLOC is used, then a
+ fresh bloblist will be created each time, since there is no shared
+ address (between phases) for the bloblist.
+
+config TPL_BLOBLIST_FIXED
+   bool "Place bloblist at a fixed address in memory"
+   help
+ Select this to used a fixed memory address for the bloblist. If the
+ bloblist exists at this address from a previous phase, it used as is.
+ If 

[PATCH 09/31] bloblist: Use explicit numbering for the tags

2021-10-31 Thread Simon Glass
At present if someone adds a tag in the middle of the list it works well
enough within a U-Boot build. But if these tags are used in another
project, or with an older version of SPL, the numbers make become
inconsistent.

Use explicit tag numbers that never change, to resolve this problem.
Allocate areas for existing U-Boot tags and set up an area for use by
projects and vendors, as well as for private use. Keep tags above
0x1 unallocated for now.

Update bloblist_tag_name() and the tests to work with this new setup.

Signed-off-by: Simon Glass 
---

 common/bloblist.c  | 45 +++
 include/bloblist.h | 58 +-
 test/bloblist.c| 12 +-
 3 files changed, 83 insertions(+), 32 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index 2418241193a..4a04e66576e 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -28,24 +28,39 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static const char *const tag_name[] = {
-   [BLOBLISTT_NONE]= "(none)",
-   [BLOBLISTT_U_BOOT_SPL_HANDOFF]  = "SPL hand-off",
-   [BLOBLISTT_VBOOT_CTX]   = "Chrome OS vboot context",
-   [BLOBLISTT_ACPI_GNVS]   = "ACPI GNVS",
-   [BLOBLISTT_INTEL_VBT]   = "Intel Video-BIOS table",
-   [BLOBLISTT_TPM2_TCG_LOG]= "TPM v2 log space",
-   [BLOBLISTT_TCPA_LOG]= "TPM log space",
-   [BLOBLISTT_ACPI_TABLES] = "ACPI tables for x86",
-   [BLOBLISTT_SMBIOS_TABLES]   = "SMBIOS tables for x86",
+static struct tag_name {
+   enum bloblist_tag_t tag;
+   const char *name;
+} tag_name[] = {
+   { BLOBLISTT_NONE, "(none)" },
+
+   /* BLOBLISTT_AREA_FIRMWARE_TOP */
+
+   /* BLOBLISTT_AREA_FIRMWARE */
+   { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
+   { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
+   { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
+   { BLOBLISTT_TCPA_LOG, "TPM log space" },
+   { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
+   { BLOBLISTT_SMBIOS_TABLES, "SMBIOS tables for x86" },
+   { BLOBLISTT_VBOOT_CTX, "Chrome OS vboot context" },
+
+   /* BLOBLISTT_PROJECT_AREA */
+   { BLOBLISTT_U_BOOT_SPL_HANDOFF, "SPL hand-off" },
+
+   /* BLOBLISTT_VENDOR_AREA */
 };
 
 const char *bloblist_tag_name(enum bloblist_tag_t tag)
 {
-   if (tag < 0 || tag >= BLOBLISTT_COUNT)
-   return "invalid";
+   int i;
 
-   return tag_name[tag];
+   for (i = 0; i < ARRAY_SIZE(tag_name); i++) {
+   if (tag_name[i].tag == tag)
+   return tag_name[i].name;
+   }
+
+   return "invalid";
 }
 
 static struct bloblist_rec *bloblist_first_blob(struct bloblist_hdr *hdr)
@@ -380,10 +395,10 @@ void bloblist_show_list(void)
struct bloblist_hdr *hdr = gd->bloblist;
struct bloblist_rec *rec;
 
-   printf("%-8s  %8s  Tag Name\n", "Address", "Size");
+   printf("%-8s  %8s   Tag Name\n", "Address", "Size");
for (rec = bloblist_first_blob(hdr); rec;
 rec = bloblist_next_blob(hdr, rec)) {
-   printf("%08lx  %8x  %3d %s\n",
+   printf("%08lx  %8x  %4x %s\n",
   (ulong)map_to_sysmem((void *)rec + rec->hdr_size),
   rec->size, rec->tag, bloblist_tag_name(rec->tag));
}
diff --git a/include/bloblist.h b/include/bloblist.h
index fac25907c07..5de4545160e 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -25,21 +25,57 @@ enum {
 enum bloblist_tag_t {
BLOBLISTT_NONE = 0,
 
-   /* Vendor-specific tags are permitted here */
-   BLOBLISTT_U_BOOT_SPL_HANDOFF,   /* Hand-off info from SPL */
-   BLOBLISTT_VBOOT_CTX,/* Chromium OS verified boot context */
+   /*
+* Standard area to allocate blobs used across firmware components, for
+* things that are very commonly used, particularly in multiple
+* projects.
+*/
+   BLOBLISTT_AREA_FIRMWARE_TOP = 0x1,
+
+   /* Standard area to allocate blobs used across firmware components */
+   BLOBLISTT_AREA_FIRMWARE = 0x100,
/*
 * Advanced Configuration and Power Interface Global Non-Volatile
 * Sleeping table. This forms part of the ACPI tables passed to Linux.
 */
-   BLOBLISTT_ACPI_GNVS,
-   BLOBLISTT_INTEL_VBT,/* Intel Video-BIOS table */
-   BLOBLISTT_TPM2_TCG_LOG, /* TPM v2 log space */
-   BLOBLISTT_TCPA_LOG, /* TPM log space */
-   BLOBLISTT_ACPI_TABLES,  /* ACPI tables for x86 */
-   BLOBLISTT_SMBIOS_TABLES,/* SMBIOS tables for x86 */
-
-   BLOBLISTT_COUNT
+   BLOBLISTT_ACPI_GNVS = 0x100,
+   BLOBLISTT_INTEL_VBT = 0x101,/* Intel Video-BIOS table */
+   BLOBLISTT_TPM2_TCG_LOG = 0x102, /* TPM v2 log space */
+   BLOBLISTT_TCPA_LOG = 0x103, /* TPM log space */
+   BLOBLISTT_ACPI_TABLES = 

[PATCH 10/31] bloblist: Support allocating the bloblist

2021-10-31 Thread Simon Glass
Typically the bloblist is positioned at a fixed address in memory until
relocation. This is convenient when it is set up in SPL or before
relocation.

But for EFI we want to set it up only when U-Boot proper is running. Add
a way to allocate it using malloc() and update the documentation to cover
this aspect of bloblist.

Note there are no tests of this feature at present, nor any direct testing
of bloblist_init().

This can be added, e.g. by making this option controllable at runtime.

A test that uses sandbox_spl is possible but will need some more plumbing,
to come later. A qemu test for ARM is included later in this series.

Signed-off-by: Simon Glass 
---

 common/Kconfig   | 15 +--
 common/bloblist.c| 16 ++--
 common/board_f.c |  8 +++-
 doc/develop/bloblist.rst | 16 
 4 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index d6f77ab7b9c..00ccaf59fa4 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -719,6 +719,8 @@ config TPL_BLOBLIST
  This enables a bloblist in TPL. The bloblist is set up in TPL and
  passed to SPL and U-Boot proper.
 
+if BLOBLIST
+
 config BLOBLIST_SIZE
hex "Size of bloblist"
depends on BLOBLIST
@@ -729,17 +731,24 @@ config BLOBLIST_SIZE
  is set up in the first part of U-Boot to run (TPL, SPL or U-Boot
  proper), and this sane bloblist is used for subsequent stages.
 
+config BLOBLIST_ALLOC
+   bool "Allocate bloblist"
+   help
+ Allocate the bloblist using malloc(). This avoids the need to
+ specify a fixed address on systems where this is unknown or can
+ change at runtime.
+
 config BLOBLIST_ADDR
hex "Address of bloblist"
-   depends on BLOBLIST
default 0xc000 if SANDBOX
help
  Sets the address of the bloblist, set up by the first part of U-Boot
  which runs. Subsequent U-Boot stages typically use the same address.
 
+ This is not used if BLOBLIST_ALLOC is selected.
+
 config BLOBLIST_SIZE_RELOC
hex "Size of bloblist after relocation"
-   depends on BLOBLIST
default BLOBLIST_SIZE
help
  Sets the size of the bloblist in bytes after relocation. Since U-Boot
@@ -747,6 +756,8 @@ config BLOBLIST_SIZE_RELOC
  size than the one set up by SPL. This bloblist is set up during the
  relocation process.
 
+endif # BLOBLIST
+
 endmenu
 
 source "common/spl/Kconfig"
diff --git a/common/bloblist.c b/common/bloblist.c
index 4a04e66576e..baf1d371b71 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -429,10 +430,21 @@ int bloblist_init(void)
ret = bloblist_check(CONFIG_BLOBLIST_ADDR,
 CONFIG_BLOBLIST_SIZE);
if (ret) {
+   ulong addr;
+
log(LOGC_BLOBLIST, expected ? LOGL_WARNING : LOGL_DEBUG,
"Existing bloblist not found: creating new bloblist\n");
-   ret = bloblist_new(CONFIG_BLOBLIST_ADDR, CONFIG_BLOBLIST_SIZE,
-  0);
+   if (IS_ENABLED(CONFIG_BLOBLIST_ALLOC)) {
+   void *ptr = memalign(BLOBLIST_ALIGN,
+CONFIG_BLOBLIST_SIZE);
+
+   if (!ptr)
+   return log_msg_ret("alloc", -ENOMEM);
+   addr = map_to_sysmem(ptr);
+   } else {
+   addr = CONFIG_BLOBLIST_ADDR;
+   }
+   ret = bloblist_new(addr, CONFIG_BLOBLIST_SIZE, 0);
} else {
log(LOGC_BLOBLIST, LOGL_DEBUG, "Found existing bloblist\n");
}
diff --git a/common/board_f.c b/common/board_f.c
index 261d0f52cd7..14e9286a70f 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -655,8 +655,14 @@ static int reloc_bootstage(void)
 static int reloc_bloblist(void)
 {
 #ifdef CONFIG_BLOBLIST
-   if (gd->flags & GD_FLG_SKIP_RELOC)
+   /*
+* Relocate only if we are supposed to send it
+*/
+   if ((gd->flags & GD_FLG_SKIP_RELOC) &&
+   CONFIG_BLOBLIST_SIZE == CONFIG_BLOBLIST_SIZE_RELOC) {
+   debug("Not relocating bloblist\n");
return 0;
+   }
if (gd->new_bloblist) {
int size = CONFIG_BLOBLIST_SIZE;
 
diff --git a/doc/develop/bloblist.rst b/doc/develop/bloblist.rst
index 317ebc4919d..47274cf8e26 100644
--- a/doc/develop/bloblist.rst
+++ b/doc/develop/bloblist.rst
@@ -59,6 +59,22 @@ Bloblist provides a fairly simple API which allows blobs to 
be created and
 found. All access is via the blob's tag. Blob records are zeroed when added.
 
 
+Placing the bloblist
+
+
+The bloblist is typically positioned at a fixed address by TPL, or SPL. This
+is controlled by 

[PATCH 07/31] bloblist: Rename the SPL tag

2021-10-31 Thread Simon Glass
Add a U_BOOT prefix to this tag since it is specific to the U-Boot
project.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/broadwell/cpu_from_spl.c | 4 ++--
 common/bloblist.c | 2 +-
 common/board_f.c  | 2 +-
 common/spl/spl.c  | 4 ++--
 include/bloblist.h| 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/cpu/broadwell/cpu_from_spl.c 
b/arch/x86/cpu/broadwell/cpu_from_spl.c
index e5f62e7187c..df5a9675ee4 100644
--- a/arch/x86/cpu/broadwell/cpu_from_spl.c
+++ b/arch/x86/cpu/broadwell/cpu_from_spl.c
@@ -23,7 +23,7 @@ int dram_init(void)
 {
struct spl_handoff *ho;
 
-   ho = bloblist_find(BLOBLISTT_SPL_HANDOFF, sizeof(*ho));
+   ho = bloblist_find(BLOBLISTT_U_BOOT_SPL_HANDOFF, sizeof(*ho));
if (!ho)
return log_msg_ret("Missing SPL hand-off info", -ENOENT);
handoff_load_dram_size(ho);
@@ -56,7 +56,7 @@ int dram_init_banksize(void)
 {
struct spl_handoff *ho;
 
-   ho = bloblist_find(BLOBLISTT_SPL_HANDOFF, sizeof(*ho));
+   ho = bloblist_find(BLOBLISTT_U_BOOT_SPL_HANDOFF, sizeof(*ho));
if (!ho)
return log_msg_ret("Missing SPL hand-off info", -ENOENT);
handoff_load_dram_banks(ho);
diff --git a/common/bloblist.c b/common/bloblist.c
index 1290fff8504..557e892c854 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -31,7 +31,7 @@ DECLARE_GLOBAL_DATA_PTR;
 static const char *const tag_name[] = {
[BLOBLISTT_NONE]= "(none)",
[BLOBLISTT_EC_HOSTEVENT]= "EC host event",
-   [BLOBLISTT_SPL_HANDOFF] = "SPL hand-off",
+   [BLOBLISTT_U_BOOT_SPL_HANDOFF]  = "SPL hand-off",
[BLOBLISTT_VBOOT_CTX]   = "Chrome OS vboot context",
[BLOBLISTT_VBOOT_HANDOFF]   = "Chrome OS vboot hand-off",
[BLOBLISTT_ACPI_GNVS]   = "ACPI GNVS",
diff --git a/common/board_f.c b/common/board_f.c
index 3dc0eaa59c5..261d0f52cd7 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -283,7 +283,7 @@ static int setup_mon_len(void)
 static int setup_spl_handoff(void)
 {
 #if CONFIG_IS_ENABLED(HANDOFF)
-   gd->spl_handoff = bloblist_find(BLOBLISTT_SPL_HANDOFF,
+   gd->spl_handoff = bloblist_find(BLOBLISTT_U_BOOT_SPL_HANDOFF,
sizeof(struct spl_handoff));
debug("Found SPL hand-off info %p\n", gd->spl_handoff);
 #endif
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 0c08da06e8f..55e33d2fc44 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -408,7 +408,7 @@ static int setup_spl_handoff(void)
 {
struct spl_handoff *ho;
 
-   ho = bloblist_ensure(BLOBLISTT_SPL_HANDOFF, sizeof(struct spl_handoff));
+   ho = bloblist_ensure(BLOBLISTT_U_BOOT_SPL_HANDOFF, sizeof(struct 
spl_handoff));
if (!ho)
return -ENOENT;
 
@@ -425,7 +425,7 @@ static int write_spl_handoff(void)
struct spl_handoff *ho;
int ret;
 
-   ho = bloblist_find(BLOBLISTT_SPL_HANDOFF, sizeof(struct spl_handoff));
+   ho = bloblist_find(BLOBLISTT_U_BOOT_SPL_HANDOFF, sizeof(struct 
spl_handoff));
if (!ho)
return -ENOENT;
handoff_save_dram(ho);
diff --git a/include/bloblist.h b/include/bloblist.h
index 29ea5a768a6..d4d48f76ff4 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -27,7 +27,7 @@ enum bloblist_tag_t {
 
/* Vendor-specific tags are permitted here */
BLOBLISTT_EC_HOSTEVENT, /* Chromium OS EC host-event mask */
-   BLOBLISTT_SPL_HANDOFF,  /* Hand-off info from SPL */
+   BLOBLISTT_U_BOOT_SPL_HANDOFF,   /* Hand-off info from SPL */
BLOBLISTT_VBOOT_CTX,/* Chromium OS verified boot context */
BLOBLISTT_VBOOT_HANDOFF,/* Chromium OS internal handoff info */
/*
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 08/31] bloblist: Drop unused tags

2021-10-31 Thread Simon Glass
The EC event log tag is no-longer used. The vboot handoff is now handled
by the vboot context instead.

Drop these unused tags.

Signed-off-by: Simon Glass 
---

 common/bloblist.c  | 4 +---
 include/bloblist.h | 2 --
 test/bloblist.c| 4 ++--
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/common/bloblist.c b/common/bloblist.c
index 557e892c854..2418241193a 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -30,10 +30,8 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static const char *const tag_name[] = {
[BLOBLISTT_NONE]= "(none)",
-   [BLOBLISTT_EC_HOSTEVENT]= "EC host event",
-   [BLOBLISTT_U_BOOT_SPL_HANDOFF]  = "SPL hand-off",
+   [BLOBLISTT_U_BOOT_SPL_HANDOFF]  = "SPL hand-off",
[BLOBLISTT_VBOOT_CTX]   = "Chrome OS vboot context",
-   [BLOBLISTT_VBOOT_HANDOFF]   = "Chrome OS vboot hand-off",
[BLOBLISTT_ACPI_GNVS]   = "ACPI GNVS",
[BLOBLISTT_INTEL_VBT]   = "Intel Video-BIOS table",
[BLOBLISTT_TPM2_TCG_LOG]= "TPM v2 log space",
diff --git a/include/bloblist.h b/include/bloblist.h
index d4d48f76ff4..fac25907c07 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -26,10 +26,8 @@ enum bloblist_tag_t {
BLOBLISTT_NONE = 0,
 
/* Vendor-specific tags are permitted here */
-   BLOBLISTT_EC_HOSTEVENT, /* Chromium OS EC host-event mask */
BLOBLISTT_U_BOOT_SPL_HANDOFF,   /* Hand-off info from SPL */
BLOBLISTT_VBOOT_CTX,/* Chromium OS verified boot context */
-   BLOBLISTT_VBOOT_HANDOFF,/* Chromium OS internal handoff info */
/*
 * Advanced Configuration and Power Interface Global Non-Volatile
 * Sleeping table. This forms part of the ACPI tables passed to Linux.
diff --git a/test/bloblist.c b/test/bloblist.c
index 525e94b7217..2e8e23d77dd 100644
--- a/test/bloblist.c
+++ b/test/bloblist.c
@@ -289,9 +289,9 @@ static int bloblist_test_cmd_list(struct unit_test_state 
*uts)
console_record_reset();
run_command("bloblist list", 0);
ut_assert_nextline("Address   Size  Tag Name");
-   ut_assert_nextline("%08lx  %8x1 EC host event",
+   ut_assert_nextline("%08lx  %8x1 SPL hand-off",
   (ulong)map_to_sysmem(data), TEST_SIZE);
-   ut_assert_nextline("%08lx  %8x2 SPL hand-off",
+   ut_assert_nextline("%08lx  %8x2 Chrome OS vboot context",
   (ulong)map_to_sysmem(data2), TEST_SIZE2);
ut_assert_console_end();
ut_unsilence_console(uts);
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 06/31] bloblist: Put the magic number first

2021-10-31 Thread Simon Glass
It seems best to put the magic number right at the start of the bloblist
header, so it is easier to check. This is how devicetree works.

Make this change now, before other projects make use of bloblist. Other
changes may be needed / discussed, but that is TBD.

Add a checker function as well.

Signed-off-by: Simon Glass 
---

 include/bloblist.h | 25 +++--
 test/bloblist.c|  7 +++
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/include/bloblist.h b/include/bloblist.h
index 9f007c7a94d..29ea5a768a6 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -13,6 +13,8 @@
 #ifndef __BLOBLIST_H
 #define __BLOBLIST_H
 
+#include 
+
 enum {
BLOBLIST_VERSION= 0,
BLOBLIST_MAGIC  = 0xb00757a3,
@@ -59,11 +61,11 @@ enum bloblist_tag_t {
  * Each bloblist record is aligned to a 16-byte boundary and follows 
immediately
  * from the last.
  *
+ * @magic: BLOBLIST_MAGIC
  * @version: BLOBLIST_VERSION
  * @hdr_size: Size of this header, normally sizeof(struct bloblist_hdr). The
  * first bloblist_rec starts at this offset from the start of the header
  * @flags: Space for BLOBLISTF_... flags (none yet)
- * @magic: BLOBLIST_MAGIC
  * @size: Total size of the bloblist (non-zero if valid) including this header.
  * The bloblist extends for this many bytes from the start of this header.
  * When adding new records, the bloblist can grow up to this size.
@@ -78,10 +80,10 @@ enum bloblist_tag_t {
  * calculation.
  */
 struct bloblist_hdr {
+   u32 magic;
u32 version;
u32 hdr_size;
u32 flags;
-   u32 magic;
 
u32 size;
u32 alloced;
@@ -111,6 +113,25 @@ struct bloblist_rec {
u32 spare;
 };
 
+/**
+ * bloblist_check_magic() - return a bloblist if the magic matches
+ *
+ * @addr: Address to check
+ * @return pointer to bloblist, if the magic matches, else NULL
+ */
+static inline void *bloblist_check_magic(ulong addr)
+{
+   u32 *ptr;
+
+   if (!addr)
+   return NULL;
+   ptr = map_sysmem(addr, 0);
+   if (*ptr != BLOBLIST_MAGIC)
+   return NULL;
+
+   return ptr;
+}
+
 /**
  * bloblist_find() - Find a blob
  *
diff --git a/test/bloblist.c b/test/bloblist.c
index b48be38dc3e..525e94b7217 100644
--- a/test/bloblist.c
+++ b/test/bloblist.c
@@ -71,7 +71,9 @@ static int bloblist_test_init(struct unit_test_state *uts)
 
hdr = clear_bloblist();
ut_asserteq(-ENOENT, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
+   ut_asserteq_ptr(NULL, bloblist_check_magic(TEST_ADDR));
ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
+   ut_asserteq_ptr(hdr, bloblist_check_magic(TEST_ADDR));
hdr->version++;
ut_asserteq(-EPROTONOSUPPORT, bloblist_check(TEST_ADDR,
 TEST_BLOBLIST_SIZE));
@@ -83,6 +85,11 @@ static int bloblist_test_init(struct unit_test_state *uts)
ut_asserteq(-EIO, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
ut_assertok(bloblist_finish());
ut_assertok(bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
+
+   hdr->magic++;
+   ut_asserteq_ptr(NULL, bloblist_check_magic(TEST_ADDR));
+   hdr->magic--;
+
hdr->flags++;
ut_asserteq(-EIO, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
 
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 03/31] dm: core: Allow getting some basic stats

2021-10-31 Thread Simon Glass
Add a function that returns some basic stats about driver model. For now
we only have two.

Signed-off-by: Simon Glass 
---

 drivers/core/device.c| 11 ++
 drivers/core/root.c  |  7 ++
 drivers/core/uclass.c| 13 
 include/dm/device.h  | 11 +-
 include/dm/root.h|  8 +++
 include/dm/uclass-internal.h |  7 ++
 test/dm/core.c   | 41 
 7 files changed, 97 insertions(+), 1 deletion(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index d7a778a2413..7d327aba49e 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -723,6 +723,17 @@ int device_get_child_count(const struct udevice *parent)
return count;
 }
 
+int device_get_decendent_count(const struct udevice *parent)
+{
+   const struct udevice *dev;
+   int count = 1;
+
+   list_for_each_entry(dev, >child_head, sibling_node)
+   count += device_get_decendent_count(dev);
+
+   return count;
+}
+
 int device_find_child_by_seq(const struct udevice *parent, int seq,
 struct udevice **devp)
 {
diff --git a/drivers/core/root.c b/drivers/core/root.c
index 26b8195faa3..815173f86eb 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -407,6 +408,12 @@ int dm_init_and_scan(bool pre_reloc_only)
return 0;
 }
 
+void dm_get_stats(int *device_countp, int *uclass_countp)
+{
+   *device_countp = device_get_decendent_count(gd->dm_root);
+   *uclass_countp = uclass_get_count();
+}
+
 #ifdef CONFIG_ACPIGEN
 static int root_acpi_get_name(const struct udevice *dev, char *out_name)
 {
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index c5a50952fd0..46b3e85fdbb 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -638,6 +638,19 @@ int uclass_next_device_check(struct udevice **devp)
return device_probe(*devp);
 }
 
+int uclass_get_count(void)
+{
+   const struct uclass *uc;
+   int count = 0;
+
+   if (gd->dm_root) {
+   list_for_each_entry(uc, gd->uclass_root, sibling_node)
+   count++;
+   }
+
+   return count;
+}
+
 int uclass_first_device_drvdata(enum uclass_id id, ulong driver_data,
struct udevice **devp)
 {
diff --git a/include/dm/device.h b/include/dm/device.h
index 3028d002ab0..68e783ea409 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -593,7 +593,7 @@ int device_get_child(const struct udevice *parent, int 
index,
 struct udevice **devp);
 
 /**
- * device_get_child_count() - Get the available child count of a device
+ * device_get_child_count() - Get the child count of a device
  *
  * Returns the number of children to a device.
  *
@@ -601,6 +601,15 @@ int device_get_child(const struct udevice *parent, int 
index,
  */
 int device_get_child_count(const struct udevice *parent);
 
+/**
+ * device_get_decendent_count() - Get the total number of decendents of a 
device
+ *
+ * Returns the total number of decendents, including all children
+ *
+ * @parent:Parent device to check
+ */
+int device_get_decendent_count(const struct udevice *parent);
+
 /**
  * device_find_child_by_seq() - Find a child device based on a sequence
  *
diff --git a/include/dm/root.h b/include/dm/root.h
index 42510b106ab..780f269db65 100644
--- a/include/dm/root.h
+++ b/include/dm/root.h
@@ -131,4 +131,12 @@ int dm_remove_devices_flags(uint flags);
 static inline int dm_remove_devices_flags(uint flags) { return 0; }
 #endif
 
+/**
+ * dm_get_stats() - Get some stats for driver mode
+ *
+ * @device_countp: Returns total number of devices that are bound
+ * @uclass_countp: Returns total number of uclasses in use
+ */
+void dm_get_stats(int *device_countp, int *uclass_countp);
+
 #endif
diff --git a/include/dm/uclass-internal.h b/include/dm/uclass-internal.h
index 57c664c6daa..c71d8b1de45 100644
--- a/include/dm/uclass-internal.h
+++ b/include/dm/uclass-internal.h
@@ -294,6 +294,13 @@ int uclass_pre_remove_device(struct udevice *dev);
 static inline int uclass_pre_remove_device(struct udevice *dev) { return 0; }
 #endif
 
+/**
+ * uclass_get_count() - Get the number of uclasses
+ *
+ * Returns the number of uclasses instantiated in driver model
+ */
+int uclass_get_count(void);
+
 /**
  * uclass_find() - Find uclass by its id
  *
diff --git a/test/dm/core.c b/test/dm/core.c
index c9a760c..c76dfdb1651 100644
--- a/test/dm/core.c
+++ b/test/dm/core.c
@@ -307,11 +307,15 @@ static int dm_test_lifecycle(struct unit_test_state *uts)
 {
int op_count[DM_TEST_OP_COUNT];
struct udevice *dev, *test_dev;
+   int start_dev_count, start_uc_count;
+   int dev_count, uc_count;
int pingret;
int ret;
 
memcpy(op_count, dm_testdrv_op_count, sizeof(op_count));
 
+   dm_get_stats(_dev_count, 

[PATCH 05/31] fdt: Drop SPL_BUILD macro

2021-10-31 Thread Simon Glass
This old macro is not needed anymore since we can use IS_ENABLED() now.
Drop it.

Signed-off-by: Simon Glass 
---

 drivers/serial/serial-uclass.c | 3 ++-
 include/fdtdec.h   | 6 --
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 30d44214d7d..96a1cb65ba2 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -104,7 +104,8 @@ static void serial_find_console_or_panic(void)
}
}
}
-   if (!SPL_BUILD || !CONFIG_IS_ENABLED(OF_CONTROL) || !blob) {
+   if (!IS_ENABLED(CONFIG_SPL_BUILD) || !CONFIG_IS_ENABLED(OF_CONTROL) ||
+   !blob) {
/*
 * Try to use CONFIG_CONS_INDEX if available (it is numbered
 * from 1!).
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 68a36f10583..24992baed8b 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -49,12 +49,6 @@ struct fdt_memory {
 
 struct bd_info;
 
-#ifdef CONFIG_SPL_BUILD
-#define SPL_BUILD  1
-#else
-#define SPL_BUILD  0
-#endif
-
 /*
  * Information about a resource. start is the first address of the resource
  * and end is the last address (inclusive). The length of the resource will
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 04/31] stddef: Avoid warning with clang with offsetof()

2021-10-31 Thread Simon Glass
Some bright sparks have decided that a cast on a constant cannot be a
constant, so offsetof() produces this warning on clang-10:

include/intel_gnvs.h:113:1: error: static_assert expression is not an
integral constant expression
check_member(acpi_global_nvs, unused2, GNVS_CHROMEOS_ACPI_OFFSET);
^
include/linux/kernel.h:284:2: note: expanded from macro 'check_member'
offsetof(struct structure, member) == (offset), \
^~
include/linux/stddef.h:20:32: note: expanded from macro 'offsetof'
^
include/intel_gnvs.h:113:1: note: cast that performs the conversions of
a reinterpret_cast is ot allowed in a constant expression
include/linux/stddef.h:20:33: note: expanded from macro 'offsetof'

Fix it by using the compiler built-in version, if available.

Signed-off-by: Simon Glass 
---

 include/linux/stddef.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/linux/stddef.h b/include/linux/stddef.h
index c540f6100d4..a7f546fdfe5 100644
--- a/include/linux/stddef.h
+++ b/include/linux/stddef.h
@@ -1,6 +1,8 @@
 #ifndef _LINUX_STDDEF_H
 #define _LINUX_STDDEF_H
 
+#include 
+
 #undef NULL
 #if defined(__cplusplus)
 #define NULL 0
@@ -14,7 +16,11 @@
 
 #ifndef __CHECKER__
 #undef offsetof
-#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
+#ifdef __compiler_offsetof
+#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
+#else
+#define offsetof(TYPE, MEMBER) ((size_t)&((TYPE *)0)->MEMBER)
+#endif
 #endif
 
 #endif
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 02/31] kconfig: Add support for conditional values

2021-10-31 Thread Simon Glass
At present if an optional Kconfig value needs to be used it must be
bracketed by #ifdef. For example, with this Kconfig setup:

config WIBBLE
bool "Support wibbles, the world needs more wibbles"

config WIBBLE_ADDR
hex "Address of the wibble"
depends on WIBBLE

then the following code must be used:

 #ifdef CONFIG_WIBBLE
 static void handle_wibble(void)
 {
int val = CONFIG_WIBBLE_ADDR;

...
 }
 #endif

 static void init_machine()
 {
 ...
 #ifdef CONFIG_WIBBLE
handle_wibble();
 #endif
 }

Add a new IF_ENABLED_INT() to help with this. So now it is possible to
write, without #ifdefs:

 static void handle_wibble(void)
 {
int val = IF_ENABLED_INT(CONFIG_WIBBLE, CONFIG_WIBBLE_ADDR);

...
 }

 static void init_machine()
 {
 ...
 if (IS_ENABLED(CONFIG_WIBBLE))
handle_wibble();
 }

The value will be 0 if CONFIG_WIBBLE is not defined, and
CONFIG_WIBBLE_ADDR if it is. This allows us to reduce the use of #ifdef in
the code, ensuring that the compiler still checks the code even if it is
not ultimately used for a particular build.

Add a CONFIG_IF_ENABLED_INT() version as well.

Signed-off-by: Simon Glass 
---

 include/linux/kconfig.h  | 18 ++
 scripts/config_whitelist.txt |  1 +
 2 files changed, 19 insertions(+)

diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
index a1d1a298426..119c698a158 100644
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -59,6 +59,18 @@
  */
 #define CONFIG_VAL(option)  config_val(option)
 
+/* This use a similar mechanism to config_enabled() above */
+#define config_opt_enabled(cfg, opt_cfg) _config_opt_enabled(cfg, opt_cfg)
+#define _config_opt_enabled(cfg_val, opt_value) \
+   __config_opt_enabled(__ARG_PLACEHOLDER_##cfg_val, opt_value)
+#define __config_opt_enabled(arg1_or_junk, arg2) \
+   ___config_opt_enabled(arg1_or_junk arg2, 0)
+#define ___config_opt_enabled(__ignored, val, ...) val
+
+/* Evaluates to 0 if option is not defined, int_option if it is defined */
+#define IF_ENABLED_INT(option, int_option) \
+   config_opt_enabled(option, int_option)
+
 /*
  * Count number of arguments to a variadic macro. Currently only need
  * it for 1, 2 or 3 arguments.
@@ -113,5 +125,11 @@
 #define CONFIG_IS_ENABLED(option, ...) \
__concat(__CONFIG_IS_ENABLED_, __count_args(option, ##__VA_ARGS__)) 
(option, ##__VA_ARGS__)
 
+/*
+ * Evaluates to 0 if SPL_/TPL_/option is not defined, SPL_/TPL_int_option if it
+ * is defined
+ */
+#define CONFIG_IF_ENABLED_INT(option, int_option) \
+   CONFIG_IS_ENABLED(option, (CONFIG_VAL(int_option)), (0))
 
 #endif /* __LINUX_KCONFIG_H */
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 022a27288c9..f9d9f4a9cfe 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -609,6 +609,7 @@ CONFIG_ICS307_REFCLK_HZ
 CONFIG_IDE_PREINIT
 CONFIG_IDE_RESET
 CONFIG_IDE_SWAP_IO
+CONFIG_IF_ENABLED_INT
 CONFIG_IMA
 CONFIG_IMX
 CONFIG_IMX6_PWM_PER_CLK
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 01/31] Makefile: Correct TPL rule for OF_REAL

2021-10-31 Thread Simon Glass
Correct an error in the tpl-dtb parameter to binman. At present the TPL
rule follows SPL but this is not correct, if TPL uses of-platdata, for
example.

Fixes: f99cbe4e867 ("fdt: Update Makefile rules with the new OF_REAL Kconfig")
Signed-off-by: Simon Glass 
---

 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 09a5cea8cb8..d256a3cdc33 100644
--- a/Makefile
+++ b/Makefile
@@ -1309,7 +1309,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if 
$(BINMAN_DEBUG),-D) \
-a spl-bss-pad=$(if $(CONFIG_SPL_SEPARATE_BSS),,1) \
-a tpl-bss-pad=$(if $(CONFIG_TPL_SEPARATE_BSS),,1) \
-a spl-dtb=$(CONFIG_SPL_OF_REAL) \
-   -a tpl-dtb=$(CONFIG_SPL_OF_REAL) \
+   -a tpl-dtb=$(CONFIG_TPL_OF_REAL) \
$(BINMAN_$(@F))
 
 OBJCOPYFLAGS_u-boot.ldr.hex := -I binary -O ihex
-- 
2.33.1.1089.g2158813163f-goog



[PATCH 00/31] passage: Define a standard for firmware data flow

2021-10-31 Thread Simon Glass


This series adds a standard way of passing information between different
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 rely
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 that
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, 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 memory
footprint as well as complex data flow) and be easy enough to implement 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 to
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 possible
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/073b5c156f222c69a98b8ebcaa563d1ff10eb217


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 

Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION

2021-10-31 Thread Simon Glass
Hi Takahiro,

On Sun, 31 Oct 2021 at 18:36, AKASHI Takahiro
 wrote:
>
> On Sat, Oct 30, 2021 at 07:45:14AM +0200, Heinrich Schuchardt wrote:
> >
> >
> > Am 29. Oktober 2021 23:17:56 MESZ schrieb Simon Glass :
> > >Hi,
> > >
> > >On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt  
> > >wrote:
> > >>
> > >>
> > >>
> > >> Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takahiro 
> > >> :
> > >> >On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote:
> > >> >>
> > >> >>
> > >> >> > I agree with Heinrich that we are better to leave BLK as it is, both
> > >> >> > in name and meaning. I think maybe I am missing the gist of your
> > >> >> > argument.
> > >> >> >
> > >> >> > If we use UCLASS_PART, for example, can we have that refer to both 
> > >> >> > s/w
> > >> >> > and h/w partitions, as Herinch seems to allude to below? What would
> > >> >> > the picture look like the, and would it get us closer to agreement?
> > >> >>
> > >> >> In the driver model:
> > >> >>
> > >> >> A UCLASS is a class of drivers that share the same interface.
> > >> >> A UDEVICE is a logical device that belongs to exactly one UCLASS and 
> > >> >> is
> > >> >> accessed through this UCLASS's interface.
> > >> >
> > >> >Please be careful about "accessed through" which is a quite confusing
> > >> >expression. I don't always agree with this view.
> > >> >
> > >> >> A hardware partition is an object that exposes only a single interface
> > >> >> for block IO.
> > >> >>
> > >> >> A software partition is an object that may expose two interfaces: one
> > >> >> for block IO, the other for file IO.
> > >> >
> > >> >Are you talking about UEFI world or U-Boot?
> > >> >Definitely, a hw partitions can provide a file system
> > >> >if you want.
> > >> >It's a matter of usage.
> > >> >
> > >> >I remember that we had some discussion about whether block devices
> > >> >on UEFI system should always have a (sw) partition table or not.
> > >> >But it is a different topic.
> > >> >
> > >> >> The UEFI model does not have a problem with this because on a handle 
> > >> >> you
> > >> >> can install as many different protocols as you wish. But U-Boot's 
> > >> >> driver
> > >> >> model only allows a single interface per device. Up to now U-Boot has
> > >> >> overcome this limitation by creating child devices for the extra 
> > >> >> interfaces.
> > >> >
> > >> >> We have the following logical levels:
> > >> >>
> > >> >> Controller  | Block device | Software Partition| File system
> > >> >> +--+---+
> > >> >> NVMe Drive  | Namespace| Partition 1..n| FAT, EXT4
> > >> >> ATA Controller  | ATA-Drive|   |
> > >> >> SCSI Controller | LUN  |   |
> > >> >> MMC Controller  | HW-Partition |   |
> > >> >> MMC Controller  | SD-Card  |   |
> > >> >> USB-Node| USB-Drive|   |
> > >> >>
> > >> >> In the device tree this could be modeled as:
> > >> >>
> > >> >> |-- Controller (UCLASS_CTRL)
> > >> >> | |-- Block device / HW Partition (UCLASS_BLK)(A)
> > >> >> | | |-- Partition table (UCLASS_PARTITION_TABLE)  (B)
> > >> >> | |   |-- Software Partition (UCLASS_BLK)
> > >> >> | | |-- File system (UCLASS_FS)
> > >> >> | |
> > >> >> | |-- Block device (UCLASS_BLK)
> > >> >> |   |-- File system (UCLASS_FS)
> > >> >
> > >> >I don't know why we expect PARTITION_TABLE and FS to appear in DM tree.
> > >> >What is the benefit?
> > >> >(A) and (B) always have 1:1 relationship.
> > >>
> > >> No. You can have a bare device without a partition table.
> > >
> > >I can have a DOS partition that covers the whole device, without a
> > >partition table. This is supported in U-Boot and Linux.
> > >
> > >>
> > >> We have several partition table drivers: DOS, GPT, OSX, ... . In future 
> > >> we should also have one for the NOR Flash partitions. All of these 
> > >> drivers have a common interface. As the partition table type is mostly 
> > >> independent of the block device type we should use separate uclasses and 
> > >> udevices.
> > >>
> > >> >I also remember that you claimed that not all efi objects(handles and
> > >> >protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corresponding
> > >> >U-Boot counterparts in our 2019 discussion.
> > >> >
> > >> >If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TABLE,
> > >> >which should support other type of hw partitions as well?
> > >>
> > >> How hardware partitions, LUNs, ATA drives are enumerated is specific to 
> > >> the type of controller while the type of software partition table  is 
> > >> independent of the block device.
> > >>
> > >> >
> > >> >|-- eMMC controller (UCLASS_MMC)
> > >> >| |-- eMMC device1 / Physical media (UCLASS_HW_PARTITION_TABLE?)
> > >> >|   |-- Block device / HW Partition:user data (UCLASS_BLK)
> > >> >|   | |-- Partition table (UCLASS_PARTITION_TABLE)
> > >> >|   |   |-- Software Partition (UCLASS_BLK)
> > >> >| 

Re: [PATCH v3] video: fix positioning in TrueType console

2021-10-31 Thread Simon Glass
Hi Anatolij,

On Sun, 31 Oct 2021 at 18:23, Anatolij Gustschin  wrote:
>
> Hi Simon,
>
> On Sun, 31 Oct 2021 17:46:56 -0600
> Simon Glass s...@chromium.org wrote:
> ...
> > > v3:
> > > Use floating point only with the TrueType console.
> > > v2:
> > > Adjust hash values in tests
> > > ---
> > >  drivers/video/console_truetype.c | 27 ---
> > >  include/video_console.h  |  4 
> > >  test/dm/video.c  |  6 +++---
> > >  3 files changed, 27 insertions(+), 10 deletions(-)
> >
> > What commit is this based on, please? I don't seem to be able to apply it.
>
> there is another patch:
>
>  
> http://patchwork.ozlabs.org/project/uboot/patch/20200930225935.256667-1-xypron.g...@gmx.de/
>
> After applying it first, this v3 patch can be applied and building then works:
>
>  https://source.denx.de/u-boot/custodians/u-boot-video/-/commits/oct28

OK thank you.

Tested on: sandbox
Tested-by: Simon Glass 

Will await comments on my comments.

Regards,
Simon


Re: Please pull u-boot-dm

2021-10-31 Thread Tom Rini
On Sun, Oct 31, 2021 at 01:40:48PM -0600, Simon Glass wrote:

> Hi Tom,
> 
> https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/9692
> 
> 
> The following changes since commit 50bff6a6f86669a8652e2bf271eeb04f77911274:
> 
>   Merge branch '2021-10-31-assorted-platform-updates' (2021-10-31
> 12:21:12 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git tags/dm-pull-boo21
> 
> for you to fetch changes up to b55881ddb455af31b64038cf3b67f781909971cc:
> 
>   bootstage: Add SPL support (2021-10-31 12:26:44 -0600)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION

2021-10-31 Thread AKASHI Takahiro
On Sat, Oct 30, 2021 at 07:45:14AM +0200, Heinrich Schuchardt wrote:
> 
> 
> Am 29. Oktober 2021 23:17:56 MESZ schrieb Simon Glass :
> >Hi,
> >
> >On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt  wrote:
> >>
> >>
> >>
> >> Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takahiro 
> >> :
> >> >On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote:
> >> >>
> >> >>
> >> >> > I agree with Heinrich that we are better to leave BLK as it is, both
> >> >> > in name and meaning. I think maybe I am missing the gist of your
> >> >> > argument.
> >> >> >
> >> >> > If we use UCLASS_PART, for example, can we have that refer to both s/w
> >> >> > and h/w partitions, as Herinch seems to allude to below? What would
> >> >> > the picture look like the, and would it get us closer to agreement?
> >> >>
> >> >> In the driver model:
> >> >>
> >> >> A UCLASS is a class of drivers that share the same interface.
> >> >> A UDEVICE is a logical device that belongs to exactly one UCLASS and is
> >> >> accessed through this UCLASS's interface.
> >> >
> >> >Please be careful about "accessed through" which is a quite confusing
> >> >expression. I don't always agree with this view.
> >> >
> >> >> A hardware partition is an object that exposes only a single interface
> >> >> for block IO.
> >> >>
> >> >> A software partition is an object that may expose two interfaces: one
> >> >> for block IO, the other for file IO.
> >> >
> >> >Are you talking about UEFI world or U-Boot?
> >> >Definitely, a hw partitions can provide a file system
> >> >if you want.
> >> >It's a matter of usage.
> >> >
> >> >I remember that we had some discussion about whether block devices
> >> >on UEFI system should always have a (sw) partition table or not.
> >> >But it is a different topic.
> >> >
> >> >> The UEFI model does not have a problem with this because on a handle you
> >> >> can install as many different protocols as you wish. But U-Boot's driver
> >> >> model only allows a single interface per device. Up to now U-Boot has
> >> >> overcome this limitation by creating child devices for the extra 
> >> >> interfaces.
> >> >
> >> >> We have the following logical levels:
> >> >>
> >> >> Controller  | Block device | Software Partition| File system
> >> >> +--+---+
> >> >> NVMe Drive  | Namespace| Partition 1..n| FAT, EXT4
> >> >> ATA Controller  | ATA-Drive|   |
> >> >> SCSI Controller | LUN  |   |
> >> >> MMC Controller  | HW-Partition |   |
> >> >> MMC Controller  | SD-Card  |   |
> >> >> USB-Node| USB-Drive|   |
> >> >>
> >> >> In the device tree this could be modeled as:
> >> >>
> >> >> |-- Controller (UCLASS_CTRL)
> >> >> | |-- Block device / HW Partition (UCLASS_BLK)(A)
> >> >> | | |-- Partition table (UCLASS_PARTITION_TABLE)  (B)
> >> >> | |   |-- Software Partition (UCLASS_BLK)
> >> >> | | |-- File system (UCLASS_FS)
> >> >> | |
> >> >> | |-- Block device (UCLASS_BLK)
> >> >> |   |-- File system (UCLASS_FS)
> >> >
> >> >I don't know why we expect PARTITION_TABLE and FS to appear in DM tree.
> >> >What is the benefit?
> >> >(A) and (B) always have 1:1 relationship.
> >>
> >> No. You can have a bare device without a partition table.
> >
> >I can have a DOS partition that covers the whole device, without a
> >partition table. This is supported in U-Boot and Linux.
> >
> >>
> >> We have several partition table drivers: DOS, GPT, OSX, ... . In future we 
> >> should also have one for the NOR Flash partitions. All of these drivers 
> >> have a common interface. As the partition table type is mostly independent 
> >> of the block device type we should use separate uclasses and udevices.
> >>
> >> >I also remember that you claimed that not all efi objects(handles and
> >> >protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corresponding
> >> >U-Boot counterparts in our 2019 discussion.
> >> >
> >> >If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TABLE,
> >> >which should support other type of hw partitions as well?
> >>
> >> How hardware partitions, LUNs, ATA drives are enumerated is specific to 
> >> the type of controller while the type of software partition table  is 
> >> independent of the block device.
> >>
> >> >
> >> >|-- eMMC controller (UCLASS_MMC)
> >> >| |-- eMMC device1 / Physical media (UCLASS_HW_PARTITION_TABLE?)
> >> >|   |-- Block device / HW Partition:user data (UCLASS_BLK)
> >> >|   | |-- Partition table (UCLASS_PARTITION_TABLE)
> >> >|   |   |-- Software Partition (UCLASS_BLK)
> >> >|   | |-- File system (UCLASS_FS)
> >> >|   |
> >> >|   |-- Block device / HW Partition:boot0 (UCLASS_BLK)
> >> >|   |-- Block device / HW Partition:boot1 (UCLASS_BLK)
> >> >  ...
> >> >| |-- eMMC device2 / Physical media (UCLASS_HW_PARTITION_TABLE?)
> >> >
> >> >|-- scsi controller (UCLASS_SCSI)
> >> >| |-- scsi disk / Physical 

Re: [PATCH v3] video: fix positioning in TrueType console

2021-10-31 Thread Anatolij Gustschin
Hi Simon,

On Sun, 31 Oct 2021 17:46:56 -0600
Simon Glass s...@chromium.org wrote:
...
> > v3:
> > Use floating point only with the TrueType console.
> > v2:
> > Adjust hash values in tests
> > ---
> >  drivers/video/console_truetype.c | 27 ---
> >  include/video_console.h  |  4 
> >  test/dm/video.c  |  6 +++---
> >  3 files changed, 27 insertions(+), 10 deletions(-)  
> 
> What commit is this based on, please? I don't seem to be able to apply it.

there is another patch:

 
http://patchwork.ozlabs.org/project/uboot/patch/20200930225935.256667-1-xypron.g...@gmx.de/

After applying it first, this v3 patch can be applied and building then works:

 https://source.denx.de/u-boot/custodians/u-boot-video/-/commits/oct28

--
Anatolij


Re: [PATCH v1] arm: xea: Modify board code to generate single binary u-boot

2021-10-31 Thread Simon Glass
Hi Lukasz,

On Sat, 23 Oct 2021 at 09:04, Lukasz Majewski  wrote:
>
> This change provides the possibility to build XEA (imx287 based) board
> U-Boot as a single binary (without support for CONFIG_SPL_FRAMEWORK).
>
> The generated u-boot.sb can be used in the factory environment to for
> example perform initial setup or HW testing.
>
> It can be used with 'uuu' utility
> (SDPS: boot -f /srv/tftp/xea/u-boot.sb)
>
> In the configs/imx28_xea_defconfig one needs to disable following configs:

Something is missing here.

>
> The board_init_ll() is used in arch/arm/cpu/arm926ejs/mxs/start.S, which
> is utilized when CONFIG_SPL_FRAMEWORK is disabled.
>
> However, when it is enabled the arch/arm/cpu/arm926ejs/start.S is used,
> which requires the lowlevel_init() function.
>
> Signed-off-by: Lukasz Majewski 
>
> ---
>
>  board/liebherr/xea/spl_xea.c | 7 +++
>  board/liebherr/xea/xea.c | 2 +-
>  2 files changed, 8 insertions(+), 1 deletion(-)

Could you add a Kconifig to control this feature and add something to
the board docs?

Regards,
Simon


Re: [PATCH 1/6 v4] serial: qcom: add support for GENI serial driver

2021-10-31 Thread Simon Glass
Hi Dzmitry,

On Fri, 15 Oct 2021 at 10:22, Dzmitry Sankouski  wrote:
>
>
> чт, 14 окт. 2021 г. в 18:10, Simon Glass :
>>
>> Hi Dzmitry,
>>
>> On Fri, 8 Oct 2021 at 00:46, Dzmitry Sankouski  wrote:
>> >
>> > Generic Interface (GENI) Serial Engine (SE) based uart
>> > can be found on newer qualcomm SOCs, starting from SDM845.
>> > Tested on Samsung SM-G9600(starqltechn)
>> > by chain-loading u-boot with stock bootloader.
>> >
>> > Signed-off-by: Dzmitry Sankouski 
>> > Cc: Ramon Fried 
>> > Cc: Tom Rini 
>> > ---
>> > Changes for v2:
>> > - change functions return type to void, where possible
>> > - remove '.' from summary line
>> > Changes for v3:
>> > - move function open brace on new line
>> > - use tab between define name and value
>> > - define: wrap expression with braces, remove braces from constants
>> > Changes for v4:
>> > - add linux/delay.h header
>> >
>> >  MAINTAINERS   |   1 +
>> >  .../serial/msm-geni-serial.txt|   6 +
>> >  drivers/serial/Kconfig|  17 +
>> >  drivers/serial/Makefile   |   1 +
>> >  drivers/serial/serial_msm_geni.c  | 603 ++
>> >  5 files changed, 628 insertions(+)
>> >  create mode 100644 doc/device-tree-bindings/serial/msm-geni-serial.txt
>> >  create mode 100644 drivers/serial/serial_msm_geni.c
>>
>> Reviewed-by: Simon Glass 
>>
>> Some nits below
>>
>> >
>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> > index 776ff703b9..52ddc99cda 100644
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -390,6 +390,7 @@ F:  drivers/gpio/msm_gpio.c
>> >  F: drivers/mmc/msm_sdhci.c
>> >  F: drivers/phy/msm8916-usbh-phy.c
>> >  F: drivers/serial/serial_msm.c
>> > +F: drivers/serial/serial_msm_geni.c
>> >  F: drivers/smem/msm_smem.c
>> >  F: drivers/usb/host/ehci-msm.c
>> >
>> > diff --git a/doc/device-tree-bindings/serial/msm-geni-serial.txt 
>> > b/doc/device-tree-bindings/serial/msm-geni-serial.txt
>> > new file mode 100644
>> > index 00..9eadc2561b
>> > --- /dev/null
>> > +++ b/doc/device-tree-bindings/serial/msm-geni-serial.txt
>> > @@ -0,0 +1,6 @@
>> > +Qualcomm GENI UART
>> > +
>> > +Required properties:
>> > +- compatible: must be "qcom,msm-geni-uart"
>> > +- reg: start address and size of the registers
>> > +- clock: interface clock (must accept baudrate as a frequency)
>> > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
>> > index 93348c0929..b420a5720d 100644
>> > --- a/drivers/serial/Kconfig
>> > +++ b/drivers/serial/Kconfig
>> > @@ -278,6 +278,14 @@ config DEBUG_UART_S5P
>> >   will need to provide parameters to make this work. The driver 
>> > will
>> >   be available until the real driver-model serial is running.
>> >
>> > +config DEBUG_UART_MSM_GENI
>>
>> Do you need this? Most drivers just use the existing DEBUG_UART Kconfig.
>
>
> Documentation for CONFIG_DEBUG_UART says:
> `- Enable the CONFIG for your UART to tell it to provide this interface
>(e.g. CONFIG_DEBUG_UART_NS16550)`
> Debug functionality is controlled by chip specific CONFIG_DEBUG_UART_*.
> So no serial driver uses  plain DEBUG_UART for adding debug functionality.

Ah yes. Well I suppose I am allow to forgot something I wrote 6 years ago.

For my own information, the reason is basically because we can only
have one debug UART, but can have multiple UART drivers with driver
model. So we need to select which to use as a debug UART.

It is a bit unfortunate, since in the vast majority of cases, we only
have a single UART driver in use.

Regards,
Simon


Re: [PATCH] image-board: fix wrong implementation ram disk address setup from cmdline

2021-10-31 Thread Simon Glass
Hi Artem,

On Fri, 15 Oct 2021 at 23:19, Artem Lapkin  wrote:
>
> Problem
>
> Wrong implementation logic: ramdisk cmdline image address always ignored!
> Next block { rd_addr = hextoul(select, NULL) } unusable for raw initrd.
>
> We have unbootable raw initrd images because, select_ramdisk for raw
> initrd images ignore submited select addr and setup rd_datap value to 0
>
> Come-from: 
> https://patchwork.ozlabs.org/project/uboot/patch/20211015101501.4091141-1-...@khadas.com/
>
> Signed-off-by: Artem Lapkin 
> ---
>  common/image-board.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Fixes: f33a2c1bd0f ("image: Remove #ifdefs from select_ramdisk()")

(I believe, can you confirm?)

Reviewed-by: Simon Glass 


>
> diff --git a/common/image-board.c b/common/image-board.c
> index e7660352e9..e7063016ef 100644
> --- a/common/image-board.c
> +++ b/common/image-board.c
> @@ -333,7 +333,7 @@ static int select_ramdisk(bootm_headers_t *images, const 
> char *select, u8 arch,
>
> if (select) {
> ulong default_addr;
> -   bool done = true;
> +   bool done = false;
>
> if (CONFIG_IS_ENABLED(FIT)) {
> /*
> @@ -351,13 +351,13 @@ static int select_ramdisk(bootm_headers_t *images, 
> const char *select, u8 arch,
>_uname_config)) {
> debug("*  ramdisk: config '%s' from image at 
> 0x%08lx\n",
>   fit_uname_config, rd_addr);
> +   done = true;
> } else if (fit_parse_subimage(select, default_addr,
>   _addr,
>   _uname_ramdisk)) {
> debug("*  ramdisk: subimage '%s' from image 
> at 0x%08lx\n",
>   fit_uname_ramdisk, rd_addr);
> -   } else {
> -   done = false;
> +   done = true;
> }
> }
> if (!done) {
> --
> 2.25.1
>


Re: [PATCH v3 0/5] Fix compiler warnings for 32-bit ARM

2021-10-31 Thread Simon Glass
Hi,

On Sun, 1 Aug 2021 at 18:56, Simon Glass  wrote:
>
> These were noticed when building sandbox on a Raspberry Pi 400, which uses
> 32-bit linux.
>
> To make this work, I enabled CONFIG_HOST_32BIT in 'make menuconfig'. It
> would be nice if that were automatic, since we have the logic already in
> arch/sandbox/config.mk
>
> So this series adds that.
>
> It also fixes the unicode warnings of the form:
>
> /usr/bin/ld: warning: arch/sandbox/cpu/start.o uses 2-byte wchar_t yet the
> output is to use 4-byte wchar_t; use of wchar_t values across objects
> may fail
>
> as suggested by Heinrich.
>
> Changes in v3:
> - Mention the link to the new upstream patch
> - Change some things EFI things missed (or new since) last time
> - Use 'bitness' instead of 'bit'
> - Add a new patch to change non-EFI occurences
>
> Changes in v2:
> - Add new patch to reduce checkpatch unicode-string spam
> - Drop patches previously applied
> - Put all the packages in gcc.rst
>
> Joe Perches (1):
>   checkpatch: Support wide strings
>
> Simon Glass (4):
>   efi: Use 16-bit unicode strings
>   sandbox: Detect the host bit size automatically
>   treewide: Use 16-bit unicode strings
>   RFC: treewide: Drop -fshort-char

Any word on this series please?

Regards,
Simon


>
>  Makefile  |  13 ++-
>  arch/arm/config.mk|   2 +-
>  arch/sandbox/Kconfig  |  13 ++-
>  arch/x86/config.mk|   2 +-
>  arch/x86/cpu/Makefile |   2 +-
>  arch/x86/lib/Makefile |   6 +-
>  cmd/efidebug.c|  12 +-
>  include/efi_loader.h  |   2 +-
>  include/efi_selftest.h|   4 +-
>  lib/efi/Makefile  |   4 +-
>  lib/efi_loader/efi_bootmgr.c  |  12 +-
>  lib/efi_loader/efi_boottime.c |   2 +-
>  lib/efi_loader/efi_capsule.c  |  20 ++--
>  lib/efi_loader/efi_helper.c   |   2 +-
>  lib/efi_loader/efi_image_loader.c |   8 +-
>  lib/efi_loader/efi_setup.c|  20 ++--
>  lib/efi_loader/efi_signature.c|   4 +-
>  lib/efi_loader/efi_string.c   |   2 +-
>  lib/efi_loader/efi_var_common.c   |  14 +--
>  lib/efi_loader/efi_variable.c |   6 +-
>  lib/efi_loader/efi_variable_tee.c |   2 +-
>  lib/efi_loader/helloworld.c   |  40 +++
>  lib/efi_selftest/dtbdump.c|  82 +++---
>  lib/efi_selftest/efi_selftest.c   |   2 +-
>  lib/efi_selftest/efi_selftest_block_device.c  |   6 +-
>  lib/efi_selftest/efi_selftest_devicepath.c|   2 +-
>  lib/efi_selftest/efi_selftest_exception.c |   2 +-
>  lib/efi_selftest/efi_selftest_fdt.c   |   6 +-
>  lib/efi_selftest/efi_selftest_hii.c   |   8 +-
>  lib/efi_selftest/efi_selftest_load_file.c |   4 +-
>  lib/efi_selftest/efi_selftest_loadimage.c |   4 +-
>  .../efi_selftest_miniapp_exception.c  |   4 +-
>  lib/efi_selftest/efi_selftest_miniapp_exit.c  |   8 +-
>  .../efi_selftest_miniapp_return.c |   2 +-
>  lib/efi_selftest/efi_selftest_reset.c |   2 +-
>  lib/efi_selftest/efi_selftest_textoutput.c|  12 +-
>  .../efi_selftest_unicode_collation.c  |  38 +++
>  lib/efi_selftest/efi_selftest_util.c  | 106 +-
>  lib/efi_selftest/efi_selftest_variables.c |  22 ++--
>  .../efi_selftest_variables_runtime.c  |   4 +-
>  lib/efi_selftest/initrddump.c |  60 +-
>  lib/lzma/Types.h  |   4 +-
>  scripts/checkpatch.pl |   7 +-
>  scripts/kconfig/Makefile  |  14 ++-
>  test/print_ut.c   |   2 +-
>  test/unicode_ut.c |  22 ++--
>  46 files changed, 320 insertions(+), 295 deletions(-)
>
> --
> 2.32.0.554.ge1b32706d8-goog
>


Re: [PATCH] image: fix select_ramdisk for raw initrd

2021-10-31 Thread Simon Glass
Hi Artem,

On Fri, 15 Oct 2021 at 04:15, Artem Lapkin  wrote:
>
> Problem
>
> We have unbootable raw initrd images because, select_ramdisk for raw
> initrd images ignore submited select addr and setup rd_datap value to 0
>
> Solution: setup rd_datap value from select
>
> Signed-off-by: Artem Lapkin 
> ---
>  common/image-board.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Do we need this patch as well as the other one? If so, can you combine them?

Also, is it possible to drop the assignment to rd_addr at the top of
the function?

>
> diff --git a/common/image-board.c b/common/image-board.c
> index e7660352e9..e3c6ea806a 100644
> --- a/common/image-board.c
> +++ b/common/image-board.c
> @@ -439,7 +439,7 @@ static int select_ramdisk(bootm_headers_t *images, const 
> char *select, u8 arch,
> end = strchr(select, ':');
> if (end) {
> *rd_lenp = hextoul(++end, NULL);
> -   *rd_datap = rd_addr;
> +   *rd_datap = hextoul(select, NULL);
> processed = true;
> }
> }
> --
> 2.25.1
>

Regards,
Simon


Re: [PATCH v3] video: fix positioning in TrueType console

2021-10-31 Thread Simon Glass
Hi Heinrich,

On Thu, 28 Oct 2021 at 12:01, Heinrich Schuchardt  wrote:
>
> With the patch accurate positioning is possible for mono-typed fonts:
>
> Fix the return value of console_truetype_putc_xy(). The current position
> is passed as parameter x. Some part of x represents a fractional pixel.
> The return value represents how much the character position must be
> advanced. This should only comprise the width of the current character and
> not the preexisting fractional pixel position.
>
> Characters are not square. As all characters of a mono-type font we can
> take the width of any character. 'W' as one of the widest ANSI characters
> provides also a good value for variable width fonts.
>
> The character width must be a float for TrueType.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v3:
> Use floating point only with the TrueType console.
> v2:
> Adjust hash values in tests
> ---
>  drivers/video/console_truetype.c | 27 ---
>  include/video_console.h  |  4 
>  test/dm/video.c  |  6 +++---
>  3 files changed, 27 insertions(+), 10 deletions(-)

What commit is this based on, please? I don't seem to be able to apply it.

Also, can we avoid using the double and use the fractional int value instead?

>
> diff --git a/drivers/video/console_truetype.c 
> b/drivers/video/console_truetype.c
> index d9ad52cce0..6fe238eab3 100644
> --- a/drivers/video/console_truetype.c
> +++ b/drivers/video/console_truetype.c
> @@ -209,7 +209,7 @@ static int console_truetype_putc_xy(struct udevice *dev, 
> uint x, uint y,
> int width_frac, linenum;
> struct pos_info *pos;
> u8 *bits, *data;
> -   int advance;
> +   int advance, kern_adv;
> void *start, *line, *sync_start, *sync_end;
> int row, ret;
> int bg_r, bg_g, bg_b;
> @@ -224,8 +224,11 @@ static int console_truetype_putc_xy(struct udevice *dev, 
> uint x, uint y,
>  * this character */
> xpos = frac(VID_TO_PIXEL((double)x));
> if (vc_priv->last_ch) {
> -   xpos += priv->scale * stbtt_GetCodepointKernAdvance(font,
> -   vc_priv->last_ch, ch);
> +   kern_adv = stbtt_GetCodepointKernAdvance(font, 
> vc_priv->last_ch,
> +ch);
> +   xpos += priv->scale * kern_adv;
> +   } else {
> +   kern_adv = 0;
> }
>
> /*
> @@ -236,8 +239,8 @@ static int console_truetype_putc_xy(struct udevice *dev, 
> uint x, uint y,
>  */
> x_shift = xpos - (double)tt_floor(xpos);
> xpos += advance * priv->scale;
> -   width_frac = (int)VID_TO_POS(xpos);
> -   if (x + width_frac >= vc_priv->xsize_frac)
> +   width_frac = VID_TO_POS(priv->scale * (kern_adv + advance));
> +   if (x + (int)VID_TO_POS(xpos) >= vc_priv->xsize_frac)
> return -EAGAIN;
>
> /* Write the current cursor position into history */
> @@ -585,20 +588,21 @@ static int console_truetype_probe(struct udevice *dev)
> struct udevice *vid_dev = dev->parent;
> struct video_priv *vid_priv = dev_get_uclass_priv(vid_dev);
> stbtt_fontinfo *font = >font;
> -   int ascent;
> +   int advance, ascent, lsb;
>
> debug("%s: start\n", __func__);
> +
> if (vid_priv->font_size)
> priv->font_size = vid_priv->font_size;
> else
> priv->font_size = CONFIG_CONSOLE_TRUETYPE_SIZE;
> +
> priv->font_data = console_truetype_find_font();
> if (!priv->font_data) {
> debug("%s: Could not find any fonts\n", __func__);
> return -EBFONT;
> }
>
> -   vc_priv->x_charsize = priv->font_size;
> vc_priv->y_charsize = priv->font_size;
> vc_priv->xstart_frac = VID_TO_POS(2);
> vc_priv->cols = vid_priv->xsize / priv->font_size;
> @@ -612,6 +616,15 @@ static int console_truetype_probe(struct udevice *dev)
>
> /* Pre-calculate some things we will need regularly */
> priv->scale = stbtt_ScaleForPixelHeight(font, priv->font_size);
> +
> +   /* Assuming that 'W' is the widest character */
> +   stbtt_GetCodepointHMetrics(font, 'W', , );
> +   advance += stbtt_GetCodepointKernAdvance(font, 'W', 'W');
> +   vc_priv->cols =
> +   (int)VID_TO_POS(vid_priv->xsize - 2) /
> +   (int)VID_TO_POS(advance * priv->scale);
> +   vc_priv->x_charsize = advance * priv->scale;
> +
> stbtt_GetFontVMetrics(font, , 0, 0);
> priv->baseline = (int)(ascent * priv->scale);
> debug("%s: ready\n", __func__);
> diff --git a/include/video_console.h b/include/video_console.h
> index 06b798ef10..c339dc3956 100644
> --- a/include/video_console.h
> +++ b/include/video_console.h
> @@ -68,7 +68,11 @@ struct vidconsole_priv {
> int ycur;
> int rows;
> int cols;
> 

Re: [PATCH 4/4] watchdog: Automatically register device with sysreset

2021-10-31 Thread Simon Glass
Hi Samuel,

On Sun, 22 Aug 2021 at 14:41, Samuel Holland  wrote:
>
> Add an option to automatically register the first watchdog device with
> the wdt_reboot driver for use with sysreset. This allows sysreset to be
> a drop-in replacement for platform-specific watchdog reset code, without
> needing any device tree changes.
>
> Signed-off-by: Samuel Holland 
> ---
>
>  drivers/sysreset/Kconfig |  7 +++
>  drivers/sysreset/sysreset_watchdog.c | 24 
>  drivers/watchdog/wdt-uclass.c|  5 +
>  include/sysreset.h   | 14 ++
>  4 files changed, 50 insertions(+)

This is a bit odd, but I suppose it is OK.

Reviewed-by: Simon Glass 

>
> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> index fdc858ccbac..49354b1b27a 100644
> --- a/drivers/sysreset/Kconfig
> +++ b/drivers/sysreset/Kconfig
> @@ -119,6 +119,13 @@ config SYSRESET_WATCHDOG
> help
>   Reboot support for generic watchdog reset.
>
> +config SYSRESET_WATCHDOG_AUTO
> +   bool "Automatically register first watchdog with sysreset"
> +   depends on SYSRESET_WATCHDOG
> +   help
> + If enabled, the first watchdog (as selected by the watchdog uclass)
> + will automatically be registered with the watchdog reboot driver.
> +
>  config SYSRESET_RESETCTL
> bool "Enable support for reset controller reboot driver"
> select DM_RESET
> diff --git a/drivers/sysreset/sysreset_watchdog.c 
> b/drivers/sysreset/sysreset_watchdog.c
> index b723f5647cd..35efcac59dd 100644
> --- a/drivers/sysreset/sysreset_watchdog.c
> +++ b/drivers/sysreset/sysreset_watchdog.c
> @@ -5,7 +5,9 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -57,3 +59,25 @@ U_BOOT_DRIVER(wdt_reboot) = {
> .plat_auto  = sizeof(struct wdt_reboot_plat),
> .ops = _reboot_ops,
>  };
> +
> +#if IS_ENABLED(CONFIG_SYSRESET_WATCHDOG_AUTO)
> +int sysreset_register_wdt(struct udevice *dev)

Could you pass in plat here instead of allocating it? You could add it
to wdt-uclass.c as some private data for the uclass...

> +{
> +   struct wdt_reboot_plat *plat = malloc(sizeof(*plat));
> +   int ret;
> +
> +   if (!plat)
> +   return -ENOMEM;
> +
> +   plat->wdt = dev;
> +
> +   ret = device_bind(dev, DM_DRIVER_GET(wdt_reboot),
> + dev->name, plat, ofnode_null(), NULL);
> +   if (ret) {
> +   free(plat);
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +#endif
> diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
> index 17334dbda6c..3170ef9d945 100644
> --- a/drivers/watchdog/wdt-uclass.c
> +++ b/drivers/watchdog/wdt-uclass.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -53,6 +54,10 @@ int initr_watchdog(void)
> 4 * reset_period) / 4;
> }
>
> +   ret = sysreset_register_wdt(gd->watchdog_dev);
> +   if (ret)
> +   printf("WDT:   Failed to register sysreset\n");
> +
> if (!IS_ENABLED(CONFIG_WATCHDOG_AUTOSTART)) {
> printf("WDT:   Not starting\n");
> return 0;
> diff --git a/include/sysreset.h b/include/sysreset.h
> index 701e4f5c86e..ad45fe0db28 100644
> --- a/include/sysreset.h
> +++ b/include/sysreset.h
> @@ -118,4 +118,18 @@ void sysreset_walk_halt(enum sysreset_t type);
>   */
>  void reset_cpu(void);
>
> +/**
> + * sysreset_register_wdt() - register a watchdog for use with sysreset
> + *
> + * This registers the given watchdog timer to be used to reset the system.
> + *
> + * @dev:   WDT device
> + * @return:0 if OK, -errno if error
> + */
> +#if IS_ENABLED(CONFIG_SYSRESET_WATCHDOG_AUTO)
> +int sysreset_register_wdt(struct udevice *dev);
> +#else
> +static inline int sysreset_register_wdt(struct udevice *dev) { return 0; }
> +#endif
> +
>  #endif
> --
> 2.31.1
>

Regards,
Simon


Re: [PATCH 2/2] sandbox: fix sandbox_wdt_expire_now()

2021-10-31 Thread Simon Glass
On Thu, 28 Oct 2021 at 04:16, Heinrich Schuchardt
 wrote:
>
> With CONFIG_SYSRESET_WATCHDOG=y the sandbox can use a watchdog based system
> reset.
>
> To make this work calling sandbox_wdt_expire_now() must lead to a reset.
>
> With this change we can test the development suggested in
>
>   [PATCH 0/4] Improved sysreset/watchdog uclass integration
>   https://lists.denx.de/pipermail/u-boot/2021-August/458656.html
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/watchdog/sandbox_wdt.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

watchdog-based


Re: [PATCH 3/4] sysreset: watchdog: Move watchdog reference to plat data

2021-10-31 Thread Simon Glass
On Thu, 28 Oct 2021 at 05:18, Heinrich Schuchardt
 wrote:
>
> On 8/22/21 22:41, Samuel Holland wrote:
> > Currently, the wdt_reboot driver always gets its watchdog device
> > reference from an OF node. This prevents selecting a watchdog at
> > runtime. Move the watchdog device reference to the plat data, so
> > the driver can be bound with the reference pre-provided. The
> > reference will still be acquired from the OF node if it is not
> > already provided.
> >
> > Signed-off-by: Samuel Holland 
>
> Reviewed-by: Heinrich Schuchardt 

Reviewed-by: Simon Glass 


Re: [PATCH 1/2] test/dm: fix watchdog test

2021-10-31 Thread Simon Glass
On Thu, 28 Oct 2021 at 04:16, Heinrich Schuchardt
 wrote:
>
> Avoid a build failure for CONFIG_WDT_GPIO=n.
>
> We need this setting to test watchdog based system reset.

watchdog-based

>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  test/dm/wdt.c | 4 
>  1 file changed, 4 insertions(+)

Reviewed-by: Simon Glass 

>
> diff --git a/test/dm/wdt.c b/test/dm/wdt.c
> index ee615f0e14..07a8eb0e7a 100644
> --- a/test/dm/wdt.c
> +++ b/test/dm/wdt.c
> @@ -44,6 +44,7 @@ static int dm_test_wdt_base(struct unit_test_state *uts)
>  }
>  DM_TEST(dm_test_wdt_base, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
>
> +#ifdef CONFIG_WDT_GPIO
>  static int dm_test_wdt_gpio(struct unit_test_state *uts)
>  {
> /*
> @@ -75,6 +76,7 @@ static int dm_test_wdt_gpio(struct unit_test_state *uts)
> return 0;
>  }
>  DM_TEST(dm_test_wdt_gpio, UT_TESTF_SCAN_FDT);
> +#endif
>
>  static int dm_test_wdt_watchdog_reset(struct unit_test_state *uts)
>  {
> @@ -86,9 +88,11 @@ static int dm_test_wdt_watchdog_reset(struct 
> unit_test_state *uts)
> uint reset_count;
> int val;
>
> +#ifdef CONFIG_WDT_GPIO

The #ifdef is unfortunate but I believe it is needed due to
DM_DRIVER_GET. You could get by name perhaps, or just get the first
device?

> ut_assertok(uclass_get_device_by_driver(UCLASS_WDT,
> DM_DRIVER_GET(wdt_gpio), 
> _wdt));
> ut_assertnonnull(gpio_wdt);
> +#endif
> ut_assertok(uclass_get_device_by_driver(UCLASS_WDT,
> DM_DRIVER_GET(wdt_sandbox), 
> _wdt));
> ut_assertnonnull(sandbox_wdt);
> --
> 2.32.0
>

Regards,
Simon


Re: [BUG] buildman does not check signature of toolchain

2021-10-31 Thread Simon Glass
Hi Heinrich,

On Wed, 27 Oct 2021 at 08:23, Heinrich Schuchardt
 wrote:
>
> On 10/27/21 16:05, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Tue, 26 Oct 2021 at 13:43, Heinrich Schuchardt
> >  wrote:
> >>
> >> Downloading binaries and executing without checking the authenticity is
> >> at least unwise.
> >>
> >> When binman downloads GCC it should also download and verify the GPG
> >> signatures.
> >>
> >> Additionally binman could hold a list of the SHA256 hashes of all
> >> binaries in question for a further check.
> >
> > Buildman? Yes that sounds like a nice feature. Did you hit a problem,
> > or just come up with this idea? You could try the new issue tracker!
>
> tools/buildman/toolchain.py
>
> I have seen this script downloading binaries and executing them on my
> machine without verification. This makes me feel insecure.

This should only happen with --fetch-arch but if you see it happening
without that, there is some kind of bug.

>
> test/run invokes buildman.
>
> The same is true for tools/docker/Dockerfile. As Docker does not use its
> own kernel you should avoid running untrusted binaries in a container.

OK I will leave this as an exercise for the reader.

Regards,
Simon


Re: [BUG] Spurious error in Gitlab CI for sandbox_spl test.py

2021-10-31 Thread Simon Glass
Hi Heinrich,

On Wed, 27 Oct 2021 at 23:17, Heinrich Schuchardt  wrote:
>
> Hello Tom,
>
> we have some trouble with Gitlab CI:
>
> In https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/342220
>
> sandbox:  +   sandbox_spl
> +/usr/bin/ld: /tmp/u-boot-spl.Z4D5y0.ltrans0.ltrans.o: in function
> `dm_setup_inst.lto_priv.0':
> +drivers/core/root.c:134: undefined reference to
> `_u_boot_list_2_udevice_2_root'
> +/usr/bin/ld:
> /tmp/u-boot-spl.Z4D5y0.ltrans0.ltrans.o:(.u_boot_list_2_uclass_2_irq+0x10):
> undefined reference to `_u_boot_list_2_udevice_2_irq_sbox'
> +/usr/bin/ld:
> /tmp/u-boot-spl.Z4D5y0.ltrans0.ltrans.o:(.u_boot_list_2_uclass_2_irq+0x18):
> undefined reference to `_u_boot_list_2_udevice_2_irq_sbox'
>
> Repeating the job showed no error:
>
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/342252

This seems to be in the code generated by dtoc. Specifically the
dt-device.c file appears to be empty, but the dt-uclass.c file is not.
There is some weird code in Makefile.spl to try to deal with changing
from OF_PLATDATA_INST to !OF_PLATDATA_INST. I suspect there is
something wrong with it, but I'm not sure what, For one thing
u-boot-spl-old-platdata_c is not needed now. The parallel rule (look
for &:) might need a look too.

Regards,
Simon


Re: [PATCH v2 02/41] Makefile: Allow LTO to be disabled for a build

2021-10-31 Thread Simon Glass
Hi Tom,

On Wed, 27 Oct 2021 at 07:13, Tom Rini  wrote:
>
> On Wed, Oct 27, 2021 at 02:21:17PM +0200, Heinrich Schuchardt wrote:
> >
> >
> > On 10/27/21 10:50, Ilias Apalodimas wrote:
> > > Hi Simon
> > >
> > > How does this patch related to the standard boot series? Shouldn't
> > > this be a completely separate patch?
> > >
> > > Thanks
> > > /Ilias
> > >
> > > On Sun, 24 Oct 2021 at 02:26, Simon Glass  wrote:
> > > >
> > > > LTO (Link-Time Optimisation) is an very useful feature which can
> > > > significantly reduce the size of U-Boot binaries. So far it has been
> > > > made available for selected ARM boards and sandbox.
> > > >
> > > > However, incremental builds are much slower when LTO is used. For 
> > > > example,
> > > > an incremental build of sandbox takes 2.1 seconds on my machine, but 6.7
> > > > seconds with LTO enabled.
> > > >
> > > > Add a LTO_BUILD=n parameter to the build, so it can be disabled during
> > > > development if needed, for faster builds.
> > > >
> > > > Add some documentation about LTO while we are here.
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > ---
> > > >
> > > > (no changes since v1)
> > > >
> > > >   Makefile   | 18 +-
> > > >   arch/arm/config.mk |  4 ++--
> > > >   arch/arm/include/asm/global_data.h |  2 +-
> > > >   doc/build/gcc.rst  | 17 +
> > > >   4 files changed, 33 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/Makefile b/Makefile
> > > > index b79b2319ff6..7057723e046 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -434,6 +434,9 @@ KBUILD_CFLAGS   += -fshort-wchar 
> > > > -fno-strict-aliasing
> > > >   KBUILD_AFLAGS   := -D__ASSEMBLY__
> > > >   KBUILD_LDFLAGS  :=
> > > >
> > > > +# Set this to "n" use of LTO for this build, e.g. LTO_BUILD=n
> > > > +LTO_BUILD  ?= y
> >
> > This does not allow LTO_BUILD=y to enable LTO for CONFIG_LTO=n.
>
> I don't understand why we need this patch at all.  If you want to
> disable LTO, disable LTO.  Yes, LTO makes linking take longer which can
> be annoying on iterative development.  I have a few different "HACK: DO
> NOT PUSH:  ..." things I git am at the start of a branch, depending on
> needs.  You can just do that to drop "imply LTO" from the SANDBOX stanza
> in arch/Kconfig.  We do not need a whole thing around a CONFIG option
> that can be disabled in the defconfig, or local .config file even.
>

Cranky time.

Of course we don't *need* it. I could just buy a slower build machine
and type with two fingers. There are lots of ways to slow things down
and LTO is one of them. I change branches at least a dozen times a day
and am always trying things out from patchwork. I am sure others do
too. LTO dramatically slows down builds. Having a way to easily do
this from the build system saves time.

Regards,
Simon


Re: [PATCH v2 02/41] Makefile: Allow LTO to be disabled for a build

2021-10-31 Thread Simon Glass
Hi Heinrich,

On Wed, 27 Oct 2021 at 06:21, Heinrich Schuchardt
 wrote:
>
>
>
> On 10/27/21 10:50, Ilias Apalodimas wrote:
> > Hi Simon
> >
> > How does this patch related to the standard boot series? Shouldn't
> > this be a completely separate patch?

Probably, but I lose track of all the branches in progress,
particularly when things sit for a while.

> >
> > Thanks
> > /Ilias
> >
> > On Sun, 24 Oct 2021 at 02:26, Simon Glass  wrote:
> >>
> >> LTO (Link-Time Optimisation) is an very useful feature which can
> >> significantly reduce the size of U-Boot binaries. So far it has been
> >> made available for selected ARM boards and sandbox.
> >>
> >> However, incremental builds are much slower when LTO is used. For example,
> >> an incremental build of sandbox takes 2.1 seconds on my machine, but 6.7
> >> seconds with LTO enabled.
> >>
> >> Add a LTO_BUILD=n parameter to the build, so it can be disabled during
> >> development if needed, for faster builds.
> >>
> >> Add some documentation about LTO while we are here.
> >>
> >> Signed-off-by: Simon Glass 
> >> ---
> >>
> >> (no changes since v1)
> >>
> >>   Makefile   | 18 +-
> >>   arch/arm/config.mk |  4 ++--
> >>   arch/arm/include/asm/global_data.h |  2 +-
> >>   doc/build/gcc.rst  | 17 +
> >>   4 files changed, 33 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/Makefile b/Makefile
> >> index b79b2319ff6..7057723e046 100644
> >> --- a/Makefile
> >> +++ b/Makefile
> >> @@ -434,6 +434,9 @@ KBUILD_CFLAGS   += -fshort-wchar 
> >> -fno-strict-aliasing
> >>   KBUILD_AFLAGS   := -D__ASSEMBLY__
> >>   KBUILD_LDFLAGS  :=
> >>
> >> +# Set this to "n" use of LTO for this build, e.g. LTO_BUILD=n
> >> +LTO_BUILD  ?= y
>
> This does not allow LTO_BUILD=y to enable LTO for CONFIG_LTO=n.
>
> We should have something like
>
> LTO_CONFIG ?= $CONFIG_LTO

The CONFIG indicates that LTO is supported, so if we want to do that,
we could fix the problems with LTO for a board/arch and send a patch
to enable it. I think we want it enabled by default.

[..]

Regards

Simon


Re: (overlapping) lmb allocations during boot

2021-10-31 Thread Michael Walle

Am 2021-10-31 18:36, schrieb Mark Kettenis:

Date: Sun, 31 Oct 2021 16:19:56 +0100
From: Michael Walle 

..


>> > Unless CONFIG_EFI_LOADER is defined.  Then it relocates the spin table
>> > to memory allocated using efi_allocate_pages().  But that function
>> > only looks at the EFI memory map to figure out what memory is
>> > available.  So I suspect that it might hand out the same memory as
>> > lmb_alloc().  It all looks a bit broken to me...
>>
>> Yes, that is actually my code ;) The kontron_sl28 is the only
>> board which uses spin tables as far as I know. It doesn't support
>> PSCI; at least if you don't load a bl31 TF-A. Therefore, for SMP
>> it uses spin tables. The relocation code work arounds a problem
>> with the reserved EFI code, see [1].
>>
>> And yes, it actually is broken. But so might be every code which
>> is using the efi_allocate_pages(), no? LMB isn't global, but is
>> just initialized at different places. Like before a linux kernel
>> is booted or when you load a file (?). And everytime the whole
>> memory is added, and then different regions are carved out (see
>> above).
>
> Right.  So it mostly works because U-Boot either ends up using a code
> path where it uses LMB or a path where it ends up using the EFI memory
> map, but never both.  Except if it hits your layerscape code.
>
> I think the right way to solve this is to allocate the memory for the
> spin table through some other means and use efi_add_memory_map() to
> reserve that memory like what is done in board/raspberrypi/rpi/rpi.c.

Mh. I don't think this will work, just because lmb is quite stupid
and has just the three steps to carve out memory:
  (1) arch_lmb_reserve()
  (2) board_lmb_reserve()
  (3) boot_fdt_add_mem_rsv_regions()

(1) will carve out u-boot code and data (2) is usually not used and
(3) doesn't really work IMHO, because the reserved regions are added
much later in the bootm flow.

So what would "other means" be? I could allocate the memory somehow,
but how can I communicate that to lmb, so it would be excluded there.


It could be a simple:

  memalign(PAGE_SIZE, PAGE_SIZE);

This would allocate memory from the heap which should be excluded from
what lmb hands out.


Thanks, that was easy ;) Turns out the heap is between the stack and the
uboot code which is reserved by lmb (arch_lmb_reserve()).

-michael


[PATCH] board: kontron: sl28: add myself to ls1028a.dtsi maintainers

2021-10-31 Thread Michael Walle
I'd like to keep informed about ls1028a.dtsi changes. For now, there is
no top-level entry for any layerscape specific files. Instead, add the
file entry to my board MAINTAINERS file.

Signed-off-by: Michael Walle 
---
 board/kontron/sl28/MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/kontron/sl28/MAINTAINERS b/board/kontron/sl28/MAINTAINERS
index a7b0fbbdd1..6b24cba24f 100644
--- a/board/kontron/sl28/MAINTAINERS
+++ b/board/kontron/sl28/MAINTAINERS
@@ -1,6 +1,7 @@
 Kontron SMARC-sAL28 board
 M: Michael Walle 
 S: Maintained
+F: arch/arm/dts/fsl-ls1028a.dtsi
 F: arch/arm/dts/fsl-ls1028a-kontron-sl28-*
 F: board/kontron/sl28/
 F: configs/kontron_sl28_defconfig
-- 
2.30.2



[PATCH] get_maintainer.pl: add .get_maintainer.conf

2021-10-31 Thread Michael Walle
Since commit e57c7c5c4282 ("get_maintainer.pl: update from Linux kernel
v5.13-rc6") only the top level MAINTAINERS file is used. This is because
this commit (accidentally) disabled the search of MAINTAINERS files
(find_maintainer_files is set to 0 again). Before that, commit
b79372ae94fb ("scripts/get_maintainer.pl: enable find_maintainer_files")
explicitly enabled that feature. Nowadays, we also have to set
maintainer_path to a directory.

To fix it and enable recursive search of MAINTAINERS, create a
configuration file to set these two variables.

Signed-off-by: Michael Walle 
---
 .get_maintainer.conf | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 .get_maintainer.conf

diff --git a/.get_maintainer.conf b/.get_maintainer.conf
new file mode 100644
index 00..df595f5420
--- /dev/null
+++ b/.get_maintainer.conf
@@ -0,0 +1 @@
+--find-maintainer-files --maintainer-path=.
-- 
2.30.2



[PATCH] armv8: layerscape: use memalign() to allocate spintable code

2021-10-31 Thread Michael Walle
Don't use efi_allocate_pages(). The allocated memory isn't carved out of
the lmb allocations. The memory might then be allocated twice.
Particulary, this might happened with the fdt_high/initrd_high feature
which will relocate the fdt/ramdisk. This might then overlap with the
spin table.

Instead use memalign() which allocates on memory on the heap which is
correctly carved out by lmb.

Please note, that the memory is later reserved in the device tree as
well as in the EFI memory map in ft_fixup_cpu() (in
arch/arm/cpu/armv8/fsl-layerscape/fdt.c).

Signed-off-by: Michael Walle 
---
 arch/arm/cpu/armv8/fsl-layerscape/mp.c | 29 +-
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c 
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index 730d7663d0..d28ab26533 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -14,11 +14,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include "cpu.h"
 #include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -83,8 +84,7 @@ int fsl_layerscape_wake_seconday_cores(void)
int i, timeout = 10;
u64 *table;
 #ifdef CONFIG_EFI_LOADER
-   u64 reloc_addr = U32_MAX;
-   efi_status_t ret;
+   void *reloc_addr;
 #endif
 
 #ifdef COUNTER_FREQUENCY_REAL
@@ -102,27 +102,26 @@ int fsl_layerscape_wake_seconday_cores(void)
 * Keep this after the __real_cntfrq update, so we have it when we
 * copy the complete section here.
 */
-   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RESERVED_MEMORY_TYPE,
-efi_size_in_pages(secondary_boot_code_size),
-_addr);
-   if (ret == EFI_SUCCESS) {
-   debug("Relocating spin table from %llx to %llx (size %lx)\n",
- (u64)secondary_boot_code_start, reloc_addr,
+   reloc_addr = memalign(PAGE_SIZE,
+ round_up(secondary_boot_code_size, PAGE_SIZE));
+   if (reloc_addr) {
+   debug("Relocating spin table from %p to %p (size %lx)\n",
+ secondary_boot_code_start, reloc_addr,
  secondary_boot_code_size);
-   memcpy((void *)reloc_addr, secondary_boot_code_start,
+   memcpy(reloc_addr, secondary_boot_code_start,
   secondary_boot_code_size);
-   flush_dcache_range(reloc_addr,
-  reloc_addr + secondary_boot_code_size);
+   flush_dcache_range((unsigned long)reloc_addr,
+  (unsigned long)reloc_addr +
+ secondary_boot_code_size);
 
/* set new entry point for secondary cores */
-   secondary_boot_addr += (void *)reloc_addr -
+   secondary_boot_addr += reloc_addr -
   secondary_boot_code_start;
flush_dcache_range((unsigned long)_boot_addr,
   (unsigned long)_boot_addr + 8);
 
/* this will be used to reserve the memory */
-   secondary_boot_code_start = (void *)reloc_addr;
+   secondary_boot_code_start = reloc_addr;
}
 #endif
 
-- 
2.30.2



Re: [PATCH 1/3] net: dsa: Use true instead of 1 in the set_promisc() call

2021-10-31 Thread Vladimir Oltean
On Sat, Oct 30, 2021 at 04:31:48PM +0300, Ramon Fried wrote:
> > > > > Ping for apply?
> > > > I'll get to the patches today.
> > > > thanks for waking me up :)
> >
> > Why don't you apply patches immediately after reviewing them?
> It wouldn't make a difference. you were all working on the same file
> in code, If I would have applied bin's patches before yours, then you
> would need to rebase.
> simple as that. Also the time when I'm applying and when I'm reviewing
> is also meaningless because this problem would occur anyway.

I know, I was reacting to the 'thanks for waking me up' part.
Honestly I don't see the point of going through some patches, marking
them as reviewed, then waiting for 2 more weeks to apply them (or even
more in other cases). It slows down the process for a reason that I
can't see.

Maybe the thinking is along the lines of "I won't apply patches that
haven't marinated for long enough". But my patches (the ones conflicting
with Bin's) still had build warnings even after marinating for close to
one month (fixes for which I've sent just now). During that time, I had
also piled up a few non-critical fixes to those patches, but I wasn't
going to modify the patch set already in flight anyway, for fear of
waiting again for who knows how long. Incremental fixups are fine and
surely are a valid way of doing development too, so that argument kinda
falls off the table. What's left?

[PATCH] net: tsec: mark tsec_set_promisc() as __maybe_unused

2021-10-31 Thread Vladimir Oltean
Since the tsec driver supports both configurations with and without
DM_ETH, and since the eth_ops :: set_promisc() method is only provided
for DM_ETH, the implication is that builds with DM_ETH disabled will
result in a 'defined but not used' warning.

To silence those, mark the function as __maybe_unused.

Fixes: 79ba3435f43d ("net: tsec: add support for promiscuous mode")
Reported-by: Ramon Fried 
Signed-off-by: Vladimir Oltean 
---
 drivers/net/tsec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 4354753cab9c..64bb42b0c006 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -156,7 +156,7 @@ static int tsec_mcast_addr(struct udevice *dev, const u8 
*mcast_mac, int join)
return 0;
 }
 
-static int tsec_set_promisc(struct udevice *dev, bool enable)
+static int __maybe_unused tsec_set_promisc(struct udevice *dev, bool enable)
 {
struct tsec_private *priv = dev_get_priv(dev);
struct tsec __iomem *regs = priv->regs;
-- 
2.25.1



Re: [PATCH 5/5] arm: mvebu: Espressobin: Use new API for setting default env at runtime

2021-10-31 Thread Pali Rohár
On Thursday 28 October 2021 05:28:10 Marek Behún wrote:
> diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
> b/configs/mvebu_espressobin-88f3720_defconfig
> index 3a69954fcd..3dc6da04f8 100644
> --- a/configs/mvebu_espressobin-88f3720_defconfig
> +++ b/configs/mvebu_espressobin-88f3720_defconfig
> @@ -24,7 +24,6 @@ CONFIG_SYS_CONSOLE_INFO_QUIET=y
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_ARCH_EARLY_INIT_R=y
>  CONFIG_BOARD_EARLY_INIT_F=y
> -CONFIG_BOARD_LATE_INIT=y

This would not work. Detection of emmc is done in board_late_init()
function and cannot be done earlier as it depends on device
initialization. Also in this function is removal of emmc from DM if emmc
is not present.

>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_GPT=y


Please pull u-boot-dm

2021-10-31 Thread Simon Glass
Hi Tom,

https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/9692


The following changes since commit 50bff6a6f86669a8652e2bf271eeb04f77911274:

  Merge branch '2021-10-31-assorted-platform-updates' (2021-10-31
12:21:12 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-dm.git tags/dm-pull-boo21

for you to fetch changes up to b55881ddb455af31b64038cf3b67f781909971cc:

  bootstage: Add SPL support (2021-10-31 12:26:44 -0600)


Environment tidy-ups
patman 'postfix' support
fix binman test race condition causing a timeout error


Alistair Delva (1):
  x86: Fix linking u-boot with ld.lld

Hannu Lounento (1):
  image.h: make image_sign_info.fit point to const

Marek Behún (14):
  env: sf: Cosmetic fix in env_sf_init_addr()
  env: sf: Use ENV_VALID enum names instead of literals
  env: sf: Put ENV_INVALID into gd->env_valid on CRC failure
  env: nand: Put ENV_INVALID into gd->env_valid if default environment
  env: nvram: Let generic env_init() assign default environment
  env: nvram: Cosmetic fix in env_nvram_init()
  env: nowhere: Let generic env_init() assign default environment
  env: nowhere: Cosmetic fix
  env: flash: Let generic env_init() assign default environment
  env: flash: Cosmetic fix
  board: synquacer: developerbox: Don't set gd->env_addr to
default_environment
  board: freescale: various boards: Let env subsystem set gd->env_addr
  env: Always use char for default_environment
  env: Use static_assert() to check if default_environment is too large

Marek Vasut (1):
  bootstage: Add SPL support

Sean Anderson (1):
  patman: Add "postfix" support to patch subjects

Simon Glass (1):
  binman: Allow timeout to occur in the image or its section

Tom Rini (1):
  sandbox: Migrate ARCH_MAP_SYSMEM to Kconfig

 Makefile|  3 +++
 arch/sandbox/Kconfig|  3 +++
 arch/sandbox/config.mk  |  1 -
 arch/x86/cpu/cpu.c  |  2 +-
 board/Marvell/mvebu_armada-37xx/board.c |  2 +-
 board/freescale/ls1012afrdm/ls1012afrdm.c   |  4 
 board/freescale/ls1012aqds/ls1012aqds.c |  4 
 board/freescale/ls1012ardb/ls1012ardb.c |  4 
 board/freescale/ls1028a/ls1028a.c   |  4 
 board/freescale/ls1088a/ls1088a.c   |  4 
 board/freescale/ls2080aqds/ls2080aqds.c |  3 ---
 board/freescale/ls2080ardb/ls2080ardb.c |  3 ---
 board/freescale/lx2160a/lx2160a.c   |  3 ---
 board/siemens/iot2050/board.c   |  2 +-
 board/socionext/developerbox/developerbox.c |  2 --
 common/Kconfig.boot |  9 +
 common/image-fit-sig.c  |  2 +-
 common/init/board_init.c|  2 +-
 common/spl/spl.c|  2 +-
 env/common.c| 11 +++
 env/flash.c |  5 +
 env/nand.c  |  3 +--
 env/nowhere.c   |  5 ++---
 env/nvram.c |  7 +++
 env/sf.c|  7 +++
 include/bootstage.h |  2 +-
 include/env_default.h   | 10 --
 include/env_internal.h  |  4 ++--
 include/image.h |  2 +-
 tools/binman/ftest.py   |  3 +--
 tools/patman/README |  5 +
 tools/patman/func_test.py   |  6 --
 tools/patman/patchstream.py |  2 ++
 tools/patman/series.py  |  9 +++--
 tools/patman/test/test01.txt|  1 +
 35 files changed, 66 insertions(+), 75 deletions(-)

Regards,
SImon


Re: [u-boot-test-hooks PATCH 7/7] ellesmere: Add qemu rules

2021-10-31 Thread Tom Rini
On Sun, Oct 31, 2021 at 12:22:48PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Sun, 31 Oct 2021 at 10:57, Tom Rini  wrote:
> >
> > On Sat, Oct 30, 2021 at 12:25:39PM -0600, Simon Glass wrote:
> >
> > > Add some symlinks so that qemu can be used on ellesmere.
> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > >
> > >  bin/ellesmere/conf.qemu_arm_na | 1 +
> > >  bin/ellesmere/conf.qemu_arm_spl_na | 1 +
> > >  2 files changed, 2 insertions(+)
> > >  create mode 12 bin/ellesmere/conf.qemu_arm_na
> > >  create mode 12 bin/ellesmere/conf.qemu_arm_spl_na
> >
> > Alright, so I think the best use of the public u-boot-test-hooks is to
> > have first public CI used scripts (aka everything in {bin,py}/travis-ci)
> > and then we should move to having a reference directory.  It's not
> > useful to everyone for example to have symlinks like these here, for
> > your lab.  But it is very useful to have things like
> > bin/kea/conf.orangepi_pc_sjg-opi_pc which I used locally the other day
> > to make bin/bill-the-cat/conf.pine64_plus_na and I think everyone would
> > benefit from something like
> > bin/references/conf.sunxi_with_sdwire_and_digital-loggers so that anyone
> > else can figure out how to plumb in their own sunxi platform with sdwire
> > and then whatever reference they also need for power control, if not a
> > digital-loggers type "curl" solution.
> 
> OK. Can you apply the other patches? Then I'll check and try some renames.

I'll review the rest of the series soon, yes.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL] u-boot-usb/master

2021-10-31 Thread Tom Rini
On Sun, Oct 31, 2021 at 09:01:14AM +0100, Marek Vasut wrote:

> The following changes since commit a09929cc6c5a108f89e91660f37d745ed119385b:
> 
>   Merge https://source.denx.de/u-boot/custodians/u-boot-mmc (2021-10-29
> 08:27:32 -0400)
> 
> are available in the Git repository at:
> 
>   git://source.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 1833e68c4f05fe7b3e502135dbc0ffa09327850d:
> 
>   cmd: usb_mass_storage: Use part_get_info_by_dev_and_name_or_num
> (2021-10-30 22:55:00 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL] u-boot-sh/master

2021-10-31 Thread Tom Rini
On Sun, Oct 31, 2021 at 09:00:27AM +0100, Marek Vasut wrote:

> The following changes since commit a09929cc6c5a108f89e91660f37d745ed119385b:
> 
>   Merge https://source.denx.de/u-boot/custodians/u-boot-mmc (2021-10-29
> 08:27:32 -0400)
> 
> are available in the Git repository at:
> 
>   git://source.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to 16f1f0058974abd480a2c01d99a98179c667e828:
> 
>   ARM: rmobile: Rename r8a774a1_beacon_defconfig to rzg2_beacon_defconfig
> (2021-10-30 22:54:07 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [u-boot-test-hooks PATCH 7/7] ellesmere: Add qemu rules

2021-10-31 Thread Simon Glass
Hi Tom,

On Sun, 31 Oct 2021 at 10:57, Tom Rini  wrote:
>
> On Sat, Oct 30, 2021 at 12:25:39PM -0600, Simon Glass wrote:
>
> > Add some symlinks so that qemu can be used on ellesmere.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  bin/ellesmere/conf.qemu_arm_na | 1 +
> >  bin/ellesmere/conf.qemu_arm_spl_na | 1 +
> >  2 files changed, 2 insertions(+)
> >  create mode 12 bin/ellesmere/conf.qemu_arm_na
> >  create mode 12 bin/ellesmere/conf.qemu_arm_spl_na
>
> Alright, so I think the best use of the public u-boot-test-hooks is to
> have first public CI used scripts (aka everything in {bin,py}/travis-ci)
> and then we should move to having a reference directory.  It's not
> useful to everyone for example to have symlinks like these here, for
> your lab.  But it is very useful to have things like
> bin/kea/conf.orangepi_pc_sjg-opi_pc which I used locally the other day
> to make bin/bill-the-cat/conf.pine64_plus_na and I think everyone would
> benefit from something like
> bin/references/conf.sunxi_with_sdwire_and_digital-loggers so that anyone
> else can figure out how to plumb in their own sunxi platform with sdwire
> and then whatever reference they also need for power control, if not a
> digital-loggers type "curl" solution.

OK. Can you apply the other patches? Then I'll check and try some renames.

Regards,
Simon


[PATCH v5 2/2] arm: imx8m: add support for Advantech RSB-3720

2021-10-31 Thread Ying-Chun Liu
From: "Ying-Chun Liu (PaulLiu)" 

Add initial support for Advantech RSB-3720 board.
The initial support includes:
 - MMC
 - eMMC
 - I2C
 - FEC
 - Serial console

Signed-off-by: Darren Huang 
Signed-off-by: Kevin12.Chen 
Signed-off-by: Phill.Liu 
Signed-off-by: Tim Liang 
Signed-off-by: wei.zeng 
Signed-off-by: Ying-Chun Liu (PaulLiu) 
Cc: uboot-imx 
Cc: Peng Fan (OSS) 
---
v3: remove unnecessary code. move board code to board/advantech
v4: rebase to latest master branch
---
 arch/arm/dts/Makefile |3 +
 arch/arm/mach-imx/imx8m/Kconfig   |   15 +
 board/advantech/imx8mp_rsb3720a1/Kconfig  |   14 +
 board/advantech/imx8mp_rsb3720a1/MAINTAINERS  |7 +
 board/advantech/imx8mp_rsb3720a1/Makefile |   24 +
 .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c   |  213 ++
 .../imx8mp_rsb3720a1/imximage-8mp-lpddr4.cfg  |   11 +
 .../lpddr4_timing_rsb3720a1_4G.c  | 1848 
 .../lpddr4_timing_rsb3720a1_6G.c  | 1875 +
 board/advantech/imx8mp_rsb3720a1/spl.c|  263 +++
 configs/imx8mp_rsb3720a1_4G_defconfig |  163 ++
 configs/imx8mp_rsb3720a1_6G_defconfig |  164 ++
 include/configs/imx8mp_rsb3720.h  |  233 ++
 13 files changed, 4833 insertions(+)
 create mode 100644 board/advantech/imx8mp_rsb3720a1/Kconfig
 create mode 100644 board/advantech/imx8mp_rsb3720a1/MAINTAINERS
 create mode 100644 board/advantech/imx8mp_rsb3720a1/Makefile
 create mode 100644 board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c
 create mode 100644 board/advantech/imx8mp_rsb3720a1/imximage-8mp-lpddr4.cfg
 create mode 100644 
board/advantech/imx8mp_rsb3720a1/lpddr4_timing_rsb3720a1_4G.c
 create mode 100644 
board/advantech/imx8mp_rsb3720a1/lpddr4_timing_rsb3720a1_6G.c
 create mode 100644 board/advantech/imx8mp_rsb3720a1/spl.c
 create mode 100644 configs/imx8mp_rsb3720a1_4G_defconfig
 create mode 100644 configs/imx8mp_rsb3720a1_6G_defconfig
 create mode 100644 include/configs/imx8mp_rsb3720.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a88aecc5bd..37770e47f5 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1148,6 +1148,9 @@ dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
 dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb
 
 dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.dtb
+ifneq 
($(CONFIG_TARGET_IMX8MP_RSB3720A1_4G)$(CONFIG_TARGET_IMX8MP_RSB3720A1_6G),)
+dtb-y += imx8mp-rsb3720-a1.dtb
+endif
 
 dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += imx8mm-cl-iot-gate-optee.dtb
 
diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index 276b8bd974..6b870c1593 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -154,8 +154,23 @@ config TARGET_IMX8MM_CL_IOT_GATE_OPTEE
select IMX8MM
select SUPPORT_SPL
select IMX8M_LPDDR4
+
+config TARGET_IMX8MP_RSB3720A1_4G
+   bool "Support i.MX8MP RSB3720A1 4G"
+   select BINMAN
+   select IMX8MP
+   select SUPPORT_SPL
+   select IMX8M_LPDDR4
+
+config TARGET_IMX8MP_RSB3720A1_6G
+   bool "Support i.MX8MP RSB3720A1 6G"
+   select BINMAN
+   select IMX8MP
+   select SUPPORT_SPL
+   select IMX8M_LPDDR4
 endchoice
 
+source "board/advantech/imx8mp_rsb3720a1/Kconfig"
 source "board/beacon/imx8mm/Kconfig"
 source "board/beacon/imx8mn/Kconfig"
 source "board/compulab/imx8mm-cl-iot-gate/Kconfig"
diff --git a/board/advantech/imx8mp_rsb3720a1/Kconfig 
b/board/advantech/imx8mp_rsb3720a1/Kconfig
new file mode 100644
index 00..4486ed6d33
--- /dev/null
+++ b/board/advantech/imx8mp_rsb3720a1/Kconfig
@@ -0,0 +1,14 @@
+if TARGET_IMX8MP_RSB3720A1_4G || TARGET_IMX8MP_RSB3720A1_6G
+
+config SYS_BOARD
+   default "imx8mp_rsb3720a1"
+
+config SYS_VENDOR
+   default "advantech"
+
+config SYS_CONFIG_NAME
+   default "imx8mp_rsb3720"
+
+source "board/freescale/common/Kconfig"
+
+endif
diff --git a/board/advantech/imx8mp_rsb3720a1/MAINTAINERS 
b/board/advantech/imx8mp_rsb3720a1/MAINTAINERS
new file mode 100644
index 00..bc967af4f5
--- /dev/null
+++ b/board/advantech/imx8mp_rsb3720a1/MAINTAINERS
@@ -0,0 +1,7 @@
+i.MX8MP RSB3720 BOARD
+M: Ying-Chun Liu (PaulLiu) 
+S: Maintained
+F: board/advantech/imx8mp_rsb3720a1/
+F: include/configs/imx8mp_rsb3720a1.h
+F: configs/imx8mp_rsb3720a1_4G_defconfig
+F: configs/imx8mp_rsb3720a1_6G_defconfig
diff --git a/board/advantech/imx8mp_rsb3720a1/Makefile 
b/board/advantech/imx8mp_rsb3720a1/Makefile
new file mode 100644
index 00..ae5b8b83eb
--- /dev/null
+++ b/board/advantech/imx8mp_rsb3720a1/Makefile
@@ -0,0 +1,24 @@
+#
+# Copyright 2019 NXP
+# Copyright 2021 Linaro
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+
+ifdef CONFIG_TARGET_IMX8MP_RSB3720A1_6G
+obj-y += imx8mp_rsb3720a1.o
+
+ifdef CONFIG_SPL_BUILD
+obj-y += spl.o
+obj-$(CONFIG_IMX8M_LPDDR4) += lpddr4_timing_rsb3720a1_6G.o
+endif
+endif
+
+ifdef 

Re: (overlapping) lmb allocations during boot

2021-10-31 Thread Mark Kettenis
> Date: Sun, 31 Oct 2021 16:19:56 +0100
> From: Michael Walle 
> 
> Am 2021-10-31 13:51, schrieb Mark Kettenis:
> >> Date: Sun, 31 Oct 2021 13:04:40 +0100
> >> From: Michael Walle 
> >> 
> >> Am 2021-10-31 12:44, schrieb Mark Kettenis:
> >> >> Date: Sun, 31 Oct 2021 11:43:38 +0100
> >> >> From: Michael Walle 
> >> >>
> >> >> Hi,
> >> >>
> >> >> I sometimes see a corrupted initrd during kernel boot on my board
> >> >> (kontron_sl28). Debugging showed that in this case the spin table
> >> >> for the secondary CPUs overlaps with the lmb initrd allocations
> >> >> (initrd_high is set).
> >> >>
> >> >> I had a look at how the fdt and initrd are relocated (if enabled). In
> >> >> summary, they use lmb_alloc() which will first add all available
> >> >> memory
> >> >> and then carve out reserved regions. There are calls for arch
> >> >> (arch_lmb_reserve()) and board (board_lmb_reserve()) callbacks. The
> >> >> interesting thing is that, there is also code to carve out any
> >> >> reserved regions which were added to the fdt earlier
> >> >> (boot_fdt_add_mem_rsv_regions()). The problem here is, that the DT
> >> >> fixups,
> >> >> which might add the reserved regions are called just before jumping to
> >> >> linux. Thus both the allocation for the fdt (if fdt_high is set) and
> >> >> the ramdisk (if initrd_high is set) will ignore any reserved memory
> >> >> regions.
> >> >>
> >> >> Unfortunately, I don't see any good way to fix this. You'd need all
> >> >> the
> >> >> DT fixups before we can initialize the lmb. Also, I don't know if this
> >> >> will affect any other areas; probably I'm the only one, who reserves
> >> >> an
> >> >> area which is outside of the u-boot code and data segment.
> >> >>
> >> >> A hackish way would be to carve out the spin_table code in
> >> >> board_lmb_reserve(). But meh..
> >> >
> >> > The spin table is embedded in the u-boot binary itself isn't it?  But
> >> > the memory occupied by the u-boot should already be reserved...
> >> 
> >> Yes it is. As long as it doen't overlap with the 64k EFI code page.
> >> See below.
> > 
> > Yes, I saw the comment.  Which confuses me.  The overlap itself
> > shouldn't be a problem since both the spin table and the EFI runtime
> > code page should be preserved.  But I guess that the overlap causes
> > problems later on because attempting to reserve overlapping areas
> > fails?
> 
> TBH I don't remember the specifics anymore, my first try to fix this
> problem was here [1]. But the conclusion was that reserving 64k for
> the EFI alone would increase the binary size a lot. Thus Heinrich
> suggested to relocate the spin table code.

Ah right, the overlap is somewhat problematic since the EFI memory
types don't match.  Now that in itself isn't an issue as long as the
memory page attributes are the same.  As far as I can tell, both the
spin table and the EFI runtime services code would use EFI_MEMORY_WB,
so that would be fine.

> >> > Unless CONFIG_EFI_LOADER is defined.  Then it relocates the spin table
> >> > to memory allocated using efi_allocate_pages().  But that function
> >> > only looks at the EFI memory map to figure out what memory is
> >> > available.  So I suspect that it might hand out the same memory as
> >> > lmb_alloc().  It all looks a bit broken to me...
> >> 
> >> Yes, that is actually my code ;) The kontron_sl28 is the only
> >> board which uses spin tables as far as I know. It doesn't support
> >> PSCI; at least if you don't load a bl31 TF-A. Therefore, for SMP
> >> it uses spin tables. The relocation code work arounds a problem
> >> with the reserved EFI code, see [1].
> >> 
> >> And yes, it actually is broken. But so might be every code which
> >> is using the efi_allocate_pages(), no? LMB isn't global, but is
> >> just initialized at different places. Like before a linux kernel
> >> is booted or when you load a file (?). And everytime the whole
> >> memory is added, and then different regions are carved out (see
> >> above).
> > 
> > Right.  So it mostly works because U-Boot either ends up using a code
> > path where it uses LMB or a path where it ends up using the EFI memory
> > map, but never both.  Except if it hits your layerscape code.
> > 
> > I think the right way to solve this is to allocate the memory for the
> > spin table through some other means and use efi_add_memory_map() to
> > reserve that memory like what is done in board/raspberrypi/rpi/rpi.c.
> 
> Mh. I don't think this will work, just because lmb is quite stupid
> and has just the three steps to carve out memory:
>   (1) arch_lmb_reserve()
>   (2) board_lmb_reserve()
>   (3) boot_fdt_add_mem_rsv_regions()
> 
> (1) will carve out u-boot code and data (2) is usually not used and
> (3) doesn't really work IMHO, because the reserved regions are added
> much later in the bootm flow.
> 
> So what would "other means" be? I could allocate the memory somehow,
> but how can I communicate that to lmb, so it would be excluded there.

It could be a simple:

  

[PATCH] Azure: Move to windows-2019

2021-10-31 Thread Tom Rini
As per https://github.com/actions/virtual-environments/issues/4312 the
Windows-2016 environments are scheduled for deprecation and removal in
early 2022.  Move to windows-2019 now to avoid this (Visual Studio 2019
is included here, hence the tag naming scheme change).

Signed-off-by: Tom Rini 
---
 .azure-pipelines.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index b3794a956e86..41b34ea7de5a 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -1,5 +1,5 @@
 variables:
-  windows_vm: vs2017-win2016
+  windows_vm: windows-2019
   ubuntu_vm: ubuntu-18.04
   macos_vm: macOS-10.15
   ci_runner_image: trini/u-boot-gitlab-ci-runner:focal-20210921-05Oct2021
-- 
2.25.1



Re: [PATCH 2/2] Revert "arch: arm: use dt and UCLASS_SYSCON to get gic lpi details"

2021-10-31 Thread Michael Walle

Hi,

Am 2021-10-31 17:45, schrieb Z.Q. Hou:

-Original Message-
From: Marc Zyngier [mailto:m...@kernel.org]
Sent: 2021年10月29日 5:09
To: Michael Walle 
Cc: u-boot@lists.denx.de; Vladimir Oltean ; 
Z.Q. Hou

; Bharat Gooty ;
Rayagonda Kokatanur ; Simon Glass
; Priyanka Jain ; Tom Rini

Subject: Re: [PATCH 2/2] Revert "arch: arm: use dt and UCLASS_SYSCON 
to get gic

lpi details"

On Wed, 27 Oct 2021 17:54:54 +0100,
Michael Walle  wrote:
>
> Stop using the device tree as a source for ad-hoc information.
>
> This reverts commit 2ae7adc659f7fca9ea65df4318e5bca2b8274310.
>
> Signed-off-by: Michael Walle 
> ---
>  arch/arm/Kconfig|  2 -
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c | 27 +-
>  arch/arm/include/asm/gic-v3.h   |  4 +-
>  arch/arm/lib/gic-v3-its.c   | 66 +++--
>  4 files changed, 36 insertions(+), 63 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> 02f8306f15..86c1ebde05 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -82,8 +82,6 @@ config GICV3
>
>  config GIC_V3_ITS
>bool "ARM GICV3 ITS"
> -  select REGMAP
> -  select SYSCON
>select IRQ
>help
>  ARM GICV3 Interrupt translation service (ITS).
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index c0e100d21c..a08ed3f544 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c

Why is this FSL specific?

> @@ -41,11 +41,36 @@ DECLARE_GLOBAL_DATA_PTR;  #endif
>
>  #ifdef CONFIG_GIC_V3_ITS
> +#define PENDTABLE_MAX_SZ  ALIGN(BIT(ITS_MAX_LPI_NRBITS), SZ_64K)
> +#define PROPTABLE_MAX_SZ  ALIGN(BIT(ITS_MAX_LPI_NRBITS) / 8,
SZ_64K)

This looks completely wrong.

The pending table needs one bit per LPI, and the property table one 
byte per LPI.

Here, you have it the other way around.


It's a typo, will fix after the revert patch applied.


Please keep me on CC.

..
Finally, ITS_MAX_LPI_NRBITS is hardcoded to 16, while it can actually 
vary from 14

to 32 (and even further limited by some hypervisors), depending on the
implementation. Granted, this was broken before this patch, and in 
most cases,

64k is more than enough.



This is only for Layerscape platforms, so hardcoded to 16 bit works.


But why is this layerscape only? Can't we make it so it works on any
platform. If I understand Marc correctly, it should be possible.

..

> +  ret = gic_lpi_tables_init(gic_lpi_base, cpu_numcores());

This really should fetch the number of CPUs from the DT rather then 
some SoC

specific black magic...


Currently in most Layerscape platforms' DTS file there isn't cpu
nodes. On Layerscape platforms the implemented core number can be get
from GUT register.


So this would be the perfect time to actually sync the device
trees with linux.

-michael


Re: [u-boot-test-hooks PATCH 7/7] ellesmere: Add qemu rules

2021-10-31 Thread Tom Rini
On Sat, Oct 30, 2021 at 12:25:39PM -0600, Simon Glass wrote:

> Add some symlinks so that qemu can be used on ellesmere.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  bin/ellesmere/conf.qemu_arm_na | 1 +
>  bin/ellesmere/conf.qemu_arm_spl_na | 1 +
>  2 files changed, 2 insertions(+)
>  create mode 12 bin/ellesmere/conf.qemu_arm_na
>  create mode 12 bin/ellesmere/conf.qemu_arm_spl_na

Alright, so I think the best use of the public u-boot-test-hooks is to
have first public CI used scripts (aka everything in {bin,py}/travis-ci)
and then we should move to having a reference directory.  It's not
useful to everyone for example to have symlinks like these here, for
your lab.  But it is very useful to have things like
bin/kea/conf.orangepi_pc_sjg-opi_pc which I used locally the other day
to make bin/bill-the-cat/conf.pine64_plus_na and I think everyone would
benefit from something like
bin/references/conf.sunxi_with_sdwire_and_digital-loggers so that anyone
else can figure out how to plumb in their own sunxi platform with sdwire
and then whatever reference they also need for power control, if not a
digital-loggers type "curl" solution.

-- 
Tom


signature.asc
Description: PGP signature


RE: [PATCH 2/2] Revert "arch: arm: use dt and UCLASS_SYSCON to get gic lpi details"

2021-10-31 Thread Z.Q. Hou


> -Original Message-
> From: Marc Zyngier [mailto:m...@kernel.org]
> Sent: 2021年10月29日 5:09
> To: Michael Walle 
> Cc: u-boot@lists.denx.de; Vladimir Oltean ; Z.Q. Hou
> ; Bharat Gooty ;
> Rayagonda Kokatanur ; Simon Glass
> ; Priyanka Jain ; Tom Rini
> 
> Subject: Re: [PATCH 2/2] Revert "arch: arm: use dt and UCLASS_SYSCON to get 
> gic
> lpi details"
> 
> On Wed, 27 Oct 2021 17:54:54 +0100,
> Michael Walle  wrote:
> >
> > Stop using the device tree as a source for ad-hoc information.
> >
> > This reverts commit 2ae7adc659f7fca9ea65df4318e5bca2b8274310.
> >
> > Signed-off-by: Michael Walle 
> > ---
> >  arch/arm/Kconfig|  2 -
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c | 27 +-
> >  arch/arm/include/asm/gic-v3.h   |  4 +-
> >  arch/arm/lib/gic-v3-its.c   | 66 +++--
> >  4 files changed, 36 insertions(+), 63 deletions(-)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> > 02f8306f15..86c1ebde05 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -82,8 +82,6 @@ config GICV3
> >
> >  config GIC_V3_ITS
> > bool "ARM GICV3 ITS"
> > -   select REGMAP
> > -   select SYSCON
> > select IRQ
> > help
> >   ARM GICV3 Interrupt translation service (ITS).
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index c0e100d21c..a08ed3f544 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> 
> Why is this FSL specific?
> 
> > @@ -41,11 +41,36 @@ DECLARE_GLOBAL_DATA_PTR;  #endif
> >
> >  #ifdef CONFIG_GIC_V3_ITS
> > +#define PENDTABLE_MAX_SZ   ALIGN(BIT(ITS_MAX_LPI_NRBITS), SZ_64K)
> > +#define PROPTABLE_MAX_SZ   ALIGN(BIT(ITS_MAX_LPI_NRBITS) / 8,
> SZ_64K)
> 
> This looks completely wrong.
> 
> The pending table needs one bit per LPI, and the property table one byte per 
> LPI.
> Here, you have it the other way around.

It's a typo, will fix after the revert patch applied.

> Also, the property table alignment
> requirement is 4kB, not 64kB, and its size is defined as the maximum number of
> LPIs - 8192.

As in the accessor gic_lpi_tables_init() there isn't alignment operation for 
both property table and pending table, we have to pass a 64KB alignment 
address, even though the property table only requires 4KB alignment.

> 
> Finally, ITS_MAX_LPI_NRBITS is hardcoded to 16, while it can actually vary 
> from 14
> to 32 (and even further limited by some hypervisors), depending on the
> implementation. Granted, this was broken before this patch, and in most cases,
> 64k is more than enough.
>

This is only for Layerscape platforms, so hardcoded to 16 bit works.

> However, given that this defining the number of LPIs for the lifetime of the 
> system,
> it would be better to actually allocate what the HW advertises 
> (GICD_TYPER.IDbits,
> capped by GICD_TYPER.num_LPIs).
> 
> > +#define GIC_LPI_SIZE   ALIGN(cpu_numcores() * PENDTABLE_MAX_SZ 
> > + \
> > +   PROPTABLE_MAX_SZ, SZ_1M)
> 
> Why the 1MB alignment? There is no such requirement in the architecture (64kB
> for the pending tables, 4kB for the property table).

This is definition of the size instead of address, 1MB size alignment is to 
ensure we have enough space to do address alignment, perhaps 64KB should be 
enough.

> 
> > +static int fdt_add_resv_mem_gic_rd_tables(void *blob, u64 base,
> > +size_t size) {
> > +   int err;
> > +   struct fdt_memory gic_rd_tables;
> > +
> > +   gic_rd_tables.start = base;
> > +   gic_rd_tables.end = base + size - 1;
> > +   err = fdtdec_add_reserved_memory(blob, "gic-rd-tables", _rd_tables,
> > +NULL, 0, NULL, 0);
> > +   if (err < 0)
> > +   debug("%s: failed to add reserved memory: %d\n", __func__, err);
> > +
> > +   return err;
> > +}
> > +
> >  int ls_gic_rd_tables_init(void *blob)  {
> > +   u64 gic_lpi_base;
> > int ret;
> >
> > -   ret = gic_lpi_tables_init();
> > +   gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K);
> > +   ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base, GIC_LPI_SIZE);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = gic_lpi_tables_init(gic_lpi_base, cpu_numcores());
> 
> This really should fetch the number of CPUs from the DT rather then some SoC
> specific black magic...

Currently in most Layerscape platforms' DTS file there isn't cpu nodes. On 
Layerscape platforms the implemented core number can be get from GUT register.

Thanks,
Zhiqiang

> 
> > if (ret)
> > debug("%s: failed to init gic-lpi-tables\n", __func__);
> >
> > diff --git a/arch/arm/include/asm/gic-v3.h
> > b/arch/arm/include/asm/gic-v3.h index 35efec78c3..5131fabec4 100644
> > --- a/arch/arm/include/asm/gic-v3.h
> > +++ b/arch/arm/include/asm/gic-v3.h
> > @@ -127,9 +127,9 @@
> >  #define GIC_REDISTRIBUTOR_OFFSET 0x2
> >
> >  #ifdef CONFIG_GIC_V3_ITS
> > -int 

Re: [PATCH v4 6/7] arm: dts: apple: Add preliminary device trees

2021-10-31 Thread Tom Rini
On Sat, Oct 23, 2021 at 04:58:06PM +0200, Mark Kettenis wrote:

> Add preliminary device trees for the Apple M1 mini (2020) and
> Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
> the Apple M1 SoC are still being formalized and these device
> trees will be synchronized with the Linux kernel as needed.
> 
> The device trees in this commit are based on the initial Apple
> M1 device trees from Linux 5.13, nodes for dart, pcie, pinctrl,
> pmgr, usb based on bindings on track for inclusion in Linux
> 5.15 and 5.16 and nodes for i2c, mailbox, nvme, pmu, spmi and
> watchdog that don't have a proposed binding yet.
> 
> These device trees are provided as a reference only as U-Boot
> uses the device tree passed by the m1n1 bootloader.
> 
> Signed-off-by: Mark Kettenis 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4 3/7] arm: apple: Add initial support for Apple's M1 SoC

2021-10-31 Thread Tom Rini
On Sat, Oct 23, 2021 at 04:58:03PM +0200, Mark Kettenis wrote:

> Add support for Apple's M1 SoC that is used in "Apple Silicon"
> Macs.  This builds a basic U-Boot that can be used as a payload
> for the m1n1 boot loader being developed by the Asahi Linux
> project.
> 
> Signed-off-by: Mark Kettenis 
> Reviewed-by: Simon Glass 

After adding a MAINTAINERS entry, applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4 7/7] doc: board: apple: Add Apple M1 documentation

2021-10-31 Thread Tom Rini
On Sat, Oct 23, 2021 at 04:58:07PM +0200, Mark Kettenis wrote:

> Provide preliminary instructions on how to get U-Boot to run on
> Apple Silicon Macs.
> 
> Signed-off-by: Mark Kettenis 
> Reviewed-by: Simon Glass 

signature.asc
Description: PGP signature


Re: [PATCH v4 5/7] iommu: Add Apple DART driver

2021-10-31 Thread Tom Rini
On Sat, Oct 23, 2021 at 04:58:05PM +0200, Mark Kettenis wrote:

> The DART is an IOMMU that is used on Apple's M1 SoC.  This driver
> configures the DART such that it operates in bypass mode which is
> enough to support DMA for the USB3 ports integrated on the SoC.
> 
> Signed-off-by: Mark Kettenis 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4 4/7] serial: s5p: Add Apple M1 support

2021-10-31 Thread Tom Rini
On Sat, Oct 23, 2021 at 04:58:04PM +0200, Mark Kettenis wrote:

> Apple M1 SoCs include an S5L UART which is a variant of the S5P
> UART.  Add support for this variant and enable it by default
> on Apple SoCs.
> 
> Signed-off-by: Mark Kettenis 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4 2/7] test: Add tests for IOMMU uclass

2021-10-31 Thread Tom Rini
On Sat, Oct 23, 2021 at 04:58:02PM +0200, Mark Kettenis wrote:

> Add a set of tests for the IOMMU uclass.
> 
> Signed-off-by: Mark Kettenis 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4 1/7] iommu: Add IOMMU uclass

2021-10-31 Thread Tom Rini
On Sat, Oct 23, 2021 at 04:58:01PM +0200, Mark Kettenis wrote:

> This uclass is intended to manage IOMMUs on systems where the
> IOMMUs are not in bypass mode by default.  In that case U-Boot
> cannot ignore the IOMMUs if it wants to use devices that need
> to do DMA and sit behind such an IOMMU.
> 
> This initial IOMMU uclass implementation does not implement and
> device ops and is intended for IOMMUs that have a bypass mode
> that does not require address translation.  Support for IOMMUs
> that do require address translation is planned and device ops
> will be defined when support for such IOMMUs will be added.
> 
> Signed-off-by: Mark Kettenis 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/4] board: samsung: add support for Galaxy A series of 2017 (a5y17lte)

2021-10-31 Thread Tom Rini
On Sun, Oct 17, 2021 at 01:45:42PM +0300, Dzmitry Sankouski wrote:

> Samsung Galaxy A3, A5, A7 (2017) - middle class Samsung smartphones.
> U-boot can be used as chain-loaded bootloader to gain control
> on booting vanilla linux(and possibly others) kernels
> 
> Signed-off-by: Dzmitry Sankouski 
> Cc: Minkyu Kang 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/4] SoC: exynos: add support for exynos 78x0

2021-10-31 Thread Tom Rini
On Sun, Oct 17, 2021 at 01:45:41PM +0300, Dzmitry Sankouski wrote:

> Samsung Exynos 7880 \ 7870 - SoC for mainstream smartphones and tablets
> introduced on March 2017.
> Features:
> - 8 Cortex A53 cores
> - ARM Mali-T830 MP3 GPU
> - LTE Cat. 7 (7880) or 6 (7870) modem
> 
> Signed-off-by: Dzmitry Sankouski 
> Cc: Minkyu Kang 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/4] pinctrl: exynos: add support for multiple pin banks

2021-10-31 Thread Tom Rini
On Sun, Oct 17, 2021 at 01:45:40PM +0300, Dzmitry Sankouski wrote:

> Iterate all pin banks to find a pin
> 
> Signed-off-by: Dzmitry Sankouski 
> Cc: Minkyu Kang 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/4 v2] serial: samsung: add support for skip debug init in s5p

2021-10-31 Thread Tom Rini
On Sun, Oct 17, 2021 at 01:45:39PM +0300, Dzmitry Sankouski wrote:

> Signed-off-by: Dzmitry Sankouski 
> Cc: Minkyu Kang 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 6/6 v4] board: samsung: add Samsung Galaxy S9/S9+(SM-G96x0) board

2021-10-31 Thread Tom Rini
On Sun, Oct 17, 2021 at 01:44:32PM +0300, Dzmitry Sankouski wrote:

> Samsung S9 SM-G9600 - Snapdragon SDM845 version of the phone,
> for China \ Hong Kong markets.
> Has unlockable bootloader, unlike SM-G960U (American market version),
> which allows running u-boot as a chain-loaded bootloader.
> 
> Signed-off-by: Dzmitry Sankouski 
> Cc: Ramon Fried 
> Cc: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 5/6 v2] SoC: qcom: add support for SDM845

2021-10-31 Thread Tom Rini
On Sun, Oct 17, 2021 at 01:44:31PM +0300, Dzmitry Sankouski wrote:

> Hi-end qualcomm chip, introduced in late 2017.
> Mostly used in flagship phones and tablets of 2018.
> Features:
> - arm64 arch
> - total of 8 Kryo 385 Gold / Silver cores
> - Hexagon 685 DSP
> - Adreno 630 GPU
> 
> Tested only as second-stage bootloader.
> 
> Signed-off-by: Dzmitry Sankouski 
> Cc: Ramon Fried 
> Cc: Tom Rini 
> Cc: Stephan Gerhold 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/6] clocks: qcom: add clocks for SDM845 debug uart

2021-10-31 Thread Tom Rini
On Sun, Oct 17, 2021 at 01:44:30PM +0300, Dzmitry Sankouski wrote:

> Allows to change clock frequency of debug uart,
> thus supporting wide range of baudrates.
> Enable / disable functionality is not implemented yet.
> In most use cases of SDM845 (i.e. mobile phones and tablets)
> it's not needed, because qualcomm first stage bootloader leaves it
> initialized, and on the other hand there's no possibility to
> replace signed first stage bootloader with u-boot.
> 
> Signed-off-by: Dzmitry Sankouski 
> Cc: Ramon Fried 
> Cc: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/6 v2] pinctrl: qcom: add pinctrl and gpio drivers for SDM845 SoC

2021-10-31 Thread Tom Rini
On Sun, Oct 17, 2021 at 01:44:29PM +0300, Dzmitry Sankouski wrote:

> Signed-off-by: Dzmitry Sankouski 
> Cc: Ramon Fried 
> Cc: Tom Rini 
> Cc: Stephan Gerhold 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/6 v4] spmi: msm: add arbiter version 5 support

2021-10-31 Thread Tom Rini
On Sun, Oct 17, 2021 at 01:44:28PM +0300, Dzmitry Sankouski wrote:

> Currently driver supports only version 1 and 2.
> Version 5 has slightly different registers structure
> 
> Signed-off-by: Dzmitry Sankouski 
> Cc: Ramon Fried 
> Cc: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


  1   2   >