Question about extension board used in U-boot

[Ying-Chun Liu (PaulLiu)]

Hi all,


I have some questions about how to implement extension board usage.
My case is on imx8mm-cl-iot-gate. It can add three different types of
extension boards.
One of the extension boards is SPI extension which have 3 empty slots.
And you can add
some small boards onto it. One of them is a "TPM2" module.


My first question is if I want to use tpm2 in U-boot for measured boot.
How to implement this right? Currently I just modify the dts used by
U-boot to let it drive
the extension board. And let it drive the TPM. But it is not good for
upstreaming because
when other types of extension boards installed then it is not working.
Where to implement this? What is the best practice of this?


The second question is about extension manager.
I have read the extension.rst. I think I'll implement this anyway
because then
I can have a command to query what type of extension boards I have.
And if the extension board is the 3 slots one. I can then detect which
slot is the TPM.
I'll implement this anyway because the "extension" command is convenient
for users.
But it seems to me that it only solves the problem for Linux kernel.
It can apply a DTB Overlay to Linux DTB to let Linux knows we have that
extension board.
But it is too late for U-boot itself, right?


The third question is I'm also dong SystemReady IR certificate. That means
the dtb for Linux is directly provided by U-boot. We use U-boot dtb
directly to Linux
kernel. In this case, how to modify that dts dynamically to feed to the
Linux kernel by
the extension manager?
What is the best practice if I want to use U-boot dts for Linux in
implementation?


Thanks a lot.


Yours,
Paul




OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH V2] arm: mach-k3: am6_init: Prioritize MSMC traffic over DDR in NAVSS Northbridge

[Tom Rini]

On Wed, Sep 08, 2021 at 03:28:59PM -0500, Nishanth Menon wrote:

> From: Roger Quadros 
> 
> NB0 is bridge to SRAM and NB1 is bridge to DDR.
> 
> To ensure that SRAM transfers are not stalled due to delays during DDR
> refreshes, SRAM traffic should be higher priority (threadmap=2) than
> DDR traffic (threadmap=0).
> 
> This fixup is critical to provide deterministic access latency to
> MSMC from ICSSG, it applies to all AM65 silicon revisions and is due
> to incorrect reset values (has no erratum id) and statically setting
> things up should be done independent of usecases and board.
> 
> This specific style of Northbridge configuration is specific only to
> AM65x devices, follow-on K3 devices have different data prioritization
> schemes (ASEL and the like) and hence the fixup applies purely to
> AM65x.
> 
> Without this fix, ICSSG TX lock-ups due to delays in MSMC transfers in
> case of SR1 devices, on SR2 devices, lockups were not observed so far
> but high retry rates of ICSSG Ethernet (icssg-eth) and, thus, lower
> throughput.
> 
> Signed-off-by: Roger Quadros 
> Acked-by: Andrew F. Davis 
> Acked-by: Tomi Valkeinen 
> Acked-by: Benoit Parrot 
> [Jan: rebased, dropped used define, extended commit log]
> Signed-off-by: Jan Kiszka 
> [Nishanth: Provide relevant context in the commit message]
> Signed-off-by: Nishanth Menon

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 5/5] clk: ti: k3: Update driver to account for divider flags

[Tom Rini]

On Tue, Sep 07, 2021 at 05:16:58PM -0500, Dave Gerlach wrote:

> From: Suman Anna 
> 
> The K3 SoCs have some PLL output clocks (POSTDIV clocks) which in
> turn serve as inputs to other HSDIV output clocks. These clocks use
> the actual value to compute the divider clock rate, and need to be
> registered with the CLK_DIVIDER_ONE_BASED flags. The current k3-clk
> driver and data lacks the infrastructure to pass in divider flags.
> Update the driver and data to account for these divider flags.
> 
> Signed-off-by: Suman Anna 
> Signed-off-by: Dave Gerlach 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 4/5] clk: ti: k3-pll: Change DIV_CTRL programming to read-modify-write

[Tom Rini]

On Tue, Sep 07, 2021 at 05:16:57PM -0500, Dave Gerlach wrote:

> There are three different divider values in the DIV_CTRL register
> controlled by the k3-pll driver. Currently the ti_pll_clk_set_rate
> function writes the entire register when programming plld, even though
> plld only resides in the lower 6 bits.
> 
> Change the plld programming to read-modify-write to only affect the
> relevant bits for plld and to preserve the other two divider values
> present in the upper 16 bits, otherwise they will always get set to zero
> when programming plld.
> 
> Fixes: 0aa2930ca192 ("clk: add support for TI K3 SoC PLL")
> Signed-off-by: Dave Gerlach 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 3/5] arm: mach-k3: Add note to auto-generated files

[Tom Rini]

On Tue, Sep 07, 2021 at 05:16:56PM -0500, Dave Gerlach wrote:

> Add a note to the automatically generated clk-data and dev-data files
> for j721e and j7200 to indicate that they are in fact auto-generated and
> should not be hand edited.
> 
> Also adjust TI URL to use https instead of http and also add an empty
> line before first header inclusion.
> 
> Signed-off-by: Dave Gerlach 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 2/5] arm: mach-k3: j7200: Fix clk-data parenting for postdiv PLL clocks

[Tom Rini]

On Tue, Sep 07, 2021 at 05:16:55PM -0500, Dave Gerlach wrote:

> From: Suman Anna 
> 
> The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2
> divisors to generate the final FOUTPOSTDIV clock. These are in sequence
> with POSTDIV2 following the POSTDIV1 clock. The current J7200 clock data
> has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is
> opposite of the actual implementation. Fix the data by simply adjusting
> the register bit-shifts.
> 
> The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0
> register values, fix these as well.
> 
> Fixes: 277729eaf373 ("arm: mach-k3: Add platform data for j721e and j7200")
> Signed-off-by: Suman Anna 
> Signed-off-by: Dave Gerlach 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/5] arm: mach-k3: j721e: Fix clk-data parenting for postdiv PLL clocks

[Tom Rini]

On Tue, Sep 07, 2021 at 05:16:54PM -0500, Dave Gerlach wrote:

> From: Suman Anna 
> 
> The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2
> divisors to generate the final FOUTPOSTDIV clock. These are in sequence
> with POSTDIV2 following the POSTDIV1 clock. The current J721E clock data
> has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is
> opposite of the actual implementation. Fix the data by simply adjusting
> the register bit-shifts.
> 
> The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0
> register values, fix these as well.
> 
> Fixes: 277729eaf373 ("arm: mach-k3: Add platform data for j721e and j7200")
> Signed-off-by: Suman Anna 
> Signed-off-by: Dave Gerlach 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] arm: mach-k3: common: Add a release_resources_for_core_shutdown() stub

[Tom Rini]

On Tue, Jul 27, 2021 at 06:24:40PM -0500, Suman Anna wrote:

> Add a weak release_resources_for_core_shutdown() stub implementation
> that can be overridden by actual implementation if a SoC supports that
> function.
> 
> Signed-off-by: Suman Anna 
> Reviewed-by: Nishanth Menon 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] firmware: ti_sci: Include linux/err.h in ti_sci_protocol.h

[Tom Rini]

On Tue, Jul 27, 2021 at 06:24:39PM -0500, Suman Anna wrote:

> The common TI SCI header file uses some macros from err.h and these
> get exercised when CONFIG_TI_SCI_PROTOCOL is not defined. Include
> the linux/err.h header file in this header file directly rather
> than relying on source files to include it to eliminate any
> potential build errors.
> 
> While at this, reorder the existing header file include to the
> beginning of the file.
> 
> Signed-off-by: Suman Anna 
> Reviewed-by: Nishanth Menon 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] arm: mach-k3: common: Make sure firmware sections are loaded prior to armv8 startup

[Tom Rini]

On Tue, Aug 31, 2021 at 01:20:48PM -0500, Nishanth Menon wrote:

> With Device Manager firmware in an elf file form, we cannot load the FIT
> image to the exact same address as any of the executable sections of the
> elf file itself is located.
> 
> However, the device tree descriptions for the ARMV8 bootloader/OS
> includes DDR regions only the final sections in DDR where the Device
> Manager firmware is actually executing out of.
> 
> As the R5 uC is usually operating at a slower rate than an ARMv8 MPU,
> by starting the Armv8 ahead of parsing the elf and copying the correct
> sections to the required memories creates a race condition where the
> ARMv8 could overwrite the elf image loaded from the FIT image prior to
> the R5 completing parsing and putting the correct sections of elf in
> the required memory locations. OR create rather obscure debug conditions
> where data in the section is being modified by ARMV8 OS while the elf
> copy is in progress.
> 
> To prevent all these conditions, lets make sure that the elf parse and
> copy operations are completed ahead of ARMv8 being released to execute.
> 
> We will pay a penalty of elf copy time, but that is a valid tradeoff in
> comparison to debug of alternate scenarios.
> 
> Signed-off-by: Nishanth Menon 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: IMX8MM fsl_esdhc_imx UHS/HS200/HS400 not working?

[Tim Harvey]

On Thu, Sep 16, 2021 at 4:32 PM Tim Harvey  wrote:
>
> Greetings,
>
> Can anyone confirm if IMX8MM UHS/HS200/HS400 is working for them? I
> had this working in my U-Boot v2021.01 imx8mm-veice branch but it
> seems to not work in U-Boot master or v2021.07. I know there was a lot
> of back and forth on this... perhaps I missed something. I haven't
> been able to bisect yet as I had a lot of patches on top of my
> v2021.01 branch.
>

It looks to me like I was mistaken and we still don't have enough
support upstream for IMX8MM UHS/HS200/HS400 to work.

The following are still needed:
[1] fsl_esdhc_imx: Use esdhc_soc_data flags to set host caps
- Adam submitted this some time ago which is required to set the
IMX8MM MMC host capabilities such that UHS/HS200/HS400 are supported
- it was never merged due to some uncertainty that everything was
working with those modes.
[2] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to control card clock output
- this was merged but later reverted [3] due to it causing a
regression of extremely slow MMC in SPL/U-Boot on imx6qdl-pico for
unknown reasons

That said, even though I had UHS/HS200/HS400/HS400ES support in my
v2021.01 branch I ran into the following issues and ended up disabing
HS200/HS400/HS400ES (but kept UHS enabled):
- occasional failures with 'mmc init ' (nothing printed but
an error code returned causing bootscripts to fail to boot to Linux
- failures with eMMC parts that supported eMMC 5.1 HS400ES unless I
disabled HS400ES (can't recall the exact failure and don't have a
board handy to test with)

I'm going to kick off some testing to see if the above issues are
still occuring with patch [1] and [2] on u-boot master.

Anyone else have some feedback regarding UHS/HS200/HS400/HS400ES on IMX8MM?

Best regards,

Tim
[1] https://lists.denx.de/pipermail/u-boot/2020-December/436386.html
[2] https://lists.denx.de/pipermail/u-boot/2021-March/443018.html
[3] https://lists.denx.de/pipermail/u-boot/2021-June/451601.html

Re: [PATCH] riscv: Fix setting no-map in reserved memory nodes

[Atish Patra]

On Sun, Sep 12, 2021 at 9:05 AM Samuel Holland  wrote:
>
> The no-map property is wrongly skipped if a no-map reserved memory
> node follows one without that property. Fix this by not remembering
> the absence of a no-map property across loop iterations.
>
> Fixes: d4ea649f179a ("riscv: Provide a mechanism to fix DT for reserved 
> memory")
> Signed-off-by: Samuel Holland 
> ---
>
>  arch/riscv/lib/fdt_fixup.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
> index f636b284497..61cf8935269 100644
> --- a/arch/riscv/lib/fdt_fixup.c
> +++ b/arch/riscv/lib/fdt_fixup.c
> @@ -31,7 +31,6 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
> fdt_addr_t addr;
> fdt_size_t size;
> int offset, node, err, rmem_offset;
> -   bool nomap = true;
> char basename[32] = {0};
> int bname_len;
> int max_len = sizeof(basename);
> @@ -81,9 +80,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
> log_err("failed to add reserved memory: %d\n", err);
> return err;
> }
> -   if (!fdt_getprop(src, node, "no-map", NULL))
> -   nomap = false;
> -   if (nomap) {
> +   if (fdt_getprop(src, node, "no-map", NULL)) {
> rmem_offset = fdt_node_offset_by_phandle(dst, 
> phandle);
> fdt_setprop_empty(dst, rmem_offset, "no-map");
> }
> --
> 2.31.1
>

Thanks for catching it.

Reviewed-by: Atish Patra 

-- 
Regards,
Atish

[RFC 1/2] mtd: Add partial support for Linux slc-mode for MLC NAND

[Chris Morgan]

From: Chris Morgan 

Add support for setting the slc-mode parameter for a given MLC NAND
device. This allows a given device to write only to the first set
of paried pages to help reduce data corruption and increase reliability
of the NAND.

I haven't tested these patches extensively yet, but thus far I have
been able to boot a FIT image written directly to an MTD partition
from within Linux via U-boot where the slc-mode parameter is set. I
am not able to attach a ubifs partition generated in Linux with the
slc-mode set.

As I am unfamiliar with NAND and have limited experience with the MTD
subsystems, please let me know what else I can do to improve the driver
(and possibly get it where ubifs can work).

Thank you.

Signed-off-by: Chris Morgan 
---
 drivers/mtd/mtdcore.c| 320 ---
 drivers/mtd/mtdpart.c|   7 +
 drivers/mtd/nand/raw/nand_base.c |  50 +
 include/linux/mtd/mtd.h  | 126 
 include/linux/mtd/partitions.h   |   2 +
 include/mtd/mtd-abi.h|   1 +
 6 files changed, 482 insertions(+), 24 deletions(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 0d1f94c6cb..884c95228a 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -397,6 +397,114 @@ static struct device_type mtd_devtype = {
 };
 #endif
 
+/**
+ * mtd_wunit_to_pairing_info - get pairing information of a wunit
+ * @mtd: pointer to new MTD device info structure
+ * @wunit: write unit we are interested in
+ * @info: returned pairing information
+ *
+ * Retrieve pairing information associated to the wunit.
+ * This is mainly useful when dealing with MLC/TLC NANDs where pages can be
+ * paired together, and where programming a page may influence the page it is
+ * paired with.
+ * The notion of page is replaced by the term wunit (write-unit) to stay
+ * consistent with the ->writesize field.
+ *
+ * The @wunit argument can be extracted from an absolute offset using
+ * mtd_offset_to_wunit(). @info is filled with the pairing information attached
+ * to @wunit.
+ *
+ * From the pairing info the MTD user can find all the wunits paired with
+ * @wunit using the following loop:
+ *
+ * for (i = 0; i < mtd_pairing_groups(mtd); i++) {
+ * info.pair = i;
+ * mtd_pairing_info_to_wunit(mtd, );
+ * ...
+ * }
+ */
+int mtd_wunit_to_pairing_info(struct mtd_info *mtd, int wunit,
+ struct mtd_pairing_info *info)
+{
+   struct mtd_info *master = mtd_get_master(mtd);
+   int npairs = mtd_wunit_per_eb(master) / mtd_pairing_groups(master);
+
+   if (wunit < 0 || wunit >= npairs)
+   return -EINVAL;
+
+   if (master->pairing && master->pairing->get_info)
+   return master->pairing->get_info(master, wunit, info);
+
+   info->group = 0;
+   info->pair = wunit;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(mtd_wunit_to_pairing_info);
+
+/**
+ * mtd_pairing_info_to_wunit - get wunit from pairing information
+ * @mtd: pointer to new MTD device info structure
+ * @info: pairing information struct
+ *
+ * Returns a positive number representing the wunit associated to the info
+ * struct, or a negative error code.
+ *
+ * This is the reverse of mtd_wunit_to_pairing_info(), and can help one to
+ * iterate over all wunits of a given pair (see mtd_wunit_to_pairing_info()
+ * doc).
+ *
+ * It can also be used to only program the first page of each pair (i.e.
+ * page attached to group 0), which allows one to use an MLC NAND in
+ * software-emulated SLC mode:
+ *
+ * info.group = 0;
+ * npairs = mtd_wunit_per_eb(mtd) / mtd_pairing_groups(mtd);
+ * for (info.pair = 0; info.pair < npairs; info.pair++) {
+ * wunit = mtd_pairing_info_to_wunit(mtd, );
+ * mtd_write(mtd, mtd_wunit_to_offset(mtd, blkoffs, wunit),
+ *   mtd->writesize, , buf + (i * mtd->writesize));
+ * }
+ */
+int mtd_pairing_info_to_wunit(struct mtd_info *mtd,
+ const struct mtd_pairing_info *info)
+{
+   struct mtd_info *master = mtd_get_master(mtd);
+   int ngroups = mtd_pairing_groups(master);
+   int npairs = mtd_wunit_per_eb(master) / ngroups;
+
+   if (!info || info->pair < 0 || info->pair >= npairs ||
+   info->group < 0 || info->group >= ngroups)
+   return -EINVAL;
+
+   if (master->pairing && master->pairing->get_wunit)
+   return mtd->pairing->get_wunit(master, info);
+
+   return info->pair;
+}
+EXPORT_SYMBOL_GPL(mtd_pairing_info_to_wunit);
+
+/**
+ * mtd_pairing_groups - get the number of pairing groups
+ * @mtd: pointer to new MTD device info structure
+ *
+ * Returns the number of pairing groups.
+ *
+ * This number is usually equal to the number of bits exposed by a single
+ * cell, and can be used in conjunction with mtd_pairing_info_to_wunit()
+ * to iterate over all pages of a given pair.
+ */
+int mtd_pairing_groups(struct mtd_info *mtd)
+{
+   struct mtd_info *master = mtd_get_master(mtd);
+
+  

[RFC 2/2] mtd: Add pairing info for Toshiba TC58TEG5DCLTA00 NAND

[Chris Morgan]

From: Chris Morgan 

Add pairing info for the Toshiba TC58TEG5DCLTA00 NAND so that we may
utilize slc-mode emulation for enhanced reliability and compatibility
with upstream Linux.

Signed-off-by: Chris Morgan 
---
 drivers/mtd/nand/raw/nand_base.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 845bf57c53..ac5b17af70 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4549,6 +4549,15 @@ ident_done:
break;
}
 
+   /* Special handling for TC58TEG5DCLTA00 to match upstream Linux */
+   if (id_data[0] == NAND_MFR_TOSHIBA && id_data[1] == 0xd7
+   && id_data[2] == 0x84 && id_data[3] == 0x93
+   && id_data[4] == 0x72 && id_data[5] == 0x51
+   && id_data[6] == 0x08 && id_data[7] == 0x04) {
+   chip->options |= NAND_NEED_SCRAMBLING;
+   mtd_set_pairing_scheme(mtd, _pairing_scheme);
+   }
+
if (chip->options & NAND_BUSWIDTH_AUTO) {
WARN_ON(chip->options & NAND_BUSWIDTH_16);
chip->options |= busw;
-- 
2.30.2

[RFC 0/2] mtd: Support slc-mode for Toshiba TC58TEG5DCLTA00

[Chris Morgan]

From: Chris Morgan 

Add support for slc-mode implemented in Linux for the Toshiba
TC58TEG5DCLTA00 NAND flash found on the NTC CHIP. This requires the
addition of a paired-pages scheme, a new parameter for MTD partitions
of slc-mode, and setting the correct paired-pages scheme for the
TC58TEG5DCLTA00 flash chip. I will likely need some help making sure
this is consistent with the quality expected of upstream, as well as
solving some remaining issues (such as ubifs partitions not working
with slc-mode set).

Signed-off-by: Chris Morgan 

Chris Morgan (2):
  mtd: Add partial support for Linux slc-mode for MLC NAND
  mtd: Add pairing info for Toshiba TC58TEG5DCLTA00 NAND

 drivers/mtd/mtdcore.c| 320 ---
 drivers/mtd/mtdpart.c|   7 +
 drivers/mtd/nand/raw/nand_base.c |  59 ++
 include/linux/mtd/mtd.h  | 126 
 include/linux/mtd/partitions.h   |   2 +
 include/mtd/mtd-abi.h|   1 +
 6 files changed, 491 insertions(+), 24 deletions(-)

-- 
2.30.2

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Tom Rini]

On Fri, Sep 17, 2021 at 10:21:38AM -0600, Simon Glass wrote:
> Hi François,
> 
> On Wed, 15 Sept 2021 at 04:26, François Ozog  wrote:
> >
> >
> >
> > Le mer. 15 sept. 2021 à 12:13, Simon Glass  a écrit :
> >>
> >> Hi Mark,
> >>
> >> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis  
> >> wrote:
> >> >
> >> > > From: Moiz Imtiaz 
> >> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> >> > >
> >> > > Hi Simon,
> >> > >
> >> > > Thanks for the reply.  I already followed the steps mentioned in
> >> > > "doc/uImage.FIT/beaglebone_vboot.txt".
> >> > >
> >> > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> >> > > instead one provided by the earlier-stage firmware?
> >> > >
> >> > > Not sure, but seems like this is the case. I checked and there isn't 
> >> > > any
> >> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I 
> >> > > tried to
> >> > > add the dtb and other dts dtsi
> >> > > files
> >> > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE 
> >> > > and
> >> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot 
> >> > > and
> >> > > it would just give a blank screen*. I wonder why there isn't any device
> >> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported 
> >> > > by
> >> > > RPI4?
> >> >
> >> > The issue with the rpi4 is that the addresses of devices move around
> >> > based on the version of the Raspberry Pi firmware you're using.  And
> >> > possibly on the amount of memory on the board as well.  So U-Boot
> >> > pretty much has to use the device tree passed by the firmware since
> >> > the device tree in the U-Boot tree would be wrong for many
> >> > combinations of firmware and hardware.
> >> >
> >> > Simon, this sort of thing is exactly the reason why I think the idea
> >> > of having all U-Boot configuration information in a single device tree
> >> > with the hardware description doesn't work everywhere.
> >>
> >> From my reading of this thread, it rather reinforces the need to
> >> provide a way to give U-Boot the config it needs, in the devicetree.
> >>
> >> It seems that rpi is actually OK in this regard. If you think about
> >> it, it would be pretty hopeless if first-stage firmware assumed that
> >> it could provide a devicetree to whatever is next. For example, if
> >> U-Boot evolves to support more devices, they could not be supported.
> >> If UEFI is used, the devicetree would have no effect, since it doesn't
> >> support devicetree.
> >
> > Please use EDK2 when you refer to it and not by the interface it 
> > implements. And even if we read “If EDK2 is used” this is false as 
> > Socionext has a platform that can select ACPI or DT for its EDK2 
> > implementation.
> 
> OK I will try to remember to use 'EDK2' to describe a UEFI
> implementation. Since all the other UEFI implementations are
> closed-source(?) I suppose it is the only one that is relevant here.

Just for the record, AMI recently announced they will be supporting
aarch64, and yes with ACPI.

-- 
Tom


signature.asc
Description: PGP signature

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Tom Rini]

On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 15 Sept 2021 at 07:35, Tom Rini  wrote:
> >
> > On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > > > From: Simon Glass 
> > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > >
> > > Hi Simon,
> > >
> > > > Hi Mark,
> > > >
> > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis  
> > > > wrote:
> > > > >
> > > > > > From: Moiz Imtiaz 
> > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > >
> > > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, 
> > > > > > >but
> > > > > > instead one provided by the earlier-stage firmware?
> > > > > >
> > > > > > Not sure, but seems like this is the case. I checked and there 
> > > > > > isn't any
> > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I 
> > > > > > tried to
> > > > > > add the dtb and other dts dtsi
> > > > > > files
> > > > > > from the raspberry pi Linux and compile them with 
> > > > > > CONFIG_OF_SEPARATE and
> > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the 
> > > > > > U-Boot and
> > > > > > it would just give a blank screen*. I wonder why there isn't any 
> > > > > > device
> > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not 
> > > > > > supported by
> > > > > > RPI4?
> > > > >
> > > > > The issue with the rpi4 is that the addresses of devices move around
> > > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > pretty much has to use the device tree passed by the firmware since
> > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > combinations of firmware and hardware.
> > > > >
> > > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > > of having all U-Boot configuration information in a single device tree
> > > > > with the hardware description doesn't work everywhere.
> > > >
> > > > >From my reading of this thread, it rather reinforces the need to
> > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > >
> > > As long as that configuration is optional, yes, maybe.
> >
> > Lets be a little careful.  We don't want to have two ways to provide the
> > information for a given feature.  But some configuration properties are
> > certainly optional.
> >
> > > > It seems that rpi is actually OK in this regard. If you think about
> > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > it could provide a devicetree to whatever is next.
> > >
> > > Not hopeless.  If that device tree provides a hardware description
> > > that is complete enough to boot Linux, it should be good enough to run
> > > U-Boot.
> >
> > And keep in mind that one of those long stated goals is that the device
> > tree for a platform lives physically on the platform and doesn't require
> > being replaced entirely at run-time with a new/different device tree.
> >
> > > And yes, the Raspberry Pi has a nice way to load overlays to do
> > > additional hardware configuration and support add-on hardware that
> > > connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> > > would make very little sense.
> >
> > Note that in U-Boot we do have functionality to figure out and apply DT
> > overlays for a platform, and it's generic enough that platforms can
> > plugin their logic to detect what overlays are appropriate.  This is
> > under CMD_EXTENSION.  It's not appropriate for Pi as they did all of
> > this in their in-house firmware instead of using U-Boot.
> >
> > > > For example, if U-Boot evolves to support more devices, they could
> > > > not be supported.
> > >
> > > Unless the device in question has a mechanism to load device tree
> > > overlays like the Pi, this would require a firmware update.
> >
> > In that CMD_EXTENSION is about updating the tree for the next stage, and
> > not ourself, yes.  But this is also the same problem that OSes have that
> > lead to overlays, at least in part.  But also why it's so hard to
> > support a static device tree on hardware, and have an evolving kernel.
> > I'm not sure there's many / any good examples of wholly static and also
> > feature complete device trees and OSes today, on a recent / semi-recent
> > piece of hardware.
> >
> > > In practice, the device tree provided by the firmware will have more
> > > stuff than U-Boot will ever need though.  Unless you're advocating
> > > that U-Boot evolves into a full-fledged OS ;).
> > >
> > > > If UEFI is used, the devicetree would have no effect, since it doesn't
> > > > support devicetree.
> > >
> > > That is not true.  UEFI 

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Tom Rini]

On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> Hi Mark,
> 
> On Wed, 15 Sept 2021 at 05:52, Mark Kettenis  wrote:
> >
> > > From: Simon Glass 
> > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> >
> > Hi Simon,
> >
> > > Hi Mark,
> > >
> > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis  
> > > wrote:
> > > >
> > > > > From: Moiz Imtiaz 
> > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > >
> > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > instead one provided by the earlier-stage firmware?
> > > > >
> > > > > Not sure, but seems like this is the case. I checked and there isn't 
> > > > > any
> > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I 
> > > > > tried to
> > > > > add the dtb and other dts dtsi
> > > > > files
> > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE 
> > > > > and
> > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot 
> > > > > and
> > > > > it would just give a blank screen*. I wonder why there isn't any 
> > > > > device
> > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported 
> > > > > by
> > > > > RPI4?
> > > >
> > > > The issue with the rpi4 is that the addresses of devices move around
> > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > pretty much has to use the device tree passed by the firmware since
> > > > the device tree in the U-Boot tree would be wrong for many
> > > > combinations of firmware and hardware.
> > > >
> > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > of having all U-Boot configuration information in a single device tree
> > > > with the hardware description doesn't work everywhere.
> > >
> > > >From my reading of this thread, it rather reinforces the need to
> > > provide a way to give U-Boot the config it needs, in the devicetree.
> >
> > As long as that configuration is optional, yes, maybe.
> >
> > > It seems that rpi is actually OK in this regard. If you think about
> > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > it could provide a devicetree to whatever is next.
> >
> > Not hopeless.  If that device tree provides a hardware description
> > that is complete enough to boot Linux, it should be good enough to run
> > U-Boot.
> 
> Not in general. I hope I have covered this in enormous detail in the
> devicetree patch. But if you don't need verified boot, SPL or some
> other feature that needs config, then perhaps you will get away with
> it.

Wait, why does SPL _need_ it?  If something provides us with a device
tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
smaller DT to use.  Dealing with u-boot,dm-pre-reloc could be trickier,
but means whatever loaded us needs to have enabled any early clocks we
need.  But even then, it's just going to be output related?  And some
"was already configured" path could be used.

-- 
Tom


signature.asc
Description: PGP signature

Re: Problem with U-boot | Configuration Signature not being checked while booting

[François Ozog]

HI Simon,

On Fri, 17 Sept 2021 at 18:21, Simon Glass  wrote:

> Hi François,
>
> On Wed, 15 Sept 2021 at 04:26, François Ozog 
> wrote:
> >
> >
> >
> > Le mer. 15 sept. 2021 à 12:13, Simon Glass  a écrit :
> >>
> >> Hi Mark,
> >>
> >> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis 
> wrote:
> >> >
> >> > > From: Moiz Imtiaz 
> >> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> >> > >
> >> > > Hi Simon,
> >> > >
> >> > > Thanks for the reply.  I already followed the steps mentioned in
> >> > > "doc/uImage.FIT/beaglebone_vboot.txt".
> >> > >
> >> > > >I wonder if rpi is not using the devicetree compiled with U-Boot,
> but
> >> > > instead one provided by the earlier-stage firmware?
> >> > >
> >> > > Not sure, but seems like this is the case. I checked and there
> isn't any
> >> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
> tried to
> >> > > add the dtb and other dts dtsi
> >> > > <
> https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom
> >files
> >> > > from the raspberry pi Linux and compile them with
> CONFIG_OF_SEPARATE and
> >> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the
> U-Boot and
> >> > > it would just give a blank screen*. I wonder why there isn't any
> device
> >> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not
> supported by
> >> > > RPI4?
> >> >
> >> > The issue with the rpi4 is that the addresses of devices move around
> >> > based on the version of the Raspberry Pi firmware you're using.  And
> >> > possibly on the amount of memory on the board as well.  So U-Boot
> >> > pretty much has to use the device tree passed by the firmware since
> >> > the device tree in the U-Boot tree would be wrong for many
> >> > combinations of firmware and hardware.
> >> >
> >> > Simon, this sort of thing is exactly the reason why I think the idea
> >> > of having all U-Boot configuration information in a single device tree
> >> > with the hardware description doesn't work everywhere.
> >>
> >> From my reading of this thread, it rather reinforces the need to
> >> provide a way to give U-Boot the config it needs, in the devicetree.
> >>
> >> It seems that rpi is actually OK in this regard. If you think about
> >> it, it would be pretty hopeless if first-stage firmware assumed that
> >> it could provide a devicetree to whatever is next. For example, if
> >> U-Boot evolves to support more devices, they could not be supported.
> >> If UEFI is used, the devicetree would have no effect, since it doesn't
> >> support devicetree.
> >
> > Please use EDK2 when you refer to it and not by the interface it
> implements. And even if we read “If EDK2 is used” this is false as
> Socionext has a platform that can select ACPI or DT for its EDK2
> implementation.
>
> OK I will try to remember to use 'EDK2' to describe a UEFI
> implementation. Since all the other UEFI implementations are
> closed-source(?) I suppose it is the only one that is relevant here.
> Not that EDK2 actually supports very many boards, so far as I can tell
> from the source tree.
>
> I recall people complaining about libfdt being needed in EDK2 (I
> assume, perhaps it was some other UEFI?) Are you saying that EDK2 can
> use devicetree for its configuration? If not, thenI think you
> misunderstood my point.
>
I effectively did misunderstood your point. EDK2 configuration elements
come from very different sources. It consumes HOBs from the pre-EFI world,
has ACPI parameters, and even private storage. UEFI variables are used to
control some functional elements but if you want to talk about PCI
bifurcation control for instance it is not in ACPI, not in UEFI: just
private structures may be stored in an EEPROM or other element.

>
> > TF-A has fat less drivers than U-Boot. There is no problem in having a
> “verified” platform DT stored in BL33_CONFIG part of a FIP, verified by TFa
> and handed over by U-Boot to OS.
> > That can be the same thing in RPI4 case or FPGA boards.
> >>
>
> OK. I think you are saying that we can use TF-A on rpi and have it
> provide a suitable devicetree for U-Boot. That's fine. However it
> happens is fine. It just needs to support the features U-Boot
> supports, not provide a partial devicetree forcing U-Boot to put its
> config elsewhere.
>
> This is how I implemented LinuxBoot on MacchiatoBin: DT for the platform
in the FIP.
For the RPI, I would just consume what has been assembled through
config.txt overlays and other adjustments.
But again, TFA shall ignore the exact nature of the BL33 (U-Boot,
LinuxBoot, Xen...).
That said I agree there is a need of a clearer/richer contract at the entry
of BL33 (the HOBs/bloblist proposal by Harb is part of this extended
contract discussion).  The DT that TFA passes to BL33, may list a
restricted set of devices because BL33 may not need all devices, or it may
contain the same list of devices but with different bindings (I remember ST
suggesting a display may need 4 parameters for BL33 while it may be
thousands 

Re: [PATCH] mtd: spi-nor-core: Add fixups for s25fs512s

[Pratyush Yadav]

On 15/09/21 12:49PM, tkuw584...@gmail.com wrote:
> From: Takahiro Kuwano 
> 
> The current S25FS512S support has following issues that need to be fixed.
> 
>   - Non-uniform sectors by factory default. The setting needs to be
> checked and assign erase hook as needed.
>   - Page size is wrongly advertised in SFDP.
>   - READ_1_1_2 (3Bh/3Ch), READ_1_1_4 (6Bh/6Ch), and PP_1_1_4 (32h/34h)
> are not supported.
>   - Bank Address Register (BAR) is not supported.
> 
> In addtion, volatile version of Quad Enable is used for safety.
> 
> For future use, the fixups is assigned for S25FS-S family.
> 
> The datasheet can be found in the following link.
> https://www.cypress.com/file/216376/download
> 
> Tested on Xilinx Zynq-7000 FPGA board.
> 
> Signed-off-by: Takahiro Kuwano 
> ---
>  drivers/mtd/spi/spi-nor-core.c | 101 +
>  1 file changed, 101 insertions(+)
> 
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index d5d905fa5a..5e847ebf6a 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -3097,6 +3097,102 @@ static int spi_nor_setup(struct spi_nor *nor, const 
> struct flash_info *info,
>  }
>  
>  #ifdef CONFIG_SPI_FLASH_SPANSION
> +static int s25fs_s_quad_enable(struct spi_nor *nor)
> +{
> + return spansion_quad_enable_volatile(nor, 0, 8);
> +}
> +
> +static int s25fs_s_erase_non_uniform(struct spi_nor *nor, loff_t addr)
> +{
> + /* Support 8 x 4KB sectors at bottom */
> + return spansion_erase_non_uniform(nor, addr, SPINOR_OP_BE_4K_4B, 0,
> +   SZ_32K);
> +}
> +
> +static int s25fs_s_setup(struct spi_nor *nor, const struct flash_info *info,
> +  const struct spi_nor_flash_parameter *params)
> +{
> + int ret;
> + u8 cfr3v;
> +
> +#ifdef CONFIG_SPI_FLASH_BAR

Avoid using #ifdef. Prefer if (CONFIG_IS_ENABLED(SPI_FLASH_BAR) instead.

> + return -ENOTSUPP; /* Bank Address Register is not supported */

Same question as the other patch I just reviewed. What would happen if 
we don't do this?

> +#endif
> + /*
> +  * Read CR3V to check if uniform sector is selected. If not, assign an
> +  * erase hook that supports non-uniform erase.
> +  */
> + ret = spansion_read_any_reg(nor, SPINOR_REG_ADDR_CFR3V, 8, );

Don't hard-code the 8. Use a #define instead.

> + if (ret)
> + return ret;
> + if (!(cfr3v & CFR3V_UNHYSA))
> + nor->erase = s25fs_s_erase_non_uniform;

Ok, but you still don't check for top/bottom configuration. This is the 
same as the S25Hx flashes, right?

> +
> + return spi_nor_default_setup(nor, info, params);
> +}
> +
> +static void s25fs_s_default_init(struct spi_nor *nor)
> +{
> + nor->setup = s25fs_s_setup;
> +}
> +
> +static int s25fs_s_post_bfpt_fixup(struct spi_nor *nor,
> +const struct sfdp_parameter_header *header,
> +const struct sfdp_bfpt *bfpt,
> +struct spi_nor_flash_parameter *params)
> +{
> + int ret;
> + u8 cfr3v;
> +
> + /* The erase size is set to 4K from BFPT, but it's wrong. Fix it. */
> + nor->erase_opcode = SPINOR_OP_SE;
> + nor->mtd.erasesize = nor->info->sector_size;
> +
> + if (params->size > SZ_16M) {
> + ret = nor->write_reg(nor, SPINOR_OP_EN4B, NULL, 0);

set_4byte() should call this as well, right? Why call it here?

> + if (ret)
> + return ret;
> + nor->addr_width = 4;
> + } else {
> + nor->addr_width = 3;
> + }
> +
> + /*
> +  * The page_size is set to 512B from BFPT, but it actually depends on
> +  * the configuration register. Look up the CFR3V and determine the
> +  * page_size.
> +  */
> + ret = spansion_read_any_reg(nor, SPINOR_REG_ADDR_CFR3V, 8, );
> + if (ret)
> + return ret;
> +
> + if (cfr3v & CFR3V_PGMBUF)
> + params->page_size = 512;
> + else
> + params->page_size = 256;
> +
> + return 0;
> +}
> +
> +static void s25fs_s_post_sfdp_fixup(struct spi_nor *nor,
> + struct spi_nor_flash_parameter *params)
> +{
> + /* READ_1_1_2 is not supported */
> + params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_2;
> + /* READ_1_1_4 is not supported */
> + params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_4;
> + /* PP_1_1_4 is not supported */
> + params->hwcaps.mask &= ~SNOR_HWCAPS_PP_1_1_4;
> + /* Use volatile register to enable quad */
> + params->quad_enable = s25fs_s_quad_enable;
> +}
> +
> +static struct spi_nor_fixups s25fs_s_fixups = {
> + .default_init = s25fs_s_default_init,
> + .post_bfpt = s25fs_s_post_bfpt_fixup,
> + .post_sfdp = s25fs_s_post_sfdp_fixup,
> +};
> +
>  static int s25hx_t_mdp_ready(struct spi_nor *nor)
>  {
>   u32 addr;
> @@ -3644,6 +3740,11 @@ void spi_nor_set_fixups(struct 

Re: [PATCH 2/2] mtd: spi-nor-core: Add fixups for Spansion S25FL256L

[Pratyush Yadav]

On 08/09/21 05:47PM, tkuw584...@gmail.com wrote:
> From: Takahiro Kuwano 
> 
> The S25FL256L is 32MB NOR Flash that does not support Bank Address
> Register. This fixup is activated if CONFIG_SPI_FLASH_BAR is enabled and
> returns ENOTSUPP in setup() hook to avoid further ops.
> 
> Signed-off-by: Takahiro Kuwano 
> ---
>  drivers/mtd/spi/spi-nor-core.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index d5d905fa5a..4940b35682 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -3222,6 +3222,23 @@ static struct spi_nor_fixups s25hx_t_fixups = {
>   .post_bfpt = s25hx_t_post_bfpt_fixup,
>   .post_sfdp = s25hx_t_post_sfdp_fixup,
>  };
> +
> +#ifdef CONFIG_SPI_FLASH_BAR
> +static int s25fl256l_setup(struct spi_nor *nor, const struct flash_info 
> *info,
> +const struct spi_nor_flash_parameter *params)
> +{
> + return -ENOTSUPP; /* Bank Address Register is not supported */

I am not very familiar with BAR. Can you please explain what would 
happen if we don't do this?

> +}
> +
> +static void s25fl256l_default_init(struct spi_nor *nor)
> +{
> + nor->setup = s25fl256l_setup;
> +}
> +
> +static struct spi_nor_fixups s25fl256l_fixups = {
> + .default_init = s25fl256l_default_init,
> +};
> +#endif
>  #endif
>  
>  #ifdef CONFIG_SPI_FLASH_S28HS512T
> @@ -3644,6 +3661,10 @@ void spi_nor_set_fixups(struct spi_nor *nor)
>   break;
>   }
>   }
> +#ifdef CONFIG_SPI_FLASH_BAR

We should avoid using #ifdef as much as possible. Change this to

  if (CONFIG_IS_ENABLED(SPI_FLASH_BAR) && !strcmp())

> + if (!strcmp(nor->info->name, "s25fl256l"))
> + nor->fixups = _fixups;
> +#endif

*sigh* we really need to find a better way to specify fixups. Let me see 
if I can figure something out. In the meantime, this should be fine.

>  #endif
>  
>  #ifdef CONFIG_SPI_FLASH_S28HS512T
> -- 
> 2.25.1
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH 1/2] mtd: spi-nor-ids: Add support for Spansion S25FL256L

[Pratyush Yadav]

On 08/09/21 05:47PM, tkuw584...@gmail.com wrote:
> From: Takahiro Kuwano 
> 
> The S25FL256L is a part of the S25FL-L family and has the same feature set
> as S25FL128L except the density.
> 
> The datasheet can be found in the following link.
> https://www.cypress.com/file/316171/download
> 
> Tested on Xilinx Zynq-7000 FPGA board.

I think you should add fixups and the flash entry in the same commit 
instead of adding them in separate ones. This would make sure the flash 
works correctly if someone lands on this commit when bisecting.

The patch LGTM otherwise.

> 
> Signed-off-by: Takahiro Kuwano 
> ---
>  drivers/mtd/spi/spi-nor-ids.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index 4aef1ddd6e..11d7d4fcaa 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -227,6 +227,7 @@ const struct flash_info spi_nor_ids[] = {
>   { INFO("s25fl208k",  0x014014,  0,  64 * 1024,  16, SECT_4K | 
> SPI_NOR_DUAL_READ) },
>   { INFO("s25fl064l",  0x016017,  0,  64 * 1024, 128, SECT_4K | 
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>   { INFO("s25fl128l",  0x016018,  0,  64 * 1024, 256, SECT_4K | 
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> + { INFO("s25fl256l",  0x016019,  0,  64 * 1024, 512, SECT_4K | 
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>   { INFO6("s25hl512t",  0x342a1a, 0x0f0390, 256 * 1024, 256,
>   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
>   USE_CLSR) },
> -- 
> 2.25.1
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Simon Glass]

Hi François,

On Wed, 15 Sept 2021 at 04:26, François Ozog  wrote:
>
>
>
> Le mer. 15 sept. 2021 à 12:13, Simon Glass  a écrit :
>>
>> Hi Mark,
>>
>> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis  wrote:
>> >
>> > > From: Moiz Imtiaz 
>> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
>> > >
>> > > Hi Simon,
>> > >
>> > > Thanks for the reply.  I already followed the steps mentioned in
>> > > "doc/uImage.FIT/beaglebone_vboot.txt".
>> > >
>> > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
>> > > instead one provided by the earlier-stage firmware?
>> > >
>> > > Not sure, but seems like this is the case. I checked and there isn't any
>> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried 
>> > > to
>> > > add the dtb and other dts dtsi
>> > > files
>> > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
>> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
>> > > it would just give a blank screen*. I wonder why there isn't any device
>> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
>> > > RPI4?
>> >
>> > The issue with the rpi4 is that the addresses of devices move around
>> > based on the version of the Raspberry Pi firmware you're using.  And
>> > possibly on the amount of memory on the board as well.  So U-Boot
>> > pretty much has to use the device tree passed by the firmware since
>> > the device tree in the U-Boot tree would be wrong for many
>> > combinations of firmware and hardware.
>> >
>> > Simon, this sort of thing is exactly the reason why I think the idea
>> > of having all U-Boot configuration information in a single device tree
>> > with the hardware description doesn't work everywhere.
>>
>> From my reading of this thread, it rather reinforces the need to
>> provide a way to give U-Boot the config it needs, in the devicetree.
>>
>> It seems that rpi is actually OK in this regard. If you think about
>> it, it would be pretty hopeless if first-stage firmware assumed that
>> it could provide a devicetree to whatever is next. For example, if
>> U-Boot evolves to support more devices, they could not be supported.
>> If UEFI is used, the devicetree would have no effect, since it doesn't
>> support devicetree.
>
> Please use EDK2 when you refer to it and not by the interface it implements. 
> And even if we read “If EDK2 is used” this is false as Socionext has a 
> platform that can select ACPI or DT for its EDK2 implementation.

OK I will try to remember to use 'EDK2' to describe a UEFI
implementation. Since all the other UEFI implementations are
closed-source(?) I suppose it is the only one that is relevant here.
Not that EDK2 actually supports very many boards, so far as I can tell
from the source tree.

I recall people complaining about libfdt being needed in EDK2 (I
assume, perhaps it was some other UEFI?) Are you saying that EDK2 can
use devicetree for its configuration? If not, thenI think you
misunderstood my point.

> TF-A has fat less drivers than U-Boot. There is no problem in having a 
> “verified” platform DT stored in BL33_CONFIG part of a FIP, verified by TFa 
> and handed over by U-Boot to OS.
> That can be the same thing in RPI4 case or FPGA boards.
>>

OK. I think you are saying that we can use TF-A on rpi and have it
provide a suitable devicetree for U-Boot. That's fine. However it
happens is fine. It just needs to support the features U-Boot
supports, not provide a partial devicetree forcing U-Boot to put its
config elsewhere.


>>
>>
>> So perhaps the only remaining issue is with qemu on ARM / Risc-V?

Regards,
Simon

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Simon Glass]

Hi Tom,

On Wed, 15 Sept 2021 at 07:35, Tom Rini  wrote:
>
> On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > > From: Simon Glass 
> > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> >
> > Hi Simon,
> >
> > > Hi Mark,
> > >
> > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis  
> > > wrote:
> > > >
> > > > > From: Moiz Imtiaz 
> > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > >
> > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > instead one provided by the earlier-stage firmware?
> > > > >
> > > > > Not sure, but seems like this is the case. I checked and there isn't 
> > > > > any
> > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I 
> > > > > tried to
> > > > > add the dtb and other dts dtsi
> > > > > files
> > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE 
> > > > > and
> > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot 
> > > > > and
> > > > > it would just give a blank screen*. I wonder why there isn't any 
> > > > > device
> > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported 
> > > > > by
> > > > > RPI4?
> > > >
> > > > The issue with the rpi4 is that the addresses of devices move around
> > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > pretty much has to use the device tree passed by the firmware since
> > > > the device tree in the U-Boot tree would be wrong for many
> > > > combinations of firmware and hardware.
> > > >
> > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > of having all U-Boot configuration information in a single device tree
> > > > with the hardware description doesn't work everywhere.
> > >
> > > >From my reading of this thread, it rather reinforces the need to
> > > provide a way to give U-Boot the config it needs, in the devicetree.
> >
> > As long as that configuration is optional, yes, maybe.
>
> Lets be a little careful.  We don't want to have two ways to provide the
> information for a given feature.  But some configuration properties are
> certainly optional.
>
> > > It seems that rpi is actually OK in this regard. If you think about
> > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > it could provide a devicetree to whatever is next.
> >
> > Not hopeless.  If that device tree provides a hardware description
> > that is complete enough to boot Linux, it should be good enough to run
> > U-Boot.
>
> And keep in mind that one of those long stated goals is that the device
> tree for a platform lives physically on the platform and doesn't require
> being replaced entirely at run-time with a new/different device tree.
>
> > And yes, the Raspberry Pi has a nice way to load overlays to do
> > additional hardware configuration and support add-on hardware that
> > connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> > would make very little sense.
>
> Note that in U-Boot we do have functionality to figure out and apply DT
> overlays for a platform, and it's generic enough that platforms can
> plugin their logic to detect what overlays are appropriate.  This is
> under CMD_EXTENSION.  It's not appropriate for Pi as they did all of
> this in their in-house firmware instead of using U-Boot.
>
> > > For example, if U-Boot evolves to support more devices, they could
> > > not be supported.
> >
> > Unless the device in question has a mechanism to load device tree
> > overlays like the Pi, this would require a firmware update.
>
> In that CMD_EXTENSION is about updating the tree for the next stage, and
> not ourself, yes.  But this is also the same problem that OSes have that
> lead to overlays, at least in part.  But also why it's so hard to
> support a static device tree on hardware, and have an evolving kernel.
> I'm not sure there's many / any good examples of wholly static and also
> feature complete device trees and OSes today, on a recent / semi-recent
> piece of hardware.
>
> > In practice, the device tree provided by the firmware will have more
> > stuff than U-Boot will ever need though.  Unless you're advocating
> > that U-Boot evolves into a full-fledged OS ;).
> >
> > > If UEFI is used, the devicetree would have no effect, since it doesn't
> > > support devicetree.
> >
> > That is not true.  UEFI supports device trees just fine.  All the
> > arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
> > support use device trees.  The idea that UEFI implies ACPI is a
> > misconception.
> >
> > > So perhaps the only remaining issue is with qemu on ARM / Risc-V?
> >
> > Maybe 

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Simon Glass]

Hi Mark,

On Wed, 15 Sept 2021 at 05:52, Mark Kettenis  wrote:
>
> > From: Simon Glass 
> > Date: Wed, 15 Sep 2021 04:13:24 -0600
>
> Hi Simon,
>
> > Hi Mark,
> >
> > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis  
> > wrote:
> > >
> > > > From: Moiz Imtiaz 
> > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > >
> > > > Hi Simon,
> > > >
> > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > >
> > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > instead one provided by the earlier-stage firmware?
> > > >
> > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried 
> > > > to
> > > > add the dtb and other dts dtsi
> > > > files
> > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot 
> > > > and
> > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > RPI4?
> > >
> > > The issue with the rpi4 is that the addresses of devices move around
> > > based on the version of the Raspberry Pi firmware you're using.  And
> > > possibly on the amount of memory on the board as well.  So U-Boot
> > > pretty much has to use the device tree passed by the firmware since
> > > the device tree in the U-Boot tree would be wrong for many
> > > combinations of firmware and hardware.
> > >
> > > Simon, this sort of thing is exactly the reason why I think the idea
> > > of having all U-Boot configuration information in a single device tree
> > > with the hardware description doesn't work everywhere.
> >
> > >From my reading of this thread, it rather reinforces the need to
> > provide a way to give U-Boot the config it needs, in the devicetree.
>
> As long as that configuration is optional, yes, maybe.
>
> > It seems that rpi is actually OK in this regard. If you think about
> > it, it would be pretty hopeless if first-stage firmware assumed that
> > it could provide a devicetree to whatever is next.
>
> Not hopeless.  If that device tree provides a hardware description
> that is complete enough to boot Linux, it should be good enough to run
> U-Boot.

Not in general. I hope I have covered this in enormous detail in the
devicetree patch. But if you don't need verified boot, SPL or some
other feature that needs config, then perhaps you will get away with
it.

>
> And yes, the Raspberry Pi has a nice way to load overlays to do
> additional hardware configuration and support add-on hardware that
> connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> would make very little sense.

Indeed, since AFAIK there is no way to use U-Boot as a first-stage
bootloader on rpi.

>
> > For example, if U-Boot evolves to support more devices, they could
> > not be supported.
>
> Unless the device in question has a mechanism to load device tree
> overlays like the Pi, this would require a firmware update.
>
> In practice, the device tree provided by the firmware will have more
> stuff than U-Boot will ever need though.  Unless you're advocating
> that U-Boot evolves into a full-fledged OS ;).

It is a constant risk.

>
> > If UEFI is used, the devicetree would have no effect, since it doesn't
> > support devicetree.
>
> That is not true.  UEFI supports device trees just fine.  All the
> arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
> support use device trees.  The idea that UEFI implies ACPI is a
> misconception.

François made the same point and I'm pretty sure you are talking about
booting a kernel using devicetree. Here, we are talking about setting
up the U-Boot control dtb correctly and my point was that UEFI does
not use a control dtb, so far as I know.

>
> > So perhaps the only remaining issue is with qemu on ARM / Risc-V?
>
> Maybe somebody can add device tree overlay support to QEMU?

Yes. I'm actually willing to do this once we get the UEFI embedded
signature reverted. I think it is pretty clear now that it is a dead
end.

Regards,
Simon

[PATCH 15/17] Makefile: Support ad-hoc COMFIX_SPL_IMAGE_SIZE et al

[Simon Glass]

Ad-hoc CONFIGs are not supported by the new split-config mechanism. Use
the provided work-around for these symbols, just to show the mechanism.

Signed-off-by: Simon Glass 
---

 scripts/Makefile.spl | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index a6705efcf07..8baf8478f64 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -198,11 +198,11 @@ LDPPFLAGS += \
 
 # Turn various CONFIG symbols into IMAGE symbols for easy reuse of
 # the scripts between SPL and TPL.
-ifneq ($(CONFIG_$(SPL_TPL_)MAX_SIZE),)
-LDPPFLAGS += -DIMAGE_MAX_SIZE=$(CONFIG_$(SPL_TPL_)MAX_SIZE)
+ifneq ($(CONFIG_$(xSPL_TPL_)MAX_SIZE),)
+LDPPFLAGS += -DIMAGE_MAX_SIZE=$(CONFIG_$(xSPL_TPL_)MAX_SIZE)
 endif
-ifneq ($(CONFIG_$(SPL_TPL_)TEXT_BASE),)
-LDPPFLAGS += -DIMAGE_TEXT_BASE=$(CONFIG_$(SPL_TPL_)TEXT_BASE)
+ifneq ($(CONFIG_$(xSPL_TPL_)TEXT_BASE),)
+LDPPFLAGS += -DIMAGE_TEXT_BASE=$(CONFIG_$(xSPL_TPL_)TEXT_BASE)
 endif
 
 MKIMAGEOUTPUT ?= /dev/null
-- 
2.33.0.309.g3052b89438-goog

[PATCH 12/17] kconfig: Support writing separate SPL files

[Simon Glass]

At present kconfig writes out several files, including:

   auto.conf  - CONFIG settings used by make
   autoconf.h - header file used by C code

This works well but is a bit ugly in places, for example requiring the use
of a SPL_TPL_ macro in Makefiles to distinguish between options intended
for SPL and U-Boot proper.

Update the kconfig tool to also output separate files for each phase: e.g.
auto_spl.conf and autoconf_spl.h

These are similar to the existing file, but drop the SPL_ prefix so that
SPL_TPL_ is not needed. It also allows the CONFIG_IS_ENABLED() macro to be
simplified, in a later patch.

The output of existing files is not changed in any way, This commit just
adds new ones.

These changes may benefit from some reworking to send upstream, e.g. to
use a struct for the 'arg' parameter.

Signed-off-by: Simon Glass 
---

 scripts/kconfig/conf.c |   4 +
 scripts/kconfig/confdata.c | 229 -
 2 files changed, 231 insertions(+), 2 deletions(-)

diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 376f796f674..0104180817e 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -684,6 +684,10 @@ int main(int ac, char **av)
break;
}
 
+   /* U-Boot: Mark SPL symbols */
+   if (sync_kconfig)
+   conf_mark_spl_symbols();
+
if (sync_kconfig) {
/* syncconfig is used during the build so we shall update 
autoconf.
 * All other commands are only used to generate a config.
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 73bf43bcb95..5b6bf927a7a 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -16,6 +16,15 @@
 
 #include "lkc.h"
 
+/* Number of SPL prefixes we recognise */
+#define NUM_SPLS2
+
+/*
+ * SPL prefixes recognised. For example CONFIG_SPL_xxx is considered to be an
+ * SPL version of CONFIG_xxx
+ */
+static const char *spl_name[NUM_SPLS] = {"SPL", "TPL"};
+
 /* return true if 'path' exists, false otherwise */
 static bool is_present(const char *path)
 {
@@ -571,11 +580,77 @@ static struct conf_printer kconfig_printer_cb =
.print_comment = kconfig_print_comment,
 };
 
+/**
+ * get_spl_name() - Look up an SPL symbol
+ *
+ * This is used to get the name of a Kconfig option to write in an SPL context.
+ * If the symbol has an SPL symbol, this means it is used for U-Boot proper, so
+ * should not be written at all.
+ *
+ * Otherwise, this returns the name of the option. If the option is an SPL
+ * option, then the prefix (SPL_ or TPL_) is removed
+ *
+ * @sym: Symbol to look up
+ * @arg: Argument passed to the symbol function. This is void * but is actually
+ * an int, indicating the SPL index / type (see spl_name[])
+ * @return name to write out for this symbol xxx:
+ * NULL (don't write) if xxx has an associated SPL symbol
+ * xxx if xxx is a non-SPL symbol
+ * xxx if SPL_xxx is an SPL symbol
+ */
+static const char *get_spl_name(const struct symbol *sym, const void *arg)
+{
+   int spl = (long)arg;
+   const char *name = sym->name;
+
+   /* Don't print it if this has an SPL symbol */
+   if (sym->flags & SYMBOL_HAS_SPL)
+   return NULL;
+
+   /*
+* If it is SPL, only print it if the SPL_ prefix matches
+* Drop the prefix.
+*/
+   if (sym->flags & SYMBOL_SPL) {
+   int len = strlen(spl_name[spl]);
+
+   if (!strncmp(name, spl_name[spl], len) && name[len] == '_')
+   name += len + 1;
+   }
+
+   return name;
+}
+
+/*
+ * Kconfig configuration printer for SPL
+ *
+ * This printer is used when generating the resulting configuration after
+ * kconfig invocation and `defconfig' files. Unset symbol might be omitted by
+ * passing a non-NULL argument to the printer.
+ *
+ */
+static void spl_kconfig_print_symbol(FILE *fp, struct symbol *sym,
+const char *value, void *arg)
+{
+   const char *name;
+
+   name = get_spl_name(sym, arg);
+   if (!name)
+   return;
+
+   print_makefile_sym(fp, name, sym->type, value, false);
+   print_makefile_sym(fp, sym->name, sym->type, value, false);
+}
+
+static struct conf_printer spl_kconfig_printer_cb = {
+   .print_symbol = spl_kconfig_print_symbol,
+   .print_comment = kconfig_print_comment,
+};
+
 /* Print a symbol for a header file */
 static void print_header_sym(FILE *fp, const char *name, enum symbol_type type,
 const char *value)
 {
-
switch (type) {
case S_BOOLEAN:
case S_TRISTATE: {
@@ -651,6 +726,35 @@ static struct conf_printer header_printer_cb =
.print_comment = header_print_comment,
 };
 
+/*
+ * SPL header printer
+ *
+ * This printer is used when generating SPL files such as
+ * `include/generated/autoconf_spl.h'
+ */
+static void spl_header_print_symbol(FILE *fp, struct symbol *sym,
+ 

[PATCH 17/17] kconfig: Add a new CONFIG() macro

[Simon Glass]

It is annoying to have to use IS_ENABLED() and CONFIG_IS_ENABLED(),
depending on whether the option being checked has an SPL version. Also
we use #ifdef CONFIG_xxx and #if defined(CONFIG_xxx) in some contexts.
It would be nice to use a single style consistenty.

Add a CONFIG() macro to this end, to check configuration. The argument is
the Kconfig name to check, excluding any SPL_/TPL_ prefix, for example:

   CONFIG(DM)
   CONFIG(CMD_MISC)
   CONFIG(OF_PLATDATA)

This is just for illustration, but it should be possible to drop
IS_ENABLED() and CONFIG_IS_ENABLED(), once migration of ad-hoc CONFIG
is complete. The use of #ifdef and defined() can be updated also.

Signed-off-by: Simon Glass 
---

 include/linux/kconfig.h | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
index e6b0f238ec4..401341275fe 100644
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -28,14 +28,6 @@
 #define __config_enabled(arg1_or_junk) ___config_enabled(arg1_or_junk 1, 0)
 #define ___config_enabled(__ignored, val, ...) val
 
-/*
- * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y',
- * 0 otherwise.
- *
- */
-#define IS_ENABLED(option) \
-   (config_enabled(option))
-
 /*
  * The _nospl version of a CONFIG is emitted by kconfig when an option has no
  * SPL equivalent. So in that case there is a CONFIG_xxx for example, but not a
@@ -51,11 +43,11 @@
config_enabled(CONFIG_ ## cfg))
 
 /*
- * CONFIG_IS_ENABLED(FOO) returns 1 if CONFIG_FOO is enabled for the phase 
being
+ * CONFIG(FOO) returns 1 if CONFIG_FOO is enabled for the phase being
  * built, else 0. Note that CONFIG_FOO corresponds to CONFIG_SPL_FOO (in
  * Kconfig) for the SPL phase, CONFIG_TPL_FOO for the TPL phase, etc.
  */
-#define CONFIG_IS_ENABLED(option) __config_is_enabled(option)
+#define CONFIG(option) __config_is_enabled(option)
 
 #define __config_val(cfg) CONFIG_ ## cfg
 
-- 
2.33.0.309.g3052b89438-goog

[PATCH 16/17] kconfig: Update CONFIG_IS_ENABLED() for split files

[Simon Glass]

Update this file to include the correct autoconf.h or autoconf_spl.h file
for each phase. This allows the macros to be simplified.

With this, CONFIG_IS_ENABLED() is the same as IS_ENABLED() apart from a
migration detail.

Signed-off-by: Simon Glass 
---

 include/linux/kconfig.h | 87 -
 1 file changed, 24 insertions(+), 63 deletions(-)

diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
index d109ed3119e..e6b0f238ec4 100644
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -1,7 +1,13 @@
 #ifndef __LINUX_KCONFIG_H
 #define __LINUX_KCONFIG_H
 
+#ifdef CONFIG_TPL_BUILD
+#include 
+#elif defined(CONFIG_SPL_BUILD)
+#include 
+#else
 #include 
+#endif
 
 /*
  * Helper macros to use CONFIG_ options in C/CPP expressions. Note that
@@ -31,29 +37,29 @@
(config_enabled(option))
 
 /*
- * U-Boot add-on: Helper macros to reference to different macros
- * (CONFIG_ or CONFIG_SPL_ prefixed), depending on the build context.
+ * The _nospl version of a CONFIG is emitted by kconfig when an option has no
+ * SPL equivalent. So in that case there is a CONFIG_xxx for example, but not a
+ * CONFIG_SPL_xxx
+ *
+ * This is needed as a transition measure while CONFIG_IS_ENABLED() is used on
+ * options without SPL equivalent, since in that case it should always return
+ * zero. Once we add SPL equivalents, this clause can be dropped.
  */
 
-#if defined(CONFIG_TPL_BUILD)
-#define _CONFIG_PREFIX TPL_
-#elif defined(CONFIG_SPL_BUILD)
-#define _CONFIG_PREFIX SPL_
-#else
-#define _CONFIG_PREFIX
-#endif
-
-#define   config_val(cfg)   _config_val(_CONFIG_PREFIX, cfg)
-#define  _config_val(pfx, cfg) __config_val(pfx, cfg)
-#define __config_val(pfx, cfg) CONFIG_ ## pfx ## cfg
+#define __config_is_enabled(cfg) (IS_ENABLED(CONFIG_ ## cfg ## _nospl) ? \
+   !IS_ENABLED(CONFIG_SPL_BUILD) : \
+   config_enabled(CONFIG_ ## cfg))
 
 /*
- * CONFIG_VAL(FOO) evaluates to the value of
- *  CONFIG_FOO if CONFIG_SPL_BUILD is undefined,
- *  CONFIG_SPL_FOO if CONFIG_SPL_BUILD is defined.
- *  CONFIG_TPL_FOO if CONFIG_TPL_BUILD is defined.
+ * CONFIG_IS_ENABLED(FOO) returns 1 if CONFIG_FOO is enabled for the phase 
being
+ * built, else 0. Note that CONFIG_FOO corresponds to CONFIG_SPL_FOO (in
+ * Kconfig) for the SPL phase, CONFIG_TPL_FOO for the TPL phase, etc.
  */
-#define CONFIG_VAL(option)  config_val(option)
+#define CONFIG_IS_ENABLED(option) __config_is_enabled(option)
+
+#define __config_val(cfg) CONFIG_ ## cfg
+
+#define CONFIG_VAL(option)  __config_val(option)
 
 /*
  * Count number of arguments to a variadic macro. Currently only need
@@ -62,49 +68,4 @@
 #define __arg6(a1, a2, a3, a4, a5, a6, ...) a6
 #define __count_args(...) __arg6(dummy, ##__VA_ARGS__, 4, 3, 2, 1, 0)
 
-#define __concat(a, b)   ___concat(a, b)
-#define ___concat(a, b)  a ## b
-
-#define __unwrap(...) __VA_ARGS__
-#define __unwrap1(case1, case0) __unwrap case1
-#define __unwrap0(case1, case0) __unwrap case0
-
-#define __CONFIG_IS_ENABLED_1(option)__CONFIG_IS_ENABLED_3(option, 
(1), (0))
-#define __CONFIG_IS_ENABLED_2(option, case1) __CONFIG_IS_ENABLED_3(option, 
case1, ())
-#define __CONFIG_IS_ENABLED_3(option, case1, case0) \
-   __concat(__unwrap, config_enabled(CONFIG_VAL(option))) (case1, case0)
-
-/*
- * CONFIG_IS_ENABLED(FOO) expands to
- *  1 if CONFIG_SPL_BUILD is undefined and CONFIG_FOO is set to 'y',
- *  1 if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y',
- *  1 if CONFIG_TPL_BUILD is defined and CONFIG_TPL_FOO is set to 'y',
- *  0 otherwise.
- *
- * CONFIG_IS_ENABLED(FOO, (abc)) expands to
- *  abc if CONFIG_SPL_BUILD is undefined and CONFIG_FOO is set to 'y',
- *  abc if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y',
- *  abc if CONFIG_TPL_BUILD is defined and CONFIG_TPL_FOO is set to 'y',
- *  nothing otherwise.
- *
- * CONFIG_IS_ENABLED(FOO, (abc), (def)) expands to
- *  abc if CONFIG_SPL_BUILD is undefined and CONFIG_FOO is set to 'y',
- *  abc if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y',
- *  abc if CONFIG_TPL_BUILD is defined and CONFIG_TPL_FOO is set to 'y',
- *  def otherwise.
- *
- * The optional second and third arguments must be parenthesized; that
- * allows one to include a trailing comma, e.g. for use in
- *
- * CONFIG_IS_ENABLED(ACME, ({.compatible = "acme,frobnozzle"},))
- *
- * which adds an entry to the array being defined if CONFIG_ACME (or
- * CONFIG_SPL_ACME/CONFIG_TPL_ACME, depending on build context) is
- * set, and nothing otherwise.
- */
-
-#define CONFIG_IS_ENABLED(option, ...) \
-   __concat(__CONFIG_IS_ENABLED_, __count_args(option, ##__VA_ARGS__)) 
(option, ##__VA_ARGS__)
-
-
 #endif /* __LINUX_KCONFIG_H */
-- 
2.33.0.309.g3052b89438-goog

[PATCH 10/17] virtio: Add SPL Kconfig for virtio

[Simon Glass]

At present we rely on this not existing to avoid building virtio for SPL.

But with the new split configs this does not work. Add a separate Kconfig
instead.

Signed-off-by: Simon Glass 
---

 drivers/virtio/Kconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 863c3fbe029..2ac98edff58 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -22,6 +22,12 @@ config VIRTIO
  This option is selected by any driver which implements the virtio
  transport, such as CONFIG_VIRTIO_MMIO or CONFIG_VIRTIO_PCI.
 
+config SPL_VIRTIO
+   bool
+   help
+ This option is selected by any driver which implements the virtio
+ transport, such as CONFIG_VIRTIO_MMIO or CONFIG_VIRTIO_PCI.
+
 config VIRTIO_MMIO
bool "Platform bus driver for memory mapped virtio devices"
select VIRTIO
-- 
2.33.0.309.g3052b89438-goog

[PATCH 14/17] Makefile: Use empty SPL_ and SPL_TPL_ vars

[Simon Glass]

Now that we include an auto.conf file specific to the phase being built
we can make these variables empty.

With this done, we can also remove them from U-Boot entirely, dropping
them from all Makefiles. That is left for a future clean-up since we
cannot apply this series until CONFIG migration is complete.

Signed-off-by: Simon Glass 
---

 scripts/Kbuild.include | 17 +
 scripts/Makefile.spl   | 17 +
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index a745cc4fccd..90444d38f89 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -319,14 +319,23 @@ endif
 # do not delete intermediate files automatically
 .SECONDARY:
 
+# The SPL_ and SPL_TPL_ vars resolve to nothing so they can be used in
+# Makefiles
+
+# For compatibility with ad-hoc CONFIG options, provide xSPL_ and xSPL_TPL_
+# which maintain the old behaviour. The is just for illustration purposes,
+# since it is better to wait until all CONFIGs are migrated.
 ifdef CONFIG_SPL_BUILD
-SPL_ := SPL_
+xSPL_ := SPL_
 ifeq ($(CONFIG_TPL_BUILD),y)
-SPL_TPL_ := TPL_
+xSPL_TPL_ := TPL_
 else
-SPL_TPL_ := SPL_
+xSPL_TPL_ := SPL_
 endif
 else
+xSPL_ :=
+xSPL_TPL_ :=
+endif
+
 SPL_ :=
 SPL_TPL_ :=
-endif
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 02dd85b8e1c..a6705efcf07 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -45,17 +45,26 @@ endif
 
 export SPL_NAME
 
+# The SPL_ and SPL_TPL_ vars resolve to nothing so they can be used in
+# Makefiles
+
+# For compatibility with ad-hoc CONFIG options, provide xSPL_ and xSPL_TPL_
+# which maintain the old behaviour. The is just for illustration purposes,
+# since it is better to wait until all CONFIGs are migrated.
 ifdef CONFIG_SPL_BUILD
-SPL_ := SPL_
+xSPL_ := SPL_
 ifeq ($(CONFIG_TPL_BUILD),y)
-SPL_TPL_ := TPL_
+xSPL_TPL_ := TPL_
 else
-SPL_TPL_ := SPL_
+xSPL_TPL_ := SPL_
 endif
 else
+xSPL_ :=
+xSPL_TPL_ :=
+endif
+
 SPL_ :=
 SPL_TPL_ :=
-endif
 
 ifeq ($(obj)$(CONFIG_SUPPORT_SPL),spl)
 $(error You cannot build SPL without enabling CONFIG_SUPPORT_SPL)
-- 
2.33.0.309.g3052b89438-goog

[PATCH 11/17] kconfig: Refactor code into separate writer functions

[Simon Glass]

Separate out the code that writes the Makefile and headers so we can
reuse these functions when writing out SPL files.

This makes no functional change.

Signed-off-by: Simon Glass 
---

 scripts/kconfig/confdata.c | 65 ++
 scripts/kconfig/expr.h |  9 ++
 scripts/kconfig/lkc.h  |  9 ++
 3 files changed, 56 insertions(+), 27 deletions(-)

diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index d587b10d7f8..73bf43bcb95 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -509,27 +509,18 @@ int conf_read(const char *name)
return 0;
 }
 
-/*
- * Kconfig configuration printer
- *
- * This printer is used when generating the resulting configuration after
- * kconfig invocation and `defconfig' files. Unset symbol might be omitted by
- * passing a non-NULL argument to the printer.
- *
- */
-static void
-kconfig_print_symbol(FILE *fp, struct symbol *sym, const char *value, void 
*arg)
+/* Print a symbol for a Makefile */
+static void print_makefile_sym(FILE *fp, const char *name,
+  enum symbol_type type, const char *value,
+  bool skip_unset)
 {
-
-   switch (sym->type) {
+   switch (type) {
case S_BOOLEAN:
case S_TRISTATE:
if (*value == 'n') {
-   bool skip_unset = (arg != NULL);
-
if (!skip_unset)
fprintf(fp, "# %s%s is not set\n",
-   CONFIG_, sym->name);
+   CONFIG_, name);
return;
}
break;
@@ -537,7 +528,21 @@ kconfig_print_symbol(FILE *fp, struct symbol *sym, const 
char *value, void *arg)
break;
}
 
-   fprintf(fp, "%s%s=%s\n", CONFIG_, sym->name, value);
+   fprintf(fp, "%s%s=%s\n", CONFIG_, name, value);
+}
+
+/*
+ * Kconfig configuration printer
+ *
+ * This printer is used when generating the resulting configuration after
+ * kconfig invocation and `defconfig' files. Unset symbol might be omitted by
+ * passing a non-NULL argument to the printer.
+ *
+ */
+static void
+kconfig_print_symbol(FILE *fp, struct symbol *sym, const char *value, void 
*arg)
+{
+   print_makefile_sym(fp, sym->name, sym->type, value, arg != NULL);
 }
 
 static void
@@ -566,16 +571,12 @@ static struct conf_printer kconfig_printer_cb =
.print_comment = kconfig_print_comment,
 };
 
-/*
- * Header printer
- *
- * This printer is used when generating the `include/generated/autoconf.h' 
file.
- */
-static void
-header_print_symbol(FILE *fp, struct symbol *sym, const char *value, void *arg)
+/* Print a symbol for a header file */
+static void print_header_sym(FILE *fp, const char *name, enum symbol_type type,
+const char *value)
 {
 
-   switch (sym->type) {
+   switch (type) {
case S_BOOLEAN:
case S_TRISTATE: {
const char *suffix = "";
@@ -588,7 +589,7 @@ header_print_symbol(FILE *fp, struct symbol *sym, const 
char *value, void *arg)
/* fall through */
default:
fprintf(fp, "#define %s%s%s 1\n",
-   CONFIG_, sym->name, suffix);
+   CONFIG_, name, suffix);
}
break;
}
@@ -598,18 +599,28 @@ header_print_symbol(FILE *fp, struct symbol *sym, const 
char *value, void *arg)
if (value[0] != '0' || (value[1] != 'x' && value[1] != 'X'))
prefix = "0x";
fprintf(fp, "#define %s%s %s%s\n",
-   CONFIG_, sym->name, prefix, value);
+   CONFIG_, name, prefix, value);
break;
}
case S_STRING:
case S_INT:
fprintf(fp, "#define %s%s %s\n",
-   CONFIG_, sym->name, value);
+   CONFIG_, name, value);
break;
default:
break;
}
+}
 
+/*
+ * Header printer
+ *
+ * This printer is used when generating the `include/generated/autoconf.h' 
file.
+ */
+static void
+header_print_symbol(FILE *fp, struct symbol *sym, const char *value, void *arg)
+{
+   print_header_sym(fp, sym->name, sym->type, value);
 }
 
 static void
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index 7c329e17900..656c87fb4f3 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -158,6 +158,15 @@ struct symbol {
 /* Set symbol to y if allnoconfig; used for symbols that hide others */
 #define SYMBOL_ALLNOCONFIG_Y 0x20
 
+/* U-Boot: Marks an SPL symbol */
+#define SYMBOL_SPL 0x40
+
+/* U-Boot: Marks a non-SPL symbol that also has an SPL version */
+#define SYMBOL_HAS_SPL 0x80
+
+/* U-Boot: Marks an-SPL symbol that does not have a non-SPL version */
+#define 

[PATCH 13/17] Makefile: Include the config for the phase being built

[Simon Glass]

At present there is only a single auto.conf file used within the
makefiles. Update them to use the correct one for each phase.

Signed-off-by: Simon Glass 
---

 Makefile   | 11 ++-
 scripts/Makefile.build | 10 +-
 scripts/Makefile.spl   |  8 +++-
 3 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 3014788e14e..0bf846b5640 100644
--- a/Makefile
+++ b/Makefile
@@ -581,8 +581,17 @@ scripts: scripts_basic scripts_dtc include/config/auto.conf
$(Q)$(MAKE) $(build)=$(@)
 
 ifeq ($(dot-config),1)
-# Read in config
+
+# Read in the config for this phase
+ifdef CONFIG_TPL_BUILD
+-include include/config/auto_tpl.conf
+else
+ifdef CONFIG_SPL_BUILD
+-include include/config/auto_spl.conf
+else
 -include include/config/auto.conf
+endif
+endif
 
 # Read in dependencies to all Kconfig* files, make sure to run
 # oldconfig if changes are detected.
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 5df8f61aa58..aaa960b51ce 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -40,9 +40,17 @@ ldflags-y  :=
 subdir-asflags-y :=
 subdir-ccflags-y :=
 
-# Read auto.conf if it exists, otherwise ignore
+# Read appropriate auto.conf if it exists, otherwise ignore
 # Modified for U-Boot
+
+ifeq ($(SPL_NAME),tpl)
+-include include/config/auto_tpl.conf
+else ifeq ($(SPL_NAME),spl)
+-include include/config/auto_spl.conf
+else
 -include include/config/auto.conf
+endif
+
 -include $(prefix)/include/autoconf.mk
 include scripts/Makefile.uncmd_spl
 
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 25a3e7fa52e..02dd85b8e1c 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -19,9 +19,15 @@ _dummy := $(shell [ -d $(obj) ] || mkdir -p $(obj))
 
 include $(srctree)/scripts/Kbuild.include
 
--include include/config/auto.conf
 -include $(obj)/include/autoconf.mk
 
+# Read in the config for this SPL phase
+ifdef CONFIG_TPL_BUILD
+-include include/config/auto_tpl.conf
+else
+-include include/config/auto_spl.conf
+endif
+
 UBOOTINCLUDE := -I$(obj)/include $(UBOOTINCLUDE)
 
 KBUILD_CPPFLAGS += -DCONFIG_SPL_BUILD
-- 
2.33.0.309.g3052b89438-goog

[PATCH 09/17] serial: Tidy up the Makefile condition for DM_SERIAL

[Simon Glass]

There is no need to check for SPL/TPL build again as the 'ifdef' above
does this already. Drop it, so that the build rule works with split
configs.

Signed-off-by: Simon Glass 
---

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

diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 3cbea8156f8..4b723faf79b 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -5,7 +5,7 @@
 
 ifdef CONFIG_SPL_BUILD
 
-ifeq ($(CONFIG_$(SPL_TPL_)BUILD)$(CONFIG_$(SPL_TPL_)DM_SERIAL),yy)
+ifeq ($(CONFIG_$(SPL_TPL_)DM_SERIAL),y)
 obj-y += serial-uclass.o
 else
 obj-y += serial.o
-- 
2.33.0.309.g3052b89438-goog

[PATCH 08/17] sandbox: Enable MISC support for the SPL build

[Simon Glass]

At present this is always enabled in SPL by virtue of the Makefile
condition, which ignores SPL. Add the required config to tidy this up,
so it will works with split configs.

Signed-off-by: Simon Glass 
---

 configs/sandbox_noinst_defconfig | 1 +
 configs/sandbox_spl_defconfig| 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/sandbox_noinst_defconfig b/configs/sandbox_noinst_defconfig
index 88443f5ab27..b1f3737bb01 100644
--- a/configs/sandbox_noinst_defconfig
+++ b/configs/sandbox_noinst_defconfig
@@ -131,6 +131,7 @@ CONFIG_LED_GPIO=y
 CONFIG_DM_MAILBOX=y
 CONFIG_SANDBOX_MBOX=y
 CONFIG_MISC=y
+CONFIG_SPL_MISC=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_I2C=y
 CONFIG_CROS_EC_LPC=y
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index 77dd83cf6fd..1e54edf66ac 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -133,6 +133,7 @@ CONFIG_LED_GPIO=y
 CONFIG_DM_MAILBOX=y
 CONFIG_SANDBOX_MBOX=y
 CONFIG_MISC=y
+CONFIG_SPL_MISC=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_I2C=y
 CONFIG_CROS_EC_LPC=y
-- 
2.33.0.309.g3052b89438-goog

[PATCH 06/17] power: Add SPL Kconfig for sandbox pmc emulator

[Simon Glass]

At present we rely on this not existing to avoid building the emulator for
SPL.

But with the new split configs this does not work. Add a separate Kconfig
instead.

Signed-off-by: Simon Glass 
---

 drivers/power/acpi_pmc/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/power/acpi_pmc/Kconfig b/drivers/power/acpi_pmc/Kconfig
index fcd50e36cad..d3f363b0dcf 100644
--- a/drivers/power/acpi_pmc/Kconfig
+++ b/drivers/power/acpi_pmc/Kconfig
@@ -32,3 +32,8 @@ config ACPI_PMC_SANDBOX
  the uclass logic can be tested. You can use the 'pmc' command to
  access information from the driver. It uses I/O access to read
  from the PMC.
+
+config SPL_ACPI_PMC_SANDBOX
+   def_bool n
+   help
+ Dummy option to ensure that this feature is not enabled in SPL.
-- 
2.33.0.309.g3052b89438-goog

[PATCH 07/17] test: Add SPL Kconfig for compression tests

[Simon Glass]

At present we rely on this not existing to avoid building these tests for
SPL.

But with the new split configs this does not work. Add a separate Kconfig
instead.

Signed-off-by: Simon Glass 
---

 test/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/test/Kconfig b/test/Kconfig
index e15ba239eb3..52d85ca78a2 100644
--- a/test/Kconfig
+++ b/test/Kconfig
@@ -69,6 +69,11 @@ config UT_COMPRESSION
  Enables tests for compression and decompression routines for simple
  sanity and for buffer overflow conditions.
 
+config SPL_UT_COMPRESSION
+   def_bool n
+   help
+ Dummy option to ensure that this feature is not enabled in SPL.
+
 config UT_LOG
bool "Unit tests for logging functions"
depends on UNIT_TEST
-- 
2.33.0.309.g3052b89438-goog

[PATCH 05/17] cros_ec: Add SPL Kconfigs for cros_ec features

[Simon Glass]

At present we rely on this not existing to avoid building various
EC features.

But with the new split configs this does not work. Add separates Kconfigs
instead.

Signed-off-by: Simon Glass 
---

 drivers/i2c/Kconfig | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 63d03a3cebf..4c3a084b4f8 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -57,6 +57,11 @@ config I2C_CROS_EC_TUNNEL
  I2C or LPC). Some Chromebooks use this when the hardware design
  does not allow direct access to the main PMIC from the AP.
 
+config SPL_I2C_CROS_EC_TUNNEL
+   def_bool n
+   help
+ Dummy option to ensure that this feature is not enabled in SPL.
+
 config I2C_CROS_EC_LDO
bool "Provide access to LDOs on the Chrome OS EC"
depends on CROS_EC
@@ -71,6 +76,11 @@ config I2C_CROS_EC_LDO
avoid duplicating the logic in the TPS65090 regulator driver for
enabling/disabling an LDO.
 
+config SPL_I2C_CROS_EC_LDO
+   def_bool n
+   help
+ Dummy option to ensure that this feature is not enabled in SPL.
+
 config I2C_SET_DEFAULT_BUS_NUM
bool "Set default I2C bus number"
depends on DM_I2C
-- 
2.33.0.309.g3052b89438-goog

[PATCH 03/17] acpi: Add a Kconfig for SPL

[Simon Glass]

At present we rely on this not existing to avoid building ACPI for SPL.
But with the new split configs this does not work. Add a separate Kconfig
instead.

Signed-off-by: Simon Glass 
---

 drivers/core/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 9ae188c1dfc..4c2aeb8bce5 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -332,6 +332,11 @@ config ACPIGEN
  things like generating device-specific tables and returning the ACPI
  name of a device.
 
+config SPL_ACPIGEN
+   def_bool n
+   help
+ Dummy option to ensure that ACPI tables are not generated in SPL.
+
 config BOUNCE_BUFFER
bool "Include bounce buffer API"
help
-- 
2.33.0.309.g3052b89438-goog

[PATCH 04/17] cmd: Add an SPL Kconfig for CMDLINE and HUSH

[Simon Glass]

At present we rely on this not existing to avoid building various
command-line features.

But with the new split configs this does not work. Add separates Kconfigs
instead.

Signed-off-by: Simon Glass 
---

 cmd/Kconfig | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3a857b3f6e2..f469739a5fe 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -23,6 +23,16 @@ config HUSH_PARSER
  If disabled, you get the old, much simpler behaviour with a somewhat
  smaller memory footprint.
 
+config SPL_CMDLINE
+   def_bool n
+   help
+ Dummy option to ensure that the command line is not enabled in SPL.
+
+config SPL_HUSH_PARSER
+   def_bool n
+   help
+ Dummy option to ensure that the hush parser is not enabled in SPL.
+
 config CMDLINE_EDITING
bool "Enable command line editing"
depends on CMDLINE
-- 
2.33.0.309.g3052b89438-goog

[PATCH 01/17] env: Avoid checking ENV_IS_IN when env disabled

[Simon Glass]

This check is not needed when the environment is not enabled, e.g. in
SPL. Add a condition to handle this.

Signed-off-by: Simon Glass 
---

 cmd/nvedit.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index ddc715b4f91..1c8d49646e5 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -62,11 +62,13 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #endif
 
+#if CONFIG_IS_ENABLED(ENV_SUPPORT)
 #if!defined(ENV_IS_IN_DEVICE)  && \
!defined(CONFIG_ENV_IS_NOWHERE)
 # error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|MMC|FAT|EXT4|\
 NAND|NVRAM|ONENAND|SATA|SPI_FLASH|REMOTE|UBI} or CONFIG_ENV_IS_NOWHERE
 #endif
+#endif /* ENV_SUPPORT */
 
 /*
  * Maximum expected input data size for import command
-- 
2.33.0.309.g3052b89438-goog

[PATCH 02/17] x86: Fix qemu condition for arch_cpu_init()

[Simon Glass]

This is written incorrectly, since SPL_ should not be used with the
CONFIG_IS_ENABLED macro. Fix it by dropping the prefix and inverting the
logic, which produces the same result as now.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/qemu/qemu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c
index e54082df7f9..274978c023b 100644
--- a/arch/x86/cpu/qemu/qemu.c
+++ b/arch/x86/cpu/qemu/qemu.c
@@ -97,7 +97,7 @@ static void qemu_chipset_init(void)
}
 }
 
-#if !CONFIG_IS_ENABLED(SPL_X86_32BIT_INIT)
+#if CONFIG_IS_ENABLED(X86_32BIT_INIT)
 int arch_cpu_init(void)
 {
post_code(POST_CPU_INIT);
-- 
2.33.0.309.g3052b89438-goog

[PATCH 00/17] RFC: Split configs between U-Boot proper and SPL builds

[Simon Glass]

At present a single .config file is used to configure the build for all
phases, with SPL phases having a SPL_ or TPL_ prefix on each CONFIG to
indicate which build it controls.

So, for example, we have CONFIG_MISC and CONFIG_SPL_MISC to control the
inclusion of MISC drivers in each phase.

>From this .config a few other files are generated (by the kconfig tool)
for use with make and from C code (auto.conf and autoconf.h).

This all  works well but is a bit ugly in places, for example requiring
the use of a SPL_TPL_ macro in Makefiles to distinguish between options
intended for SPL and U-Boot proper.

In discussions with trini the idea came up of creating separate config
files for each type of build. So instead of using SPL_ or TPL_ prefixes,
each build includes its own files with the config it needs.

This series takes a pass at implementing this. It makes only minor changes
to the existing Kconfig files, to make things work, but updates the
kconfig tool to output seperate files for each phase. These changes may
need reworking to send upstream.

With this series, SPL_TPL_ resolves to an empty value, so it is possible
to drop this macro.

This cannot be applied as is. Any ad-hoc CONFIG options break the logic
in this series, since these are not processed by the kconfig tool. A
special xSPL_TPL_ macro is added to show this problem.

A run indicative of the current state (without the last patch, which
breaks everything) is here:

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

Once CONFIG migration is completed, something along these lines can be
applied.


Simon Glass (17):
  env: Avoid checking ENV_IS_IN when env disabled
  x86: Fix qemu condition for arch_cpu_init()
  acpi: Add a Kconfig for SPL
  cmd: Add an SPL Kconfig for CMDLINE and HUSH
  cros_ec: Add SPL Kconfigs for cros_ec features
  power: Add SPL Kconfig for sandbox pmc emulator
  test: Add SPL Kconfig for compression tests
  sandbox: Enable MISC support for the SPL build
  serial: Tidy up the Makefile condition for DM_SERIAL
  virtio: Add SPL Kconfig for virtio
  kconfig: Refactor code into separate writer functions
  kconfig: Support writing separate SPL files
  Makefile: Include the config for the phase being built
  Makefile: Use empty SPL_ and SPL_TPL_ vars
  Makefile: Support ad-hoc COMFIX_SPL_IMAGE_SIZE et al
  kconfig: Update CONFIG_IS_ENABLED() for split files
  kconfig: Add a new CONFIG() macro

 Makefile |  11 +-
 arch/x86/cpu/qemu/qemu.c |   2 +-
 cmd/Kconfig  |  10 ++
 cmd/nvedit.c |   2 +
 configs/sandbox_noinst_defconfig |   1 +
 configs/sandbox_spl_defconfig|   1 +
 drivers/core/Kconfig |   5 +
 drivers/i2c/Kconfig  |  10 ++
 drivers/power/acpi_pmc/Kconfig   |   5 +
 drivers/serial/Makefile  |   2 +-
 drivers/virtio/Kconfig   |   6 +
 include/linux/kconfig.h  |  91 +++---
 scripts/Kbuild.include   |  17 +-
 scripts/Makefile.build   |  10 +-
 scripts/Makefile.spl |  33 +++-
 scripts/kconfig/conf.c   |   4 +
 scripts/kconfig/confdata.c   | 286 ---
 scripts/kconfig/expr.h   |   9 +
 scripts/kconfig/lkc.h|   9 +
 test/Kconfig |   5 +
 20 files changed, 408 insertions(+), 111 deletions(-)

-- 
2.33.0.309.g3052b89438-goog

[PATCH] m68k: Add missing ENTRY entry in linker script

[Tom Rini]

Currently, there is no ENTRY() entry in the m68k linker script.
However, since they currently contain a version_string symbol, which
then overrides the default weak version_string symbol, the linker
decides we must keep start.o in the resulting link.  Add an ENTRY() line
so that the linker will know to keep this, even when version_string is
no longer provided in start.S

Cc: Huan Wang 
Cc: Angelo Dureghello 
Signed-off-by: Tom Rini 
---
 arch/m68k/cpu/u-boot.lds | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/m68k/cpu/u-boot.lds b/arch/m68k/cpu/u-boot.lds
index 64cf2ff5ef97..affb2d937464 100644
--- a/arch/m68k/cpu/u-boot.lds
+++ b/arch/m68k/cpu/u-boot.lds
@@ -9,6 +9,7 @@
 #include 
 
 OUTPUT_ARCH(m68k)
+ENTRY(_start)
 
 #ifndef LDS_BOARD_TEXT
 #define LDS_BOARD_TEXT
-- 
2.17.1

Re: [PATCH] distro_bootcmd: change the default dtb search path to include default kernel dtbs directory

[Qu Wenruo]

On 2021/9/17 22:25, Mark Kettenis wrote:

Date: Fri, 17 Sep 2021 19:42:29 +0800
Content-Language: en-US

On 2021/9/17 19:34, Mark Kettenis wrote:

From: Qu Wenruo 
Date: Fri, 17 Sep 2021 19:02:35 +0800

When booting using U-boot -> systemd-boot (EFI payload) -> kernel on
RK3399, systemd-boot by some bug can't execute its "devicetree" key
correctly to load its proper dtb from files.

In that case, it will use fallback dtb from U-boot, which can be
out-of-date, and on RK3399, even the latest U-boot contains out-of-date
dtb which can cause problems like invalid opp tables.

And for systemd-boot, it doesn't provide any board specific dtb, but
completely relies on the EFI environment provided by U-boot, thus if we
can't find a good dtb, the fallback one will be used anyway.

So this patch will workaround the problem by appending common linux dtbs
directory to the existing "efi_dtb_prefixes" so that for systemd-boot it
can use the existing fdt and boot properly.


Why isn't the dtb installed in the standard location?


Isn't standard location "/dtbs" other than "/dtb"?

At least kernel puts its dtbs into "/dtbs" by default.


Hmm, well, when I Alexander Graf introduced the code to load an
updated DTB the intention was clearly to load it from the EFI System
Partition (ESP).  I doubt that's where "the kernel" sticks them by
default.  So I suspect the intention is that you copy the DTB to the
/dtb directory on the ESP if needed.  Clearly that isn't what you've
done on your system.


Well, for this U-boot > systemd-boot > kernel loading scheme,
systemd-boot is responsible to load the fdt.

But for now (the latest stable release), it doesn't support fdt loading
at all, and only recently get the ability:
https://github.com/systemd/systemd/pull/19417

So in theory, it doesn't need any fdt for systemd-boot.

It's more like a workaround (and not really needed now).



I suspect things have moved on a bit as the discussion in the systemd
thread shows.  One of the new developments is the EFI_DT_FIXUP_PROCOL
feature that is clearly targeted at EFI bootloaders picking and
loading the DT instead of U-Boot.


Yep, I didn't notice the development in systemd part.



In this light I would be somewhat reluctant adding more directories to
efi_dtb_prefixes.


Yeah, please discard the patch, it's really a workaround and not needed
anymore.

Thanks,
Qu




Slowing the boot process down because distro's can't agree where to
put the files is a bit lame...


Would it be better to make the search path configurable at config time?

By that each distro should config their dtbs search path, which could
further optimize the boot sequence by removing all other unnecessary
prefixes.


Not in my opinion.  I consider it a bad thing if people configure
U-Boot specifically for their distro.  The whole idea of distroboot
and EFI in U-Boot is to be able to boot just any OS with a generic
U-Boot binary.


Thanks,
Qu




Signed-off-by: Qu Wenruo 
---
   include/config_distro_bootcmd.h | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 2627c2a6a541..4ec87483eb65 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -151,7 +151,7 @@
"load ${devtype} ${devnum}:${distro_bootpart} "   \
"${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
\
-   "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
+   "efi_dtb_prefixes=/ /dtb/ /dtb/current/ /dtbs/ /dtbs/current/\0"  \
"scan_dev_for_efi="   \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
--
2.33.0

Re: [PATCH] distro_bootcmd: change the default dtb search path to include default kernel dtbs directory

[Mark Kettenis]

> Date: Fri, 17 Sep 2021 19:42:29 +0800
> Content-Language: en-US
> 
> On 2021/9/17 19:34, Mark Kettenis wrote:
> >> From: Qu Wenruo 
> >> Date: Fri, 17 Sep 2021 19:02:35 +0800
> >>
> >> When booting using U-boot -> systemd-boot (EFI payload) -> kernel on
> >> RK3399, systemd-boot by some bug can't execute its "devicetree" key
> >> correctly to load its proper dtb from files.
> >>
> >> In that case, it will use fallback dtb from U-boot, which can be
> >> out-of-date, and on RK3399, even the latest U-boot contains out-of-date
> >> dtb which can cause problems like invalid opp tables.
> >>
> >> And for systemd-boot, it doesn't provide any board specific dtb, but
> >> completely relies on the EFI environment provided by U-boot, thus if we
> >> can't find a good dtb, the fallback one will be used anyway.
> >>
> >> So this patch will workaround the problem by appending common linux dtbs
> >> directory to the existing "efi_dtb_prefixes" so that for systemd-boot it
> >> can use the existing fdt and boot properly.
> >
> > Why isn't the dtb installed in the standard location?
> 
> Isn't standard location "/dtbs" other than "/dtb"?
> 
> At least kernel puts its dtbs into "/dtbs" by default.

Hmm, well, when I Alexander Graf introduced the code to load an
updated DTB the intention was clearly to load it from the EFI System
Partition (ESP).  I doubt that's where "the kernel" sticks them by
default.  So I suspect the intention is that you copy the DTB to the
/dtb directory on the ESP if needed.  Clearly that isn't what you've
done on your system.

I suspect things have moved on a bit as the discussion in the systemd
thread shows.  One of the new developments is the EFI_DT_FIXUP_PROCOL
feature that is clearly targeted at EFI bootloaders picking and
loading the DT instead of U-Boot.

In this light I would be somewhat reluctant adding more directories to
efi_dtb_prefixes.

> > Slowing the boot process down because distro's can't agree where to
> > put the files is a bit lame...
> 
> Would it be better to make the search path configurable at config time?
> 
> By that each distro should config their dtbs search path, which could
> further optimize the boot sequence by removing all other unnecessary
> prefixes.

Not in my opinion.  I consider it a bad thing if people configure
U-Boot specifically for their distro.  The whole idea of distroboot
and EFI in U-Boot is to be able to boot just any OS with a generic
U-Boot binary.

> Thanks,
> Qu
> 
> >
> >> Signed-off-by: Qu Wenruo 
> >> ---
> >>   include/config_distro_bootcmd.h | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/config_distro_bootcmd.h 
> >> b/include/config_distro_bootcmd.h
> >> index 2627c2a6a541..4ec87483eb65 100644
> >> --- a/include/config_distro_bootcmd.h
> >> +++ b/include/config_distro_bootcmd.h
> >> @@ -151,7 +151,7 @@
> >>"load ${devtype} ${devnum}:${distro_bootpart} "   \
> >>"${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
> >>\
> >> -  "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
> >> +  "efi_dtb_prefixes=/ /dtb/ /dtb/current/ /dtbs/ /dtbs/current/\0"  \
> >>"scan_dev_for_efi="   \
> >>"setenv efi_fdtfile ${fdtfile}; " \
> >>BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
> >> --
> >> 2.33.0
> >>
> >>
> 

Re: [PATCH v3 2/2] mtd: spi: nor: force mtd name to "nor%d"

[Marek Vasut]

On 9/17/21 3:06 PM, Patrick DELAUNAY wrote:

Hi Marek,

 > Marek VasutSept. 16, 2021, 5:27 p.m. UTC | #3
 > On 9/16/21 4:01 PM, Patrick Delaunay wrote:

 > [...]

 > > @@ -3664,6 +3666,11 @@ int spi_nor_scan(struct spi_nor *nor)
 > >       struct mtd_info *mtd = >mtd;
 > >       struct spi_slave *spi = nor->spi;
 > >       int ret;
 > > +    int cfi_mtd_nb = 0;
 > > +
 > > +#ifdef CONFIG_SYS_MAX_FLASH_BANKS
 > > +    cfi_mtd_nb = CONFIG_SYS_MAX_FLASH_BANKS;
 > > +#endif

 > Are we covering all the NORs (HF and co.) with this ?


Yes, except if I miss something


any NOR (including hyperflash) wich use the CFI interface / 
CONFIG_FLASH_CFI_MTD


define the the 'nor%d' name with the calling stack:


Yes


initr_flash()

=> flash_init()

==> cfi_flash_init_dm()

==> cfi_mtd_init()   "nor%d" wich use loop on CONFIG_SYS_MAX_FLASH_BANKS


I have only one concern today...


if one cfi bank is missing (not activated in DT by example)

and CONFIG_SYS_MAX_FLASH_BANKS_DETECT is not activated

some holes can be done in index


example:

with CONFIG_SYS_MAX_FLASH_BANKS = 2 but with only one NOR on the board

=> "nor1" is absent and we have only 2 MTD device named "nor"

- "nor0" => NOR or HF, first CFI bank

- "nor2" => SPI-NOR (first)


but I don't think that it is blocking


Wasn't the old behavior exactly the same anyway ?


 > >       /* Reset SPI protocol for all commands. */
 > >       nor->reg_proto = SNOR_PROTO_1_1_1;
 > > @@ -3715,8 +3722,10 @@ int spi_nor_scan(struct spi_nor *nor)
 > >       if (ret)
 > >           return ret;
 > >
 > > -    if (!mtd->name)
 > > -        mtd->name = info->name;
 > > +    if (!mtd->name) {
 > > +        sprintf(nor->mtd_name, "nor%d",  cfi_mtd_nb + 
dev_seq(nor->dev));

 > > +        mtd->name = nor->mtd_name;
 > > +    }
 > >       mtd->dev = nor->dev;
 > >       mtd->priv = nor;
 > >       mtd->type = MTD_NORFLASH;
 > > @@ -3821,7 +3830,7 @@ int spi_nor_scan(struct spi_nor *nor)
 > >
 > >       nor->rdsr_dummy = params.rdsr_dummy;
 > >       nor->rdsr_addr_nbytes = params.rdsr_addr_nbytes;
 > > -    nor->name = mtd->name;
 > > +    nor->name = info->name;
 > >       nor->size = mtd->size;
 > >       nor->erase_size = mtd->erasesize;
 > >       nor->sector_size = mtd->erasesize;
 > > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
 > > index 7ddc4ba2bf..8c3d5032e3 100644
 > > --- a/include/linux/mtd/spi-nor.h
 > > +++ b/include/linux/mtd/spi-nor.h
 > > @@ -561,6 +561,7 @@ struct spi_nor {
 > >       int (*ready)(struct spi_nor *nor);
 > >
 > >       void *priv;
 > > +    char mtd_name[10];

 > should be 14, because nor%d\0 can be up to 14 bytes long.

normally DM_MAX_SEQ = 999 (but never used)

but Ok with you for 14 with "nor" = 3 + "%d" = 10 for max u32 value + 
"/0" = 1



for cfi_mtd_names => 16 byte used with "nor%d"

     static char cfi_mtd_names[CFI_MAX_FLASH_BANKS][16];

for nand => 8 bytes (./drivers/mtd/nand/raw/nand.c:59)

     static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];

for spi-nand => 20 bytes (drivers/mtd/nand/spi/core.c:1169)

     mtd->name = malloc(20);


Maybe we need a macro for this length of DM seq string which we could 
use in these embedded array cases.

Re: [PATCH v3 1/2] mtd: cfi_flash: use cfi_flash_num_flash_banks only when supported

[Marek Vasut]

On 9/17/21 12:55 PM, Patrick DELAUNAY wrote:

Hi Marek,

 > Marek VasutSept. 16, 2021, 5:24 p.m. UTC | #1

 > On 9/16/21 4:01 PM, Patrick Delaunay wrote:

 >> When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated,
 >> CONFIG_SYS_MAX_FLASH_BANKS is replaced by cfi_flash_num_flash_banks,
 >> but this variable is defined in drivers/mtd/cfi_flash.c, which is
 >> compiled only when CONFIG_FLASH_CFI_DRIVER is activated, in U-Boot
 >> or in SPL when CONFIG_SPL_MTD_SUPPORT is activated.
 >>
 >> This patch deactivates this feature CONFIG_SYS_MAX_FLASH_BANKS_DETECT
 >> when flash cfi driver is not activated to avoid compilation issue in
 >> the next patch, when CONFIG_SYS_MAX_FLASH_BANKS is used in 
spi_nor_scan().


 > Maybe just migrate this config option to Kconfig and let Kconfig handle
 > the macro magic ?


Sorry for the format  of my answer (it is just copy paste from archive)

because I don't received the U-Boot mails on my @foss.st.com mailbo

since yesterday.


I think about migration but is difficult to don't break the existing 
behaviour in kconfig


CONFIG_SYS_MAX_FLASH_BANKS and CONFIG_SYS_MAX_FLASH_BANKS_DETECT are 
define as 'int'


but can be absent => 2 new config CONFIG_USE need to be added

CONFIG_USE_SYS_MAX_FLASH_BANKS

CONFIG_USE_SYS_MAX_FLASH_BANKS_DETECT


and I don't fully understood the mix between the 2 options and 
CFI_MAX_FLASH_BANKS


in some part of code I think CONFIG_SYS_MAX_FLASH_BANKS should be 
replaced by CFI_MAX_FLASH_BANKS


to avoid to define CONFIG_SYS_MAX_FLASH_BANKS = 
cfi_flash_num_flash_banks (as it is not possible in Kconfig)



=> too huge task just to solve compilation issues.


and I also think to use CONFIG_IS_ENABLED(MTD_SUPPORT)

but it not possible because today

- CONFIG_SPL_MTD_SUPPORT exist

- CONFIG_MTD_SUPPORT don't exit ( test on $(mtd-y) in Makefile)


=> the creation of this config is a huge task just to solve compilation 
issue.


All right, well, ew.

Can you send a subsequent patchset _after_ this one to fix this flash 
banks mess ?

Re: [ANN] U-Boot v2021.10-rc4 released

[Tom Rini]

On Fri, Sep 17, 2021 at 08:29:07AM +0200, Christophe Leroy wrote:

> Hi Tom,
> 
> Le 15/09/2021 à 01:01, Tom Rini a écrit :
> > Hey all,
> > 
> > Alright, I'm a day late, but, here's v2021.10-rc4.  We've had a few
> > regressions pop up of late, unfortunately.  I've pushed the fix for
> > (what I believe are) existing FIT images showing a problem where we
> > calculated the crc32 wrong.  And we're just now starting to figure out
> > the proper fix for a problem that was introduced late in v2021.07 with
> > SPI buses not being configured in the right mode (or in Linux Kernel
> > terms, spi-cpha/spi-cpol being set on platforms where that's not
> > correct).
> > 
> > In terms of a changelog,
> > git log --merges v2021.10-rc3..v2021.10-rc4
> > contains what I've pulled but as always, better PR messages and tags
> > will provide better results here.
> > 
> > We should be releasing on October 4th, 2021 as expected.  Thanks all!
> 
> Commit 3b84809b7b ("MAINTAINERS: POWERPC MPC8XX: Update email address") has
> been washed-out by commit 047e31ed4b ("led: led_cortina: Add CAxxx LED
> support").
> 
> Can you please re-apply it

Queued up for my next push now.

-- 
Tom


signature.asc
Description: PGP signature

Re: [systemd-devel] Systemd-boot not properly loading device tree, when loaded by U-boot (ARM64, tested on RK3399)

[Qu Wenruo]

On 2021/9/17 19:45, Lennart Poettering wrote:

On Fr, 17.09.21 19:25, Qu Wenruo (w...@suse.com) wrote:


Hi,

I'm recently testing booting my RK3399 boards with the following boot
sequence:

U-boot -> systemd-boot (EFI payload) -> kernel

Which provides much more flex than plain extlinux conf from U-boot.
(More choice, easier to write config, runtime kernel change).

So far "kernel" and "initramfs" key work fine.

But I notice that "devicetree" key is not working properly.

The Uboot fdt search path doesn't include "/dtbs" which is used by my
distro, and my entry config specify the device-tree file like this:

titleManjaroARM boot from nvme
linux/Image
devicetree/dtbs/rockchip/rk3399-rockpro64.dtb
initrd/initramfs-linux.img
optionsconsole=ttyS2,150 root=/dev/arm_nvme/root rw loglevel=7

Thus if systemd-boot doesn't load the correct device-tree, kernel will
use the default fdt passed from Uboot, which is already out-of-date and
can cause problems for the upstream kernel I used.

Unfortunately, with above config, after booting the kernel, the fdt is
the fallback one from Uboot, not loading the proper one specified by
systemd-boot config.

The proof I went is checking the opp table.
I have replaced the "/dtbs/rockchip/rk3399-rockpro64.dtb" with a custom
dtb which uses op1 tables.
But the kernel only sees a very out-of-dated fdt, which some opp is even
invalid.

How could I continue debugging the missing link?
Like what systemd-boot needs to load the device-tree? Or U-boot EFI
environment lacks certain facility to support systemd-boot?


Did you see this:

https://github.com/systemd/systemd/pull/19417


Confirmed this pull fixes the problem.

I only need to wait for next release to get it from my distro.

Awesome!

Thanks,
Qu



(and maybe this: https://github.com/systemd/systemd/pull/20601)

maybe that addresses your issues?

Lennart

--
Lennart Poettering, Berlin

[PATCH v3 2/2] spi: rockchip_sfc: Using read_poll

[Jon Lin]

Using read_poll logic.

Tested-by: Chris Morgan 
Signed-off-by: Jon Lin 
---

(no changes since v2)

Changes in v2:
- Fix assigned but never used return error codes

 drivers/spi/rockchip_sfc.c | 67 --
 1 file changed, 35 insertions(+), 32 deletions(-)

diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c
index 94222df5ce..e098ac 100644
--- a/drivers/spi/rockchip_sfc.c
+++ b/drivers/spi/rockchip_sfc.c
@@ -285,33 +285,38 @@ err_init:
return ret;
 }
 
-static inline int rockchip_sfc_get_fifo_level(struct rockchip_sfc *sfc, int wr)
+static int rockchip_sfc_wait_txfifo_ready(struct rockchip_sfc *sfc, u32 
timeout_us)
 {
-   u32 fsr = readl(sfc->regbase + SFC_FSR);
-   int level;
+   int ret = 0;
+   u32 status;
 
-   if (wr)
-   level = (fsr & SFC_FSR_TXLV_MASK) >> SFC_FSR_TXLV_SHIFT;
-   else
-   level = (fsr & SFC_FSR_RXLV_MASK) >> SFC_FSR_RXLV_SHIFT;
+   ret = readl_poll_timeout(sfc->regbase + SFC_FSR, status,
+status & SFC_FSR_TXLV_MASK,
+timeout_us);
+   if (ret) {
+   dev_dbg(sfc->dev, "sfc wait tx fifo timeout\n");
+
+   return -ETIMEDOUT;
+   }
 
-   return level;
+   return (status & SFC_FSR_TXLV_MASK) >> SFC_FSR_TXLV_SHIFT;
 }
 
-static int rockchip_sfc_wait_fifo_ready(struct rockchip_sfc *sfc, int wr, u32 
timeout)
+static int rockchip_sfc_wait_rxfifo_ready(struct rockchip_sfc *sfc, u32 
timeout_us)
 {
-   unsigned long tbase = get_timer(0);
-   int level;
+   int ret = 0;
+   u32 status;
 
-   while (!(level = rockchip_sfc_get_fifo_level(sfc, wr))) {
-   if (get_timer(tbase) > timeout) {
-   debug("%s fifo timeout\n", wr ? "write" : "read");
-   return -ETIMEDOUT;
-   }
-   udelay(1);
+   ret = readl_poll_timeout(sfc->regbase + SFC_FSR, status,
+status & SFC_FSR_RXLV_MASK,
+timeout_us);
+   if (ret) {
+   dev_dbg(sfc->dev, "sfc wait rx fifo timeout\n");
+
+   return -ETIMEDOUT;
}
 
-   return level;
+   return (status & SFC_FSR_RXLV_MASK) >> SFC_FSR_RXLV_SHIFT;
 }
 
 static void rockchip_sfc_adjust_op_work(struct spi_mem_op *op)
@@ -429,7 +434,7 @@ static int rockchip_sfc_write_fifo(struct rockchip_sfc 
*sfc, const u8 *buf, int
 
dwords = len >> 2;
while (dwords) {
-   tx_level = rockchip_sfc_wait_fifo_ready(sfc, SFC_CMD_DIR_WR, 
1000);
+   tx_level = rockchip_sfc_wait_txfifo_ready(sfc, 1000);
if (tx_level < 0)
return tx_level;
write_words = min_t(u32, tx_level, dwords);
@@ -440,7 +445,7 @@ static int rockchip_sfc_write_fifo(struct rockchip_sfc 
*sfc, const u8 *buf, int
 
/* write the rest non word aligned bytes */
if (bytes) {
-   tx_level = rockchip_sfc_wait_fifo_ready(sfc, SFC_CMD_DIR_WR, 
1000);
+   tx_level = rockchip_sfc_wait_txfifo_ready(sfc, 1000);
if (tx_level < 0)
return tx_level;
memcpy(, buf, bytes);
@@ -461,7 +466,7 @@ static int rockchip_sfc_read_fifo(struct rockchip_sfc *sfc, 
u8 *buf, int len)
/* word aligned access only */
dwords = len >> 2;
while (dwords) {
-   rx_level = rockchip_sfc_wait_fifo_ready(sfc, SFC_CMD_DIR_RD, 
1000);
+   rx_level = rockchip_sfc_wait_rxfifo_ready(sfc, 1000);
if (rx_level < 0)
return rx_level;
read_words = min_t(u32, rx_level, dwords);
@@ -472,7 +477,7 @@ static int rockchip_sfc_read_fifo(struct rockchip_sfc *sfc, 
u8 *buf, int len)
 
/* read the rest non word aligned bytes */
if (bytes) {
-   rx_level = rockchip_sfc_wait_fifo_ready(sfc, SFC_CMD_DIR_RD, 
1000);
+   rx_level = rockchip_sfc_wait_rxfifo_ready(sfc, 1000);
if (rx_level < 0)
return rx_level;
tmp = readl(sfc->regbase + SFC_DATA);
@@ -533,19 +538,17 @@ static int rockchip_sfc_xfer_data_dma(struct rockchip_sfc 
*sfc,
 
 static int rockchip_sfc_xfer_done(struct rockchip_sfc *sfc, u32 timeout_us)
 {
-   unsigned long tbase = get_timer(0);
int ret = 0;
-   u32 timeout = timeout_us;
-
-   while (readl(sfc->regbase + SFC_SR) & SFC_SR_IS_BUSY) {
-   if (get_timer(tbase) > timeout) {
-   printf("wait sfc idle timeout\n");
-   rockchip_sfc_reset(sfc);
+   u32 status;
 
-   return -ETIMEDOUT;
-   }
+   ret = readl_poll_timeout(sfc->regbase + SFC_SR, status,
+!(status & SFC_SR_IS_BUSY),
+timeout_us);
+   if (ret) {
+ 

[PATCH v3 1/2] spi: rockchip_sfc: Implement set_speed logic

[Jon Lin]

Set clock related processing into set_speed logic. And Optimize
printing format.

Tested-by: Chris Morgan 
Signed-off-by: Jon Lin 
---

Changes in v3:
- Remove useless headfile
- Fix misspelling

 drivers/spi/rockchip_sfc.c | 82 ++
 1 file changed, 39 insertions(+), 43 deletions(-)

diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c
index 4e2b861f22..94222df5ce 100644
--- a/drivers/spi/rockchip_sfc.c
+++ b/drivers/spi/rockchip_sfc.c
@@ -116,6 +116,7 @@
 
 /* Master trigger */
 #define SFC_DMA_TRIGGER0x80
+#define SFC_DMA_TRIGGER_START  1
 
 /* Src or Dst addr for master */
 #define SFC_DMA_ADDR   0x84
@@ -163,14 +164,12 @@
 #define SFC_DMA_TRANS_THRETHOLD(0x40)
 
 /* Maximum clock values from datasheet suggest keeping clock value under
- * 150MHz. No minimum or average value is suggested, but the U-boot BSP driver
- * has a minimum of 10MHz and a default of 80MHz which seems reasonable.
+ * 150MHz. No minimum or average value is suggested.
  */
-#define SFC_MIN_SPEED_HZ   (10 * 1000 * 1000)
-#define SFC_DEFAULT_SPEED_HZ   (80 * 1000 * 1000)
-#define SFC_MAX_SPEED_HZ   (150 * 1000 * 1000)
+#define SFC_MAX_SPEED  (150 * 1000 * 1000)
 
 struct rockchip_sfc {
+   struct udevice *dev;
void __iomem *regbase;
struct clk hclk;
struct clk clk;
@@ -197,8 +196,6 @@ static int rockchip_sfc_reset(struct rockchip_sfc *sfc)
/* Still need to clear the masked interrupt from RISR */
writel(0x, sfc->regbase + SFC_ICLR);
 
-   debug("reset\n");
-
return err;
 }
 
@@ -261,15 +258,11 @@ static int rockchip_sfc_probe(struct udevice *bus)
 #if CONFIG_IS_ENABLED(CLK)
ret = clk_enable(>hclk);
if (ret)
-   debug("Enable ahb clock fail %s: %d\n", bus->name, ret);
+   dev_dbg(sfc->dev, "sfc Enable ahb clock fail %s: %d\n", 
bus->name, ret);
 
ret = clk_enable(>clk);
if (ret)
-   debug("Enable clock fail for %s: %d\n", bus->name, ret);
-
-   ret = clk_set_rate(>clk, SFC_DEFAULT_SPEED_HZ);
-   if (ret)
-   debug("Could not set sfc clock for %s: %d\n", bus->name, ret);
+   dev_dbg(sfc->dev, "sfc Enable clock fail for %s: %d\n", 
bus->name, ret);
 #endif
 
ret = rockchip_sfc_init(sfc);
@@ -278,7 +271,8 @@ static int rockchip_sfc_probe(struct udevice *bus)
 
sfc->max_iosize = rockchip_sfc_get_max_iosize(sfc);
sfc->version = rockchip_sfc_get_version(sfc);
-   sfc->speed = SFC_DEFAULT_SPEED_HZ;
+   sfc->max_freq = SFC_MAX_SPEED;
+   sfc->dev = bus;
 
return 0;
 
@@ -411,11 +405,11 @@ static int rockchip_sfc_xfer_setup(struct rockchip_sfc 
*sfc,
ctrl |= SFC_CTRL_PHASE_SEL_NEGETIVE;
cmd |= plat->cs << SFC_CMD_CS_SHIFT;
 
-   debug("addr.nbytes=%x(x%d) dummy.nbytes=%x(x%d)\n",
- op->addr.nbytes, op->addr.buswidth,
- op->dummy.nbytes, op->dummy.buswidth);
-   debug("ctrl=%x cmd=%x addr=%llx len=%x\n",
- ctrl, cmd, op->addr.val, len);
+   dev_dbg(sfc->dev, "sfc addr.nbytes=%x(x%d) dummy.nbytes=%x(x%d)\n",
+   op->addr.nbytes, op->addr.buswidth,
+   op->dummy.nbytes, op->dummy.buswidth);
+   dev_dbg(sfc->dev, "sfc ctrl=%x cmd=%x addr=%llx len=%x\n",
+   ctrl, cmd, op->addr.val, len);
 
writel(ctrl, sfc->regbase + SFC_CTRL);
writel(cmd, sfc->regbase + SFC_CMD);
@@ -492,7 +486,7 @@ static int rockchip_sfc_fifo_transfer_dma(struct 
rockchip_sfc *sfc, dma_addr_t d
 {
writel(0x, sfc->regbase + SFC_ICLR);
writel((u32)dma_buf, sfc->regbase + SFC_DMA_ADDR);
-   writel(0x1, sfc->regbase + SFC_DMA_TRIGGER);
+   writel(SFC_DMA_TRIGGER_START, sfc->regbase + SFC_DMA_TRIGGER);
 
return len;
 }
@@ -500,7 +494,7 @@ static int rockchip_sfc_fifo_transfer_dma(struct 
rockchip_sfc *sfc, dma_addr_t d
 static int rockchip_sfc_xfer_data_poll(struct rockchip_sfc *sfc,
   const struct spi_mem_op *op, u32 len)
 {
-   debug("xfer_poll len=%x\n", len);
+   dev_dbg(sfc->dev, "sfc xfer_poll len=%x\n", len);
 
if (op->data.dir == SPI_MEM_DATA_OUT)
return rockchip_sfc_write_fifo(sfc, op->data.buf.out, len);
@@ -516,7 +510,7 @@ static int rockchip_sfc_xfer_data_dma(struct rockchip_sfc 
*sfc,
void *dma_buf;
int ret;
 
-   debug("xfer_dma len=%x\n", len);
+   dev_dbg(sfc->dev, "sfc xfer_dma len=%x\n", len);
 
if (op->data.dir == SPI_MEM_DATA_OUT) {
dma_buf = (void *)op->data.buf.out;
@@ -564,33 +558,16 @@ static int rockchip_sfc_exec_op(struct spi_slave *mem,
u32 len = min_t(u32, op->data.nbytes, sfc->max_iosize);
int ret;
 
-#if CONFIG_IS_ENABLED(CLK)
-   if (unlikely(mem->max_hz != sfc->speed)) {
-   ret = 

Re: [PATCH v3 2/2] mtd: spi: nor: force mtd name to "nor%d"

[Patrick DELAUNAY]

Hi Marek,

> Marek VasutSept. 16, 2021, 5:27 p.m. UTC | #3
> On 9/16/21 4:01 PM, Patrick Delaunay wrote:

> [...]

> > @@ -3664,6 +3666,11 @@ int spi_nor_scan(struct spi_nor *nor)
> >       struct mtd_info *mtd = >mtd;
> >       struct spi_slave *spi = nor->spi;
> >       int ret;
> > +    int cfi_mtd_nb = 0;
> > +
> > +#ifdef CONFIG_SYS_MAX_FLASH_BANKS
> > +    cfi_mtd_nb = CONFIG_SYS_MAX_FLASH_BANKS;
> > +#endif

> Are we covering all the NORs (HF and co.) with this ?


Yes, except if I miss something


any NOR (including hyperflash) wich use the CFI interface / 
CONFIG_FLASH_CFI_MTD


define the the 'nor%d' name with the calling stack:


initr_flash()

=> flash_init()

==> cfi_flash_init_dm()

==> cfi_mtd_init()   "nor%d" wich use loop on CONFIG_SYS_MAX_FLASH_BANKS


I have only one concern today...


if one cfi bank is missing (not activated in DT by example)

and CONFIG_SYS_MAX_FLASH_BANKS_DETECT is not activated

some holes can be done in index


example:

with CONFIG_SYS_MAX_FLASH_BANKS = 2 but with only one NOR on the board

=> "nor1" is absent and we have only 2 MTD device named "nor"

- "nor0" => NOR or HF, first CFI bank

- "nor2" => SPI-NOR (first)


but I don't think that it is blocking


> >       /* Reset SPI protocol for all commands. */
> >       nor->reg_proto = SNOR_PROTO_1_1_1;
> > @@ -3715,8 +3722,10 @@ int spi_nor_scan(struct spi_nor *nor)
> >       if (ret)
> >           return ret;
> >
> > -    if (!mtd->name)
> > -        mtd->name = info->name;
> > +    if (!mtd->name) {
> > +        sprintf(nor->mtd_name, "nor%d",  cfi_mtd_nb + 
dev_seq(nor->dev));

> > +        mtd->name = nor->mtd_name;
> > +    }
> >       mtd->dev = nor->dev;
> >       mtd->priv = nor;
> >       mtd->type = MTD_NORFLASH;
> > @@ -3821,7 +3830,7 @@ int spi_nor_scan(struct spi_nor *nor)
> >
> >       nor->rdsr_dummy = params.rdsr_dummy;
> >       nor->rdsr_addr_nbytes = params.rdsr_addr_nbytes;
> > -    nor->name = mtd->name;
> > +    nor->name = info->name;
> >       nor->size = mtd->size;
> >       nor->erase_size = mtd->erasesize;
> >       nor->sector_size = mtd->erasesize;
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index 7ddc4ba2bf..8c3d5032e3 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -561,6 +561,7 @@ struct spi_nor {
> >       int (*ready)(struct spi_nor *nor);
> >
> >       void *priv;
> > +    char mtd_name[10];

> should be 14, because nor%d\0 can be up to 14 bytes long.

normally DM_MAX_SEQ = 999 (but never used)

but Ok with you for 14 with "nor" = 3 + "%d" = 10 for max u32 value + 
"/0" = 1



for cfi_mtd_names => 16 byte used with "nor%d"

    static char cfi_mtd_names[CFI_MAX_FLASH_BANKS][16];

for nand => 8 bytes (./drivers/mtd/nand/raw/nand.c:59)

    static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];

for spi-nand => 20 bytes (drivers/mtd/nand/spi/core.c:1169)

    mtd->name = malloc(20);


Patrick

Re: [PATCH 2/3] efi_loader: GOP: Add 30bpp support

[Mark Kettenis]

> From: Heinrich Schuchardt 
> Date: Fri, 17 Sep 2021 13:29:06 +0200
> 
> On 9/17/21 11:23 AM, Mark Kettenis wrote:
> >> From: Heinrich Schuchardt 
> >> Date: Fri, 17 Sep 2021 04:56:31 +0200
> >
> > Hi Heinrich,
> >
> >> On 9/16/21 3:01 PM, Mark Kettenis wrote:
> >>> Provide correct framebuffer information for 30bpp modes.
> >>
> >> This is not enough to get a correct GOP implementation for the 30bpp mode.
> >>
> >> Have a look at efi_gop_pixel efi_vid16_to_blt_col() and
> >> efi_blt_col_to_vid16() and where they are used.
> >
> > Ah right.  This does indeed not support EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt()
> > correctly.  I shouldn't be too hard to translate between XRGB2101010
> > and XRGB.  Any ideas how I could test that code?
> 
> setenv efi_selftest block image transfer
> bootefi selftest
> 
> should show an animated submarine with yellow portholes similar to
> 
> https://gist.github.com/xypron/7e1f73408465da71e3ef946250e76776#file-sub-png
> 
> Best regards

Cool thanks.  Looks like my implementation works!  I'll wait a bit for
feedback on the other diffs in this series before sending a v2 with that.

Cheers,

Mark

> >>> Signed-off-by: Mark Kettenis 
> >>> ---
> >>>lib/efi_loader/efi_gop.c | 10 ++
> >>>1 file changed, 10 insertions(+)
> >>>
> >>> diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
> >>> index 1206b2d7a2..42bf49b184 100644
> >>> --- a/lib/efi_loader/efi_gop.c
> >>> +++ b/lib/efi_loader/efi_gop.c
> >>> @@ -227,6 +227,7 @@ static efi_uintn_t gop_get_bpp(struct efi_gop *this)
> >>>
> >>>   switch (gopobj->bpix) {
> >>>#ifdef CONFIG_DM_VIDEO
> >>> + case VIDEO_BPP30:
> >>>   case VIDEO_BPP32:
> >>>#else
> >>>   case LCD_COLOR32:
> >>> @@ -468,6 +469,7 @@ efi_status_t efi_gop_register(void)
> >>>   switch (bpix) {
> >>>#ifdef CONFIG_DM_VIDEO
> >>>   case VIDEO_BPP16:
> >>> + case VIDEO_BPP30:
> >>>   case VIDEO_BPP32:
> >>>#else
> >>>   case LCD_COLOR32:
> >>> @@ -518,6 +520,14 @@ efi_status_t efi_gop_register(void)
> >>>#endif
> >>>   {
> >>>   gopobj->info.pixel_format = EFI_GOT_BGRA8;
> >>> +#ifdef CONFIG_DM_VIDEO
> >>
> >> This symbol is not 30bpp specific. Is there a Kconfig variable that we
> >> can use to hide 30bpp support where it is not needed?
> >
> > I quite deliberately didn't add a separate config option for 30bpp as
> > there is very little code that is added to the already existing 32bpp
> > code.  In a sense 30bpp is just a different submode of the 32bpp
> > support with just a different color map, so I thought it made sense to
> > group it under CONFIG_VIDEO_32BPP.  I did initially consider adding a
> > separate config option for it, but it quickly turns into an #ifdef
> > maze that makes it hard to understand the code.
> >
> > The CONFIG_DM_VIDEO check is just there to make sure the 30bpp is only
> > offered in the DM model.  Based on recent discussions I expect the
> > !CONFIG_DM_VIDEO case to disappear in the near feature so adding 30bpp
> > support for the non-DM case doesn't make sense.
> >
> > The EFI GOP code currently doesn't check the CONFIG_VIDEO_BPP16 and
> > CONFIG_VIDEO_BPP32 defines to see which of these modes are enabled
> > within U-Boot, so we don't "hide" 16bpp support on platforms that just
> > support 32bpp either.
> >
> >> Which modes does the M1 support?
> >
> > We're not sure.  It does support at least 8-bit (32bpp) and 10-bit
> > (30bpp) color depth modes.  But the firmware tends to come up with
> > 10-bit color depth whenever it can and I'm not planning to add support
> > for changing the framebuffer mode on the M1, since the interface to do
> > that is "interesting" [1].
> >
> > [1] See Alyssa Rozenzweig's talk at XDC 2021,
> >  https://www.youtube.com/watch?v=uTZISTjqy9Q
> >>
> >>> + } else if (bpix == VIDEO_BPP30) {
> >>> + gopobj->info.pixel_format = EFI_GOT_BITMASK;
> >>> + gopobj->info.pixel_bitmask[0] = 0x3ff0; /* red */
> >>> + gopobj->info.pixel_bitmask[1] = 0x000ffc00; /* green */
> >>> + gopobj->info.pixel_bitmask[2] = 0x03ff; /* blue */
> >>> + gopobj->info.pixel_bitmask[3] = 0xc000; /* reserved */
> >>> +#endif
> >>>   } else {
> >>>   gopobj->info.pixel_format = EFI_GOT_BITMASK;
> >>>   gopobj->info.pixel_bitmask[0] = 0xf800; /* red */
> >>>
> >>
> >>
> 

Re: [PATCH] xtensa: Put U-Boot version string at correct place by linker script

[Max Filippov]

On Fri, Sep 17, 2021 at 5:04 AM Tom Rini  wrote:
> So this is in context with:
> https://patchwork.ozlabs.org/project/uboot/list/?series=256258
> and specifically:
> https://patchwork.ozlabs.org/project/uboot/patch/20210802131838.21097-7-p...@kernel.org/

Yes, I've found that series and the purpose of this patch puzzled
me, given the absence of actual references to the newly added
section in the series.

> Now that said, I think the whole point of that has been removed with:
> https://patchwork.ozlabs.org/project/uboot/patch/20210916195648.9424-1-tr...@konsulko.com/
> and no longer needing to reference it from the linker script for
> PowerPC.

Aha, that explains the purpose of that section, thanks.

> So maybe I can just drop this whole part.

-- 
Thanks.
-- Max

RE: [PATCH] configs: lx2162a: Enable CONFIG_SPI_FLASH_MT35XU for lx2162a-qds

[Wasim Khan]

> -Original Message-
> From: U-Boot  On Behalf Of Kuldeep Singh
> Sent: Wednesday, September 15, 2021 3:34 PM
> To: u-boot@lists.denx.de
> Cc: Priyanka Jain ; Kuldeep Singh
> 
> Subject: [PATCH] configs: lx2162a: Enable CONFIG_SPI_FLASH_MT35XU for
> lx2162a-qds
> 
> LX2162A-QDS has micron mt35xu512aba flash which requires flag
> CONFIG_SPI_FLASH_MT35XU on to probe flash successfully.
> 
> Signed-off-by: Kuldeep Singh 

Reviewed-by: Wasim Khan 
Tested-by: Wasim Khan 

[PATCH] board: freescale: lx216x : increase fdt blob size

[Wasim Khan]

From: Wasim Khan 

Increase fdt blob size for lx2160 and lx2162 series
to fix below errors/warnings during device tree fixup.

Unable to update property /soc/spi@210:status, err=FDT_ERR_NOSPACE
Unable to update property /soc/spi@211:status, err=FDT_ERR_NOSPACE
Unable to update property /soc/spi@212:status, err=FDT_ERR_NOSPACE
WARNING: could not set reg FDT_ERR_NOSPACE.
WARNING unable to set iommus: FDT_ERR_NOSPACE

Signed-off-by: Wasim Khan 
---
 board/freescale/lx2160a/lx2160a.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/board/freescale/lx2160a/lx2160a.c 
b/board/freescale/lx2160a/lx2160a.c
index f505e82fb9..d03168d6a2 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -828,10 +828,18 @@ int ft_board_setup(void *blob, struct bd_info *bd)
u64 mc_memory_base = 0;
u64 mc_memory_size = 0;
u16 total_memory_banks;
+   int err;
 #if CONFIG_IS_ENABLED(TARGET_LX2160ARDB)
u8 board_rev;
 #endif
 
+   err = fdt_increase_size(blob, 512);
+   if (err) {
+   printf("%s fdt_increase_size: err=%s\n", __func__,
+  fdt_strerror(err));
+   return 1;
+   }
+
ft_cpu_setup(blob, bd);
 
fdt_fixup_mc_ddr(_memory_base, _memory_size);
-- 
2.25.1

[PATCH 10/11] pci: pcie_layerscape_fixup_common: include fdt_support.h for ft_pci_setup

[Vladimir Oltean]

The function prototype for ft_pci_setup is inside fdt_support.h, we need
to include that header.

Signed-off-by: Vladimir Oltean 
---
 drivers/pci/pcie_layerscape_fixup_common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pcie_layerscape_fixup_common.c 
b/drivers/pci/pcie_layerscape_fixup_common.c
index 8b924d404c2d..08dac7632b0f 100644
--- a/drivers/pci/pcie_layerscape_fixup_common.c
+++ b/drivers/pci/pcie_layerscape_fixup_common.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pcie_layerscape_fixup_common.h"
 
 void ft_pci_setup(void *blob, struct bd_info *bd)
-- 
2.25.1

[PATCH 09/11] pci: layerscape: ls_pcie_conf_address can be static

[Vladimir Oltean]

To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.

Signed-off-by: Vladimir Oltean 
---
 drivers/pci/pcie_layerscape_rc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pcie_layerscape_rc.c b/drivers/pci/pcie_layerscape_rc.c
index bd2c19f7f0c9..f50d6ef65396 100644
--- a/drivers/pci/pcie_layerscape_rc.c
+++ b/drivers/pci/pcie_layerscape_rc.c
@@ -143,8 +143,8 @@ static int ls_pcie_addr_valid(struct ls_pcie_rc *pcie_rc, 
pci_dev_t bdf)
return 0;
 }
 
-int ls_pcie_conf_address(const struct udevice *bus, pci_dev_t bdf,
-uint offset, void **paddress)
+static int ls_pcie_conf_address(const struct udevice *bus, pci_dev_t bdf,
+   uint offset, void **paddress)
 {
struct ls_pcie_rc *pcie_rc = dev_get_priv(bus);
struct ls_pcie *pcie = pcie_rc->pcie;
-- 
2.25.1

[PATCH 11/11] pci: pcie_layerscape_fixup_common: lx2_board_fix_fdt can be static

[Vladimir Oltean]

To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.

Signed-off-by: Vladimir Oltean 
---
 drivers/pci/pcie_layerscape_fixup_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pcie_layerscape_fixup_common.c 
b/drivers/pci/pcie_layerscape_fixup_common.c
index 08dac7632b0f..3216a20027a8 100644
--- a/drivers/pci/pcie_layerscape_fixup_common.c
+++ b/drivers/pci/pcie_layerscape_fixup_common.c
@@ -30,7 +30,7 @@ void ft_pci_setup(void *blob, struct bd_info *bd)
 }
 
 #if defined(CONFIG_FSL_LAYERSCAPE)
-int lx2_board_fix_fdt(void *fdt)
+static int lx2_board_fix_fdt(void *fdt)
 {
char *reg_name, *old_str, *new_str;
const char *reg_names;
-- 
2.25.1

[PATCH 08/11] pci: _dm_pci_phys_to_bus can be static

[Vladimir Oltean]

To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.

Signed-off-by: Vladimir Oltean 
---
 drivers/pci/pci-uclass.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index f0313d059042..f3ac6fdb0031 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1433,9 +1433,9 @@ phys_addr_t dm_pci_bus_to_phys(struct udevice *dev, 
pci_addr_t bus_addr,
return phys_addr;
 }
 
-int _dm_pci_phys_to_bus(struct udevice *dev, phys_addr_t phys_addr,
-   unsigned long flags, unsigned long skip_mask,
-   pci_addr_t *ba)
+static int _dm_pci_phys_to_bus(struct udevice *dev, phys_addr_t phys_addr,
+  unsigned long flags, unsigned long skip_mask,
+  pci_addr_t *ba)
 {
struct pci_region *res;
struct udevice *ctlr;
-- 
2.25.1

[PATCH 04/11] pci: pci_header_show can be static

[Vladimir Oltean]

To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.

Signed-off-by: Vladimir Oltean 
---
 cmd/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/pci.c b/cmd/pci.c
index ebe7c0fc5377..7febff497c54 100644
--- a/cmd/pci.c
+++ b/cmd/pci.c
@@ -223,7 +223,7 @@ static struct pci_reg_info regs_cardbus[] = {
  *
  * @dev: Bus+Device+Function number
  */
-void pci_header_show(struct udevice *dev)
+static void pci_header_show(struct udevice *dev)
 {
unsigned long class, header_type;
 
-- 
2.25.1

[PATCH 07/11] pci: pci_read_config can be static

[Vladimir Oltean]

To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.

Signed-off-by: Vladimir Oltean 
---
 drivers/pci/pci-uclass.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 20bddb597588..f0313d059042 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -369,8 +369,8 @@ int pci_bus_read_config(const struct udevice *bus, 
pci_dev_t bdf, int offset,
return ops->read_config(bus, bdf, offset, valuep, size);
 }
 
-int pci_read_config(pci_dev_t bdf, int offset, unsigned long *valuep,
-   enum pci_size_t size)
+static int pci_read_config(pci_dev_t bdf, int offset, unsigned long *valuep,
+  enum pci_size_t size)
 {
struct udevice *bus;
int ret;
-- 
2.25.1

[PATCH 05/11] pci: pciinfo_header can be static

[Vladimir Oltean]

To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.

Signed-off-by: Vladimir Oltean 
---
 cmd/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/pci.c b/cmd/pci.c
index 7febff497c54..cfabdc0f3012 100644
--- a/cmd/pci.c
+++ b/cmd/pci.c
@@ -251,7 +251,7 @@ static void pci_header_show(struct udevice *dev)
 }
 }
 
-void pciinfo_header(int busnum, bool short_listing)
+static void pciinfo_header(int busnum, bool short_listing)
 {
printf("Scanning PCI devices on bus %d\n", busnum);
 
-- 
2.25.1

[PATCH 06/11] pci: pci_write_config can be static

[Vladimir Oltean]

To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.

Signed-off-by: Vladimir Oltean 
---
 drivers/pci/pci-uclass.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index ce2eb5da2ca5..20bddb597588 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -304,8 +304,8 @@ int pci_bus_clrset_config32(struct udevice *bus, pci_dev_t 
bdf, int offset,
return pci_bus_write_config(bus, bdf, offset, val, PCI_SIZE_32);
 }
 
-int pci_write_config(pci_dev_t bdf, int offset, unsigned long value,
-enum pci_size_t size)
+static int pci_write_config(pci_dev_t bdf, int offset, unsigned long value,
+   enum pci_size_t size)
 {
struct udevice *bus;
int ret;
-- 
2.25.1

[PATCH 03/11] pci: pci_bar_show can be static

[Vladimir Oltean]

To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.

Signed-off-by: Vladimir Oltean 
---
 cmd/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/pci.c b/cmd/pci.c
index af75a6cfff4a..ebe7c0fc5377 100644
--- a/cmd/pci.c
+++ b/cmd/pci.c
@@ -59,7 +59,7 @@ static void pci_show_regs(struct udevice *dev, struct 
pci_reg_info *regs)
}
 }
 
-int pci_bar_show(struct udevice *dev)
+static int pci_bar_show(struct udevice *dev)
 {
u8 header_type;
int bar_cnt, bar_id, mem_type;
-- 
2.25.1

[PATCH 02/11] pci: include pci_internal.h inside pci_auto.c

[Vladimir Oltean]

To avoid a build warning with W=1, provide a function prototype for
dm_pciauto_prescan_setup_bridge, which is a non-static function whose
definition is inside pci_auto.c.

Signed-off-by: Vladimir Oltean 
---
 drivers/pci/pci_auto.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index b128a05dd380..8de5e7e12d43 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include "pci_internal.h"
 
 /* the user can define CONFIG_SYS_PCI_CACHE_LINE_SIZE to avoid problems */
 #ifndef CONFIG_SYS_PCI_CACHE_LINE_SIZE
-- 
2.25.1

[PATCH 01/11] pci: provide prototype for pci_skip_dev outside of #if defined(CONFIG_DM_PCI_COMPAT)

[Vladimir Oltean]

The weak definition of pci_skip_dev from drivers/pci/pci_common.c is not
under CONFIG_DM_PCI_COMPAT, and that definition needs a previous
function prototype declaration to avoid W=1 build warnings.

That prototype is not available due to it being under CONFIG_DM_PCI_COMPAT,
so move it outside of that preprocessor block.

Signed-off-by: Vladimir Oltean 
---
 include/pci.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/pci.h b/include/pci.h
index 0fc22adffd00..11009a2f787a 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -724,6 +724,7 @@ void pciauto_config_init(struct pci_controller *hose);
  */
 int pciauto_region_allocate(struct pci_region *res, pci_size_t size,
pci_addr_t *bar, bool supports_64bit);
+int pci_skip_dev(struct pci_controller *hose, pci_dev_t dev);
 
 #if defined(CONFIG_DM_PCI_COMPAT)
 extern int pci_hose_read_config_byte_via_dword(struct pci_controller *hose,
@@ -741,7 +742,6 @@ extern struct pci_controller* pci_bus_to_hose(int bus);
 extern struct pci_controller *find_hose_by_cfg_addr(void *cfg_addr);
 extern struct pci_controller *pci_get_hose_head(void);
 
-extern int pci_skip_dev(struct pci_controller *hose, pci_dev_t dev);
 extern int pci_hose_scan(struct pci_controller *hose);
 extern int pci_hose_scan_bus(struct pci_controller *hose, int bus);
 
-- 
2.25.1

[PATCH 00/11] Drive-by PCI W=1 cleanups

[Vladimir Oltean]

These are some trivial cleanup patches I made after compiling U-Boot for
ls1028ardb_tfa_defconfig with W=1.

Vladimir Oltean (11):
  pci: provide prototype for pci_skip_dev outside of #if
defined(CONFIG_DM_PCI_COMPAT)
  pci: include pci_internal.h inside pci_auto.c
  pci: pci_bar_show can be static
  pci: pci_header_show can be static
  pci: pciinfo_header can be static
  pci: pci_write_config can be static
  pci: pci_read_config can be static
  pci: _dm_pci_phys_to_bus can be static
  pci: layerscape: ls_pcie_conf_address can be static
  pci: pcie_layerscape_fixup_common: include fdt_support.h for
ft_pci_setup
  pci: pcie_layerscape_fixup_common: lx2_board_fix_fdt can be static

 cmd/pci.c  |  6 +++---
 drivers/pci/pci-uclass.c   | 14 +++---
 drivers/pci/pci_auto.c |  1 +
 drivers/pci/pcie_layerscape_fixup_common.c |  3 ++-
 drivers/pci/pcie_layerscape_rc.c   |  4 ++--
 include/pci.h  |  2 +-
 6 files changed, 16 insertions(+), 14 deletions(-)

-- 
2.25.1

Re: [PATCH] test/py: tpm2: Skip tpm pytest based on env variable

[Tom Rini]

On Fri, Sep 17, 2021 at 11:49:51AM +, T Karthik Reddy wrote:
> Hi Tom,
> 
> > -Original Message-
> > From: Tom Rini 
> > Sent: Thursday, August 5, 2021 6:53 PM
> > To: T Karthik Reddy 
> > Cc: Ashok Reddy Soma ; u-boot@lists.denx.de;
> > miquel.ray...@bootlin.com; git 
> > Subject: Re: [PATCH] test/py: tpm2: Skip tpm pytest based on env variable
> > 
> > On Thu, Aug 05, 2021 at 05:56:50AM +, T Karthik Reddy wrote:
> > > Hello Tom Rini,
> > >
> > > > -Original Message-
> > > > From: Tom Rini 
> > > > Sent: Wednesday, August 4, 2021 8:52 PM
> > > > To: Ashok Reddy Soma 
> > > > Cc: u-boot@lists.denx.de; miquel.ray...@bootlin.com; git
> > > > ; T Karthik Reddy 
> > > > Subject: Re: [PATCH] test/py: tpm2: Skip tpm pytest based on env
> > > > variable
> > > >
> > > > On Fri, Jul 23, 2021 at 06:18:26AM -0600, Ashok Reddy Soma wrote:
> > > >
> > > > > From: T Karthik Reddy 
> > > > >
> > > > > Tpm test cases relies on tpm device setup. Provide an environment
> > > > > variable "env__tpm_device_test_skip = True" to skip the test case
> > > > > if tpm device is not present.
> > > > > Only needed will have to add variable to the py-test framework.
> > > > > Test runs successfully even this variable is absent.
> > > > >
> > > > > Signed-off-by: T Karthik Reddy 
> > > > > Signed-off-by: Ashok Reddy Soma 
> > > >
> > > > Why is this not using boardenv_* like other tests do to disable running?
> > >
> > > What I meant here was this test doesn't depend on configuration value
> > > from boardenv_*. But it uses env__tpm_device_test_skip variable from
> > the configuration file.
> > > I referred test/py/tests/test_sleep.py for writing this test case, hence
> > copied comments as well.
> > > Should I change this NOTE in comment section?
> > 
> > Thanks for explaining.  This got me to re-read the existing tests and while
> > none of it is as clear as I would like, your example here is just as clear 
> > as the
> > rest, so it's fine and I'll pick it up soon.
> 
> I see this patch is not yet applied on the repo, could you please let me know 
> when this will be applied?

Ilias, since you've said you'd review TPM related patches, does this:
https://patchwork.ozlabs.org/project/uboot/patch/1624340962-91190-1-git-send-email-t.karthik.re...@xilinx.com/
work for you?  Thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [systemd-devel] Systemd-boot not properly loading device tree, when loaded by U-boot (ARM64, tested on RK3399)

[Lennart Poettering]

On Fr, 17.09.21 19:25, Qu Wenruo (w...@suse.com) wrote:

> Hi,
>
> I'm recently testing booting my RK3399 boards with the following boot
> sequence:
>
> U-boot -> systemd-boot (EFI payload) -> kernel
>
> Which provides much more flex than plain extlinux conf from U-boot.
> (More choice, easier to write config, runtime kernel change).
>
> So far "kernel" and "initramfs" key work fine.
>
> But I notice that "devicetree" key is not working properly.
>
> The Uboot fdt search path doesn't include "/dtbs" which is used by my
> distro, and my entry config specify the device-tree file like this:
>
> titleManjaroARM boot from nvme
> linux/Image
> devicetree/dtbs/rockchip/rk3399-rockpro64.dtb
> initrd/initramfs-linux.img
> optionsconsole=ttyS2,150 root=/dev/arm_nvme/root rw loglevel=7
>
> Thus if systemd-boot doesn't load the correct device-tree, kernel will
> use the default fdt passed from Uboot, which is already out-of-date and
> can cause problems for the upstream kernel I used.
>
> Unfortunately, with above config, after booting the kernel, the fdt is
> the fallback one from Uboot, not loading the proper one specified by
> systemd-boot config.
>
> The proof I went is checking the opp table.
> I have replaced the "/dtbs/rockchip/rk3399-rockpro64.dtb" with a custom
> dtb which uses op1 tables.
> But the kernel only sees a very out-of-dated fdt, which some opp is even
> invalid.
>
> How could I continue debugging the missing link?
> Like what systemd-boot needs to load the device-tree? Or U-boot EFI
> environment lacks certain facility to support systemd-boot?

Did you see this:

https://github.com/systemd/systemd/pull/19417

(and maybe this: https://github.com/systemd/systemd/pull/20601)

maybe that addresses your issues?

Lennart

--
Lennart Poettering, Berlin

Re: [PATCH] xtensa: Put U-Boot version string at correct place by linker script

[Tom Rini]

On Thu, Sep 16, 2021 at 10:14:03PM -0700, Max Filippov wrote:
> On Thu, Sep 16, 2021 at 10:30 AM Tom Rini  wrote:
> >
> > Update the linker script macros to know that we need to include the
> > .text_version_string section now as well.
> >
> > Signed-off-by: Tom Rini 
> > ---
> >  arch/xtensa/include/asm/ldscript.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/xtensa/include/asm/ldscript.h 
> > b/arch/xtensa/include/asm/ldscript.h
> > index 08f5d0135ed0..84c496e09f1b 100644
> > --- a/arch/xtensa/include/asm/ldscript.h
> > +++ b/arch/xtensa/include/asm/ldscript.h
> > @@ -72,6 +72,7 @@
> > {   \
> > _text_start = ABSOLUTE(.);  \
> > *(.literal .text)   \
> > +   *(.literal .text_version_string)\
> 
> This does not belong to .text, as far as I understand it's rodata and so
> it should go with rodata, probably like this:
> ---8<---
> diff --git a/arch/xtensa/include/asm/ldscript.h
> b/arch/xtensa/include/asm/ldscript.h
> index 08f5d0135ed0..e03fcffdd6f1 100644
> --- a/arch/xtensa/include/asm/ldscript.h
> +++ b/arch/xtensa/include/asm/ldscript.h
> @@ -87,6 +87,7 @@
>_rodata_start = ABSOLUTE(.);\
>*(.rodata)  \
>*(.rodata.*)\
> +   *(.text_version_string) \
>*(.dtb.init.rodata) \
>*(.gnu.linkonce.r.*)\
>*(.rodata1) \

So this is in context with:
https://patchwork.ozlabs.org/project/uboot/list/?series=256258
and specifically:
https://patchwork.ozlabs.org/project/uboot/patch/20210802131838.21097-7-p...@kernel.org/

Now that said, I think the whole point of that has been removed with:
https://patchwork.ozlabs.org/project/uboot/patch/20210916195648.9424-1-tr...@konsulko.com/
and no longer needing to reference it from the linker script for
PowerPC.  So maybe I can just drop this whole part.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] xtensa: Put U-Boot version string at correct place by linker script

[Tom Rini]

On Thu, Sep 16, 2021 at 10:21:29PM -0700, Max Filippov wrote:

> On Thu, Sep 16, 2021 at 12:42 PM Tom Rini  wrote:
> > We also don't have qemu support for it
> 
> I'm curious what happened to it and what I should do to update it?
> 
> xtensa is still supported in the QEMU and AFAIK nothing has changed
> about it: neither building nor invocation.

OK, yes, I was just wrong there.  It's still there, it's part of Azure
and GitLab CI, tested every time.  Sorry for the confusion.

-- 
Tom


signature.asc
Description: PGP signature

RE: [PATCH] test/py: tpm2: Skip tpm pytest based on env variable

[T Karthik Reddy]

Hi Tom,

> -Original Message-
> From: Tom Rini 
> Sent: Thursday, August 5, 2021 6:53 PM
> To: T Karthik Reddy 
> Cc: Ashok Reddy Soma ; u-boot@lists.denx.de;
> miquel.ray...@bootlin.com; git 
> Subject: Re: [PATCH] test/py: tpm2: Skip tpm pytest based on env variable
> 
> On Thu, Aug 05, 2021 at 05:56:50AM +, T Karthik Reddy wrote:
> > Hello Tom Rini,
> >
> > > -Original Message-
> > > From: Tom Rini 
> > > Sent: Wednesday, August 4, 2021 8:52 PM
> > > To: Ashok Reddy Soma 
> > > Cc: u-boot@lists.denx.de; miquel.ray...@bootlin.com; git
> > > ; T Karthik Reddy 
> > > Subject: Re: [PATCH] test/py: tpm2: Skip tpm pytest based on env
> > > variable
> > >
> > > On Fri, Jul 23, 2021 at 06:18:26AM -0600, Ashok Reddy Soma wrote:
> > >
> > > > From: T Karthik Reddy 
> > > >
> > > > Tpm test cases relies on tpm device setup. Provide an environment
> > > > variable "env__tpm_device_test_skip = True" to skip the test case
> > > > if tpm device is not present.
> > > > Only needed will have to add variable to the py-test framework.
> > > > Test runs successfully even this variable is absent.
> > > >
> > > > Signed-off-by: T Karthik Reddy 
> > > > Signed-off-by: Ashok Reddy Soma 
> > >
> > > Why is this not using boardenv_* like other tests do to disable running?
> >
> > What I meant here was this test doesn't depend on configuration value
> > from boardenv_*. But it uses env__tpm_device_test_skip variable from
> the configuration file.
> > I referred test/py/tests/test_sleep.py for writing this test case, hence
> copied comments as well.
> > Should I change this NOTE in comment section?
> 
> Thanks for explaining.  This got me to re-read the existing tests and while
> none of it is as clear as I would like, your example here is just as clear as 
> the
> rest, so it's fine and I'll pick it up soon.

I see this patch is not yet applied on the repo, could you please let me know 
when this will be applied?

Thanks
T karthik 

> 
> --
> Tom

Re: [systemd-devel] Systemd-boot not properly loading device tree, when loaded by U-boot (ARM64, tested on RK3399)

[Qu Wenruo]

On 2021/9/17 19:45, Lennart Poettering wrote:

On Fr, 17.09.21 19:25, Qu Wenruo (w...@suse.com) wrote:


Hi,

I'm recently testing booting my RK3399 boards with the following boot
sequence:

U-boot -> systemd-boot (EFI payload) -> kernel

Which provides much more flex than plain extlinux conf from U-boot.
(More choice, easier to write config, runtime kernel change).

So far "kernel" and "initramfs" key work fine.

But I notice that "devicetree" key is not working properly.

The Uboot fdt search path doesn't include "/dtbs" which is used by my
distro, and my entry config specify the device-tree file like this:

titleManjaroARM boot from nvme
linux/Image
devicetree/dtbs/rockchip/rk3399-rockpro64.dtb
initrd/initramfs-linux.img
optionsconsole=ttyS2,150 root=/dev/arm_nvme/root rw loglevel=7

Thus if systemd-boot doesn't load the correct device-tree, kernel will
use the default fdt passed from Uboot, which is already out-of-date and
can cause problems for the upstream kernel I used.

Unfortunately, with above config, after booting the kernel, the fdt is
the fallback one from Uboot, not loading the proper one specified by
systemd-boot config.

The proof I went is checking the opp table.
I have replaced the "/dtbs/rockchip/rk3399-rockpro64.dtb" with a custom
dtb which uses op1 tables.
But the kernel only sees a very out-of-dated fdt, which some opp is even
invalid.

How could I continue debugging the missing link?
Like what systemd-boot needs to load the device-tree? Or U-boot EFI
environment lacks certain facility to support systemd-boot?


Did you see this:

https://github.com/systemd/systemd/pull/19417

(and maybe this: https://github.com/systemd/systemd/pull/20601)


Awesome! Let me try these PRs and report back!

Thanks for the super-fast mention!
Qu



maybe that addresses your issues?

Lennart

--
Lennart Poettering, Berlin

Re: [PATCH] distro_bootcmd: change the default dtb search path to include default kernel dtbs directory

[Qu Wenruo]

On 2021/9/17 19:34, Mark Kettenis wrote:

From: Qu Wenruo 
Date: Fri, 17 Sep 2021 19:02:35 +0800

When booting using U-boot -> systemd-boot (EFI payload) -> kernel on
RK3399, systemd-boot by some bug can't execute its "devicetree" key
correctly to load its proper dtb from files.

In that case, it will use fallback dtb from U-boot, which can be
out-of-date, and on RK3399, even the latest U-boot contains out-of-date
dtb which can cause problems like invalid opp tables.

And for systemd-boot, it doesn't provide any board specific dtb, but
completely relies on the EFI environment provided by U-boot, thus if we
can't find a good dtb, the fallback one will be used anyway.

So this patch will workaround the problem by appending common linux dtbs
directory to the existing "efi_dtb_prefixes" so that for systemd-boot it
can use the existing fdt and boot properly.


Why isn't the dtb installed in the standard location?


Isn't standard location "/dtbs" other than "/dtb"?

At least kernel puts its dtbs into "/dtbs" by default.



Slowing the boot process down because distro's can't agree where to
put the files is a bit lame...


Would it be better to make the search path configurable at config time?

By that each distro should config their dtbs search path, which could
further optimize the boot sequence by removing all other unnecessary
prefixes.

Thanks,
Qu




Signed-off-by: Qu Wenruo 
---
  include/config_distro_bootcmd.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 2627c2a6a541..4ec87483eb65 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -151,7 +151,7 @@
"load ${devtype} ${devnum}:${distro_bootpart} "   \
"${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
\
-   "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
+   "efi_dtb_prefixes=/ /dtb/ /dtb/current/ /dtbs/ /dtbs/current/\0"  \
"scan_dev_for_efi="   \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
--
2.33.0

Re: [PATCH] distro_bootcmd: change the default dtb search path to include default kernel dtbs directory

[Mark Kettenis]

> From: Qu Wenruo 
> Date: Fri, 17 Sep 2021 19:02:35 +0800
> 
> When booting using U-boot -> systemd-boot (EFI payload) -> kernel on
> RK3399, systemd-boot by some bug can't execute its "devicetree" key
> correctly to load its proper dtb from files.
> 
> In that case, it will use fallback dtb from U-boot, which can be
> out-of-date, and on RK3399, even the latest U-boot contains out-of-date
> dtb which can cause problems like invalid opp tables.
> 
> And for systemd-boot, it doesn't provide any board specific dtb, but
> completely relies on the EFI environment provided by U-boot, thus if we
> can't find a good dtb, the fallback one will be used anyway.
> 
> So this patch will workaround the problem by appending common linux dtbs
> directory to the existing "efi_dtb_prefixes" so that for systemd-boot it
> can use the existing fdt and boot properly.

Why isn't the dtb installed in the standard location?

Slowing the boot process down because distro's can't agree where to
put the files is a bit lame...

> Signed-off-by: Qu Wenruo 
> ---
>  include/config_distro_bootcmd.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
> index 2627c2a6a541..4ec87483eb65 100644
> --- a/include/config_distro_bootcmd.h
> +++ b/include/config_distro_bootcmd.h
> @@ -151,7 +151,7 @@
>   "load ${devtype} ${devnum}:${distro_bootpart} "   \
>   "${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
>   \
> - "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
> + "efi_dtb_prefixes=/ /dtb/ /dtb/current/ /dtbs/ /dtbs/current/\0"  \
>   "scan_dev_for_efi="   \
>   "setenv efi_fdtfile ${fdtfile}; " \
>   BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
> -- 
> 2.33.0
> 
> 

Re: [PATCH 2/3] efi_loader: GOP: Add 30bpp support

[Heinrich Schuchardt]

On 9/17/21 11:23 AM, Mark Kettenis wrote:

From: Heinrich Schuchardt 
Date: Fri, 17 Sep 2021 04:56:31 +0200


Hi Heinrich,


On 9/16/21 3:01 PM, Mark Kettenis wrote:

Provide correct framebuffer information for 30bpp modes.


This is not enough to get a correct GOP implementation for the 30bpp mode.

Have a look at efi_gop_pixel efi_vid16_to_blt_col() and
efi_blt_col_to_vid16() and where they are used.


Ah right.  This does indeed not support EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt()
correctly.  I shouldn't be too hard to translate between XRGB2101010
and XRGB.  Any ideas how I could test that code?


setenv efi_selftest block image transfer
bootefi selftest

should show an animated submarine with yellow portholes similar to

https://gist.github.com/xypron/7e1f73408465da71e3ef946250e76776#file-sub-png

Best regards

Heinrich




Signed-off-by: Mark Kettenis 
---
   lib/efi_loader/efi_gop.c | 10 ++
   1 file changed, 10 insertions(+)

diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
index 1206b2d7a2..42bf49b184 100644
--- a/lib/efi_loader/efi_gop.c
+++ b/lib/efi_loader/efi_gop.c
@@ -227,6 +227,7 @@ static efi_uintn_t gop_get_bpp(struct efi_gop *this)

switch (gopobj->bpix) {
   #ifdef CONFIG_DM_VIDEO
+   case VIDEO_BPP30:
case VIDEO_BPP32:
   #else
case LCD_COLOR32:
@@ -468,6 +469,7 @@ efi_status_t efi_gop_register(void)
switch (bpix) {
   #ifdef CONFIG_DM_VIDEO
case VIDEO_BPP16:
+   case VIDEO_BPP30:
case VIDEO_BPP32:
   #else
case LCD_COLOR32:
@@ -518,6 +520,14 @@ efi_status_t efi_gop_register(void)
   #endif
{
gopobj->info.pixel_format = EFI_GOT_BGRA8;
+#ifdef CONFIG_DM_VIDEO


This symbol is not 30bpp specific. Is there a Kconfig variable that we
can use to hide 30bpp support where it is not needed?


I quite deliberately didn't add a separate config option for 30bpp as
there is very little code that is added to the already existing 32bpp
code.  In a sense 30bpp is just a different submode of the 32bpp
support with just a different color map, so I thought it made sense to
group it under CONFIG_VIDEO_32BPP.  I did initially consider adding a
separate config option for it, but it quickly turns into an #ifdef
maze that makes it hard to understand the code.

The CONFIG_DM_VIDEO check is just there to make sure the 30bpp is only
offered in the DM model.  Based on recent discussions I expect the
!CONFIG_DM_VIDEO case to disappear in the near feature so adding 30bpp
support for the non-DM case doesn't make sense.

The EFI GOP code currently doesn't check the CONFIG_VIDEO_BPP16 and
CONFIG_VIDEO_BPP32 defines to see which of these modes are enabled
within U-Boot, so we don't "hide" 16bpp support on platforms that just
support 32bpp either.


Which modes does the M1 support?


We're not sure.  It does support at least 8-bit (32bpp) and 10-bit
(30bpp) color depth modes.  But the firmware tends to come up with
10-bit color depth whenever it can and I'm not planning to add support
for changing the framebuffer mode on the M1, since the interface to do
that is "interesting" [1].

[1] See Alyssa Rozenzweig's talk at XDC 2021,
 https://www.youtube.com/watch?v=uTZISTjqy9Q



+   } else if (bpix == VIDEO_BPP30) {
+   gopobj->info.pixel_format = EFI_GOT_BITMASK;
+   gopobj->info.pixel_bitmask[0] = 0x3ff0; /* red */
+   gopobj->info.pixel_bitmask[1] = 0x000ffc00; /* green */
+   gopobj->info.pixel_bitmask[2] = 0x03ff; /* blue */
+   gopobj->info.pixel_bitmask[3] = 0xc000; /* reserved */
+#endif
} else {
gopobj->info.pixel_format = EFI_GOT_BITMASK;
gopobj->info.pixel_bitmask[0] = 0xf800; /* red */

[PATCH] net: update NXP copyright text

[Vladimir Oltean]

NXP Legal insists that the following are not fine:

- Saying "NXP Semiconductors" instead of "NXP", since the company's
  registered name is "NXP"

- Putting a "(c)" sign in the copyright string

- Putting a comma in the copyright string

The only accepted copyright string format is "Copyright  NXP".

This patch changes the copyright headers in the networking files that
were sent by me, or derived from code sent by me.

Signed-off-by: Vladimir Oltean 
---
 arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi  | 2 +-
 arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi  | 2 +-
 arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi  | 2 +-
 arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 2 +-
 arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi  | 2 +-
 arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 2 +-
 arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi  | 2 +-
 arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 2 +-
 arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 2 +-
 arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi  | 2 +-
 arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi  | 2 +-
 arch/arm/dts/fsl-sch-24801.dtsi   | 2 +-
 arch/arm/dts/fsl-sch-28021.dtsi   | 2 +-
 arch/arm/dts/fsl-sch-30841.dtsi   | 2 +-
 arch/arm/dts/fsl-sch-30842.dtsi   | 2 +-
 arch/arm/dts/ls1021a-tsn.dts  | 2 +-
 board/freescale/ls1021atsn/ls1021atsn.c   | 2 +-
 drivers/net/dsa_sandbox.c | 2 +-
 drivers/net/mscc_eswitch/felix_switch.c   | 2 +-
 include/configs/ls1021atsn.h  | 2 +-
 include/net/dsa.h | 2 +-
 test/dm/dsa.c | 2 +-
 22 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
index 23816da8eeba..4063d9a114d3 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
@@ -2,7 +2,7 @@
 /*
  * NXP LS1028A-QDS device tree fragment for RCW 1xxx
  *
- * Copyright 2019-2021 NXP Semiconductors
+ * Copyright 2019-2021 NXP
  */
 
 /*
diff --git a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
index c6558ae2e07b..6dcd15a68514 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
@@ -2,7 +2,7 @@
 /*
  * NXP LS1028A-QDS device tree fragment for RCW 6xxx
  *
- * Copyright 2019-2021 NXP Semiconductors
+ * Copyright 2019-2021 NXP
  */
 
 /*
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
index 5a0f060c16e5..1607a32c1ee9 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
@@ -2,7 +2,7 @@
 /*
  * NXP LS1028A-QDS device tree fragment for RCW 
  *
- * Copyright 2019-2021 NXP Semiconductors
+ * Copyright 2019-2021 NXP
  */
 
 /*
diff --git a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
index 39a83e10c4ce..a00f58273dc6 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
@@ -2,7 +2,7 @@
 /*
  * NXP LS1028A-QDS device tree fragment for RCW 7xx7
  *
- * Copyright 2019-2021 NXP Semiconductors
+ * Copyright 2019-2021 NXP
  */
 
  {
diff --git a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
index 7d4702e4ff2b..94b5081d6101 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
@@ -2,7 +2,7 @@
 /*
  * NXP LS1028A-QDS device tree fragment for RCW 8xxx
  *
- * Copyright 2019-2021 NXP Semiconductors
+ * Copyright 2019-2021 NXP
  */
 
 /*
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
index 021fe3fbc67a..3b850268e6a9 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
@@ -2,7 +2,7 @@
 /*
  * NXP LS1028A-QDS device tree fragment for RCW 
  *
- * Copyright 2019-2021 NXP Semiconductors
+ * Copyright 2019-2021 NXP
  */
 
 /*
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
index b6704d8089a8..eb632143e068 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
@@ -2,7 +2,7 @@
 /*
  * NXP LS1028A-QDS device tree fragment for RCW 
  *
- * Copyright 2019-2021 NXP Semiconductors
+ * Copyright 2019-2021 NXP
  *
  */
 
diff --git a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi 
b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi

Systemd-boot not properly loading device tree, when loaded by U-boot (ARM64, tested on RK3399)

[Qu Wenruo]

Hi,

I'm recently testing booting my RK3399 boards with the following boot
sequence:

U-boot -> systemd-boot (EFI payload) -> kernel

Which provides much more flex than plain extlinux conf from U-boot.
(More choice, easier to write config, runtime kernel change).

So far "kernel" and "initramfs" key work fine.

But I notice that "devicetree" key is not working properly.

The Uboot fdt search path doesn't include "/dtbs" which is used by my
distro, and my entry config specify the device-tree file like this:

titleManjaroARM boot from nvme
linux/Image
devicetree/dtbs/rockchip/rk3399-rockpro64.dtb
initrd/initramfs-linux.img
optionsconsole=ttyS2,150 root=/dev/arm_nvme/root rw loglevel=7

Thus if systemd-boot doesn't load the correct device-tree, kernel will
use the default fdt passed from Uboot, which is already out-of-date and
can cause problems for the upstream kernel I used.

Unfortunately, with above config, after booting the kernel, the fdt is
the fallback one from Uboot, not loading the proper one specified by
systemd-boot config.

The proof I went is checking the opp table.
I have replaced the "/dtbs/rockchip/rk3399-rockpro64.dtb" with a custom
dtb which uses op1 tables.
But the kernel only sees a very out-of-dated fdt, which some opp is even
invalid.

How could I continue debugging the missing link?
Like what systemd-boot needs to load the device-tree? Or U-boot EFI
environment lacks certain facility to support systemd-boot?

Thanks,
Qu

Re: [PATCH] arm: rpi: perform XHCI firmware upload only once

[nicolas saenz julienne]

On Fri, 2021-09-17 at 10:19 +0200, Marek Szyprowski wrote:
> XHCI firmware upload must be performed only once after initializing the
> PCI bridge. This fixes USB stack initialization after calling "usb stop;
> usb start" on Raspberry Pi 4B.
> 
> Signed-off-by: Marek Szyprowski 
> ---

Reviewed-by: Nicolas Saenz Julienne 

Regards,
Nicolas

[PATCH] distro_bootcmd: change the default dtb search path to include default kernel dtbs directory

[Qu Wenruo]

When booting using U-boot -> systemd-boot (EFI payload) -> kernel on
RK3399, systemd-boot by some bug can't execute its "devicetree" key
correctly to load its proper dtb from files.

In that case, it will use fallback dtb from U-boot, which can be
out-of-date, and on RK3399, even the latest U-boot contains out-of-date
dtb which can cause problems like invalid opp tables.

And for systemd-boot, it doesn't provide any board specific dtb, but
completely relies on the EFI environment provided by U-boot, thus if we
can't find a good dtb, the fallback one will be used anyway.

So this patch will workaround the problem by appending common linux dtbs
directory to the existing "efi_dtb_prefixes" so that for systemd-boot it
can use the existing fdt and boot properly.

Signed-off-by: Qu Wenruo 
---
 include/config_distro_bootcmd.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 2627c2a6a541..4ec87483eb65 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -151,7 +151,7 @@
"load ${devtype} ${devnum}:${distro_bootpart} "   \
"${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
\
-   "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
+   "efi_dtb_prefixes=/ /dtb/ /dtb/current/ /dtbs/ /dtbs/current/\0"  \
"scan_dev_for_efi="   \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
-- 
2.33.0

Re: [PATCH v3 1/2] mtd: cfi_flash: use cfi_flash_num_flash_banks only when supported

[Patrick DELAUNAY]

Hi Marek,

> Marek VasutSept. 16, 2021, 5:24 p.m. UTC | #1

> On 9/16/21 4:01 PM, Patrick Delaunay wrote:

>> When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated,
>> CONFIG_SYS_MAX_FLASH_BANKS is replaced by cfi_flash_num_flash_banks,
>> but this variable is defined in drivers/mtd/cfi_flash.c, which is
>> compiled only when CONFIG_FLASH_CFI_DRIVER is activated, in U-Boot
>> or in SPL when CONFIG_SPL_MTD_SUPPORT is activated.
>>
>> This patch deactivates this feature CONFIG_SYS_MAX_FLASH_BANKS_DETECT
>> when flash cfi driver is not activated to avoid compilation issue in
>> the next patch, when CONFIG_SYS_MAX_FLASH_BANKS is used in 
spi_nor_scan().


> Maybe just migrate this config option to Kconfig and let Kconfig handle
> the macro magic ?


Sorry for the format  of my answer (it is just copy paste from archive)

because I don't received the U-Boot mails on my @foss.st.com mailbo

since yesterday.


I think about migration but is difficult to don't break the existing 
behaviour in kconfig


CONFIG_SYS_MAX_FLASH_BANKS and CONFIG_SYS_MAX_FLASH_BANKS_DETECT are 
define as 'int'


but can be absent => 2 new config CONFIG_USE need to be added

CONFIG_USE_SYS_MAX_FLASH_BANKS

CONFIG_USE_SYS_MAX_FLASH_BANKS_DETECT


and I don't fully understood the mix between the 2 options and 
CFI_MAX_FLASH_BANKS


in some part of code I think CONFIG_SYS_MAX_FLASH_BANKS should be 
replaced by CFI_MAX_FLASH_BANKS


to avoid to define CONFIG_SYS_MAX_FLASH_BANKS = 
cfi_flash_num_flash_banks (as it is not possible in Kconfig)



=> too huge task just to solve compilation issues.


and I also think to use CONFIG_IS_ENABLED(MTD_SUPPORT)

but it not possible because today

- CONFIG_SPL_MTD_SUPPORT exist

- CONFIG_MTD_SUPPORT don't exit ( test on $(mtd-y) in Makefile)


=> the creation of this config is a huge task just to solve compilation 
issue.



Patrick

Re: [PATCH v3 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset

[Pratyush Yadav]

On 13/09/21 01:42PM, JaimeLiao wrote:
> Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from 
> 8D-8D-8D
> in the begging of probe.

Typo: begging -> beginning

> 
> Command extension type is not standardized across flash vendors in DTR mode.
> 
> For suiting different vendor flash devices, adding a flag to seperate types if
> nor->cmd_ext_type didn't configure from SFDP.

No, the code does not do what the commit message says. The code only 
sets the extension for soft reset, which is then reset back to the 
default at the end of the function. Then we read from SFDP and do the 
usual initialization.

> 
> Signed-off-by: JaimeLiao 
> ---
>  drivers/mtd/spi/Kconfig| 6 ++
>  drivers/mtd/spi/spi-nor-core.c | 7 ++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> index 67599b32c9..d850480401 100644
> --- a/drivers/mtd/spi/Kconfig
> +++ b/drivers/mtd/spi/Kconfig
> @@ -97,6 +97,12 @@ config SPI_FLASH_SMART_HWCAPS
>can support a type of operation in a much more refined way compared
>to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
>  
> +config SPI_NOR_CMD_EXT_INVERT

Let's only have this extension for the soft reset on boot, and then let 
the usual initialization process discover it via SFDP. This will make 
the code a little less complicated IMO.

So I suggest calling it SPI_NOR_BOOT_SOFT_RESET_EXT.

> + bool "Command extension type is INVERT for SPI NOR flashed"
> + default n
> + help
> +  Define command extension type is INVERT.

And explain here that this only sets the extension for the soft reset on 
boot since we can't discover it at that point. Then we drop the 
information and rediscover it as normal via SFDP or flash fixup hooks.

> +
>  config SPI_FLASH_SOFT_RESET
>   bool "Software Reset support for SPI NOR flashes"
>   default n
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index b8dda02aa7..4bcd58d839 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
>   enum spi_nor_cmd_ext ext;
>  
>   ext = nor->cmd_ext_type;
> - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> + if (!nor->cmd_ext_type) {

Use (nor->cmd_ext_type == SPI_NOR_EXT_NONE). Also add a comment 
explaining here why you do this check.

> + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> +#ifdef CONFIG_SPI_NOR_CMD_EXT_INVERT
> + nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
> +#endif

Avoid using #ifdef. You can replace it with 

  if (CONFIG_IS_ENABLED(SPI_NOR_CMD_EXT_INVERT))
  nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
  else
  nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;

> + }
>  
>   op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0),
>   SPI_MEM_OP_NO_DUMMY,
> -- 
> 2.17.1
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH v2 3/3] mx7ulp_com: add support for SPL

[Oleksandr Suvorov]

Hi Fabio,

On Thu, Sep 16, 2021 at 10:27 PM Fabio Estevam  wrote:
>
> Hi Oleksandr,
>
> On Thu, Sep 16, 2021 at 3:50 PM Oleksandr Suvorov  wrote:
>
> > The SPL for this board is built with prepended DCD which includes DDR
> > training data (defined in imximage.cfg). So that the bootrom initializes
> > DDR using DCD before jumping to SPL.
> > Is it mandatory to move DDR init in C code for SPL-enabled setups?
> > We wouldn't be changing it for now :(
>
> If the SPL is currently not doing its minimum task of configuring DDR,
> why do we need SPL in the first place?

It's for a secure boot process, for running op-tee before u-boot.
You could refer to the model we use
https://docs.foundries.io/latest/reference-manual/security/secure-boot-imx.html#our-implementation
In that model, u-boot runs in a normal world.
Separating SPL is only the beginning of changes, so I'm trying to go
prepare changes to mainline step-by-step.
-- 
Best regards,

Oleksandr Suvorov
Software Engineer
T: +380 63 8489656
E: oleksandr.suvo...@foundries.io
W: www.foundries.io

Re: [PATCH 2/3] efi_loader: GOP: Add 30bpp support

[Mark Kettenis]

> From: Heinrich Schuchardt 
> Date: Fri, 17 Sep 2021 04:56:31 +0200

Hi Heinrich,

> On 9/16/21 3:01 PM, Mark Kettenis wrote:
> > Provide correct framebuffer information for 30bpp modes.
> 
> This is not enough to get a correct GOP implementation for the 30bpp mode.
> 
> Have a look at efi_gop_pixel efi_vid16_to_blt_col() and
> efi_blt_col_to_vid16() and where they are used.

Ah right.  This does indeed not support EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt()
correctly.  I shouldn't be too hard to translate between XRGB2101010
and XRGB.  Any ideas how I could test that code?

> > Signed-off-by: Mark Kettenis 
> > ---
> >   lib/efi_loader/efi_gop.c | 10 ++
> >   1 file changed, 10 insertions(+)
> >
> > diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
> > index 1206b2d7a2..42bf49b184 100644
> > --- a/lib/efi_loader/efi_gop.c
> > +++ b/lib/efi_loader/efi_gop.c
> > @@ -227,6 +227,7 @@ static efi_uintn_t gop_get_bpp(struct efi_gop *this)
> >
> > switch (gopobj->bpix) {
> >   #ifdef CONFIG_DM_VIDEO
> > +   case VIDEO_BPP30:
> > case VIDEO_BPP32:
> >   #else
> > case LCD_COLOR32:
> > @@ -468,6 +469,7 @@ efi_status_t efi_gop_register(void)
> > switch (bpix) {
> >   #ifdef CONFIG_DM_VIDEO
> > case VIDEO_BPP16:
> > +   case VIDEO_BPP30:
> > case VIDEO_BPP32:
> >   #else
> > case LCD_COLOR32:
> > @@ -518,6 +520,14 @@ efi_status_t efi_gop_register(void)
> >   #endif
> > {
> > gopobj->info.pixel_format = EFI_GOT_BGRA8;
> > +#ifdef CONFIG_DM_VIDEO
> 
> This symbol is not 30bpp specific. Is there a Kconfig variable that we
> can use to hide 30bpp support where it is not needed?

I quite deliberately didn't add a separate config option for 30bpp as
there is very little code that is added to the already existing 32bpp
code.  In a sense 30bpp is just a different submode of the 32bpp
support with just a different color map, so I thought it made sense to
group it under CONFIG_VIDEO_32BPP.  I did initially consider adding a
separate config option for it, but it quickly turns into an #ifdef
maze that makes it hard to understand the code.

The CONFIG_DM_VIDEO check is just there to make sure the 30bpp is only
offered in the DM model.  Based on recent discussions I expect the
!CONFIG_DM_VIDEO case to disappear in the near feature so adding 30bpp
support for the non-DM case doesn't make sense.

The EFI GOP code currently doesn't check the CONFIG_VIDEO_BPP16 and
CONFIG_VIDEO_BPP32 defines to see which of these modes are enabled
within U-Boot, so we don't "hide" 16bpp support on platforms that just
support 32bpp either.

> Which modes does the M1 support?

We're not sure.  It does support at least 8-bit (32bpp) and 10-bit
(30bpp) color depth modes.  But the firmware tends to come up with
10-bit color depth whenever it can and I'm not planning to add support
for changing the framebuffer mode on the M1, since the interface to do
that is "interesting" [1].

[1] See Alyssa Rozenzweig's talk at XDC 2021,
https://www.youtube.com/watch?v=uTZISTjqy9Q
> 
> > +   } else if (bpix == VIDEO_BPP30) {
> > +   gopobj->info.pixel_format = EFI_GOT_BITMASK;
> > +   gopobj->info.pixel_bitmask[0] = 0x3ff0; /* red */
> > +   gopobj->info.pixel_bitmask[1] = 0x000ffc00; /* green */
> > +   gopobj->info.pixel_bitmask[2] = 0x03ff; /* blue */
> > +   gopobj->info.pixel_bitmask[3] = 0xc000; /* reserved */
> > +#endif
> > } else {
> > gopobj->info.pixel_format = EFI_GOT_BITMASK;
> > gopobj->info.pixel_bitmask[0] = 0xf800; /* red */
> >
> 
> 

Re: [PATCH] arm: rpi: perform XHCI firmware upload only once

[Matthias Brugger]

On 17/09/2021 10:42, Matthias Brugger wrote:



On 17/09/2021 10:19, Marek Szyprowski wrote:

XHCI firmware upload must be performed only once after initializing the
PCI bridge. This fixes USB stack initialization after calling "usb stop;
usb start" on Raspberry Pi 4B.

Signed-off-by: Marek Szyprowski 


Looks good to me. I'll wait a bit more to see if Nicolas can do a review as well 
before queuing it.




There was a race condition, I'll queque it now :)


Regards,
Matthias


---
  arch/arm/mach-bcm283x/msg.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index 347aece3cd..345f7fe2b7 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -170,6 +170,12 @@ int bcm2711_notify_vl805_reset(void)
  ALLOC_CACHE_ALIGN_BUFFER(struct msg_notify_vl805_reset,
   msg_notify_vl805_reset, 1);
  int ret;
+    static int done = false;
+
+    if (done)
+    return 0;
+
+    done = true;
  BCM2835_MBOX_INIT_HDR(msg_notify_vl805_reset);
  BCM2835_MBOX_INIT_TAG(_notify_vl805_reset->dev_addr,

Re: [PATCH] arm: rpi: perform XHCI firmware upload only once

[Matthias Brugger]

On 17/09/2021 10:19, Marek Szyprowski wrote:

XHCI firmware upload must be performed only once after initializing the
PCI bridge. This fixes USB stack initialization after calling "usb stop;
usb start" on Raspberry Pi 4B.

Signed-off-by: Marek Szyprowski 


Looks good to me. I'll wait a bit more to see if Nicolas can do a review as well 
before queuing it.


Regards,
Matthias


---
  arch/arm/mach-bcm283x/msg.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index 347aece3cd..345f7fe2b7 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -170,6 +170,12 @@ int bcm2711_notify_vl805_reset(void)
ALLOC_CACHE_ALIGN_BUFFER(struct msg_notify_vl805_reset,
 msg_notify_vl805_reset, 1);
int ret;
+   static int done = false;
+
+   if (done)
+   return 0;
+
+   done = true;
  
  	BCM2835_MBOX_INIT_HDR(msg_notify_vl805_reset);

BCM2835_MBOX_INIT_TAG(_notify_vl805_reset->dev_addr,

[PATCH] arm: rpi: perform XHCI firmware upload only once

[Marek Szyprowski]

XHCI firmware upload must be performed only once after initializing the
PCI bridge. This fixes USB stack initialization after calling "usb stop;
usb start" on Raspberry Pi 4B.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/mach-bcm283x/msg.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index 347aece3cd..345f7fe2b7 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -170,6 +170,12 @@ int bcm2711_notify_vl805_reset(void)
ALLOC_CACHE_ALIGN_BUFFER(struct msg_notify_vl805_reset,
 msg_notify_vl805_reset, 1);
int ret;
+   static int done = false;
+
+   if (done)
+   return 0;
+
+   done = true;
 
BCM2835_MBOX_INIT_HDR(msg_notify_vl805_reset);
BCM2835_MBOX_INIT_TAG(_notify_vl805_reset->dev_addr,
-- 
2.17.1

[PATCH v3 01/10] ARM: meson: Sync Amlogic DT from Linux 5.14

[Neil Armstrong]

Import Amlogic DT changes from Linux commit 7d2a07b76933 ("Linux 5.14"),
dt-bindings clock changes and new meson-g12b-gsking-x.dts,
meson-sm1-bananapi-m5 & odroid-hc4 boards.

Signed-off-by: Neil Armstrong 
---
 arch/arm/dts/Makefile |   3 +
 arch/arm/dts/meson-axg-s400.dts   |  16 +
 arch/arm/dts/meson-axg.dtsi   | 181 +
 arch/arm/dts/meson-g12-common.dtsi|  31 +-
 arch/arm/dts/meson-g12a-sei510.dts|   2 +-
 arch/arm/dts/meson-g12b-gsking-x.dts  | 133 
 arch/arm/dts/meson-g12b-gtking-pro.dts|  23 +-
 arch/arm/dts/meson-g12b-gtking.dts|  22 +-
 arch/arm/dts/meson-g12b-odroid-n2-plus.dts|   2 +-
 arch/arm/dts/meson-g12b-odroid-n2.dtsi|  74 +-
 arch/arm/dts/meson-g12b-w400.dtsi |   2 +-
 arch/arm/dts/meson-g12b.dtsi  |   4 +
 arch/arm/dts/meson-gx-libretech-pc.dtsi   |   2 +-
 arch/arm/dts/meson-gx-p23x-q20x.dtsi  |   2 +-
 arch/arm/dts/meson-gx.dtsi|   7 +
 arch/arm/dts/meson-gxbb-nanopi-k2.dts |  42 +-
 arch/arm/dts/meson-gxbb-odroidc2.dts  |  44 +-
 arch/arm/dts/meson-gxl-s805x-libretech-ac.dts |   2 +-
 arch/arm/dts/meson-gxl-s905x-khadas-vim.dts   |  50 +-
 .../dts/meson-gxl-s905x-libretech-cc-v2.dts   |   6 +-
 arch/arm/dts/meson-gxl-s905x-libretech-cc.dts |   2 +-
 arch/arm/dts/meson-gxm-khadas-vim2.dts|  55 +-
 arch/arm/dts/meson-gxm-wetek-core2.dts|   2 +-
 arch/arm/dts/meson-gxm.dtsi   |  20 +
 arch/arm/dts/meson-khadas-vim3.dtsi   |  73 +-
 arch/arm/dts/meson-sm1-bananapi-m5.dts| 646 ++
 arch/arm/dts/meson-sm1-khadas-vim3l.dts   |  20 +-
 arch/arm/dts/meson-sm1-odroid-c4.dts  | 448 +---
 arch/arm/dts/meson-sm1-odroid-hc4.dts | 140 
 arch/arm/dts/meson-sm1-odroid.dtsi| 449 
 arch/arm/dts/meson-sm1-sei610.dts |  10 +-
 arch/arm/dts/meson-sm1.dtsi   |  12 +-
 include/dt-bindings/clock/axg-clkc.h  |  26 +-
 include/dt-bindings/clock/g12a-clkc.h |   2 +
 34 files changed, 2030 insertions(+), 523 deletions(-)
 create mode 100644 arch/arm/dts/meson-g12b-gsking-x.dts
 create mode 100644 arch/arm/dts/meson-sm1-bananapi-m5.dts
 create mode 100644 arch/arm/dts/meson-sm1-odroid-hc4.dts
 create mode 100644 arch/arm/dts/meson-sm1-odroid.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index fc16a57e60..f0160d2dc0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -177,11 +177,14 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-g12a-sei510.dtb \
meson-g12b-gtking.dtb \
meson-g12b-gtking-pro.dtb \
+   meson-g12b-gsking-x.dtb \
meson-g12b-odroid-n2.dtb \
meson-g12b-odroid-n2-plus.dtb \
meson-g12b-a311d-khadas-vim3.dtb \
+   meson-sm1-bananapi-m5.dtb \
meson-sm1-khadas-vim3l.dtb \
meson-sm1-odroid-c4.dtb \
+   meson-sm1-odroid-hc4.dtb \
meson-sm1-sei610.dtb
 dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
tegra20-medcom-wide.dtb \
diff --git a/arch/arm/dts/meson-axg-s400.dts b/arch/arm/dts/meson-axg-s400.dts
index cb1360ae12..359589d1df 100644
--- a/arch/arm/dts/meson-axg-s400.dts
+++ b/arch/arm/dts/meson-axg-s400.dts
@@ -441,6 +441,16 @@
status = "okay";
 };
 
+ {
+   reset-gpios = < GPIOX_19 GPIO_ACTIVE_LOW>;
+   status = "okay";
+};
+
+ {
+   reset-gpios = < GPIOZ_10 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
+   status = "okay";
+};
+
 _ab {
status = "okay";
pinctrl-0 = <_a_x20_pins>;
@@ -584,3 +594,9 @@
pinctrl-0 = <_ao_a_pins>;
pinctrl-names = "default";
 };
+
+ {
+   status = "okay";
+   dr_mode = "otg";
+   vbus-supply = <_pwr>;
+};
diff --git a/arch/arm/dts/meson-axg.dtsi b/arch/arm/dts/meson-axg.dtsi
index b9efc84692..3f5254eeb4 100644
--- a/arch/arm/dts/meson-axg.dtsi
+++ b/arch/arm/dts/meson-axg.dtsi
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "amlogic,meson-axg";
@@ -171,6 +172,98 @@
#size-cells = <2>;
ranges;
 
+   pcieA: pcie@f980 {
+   compatible = "amlogic,axg-pcie", "snps,dw-pcie";
+   reg = <0x0 0xf980 0x0 0x40>,
+ <0x0 0xff646000 0x0 0x2000>,
+ <0x0 0xf9f0 0x0 0x10>;
+   reg-names = "elbi", "cfg", "config";
+   interrupts = ;
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0>;
+   interrupt-map = <0 0 0 0  GIC_SPI 179 
IRQ_TYPE_EDGE_RISING>;
+   bus-range = <0x0 0xff>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   ranges 

[PATCH v3 10/10] ARM: amlogic: add Banana Pi M5

[Neil Armstrong]

Banana Pi BPI-M5 is a credit card format SBC with the following features:
- Amlogic S905X3 quad core Cortex-A55
- Mali-G31 GPU
- 4GB LPDDR4
- 16GB eMMC flash
- 4 USB 3.0
- 1 GbE ethernet
- HDMI output
- 2x LEDS
- SDCard
- 2.5mm Jack with Stereo Audio + CVBS
- Infrared Received
- ADC Button
- GPIO Button
- 40 pins header + 3pins debug header

Signed-off-by: Neil Armstrong 
---
 .../arm/dts/meson-sm1-bananapi-m5-u-boot.dtsi | 13 
 board/amlogic/u200/MAINTAINERS|  1 +
 configs/bananapi-m5_defconfig | 73 +++
 doc/board/amlogic/index.rst   |  1 +
 4 files changed, 88 insertions(+)
 create mode 100644 arch/arm/dts/meson-sm1-bananapi-m5-u-boot.dtsi
 create mode 100644 configs/bananapi-m5_defconfig

diff --git a/arch/arm/dts/meson-sm1-bananapi-m5-u-boot.dtsi 
b/arch/arm/dts/meson-sm1-bananapi-m5-u-boot.dtsi
new file mode 100644
index 00..a86fdb5668
--- /dev/null
+++ b/arch/arm/dts/meson-sm1-bananapi-m5-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 BayLibre, SAS
+ * Author: Neil Armstrong 
+ */
+
+#include "meson-sm1-u-boot.dtsi"
+
+ {
+   snps,reset-gpio = < GPIOZ_15 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
+   snps,reset-delays-us = <0 1 100>;
+   snps,reset-active-low;
+};
diff --git a/board/amlogic/u200/MAINTAINERS b/board/amlogic/u200/MAINTAINERS
index 8c23f9a7d3..655cf64a3d 100644
--- a/board/amlogic/u200/MAINTAINERS
+++ b/board/amlogic/u200/MAINTAINERS
@@ -4,4 +4,5 @@ S:  Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/u200/
 F: configs/u200_defconfig
+F: configs/bananapi-m5_defconfig
 F: doc/board/amlogic/u200.rst
diff --git a/configs/bananapi-m5_defconfig b/configs/bananapi-m5_defconfig
new file mode 100644
index 00..a088761622
--- /dev/null
+++ b/configs/bananapi-m5_defconfig
@@ -0,0 +1,73 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MESON=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="meson-sm1-bananapi-m5"
+CONFIG_MESON_G12A=y
+CONFIG_DEBUG_UART_BASE=0xff803000
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_IDENT_STRING="bpi-m5"
+CONFIG_DEBUG_UART=y
+CONFIG_OF_BOARD_SETUP=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_MISC_INIT_R=y
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_IMI is not set
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+CONFIG_OF_CONTROL=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_ADC=y
+CONFIG_SARADC_MESON=y
+CONFIG_MMC_MESON_GX=y
+CONFIG_PHY_REALTEK=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_DM_MDIO_MUX=y
+CONFIG_ETH_DESIGNWARE_MESON8B=y
+CONFIG_MDIO_MUX_MESON_G12A=y
+CONFIG_MESON_G12A_USB_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_MESON_G12A=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_MESON_EE_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_RESET=y
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_DEBUG_UART_SKIP_INIT=y
+CONFIG_MESON_SERIAL=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
+CONFIG_USB_DWC3_MESON_G12A=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b8e
+CONFIG_USB_GADGET_PRODUCT_NUM=0xfada
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_USB_GADGET_DWC2_OTG_PHY_BUS_WIDTH_8=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_DM_VIDEO=y
+# CONFIG_VIDEO_BPP8 is not set
+# CONFIG_VIDEO_BPP16 is not set
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_VIDEO_MESON=y
+CONFIG_VIDEO_DT_SIMPLEFB=y
+CONFIG_SPLASH_SCREEN=y
+CONFIG_SPLASH_SCREEN_ALIGN=y
+CONFIG_VIDEO_BMP_RLE8=y
+CONFIG_BMP_16BPP=y
+CONFIG_BMP_24BPP=y
+CONFIG_BMP_32BPP=y
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
index de1a9ce284..2913ab281a 100644
--- a/doc/board/amlogic/index.rst
+++ b/doc/board/amlogic/index.rst
@@ -19,6 +19,7 @@ This matrix concerns the actual source code version.
 |  | Nanopi-K2 | Khadas-VIM  | Libretech-PC |  
  | SEI510 | Khadas-VIM3 | Khadas-VIM3L |
 |  | P200  | LibreTech-CC v1 | WeTek Core2  |  
  || GT-King/Pro | Odroid-C4|
 |  | P201  | LibreTech-AC v2 |  |  
  || GSKing-X| Odroid-HC4   |
+|   |   | |  | 
   || | BananaPi-M5  |
 
+---+---+-+--+++-+--+
 | UART | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
 

[PATCH v3 09/10] ARM: meson: add Beelink GS-King X board

[Neil Armstrong]

The Beelink GS-King X is a variant of the GS King boards but with an internal
USB to SATA bridge and advanced audio features.

Signed-off-by: Neil Armstrong 
---
 arch/arm/dts/meson-g12b-gsking-x-u-boot.dtsi |  7 ++
 board/amlogic/beelink-s922x/MAINTAINERS  |  1 +
 configs/beelink-gsking-x_defconfig   | 70 
 doc/board/amlogic/index.rst  |  2 +-
 4 files changed, 79 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/meson-g12b-gsking-x-u-boot.dtsi
 create mode 100644 configs/beelink-gsking-x_defconfig

diff --git a/arch/arm/dts/meson-g12b-gsking-x-u-boot.dtsi 
b/arch/arm/dts/meson-g12b-gsking-x-u-boot.dtsi
new file mode 100644
index 00..236f2468dc
--- /dev/null
+++ b/arch/arm/dts/meson-g12b-gsking-x-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ */
+
+#include "meson-g12-common-u-boot.dtsi"
diff --git a/board/amlogic/beelink-s922x/MAINTAINERS 
b/board/amlogic/beelink-s922x/MAINTAINERS
index 7f223df4ae..47b622765a 100644
--- a/board/amlogic/beelink-s922x/MAINTAINERS
+++ b/board/amlogic/beelink-s922x/MAINTAINERS
@@ -5,5 +5,6 @@ L:  u-boot-amlo...@groups.io
 F: board/amlogic/beelink-s922x/
 F: configs/beelink-gtking_defconfig
 F: configs/beelink-gtkingpro_defconfig
+F: configs/beelink-gsking-x_defconfig
 F: doc/board/amlogic/beelink-gtking.rst
 F: doc/board/amlogic/beelink-gtkingpro.rst
diff --git a/configs/beelink-gsking-x_defconfig 
b/configs/beelink-gsking-x_defconfig
new file mode 100644
index 00..8a76e8829a
--- /dev/null
+++ b/configs/beelink-gsking-x_defconfig
@@ -0,0 +1,70 @@
+CONFIG_ARM=y
+CONFIG_SYS_BOARD="beelink-s922x"
+CONFIG_ARCH_MESON=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="meson-g12b-gsking-x"
+CONFIG_MESON_G12A=y
+CONFIG_DEBUG_UART_BASE=0xff803000
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_IDENT_STRING=" beelink"
+CONFIG_DEBUG_UART=y
+CONFIG_OF_BOARD_SETUP=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_MISC_INIT_R=y
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_IMI is not set
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+CONFIG_OF_CONTROL=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_MMC_MESON_GX=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_PHY_REALTEK=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_DM_MDIO_MUX=y
+CONFIG_ETH_DESIGNWARE_MESON8B=y
+CONFIG_MDIO_MUX_MESON_G12A=y
+CONFIG_MESON_G12A_USB_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_MESON_G12A=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_MESON_EE_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_RESET=y
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_DEBUG_UART_SKIP_INIT=y
+CONFIG_MESON_SERIAL=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
+CONFIG_USB_DWC3_MESON_G12A=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b8e
+CONFIG_USB_GADGET_PRODUCT_NUM=0xfada
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_USB_GADGET_DWC2_OTG_PHY_BUS_WIDTH_8=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_DM_VIDEO=y
+# CONFIG_VIDEO_BPP8 is not set
+# CONFIG_VIDEO_BPP16 is not set
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_VIDEO_MESON=y
+CONFIG_VIDEO_DT_SIMPLEFB=y
+CONFIG_SPLASH_SCREEN=y
+CONFIG_SPLASH_SCREEN_ALIGN=y
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
index af12f94fde..de1a9ce284 100644
--- a/doc/board/amlogic/index.rst
+++ b/doc/board/amlogic/index.rst
@@ -18,7 +18,7 @@ This matrix concerns the actual source code version.
 | Boards   | Odroid-C2 | P212| Khadas 
VIM2  | S400   | U200   | Odroid-N2   | SEI610   |
 |  | Nanopi-K2 | Khadas-VIM  | Libretech-PC |  
  | SEI510 | Khadas-VIM3 | Khadas-VIM3L |
 |  | P200  | LibreTech-CC v1 | WeTek Core2  |  
  || GT-King/Pro | Odroid-C4|
-|  | P201  | LibreTech-AC v2 |  |  
  || | Odroid-HC4   |
+|  | P201  | LibreTech-AC v2 |  |  
  || GSKing-X| Odroid-HC4   |
 
+---+---+-+--+++-+--+
 | UART | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
 
+---+---+-+--+++-+--+
-- 
2.25.1

[PATCH v3 08/10] doc: boards: amlogic: update for Odroid HC4

[Neil Armstrong]

Add documentation bits for the Odroid-HC4.

Signed-off-by: Neil Armstrong 
---
 doc/board/amlogic/index.rst | 2 +-
 doc/board/amlogic/odroid-c4.rst | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
index 8da7afddb4..af12f94fde 100644
--- a/doc/board/amlogic/index.rst
+++ b/doc/board/amlogic/index.rst
@@ -18,7 +18,7 @@ This matrix concerns the actual source code version.
 | Boards   | Odroid-C2 | P212| Khadas 
VIM2  | S400   | U200   | Odroid-N2   | SEI610   |
 |  | Nanopi-K2 | Khadas-VIM  | Libretech-PC |  
  | SEI510 | Khadas-VIM3 | Khadas-VIM3L |
 |  | P200  | LibreTech-CC v1 | WeTek Core2  |  
  || GT-King/Pro | Odroid-C4|
-|  | P201  | LibreTech-AC v2 |  |  
  || |  |
+|  | P201  | LibreTech-AC v2 |  |  
  || | Odroid-HC4   |
 
+---+---+-+--+++-+--+
 | UART | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
 
+---+---+-+--+++-+--+
diff --git a/doc/board/amlogic/odroid-c4.rst b/doc/board/amlogic/odroid-c4.rst
index 5a5a8688b8..f66d60a54d 100644
--- a/doc/board/amlogic/odroid-c4.rst
+++ b/doc/board/amlogic/odroid-c4.rst
@@ -17,6 +17,9 @@ Co. Ltd with the following specifications:
  - UART serial
  - Infrared receiver
 
+The ODROID-HC4 is a variant with a PCIe-SATA controller, the same commands
+applies for HC4.
+
 Schematics are available on the manufacturer website.
 
 U-Boot compilation
-- 
2.25.1

[PATCH v3 07/10] ARM: amlogic: add support for Odroid-HC4 device

[Neil Armstrong]

The Odroid-HC4 is a variant of the Odroid-C4 board but with a PCIe-SATA bridge
instead of the USB3 ports.

Signed-off-by: Neil Armstrong 
---
 arch/arm/dts/meson-sm1-odroid-hc4-u-boot.dtsi | 23 +
 board/amlogic/odroid-n2/MAINTAINERS   |  1 +
 configs/odroid-hc4_defconfig  | 92 +++
 3 files changed, 116 insertions(+)
 create mode 100644 arch/arm/dts/meson-sm1-odroid-hc4-u-boot.dtsi
 create mode 100644 configs/odroid-hc4_defconfig

diff --git a/arch/arm/dts/meson-sm1-odroid-hc4-u-boot.dtsi 
b/arch/arm/dts/meson-sm1-odroid-hc4-u-boot.dtsi
new file mode 100644
index 00..963bf96b25
--- /dev/null
+++ b/arch/arm/dts/meson-sm1-odroid-hc4-u-boot.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 BayLibre, SAS
+ * Author: Neil Armstrong 
+ */
+
+#include "meson-sm1-u-boot.dtsi"
+
+ {
+   snps,reset-gpio = < GPIOZ_15 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
+   snps,reset-delays-us = <0 1 100>;
+   snps,reset-active-low;
+};
+
+/* SARADC is needed for proper board variant detection */
+ {
+   status = "okay";
+   vref-supply = <_1v8>;
+};
+
+_vdd {
+   gpio = <_ao GPIOAO_3 GPIO_OPEN_DRAIN>;
+};
diff --git a/board/amlogic/odroid-n2/MAINTAINERS 
b/board/amlogic/odroid-n2/MAINTAINERS
index 77f7746346..43724e6fdd 100644
--- a/board/amlogic/odroid-n2/MAINTAINERS
+++ b/board/amlogic/odroid-n2/MAINTAINERS
@@ -5,5 +5,6 @@ L:  u-boot-amlo...@groups.io
 F: board/amlogic/odroid-n2/
 F: configs/odroid-n2_defconfig
 F: configs/odroid-c4_defconfig
+F: configs/odroid-hc4_defconfig
 F: doc/board/amlogic/odroid-n2.rst
 F: doc/board/amlogic/odroid-c4.rst
diff --git a/configs/odroid-hc4_defconfig b/configs/odroid-hc4_defconfig
new file mode 100644
index 00..7671496218
--- /dev/null
+++ b/configs/odroid-hc4_defconfig
@@ -0,0 +1,92 @@
+CONFIG_ARM=y
+CONFIG_SYS_BOARD="odroid-n2"
+CONFIG_ARCH_MESON=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="meson-sm1-odroid-hc4"
+CONFIG_MESON_G12A=y
+CONFIG_DEBUG_UART_BASE=0xff803000
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_IDENT_STRING=" odroid-hc4"
+CONFIG_DEBUG_UART=y
+CONFIG_AHCI=y
+CONFIG_OF_BOARD_SETUP=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_MISC_INIT_R=y
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_IMI is not set
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+CONFIG_OF_CONTROL=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_ADC=y
+CONFIG_SARADC_MESON=y
+CONFIG_SATA=y
+CONFIG_SCSI_AHCI=y
+CONFIG_AHCI_PCI=y
+CONFIG_MMC_MESON_GX=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_XTX=y
+CONFIG_PHY_REALTEK=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_DM_MDIO_MUX=y
+CONFIG_ETH_DESIGNWARE_MESON8B=y
+CONFIG_MDIO_MUX_MESON_G12A=y
+CONFIG_PCI=y
+CONFIG_PCIE_DW_MESON=y
+CONFIG_MESON_G12A_USB_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_MESON_G12A=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_MESON_EE_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_RESET=y
+CONFIG_SCSI=y
+CONFIG_DM_SCSI=y
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_DEBUG_UART_SKIP_INIT=y
+CONFIG_MESON_SERIAL=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_MESON_SPIFC=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
+CONFIG_USB_DWC3_MESON_G12A=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b8e
+CONFIG_USB_GADGET_PRODUCT_NUM=0xfada
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_USB_GADGET_DWC2_OTG_PHY_BUS_WIDTH_8=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_DM_VIDEO=y
+# CONFIG_VIDEO_BPP8 is not set
+# CONFIG_VIDEO_BPP16 is not set
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_VIDEO_MESON=y
+CONFIG_VIDEO_DT_SIMPLEFB=y
+CONFIG_SPLASH_SCREEN=y
+CONFIG_SPLASH_SCREEN_ALIGN=y
+CONFIG_VIDEO_BMP_RLE8=y
+CONFIG_BMP_16BPP=y
+CONFIG_BMP_24BPP=y
+CONFIG_BMP_32BPP=y
+CONFIG_OF_LIBFDT_OVERLAY=y
-- 
2.25.1

[PATCH v3 05/10] configs: meson64: add SCSI boot target

[Neil Armstrong]

Add SCSI target to be able to boot from the SATA disks on the Odroid HC4 using
an on-board AHCI PCIe controller.

Signed-off-by: Neil Armstrong 
Signed-off-by: Mark Kettenis 
---
 include/configs/meson64.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/configs/meson64.h b/include/configs/meson64.h
index f9bb0240d2..08816fff1f 100644
--- a/include/configs/meson64.h
+++ b/include/configs/meson64.h
@@ -66,6 +66,12 @@
#define BOOT_TARGET_NVME(func)
 #endif
 
+#ifdef CONFIG_CMD_SCSI
+   #define BOOT_TARGET_SCSI(func) func(SCSI, scsi, 0)
+#else
+   #define BOOT_TARGET_SCSI(func)
+#endif
+
 #ifndef BOOT_TARGET_DEVICES
 #define BOOT_TARGET_DEVICES(func) \
func(ROMUSB, romusb, na)  \
@@ -74,6 +80,7 @@
func(MMC, mmc, 2) \
BOOT_TARGET_DEVICES_USB(func) \
BOOT_TARGET_NVME(func) \
+   BOOT_TARGET_SCSI(func) \
func(PXE, pxe, na) \
func(DHCP, dhcp, na)
 #endif
-- 
2.25.1

[PATCH v3 03/10] ARM: meson: keep HW order for MMC devices

[Neil Armstrong]

Since Linux commmit [1], the order is fixed with aliases, in order to keep the
MMC device order, set it back to HW order in U-Boot dtsi files.

[1] ab547c4fb39f ("arm64: dts: amlogic: Assign a fixed index to mmc devices")

Signed-off-by: Neil Armstrong 
---
 arch/arm/dts/meson-g12-common-u-boot.dtsi | 7 +++
 arch/arm/dts/meson-gx-u-boot.dtsi | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/dts/meson-g12-common-u-boot.dtsi 
b/arch/arm/dts/meson-g12-common-u-boot.dtsi
index 38fd3d3feb..b1f60b15c9 100644
--- a/arch/arm/dts/meson-g12-common-u-boot.dtsi
+++ b/arch/arm/dts/meson-g12-common-u-boot.dtsi
@@ -5,6 +5,13 @@
  */
 
 / {
+   /* Keep HW order from U-boot */
+   aliases {
+   /delete-property/ mmc0;
+   /delete-property/ mmc1;
+   /delete-property/ mmc2;
+   };
+
soc {
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/meson-gx-u-boot.dtsi 
b/arch/arm/dts/meson-gx-u-boot.dtsi
index 17d2cb95c1..fb6952f1d8 100644
--- a/arch/arm/dts/meson-gx-u-boot.dtsi
+++ b/arch/arm/dts/meson-gx-u-boot.dtsi
@@ -5,6 +5,13 @@
  */
 
 / {
+   /* Keep HW order from U-boot */
+   aliases {
+   /delete-property/ mmc0;
+   /delete-property/ mmc1;
+   /delete-property/ mmc2;
+   };
+
soc {
u-boot,dm-pre-reloc;
};
-- 
2.25.1

[PATCH v3 04/10] ARM: meson-axg: remove local USB nodes

[Neil Armstrong]

Drop the local USB nodes after Linux 5.14 sync.

Signed-off-by: Neil Armstrong 
---
 arch/arm/dts/meson-axg-s400-u-boot.dtsi |  8 
 arch/arm/dts/meson-axg-u-boot.dtsi  | 62 -
 2 files changed, 70 deletions(-)
 delete mode 100644 arch/arm/dts/meson-axg-u-boot.dtsi

diff --git a/arch/arm/dts/meson-axg-s400-u-boot.dtsi 
b/arch/arm/dts/meson-axg-s400-u-boot.dtsi
index 2c4b06f140..334650d610 100644
--- a/arch/arm/dts/meson-axg-s400-u-boot.dtsi
+++ b/arch/arm/dts/meson-axg-s400-u-boot.dtsi
@@ -3,8 +3,6 @@
  * Copyright (c) 2017 Amlogic, Inc. All rights reserved.
  */
 
-#include "meson-axg-u-boot.dtsi"
-
 /* wifi module */
 _emmc_b {
status = "disabled";
@@ -15,12 +13,6 @@
status = "okay";
 };
 
- {
-   status = "okay";
-   dr_mode = "otg";
-   vbus-supply = <_pwr>;
-};
-
 _phy1 {
phy-supply = <_5v>;
 };
diff --git a/arch/arm/dts/meson-axg-u-boot.dtsi 
b/arch/arm/dts/meson-axg-u-boot.dtsi
deleted file mode 100644
index cb1c71e78c..00
--- a/arch/arm/dts/meson-axg-u-boot.dtsi
+++ /dev/null
@@ -1,62 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2020 BayLibre, SAS.
- * Author: Neil Armstrong 
- */
-
-/ {
-   soc {
-   usb: usb@ffe09080 {
-   compatible = "amlogic,meson-gxl-usb-ctrl";
-   reg = <0x0 0xffe09080 0x0 0x20>;
-   interrupts = ;
-   #address-cells = <2>;
-   #size-cells = <2>;
-   ranges;
-
-   clocks = < CLKID_USB>, < 
CLKID_USB1_DDR_BRIDGE>;
-   clock-names = "usb_ctrl", "ddr";
-   resets = < RESET_USB_OTG>;
-
-   dr_mode = "otg";
-
-   phys = <_phy1>;
-   phy-names = "usb2-phy1";
-
-   dwc2: usb@ff40 {
-   compatible = "amlogic,meson-g12a-usb", 
"snps,dwc2";
-   reg = <0x0 0xff40 0x0 0x4>;
-   interrupts = ;
-   clocks = < CLKID_USB1>;
-   clock-names = "otg";
-   phys = <_phy1>;
-   dr_mode = "peripheral";
-   g-rx-fifo-size = <192>;
-   g-np-tx-fifo-size = <128>;
-   g-tx-fifo-size = <128 128 16 16 16>;
-   };
-
-   dwc3: usb@ff50 {
-   compatible = "snps,dwc3";
-   reg = <0x0 0xff50 0x0 0x10>;
-   interrupts = ;
-   dr_mode = "host";
-   maximum-speed = "high-speed";
-   snps,dis_u2_susphy_quirk;
-   };
-   };
-   };
-};
-
- {
-   usb2_phy1: phy@9020 {
-   compatible = "amlogic,meson-gxl-usb2-phy";
-   #phy-cells = <0>;
-   reg = <0x0 0x9020 0x0 0x20>;
-   clocks = < CLKID_USB>;
-   clock-names = "phy";
-   resets = < RESET_USB_OTG>;
-   reset-names = "phy";
-   status = "okay";
-   };
-};
-- 
2.25.1

[PATCH v3 06/10] distro_bootcmd: run pci enum for scsi_boot just like it is done for nvme_boot

[Neil Armstrong]

The SCSI device can be a PCIe adapter, so run pcie enum if enabled.

Signed-off-by: Mark Kettenis 
Signed-off-by: Neil Armstrong 
---
 include/config_distro_bootcmd.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 750e9e04e8..3f724aa10f 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -226,6 +226,7 @@
"fi\0" \
\
"scsi_boot=" \
+   BOOTENV_RUN_PCI_ENUM \
BOOTENV_RUN_SCSI_INIT \
BOOTENV_SHARED_BLKDEV_BODY(scsi)
 #define BOOTENV_DEV_SCSI   BOOTENV_DEV_BLKDEV
-- 
2.25.1

[PATCH v3 02/10] usb: dwc3: meson-gxl: add AXG compatible

[Neil Armstrong]

Upstream Linux uses the "amlogic,meson-axg-usb-ctrl" for AXG SoCs.

This adds it to the compatible list for this driver.

Reported-by: Vyacheslav Bocharov 
Signed-off-by: Neil Armstrong 
---
 drivers/usb/dwc3/dwc3-meson-gxl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc3/dwc3-meson-gxl.c 
b/drivers/usb/dwc3/dwc3-meson-gxl.c
index 08467d6210..b8f3886173 100644
--- a/drivers/usb/dwc3/dwc3-meson-gxl.c
+++ b/drivers/usb/dwc3/dwc3-meson-gxl.c
@@ -409,6 +409,7 @@ static int dwc3_meson_gxl_remove(struct udevice *dev)
 }
 
 static const struct udevice_id dwc3_meson_gxl_ids[] = {
+   { .compatible = "amlogic,meson-axg-usb-ctrl" },
{ .compatible = "amlogic,meson-gxl-usb-ctrl" },
{ .compatible = "amlogic,meson-gxm-usb-ctrl" },
{ }
-- 
2.25.1

Re: [PATCH v2] board: sifive: Fix a potential build warning in board_fdt_blob_setup()

[Rick Chen]

> From: Bin Meng 
> Sent: Saturday, September 11, 2021 10:31 PM
> To: Zong Li ; Leo Yu-Chi Liang(梁育齊) 
> ; Rick Jian-Zhi Chen(陳建志) ; 
> u-boot@lists.denx.de
> Subject: [PATCH v2] board: sifive: Fix a potential build warning in 
> board_fdt_blob_setup()
>
> Commit 47d73ba4f4a4 ("board: sifive: overwrite board_fdt_blob_setup in u-boot 
> proper") added a board-specific implementation of board_fdt_blob_setup() 
> which takes a pointer as the return value, but it does not return anything if 
> CONFIG_OF_SEPARATE is not enabled. This will cause a build warning seen when 
> testing booting S-mode U-Boot directly from QEMU, per the instructions in [1]:
>
>   board/sifive/unleashed/unleashed.c: In function ‘board_fdt_blob_setup’:
>   board/sifive/unleashed/unleashed.c:125:1: warning: control reaches end of 
> non-void function [-Wreturn-type]
>
> Return &_end as the default case.
>
> [1] 
> https://qemu.readthedocs.io/en/latest/system/riscv/sifive_u.html#running-u-boot
>
> Signed-off-by: Bin Meng 
>
> ---
>
> Changes in v2:
> - Correct the commit title
>
>  board/sifive/unleashed/unleashed.c | 4 ++--  
> board/sifive/unmatched/unmatched.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Rick Chen