date:20231017

Hi Caleb,

On Tue, 17 Oct 2023 at 11:59, Caleb Connolly  wrote:
>
> Hi Both,
>
> [...]
> >>>
> >>> @@ -513,13 +517,23 @@ ulong write_smbios_table(ulong addr)
> >>>*/
> >>>   table_addr = (ulong)map_sysmem(tables, 0);
> >>>   if (sizeof(table_addr) > sizeof(u32) && table_addr > 
> >>> (ulong)UINT_MAX) {
> >>
> >> You have to check the end address of the table not the start address here.
> >>
> >> The SMBIOS specification says that you should always supply a 32bit
> >> SMBIOS entry point. Of course this is not possible on boards that don't
> >> have low memory.
> >>
> >> In install_smbios_table() this can be achieved by calling
> >> efi_allocate_pages() with EFI_MAX_ALLOCATE_TYPE and a maximum address of
> >> 4 GiB - 1. Only if this fails use high memory.
> >
> > Hmm perhaps we need a way to allocate memory below 4GB in U-Boot? How
> > does this EFI function work?
>
> Yes, prior to 53fab13a7b11 ("efi: Use the installed SMBIOS tables")
> efi_allocate_pages() was called directly from efi_smbios_register(). My
> boards all malloc() memory above the 4GB boundary and I just recently
> rebased and hit a regression caused by this.
>
> In my testing, calling efi_allocate_pages() from install_smbios_table()
> did work, but I figure that's probably not intended behaviour...
>
> I can confirm that this series does allow my boards to boot again, but
> dmidecode is unable to decode the SMBIOS 3.0 table (even with
> STRICT_DEVMEM disabled fwiw).

OK thank you for digging into this. So I suppose I can repeat that in
qemu, with a suitable distro?

>
> Below is EFI and board memory map info after applying this patch series.
>
> => efidebug tables
> Cannot read EFI system partition
> Cannot read EFI system partition
> Failed to persist EFI variables
> 00017ea22040  32313633-3532-3634-2d66-3765662d3463  EFI Conformance
> Profiles Table
> 00017ea21040  36366265-3139-6138-2d37-6565662d3430  Runtime properties
> 00017fb13000  64663266-3531-3434-2d39-3739342d3461  (unknown)
> => efidebug memmap
> Type StartEnd  Attributes
>    ==
> CONVENTIONAL 8000-00017ea1f000 WB
> BOOT DATA00017ea1f000-00017ea21000 WB
> RUNTIME DATA 00017ea21000-00017ea22000 WB|RT
> BOOT DATA00017ea22000-00017ea23000 WB
> RUNTIME DATA 00017ea23000-00017ea25000 WB|RT
> BOOT DATA00017ea25000-00017ea26000 WB
> RUNTIME DATA 00017ea26000-00017ea36000 WB|RT
> BOOT DATA00017ea36000-00017eaef000 WB
> BOOT CODE00017eaef000-00017fb13000 WB
> RUNTIME DATA 00017fb13000-00017fb14000 WB|RT
> BOOT CODE00017fb14000-00017ff2 WB
> RUNTIME CODE 00017ff2-00017ff3 WB|RT
> BOOT CODE00017ff3-00018000 WB
> BOOT DATA00018000-00027c7a WB
> => bdinfo
> boot_params = 0x
> DRAM bank   = 0x
> -> start= 0x8000
> -> size = 0x0001
> DRAM bank   = 0x0001
> -> start= 0x00018000
> -> size = 0xfc7a
> flashstart  = 0x
> flashsize   = 0x
> flashoffset = 0x
> baudrate= 115200 bps
> relocaddr   = 0x00017ff26000
> reloc off   = 0x00017ff26000
> Build   = 64-bit
> fdt_blob= 0x00017faef6c0
> new_fdt = 0x00017faef6c0
> fdt_size= 0x00017680
> Video   = framebuffer@9D40 active
> FB base = 0x9d40
> FB size = 1080x2160x32
> lmb_dump_all:
>  memory.cnt = 0x1 / max = 0x40
>  memory[0]  [0x8000-0x27c79], 0x1fc7a bytes flags: 0
>  reserved.cnt = 0x7 / max = 0x40
>  reserved[0][0x8570-0x85cf], 0x0060 bytes flags: 4
>  reserved[1][0x85e0-0x85ef], 0x0010 bytes flags: 4
>  reserved[2][0x85fc-0x890f], 0x0314 bytes flags: 4
>  reserved[3][0x8ab0-0x8c416fff], 0x01917000 bytes flags: 4
>  reserved[4][0x8c50-0x97bf], 0x0b70 bytes flags: 4
>  reserved[5][0x9d40-0x9f7f], 0x0240 bytes flags: 4
>  reserved[6][0x17ea1f000-0x27c79], 0xfdd81000 bytes flags: 0
> devicetree  = board
> arch_number = 0x
> TLB addr= 0x00017fff
> irq_sp  = 0x00017faef6b0
> sp start= 0x00017faef6b0
> Early malloc usage: a78 / 2000
> >
> > I don't think EFI has been set up by the time this function is called.
> >
> > Regards,
> > Simon
>
> --
> // Caleb (they/them)

Regards,
Simon

Re: [PATCH] cros_ec: spi: disable annoying key echo on console

On Tue, 17 Oct 2023 at 13:25, Milan P. Stanić  wrote:
>
> on Peach-pi console every key press is echoed with message
> 'cros_ec_command: Returned status 1'
>
> this is not proper fix, just hack to disable this message
> ---
>  drivers/misc/cros_ec_spi.c | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Simon Glass 

I thought a similar patch went in ages ago but I now see it was in cros_ec_i2c.c

>
> diff --git a/drivers/misc/cros_ec_spi.c b/drivers/misc/cros_ec_spi.c
> index 001f0a85ca..7317f4b0f1 100644
> --- a/drivers/misc/cros_ec_spi.c
> +++ b/drivers/misc/cros_ec_spi.c
> @@ -151,7 +151,6 @@ int cros_ec_spi_command(struct udevice *udev, uint8_t 
> cmd, int cmd_version,
>
> /* Response code is first byte of message */
> if (p[0] != EC_RES_SUCCESS) {
> -   printf("%s: Returned status %d\n", __func__, p[0]);

log_debug()  (without the __func__) would be better


> return -(int)(p[0]);
> }
>
> --
> 2.42.0
>

Re: [PATCH v3 1/2] binman: openssl: x509: ti_secure_rom: Add support for bootcore_opts

Hi Neha,

On Tue, 17 Oct 2023 at 03:58, Neha Malcom Francis  wrote:
>
> Hi Simon
>
> On 08/10/23 04:39, Simon Glass wrote:
> > Hi Neha,
> >
> > On Fri, 6 Oct 2023 at 04:07, Neha Malcom Francis  wrote:
> >>
> >> According to the TRMs of K3 platform of devices, the ROM boot image
> >> format specifies a "Core Options Field" that provides the capability to
> >> set the boot core in lockstep when set to 0 or to split mode when set
> >> to 2. Add support for providing the same from the binman DTS. Also
> >> modify existing test case for ensuring future coverage.
> >>
> >> Signed-off-by: Neha Malcom Francis 
> >> ---
> >> Link to J721E TRM: https://www.ti.com/lit/zip/spruil1
> >> Section 4.5.4.1 Boot Info
> >>
> >> Changes in v3:
> >>  - updated function comments
> >>  - removed inconsistency in setting bootcore_opts to 32
> >>
> >> Changes in v2:
> >>  - included TRM link in commit message
> >>
> >>   tools/binman/btool/openssl.py   |  6 --
> >>   tools/binman/entries.rst|  1 +
> >>   tools/binman/etype/ti_secure_rom.py | 11 +--
> >>   tools/binman/etype/x509_cert.py |  3 ++-
> >>   tools/binman/test/297_ti_secure_rom.dts |  1 +
> >>   5 files changed, 17 insertions(+), 5 deletions(-)
> >>
>
> [...]
>
> >> diff --git a/tools/binman/test/297_ti_secure_rom.dts 
> >> b/tools/binman/test/297_ti_secure_rom.dts
> >> index d1313769f4..1a3eca9425 100644
> >> --- a/tools/binman/test/297_ti_secure_rom.dts
> >> +++ b/tools/binman/test/297_ti_secure_rom.dts
> >> @@ -9,6 +9,7 @@
> >>  binman {
> >>  ti-secure-rom {
> >>  content = <_binary>;
> >> +   core-opts = <2>;
> >
> > here ^
> >
> > Do you think there could be a binding file in dt-bindings/ for this value?
> >
>
> Sorry for getting back to this patch so late, but wanted to ask about this. I
> had seen a last version of getting the binman compatible in dt-bindings but I
> don't see it merged. Not sure where I would add this property in.

Yes it is difficult to do anything genuinely new.

I am anticipating something like compatible = "ti,secure-rom"

so I suppose you could create a header file with suitable values for
this property.

On the other hand, you could wait until there is progress with the bindings.


>
> >>  };
> >>  unsecure_binary: blob-ext {
> >>  filename = "ti_unsecure.bin";
> >> --
> >> 2.34.1
> >>
Regards,
Simon

Re: [PATCH v2 1/1] efi_loader: expose the device-tree file name

Hi Heinrich,

On Tue, 17 Oct 2023 at 07:50, Heinrich Schuchardt
 wrote:
>
> Forward and backward compatibility of Linux kernel device-trees is
> sometimes missing. One solution approach is to load a kernel specific
> device-tree. This can either be done via a U-Boot scripts (like the one
> generated by Debian package flash-kernel or by a boot loader like GRUB.
> The boot loader approach currently requires to know the device-tree name
> before first boot which makes it unusable for generic images.
>
> Expose the device-tree file name as EFI variable FdtFile.
> This will allow bootloaders to load a kernel specific device-tree.
>
> The variable will not be exposed on ACPI based systems or if the
> environment variable fdtfile is not defined.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
> Use a unique GUID to enable future U-Boot independent
> standardization.
> Do not try to add the variable on ACPI based systems.
> ---
>  include/efi_loader.h   |  5 +
>  lib/efi_loader/efi_setup.c | 30 ++
>  2 files changed, 35 insertions(+)

I was too slow to reply to v1.

Does grub load the DT? I was assuming that U-Boot would pass it on?
What is the interface between U-Boot and grub?

Regards,
Simon

Re: [RESEND PATCH v1 1/2] spi: add support for Amlogic A1 SPI Flash Controller

Hi Igor,

On Tue, 17 Oct 2023 at 11:18, Igor Prusov  wrote:
>
> From: Igor Prusov 
>
> Add A1 SPIFC driver from Linux. Slightly modified to use u-boot driver
> framework and accommodate to lack of ioread32_rep/iowrite32_rep.

Well, you could bring them in!

>
> Based on Linux version 6.6-rc4
>
> Signed-off-by: Igor Prusov 
> Signed-off-by: Martin Kurbanov 
> ---
>  drivers/spi/Kconfig  |   8 +
>  drivers/spi/Makefile |   1 +
>  drivers/spi/meson_spifc_a1.c | 384 +++
>  3 files changed, 393 insertions(+)
>  create mode 100644 drivers/spi/meson_spifc_a1.c

Reviewed-by: Simon Glass 

nits below

>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 854b8b88da..dedb366370 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -251,6 +251,14 @@ config MICROCHIP_COREQSPI
>   Enable the QSPI driver for Microchip FPGA QSPI controllers.
>   This driver can be used on Polarfire SoC.
>
> +config MESON_SPIFC_A1
> +   bool "Amlogic Meson A1 SPI Flash Controller driver"
> +   depends on ARCH_MESON
> +   help
> + Enable the Amlogic A1 SPI Flash Controller (SPIFC) driver.
> + This driver can be used to access the SPI NOR/NAND flash chips on
> + Amlogic A1 SoC.

What speeds does and modes it support? Can you add a little more detail?

> +
>  config MPC8XX_SPI
> bool "MPC8XX SPI Driver"
> depends on MPC8xx
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index c27b3327c3..14bdb97f18 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_ICH_SPI) +=  ich.o
>  obj-$(CONFIG_IPROC_QSPI) += iproc_qspi.o
>  obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
>  obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
> +obj-$(CONFIG_MESON_SPIFC_A1) += meson_spifc_a1.o
>  obj-$(CONFIG_MICROCHIP_COREQSPI) += microchip_coreqspi.o
>  obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
>  obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
> diff --git a/drivers/spi/meson_spifc_a1.c b/drivers/spi/meson_spifc_a1.c
> new file mode 100644
> index 00..4b840c4634
> --- /dev/null
> +++ b/drivers/spi/meson_spifc_a1.c
> @@ -0,0 +1,384 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for Amlogic A1 SPI flash controller (SPIFC)
> + *
> + * Copyright (c) 2023, SberDevices. All Rights Reserved.
> + *
> + * Author: Martin Kurbanov 
> + *
> + * Ported to u-boot:
> + * Author: Igor Prusov 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SPIFC_A1_AHB_CTRL_REG  0x0
> +#define SPIFC_A1_AHB_BUS_ENBIT(31)
> +
> +#define SPIFC_A1_USER_CTRL0_REG0x200
> +#define SPIFC_A1_USER_REQUEST_ENABLE   BIT(31)
> +#define SPIFC_A1_USER_REQUEST_FINISH   BIT(30)
> +#define SPIFC_A1_USER_DATA_UPDATED BIT(0)
> +
> +#define SPIFC_A1_USER_CTRL1_REG0x204
> +#define SPIFC_A1_USER_CMD_ENABLE   BIT(30)
> +#define SPIFC_A1_USER_CMD_MODE GENMASK(29, 28)
> +#define SPIFC_A1_USER_CMD_CODE GENMASK(27, 20)
> +#define SPIFC_A1_USER_ADDR_ENABLE  BIT(19)
> +#define SPIFC_A1_USER_ADDR_MODEGENMASK(18, 17)
> +#define SPIFC_A1_USER_ADDR_BYTES   GENMASK(16, 15)
> +#define SPIFC_A1_USER_DOUT_ENABLE  BIT(14)
> +#define SPIFC_A1_USER_DOUT_MODEGENMASK(11, 10)
> +#define SPIFC_A1_USER_DOUT_BYTES   GENMASK(9, 0)
> +
> +#define SPIFC_A1_USER_CTRL2_REG0x208
> +#define SPIFC_A1_USER_DUMMY_ENABLE BIT(31)
> +#define SPIFC_A1_USER_DUMMY_MODE   GENMASK(30, 29)
> +#define SPIFC_A1_USER_DUMMY_CLK_SYCLES GENMASK(28, 23)
> +
> +#define SPIFC_A1_USER_CTRL3_REG0x20c
> +#define SPIFC_A1_USER_DIN_ENABLE   BIT(31)
> +#define SPIFC_A1_USER_DIN_MODE GENMASK(28, 27)
> +#define SPIFC_A1_USER_DIN_BYTESGENMASK(25, 16)
> +
> +#define SPIFC_A1_USER_ADDR_REG 0x210
> +
> +#define SPIFC_A1_AHB_REQ_CTRL_REG  0x214
> +#define SPIFC_A1_AHB_REQ_ENABLEBIT(31)
> +
> +#define SPIFC_A1_ACTIMING0_REG (0x0088 << 2)
> +#define SPIFC_A1_TSLCH GENMASK(31, 30)
> +#define SPIFC_A1_TCLSH GENMASK(29, 28)
> +#define SPIFC_A1_TSHWL GENMASK(20, 16)
> +#define SPIFC_A1_TSHSL2GENMASK(15, 12)
> +#define SPIFC_A1_TSHSL1GENMASK(11, 8)
> +#define SPIFC_A1_TWHSL GENMASK(7, 0)
> +
> +#define SPIFC_A1_DBUF_CTRL_REG 0x240
> +#define SPIFC_A1_DBUF_DIR  BIT(31)
> +#define SPIFC_A1_DBUF_AUTO_UPDATE_ADDR BIT(30)
> +#define SPIFC_A1_DBUF_ADDR GENMASK(7, 0)
> +
> +#define SPIFC_A1_DBUF_DATA_REG 0x244
> +
> +#define SPIFC_A1_USER_DBUF_ADDR_REG0x248
> +
> +#define SPIFC_A1_BUFFER_SIZE   512U
> +
> +#define SPIFC_A1_MAX_HZ2
> +#define SPIFC_A1_MIN_HZ

Re: [PATCH 2/2] bootcount: Add driver model I2C driver

Hi Philip,

On Tue, 17 Oct 2023 at 06:57, Philip Oberfichtner  wrote:
>
> Hi Simon,
>
> maybe you can give me a hint on how to implement this cleanly in driver
> model?
>
> To sum it up, I'd like to have a phandle pointing to *any* I2C device,
> not knowing which UCLASS actually fits. Then the device and the parent
> bus should be probed/prepared such that dm_i2c_read() can be used.
>
> Any ideas on this?

I suggest a phandle to the i2c device.

You can use oftree_get_by_phandle() to get the node and then
device_find_global_by_ofnode() to get the device.

This is expensive, although eventually I suspect we will fix that with
OF_LIVE. I think it should be implemented as a new function in i2c.h
so we can change the impl later easily.

If you want to be more efficient you could do something like:

int phandle = ??

struct uclass *uc;
struct udevice *bus;

uclass_id_foreach_dev(UCLASS_I2C, bus, uc) {
   struct udevice *dev;

   device_foreach_child(dev, bus) {
  if (!dev_read_u32(dev, "phandle", ) && val == phandle)
 return dev;
   }
}

but honestly now I look at it, that is awful. We try to avoid exposing
the internals of phandle because it allows us to (one day) maintain a
list of them.

[..]

Regards,
Simon

Re: [PATCH] bootm: Fix flags used for bootargs string substitution

Hi Piotr,

On Tue, 17 Oct 2023 at 10:35, Tom Rini  wrote:
>
> On Tue, Oct 17, 2023 at 12:53:05PM +0200, Piotr Kubik wrote:
>
> > Commit <51bb33846ad2> introduced a feature of bootargs
>
> Checkpatch will complain that this should be:
> In commit 51bb33846ad2 ("bootm: Support string substitution in
> bootargs")
> And this is the kind of thing I would fixup on applying if there was no
> other feedback.  However:
>
> > string substitution and changed a flag used in
> > bootm_process_cmdline_env() call to be either true or false.
> > With this flag value, condition in bootm_process_cmdline()
> > `if (flags & BOOTM_CL_SUBST)` is never true
> > and process_subst() is never called.
> >
> > Signed-off-by: Piotr Kubik 
> > ---
> >  boot/bootm.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/boot/bootm.c b/boot/bootm.c
> > index 8f96a80d42..e96489e549 100644
> > --- a/boot/bootm.c
> > +++ b/boot/bootm.c
> > @@ -778,7 +778,8 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag, 
> > int argc,
> >   if (!ret && (states & BOOTM_STATE_OS_BD_T))
> >   ret = boot_fn(BOOTM_STATE_OS_BD_T, argc, argv, images);
> >   if (!ret && (states & BOOTM_STATE_OS_PREP)) {
> > - ret = bootm_process_cmdline_env(images->os.os == IH_OS_LINUX);
> > + ret = bootm_process_cmdline_env(images->os.os == IH_OS_LINUX ?
> > +   
> >   BOOTM_CL_ALL : 0);

Oh wow that is a terrible bug. We have lots of test coverage of
bootm_process_cmdline_env() and below, but bootm itself is still quite
spotty.

I wonder if we could add something to run_fit_test to check this. We
have lots of tests for bootm_process_cmdline_env() but not much of
bootm itself. It might be possible to add just a few lines there, e.g.
to set the bootargs to something and check what ends up in bootargs?

>
> This gets hard to read. I would prefer a comment and something like:
> int flags = 0;
> if (images->os.os == IH_OS_LINUX)
>   flags = BOOTM_CL_ALL;
> ret = bootm_process_cmdline_env(flags);
>
> As the compiler should be just as smart, and that'll be clear about
> what's going on.  Thanks.

Regards,
Simon

Re: [PATCH v3 21/32] efi: Rearrange the Kconfig for CMD_BOOTEFI_BOOTMGR

Hi Tom,

On Tue, Oct 17, 2023, 07:13 Tom Rini  wrote:
>
> On Mon, Oct 16, 2023 at 04:28:12PM -0600, Simon Glass wrote:
> > The command should not be used to enable library functionality. Add a
> > new BOOTEFI_BOOTMGR Kconfig for that. Adjust the conditions so that the
> > same code is built.
> >
> > Signed-off-by: Simon Glass 
> > Suggested-by: AKASHI Takahiro 
> [snip]
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 621ed5e5b0fb..13cad6342c36 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -32,15 +32,14 @@ config EFI_LOADER
> >
> >  if EFI_LOADER
> >
> > -config CMD_BOOTEFI_BOOTMGR
> > +config BOOTEFI_BOOTMGR
> >   bool "UEFI Boot Manager"
> > - depends on CMDLINE
>
> This is another example of why I'm asking for re-ordering things so that
> first you clean / re-order things then you make all of CMD depend on
> CMDLINE.  This patch, aside from other feedback, is standalone, if you
> do that.

This patch is before the one that makes all of CMD depend on CMDLINE.

Regards,
Simon

Re: [PATCH v3 22/32] efi: Update EFI_LOADER to depend on DM_ETH

Hi,

On Tue, 17 Oct 2023 at 08:09, Tom Rini  wrote:
>
> On Mon, Oct 16, 2023 at 04:28:13PM -0600, Simon Glass wrote:
>
> > Since efi_device_path.c calls eth_get_dev() and assumes that Ethernet is
> > available, add it as an explicit dependency.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > (no changes since v2)
> >
> > Changes in v2:
> > - Add new patch to update EFI_LOADER to depend on DM_ETH
> >
> >  lib/efi_loader/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 13cad6342c36..fca4b3eef270 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -11,6 +11,7 @@ config EFI_LOADER
> >   # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
> >   depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
> >   depends on BLK
> > + depends on DM_ETH
> >   depends on !EFI_APP
> >   default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
> >   select CHARSET
>
> Does this work for you Heinrich, or do you want to clarify the
> dependencies (and re-organize the code as needed) around networking?

It would be great to tidy up networking in lots of ways...perhaps we
should add ~CMDLINE support to the list of post-lwip tasks if it lands

Regards,
Simon

Re: [PATCH v3 19/32] video: Dont require the font command

Hi Tom,

On Tue, 17 Oct 2023 at 08:07, Tom Rini  wrote:
>
> On Mon, Oct 16, 2023 at 04:28:10PM -0600, Simon Glass wrote:
> > While it is nice to have the font command, using 'select' makes it
> > impossible to build the console code without it. Change this to use
> > 'imply' instead.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > (no changes since v1)
> >
> >  drivers/video/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index ab927641bb7a..21ea5c860cca 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -180,7 +180,7 @@ config CONSOLE_ROTATION
> >
> >  config CONSOLE_TRUETYPE
> >   bool "Support a console that uses TrueType fonts"
> > - select CMD_SELECT_FONT
> > + imply CMD_SELECT_FONT
> >   help
> > TrueTrype fonts can provide outline-drawing capability rather than
> > needing to provide a bitmap for each font and size that is needed.
>
> This is one of those cases where "if CMDLINE" makes sense to add
> somewhere.

Maybe, if you can explain it a bit more. I want boards to be able to
enable or disable this command, independently of whether truetype
fonts are supported. Using 'select' here seems quite inflexible.

Regards,
Simon

Re: [PATCH v3 18/32] video: Allow use without CONFIG_CMDLINE

Hi Tom,

On Tue, 17 Oct 2023 at 08:07, Tom Rini  wrote:
>
> On Mon, Oct 16, 2023 at 04:28:09PM -0600, Simon Glass wrote:
>
> > Provide a fallback for when CONFIG_SYS_CBSIZE is not provided, so that
> > the console can still be used.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > (no changes since v1)
> >
> >  drivers/video/console_truetype.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/video/console_truetype.c 
> > b/drivers/video/console_truetype.c
> > index 14fb81e9563c..e4dad3f9a191 100644
> > --- a/drivers/video/console_truetype.c
> > +++ b/drivers/video/console_truetype.c
> > @@ -125,7 +125,11 @@ struct pos_info {
> >   * Allow one for each character on the command line plus one for each 
> > newline.
> >   * This is just an estimate, but it should not be exceeded.
> >   */
> > +#ifdef CONFIG_SYS_CBSIZE
> >  #define POS_HISTORY_SIZE (CONFIG_SYS_CBSIZE * 11 / 10)
> > +#else
> > +#define POS_HISTORY_SIZE (250 * 11 / 10)
> > +#endif
> >
> >  /**
> >   * struct console_tt_metrics - Information about a font / size combination
>
> NAK, this either should be SYS_PBSIZE (output buffer) instead which you
> move out from under CMDLINE or SYS_CBSIZE (input buffer) should also be
> outside, and both get a help text to explain them a bit better.

I think PBSIZE would be better. Even better (eventually) will be to
drop this truetype buffer if input is not needed.

Regards,
Simon

Re: [PATCH v3 16/32] net: Depend on CONFIG_CMDLINE

Hi Tom,

On Tue, 17 Oct 2023 at 08:04, Tom Rini  wrote:
>
> On Mon, Oct 16, 2023 at 04:28:07PM -0600, Simon Glass wrote:
>
> > At present it isn't possible to use networking without the command line
> > enabled. Add this as a condition.
> >
> > Signed-off-by: Simon Glass 
> > Reviewed-by: Ramon Fried 
> > ---
> >
> > (no changes since v1)
> >
> >  cmd/Kconfig | 1 +
> >  net/Kconfig | 1 +
> >  2 files changed, 2 insertions(+)
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 148414f011df..c6ea5c860e33 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -1694,6 +1694,7 @@ if NET
> >
> >  menuconfig CMD_NET
> >   bool "Network commands"
> > + depends on CMDLINE
> >   default y
> >   imply NETDEVICES
> >
> > diff --git a/net/Kconfig b/net/Kconfig
> > index 4215889127c9..25d494e1db46 100644
> > --- a/net/Kconfig
> > +++ b/net/Kconfig
> > @@ -4,6 +4,7 @@
> >
> >  menuconfig NET
> >   bool "Networking support"
> > + depends on CMDLINE
> >   default y
> >
> >  if NET
>
> Please unwind this in the other direction.  What in network is depending
> on cmdline in a non-trivial way?

I can look at this as a follow-on, but I need a starting point. See my
other comment.

Regards,
Simon

Re: [PATCH v4 4/8] rockchip: block: blk-uclass: disable bounce buffer support for rkmtd

Hi Johan,

On Tue, 17 Oct 2023 at 06:44, Johan Jonker  wrote:
>
>
>
> On 10/16/23 23:54, Simon Glass wrote:
> > Hi Johan,
> >
> > On Sun, 15 Oct 2023 at 16:33, Johan Jonker  wrote:
> >>
> >> Disable bounce buffer support for rkmtd.
> >>
> >> Signed-off-by: Johan Jonker 
> >> Reviewed-by: Kever Yang 
> >> ---
> >>
> >> Changed V3:
> >>   New patch
> >> ---
> >>  drivers/block/blk-uclass.c | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> >> index 30ad5bbb0024..ac1b43d757d8 100644
> >> --- a/drivers/block/blk-uclass.c
> >> +++ b/drivers/block/blk-uclass.c
> >> @@ -415,7 +415,7 @@ struct blk_bounce_buffer {
> >>
> >>  static int blk_buffer_aligned(struct bounce_buffer *state)
> >>  {
> >> -#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
> >> +#if IS_ENABLED(CONFIG_BOUNCE_BUFFER) && !IS_ENABLED(CONFIG_RKMTD)
> >
>
> > We should not have arch-specific code in a generic file. Can you make
> > BOUNCE_BUFFER depend on !RKMTD ?
>
> Hi Simon, Marek,
>
> No that doesn't work that way.
>
> On Rockchip mainline boards MMC_DW is always our boot device BOOT_DEVICE_MMCx.
> Therefore BOUNCE_BUFFER is also standard enabled.
>
> The solution in this patch below is wrong as it assumes that if BOUNCE_BUFFER 
> is enabled it must be used all over the place.
>
> blk: Add bounce buffer support to read/write operations
> https://source.denx.de/u-boot/u-boot/-/commit/75191f75bce45f3b9aff607c88f17778d3805c61
>
> All implementations of bounce_buffer_start and bounce_buffer_start_extalign 
> are located in the individual drivers
>
> https://elixir.bootlin.com/u-boot/latest/C/ident/bounce_buffer_start
> https://elixir.bootlin.com/u-boot/latest/C/ident/bounce_buffer_start_extalign
>
> The use of a bounce_buffer in block devices should only be allowed if needed.
> Lack of "ops->buffer_aligned" does not prevent the creation of a 
> bounce_buffer and is not a good selector yet.
>
> if (ops->buffer_aligned)
> return ops->buffer_aligned(dev, state);
>
> Current blk_ops has no option to communicate the needed resources.
> Please advise how to select the creation of a bounce buffer per device or 
> other solution.

OK, I thought you might say that. So what about a flag in blk_desc
which you can set for this driver, after the block device is created?

[..]

Regards,
Simon

Re: [PATCH v3 14/32] bootm: Allow building when cleanup functions are missing

Hi Tom,

On Tue, 17 Oct 2023 at 08:02, Tom Rini  wrote:
>
> On Mon, Oct 16, 2023 at 04:28:05PM -0600, Simon Glass wrote:
>
> > There are two cleanup functions needed during boot which depend on
> > CMD_BOOTM: bootm_disable_interrupts() and board_quiesce_devices()
> >
> > Provide static inline versions of these for when commands are not
> > enabled.
> >
> > Signed-off-by: Simon Glass 
>
> NAK, these functions need to be available to boot the OS, regardless of
> command line existing or not.  Unwind things in the other direction
> please.

That won't be a successful strategy. See my other reply on this. I
have had this idea since 2016 and have looked at it every now and
then. With bootstd it makes more sense since we actually have a
framework to boot without the command line. This series enables such
work, but cannot include it.

Regards,
Simon

Re: [PATCH v3 12/32] env: Split out non-command code into a new file

Hi Tom,

On Tue, 17 Oct 2023 at 07:40, Tom Rini  wrote:
>
> On Mon, Oct 16, 2023 at 04:28:03PM -0600, Simon Glass wrote:
>
> > It is not possible to set environment variables without having
> > CONFIG_CMD_NVEDIT enabled. When CONFIG_CMDLINE is disabled, we need a
> > way to set variables.
> >
> > Split the setting code out into its own file, so that env_set() is
> > available even when CONFIG_CMDLINE is not. If it is never called, the
> > code will be dropped at link time.
> >
> > Update the Makefile rule to only include the env commands when
> > CONFIG_CMD_NVEDIT is enabled.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > (no changes since v1)
> >
> >  cmd/Makefile   |   2 +-
> >  cmd/nvedit.c   | 122 ++---
> >  env/Makefile   |   1 +
> >  env/env_set.c  | 132 +
> >  include/env_internal.h |  23 +++
> >  5 files changed, 161 insertions(+), 119 deletions(-)
> >  create mode 100644 env/env_set.c
>
> This feels like it's partly but not entirely correct.  We need to split
> cmd/nvedit.c in to cmd/env.c and env/nvedit.c instead I think.  And keep
> in mind that SPL + ENV (and so - CMDLINE I believe) does work today.

OK, fine, but can I do it later? That seems like an excellent
follow-on but is it essential for the purpose of this already-large
series?

Regards,
Simon

Re: [PATCH v3 04/32] cmd: Add a few more dependencies on CMDLINE

Hi Tom,

On Tue, 17 Oct 2023 at 07:32, Tom Rini  wrote:
>
> On Mon, Oct 16, 2023 at 04:27:55PM -0600, Simon Glass wrote:
>
> > Add this to some more commands to avoid build errors with sandbox.
> >
> > Note that this is a temporary solution to expose more problems. A later
> > patch puts these behind an 'if CMDLINE'
> >
> > Signed-off-by: Simon Glass 
>
> We're doing a bunch of churn here that I'd rather just get done at once,
> make the current #27 which guards all commands with if CMDLINE happen
> earlier in the series instead.

Yes I did consider this when reviewing this patch for v3, but got
build-bisect failures. I cannot move #27 earlier, since all the builds
fail. Allowing #27 to pass is the point of this series, in fact.

If we can make progress on the thrust of this series then I will see
if I can somehow reorder some other patches to drop this patch, or
move it later, or cut it down, or something else...

I also don't agree with 'bunch of'. This is 6 lines, which enables
another 20 patches which clean everything up. Are there other patches
with churn?

Regards,
Simon

Re: [PATCH v3 02/32] bootstd: Correct dependencies on CMDLINE

Hi Tom,

On Tue, 17 Oct 2023 at 07:32, Tom Rini  wrote:
>
> On Mon, Oct 16, 2023 at 04:27:53PM -0600, Simon Glass wrote:
>
> > With recent changes over the last few years in boot/Kconfig it is
> > no-longer possible to disable CMDLINE. It results in various link
> > errors because some options which require CMDLINE are enabled
> > regardless of whether it is available.
> >
> > Add the necessary conditions to fix this.
> >
> > Note that it would be better to have all commands depend on CMDLINE,
> > but that is extremely difficult at present, since some functions use
> > CMD_xxx to enable feature xxx. For example networking and environment
> > have a number of problems to tease apart.
> >
> > Signed-off-by: Simon Glass 
>
> Since you later rework things to tease apart most, if not all of this,
> please split out the patches which tease things apart in to their own
> series so that the rest of this becomes reviewable and also reasonable
> looking.

At this point I fear I have lost track of things, since there is just
too much going on. Just in this version I have dealt with:

- some EFI stuff (which needs tweaking)
- teasing apart the CLI handling (which apparently doesn't go far enough?)

Before this version I already looked at environment (which you say
doesn't go far enough, and fair enough, but please review the code as
sent, not what you wish it was).

Perhaps you could apply whatever seems reasonable and then I can take
another look? Or suggest some small changes that would allow progress
to be made.

But do note that supporting booting without CONFIG_CMDLINE is a large
effort, the subject of 5-10 series, perhaps more. It is not my
intention to undertake that in this series, or before this series
lands

The problem, also, is that without this series, it isn't possible to
start that work. With this series, one can look at what code is
missing and find a way to call boot functions (for example) bypassing
the command line. Once you get it booting you are good. Without this
series, you don't even know where to look, since calls to the command
line happen silently.

So I think this series is a big step forward and urge another look, please.

Regards,
Simon

Re: [PATCH] doc: build: update description of build dependencies for Alpine Linux

On Tue, 17 Oct 2023 at 13:47, Milan P. Stanić  wrote:
>
> ---
>  doc/build/gcc.rst | 24 ++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
>

Reviewed-by: Simon Glass

Re: [PATCH 1/1] config: qemu: relax print and console buffer size

On Mon, 16 Oct 2023 at 15:55, Heinrich Schuchardt
 wrote:
>
> QEMU print and console buffer sizes have been restricted on QEMU below
> their default values.
>
> One of the side effects of the print buffer size restriction is output
> truncation of the 'efidebug dh' command.
>
> As QEMU does not have special memory size restrictions remove the settings
> from the defconfig files and go with the generic defaults.
>
> Fixes: d0ee7f295d74 ("Convert CONFIG_SYS_PBSIZE to Kconfig")
> Fixes: d31466b382dd ("Convert CONFIG_SYS_CBSIZE to Kconfig")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  configs/qemu-ppce500_defconfig   | 1 -
>  configs/qemu-riscv32_defconfig   | 2 --
>  configs/qemu-riscv32_smode_defconfig | 2 --
>  configs/qemu-riscv32_spl_defconfig   | 2 --
>  configs/qemu-riscv64_defconfig   | 2 --
>  configs/qemu-riscv64_smode_defconfig | 2 --
>  configs/qemu-riscv64_spl_defconfig   | 2 --
>  configs/qemu-x86_64_defconfig| 1 -
>  configs/qemu-x86_defconfig   | 1 -
>  configs/qemu_arm64_defconfig | 2 --
>  configs/qemu_arm_defconfig   | 2 --
>  11 files changed, 19 deletions(-)

Reviewed-by: Simon Glass

Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event

2023-10-17 Thread Marek Vasut


On 10/18/23 03:22, Minda Chen wrote:



On 2023/10/17 19:20, Marek Vasut wrote:

On 10/17/23 08:20, Minda Chen wrote:

xhci_wait_for_event() waiting TRB_TRANSFER event may return
NULL. Checking the return value to avoid crash.

Signed-off-by: Minda Chen 


How did you trigger this error ? Is there a reproducer ? Details please ...


While Scanning a lenovo usb2.0 udisk， not 100 % reproduce


Can you include Linux

lsusb -vvv

output for this device and include that information in the commit 
message ? (or the U-Boot info below, that works too, just please add it 
into the commit message, it is important for future reference).



This is log.

StarFive # usb reset
resetting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway.
Unexpected XHCI event TRB, skipping... (f77141f0  1300 02008401)
Unhandled exception: Load access fault
EPC: f7f563c6 RA: f7f563c6 TVAL: 000c
EPC: 4024a3c6 RA: 4024a3c6 reloc adjusted


Where does the crash point to in code, can you disassemble the PC 
pointer ? (or maybe you can use scripts/decodecode I think)



SP:  f76f9a60 GP:  f76fbdd0 TP:  0001
T0:  f76fa168 T1:  00ff T2:  0016
S0:  f7712fc0 S1:  f76fb100 A0:  
A1:   A2:  f77145d0 A3:  f7714590
A4:   A5:  0020 A6:  000f
A7:  0100 S2:   S3:  
S4:  f7717050 S5:  f7717050 S6:  8383
S7:  f76f9dc0 S8:  00ff S9:  0001
S10: f76f9ba0 S11: 00010c04 T3:  0010
T4:  0006 T5:  0080 T6:  f76fa231


[...]


3: Mass Storage,  USB Revision 2.0
  - Generic Mass Storage 31097778XB15113405
  - Class: (from Interface) Mass Storage
  - PacketSize: 64  Configurations: 1
  - Vendor: 0x17ef  Product 0x38ac Version 1.0
Configuration: 1
- Interfaces: 1 Bus Powered 200mA
  Interface: 0
  - Alternate Setting 0, Endpoints: 2
  - Class Mass Storage, Transp. SCSI, Bulk only
  - Endpoint 1 Out Bulk MaxPacket 512
  - Endpoint 2 In Bulk MaxPacket 512

StarFive # usb storage
   Device 0: Vendor:  Rev: 8.07 Prod: Lenovo SX1 64G
 Type: Removable Hard Disk
 Capacity: 6.0 MB = 58.5 GB (12288 x 512)


[...]

[PATCH v3] wdt: nuvoton: Fix reset/expire function error

2023-10-17 Thread Jim Liu

Fix npcm845 watchdog halt for reset function and expire function.
Reset function is restart wdt.

Signed-off-by: Jim Liu 

Changes for v3:
   - Modify start sentences
   - Remove empty line
Changes for v2:
   - Add commit message
   - Fix no empty line problem
   - Remove dts
---
 drivers/watchdog/npcm_wdt.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/npcm_wdt.c b/drivers/watchdog/npcm_wdt.c
index e56aa0ebe1..57b61215a2 100644
--- a/drivers/watchdog/npcm_wdt.c
+++ b/drivers/watchdog/npcm_wdt.c
@@ -69,15 +69,21 @@ static int npcm_wdt_stop(struct udevice *dev)
 static int npcm_wdt_reset(struct udevice *dev)
 {
struct npcm_wdt_priv *priv = dev_get_priv(dev);
+   u32 val;
 
-   writel(NPCM_WTR | NPCM_WTRE | NPCM_WTE, priv->regs);
+   val = readl(priv->regs);
+   writel(val | NPCM_WTR, priv->regs);
 
return 0;
 }
 
 static int npcm_wdt_expire_now(struct udevice *dev, ulong flags)
 {
-   return npcm_wdt_reset(dev);
+   struct npcm_wdt_priv *priv = dev_get_priv(dev);
+
+   writel(NPCM_WTR | NPCM_WTRE | NPCM_WTE, priv->regs);
+
+   return 0;
 }
 
 static int npcm_wdt_of_to_plat(struct udevice *dev)
-- 
2.25.1

Re: [PATCH 3/5] smbios: Use SMBIOS 3.0 to support an address above 4GB

2023-10-17 Thread Caleb Connolly

Hi Both,

[...]
>>>
>>> @@ -513,13 +517,23 @@ ulong write_smbios_table(ulong addr)
>>>*/
>>>   table_addr = (ulong)map_sysmem(tables, 0);
>>>   if (sizeof(table_addr) > sizeof(u32) && table_addr > (ulong)UINT_MAX) 
>>> {
>>
>> You have to check the end address of the table not the start address here.
>>
>> The SMBIOS specification says that you should always supply a 32bit
>> SMBIOS entry point. Of course this is not possible on boards that don't
>> have low memory.
>>
>> In install_smbios_table() this can be achieved by calling
>> efi_allocate_pages() with EFI_MAX_ALLOCATE_TYPE and a maximum address of
>> 4 GiB - 1. Only if this fails use high memory.
> 
> Hmm perhaps we need a way to allocate memory below 4GB in U-Boot? How
> does this EFI function work?

Yes, prior to 53fab13a7b11 ("efi: Use the installed SMBIOS tables")
efi_allocate_pages() was called directly from efi_smbios_register(). My
boards all malloc() memory above the 4GB boundary and I just recently
rebased and hit a regression caused by this.

In my testing, calling efi_allocate_pages() from install_smbios_table()
did work, but I figure that's probably not intended behaviour...

I can confirm that this series does allow my boards to boot again, but
dmidecode is unable to decode the SMBIOS 3.0 table (even with
STRICT_DEVMEM disabled fwiw).

Below is EFI and board memory map info after applying this patch series.

=> efidebug tables
Cannot read EFI system partition
Cannot read EFI system partition
Failed to persist EFI variables
00017ea22040  32313633-3532-3634-2d66-3765662d3463  EFI Conformance
Profiles Table
00017ea21040  36366265-3139-6138-2d37-6565662d3430  Runtime properties
00017fb13000  64663266-3531-3434-2d39-3739342d3461  (unknown)
=> efidebug memmap
Type StartEnd  Attributes
   ==
CONVENTIONAL 8000-00017ea1f000 WB
BOOT DATA00017ea1f000-00017ea21000 WB
RUNTIME DATA 00017ea21000-00017ea22000 WB|RT
BOOT DATA00017ea22000-00017ea23000 WB
RUNTIME DATA 00017ea23000-00017ea25000 WB|RT
BOOT DATA00017ea25000-00017ea26000 WB
RUNTIME DATA 00017ea26000-00017ea36000 WB|RT
BOOT DATA00017ea36000-00017eaef000 WB
BOOT CODE00017eaef000-00017fb13000 WB
RUNTIME DATA 00017fb13000-00017fb14000 WB|RT
BOOT CODE00017fb14000-00017ff2 WB
RUNTIME CODE 00017ff2-00017ff3 WB|RT
BOOT CODE00017ff3-00018000 WB
BOOT DATA00018000-00027c7a WB
=> bdinfo
boot_params = 0x
DRAM bank   = 0x
-> start= 0x8000
-> size = 0x0001
DRAM bank   = 0x0001
-> start= 0x00018000
-> size = 0xfc7a
flashstart  = 0x
flashsize   = 0x
flashoffset = 0x
baudrate= 115200 bps
relocaddr   = 0x00017ff26000
reloc off   = 0x00017ff26000
Build   = 64-bit
fdt_blob= 0x00017faef6c0
new_fdt = 0x00017faef6c0
fdt_size= 0x00017680
Video   = framebuffer@9D40 active
FB base = 0x9d40
FB size = 1080x2160x32
lmb_dump_all:
 memory.cnt = 0x1 / max = 0x40
 memory[0]  [0x8000-0x27c79], 0x1fc7a bytes flags: 0
 reserved.cnt = 0x7 / max = 0x40
 reserved[0][0x8570-0x85cf], 0x0060 bytes flags: 4
 reserved[1][0x85e0-0x85ef], 0x0010 bytes flags: 4
 reserved[2][0x85fc-0x890f], 0x0314 bytes flags: 4
 reserved[3][0x8ab0-0x8c416fff], 0x01917000 bytes flags: 4
 reserved[4][0x8c50-0x97bf], 0x0b70 bytes flags: 4
 reserved[5][0x9d40-0x9f7f], 0x0240 bytes flags: 4
 reserved[6][0x17ea1f000-0x27c79], 0xfdd81000 bytes flags: 0
devicetree  = board
arch_number = 0x
TLB addr= 0x00017fff
irq_sp  = 0x00017faef6b0
sp start= 0x00017faef6b0
Early malloc usage: a78 / 2000
> 
> I don't think EFI has been set up by the time this function is called.
> 
> Regards,
> Simon

-- 
// Caleb (they/them)

[PATCH v2 2/2] board: rockchip: add Pine64 QuartzPro64 RK3588 board

2023-10-17 Thread Tom Fitzhenry

QuartzPro64 is a Rockchip RK3588 based SBC by Pine64.

UART and boot over SD/eMMC/RJ45 are tested to work.

Linux commits from next-20231013:
8152d3d070a9 ("arm64: dts: rockchip: Add QuartzPro64 SBC device tree")

Signed-off-by: Tom Fitzhenry 
Cc: Eugen Hristev 
Cc: Jonas Karlman 
Cc: Ondrej Jirman 
---

This patch depends on "rockchip: rk3588: Sync device tree from linux
maintainer tree"[0], since the QuartzPro64 upstream DT depends on upstream
dtsi changes.

0. https://lore.kernel.org/all/20231010222344.3436526-2-jo...@kwiboo.se
---
 arch/arm/dts/Makefile |1 +
 arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi   |   12 +
 arch/arm/dts/rk3588-quartzpro64.dts   | 1137 +
 arch/arm/mach-rockchip/rk3588/Kconfig |8 +
 board/pine64/quartzpro64-rk3588/Kconfig   |   15 +
 board/pine64/quartzpro64-rk3588/MAINTAINERS   |8 +
 board/pine64/quartzpro64-rk3588/Makefile  |3 +
 .../quartzpro64-rk3588/quartzpro64-rk3588.c   |   39 +
 configs/quartzpro64-rk3588_defconfig  |   72 ++
 doc/board/rockchip/rockchip.rst   |1 +
 include/configs/quartzpro64-rk3588.h  |   14 +
 11 files changed, 1310 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588-quartzpro64.dts
 create mode 100644 board/pine64/quartzpro64-rk3588/Kconfig
 create mode 100644 board/pine64/quartzpro64-rk3588/MAINTAINERS
 create mode 100644 board/pine64/quartzpro64-rk3588/Makefile
 create mode 100644 board/pine64/quartzpro64-rk3588/quartzpro64-rk3588.c
 create mode 100644 configs/quartzpro64-rk3588_defconfig
 create mode 100644 include/configs/quartzpro64-rk3588.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 4569483d5fd..6d1e33d9e2e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -191,6 +191,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
+   rk3588-quartzpro64.dtb \
rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
 
diff --git a/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi 
b/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
new file mode 100644
index 000..191ec988c45
--- /dev/null
+++ b/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2023 Google, Inc
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
diff --git a/arch/arm/dts/rk3588-quartzpro64.dts 
b/arch/arm/dts/rk3588-quartzpro64.dts
new file mode 100644
index 000..5c59f9571dc
--- /dev/null
+++ b/arch/arm/dts/rk3588-quartzpro64.dts
@@ -0,0 +1,1137 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Ondřej Jirman 
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rk3588.dtsi"
+
+/ {
+   model = "PINE64 QuartzPro64";
+   compatible = "pine64,quartzpro64", "rockchip,rk3588";
+
+   aliases {
+   mmc0 = 
+   mmc1 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   adc-keys-0 {
+   compatible = "adc-keys";
+   io-channels = < 0>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <100>;
+
+   button-maskrom {
+   label = "Mask Rom";
+   linux,code = ;
+   press-threshold-microvolt = <393>;
+   };
+   };
+
+   adc-keys-1 {
+   compatible = "adc-keys";
+   io-channels = < 1>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <100>;
+
+   button-volume-up {
+   label = "V+/REC";
+   linux,code = ;
+   press-threshold-microvolt = <17821>;
+   };
+
+   button-volume-down {
+   label = "V-";
+   linux,code = ;
+   press-threshold-microvolt = <415384>;
+   };
+
+   button-menu {
+   label = "MENU";
+   linux,code = ;
+   press-threshold-microvolt = <890909>;
+   };
+
+   button-esc {
+   label = "ESC";
+   linux,code = ;
+   press-threshold-microvolt = <1233962>;
+   };
+   };
+
+   headphone_amp: audio-amplifier-headphone {
+   compatible = "simple-audio-amplifier";
+   enable-gpios = < RK_PD2 GPIO_ACTIVE_HIGH>;
+   sound-name-prefix = "Headphones Amp";
+   };
+
+   speaker_amp:

[PATCH v2 1/2] dt-bindings: leds: import common led bindings from linux v6.5

2023-10-17 Thread Tom Fitzhenry

This brings in more colours, e.g. ORANGE needed for the QuartzPro64 DT.

Linux commits:
472d7b9e8141 ("dt-bindings: leds: Expand LED_COLOR_ID definitions")

Signed-off-by: Tom Fitzhenry 
---
 include/dt-bindings/leds/common.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/dt-bindings/leds/common.h 
b/include/dt-bindings/leds/common.h
index 3be89a7c20a..9a0d33d027f 100644
--- a/include/dt-bindings/leds/common.h
+++ b/include/dt-bindings/leds/common.h
@@ -33,7 +33,12 @@
 #define LED_COLOR_ID_MULTI 8   /* For multicolor LEDs */
 #define LED_COLOR_ID_RGB   9   /* For multicolor LEDs that can do 
arbitrary color,
   so this would include RGBW and 
similar */
-#define LED_COLOR_ID_MAX   10
+#define LED_COLOR_ID_PURPLE10
+#define LED_COLOR_ID_ORANGE11
+#define LED_COLOR_ID_PINK  12
+#define LED_COLOR_ID_CYAN  13
+#define LED_COLOR_ID_LIME  14
+#define LED_COLOR_ID_MAX   15
 
 /* Standard LED functions */
 /* Keyboard LEDs, usually it would be input4::capslock etc. */
-- 
2.42.0

PXE booting Flatcar OS on NXP ARMv8 SoCs with Chassis generation 3.2 LX2160A: fsl-mc: DPL not deployed, DPAA2 ethernet not work

2023-10-17 Thread Adrian Vladu

Hello,

While trying to PXE boot Flatcar OS on NXP ARMv8 SoCs with Chassis generation 
3.2 LX2160A 
(https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3_2),
there is an issue with the DPAA2, error logs seen:

>> Moving Image from 0x8110 to 0x8120, end=8474
>> ## Flattened Device Tree blob at 8100
>>   Booting using the fdt blob at 0x8100
>>   Loading Device Tree to 9fff2000, end 9fb6 ... OK
>> Releasing fan controller full speed gpio
>> fsl-mc: DPL not deployed, DPAA2 ethernet not work

This issue " fsl-mc: DPL not deployed, DPAA2 ethernet not work " -- is it 
related to the Flatcar kernel not having the drivers for DPAA2 or is the device 
tree blob or maybe initrd is too large?
With the same DTB, PXE booting Ubuntu 20.04 works well.

On important note here, the Flatcar initrd and kernel are ~300MB, respectively 
~50MB for the kernel. Can it be an issue with the initrd size?

Thank you,
Adrian

Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event

2023-10-17 Thread Minda Chen




On 2023/10/17 19:20, Marek Vasut wrote:
> On 10/17/23 08:20, Minda Chen wrote:
>> xhci_wait_for_event() waiting TRB_TRANSFER event may return
>> NULL. Checking the return value to avoid crash.
>>
>> Signed-off-by: Minda Chen 
> 
> How did you trigger this error ? Is there a reproducer ? Details please ...

While Scanning a lenovo usb2.0 udisk， not 100 % reproduce

This is log.

StarFive # usb reset
resetting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway.
Unexpected XHCI event TRB, skipping... (f77141f0  1300 02008401)
Unhandled exception: Load access fault
EPC: f7f563c6 RA: f7f563c6 TVAL: 000c
EPC: 4024a3c6 RA: 4024a3c6 reloc adjusted

SP:  f76f9a60 GP:  f76fbdd0 TP:  0001
T0:  f76fa168 T1:  00ff T2:  0016
S0:  f7712fc0 S1:  f76fb100 A0:  
A1:   A2:  f77145d0 A3:  f7714590
A4:   A5:  0020 A6:  000f
A7:  0100 S2:   S3:  
S4:  f7717050 S5:  f7717050 S6:  8383
S7:  f76f9dc0 S8:  00ff S9:  0001
S10: f76f9ba0 S11: 00010c04 T3:  0010
T4:  0006 T5:  0080 T6:  f76fa231

Code: 842a f0ef d75f 0593 0200 8522 f0ef ebdf (455c) 


This is USB info and storage info 

StarFive # 
1: Hub,  USB Revision 3.0
 - U-Boot XHCI Host Controller 
 - Class: Hub
 - PacketSize: 512  Configurations: 1
 - Vendor: 0x  Product 0x Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Hub,  USB Revision 2.10
 -  USB2.0 Hub 
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x2109  Product 0x3431 Version 4.32
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 100mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

3: Mass Storage,  USB Revision 2.0
 - Generic Mass Storage 31097778XB15113405
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x17ef  Product 0x38ac Version 1.0
   Configuration: 1
   - Interfaces: 1 Bus Powered 200mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 2
 - Class Mass Storage, Transp. SCSI, Bulk only
 - Endpoint 1 Out Bulk MaxPacket 512
 - Endpoint 2 In Bulk MaxPacket 512

StarFive # usb storage
  Device 0: Vendor:  Rev: 8.07 Prod: Lenovo SX1 64G  
Type: Removable Hard Disk
Capacity: 6.0 MB = 58.5 GB (12288 x 512)
StarFive #

Re: [PATCH v7 5/9] efi_loader: support boot from URI device path


On 16.10.23 08:45, Masahisa Kojima wrote:

This supports to boot from the URI device path.
When user selects the URI device path, bootmgr downloads
the file using wget into the address specified by loadaddr
env variable.
If the file is .iso or .img file, mount the image with blkmap
then try to boot with the default file(e.g. EFI/BOOT/BOOTAA64.EFI).
Since boot option indicating the default file is automatically
created when new disk is detected, system can boot by selecting
the automatically created blkmap boot option.
If the file is PE-COFF file, load and start the downloaded file.

The buffer used to download the ISO image file must be
reserved to avoid the unintended access to the image.
For PE-COFF file case, this memory reservation is done
in LoadImage Boot Service.

Signed-off-by: Masahisa Kojima 
---
  include/efi_loader.h  |   2 +
  lib/efi_loader/Kconfig|   9 ++
  lib/efi_loader/efi_bootmgr.c  | 198 ++
  lib/efi_loader/efi_dt_fixup.c |   2 +-
  4 files changed, 210 insertions(+), 1 deletion(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index e24410505f..106006127b 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -554,6 +554,8 @@ void efi_runtime_detach(void);
  /* efi_convert_pointer() - convert pointer to virtual address */
  efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t debug_disposition,
void **address);
+/* add reserved memory to memory map */
+void efi_reserve_memory(u64 addr, u64 size, bool nomap);
  /* Carve out DT reserved memory ranges */
  void efi_carve_out_dt_rsv(void *fdt);
  /* Purge unused kaslr-seed */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index d20aaab6db..5d99206dc3 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -479,4 +479,13 @@ config EFI_RISCV_BOOT_PROTOCOL
  replace the transfer via the device-tree. The latter is not
  possible on systems using ACPI.

+config EFI_HTTP_BOOT
+   bool "EFI HTTP Boot support"
+   depends on CMD_DNS
+   depends on CMD_WGET
+   depends on BLKMAP
+   help
+ Enabling this option adds EFI HTTP Boot support. It allows to
+ directly boot from network.
+
  endif
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index c8cf1c5506..c90b68f783 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -7,10 +7,14 @@

  #define LOG_CATEGORY LOGC_EFI

+#include 
+#include 
  #include 
  #include 
+#include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -168,6 +172,192 @@ out:
return ret;
  }

+/**
+ * mount_image() - mount the image with blkmap
+ *
+ * @lo_label:  u16 label string of load option
+ * @image_addr:image address
+ * @image_size:image size
+ * Return: pointer to the UCLASS_BLK udevice, NULL if failed
+ */
+static struct udevice *mount_image(u16 *lo_label, ulong image_addr, int 
image_size)
+{
+   int err;
+   struct blkmap *bm;
+   struct udevice *bm_dev;
+   char *label = NULL, *p;
+
+   label = efi_alloc(utf16_utf8_strlen(lo_label) + 1);
+   if (!label)
+   return NULL;
+
+   p = label;
+   utf16_utf8_strcpy(, lo_label);
+   err = blkmap_create_ramdisk(label, image_addr, image_size, _dev);
+   if (err) {
+   efi_free_pool(label);
+   return NULL;
+   }
+   bm = dev_get_plat(bm_dev);
+
+   efi_free_pool(label);
+
+   return bm->blk;
+}
+
+/**
+ * load_mounted_image() - load mounted image with default file
+ *
+ * @devnum:target blkmap device
+ * @handle:pointer to handle for newly installed image
+ * Return: status code
+ */
+static efi_status_t load_mounted_image(int devnum, efi_handle_t *handle)
+{
+   u32 i;
+   u16 *bm_label, *p;
+   char device_name[12];
+   u16 *bootorder = NULL;
+   efi_uintn_t num, size;
+   void *load_option = NULL;
+   struct efi_load_option lo;
+   u16 varname[] = u"Boot";
+   efi_status_t ret = EFI_NOT_FOUND;
+
+   snprintf(device_name, 12, "blkmap %d", devnum);
+   bm_label = calloc(1, (strlen(device_name) + 1) * sizeof(u16));
+   if (!bm_label)
+   return EFI_OUT_OF_RESOURCES;
+
+   p = bm_label;
+   utf8_utf16_strcpy(, device_name);
+
+   bootorder = efi_get_var(u"BootOrder", _global_variable_guid, );
+   if (!bootorder)
+   goto out;
+
+   num = size / sizeof(u16);
+   for (i = 0; i < num; i++) {
+   efi_create_indexed_name(varname, sizeof(varname), "Boot",
+   bootorder[i]);
+   load_option = efi_get_var(varname, _global_variable_guid, 
);
+   if (!load_option)
+   continue;
+
+   ret = efi_deserialize_load_option(, load_option, );
+   if (ret != EFI_SUCCESS) {
+

Re: [PATCH 1/1] efi_loader: expose the device-tree file name

On 17.10.23 17:17, Mark Kettenis wrote:

From: Heinrich Schuchardt 
Date: Tue, 17 Oct 2023 10:55:07 +0200

Forward and backward compatibility of Linux kernel device-trees is
sometimes missing. One solution approach is to load a kernel specific
device-tree. This can either be done via a U-Boot scripts (like the one
generated by Debian package flash-kernel or by a boot loader like GRUB.
The boot loader approach currently requires to know the device-tree name
before first boot which makes it unusable for generic images.

Even if the device trees are compatible, we often see that additonal
nodes get added at a later stage.  So the ability to load a more
complete device tree for the OS is useful and means a user doesn't
necessarily need to update U-Boot to make additional devices work in
their OS.

OpenBSD should call the EFI_DT_FIXUP_PROTOCOL exposed by U-Boot after 
loading device-trees.

https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL

Expose the device-tree file name as EFI variable FdtFile.
This will allow bootloaders to load a kernel specific device-tree.

Right.  I'm considering adding support for loading device trees to the
OpenBSD bootloader and this feature would be really useful since it
would allow me to automagically load the right device tree from the
root filesystem of the OS.

Is my understanding right that this is a null-terminated (8-bit) ASCII
string?  Can this variable be documented somewhere, maybe together
with the EFI_DT_FIXUP_PROTOCOL?

Yes, the string is NUL terminated ASCII. The best place for 
documentation would be the EBBR specification.

Best regards

Heinrich

Signed-off-by: Heinrich Schuchardt 
---
  lib/efi_loader/efi_setup.c | 26 ++
  1 file changed, 26 insertions(+)

diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index e6de685e87..b24feb94dc 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -26,6 +26,27 @@ void __weak allow_unaligned(void)
  {
  }

+/**

+ * efi_init_fdtfile() - set EFI variable FdtFile
+ *
+ * Return: status code
+ */
+static efi_status_t efi_init_fdtfile(void)
+{
+   char *val;
+
+   val = env_get("fdtfile");
+   if (!val)
+   return EFI_SUCCESS;
+
+   return efi_set_variable_int(u"FdtFile",
+   _u_boot_guid,
+   EFI_VARIABLE_BOOTSERVICE_ACCESS |
+   EFI_VARIABLE_RUNTIME_ACCESS |
+   EFI_VARIABLE_READ_ONLY,
+   strlen(val) + 1, val, false);
+}
+
  /**
   * efi_init_platform_lang() - define supported languages
   *
@@ -250,6 +271,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;

+	/* Define EFI variable FdtFile */

+   ret = efi_init_fdtfile();
+   if (ret != EFI_SUCCESS)
+   goto out;
+
/* Indicate supported features */
ret = efi_init_os_indications();
if (ret != EFI_SUCCESS)
--
2.40.1

[PATCH 1/3] mtd: spi-nor: Add support for XMC XM25QU128C

From: Ricardo Pardini 

Add support for XMC XM25QU128C (128M-bit) Serial Flash memory. Used on
the Xunlong Orange Pi 3B, 5 and 5 Plus boards.

Datasheet:
https://www.xmcwh.com/uploads/806/XM25QU128C_Ver2.0.pdf

Signed-off-by: Ricardo Pardini 
[jo...@kwiboo.se: update commit message]
Signed-off-by: Jonas Karlman 
---
 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 5c35171ffd55..392db5c99e84 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -536,6 +536,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("XM25QH64A", 0x207017, 0, 64 * 1024, 128, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("XM25QH64C", 0x204017, 0, 64 * 1024, 128, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("XM25QH128A", 0x207018, 0, 64 * 1024, 256, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+   { INFO("XM25QU128C", 0x204118, 0, 64 * 1024, 256, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
 #endif
 #ifdef CONFIG_SPI_FLASH_XTX
/* XTX Technology Limited */
-- 
2.42.0

[PATCH 3/3] board: rockchip: Add Xunlong Orange Pi 5 Plus

Xunlong Orange Pi 5 Plus is a single-board computer based on the
Rockchip RK3588 SoC. The board provides abundant interfaces, including
two HDMI output ports, one HDMI input port, two 2.5G Ethernet ports,
M.2 M-Key slot, M.2 E-Key slot, two USB 3.0, two USB 2.0, and two Type-C.

Features tested on a Orange Pi 5 Plus 4GB v1.2:
- SD-card boot
- eMMC boot
- SPI Flash boot
- PCIe/NVMe
- USB 2.0 host
- Ethernet

Device tree is imported from linux v6.7-rockchip-dts64-1 tag.

Signed-off-by: Jonas Karlman 
---
Cc: Ondrej Jirman 
---
 arch/arm/dts/Makefile |   1 +
 .../dts/rk3588-orangepi-5-plus-u-boot.dtsi|  27 +
 arch/arm/dts/rk3588-orangepi-5-plus.dts   | 848 ++
 board/rockchip/evb_rk3588/MAINTAINERS |   7 +
 configs/orangepi-5-plus-rk3588_defconfig  | 105 +++
 doc/board/rockchip/rockchip.rst   |   1 +
 6 files changed, 989 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-orangepi-5-plus-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588-orangepi-5-plus.dts
 create mode 100644 configs/orangepi-5-plus-rk3588_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index fd99bb76fa6b..c1a760592df5 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -193,6 +193,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-evb1-v10.dtb \
rk3588-nanopc-t6.dtb \
rk3588s-orangepi-5.dtb \
+   rk3588-orangepi-5-plus.dtb \
rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
 
diff --git a/arch/arm/dts/rk3588-orangepi-5-plus-u-boot.dtsi 
b/arch/arm/dts/rk3588-orangepi-5-plus-u-boot.dtsi
new file mode 100644
index ..b0f5c667197c
--- /dev/null
+++ b/arch/arm/dts/rk3588-orangepi-5-plus-u-boot.dtsi
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+_pins {
+   bootph-all;
+};
+
+ {
+   cap-mmc-highspeed;
+   mmc-hs200-1_8v;
+};
+
+ {
+   bootph-pre-ram;
+   u-boot,spl-sfc-no-dma;
+
+   flash@0 {
+   bootph-pre-ram;
+   };
+};
diff --git a/arch/arm/dts/rk3588-orangepi-5-plus.dts 
b/arch/arm/dts/rk3588-orangepi-5-plus.dts
new file mode 100644
index ..298c183d6f4f
--- /dev/null
+++ b/arch/arm/dts/rk3588-orangepi-5-plus.dts
@@ -0,0 +1,848 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Ondřej Jirman 
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rk3588.dtsi"
+
+/ {
+   model = "Xunlong Orange Pi 5 Plus";
+   compatible = "xunlong,orangepi-5-plus", "rockchip,rk3588";
+
+   aliases {
+   mmc0 = 
+   mmc1 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   adc-keys-0 {
+   compatible = "adc-keys";
+   io-channels = < 0>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <100>;
+
+   button-maskrom {
+   label = "Mask Rom";
+   linux,code = ;
+   press-threshold-microvolt = <2000>;
+   };
+   };
+
+   adc-keys-1 {
+   compatible = "adc-keys";
+   io-channels = < 1>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <100>;
+
+   button-recovery {
+   label = "Recovery";
+   linux,code = ;
+   press-threshold-microvolt = <2000>;
+   };
+   };
+
+   speaker_amp: speaker-audio-amplifier {
+   compatible = "simple-audio-amplifier";
+   enable-gpios = < RK_PC0 GPIO_ACTIVE_HIGH>;
+   sound-name-prefix = "Speaker Amp";
+   };
+
+   headphone_amp: headphones-audio-amplifier {
+   compatible = "simple-audio-amplifier";
+   enable-gpios = < RK_PA7 GPIO_ACTIVE_HIGH>;
+   sound-name-prefix = "Headphones Amp";
+   };
+
+   ir-receiver {
+   compatible = "gpio-ir-receiver";
+   gpios = < RK_PB3 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_receiver_pin>;
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_led_pin>;
+
+   led {
+   color = ;
+   function = LED_FUNCTION_INDICATOR;
+   function-enumerator = <1>;
+   gpios = < RK_PA6 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   fan: pwm-fan {
+   compatible = "pwm-fan";
+   cooling-levels = <0 70 75 80 100>;
+

[PATCH 2/3] board: rockchip: Add Xunlong Orange Pi 5

Xunlong Orange Pi 5 is a single-board computer based on the Rockchip
RK3588S SoC. The board provides abundant interfaces, HDMI output, GPIO
interface, M.2 PCIe2.0, Type-C, Gigabit LAN port, 2*USB2.0, 1*USB3.0,
etc.

Features tested on a Orange Pi 5 4GB v1.2:
- SD-card boot
- SPI Flash boot
- PCIe/NVMe
- USB 2.0 host
- Ethernet

Device tree is imported from linux v6.7-rockchip-dts64-1 tag.

Signed-off-by: Jonas Karlman 
---
Cc: Muhammed Efe Cetin 
---
 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi |  22 +
 arch/arm/dts/rk3588s-orangepi-5.dts | 662 
 board/rockchip/evb_rk3588/MAINTAINERS   |   7 +
 configs/orangepi-5-rk3588s_defconfig| 102 +++
 doc/board/rockchip/rockchip.rst |   1 +
 6 files changed, 795 insertions(+)
 create mode 100644 arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588s-orangepi-5.dts
 create mode 100644 configs/orangepi-5-rk3588s_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 490709359553..fd99bb76fa6b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -192,6 +192,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
rk3588-nanopc-t6.dtb \
+   rk3588s-orangepi-5.dtb \
rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
 
diff --git a/arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi 
b/arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi
new file mode 100644
index ..888d1b9c12d7
--- /dev/null
+++ b/arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588s-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", 
+   };
+};
+
+_pins {
+   bootph-all;
+};
+
+ {
+   bootph-pre-ram;
+   u-boot,spl-sfc-no-dma;
+
+   flash@0 {
+   bootph-pre-ram;
+   };
+};
diff --git a/arch/arm/dts/rk3588s-orangepi-5.dts 
b/arch/arm/dts/rk3588s-orangepi-5.dts
new file mode 100644
index ..8f399c4317bd
--- /dev/null
+++ b/arch/arm/dts/rk3588s-orangepi-5.dts
@@ -0,0 +1,662 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include 
+#include "rk3588s.dtsi"
+
+/ {
+   model = "Xunlong Orange Pi 5";
+   compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
+
+   aliases {
+   mmc0 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = < 1>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <100>;
+
+   button-recovery {
+   label = "Recovery";
+   linux,code = ;
+   press-threshold-microvolt = <1800>;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 =<_gpio>;
+
+   led-1 {
+   gpios = < RK_PA2 GPIO_ACTIVE_HIGH>;
+   label = "status_led";
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   vbus_typec: vbus-typec-regulator {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < RK_PC0 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwren>;
+   regulator-name = "vbus_typec";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_sys>;
+   };
+
+   vcc5v0_sys: vcc5v0-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   vcc_3v3_sd_s0: vcc-3v3-sd-s0-regulator {
+   compatible = "regulator-fixed";
+   enable-active-low;
+   gpios = < RK_PB5 GPIO_ACTIVE_LOW>;
+   regulator-name = "vcc_3v3_sd_s0";
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_3v3_s3>;
+   };
+
+   vcc3v3_pcie20: vcc3v3-pcie20-regulator {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpios = < RK_PC5 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc3v3_pcie20";
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt =

[PATCH 0/3] rockchip: Add Xunlong Orange Pi 5 and 5 Plus boards

This series add support for Xunlong Orange Pi 5 and 5 Plus boards.

First patch add support for the SPI NOR Flash used on the two boards.
Second patch add support for the Xunlong Orange Pi 5 RK3588S board.
Third patch add support for the Xunlong Orange Pi 5 Plus RK3588 board.

This series depends on the following series for a clean apply:
- rockchip: rk3588: Sync pcie and usb3 nodes from linux [1]
- board: rockchip: add FriendlyElec NanoPC-T6 rk3588 board [2]

[1] https://patchwork.ozlabs.org/cover/1850311/
[2] https://patchwork.ozlabs.org/patch/1847842/

Jonas Karlman (2):
  board: rockchip: Add Xunlong Orange Pi 5
  board: rockchip: Add Xunlong Orange Pi 5 Plus

Ricardo Pardini (1):
  mtd: spi-nor: Add support for XMC XM25QU128C

 arch/arm/dts/Makefile |   2 +
 .../dts/rk3588-orangepi-5-plus-u-boot.dtsi|  27 +
 arch/arm/dts/rk3588-orangepi-5-plus.dts   | 848 ++
 arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi   |  22 +
 arch/arm/dts/rk3588s-orangepi-5.dts   | 662 ++
 board/rockchip/evb_rk3588/MAINTAINERS |  14 +
 configs/orangepi-5-plus-rk3588_defconfig  | 105 +++
 configs/orangepi-5-rk3588s_defconfig  | 102 +++
 doc/board/rockchip/rockchip.rst   |   2 +
 drivers/mtd/spi/spi-nor-ids.c |   1 +
 10 files changed, 1785 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-orangepi-5-plus-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588-orangepi-5-plus.dts
 create mode 100644 arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588s-orangepi-5.dts
 create mode 100644 configs/orangepi-5-plus-rk3588_defconfig
 create mode 100644 configs/orangepi-5-rk3588s_defconfig

-- 
2.42.0

[PATCH v1 2/2] arm: meson-a1: dts: Sync DT with Linux

Import device tree changes from Linux v6.6-rc6 for Amlogic A1 board.

Signed-off-by: Igor Prusov 
---
 arch/arm/dts/meson-a1.dtsi | 356 -
 1 file changed, 351 insertions(+), 5 deletions(-)

diff --git a/arch/arm/dts/meson-a1.dtsi b/arch/arm/dts/meson-a1.dtsi
index e3a42c5b24..648e7f4942 100644
--- a/arch/arm/dts/meson-a1.dtsi
+++ b/arch/arm/dts/meson-a1.dtsi
@@ -3,9 +3,13 @@
  * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
  */
 
-#include 
-#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 / {
compatible = "amlogic,a1";
@@ -37,9 +41,19 @@
l2: l2-cache0 {
compatible = "cache";
cache-level = <2>;
+   cache-unified;
};
};
 
+   efuse: efuse {
+   compatible = "amlogic,meson-gxbb-efuse";
+   clocks = <_periphs CLKID_OTP>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   secure-monitor = <>;
+   power-domains = < PWRC_OTP_ID>;
+   };
+
psci {
compatible = "arm,psci-1.0";
method = "smc";
@@ -65,7 +79,6 @@
pwrc: power-controller {
compatible = "amlogic,meson-a1-pwrc";
#power-domain-cells = <1>;
-   status = "okay";
};
};
 
@@ -75,6 +88,16 @@
#size-cells = <2>;
ranges;
 
+   spifc: spi@fd000400 {
+   compatible = "amlogic,a1-spifc";
+   reg = <0x0 0xfd000400 0x0 0x290>;
+   clocks = <_periphs CLKID_SPIFC>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   power-domains = < PWRC_SPIFC_ID>;
+   status = "disabled";
+   };
+
apb: bus@fe00 {
compatible = "simple-bus";
reg = <0x0 0xfe00 0x0 0x100>;
@@ -103,10 +126,200 @@
gpio-ranges = <_pinctrl 0 0 62>;
};
 
+   i2c0_f11_pins: i2c0-f11 {
+   mux {
+   groups = "i2c0_sck_f11",
+"i2c0_sda_f12";
+   function = "i2c0";
+   bias-pull-up;
+   drive-strength-microamp = 
<3000>;
+   };
+   };
+
+   i2c0_f9_pins: i2c0-f9 {
+   mux {
+   groups = "i2c0_sck_f9",
+"i2c0_sda_f10";
+   function = "i2c0";
+   bias-pull-up;
+   drive-strength-microamp = 
<3000>;
+   };
+   };
+
+   i2c1_x_pins: i2c1-x {
+   mux {
+   groups = "i2c1_sck_x",
+"i2c1_sda_x";
+   function = "i2c1";
+   bias-pull-up;
+   drive-strength-microamp = 
<3000>;
+   };
+   };
+
+   i2c1_a_pins: i2c1-a {
+   mux {
+   groups = "i2c1_sck_a",
+"i2c1_sda_a";
+   function = "i2c1";
+   bias-pull-up;
+   drive-strength-microamp = 
<3000>;
+   };
+   };
+
+   i2c2_x0_pins: i2c2-x0 {
+   mux {
+   groups = "i2c2_sck_x0",
+"i2c2_sda_x1";
+   function = "i2c2";
+   bias-pull-up;
+   drive-strength-microamp = 
<3000>;
+   };
+   };
+
+   i2c2_x15_pins: i2c2-x15 {
+

[PATCH v1 1/2] serial: amlogic: Add UART compatible for A1 board

Add additional compatible to allow using serial driver with A1 board.
After compatible change in DTS [1], serial_meson driver should still be
able to work with console device.

[1] https://lore.kernel.org/all/20230705181833.16137-8-ddroko...@sberdevices.ru/

Signed-off-by: Igor Prusov 
---
 drivers/serial/serial_meson.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/serial/serial_meson.c b/drivers/serial/serial_meson.c
index 934de2ab23..be5f380f85 100644
--- a/drivers/serial/serial_meson.c
+++ b/drivers/serial/serial_meson.c
@@ -232,6 +232,7 @@ static const struct dm_serial_ops meson_serial_ops = {
 static const struct udevice_id meson_serial_ids[] = {
{ .compatible = "amlogic,meson-uart" },
{ .compatible = "amlogic,meson-gx-uart" },
+   { .compatible = "amlogic,meson-a1-uart" },
{ }
 };
 
-- 
2.34.1

[PATCH v1 0/2] arm: dts: meson-a1 Sync DT with Linux

This series syncs Device Tree for Amlogic A1 with Linux. Currently
DTS in Linix has different compatible string for serial devices, which
is not recognized by serial_meson driver, so new compatible is added to
driver as well. Additional driver changes are not required because new
compatible only differentiates between ttyAML and ttyS names for serial
console devices.

Igor Prusov (2):
  serial: amlogic: Add UART compatible for A1 board
  arm: meson-a1: dts: Sync DT with Linux

 arch/arm/dts/meson-a1.dtsi| 356 +-
 drivers/serial/serial_meson.c |   1 +
 2 files changed, 352 insertions(+), 5 deletions(-)

-- 
2.34.1

Re: Understanding how .config for uboot is generated in buildroot

2023-10-17 Thread Ignatius Rivaldi

On Tue, Oct 17, 2023 at 7:17 PM Paul Barker 
wrote:

> On Tue, Oct 17, 2023 at 04:35:20PM +1100, Ignatius Rivaldi wrote:
> > Hi all,
> >
> > When I edit the config file in BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE in a
> > buildroot recipe, how does the config statements from that file got
> > converted into .config file in u-boot?
> >
> > The background is that we're using a custom buildroot config file at
> here:
> > https://github.com/kubos/kubos-linux-build/tree/master to build u-boot
> for
> > a space grade computer. When I added a new config statement
> > (CONFIG_SD_SWITCH=y) in the BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE, it
> doesn't
> > write the config statement to the .config file in the uboot build repo.
> >
> >  Unfortunately the company that owns that has been acquired several times
> > and all the engineers there already left, so I can't just ask them
>
> You're probably better off asking this on the buildroot mailing list.
> See https://lists.buildroot.org/mailman/listinfo/buildroot.
>
> Best regards,
> Paul
>

Thanks for the pointer, I kind of solved this by adding CONFIG_SD_SWITCH to
uboot kconfig definition file, and now when I added CONFIG_SD_SWITCH to the
_config file it works.
I'll ask about buildroot stuff on the buildroot mailing list after this.

The next problem is that the way Kubos implemented SD card slot switching
is by calling into their own proprietary(?) binary blob through the
standalone application thing:
https://www.emblogic.com/blog/12/u-boot-standalone-applications/. What
happens now is that Uboot is stuck at ## Starting application at
0×2180. What are the possible causes of this, and how do I start
debugging this?

Fortunately Kubos gave us the source code for that binary blob before they
go bankrupt, so we can tweak it

[PATCH] arm: dts: imx8mn-var-som: Fix broken EEPROM read

2023-10-17 Thread Hugo Villeneuve

From: Hugo Villeneuve 

On branch WIP/17Oct2023, the EEPROM can no longer be read:

U-Boot 2023.10-latest (Oct 17 2023 - 15:53:43 -0400)
CPU:   Freescale i.MX8MNano Quad rev1.0 at 1200 MHz
Reset cause: POR
Model: Variscite VAR-SOM-MX8MN Symphony evaluation board
var_read_som_eeprom: uclass_get_device_by_of_offset() failed: -19
initcall failed at call 4022207c (err=-19)

Convert EEPROM-related properties to bootph-all so that the EEPROM can
also be read outside of SPL.

Fixes: 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc 
after relocation")
Signed-off-by: Hugo Villeneuve 
---
 arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi 
b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
index e0caf3179ea..2bbc4a49418 100644
--- a/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
@@ -39,11 +39,11 @@
 };
 
  {
-   bootph-pre-ram;
+   bootph-all;
 };
 
 _i2c1 {
-   bootph-pre-ram;
+   bootph-all;
 };
 
 _pmic {
@@ -83,5 +83,5 @@
 };
 
 _som {
-   bootph-pre-ram;
+   bootph-all;
 };

base-commit: e65b5d35c9116485366bb08138043d51220551da
-- 
2.39.2

Re: [PATCH] board: rockchip: add FriendlyElec NanoPC-T6 rk3588 board

Hi Kever,

On 2023-10-08 11:09, Kever Yang wrote:
> 
> On 2023/10/8 05:25, John Clark wrote:
>> NanoPC-T6 is a Rockchip RK3588 based SBC by FriendlyElec.
>>
>> There are four variants depending on the DRAM size: 4G/32GB eMMC, 8G/64GB 
>> eMMC,
>> 16G/16MB SPI NOR, and 16G/256GB eMMC/16MB SPI NOR
> 
> So the board is using SPI NOR flash.
> 
> 
> [...]
> 
>> diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c 
>> b/arch/arm/mach-rockchip/rk3588/rk3588.c
>> index b1f535fad5..e08ebfa39b 100644
>> --- a/arch/arm/mach-rockchip/rk3588/rk3588.c
>> +++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
>> @@ -40,6 +40,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>   const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
>>  [BROM_BOOTSOURCE_EMMC] = "/mmc@fe2e",
>>  [BROM_BOOTSOURCE_SPINOR] = "/spi@fe2b/flash@0",
>> +[BROM_BOOTSOURCE_SPINAND] = "/spi@fe2b/flash@0",
> 
> Why need a SPI NAND?
> 
> If this is really needed, will be a separate patch to support a new boot 
> source from bootrom.

I have done spi boot testing on a few rk3588 boards with SPI NOR flash,
and there seem to be a correlation between the bootsource/bootdevice id
written to reg by the bootrom and the fspi iomux used by the board.

Following bootsource/bootdevice value can be read from reg,

- FSPI (M0): 3
- FSPI (M1): 4
- FSPI (M2): 6

based on testing on the following boards:

- Radxa ROCK 5 Model A - fspim0_pins - rk3588s
- Xunlong Orange Pi 5 - fspim0_pins - rk3588s
brom_bootdevice_id: 3

- FriendlyElec NanoPC-T6 - fspim1_pins - rk3588
- Xunlong Orange Pi 5 Plus - fspim1_pins - rk3588
brom_bootdevice_id: 4

- Radxa ROCK 5 Model B - fspim2_pins - rk3588
brom_bootdevice_id: 6

Can these observations be correct? And if so, maybe we should use
following constants for RK3588?

  BROM_BOOTSOURCE_FSPI_M0 = 3
  BROM_BOOTSOURCE_FSPI_M1 = 4
  BROM_BOOTSOURCE_FSPI_M2 = 6

Any insights into what values bootrom will write to reg would be very
helpful.

Regards,
Jonas

> 
> 
> Thanks,
> - Kever
>

Re: [PATCH v7 4/9] efi_loader: create default file boot option


On 17.10.23 07:32, Masahisa Kojima wrote:

Hi Heinrich,

On Mon, 16 Oct 2023 at 23:52, Heinrich Schuchardt  wrote:


On 16.10.23 15:00, Masahisa Kojima wrote:

On Mon, 16 Oct 2023 at 21:46, Heinrich Schuchardt  wrote:


On 16.10.23 14:31, Ilias Apalodimas wrote:

Hi Heinrich,

On Mon, 16 Oct 2023 at 10:06, Heinrich Schuchardt  wrote:




Am 16. Oktober 2023 08:45:21 MESZ schrieb Masahisa Kojima 
:

Current efibootmgr automatically creates the
boot options of all disks and partitions installing
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
Some of the automatically created boot options are
useless if the disk and partition does not have
the default file(e.g. EFI/BOOT/BOOTAA64.EFI).

This commit only creates the boot option if the disk and
partition have the default file so that system can directly
boot from it.


I don't directly see the user benefit.


The user can add an HTTP boot option now and the installer will
automatically start.  That would allow products to ship with a single
boot option provisioned and run an installer on first boot


This commit is not about HTTP. It changes how boot options for block
devices are created.





Reading all file systems will increase the boot time. Shouldn't we avoid this?


Any idea what would be an alternative?  But when we added the
automatic boot options we said we should avoid dynamic scanning and
store results in a file.  This is doing a similar thing.  The only
difference is that it mounts the iso image before adding the boot
option.


The alternative is to keep showing boot options for block devices even
if there is no BOOT.EFI file.





What does EDK II do?


No Idea :)



On my workstation I get generated boot options

Boot0001* UEFI:CD/DVD Drive BBS(129,,0x0)
Boot0003* UEFI:Removable Device BBS(130,,0x0)
Boot0004* UEFI:Network Device   BBS(131,,0x0)

without any media inserted and without any PXE server available.


It is just information about how the EDK2 works.
When I attach the Fedora installation media on EDK2(OVMF),
the automatically generated boot option is as follows.

UEFI QEMU HARDDISK QM1 : PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)


An ATAPI drive typically is not removable. So I wonder why it is listed.
Did you set the removable flag on the command line?


I guess it is not removable(actually I don't know how to set the
device as removable).
I just attached the iso image to QEMU with something like '-hda
Fedora_netinst.iso".

According to the EDK II implementation[1], the boot option is
enumerated with the following order.
   1. Removable BlockIo
   2. Fixed BlockIo
   3. Non-BlockIo SimpleFileSystem
   4. LoadFile
So boot option for the fixed device such as HDD is also automatically created.

[1] 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L2150





When this boot option is selected, Fedora installer automatically starts.
So EDK II is searching the default file on the fly.


What is shown if you attach a medium without Bootaa64.efi?


The same boot option is created.
UEFI QEMU HARDDISK QM1 : PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)


For USB devices there is a flag controlling if the device is removable:

qemu-system-riscv64 -M virt -kernel u-boot.bin -nographic -device
qemu-xhci -drive if=none,file=disk.img,format=raw,id=USB1 -device
usb-storage,drive=USB1,removable=on

This allows us to test the handling of removable devices in the boot
manager.

Best regards

Heinrich






Best regards

Heinrich



Thanks,
Masahisa Kojima



Best regards

Heinrich



Thanks
/Ilias


Does the UEFI specification warrant this change?

Best regards

Heinrich



Signed-off-by: Masahisa Kojima 
---
lib/efi_loader/efi_bootmgr.c | 86 ++--
1 file changed, 63 insertions(+), 23 deletions(-)

diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index a40762c74c..c8cf1c5506 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -355,40 +355,70 @@ error:
*/
static efi_status_t efi_bootmgr_enumerate_boot_option(struct 
eficonfig_media_boot_option *opt,
   efi_handle_t 
*volume_handles,
-efi_status_t count)
+efi_uintn_t *count)
{
-  u32 i;
+  u32 i, num = 0;
 struct efi_handler *handler;
 efi_status_t ret = EFI_SUCCESS;

-  for (i = 0; i < count; i++) {
+  for (i = 0; i < *count; i++) {
 u16 *p;
 u16 dev_name[BOOTMENU_DEVICE_NAME_MAX];
 char *optional_data;
 struct efi_load_option lo;
 char buf[BOOTMENU_DEVICE_NAME_MAX];
-  struct efi_device_path *device_path;
+  struct efi_device_path *device_path, *full_path, *dp, *fp;
 struct efi_device_path *short_dp;
+  struct efi_file_handle *root, *f;
+

Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3

2023-10-17 Thread Stefano Babic





On 17.10.23 21:21, Tim Harvey wrote:

On Thu, Jul 13, 2023 at 10:17 PM Stefano Babic  wrote:


Hi Tim, Fabio,

On 14.07.23 02:42, Tim Harvey wrote:

On Wed, May 3, 2023 at 9:11 AM Tim Harvey  wrote:


On Fri, Apr 28, 2023 at 11:19 AM Fabio Estevam  wrote:


Hi Tim,

On Fri, Apr 28, 2023 at 2:59 PM Tim Harvey  wrote:


I believe the fix we need is the following which moves phy setup
before the register access (where it should have been along with the
case for !defined(CONFIG_PHY):

...

If everyone agrees here I'll submit a formal patch which should get
applied through Marek via the usb tree before the dt sync.


This works for me, thanks.

When you submit it, feel free to add:

Tested-by: Fabio Estevam 


Fabio,

with commit bb6ea0fe9290 ("usb: ehci-mx6: move phy setup before
register access") now in imx/master:
Tested-by: Tim Harvey  #imx8mm-venice-gw73xx-0x



Stefano,

It doesn't look like this got picked up in your latest tree for some reason.



Series disappeared from my list in patchworks, maybe because I
erroneously thought that a V2 will be sent. I will pick up the series,
thanks for advising.

Best regards,
Stefano



Hi Stefano,

This series [1] is still missing - can you pick it up?

[PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
[PATCH 2/3] arm: dts: imx8mn: Sync with Linux 6.3
[PATCH 3/3] arm: dts: imx8mp: Sync with Linux 6.3

Best Regards,

Tim
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=352685=*



It was set as "Superseeded", that is the reason why it disappeared by my 
list. Thanks for pointing out, I have added again to be merged.


Regards,
Stefano

--
=
DENX Software Engineering GmbH,Managing Director: Erika Unter
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

Re: [PATCH v4 1/1] board: rockchip: add FriendlyElec NanoPC-T6 rk3588 board

On 2023-10-13 03:19, John Clark wrote:
> The NanoPC-T6 is a Rockchip RK3588 based SBC by FriendlyElec.
> 
> There are four variants depending on the DRAM size: 4G/32GB eMMC,
> 8G/64GB eMMC, 16G/16MB SPI NOR, and 16G/256GB eMMC/16MB SPI NOR
> 
> Specifications:
> CPU: Rockchip RK3588, 4x Cortex-A76 (up to 2.4GHz)
> + 4x Cortex-A55 (up to 1.8GHz)
> GPU: Mali-G610 MP4
> VPU: 8K@60fps H.265 and VP9 decoder, 8K@30fps H.264 decoder,
>  4K@60fps AV1 decoder, 8K@30fps H.264 and H.265 encoder
> NPU: 6TOPs, supports INT4/INT8/INT16/FP16
> RAM: 64-bit 4GB/8GB/16GB LPDDR4X at 2133MHz
> eMMC: 0GB/32GB/64GB/256GB HS400
> MicroSD Slot: MicroSD SDR104
> PCIe 3.0: M.2 M-Key x1, PCIe 3.0 x4 for NVMe SSDs up to 2,500 MB/s
> Ethernet: PCIe 2.5G 2x Ethernet (RTL8125BG)
> PCIe 2.1: M.2 E-Key x1, PCIe 2.1 x1 and USB2.0 Host,
>   supports M.2 WiFi and Bluetooth
> 4G Module: MiniPCIe x1, MicroSIM Card Slot x1
> Audio Out: 3.5mm jack for stereo headphone output
> Audio In: 2.0mm PH-2A connector for analog microphone input
> Video Input: standard HDMI input port, up to 4Kp60
> 2x 4-lane MIPI-CSI, compatible with MIPI V1.2
> Video Output: 2x standard HDMI output ports compatible with HDMI2.1,
>   HDMI2.0, and HDMI1.4
> 2x 4-lane MIPI-DSI, compatible with MIPI DPHY 2.0 or CPHY 1.1
> USB-A: USB 3.0, Type A
> USB-C: Full function USB Type‑C port, DP display up to 4Kp60, USB 3.0
> 40-pin 2.54mm header connector: up to 2x SPIs, 6x UARTs, 1x I2Cs,
> 8x PWMs, 2x I2Ss, 28x GPIOs
> Debug UART: 3 Pin 2.54mm header, 3V level, 150bps
> Onboard IR receiver: 38KHz carrier frequency
> RTC Battery: 2 Pin 1.27/1.25mm RTC battery connector for low power
>  RTC IC HYM8563TS
> 5V Fan connector
> Working Temperature: 0C to 70C
> Power: 5.5*2.1mm DC Jack, 12VDC input
> Dimensions: 110x80x1.6mm (without case) / 86x114.5x30mm (with case)
> 
> Kernel commits:
> 893c17716d0c ("arm64: dts: rockchip: Add NanoPC T6")
> a721e28dfad2 ("arm64: dts: rockchip: Add NanoPC T6 PCIe Ethernet support")
> ac76b786cc37 ("arm64: dts: rockchip: Add NanoPC T6 PCIe e-key support")
> 
> Signed-off-by: John Clark 

Reviewed-by: Jonas Karlman 
Tested-by: Jonas Karlman 

Regards,
Jonas

Re: [PATCH v7 4/9] efi_loader: create default file boot option

Hi all,

On Tue, 17 Oct 2023 at 08:33, Masahisa Kojima
 wrote:
>
> Hi Heinrich,
>
> On Mon, 16 Oct 2023 at 23:52, Heinrich Schuchardt  wrote:
> >
> > On 16.10.23 15:00, Masahisa Kojima wrote:
> > > On Mon, 16 Oct 2023 at 21:46, Heinrich Schuchardt  
> > > wrote:
> > >>
> > >> On 16.10.23 14:31, Ilias Apalodimas wrote:
> > >>> Hi Heinrich,
> > >>>
> > >>> On Mon, 16 Oct 2023 at 10:06, Heinrich Schuchardt  
> > >>> wrote:
> > 
> > 
> > 
> >  Am 16. Oktober 2023 08:45:21 MESZ schrieb Masahisa Kojima 
> >  :
> > > Current efibootmgr automatically creates the
> > > boot options of all disks and partitions installing
> > > EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
> > > Some of the automatically created boot options are
> > > useless if the disk and partition does not have
> > > the default file(e.g. EFI/BOOT/BOOTAA64.EFI).
> > >
> > > This commit only creates the boot option if the disk and
> > > partition have the default file so that system can directly
> > > boot from it.
> > 
> >  I don't directly see the user benefit.
> > >>>
> > >>> The user can add an HTTP boot option now and the installer will
> > >>> automatically start.  That would allow products to ship with a single
> > >>> boot option provisioned and run an installer on first boot
> > >>
> > >> This commit is not about HTTP. It changes how boot options for block
> > >> devices are created.
> > >>
> > >>>
> > 
> >  Reading all file systems will increase the boot time. Shouldn't we 
> >  avoid this?
> > >>>
> > >>> Any idea what would be an alternative?  But when we added the
> > >>> automatic boot options we said we should avoid dynamic scanning and
> > >>> store results in a file.  This is doing a similar thing.  The only
> > >>> difference is that it mounts the iso image before adding the boot
> > >>> option.
> > >>
> > >> The alternative is to keep showing boot options for block devices even
> > >> if there is no BOOT.EFI file.
> > >>
> > >>>
> > 
> >  What does EDK II do?
> > >>>
> > >>> No Idea :)
> > >>
> > >>
> > >> On my workstation I get generated boot options
> > >>
> > >> Boot0001* UEFI:CD/DVD Drive BBS(129,,0x0)
> > >> Boot0003* UEFI:Removable Device BBS(130,,0x0)
> > >> Boot0004* UEFI:Network Device   BBS(131,,0x0)
> > >>
> > >> without any media inserted and without any PXE server available.
> > >
> > > It is just information about how the EDK2 works.
> > > When I attach the Fedora installation media on EDK2(OVMF),
> > > the automatically generated boot option is as follows.
> > >
> > > UEFI QEMU HARDDISK QM1 : 
> > > PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
> >
> > An ATAPI drive typically is not removable. So I wonder why it is listed.
> > Did you set the removable flag on the command line?
>
> I guess it is not removable(actually I don't know how to set the
> device as removable).
> I just attached the iso image to QEMU with something like '-hda
> Fedora_netinst.iso".
>
> According to the EDK II implementation[1], the boot option is
> enumerated with the following order.
>   1. Removable BlockIo
>   2. Fixed BlockIo
>   3. Non-BlockIo SimpleFileSystem
>   4. LoadFile
> So boot option for the fixed device such as HDD is also automatically created.
>
> [1] 
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L2150
>
> >
> > >
> > > When this boot option is selected, Fedora installer automatically starts.
> > > So EDK II is searching the default file on the fly.
> >
> > What is shown if you attach a medium without Bootaa64.efi?
>
> The same boot option is created.
> UEFI QEMU HARDDISK QM1 : PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)

I went back to reading the spec and I think Heinrich is right.  We
don't need that check at all. Going through [0] paragraph 4 says
" This search occurs when the device path of the boot image listed in
any boot option points directly to an EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
device and does not specify the exact file to load"

So we should *only* add an automatic variable without the default
application.  Our code in try_load_entry() will search for that

[0] https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html#load-option-processing

Regards
/Ilias
>
> Thanks,
> Masahisa Kojima
>
> >

[PATCH] doc: build: update description of build dependencies for Alpine Linux

2023-10-17 Thread Milan P . Stanić

---
 doc/build/gcc.rst | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/doc/build/gcc.rst b/doc/build/gcc.rst
index a0650a51db..e73f24a304 100644
--- a/doc/build/gcc.rst
+++ b/doc/build/gcc.rst
@@ -60,8 +60,28 @@ For building U-Boot on Alpine Linux at least the following 
packages are needed:
 
 .. code-block:: bash
 
-apk add alpine-sdk bc bison dtc flex linux-headers ncurses-dev \
-  openssl-dev perl python3 py3-setuptools python3-dev sdl2-dev
+apk add alpine-sdk bc bison dtc flex gnutls-dev linux-headers \
+  openssl-dev py3-elftools py3-setuptools python3-dev swig util-linux-dev
+
+Dependeing on the build target further packages may be needed
+
+For build sandbox with lcd
+
+.. code-block:: bash
+
+apk add sdl2-dev
+
+For build riscv64 targets
+
+.. code-block:: bash
+
+apk add opensbi
+
+For build some arm64 targets
+
+.. code-block:: bash
+
+apk add arm-trusted-firmware
 
 Prerequisites
 -
-- 
2.42.0

Re: [PATCH] efi_loader: fix efi_bootmgr_enumerate_boot_option

Hi Mark,

On Tue, 17 Oct 2023 at 22:25, Mark Kettenis  wrote:
>
> > From: Heinrich Schuchardt 
> > Date: Tue, 17 Oct 2023 19:51:48 +0200
> >
> > Only auto-generate boot options for removable media.
> >
> > For testing the different handling of removable and non-removable devices
> > an emulated USB device can be used:
> >
> > make qemu-riscv64_smode_defconfig; make
> > qemu-system-riscv64 -M virt -kernel u-boot.bin -nographic \
> > -device qemu-xhci -drive if=none,file=disk.img,format=raw,id=USB1 \
> > -device usb-storage,drive=USB1,removable=on
>
> Unless I misunderstand what this patch does, this may result in
> systems that don't boot after installation.
>
> On most boards U-Boot does not provide a way to create persistent EFI
> variables after ExitBootServices() is called.  This means that an OS
> installer cannot create a boot entry for the OS installation it just
> created.  Therefore the EFI boot manager will not boot the newly
> installed system.
>
> Now as long as the traditional distro boot mechanism or the EFI distro
> boot bootmeth is enabled the system will probobly still attempt to
> boot the installed system.  But do want to rely on that?

No, we don't.  We already discussed this with Heinrich (offline) and I
think we should not merge that.  The EFI spec doesn't limit the boot
manager to removable entries only. In [0] it mentions

"if the boot image is not loaded via EFI_BOOT_SERVICES.LoadImage() the
boot manager is required to check for a default application to boot.
Searching for a default application to boot happens on ** both
removable and fixed media types**. This search occurs when the device
path of the boot image listed in any boot option points directly to an
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL device and does not specify the exact
file to load. The file discovery method is explained in Boot Option
Recovery. The default media boot case of a protocol other than
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL is handled by the
EFI_LOAD_FILE_PROTOCOL for the target device path and does not need to
be handled by the boot manager."

So scanning both is required.

[0] https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html#load-option-processing

Regards
/Ilias
>
> > Fixes: c416f1c0bcab ("bootmenu: add removable media entries")
> > Fixes: 339b527bd450 ("Move bootorder and bootoption apis to lib")
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> >  lib/efi_loader/efi_bootmgr.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> > index a40762c74c..96d45157b3 100644
> > --- a/lib/efi_loader/efi_bootmgr.c
> > +++ b/lib/efi_loader/efi_bootmgr.c
> > @@ -346,7 +346,7 @@ error:
> >  }
> >
> >  /**
> > - * efi_bootmgr_enumerate_boot_option() - enumerate the possible bootable 
> > media
> > + * efi_bootmgr_enumerate_boot_option() - boot options for removable boot 
> > media
> >   *
> >   * @opt: pointer to the media boot option structure
> >   * @volume_handles:  pointer to the efi handles
> > @@ -370,6 +370,9 @@ static efi_status_t 
> > efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
> >   struct efi_device_path *device_path;
> >   struct efi_device_path *short_dp;
> >
> > + if (!efi_disk_is_removable(volume_handles[i]))
> > + continue;
> > +
> >   ret = efi_search_protocol(volume_handles[i], 
> > _guid_device_path, );
> >   if (ret != EFI_SUCCESS)
> >   continue;
> > @@ -674,7 +677,10 @@ efi_status_t 
> > efi_bootmgr_update_media_device_boot_option(void)
> >   goto out;
> >   }
> >
> > - /* enumerate all devices supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL */
> > + /*
> > +  * Enumerate all removable devices supporting the
> > +  * EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
> > +  */
> >   ret = efi_bootmgr_enumerate_boot_option(opt, volume_handles, count);
> >   if (ret != EFI_SUCCESS)
> >   goto out;
> > --
> > 2.40.1
> >
> >

[PATCH v2 1/1] mtd: spinand: add support for ESMT F50x1G41LB

Adaptation of Linux commit d74c36480a67

This patch adds support for ESMT F50L1G41LB and F50D1G41LB.
It seems that ESMT likes to use random JEDEC ID from other vendors.
Their 1G chips uses 0xc8 from GigaDevice and 2G/4G chips uses 0x2c from
Micron. For this reason, the ESMT entry is named esmt_c8 with explicit
JEDEC ID in variable name.

Datasheets:
https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/F50L1G41LB(2M).pdf
https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/F50D1G41LB(2M).pdf

Signed-off-by: Igor Prusov 
Signed-off-by: Chuanhong Guo 
Signed-off-by: Martin Kurbanov 
Signed-off-by: Dmitry Rokosov 
Tested-by: Martin Kurbanov 
---
 drivers/mtd/nand/spi/Makefile |   3 +-
 drivers/mtd/nand/spi/core.c   |   1 +
 drivers/mtd/nand/spi/esmt.c   | 137 ++
 include/linux/mtd/spinand.h   |   1 +
 4 files changed, 141 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/spi/esmt.c

diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index 3051de4f7e..f172f4787f 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-spinand-objs := core.o gigadevice.o macronix.o micron.o paragon.o toshiba.o 
winbond.o
+spinand-objs := core.o esmt.o gigadevice.o macronix.o micron.o paragon.o
+spinand-objs += toshiba.o winbond.o
 obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 597b088ca7..8ca33459f9 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -828,6 +828,7 @@ static const struct spinand_manufacturer 
*spinand_manufacturers[] = {
_spinand_manufacturer,
_spinand_manufacturer,
_spinand_manufacturer,
+   _c8_spinand_manufacturer,
 };
 
 static int spinand_manufacturer_match(struct spinand_device *spinand,
diff --git a/drivers/mtd/nand/spi/esmt.c b/drivers/mtd/nand/spi/esmt.c
new file mode 100644
index 00..7e07b26827
--- /dev/null
+++ b/drivers/mtd/nand/spi/esmt.c
@@ -0,0 +1,137 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Author:
+ * Chuanhong Guo  - the main driver logic
+ * Martin Kurbanov  - OOB layout
+ */
+
+#ifndef __UBOOT__
+#include 
+#include 
+#endif
+#include 
+
+/* ESMT uses GigaDevice 0xc8 JECDEC ID on some SPI NANDs */
+#define SPINAND_MFR_ESMT_C80xc8
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+  SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+  SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+  SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+  SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 
0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+  SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+  SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+  SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+  SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+/*
+ * OOB spare area map (64 bytes)
+ *
+ * Bad Block Markers
+ * filled by HW and kernel Reserved
+ *   | +---+---+
+ *   | |   |   |
+ *   | |OOB free data Area |non ECC protected  |
+ *   |   +-|-+-|-+-|-+
+ *   |   | | | | | | |
+ * 
+-|---|--+--|-|--+--|-|--+--|-|--+
+ * | |   | section0 |  | |section1  |  | |section2  |  | | 
   section3  |
+ * 
+-v-+-v-+---++--v--+--v--+-+-+--v--+--v--+-+-+--v--+--v--+-+-+
+ * |   |   |   || | | | | | | | | |
 | | |
+ * 
|0:1|2:3|4:7|8:15|16:17|18:19|20:23|24:31|32:33|34:35|36:39|40:47|48:49|50:51|52:55|56:63|
+ * |   |   |   || | | | | | | | | |
 | | |
+ * 
+---+---+-^-+--^-+-+-+--^--+--^--+-+-+--^--+--^--+-+-+--^--+--^--+
+ *   ||| | | | 
| |
+ *   |
+|-+-|-+-|-+
+ *   | ECC Area|(Main + Spare) - filled|by ESMT NAND HW
|
+ *   | |   |   
|
+ *   
+-+---+---+
+ * OOB ECC protected Area - not used due to
+ * partial programming from some filesystems
+ * (like JFFS2 with cleanmarkers)
+ */
+
+#define ESMT_OOB_SECTION_COUNT

[PATCH v2 0/1] mtd: spinand: add support for ESMT F50x1G41LB

This series ports ESMT NAND support from Linux.

Changes in v2:
- Dropped detect procedure rework patch, since similar one was
  already applied to u-boot in commit b20913e3cb.
- Updated NAND_MEMORG values, so that they are correct after
  mbb parameter was added in 8acaec923b.

Igor Prusov (1):
  mtd: spinand: add support for ESMT F50x1G41LB

 drivers/mtd/nand/spi/Makefile |   3 +-
 drivers/mtd/nand/spi/core.c   |   1 +
 drivers/mtd/nand/spi/esmt.c   | 137 ++
 include/linux/mtd/spinand.h   |   1 +
 4 files changed, 141 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/spi/esmt.c

-- 
2.34.1

Re: [PATCH v7 8/9] cmd: efidebug: add uri device path

Hi Kojima-san,

[...]

> + id = (int)hextoul(argv[1], );
> + if (*endp != '\0' || id > 0x)
> + return CMD_RET_USAGE;
> +
> + efi_create_indexed_name(var_name16, sizeof(var_name16),
> + "Boot", id);
> +
> + label = efi_convert_string(argv[2]);
> + if (!label)
> + return CMD_RET_FAILURE;
> + lo.label = label;
> +
> + uridp_len = sizeof(struct efi_device_path) + 
> strlen(argv[3]) + 1;
> + fp_free = efi_alloc(uridp_len + sizeof(END));
> + uridp = (struct efi_device_path_uri *)fp_free;
> + uridp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
> + uridp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_URI;
> + uridp->dp.length = uridp_len;
> + if (!wget_validate_uri(argv[3])) {
> + printf("ERROR: invalid URI\n");
> + r = CMD_RET_FAILURE;
> + goto out;
> + }

This needs to be moved right under label = efi_convert_string(argv[2]);
and group all the checks together early.  You won't have to allocate and
free the memory as well 

> +
> + strcpy(uridp->uri, argv[3]);
> + pos = (char *)uridp + uridp_len;
> + memcpy(pos, , sizeof(END));
> + fp_size += uridp_len + sizeof(END);

Assign this earlier and use it on fp_free = efi_alloc(...)

> + file_path = (struct efi_device_path *)uridp;
> + argc -= 3;

[...]

> + *
> + * @uri: uri string of target file of wget
> + * Return:   true if uri is valid, false if uri is invalid
> + */
> +bool wget_validate_uri(char *uri);
> +
>  #endif /* __NET_H__ */
> diff --git a/net/wget.c b/net/wget.c
> index 2087146b37..6ae2237a0a 100644
> --- a/net/wget.c
> +++ b/net/wget.c
> @@ -566,3 +566,74 @@ out:
>   return ret;
>  }
>  #endif
> +
 
Regards
/Ilias

Re: [PATCH] efi_loader: fix efi_bootmgr_enumerate_boot_option

2023-10-17 Thread Mark Kettenis

> From: Heinrich Schuchardt 
> Date: Tue, 17 Oct 2023 19:51:48 +0200
> 
> Only auto-generate boot options for removable media.
> 
> For testing the different handling of removable and non-removable devices
> an emulated USB device can be used:
> 
> make qemu-riscv64_smode_defconfig; make
> qemu-system-riscv64 -M virt -kernel u-boot.bin -nographic \
> -device qemu-xhci -drive if=none,file=disk.img,format=raw,id=USB1 \
> -device usb-storage,drive=USB1,removable=on

Unless I misunderstand what this patch does, this may result in
systems that don't boot after installation.

On most boards U-Boot does not provide a way to create persistent EFI
variables after ExitBootServices() is called.  This means that an OS
installer cannot create a boot entry for the OS installation it just
created.  Therefore the EFI boot manager will not boot the newly
installed system.

Now as long as the traditional distro boot mechanism or the EFI distro
boot bootmeth is enabled the system will probobly still attempt to
boot the installed system.  But do want to rely on that?

> Fixes: c416f1c0bcab ("bootmenu: add removable media entries")
> Fixes: 339b527bd450 ("Move bootorder and bootoption apis to lib")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_bootmgr.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index a40762c74c..96d45157b3 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -346,7 +346,7 @@ error:
>  }
>  
>  /**
> - * efi_bootmgr_enumerate_boot_option() - enumerate the possible bootable 
> media
> + * efi_bootmgr_enumerate_boot_option() - boot options for removable boot 
> media
>   *
>   * @opt: pointer to the media boot option structure
>   * @volume_handles:  pointer to the efi handles
> @@ -370,6 +370,9 @@ static efi_status_t 
> efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
>   struct efi_device_path *device_path;
>   struct efi_device_path *short_dp;
>  
> + if (!efi_disk_is_removable(volume_handles[i]))
> + continue;
> +
>   ret = efi_search_protocol(volume_handles[i], 
> _guid_device_path, );
>   if (ret != EFI_SUCCESS)
>   continue;
> @@ -674,7 +677,10 @@ efi_status_t 
> efi_bootmgr_update_media_device_boot_option(void)
>   goto out;
>   }
>  
> - /* enumerate all devices supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL */
> + /*
> +  * Enumerate all removable devices supporting the
> +  * EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
> +  */
>   ret = efi_bootmgr_enumerate_boot_option(opt, volume_handles, count);
>   if (ret != EFI_SUCCESS)
>   goto out;
> -- 
> 2.40.1
> 
>

[PATCH] cros_ec: spi: disable annoying key echo on console

2023-10-17 Thread Milan P . Stanić

on Peach-pi console every key press is echoed with message
'cros_ec_command: Returned status 1'

this is not proper fix, just hack to disable this message
---
 drivers/misc/cros_ec_spi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/misc/cros_ec_spi.c b/drivers/misc/cros_ec_spi.c
index 001f0a85ca..7317f4b0f1 100644
--- a/drivers/misc/cros_ec_spi.c
+++ b/drivers/misc/cros_ec_spi.c
@@ -151,7 +151,6 @@ int cros_ec_spi_command(struct udevice *udev, uint8_t cmd, 
int cmd_version,
 
/* Response code is first byte of message */
if (p[0] != EC_RES_SUCCESS) {
-   printf("%s: Returned status %d\n", __func__, p[0]);
return -(int)(p[0]);
}
 
-- 
2.42.0

Re: [PATCH v1 1/2] mtd: spinand: rework detect procedure for different READ_ID operation

Hi Frieder,

On Mon, Oct 09, 2023 at 10:23:53AM +0200, Frieder Schrempf wrote:
> On 04.10.23 17:07, Igor Prusov wrote:
> > Adaptation of Linux commit f1541773af49.
> > 
> > Currently there are 3 different variants of read_id implementation:
> > 1. opcode only. Found in GD5FxGQ4xF.
> > 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
> > 3. opcode + 1 dummy byte. Found in other currently supported chips.
> > 
> > Original implementation was for variant 1 and let detect function
> > of chips with variant 2 and 3 to ignore the first byte. This isn't
> > robust:
> > 
> > 1. For chips of variant 2, if SPI master doesn't keep MOSI low
> > during read, chip will get a random id offset, and the entire id
> > buffer will shift by that offset, causing detect failure.
> > 
> > 2. For chips of variant 1, if it happens to get a devid that equals
> > to manufacture id of variant 2 or 3 chips, it'll get incorrectly
> > detected.
> > 
> > This patch reworks detect procedure to address problems above. New
> > logic do detection for all variants separatedly, in 1-2-3 order.
> > Since all current detect methods do exactly the same id matching
> > procedure, unify them into core.c and remove detect method from
> > manufacture_ops.
> > 
> > Signed-off-by: Chuanhong Guo 
> > Signed-off-by: Igor Prusov 
> 
> An adaptation of this patch was already sent long ago [1] and Dario also
> picked it up in nand-next [2]. Though it looks like this was never
> merged upstream as there wasn't any pull request sent to Tom, right?

Thanks for pointing this out, looks like this rework made it to
upstream, so I'll drop it in v2.

> Dario, as you already seem to have rebased nand-next recently, can you
> please sent the changes to Tom for picking them up? As the merge window
> is open at the moment it would be good to get it done soon. Thanks!
> 
> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20230110115843.391630-1-frie...@fris.de/
> [2]
> https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/commits/nand-next/

-- 
Best Regards,
Igor Prusov

Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3

2023-10-17 Thread Tim Harvey

On Thu, Jul 13, 2023 at 10:17 PM Stefano Babic  wrote:
>
> Hi Tim, Fabio,
>
> On 14.07.23 02:42, Tim Harvey wrote:
> > On Wed, May 3, 2023 at 9:11 AM Tim Harvey  wrote:
> >>
> >> On Fri, Apr 28, 2023 at 11:19 AM Fabio Estevam  wrote:
> >>>
> >>> Hi Tim,
> >>>
> >>> On Fri, Apr 28, 2023 at 2:59 PM Tim Harvey  wrote:
> >>>
>  I believe the fix we need is the following which moves phy setup
>  before the register access (where it should have been along with the
>  case for !defined(CONFIG_PHY):
> >>> ...
>  If everyone agrees here I'll submit a formal patch which should get
>  applied through Marek via the usb tree before the dt sync.
> >>>
> >>> This works for me, thanks.
> >>>
> >>> When you submit it, feel free to add:
> >>>
> >>> Tested-by: Fabio Estevam 
> >>
> >> Fabio,
> >>
> >> with commit bb6ea0fe9290 ("usb: ehci-mx6: move phy setup before
> >> register access") now in imx/master:
> >> Tested-by: Tim Harvey  #imx8mm-venice-gw73xx-0x
> >>
> >
> > Stefano,
> >
> > It doesn't look like this got picked up in your latest tree for some reason.
> >
>
> Series disappeared from my list in patchworks, maybe because I
> erroneously thought that a V2 will be sent. I will pick up the series,
> thanks for advising.
>
> Best regards,
> Stefano
>

Hi Stefano,

This series [1] is still missing - can you pick it up?

[PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
[PATCH 2/3] arm: dts: imx8mn: Sync with Linux 6.3
[PATCH 3/3] arm: dts: imx8mp: Sync with Linux 6.3

Best Regards,

Tim
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=352685=*

Re: failed to build u-boot mt7621_rfb_defconfig

2023-10-17 Thread Fabio Estevam

[Please keep the list on Cc]

On Mon, Oct 16, 2023 at 11:14 PM Xiaobo Liu  wrote:
>
> Hi
>
> I found the nand rfb u-boot mt7621_stage_sram.bin, no spi-nor version was 
> found.
>
> https://u-boot.readthedocs.io/en/latest/board/mediatek/mt7621.html
>
> Where can I find a version of the mt7621 spi-nor?

I am not familiar with the Mediatek chips, but mt7621_stage_sram.bin
seems to be generic, independent of the boot medium.

https://u-boot.readthedocs.io/en/latest/board/mediatek/mt7621.html
shows the same procedure for generating the binary.

Then the last line says: "Burn the u-boot-mt7621.bin to the SPI-NOR or
NAND flash."

Adding the Mediatek maintainers on Cc.

[PATCH] phy: meson-g12a-usb2: fix ret check on power_domain_get

2023-10-17 Thread Guillaume La Roque

Patch which add A1 SoC support create a regression on khadas vim3/vim3l
boards when we try to use fastboot command:

  => fastboot usb 0
  failed to get power domain
  failed to get power domain
  No USB device found
  USB init failed: -19

Add ENOENT check on ret in probe function.

Fixes: 5533c883ce10 ("phy: support Amlogic A1 family")

Signed-off-by: Guillaume La Roque 
---
 drivers/phy/meson-g12a-usb2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/meson-g12a-usb2.c b/drivers/phy/meson-g12a-usb2.c
index 4ba3992bda70..3958d2404b85 100644
--- a/drivers/phy/meson-g12a-usb2.c
+++ b/drivers/phy/meson-g12a-usb2.c
@@ -328,12 +328,12 @@ int meson_g12a_usb2_phy_probe(struct udevice *dev)
 
 #if CONFIG_IS_ENABLED(POWER_DOMAIN)
ret = power_domain_get(dev, >pwrdm);
-   if (ret < 0 && ret != -ENODEV) {
-   pr_err("failed to get power domain\n");
+   if (ret < 0 && ret != -ENODEV && ret != -ENOENT) {
+   pr_err("failed to get power domain : %d\n", ret);
return ret;
}
 
-   if (ret != -ENODEV) {
+   if (ret != -ENODEV && ret != -ENOENT) {
ret = power_domain_on(>pwrdm);
if (ret < 0) {
pr_err("failed to enable power domain\n");
-- 
2.34.1

Re: [PATCH] arm: dts: k3-j721e-mcu-wakeup: Add MCU domain ESM instance

2023-10-17 Thread Nishanth Menon

On 16:35-20231013, Kumar, Udit wrote:
> 
> On 10/13/2023 3:59 PM, Neha Malcom Francis wrote:
> > Currently J721E defines only the main_esm in DTS. Add node for mcu_esm
> > as well.
> > 
> > According to J721E TRM (12.11.2.2 ESM Environment) [1], we see that the
> > interrupt line from ESMi (main_esm) is routed to MCU_ESM (mcu_esm). This
> > is MCU_ESM0_LVL_IN_95 with interrupt ID 95. Configure mcu_esm
> > accordingly so that errors from main_esm are routed to mcu_esm and
> > handled.
> > 
> > [1] https://www.ti.com/lit/zip/spruil1
> > 
> > Signed-off-by: Neha Malcom Francis 
> > ---
> > Upstream kernel effort:
> > https://lore.kernel.org/lkml/20230926142810.602384-1-n-fran...@ti.com/
> 
> 
> should part of next u-boot, kernel sync, no?
> 

That is correct, this should come in via upstream kernel sync.
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

[PATCH 3/3] board: rockchip: Add support for RGB30 and RK2023 to RGxx3

From: Chris Morgan 

Add support for the Powkiddy RK2023 and RGB30 to the Anbernic RGxx3.
While these devices are manufactured by Powkiddy instead of Anbernic,
the hardware is so similar they can all use the same bootloader.

Signed-off-by: Chris Morgan 
---
 board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c 
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index a93b11cd47..dae9dc87c2 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -60,6 +60,8 @@ enum rgxx3_device_id {
RG353P,
RG353V,
RG503,
+   RGB30,
+   RK2023,
/* Devices with duplicate ADC value */
RG353PS,
RG353VS,
@@ -95,6 +97,20 @@ static const struct rg3xx_model rg3xx_model_details[] = {
.fdtfile = DTB_DIR "rk3566-anbernic-rg503.dtb",
.detect_panel = 0,
},
+   [RGB30] = {
+   .adc_value = 383, /* Gathered from second hand information */
+   .board = "rk3566-powkiddy-rgb30",
+   .board_name = "RGB30",
+   .fdtfile = DTB_DIR "rk3566-powkiddy-rgb30.dtb",
+   .detect_panel = 0,
+   },
+   [RK2023] = {
+   .adc_value = 635, /* Observed average from device */
+   .board = "rk3566-powkiddy-rk2023",
+   .board_name = "RK2023",
+   .fdtfile = DTB_DIR "rk3566-powkiddy-rk2023.dtb",
+   .detect_panel = 0,
+   },
/* Devices with duplicate ADC value */
[RG353PS] = {
.adc_value = 860, /* Observed average from device */
-- 
2.34.1

[PATCH 0/3] Add Additional Boards and Features to RGxx3

From: Chris Morgan 

The RGxx3 is a pseudo-device for U-Boot that works for every Anbernic
RGxx3 series device on the market. Add support for another series of
very similar devices from Powkiddy.

Chris Morgan (3):
  board: rockchip: Refactor panel auto-detect code
  board: rockchip: Add Maskrom Mode for Anbernic RGxx3
  board: rockchip: Add support for RGB30 and RK2023 to RGxx3

 board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 195 -
 1 file changed, 154 insertions(+), 41 deletions(-)

-- 
2.34.1

[PATCH 2/3] board: rockchip: Add Maskrom Mode for Anbernic RGxx3

From: Chris Morgan 

Add support for users to enter maskrom mode by holding the function
button when they power up the device.

Since the device has soldered eMMC and sometimes does not expose a clk
pin on the mainboard there is a small chance that a user who flashes a
bad bootloader may not be able to recover if the headers themselves
are valid. As a result this check is done during spl_early_init() to
ensure that it runs as early as possible, and it does so by directly
manipulating the ADC hardware in lieu of loading the ADC driver.

Ideally, once we have an open source TPL stage we can move this to
the TPL stage, so it will run even earlier.

Signed-off-by: Chris Morgan 
---
 board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c 
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index 3d0c614623..a93b11cd47 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -6,12 +6,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -20,6 +22,8 @@
 #include 
 #include 
 
+#define BOOT_BROM_DOWNLOAD 0xef08a53c
+
 #define GPIO0_BASE 0xfdd6
 #define GPIO4_BASE 0xfe77
 #define GPIO_SWPORT_DR_L   0x
@@ -33,6 +37,14 @@
 
 #define GPIO_WRITEMASK(bits)   ((bits) << 16)
 
+#define SARADC_BASE0xfe72
+#define SARADC_DATA0x
+#define SARADC_STAS0x0004
+#define SARADC_ADC_STATUS  BIT(0)
+#define SARADC_CTRL0x0008
+#define SARADC_INPUT_SRC_MSK   0x7
+#define SARADC_POWER_CTRL  BIT(3)
+
 #define DTB_DIR"rockchip/"
 
 struct rg3xx_model {
@@ -118,12 +130,64 @@ static const struct rg353_panel rg353_panel_details[] = {
},
 };
 
+/*
+ * The device has internal eMMC, and while some devices have an exposed
+ * clk pin you can ground to force a bypass not all devices do. As a
+ * result it may be possible for some devices to become a perma-brick
+ * if a corrupted TPL or SPL stage with a valid header is flashed to
+ * the internal eMMC. Add functionality to read ADC channel 0 (the func
+ * button) as early as possible in the boot process to provide some
+ * protection against this. If we ever get an open TPL stage, we should
+ * consider moving this function there.
+ */
+void read_func_button(void)
+{
+   int ret;
+   u32 reg;
+
+   /* Turn off SARADC to reset it. */
+   writel(0, (SARADC_BASE + SARADC_CTRL));
+
+   /* Enable channel 0 and power on SARADC. */
+   writel(((0 & SARADC_INPUT_SRC_MSK) | SARADC_POWER_CTRL),
+  (SARADC_BASE + SARADC_CTRL));
+
+   /*
+* Wait for data to be ready. Use timeout of 2us from
+* rockchip_saradc driver.
+*/
+   ret = readl_poll_timeout((SARADC_BASE + SARADC_STAS), reg,
+!(reg & SARADC_ADC_STATUS), 2);
+   if (ret) {
+   printf("ADC Timeout");
+   return;
+   }
+
+   /* Read the data from the SARADC. */
+   reg = readl((SARADC_BASE + SARADC_DATA));
+
+   /* Turn the SARADC back off so it's ready to be used again. */
+   writel(0, (SARADC_BASE + SARADC_CTRL));
+
+   /*
+* If the value is less than 30 the button is being pressed.
+* Reset the device back into Rockchip download mode.
+*/
+   if (reg <= 30) {
+   printf("download key pressed, entering download mode...");
+   writel(BOOT_BROM_DOWNLOAD, CONFIG_ROCKCHIP_BOOT_MODE_REG);
+   do_reset(NULL, 0, 0, NULL);
+   }
+};
+
 /*
  * Start LED very early so user knows device is on. Set color
  * to red.
  */
 void spl_board_init(void)
 {
+   read_func_button();
+
/* Set GPIO0_C5, GPIO0_C6, and GPIO0_C7 to output. */
writel(GPIO_WRITEMASK(GPIO_C7 | GPIO_C6 | GPIO_C5) | \
   (GPIO_C7 | GPIO_C6 | GPIO_C5),
-- 
2.34.1

[PATCH 1/3] board: rockchip: Refactor panel auto-detect code

From: Chris Morgan 

Make the inability to detect a panel using the auto detection code not
fail the entire boot process. This means that if the panel ID cannot
be read we don't set an environment variable for the panel, and if an
environment variable for the panel is not set we don't attempt to
update the compatible string. Changes to the code also ensure that
when there are multiple compatible strings required for the panel
we use them both, which solves some issues that will pop up soon
for the Linux driver.

Signed-off-by: Chris Morgan 
---
 board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 115 +
 1 file changed, 74 insertions(+), 41 deletions(-)

diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c 
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index 3f1a42d184..3d0c614623 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -40,6 +40,7 @@ struct rg3xx_model {
const char *board;
const char *board_name;
const char *fdtfile;
+   const bool detect_panel;
 };
 
 enum rgxx3_device_id {
@@ -54,52 +55,67 @@ enum rgxx3_device_id {
 
 static const struct rg3xx_model rg3xx_model_details[] = {
[RG353M] = {
-   517, /* Observed average from device */
-   "rk3566-anbernic-rg353m",
-   "RG353M",
-   DTB_DIR "rk3566-anbernic-rg353p.dtb", /* Identical devices */
+   .adc_value = 517, /* Observed average from device */
+   .board = "rk3566-anbernic-rg353m",
+   .board_name = "RG353M",
+   /* Device is identical to RG353P. */
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg353p.dtb",
+   .detect_panel = 1,
},
[RG353P] = {
-   860, /* Documented value of 860 */
-   "rk3566-anbernic-rg353p",
-   "RG353P",
-   DTB_DIR "rk3566-anbernic-rg353p.dtb",
+   .adc_value = 860, /* Documented value of 860 */
+   .board = "rk3566-anbernic-rg353p",
+   .board_name = "RG353P",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg353p.dtb",
+   .detect_panel = 1,
},
[RG353V] = {
-   695, /* Observed average from device */
-   "rk3566-anbernic-rg353v",
-   "RG353V",
-   DTB_DIR "rk3566-anbernic-rg353v.dtb",
+   .adc_value = 695, /* Observed average from device */
+   .board = "rk3566-anbernic-rg353v",
+   .board_name = "RG353V",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg353v.dtb",
+   .detect_panel = 1,
},
[RG503] = {
-   1023, /* Observed average from device */
-   "rk3566-anbernic-rg503",
-   "RG503",
-   DTB_DIR "rk3566-anbernic-rg503.dtb",
+   .adc_value = 1023, /* Observed average from device */
+   .board = "rk3566-anbernic-rg503",
+   .board_name = "RG503",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg503.dtb",
+   .detect_panel = 0,
},
/* Devices with duplicate ADC value */
[RG353PS] = {
-   860, /* Observed average from device */
-   "rk3566-anbernic-rg353ps",
-   "RG353PS",
-   DTB_DIR "rk3566-anbernic-rg353ps.dtb",
+   .adc_value = 860, /* Observed average from device */
+   .board = "rk3566-anbernic-rg353ps",
+   .board_name = "RG353PS",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg353ps.dtb",
+   .detect_panel = 1,
},
[RG353VS] = {
-   695, /* Gathered from second hand information */
-   "rk3566-anbernic-rg353vs",
-   "RG353VS",
-   DTB_DIR "rk3566-anbernic-rg353vs.dtb",
+   .adc_value = 695, /* Gathered from second hand information */
+   .board = "rk3566-anbernic-rg353vs",
+   .board_name = "RG353VS",
+   .fdtfile = DTB_DIR "rk3566-anbernic-rg353vs.dtb",
+   .detect_panel = 1,
},
 };
 
 struct rg353_panel {
const u16 id;
-   const char *panel_compat;
+   const char *panel_compat[2];
 };
 
 static const struct rg353_panel rg353_panel_details[] = {
-   { .id = 0x3052, .panel_compat = "newvision,nv3051d"},
-   { .id = 0x3821, .panel_compat = "anbernic,rg353v-panel-v2"},
+   {
+   .id = 0x3052,
+   .panel_compat[0] = "anbernic,rg353p-panel",
+   .panel_compat[1] = "newvision,nv3051d",
+   },
+   {
+   .id = 0x3821,
+   .panel_compat[0] = "anbernic,rg353v-panel-v2",
+   .panel_compat[1] = NULL,
+   },
 };
 
 /*
@@ -298,11 +314,10 @@ int rgxx3_detect_display(void)
if (!panel) {
printf("Unable to identify panel_id %x\n",
   (panel_id[0] << 8) |

[PATCH] efi_loader: fix efi_bootmgr_enumerate_boot_option

Only auto-generate boot options for removable media.

For testing the different handling of removable and non-removable devices
an emulated USB device can be used:

make qemu-riscv64_smode_defconfig; make
qemu-system-riscv64 -M virt -kernel u-boot.bin -nographic \
-device qemu-xhci -drive if=none,file=disk.img,format=raw,id=USB1 \
-device usb-storage,drive=USB1,removable=on

Fixes: c416f1c0bcab ("bootmenu: add removable media entries")
Fixes: 339b527bd450 ("Move bootorder and bootoption apis to lib")
Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_bootmgr.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index a40762c74c..96d45157b3 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -346,7 +346,7 @@ error:
 }
 
 /**
- * efi_bootmgr_enumerate_boot_option() - enumerate the possible bootable media
+ * efi_bootmgr_enumerate_boot_option() - boot options for removable boot media
  *
  * @opt:   pointer to the media boot option structure
  * @volume_handles:pointer to the efi handles
@@ -370,6 +370,9 @@ static efi_status_t 
efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
struct efi_device_path *device_path;
struct efi_device_path *short_dp;
 
+   if (!efi_disk_is_removable(volume_handles[i]))
+   continue;
+
ret = efi_search_protocol(volume_handles[i], 
_guid_device_path, );
if (ret != EFI_SUCCESS)
continue;
@@ -674,7 +677,10 @@ efi_status_t 
efi_bootmgr_update_media_device_boot_option(void)
goto out;
}
 
-   /* enumerate all devices supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL */
+   /*
+* Enumerate all removable devices supporting the
+* EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
+*/
ret = efi_bootmgr_enumerate_boot_option(opt, volume_handles, count);
if (ret != EFI_SUCCESS)
goto out;
-- 
2.40.1

[RESEND PATCH v1 1/2] spi: add support for Amlogic A1 SPI Flash Controller

From: Igor Prusov 

Add A1 SPIFC driver from Linux. Slightly modified to use u-boot driver
framework and accommodate to lack of ioread32_rep/iowrite32_rep.

Based on Linux version 6.6-rc4

Signed-off-by: Igor Prusov 
Signed-off-by: Martin Kurbanov 
---
 drivers/spi/Kconfig  |   8 +
 drivers/spi/Makefile |   1 +
 drivers/spi/meson_spifc_a1.c | 384 +++
 3 files changed, 393 insertions(+)
 create mode 100644 drivers/spi/meson_spifc_a1.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 854b8b88da..dedb366370 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -251,6 +251,14 @@ config MICROCHIP_COREQSPI
  Enable the QSPI driver for Microchip FPGA QSPI controllers.
  This driver can be used on Polarfire SoC.
 
+config MESON_SPIFC_A1
+   bool "Amlogic Meson A1 SPI Flash Controller driver"
+   depends on ARCH_MESON
+   help
+ Enable the Amlogic A1 SPI Flash Controller (SPIFC) driver.
+ This driver can be used to access the SPI NOR/NAND flash chips on
+ Amlogic A1 SoC.
+
 config MPC8XX_SPI
bool "MPC8XX SPI Driver"
depends on MPC8xx
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index c27b3327c3..14bdb97f18 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_ICH_SPI) +=  ich.o
 obj-$(CONFIG_IPROC_QSPI) += iproc_qspi.o
 obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
 obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
+obj-$(CONFIG_MESON_SPIFC_A1) += meson_spifc_a1.o
 obj-$(CONFIG_MICROCHIP_COREQSPI) += microchip_coreqspi.o
 obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
 obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
diff --git a/drivers/spi/meson_spifc_a1.c b/drivers/spi/meson_spifc_a1.c
new file mode 100644
index 00..4b840c4634
--- /dev/null
+++ b/drivers/spi/meson_spifc_a1.c
@@ -0,0 +1,384 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Amlogic A1 SPI flash controller (SPIFC)
+ *
+ * Copyright (c) 2023, SberDevices. All Rights Reserved.
+ *
+ * Author: Martin Kurbanov 
+ *
+ * Ported to u-boot:
+ * Author: Igor Prusov 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SPIFC_A1_AHB_CTRL_REG  0x0
+#define SPIFC_A1_AHB_BUS_ENBIT(31)
+
+#define SPIFC_A1_USER_CTRL0_REG0x200
+#define SPIFC_A1_USER_REQUEST_ENABLE   BIT(31)
+#define SPIFC_A1_USER_REQUEST_FINISH   BIT(30)
+#define SPIFC_A1_USER_DATA_UPDATED BIT(0)
+
+#define SPIFC_A1_USER_CTRL1_REG0x204
+#define SPIFC_A1_USER_CMD_ENABLE   BIT(30)
+#define SPIFC_A1_USER_CMD_MODE GENMASK(29, 28)
+#define SPIFC_A1_USER_CMD_CODE GENMASK(27, 20)
+#define SPIFC_A1_USER_ADDR_ENABLE  BIT(19)
+#define SPIFC_A1_USER_ADDR_MODEGENMASK(18, 17)
+#define SPIFC_A1_USER_ADDR_BYTES   GENMASK(16, 15)
+#define SPIFC_A1_USER_DOUT_ENABLE  BIT(14)
+#define SPIFC_A1_USER_DOUT_MODEGENMASK(11, 10)
+#define SPIFC_A1_USER_DOUT_BYTES   GENMASK(9, 0)
+
+#define SPIFC_A1_USER_CTRL2_REG0x208
+#define SPIFC_A1_USER_DUMMY_ENABLE BIT(31)
+#define SPIFC_A1_USER_DUMMY_MODE   GENMASK(30, 29)
+#define SPIFC_A1_USER_DUMMY_CLK_SYCLES GENMASK(28, 23)
+
+#define SPIFC_A1_USER_CTRL3_REG0x20c
+#define SPIFC_A1_USER_DIN_ENABLE   BIT(31)
+#define SPIFC_A1_USER_DIN_MODE GENMASK(28, 27)
+#define SPIFC_A1_USER_DIN_BYTESGENMASK(25, 16)
+
+#define SPIFC_A1_USER_ADDR_REG 0x210
+
+#define SPIFC_A1_AHB_REQ_CTRL_REG  0x214
+#define SPIFC_A1_AHB_REQ_ENABLEBIT(31)
+
+#define SPIFC_A1_ACTIMING0_REG (0x0088 << 2)
+#define SPIFC_A1_TSLCH GENMASK(31, 30)
+#define SPIFC_A1_TCLSH GENMASK(29, 28)
+#define SPIFC_A1_TSHWL GENMASK(20, 16)
+#define SPIFC_A1_TSHSL2GENMASK(15, 12)
+#define SPIFC_A1_TSHSL1GENMASK(11, 8)
+#define SPIFC_A1_TWHSL GENMASK(7, 0)
+
+#define SPIFC_A1_DBUF_CTRL_REG 0x240
+#define SPIFC_A1_DBUF_DIR  BIT(31)
+#define SPIFC_A1_DBUF_AUTO_UPDATE_ADDR BIT(30)
+#define SPIFC_A1_DBUF_ADDR GENMASK(7, 0)
+
+#define SPIFC_A1_DBUF_DATA_REG 0x244
+
+#define SPIFC_A1_USER_DBUF_ADDR_REG0x248
+
+#define SPIFC_A1_BUFFER_SIZE   512U
+
+#define SPIFC_A1_MAX_HZ2
+#define SPIFC_A1_MIN_HZ100
+
+#define SPIFC_A1_USER_CMD(op) ( \
+   SPIFC_A1_USER_CMD_ENABLE | \
+   FIELD_PREP(SPIFC_A1_USER_CMD_CODE, (op)->cmd.opcode) | \
+   FIELD_PREP(SPIFC_A1_USER_CMD_MODE, ilog2((op)->cmd.buswidth)))
+
+#define SPIFC_A1_USER_ADDR(op) ( \
+   SPIFC_A1_USER_ADDR_ENABLE | \
+   FIELD_PREP(SPIFC_A1_USER_ADDR_MODE, ilog2((op)->addr.buswidth)) | \
+   FIELD_PREP(SPIFC_A1_USER_ADDR_BYTES, (op)->addr.nbytes - 1))
+
+#define

[RESEND PATCH v1 2/2] ARM: amlogic: ad401: enable SPIFC

From: Igor Prusov 

Enable Amlogic A1 SPI FLash Controller support.

Signed-off-by: Igor Prusov 
Reviewed-by: Neil Armstrong 
---
 configs/ad401_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/ad401_defconfig b/configs/ad401_defconfig
index b9aca3ab0d..b44b9c63e8 100644
--- a/configs/ad401_defconfig
+++ b/configs/ad401_defconfig
@@ -51,6 +51,7 @@ CONFIG_DEBUG_UART_SKIP_INIT=y
 CONFIG_MESON_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
+CONFIG_MESON_SPIFC_A1=y
 CONFIG_USB=y
 CONFIG_DM_USB_GADGET=y
 CONFIG_USB_GADGET=y
-- 
2.34.1

[RESEND PATCH v1 0/2] ARM: amlogic: Add A1 SPIFC support

A1 family boards have new version of SPIFC controller, that is
incompatible with meson_spifc driver. This series ports A1 SPIFC driver
from Linux and enables it for ad401 board.

Igor Prusov (2):
  spi: add support for Amlogic A1 SPI Flash Controller
  ARM: amlogic: ad401: enable SPIFC

 configs/ad401_defconfig  |   1 +
 drivers/spi/Kconfig  |   8 +
 drivers/spi/Makefile |   1 +
 drivers/spi/meson_spifc_a1.c | 384 +++
 4 files changed, 394 insertions(+)
 create mode 100644 drivers/spi/meson_spifc_a1.c

-- 
2.34.1

[PATCH v2 4/4] rockchip: rk3588-rock-5b: Sync USB3 nodes from mainline linux patches

The device tree for rk3588 and rock-5b contain usb3 nodes that have
deviated too much from current state of submitted mainline linux usb3
patches, see [1].

Sync usb3 related nodes from latest patches and collaboras rk3588 tree
so that dwc3-generic driver can be updated to include support for the
rockchip,rk3588-dwc3 compatible in the future, use rockchip,rk3568-dwc3
compatible until final node is merged in linux maintainer tree.

[1] 
https://lore.kernel.org/lkml/20231009172129.43568-1-sebastian.reic...@collabora.com/

Signed-off-by: Jonas Karlman 
---
v2:
- Use rockchip,rk3568-dwc3 compatible so that driver change can be
  submitted in a separate series.

RK3588 USB 3.0 binding update [2] has not been merged for linux v6.7.
Our options is to update these nodes to latest submitted state, as done
in this patch, or to remove them until a sync of final nodes can be done.

[2] 
https://lore.kernel.org/all/20231009172129.43568-2-sebastian.reic...@collabora.com/

 arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 148 +++-
 arch/arm/dts/rk3588-u-boot.dtsi |  39 +++
 arch/arm/dts/rk3588s-u-boot.dtsi|  68 ++-
 configs/rock5b-rk3588_defconfig |   1 -
 4 files changed, 99 insertions(+), 157 deletions(-)

diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi 
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 3f390ef26a3f..b595ddef7028 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -19,38 +19,10 @@
regulator-min-microvolt = <1200>;
regulator-max-microvolt = <1200>;
};
+};
 
-   vcc5v0_usbdcin: vcc5v0-usbdcin {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc5v0_usbdcin";
-   regulator-always-on;
-   regulator-boot-on;
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   vin-supply = <_dcin>;
-   };
-
-   vcc5v0_usb: vcc5v0-usb {
-   compatible = "regulator-fixed";
-   regulator-name = "vcc5v0_usb";
-   regulator-always-on;
-   regulator-boot-on;
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   vin-supply = <_usbdcin>;
-   };
-
-   vbus5v0_typec: vbus5v0-typec {
-   compatible = "regulator-fixed";
-   regulator-name = "vbus5v0_typec";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   gpio = < RK_PB6 GPIO_ACTIVE_HIGH>;
-   vin-supply = <_usb>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_pwren>;
-   };
+_psu {
+   status = "okay";
 };
 
 _pins {
@@ -58,13 +30,9 @@
 };
 
  {
-   usb-typec {
+   usb {
usbc0_int: usbc0-int {
-   rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO _pull_up>;
-   };
-
-   typec5v_pwren: typec5v-pwren {
-   rockchip,pins = <2 RK_PB6 RK_FUNC_GPIO _pull_none>;
+   rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO _pull_none>;
};
};
 };
@@ -97,7 +65,6 @@
 };
 
 _otg {
-   rockchip,typec-vbus-det;
status = "okay";
 };
 
@@ -109,25 +76,17 @@
status = "okay";
 };
 
-_grf {
+_phy1 {
status = "okay";
 };
 
-_grf {
+_phy1_u3 {
status = "okay";
 };
 
-_host0_ehci {
-   companion = <_host0_ohci>;
-};
-
-_host1_ehci {
-   companion = <_host1_ohci>;
-};
-
 _phy0 {
orientation-switch;
-   svid = <0xff01>;
+   mode-switch;
sbu1-dc-gpios = < RK_PA6 GPIO_ACTIVE_HIGH>;
sbu2-dc-gpios = < RK_PA7 GPIO_ACTIVE_HIGH>;
status = "okay";
@@ -135,14 +94,15 @@
port {
#address-cells = <1>;
#size-cells = <0>;
-   usbdp_phy0_orientation_switch: endpoint@0 {
+
+   usbdp_phy0_typec_ss: endpoint@0 {
reg = <0>;
-   remote-endpoint = <_orien_sw>;
+   remote-endpoint = <_ss>;
};
 
-   usbdp_phy0_dp_altmode_mux: endpoint@1 {
+   usbdp_phy0_typec_sbu: endpoint@1 {
reg = <1>;
-   remote-endpoint = <_altmode_mux>;
+   remote-endpoint = <_sbu>;
};
};
 };
@@ -151,84 +111,53 @@
status = "okay";
 };
 
-_phy1 {
-   rockchip,dp-lane-mux = <2 3>;
+_host0_xhci {
+   usb-role-switch;
status = "okay";
-};
 
-_phy1_u3 {
-   status = "okay";
-};
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
 
-_0 {
-   status = "okay";
+   usb_host0_xhci_drd_sw: endpoint {
+   remote-endpoint = <_hs>;
+   };
+   };

[PATCH v2 3/4] rockchip: rk3588-rock-5b: Enable support for PCIe SATA cards

Enable support for PCIe SATA cards and the on-board SATA controller.

This also revert use of CONFIG_PCI_INIT_R in order to speed up boot from
eMMC or SD-cards. Standard boot will initialize pci after faster boot
media have been enumerated.

Signed-off-by: Jonas Karlman 
Reviewed-by: Christopher Obbard 
Tested-by: Christopher Obbard 
Reviewed-by: Kever Yang 
---
v2:
- Collect r-b and t-b tags

 configs/rock5b-rk3588_defconfig | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index 447913faccc4..ec22e70033a0 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -26,6 +26,7 @@ CONFIG_SPL_SPI=y
 CONFIG_SYS_LOAD_ADDR=0xc00800
 CONFIG_PCI=y
 CONFIG_DEBUG_UART=y
+CONFIG_AHCI=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_FIT_SIGNATURE=y
@@ -35,7 +36,6 @@ CONFIG_OF_BOARD_SETUP=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-rock-5b.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_PCI_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -63,6 +63,8 @@ CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent 
assigned-clocks assigne
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SPL_SYSCON=y
+CONFIG_AHCI_PCI=y
+CONFIG_DWC_AHCI=y
 CONFIG_SPL_CLK=y
 # CONFIG_USB_FUNCTION_FASTBOOT is not set
 CONFIG_ROCKCHIP_GPIO=y
@@ -89,6 +91,8 @@ CONFIG_SPL_PINCTRL=y
 CONFIG_REGULATOR_PWM=y
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_SPL_RAM=y
+CONFIG_SCSI=y
+CONFIG_DM_SCSI=y
 CONFIG_BAUDRATE=150
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550_MEM32=y
-- 
2.42.0

[PATCH v2 2/4] rockchip: rk3588-rock-5a: Enable support for USB 2.0 ports

Enable Kconfig options for the two USB 2.0 ports and bottom USB 3.0 port
on ROCK 5 Model A.

Signed-off-by: Jonas Karlman 
---
v2:
- New patch

 configs/rock5a-rk3588s_defconfig | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/configs/rock5a-rk3588s_defconfig b/configs/rock5a-rk3588s_defconfig
index bccdb1e3ecd6..a6471a519514 100644
--- a/configs/rock5a-rk3588s_defconfig
+++ b/configs/rock5a-rk3588s_defconfig
@@ -39,13 +39,16 @@ CONFIG_SPL_STACK_R=y
 CONFIG_SPL_ATF=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_REGULATOR=y
 # CONFIG_SPL_DOS_PARTITION is not set
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIVE=y
 CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
+CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SPL_SYSCON=y
 CONFIG_SPL_CLK=y
@@ -61,12 +64,23 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y
 CONFIG_PHY_REALTEK=y
 CONFIG_DWC_ETH_QOS=y
 CONFIG_DWC_ETH_QOS_ROCKCHIP=y
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
+CONFIG_PHY_ROCKCHIP_USBDP=y
 CONFIG_SPL_PINCTRL=y
-CONFIG_REGULATOR_PWM=y
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=150
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550_MEM32=y
 CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_DM_USB_GADGET=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_GENERIC=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GENERIC=y
 CONFIG_ERRNO_STR=y
-- 
2.42.0

[PATCH v2 1/4] rockchip: rk3588: Sync device tree from v6.7-rockchip-dts64-1 tag

Sync rk3588 device tree from v6.7-rockchip-dts64-1 tag.

Adds PCIe, button and led nodes to rk3588-evb1-v10 and rk3588-rock-5b
boards. Also remove includes from u-boot.dtsi-files that is no longer
needed.

Linux commits:
42145b7a8235 ("arm64: dts: rockchip: add PCIe network controller to rock-5b")
199cbd5f195a ("arm64: dts: rockchip: add PCIe for M.2 M-key to rock-5b")
da447ec38780 ("arm64: dts: rockchip: add PCIe for M.2 E-Key to rock-5b")
86a2024d95e2 ("arm64: dts: rockchip: add PCIe2 network controller to 
rk3588-evb1")
46bb398ea1d8 ("arm64: dts: rockchip: add PCIe3 bus to rk3588-evb1")
1c9a53ff7ece ("arm64: dts: rockchip: Add sdio node to rock-5b")
3eaf2abd11aa ("arm64: dts: rockchip: Add sfc node to rk3588s")
bf012368bb0a ("arm64: dts: rockchip: Add I2S2 M0 pin definitions to rk3588s")
3d77a3e51b0f ("arm64: dts: rockchip: Add UART9 M0 pin definitions to rk3588s")
0002c377e862 ("arm64: dts: rockchip: Remove duplicate regulator vcc3v3_wf from 
rock-5b")
a6169ab36923 ("arm64: dts: rockchip: Enable UART6 on rock-5b")
dd6dc0c4c126 ("arm64: dts: rockchip: Add AV1 decoder node to rk3588s")
afa933c208e5 ("arm64: dts: rockchip: add ADC buttons to rk3588-evb1")
7952cbbda301 ("arm64: dts: rockchip: add status LED to rock-5b")

Signed-off-by: Jonas Karlman 
Reviewed-by: Christopher Obbard 
Reviewed-by: Kever Yang 
---
v2:
- Sync with "Rockchip dts64 changes for 6.7" PR [1]
- Collect r-b tags

[1] https://lore.kernel.org/all/1870252.CQOukoFCf9@phil/

 arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi |  11 +-
 arch/arm/dts/rk3588-evb1-v10.dts | 136 +
 arch/arm/dts/rk3588-rock-5b-u-boot.dtsi  |  60 --
 arch/arm/dts/rk3588-rock-5b.dts  | 145 +++
 arch/arm/dts/rk3588-u-boot.dtsi  |   1 -
 arch/arm/dts/rk3588s-pinctrl.dtsi|  44 +++
 arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi |   4 -
 arch/arm/dts/rk3588s-u-boot.dtsi |  10 --
 arch/arm/dts/rk3588s.dtsi|  24 
 9 files changed, 350 insertions(+), 85 deletions(-)

diff --git a/arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi 
b/arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi
index bd2e25948633..e8566785e965 100644
--- a/arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi
@@ -6,16 +6,7 @@
 #include "rk3588-u-boot.dtsi"
 
 / {
-   aliases {
-   mmc0 = 
-   mmc1 = 
-   };
-
chosen {
-   u-boot,spl-boot-order = 
+   u-boot,spl-boot-order = "same-as-spl", 
};
 };
-
- {
-   bootph-all;
-};
diff --git a/arch/arm/dts/rk3588-evb1-v10.dts b/arch/arm/dts/rk3588-evb1-v10.dts
index 229a9111f5eb..b9d789d57862 100644
--- a/arch/arm/dts/rk3588-evb1-v10.dts
+++ b/arch/arm/dts/rk3588-evb1-v10.dts
@@ -7,6 +7,7 @@
 /dts-v1/;
 
 #include 
+#include 
 #include 
 #include "rk3588.dtsi"
 
@@ -23,12 +24,84 @@
stdout-path = "serial2:150n8";
};
 
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = < 1>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <100>;
+
+   button-vol-up {
+   label = "Volume Up";
+   linux,code = ;
+   press-threshold-microvolt = <17000>;
+   };
+
+   button-vol-down {
+   label = "Volume Down";
+   linux,code = ;
+   press-threshold-microvolt = <417000>;
+   };
+
+   button-menu {
+   label = "Menu";
+   linux,code = ;
+   press-threshold-microvolt = <89>;
+   };
+
+   button-escape {
+   label = "Escape";
+   linux,code = ;
+   press-threshold-microvolt = <1235000>;
+   };
+   };
+
backlight: backlight {
compatible = "pwm-backlight";
power-supply = <_dcin>;
pwms = < 0 25000 0>;
};
 
+   pcie20_avdd0v85: pcie20-avdd0v85-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "pcie20_avdd0v85";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <85>;
+   regulator-max-microvolt = <85>;
+   vin-supply = <_0v85_s0>;
+   };
+
+   pcie20_avdd1v8: pcie20-avdd1v8-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "pcie20_avdd1v8";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_1v8_s0>;
+   };
+
+   pcie30_avdd0v75: pcie30-avdd0v75-regulator {
+   compatible =

[PATCH v2 0/4] rockchip: rk3588: Sync pcie and usb3 nodes from linux

This series sync rk3588 device tree nodes from latest mainline linux
maintainer tree and also update usb3 nodes with latest submitted patches.

Patch 1 sync latest device tree from latest linux maintainer tree to
move pcie and spi flash nodes away from -u-boot.dtsi files.

Patch 2 enable usb 2.0 support on rk3588-rock-5a.

Patch 3 fully enable pcie and ahci/sata support on rk3588-rock-5b.

Patch 4 sync usb3 nodes with latest pending patches in order to drop
use of rockchip,rk3399-dwc3 compatible.

Changes in v2:
- Sync device tree from linux v6.7-rockchip-dts64-1 tag
- Add patch to enable usb 2.0 support on rk3588-rock-5a
- Use rockchip,rk3568-dwc3 compatible so that dwc3-generic driver change
  can be submitted in a separate series
- Collect r-b tags

Jonas Karlman (4):
  rockchip: rk3588: Sync device tree from v6.7-rockchip-dts64-1 tag
  rockchip: rk3588-rock-5a: Enable support for USB 2.0 ports
  rockchip: rk3588-rock-5b: Enable support for PCIe SATA cards
  rockchip: rk3588-rock-5b: Sync USB3 nodes from mainline linux patches

 arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi |  11 +-
 arch/arm/dts/rk3588-evb1-v10.dts | 136 +++
 arch/arm/dts/rk3588-rock-5b-u-boot.dtsi  | 204 +--
 arch/arm/dts/rk3588-rock-5b.dts  | 145 
 arch/arm/dts/rk3588-u-boot.dtsi  |  40 ++---
 arch/arm/dts/rk3588s-pinctrl.dtsi|  44 +
 arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi |   4 -
 arch/arm/dts/rk3588s-u-boot.dtsi |  78 +
 arch/arm/dts/rk3588s.dtsi|  24 +++
 configs/rock5a-rk3588s_defconfig |  16 +-
 configs/rock5b-rk3588_defconfig  |   7 +-
 11 files changed, 467 insertions(+), 242 deletions(-)

-- 
2.42.0

[PATCH v4 7/8] clk: treewide: switch to clock dump from clk_ops

Switch to using new dump operation in clock provider drivers instead of
overriding soc_clk_dump.

Signed-off-by: Igor Prusov 
Tested-by: Patrice Chotard 
---
 arch/mips/mach-pic32/cpu.c | 23 ---
 drivers/clk/aspeed/clk_ast2600.c   | 13 -
 drivers/clk/clk_k210.c | 11 +++-
 drivers/clk/clk_pic32.c| 39 ++
 drivers/clk/clk_versal.c   |  7 -
 drivers/clk/clk_zynq.c | 19 -
 drivers/clk/clk_zynqmp.c   | 13 -
 drivers/clk/imx/clk-imx8.c | 11 +++-
 drivers/clk/meson/a1.c | 24 
 drivers/clk/mvebu/armada-37xx-periph.c |  5 +++-
 drivers/clk/stm32/clk-stm32mp1.c   | 29 ++-
 11 files changed, 89 insertions(+), 105 deletions(-)

diff --git a/arch/mips/mach-pic32/cpu.c b/arch/mips/mach-pic32/cpu.c
index 7ed306e045..68099dd02f 100644
--- a/arch/mips/mach-pic32/cpu.c
+++ b/arch/mips/mach-pic32/cpu.c
@@ -144,26 +144,3 @@ const char *get_core_name(void)
return str;
 }
 #endif
-#ifdef CONFIG_CMD_CLK
-
-int soc_clk_dump(void)
-{
-   int i;
-
-   printf("PLL Speed: %lu MHz\n",
-  CLK_MHZ(rate(PLLCLK)));
-
-   printf("CPU Speed: %lu MHz\n", CLK_MHZ(rate(PB7CLK)));
-
-   printf("MPLL Speed: %lu MHz\n", CLK_MHZ(rate(MPLL)));
-
-   for (i = PB1CLK; i <= PB7CLK; i++)
-   printf("PB%d Clock Speed: %lu MHz\n", i - PB1CLK + 1,
-  CLK_MHZ(rate(i)));
-
-   for (i = REF1CLK; i <= REF5CLK; i++)
-   printf("REFO%d Clock Speed: %lu MHz\n", i - REF1CLK + 1,
-  CLK_MHZ(rate(i)));
-   return 0;
-}
-#endif
diff --git a/drivers/clk/aspeed/clk_ast2600.c b/drivers/clk/aspeed/clk_ast2600.c
index b3cc8392fa..e1365d3f81 100644
--- a/drivers/clk/aspeed/clk_ast2600.c
+++ b/drivers/clk/aspeed/clk_ast2600.c
@@ -1109,6 +1109,7 @@ struct aspeed_clks {
const char *name;
 };
 
+#if IS_ENABLED(CONFIG_CMD_CLK)
 static struct aspeed_clks aspeed_clk_names[] = {
{ ASPEED_CLK_HPLL, "hpll" },
{ ASPEED_CLK_MPLL, "mpll" },
@@ -1123,18 +1124,12 @@ static struct aspeed_clks aspeed_clk_names[] = {
{ ASPEED_CLK_HUARTX, "huxclk" },
 };
 
-int soc_clk_dump(void)
+static int ast2600_clk_dump(struct udevice *dev)
 {
-   struct udevice *dev;
struct clk clk;
unsigned long rate;
int i, ret;
 
-   ret = uclass_get_device_by_driver(UCLASS_CLK, DM_DRIVER_GET(aspeed_scu),
- );
-   if (ret)
-   return ret;
-
printf("Clk\t\tHz\n");
 
for (i = 0; i < ARRAY_SIZE(aspeed_clk_names); i++) {
@@ -1167,11 +1162,15 @@ int soc_clk_dump(void)
 
return 0;
 }
+#endif
 
 struct clk_ops ast2600_clk_ops = {
.get_rate = ast2600_clk_get_rate,
.set_rate = ast2600_clk_set_rate,
.enable = ast2600_clk_enable,
+#if IS_ENABLED(CONFIG_CMD_CLK)
+   .dump = ast2600_clk_dump,
+#endif
 };
 
 static int ast2600_clk_probe(struct udevice *dev)
diff --git a/drivers/clk/clk_k210.c b/drivers/clk/clk_k210.c
index 2f17152021..058940b828 100644
--- a/drivers/clk/clk_k210.c
+++ b/drivers/clk/clk_k210.c
@@ -1276,16 +1276,10 @@ static void show_clks(struct k210_clk_priv *priv, int 
id, int depth)
}
 }
 
-int soc_clk_dump(void)
+static int k210_clk_dump(struct udevice *dev)
 {
-   int ret;
-   struct udevice *dev;
struct k210_clk_priv *priv;
 
-   ret = uclass_get_device_by_driver(UCLASS_CLK, DM_DRIVER_GET(k210_clk),
- );
-   if (ret)
-   return ret;
priv = dev_get_priv(dev);
 
puts(" Rate  Enabled Name\n");
@@ -1304,6 +1298,9 @@ static const struct clk_ops k210_clk_ops = {
.set_parent = k210_clk_set_parent,
.enable = k210_clk_enable,
.disable = k210_clk_disable,
+#if IS_ENABLED(CONFIG_CMD_CLK)
+   .dump = k210_clk_dump,
+#endif
 };
 
 static int k210_clk_probe(struct udevice *dev)
diff --git a/drivers/clk/clk_pic32.c b/drivers/clk/clk_pic32.c
index ef06a7fb9f..f756fc88f0 100644
--- a/drivers/clk/clk_pic32.c
+++ b/drivers/clk/clk_pic32.c
@@ -20,6 +20,8 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define CLK_MHZ(x) ((x) / 100)
+
 /* Primary oscillator */
 #define SYS_POSC_CLK_HZ2400
 
@@ -385,9 +387,46 @@ static ulong pic32_set_rate(struct clk *clk, ulong rate)
return rate;
 }
 
+#if IS_ENABLED(CONFIG_CMD_CLK)
+static int pic32_dump(struct udevice *dev)
+{
+   int i;
+   struct clk clk;
+
+   clk.dev = dev;
+
+   clk.id = PLLCLK;
+   printf("PLL Speed: %lu MHz\n",
+  CLK_MHZ(pic32_get_rate()));
+
+   clk.id = PB7CLK;
+   printf("CPU Speed: %lu MHz\n", CLK_MHZ(pic32_get_rate()));
+
+   clk.id = MPLL;
+   printf("MPLL Speed: %lu MHz\n", CLK_MHZ(pic32_get_rate()));
+
+   for (i = PB1CLK; i <= PB7CLK; i++) {
+

[PATCH v4 8/8] cmd: clk: Make soc_clk_dump static

After introducing dump to clk_ops there is no need to override or expose
this symbol anymore.

Signed-off-by: Igor Prusov 
Reviewed-by: Patrice Chotard 
Tested-by: Patrice Chotard 
---
 cmd/clk.c | 4 ++--
 include/clk.h | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/cmd/clk.c b/cmd/clk.c
index 90cc6fa906..f55911db7a 100644
--- a/cmd/clk.c
+++ b/cmd/clk.c
@@ -59,7 +59,7 @@ static void show_clks(struct udevice *dev, int depth, int 
last_flag)
}
 }
 
-int __weak soc_clk_dump(void)
+static int soc_clk_dump(void)
 {
struct udevice *dev;
const struct clk_ops *ops;
@@ -81,7 +81,7 @@ int __weak soc_clk_dump(void)
return 0;
 }
 #else
-int __weak soc_clk_dump(void)
+static int soc_clk_dump(void)
 {
puts("Not implemented\n");
return 1;
diff --git a/include/clk.h b/include/clk.h
index d91285235f..bf0d9c9d7f 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -674,8 +674,6 @@ static inline bool clk_valid(struct clk *clk)
return clk && !!clk->dev;
 }
 
-int soc_clk_dump(void);
-
 #endif
 
 #define clk_prepare_enable(clk) clk_enable(clk)
-- 
2.34.1

[PATCH v4 6/8] cmd: clk: Use dump function from clk_ops

Add another loop to dump additional info from clock providers that
implement dump operation.

Signed-off-by: Igor Prusov 
Reviewed-by: Patrice Chotard 
Tested-by: Patrice Chotard 
---
 cmd/clk.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/cmd/clk.c b/cmd/clk.c
index c7c379d7a6..90cc6fa906 100644
--- a/cmd/clk.c
+++ b/cmd/clk.c
@@ -62,6 +62,7 @@ static void show_clks(struct udevice *dev, int depth, int 
last_flag)
 int __weak soc_clk_dump(void)
 {
struct udevice *dev;
+   const struct clk_ops *ops;
 
printf(" Rate   Usecnt  Name\n");
printf("--\n");
@@ -69,6 +70,14 @@ int __weak soc_clk_dump(void)
uclass_foreach_dev_probe(UCLASS_CLK, dev)
show_clks(dev, -1, 0);
 
+   uclass_foreach_dev_probe(UCLASS_CLK, dev) {
+   ops = dev_get_driver_ops(dev);
+   if (ops && ops->dump) {
+   printf("--\n");
+   ops->dump(dev);
+   }
+   }
+
return 0;
 }
 #else
-- 
2.34.1

[PATCH v4 5/8] clk: Add dump operation to clk_ops

This adds dump function to struct clk_ops which should replace
soc_clk_dump. It allows clock drivers to provide custom dump
implementation without overriding generic CCF dump function.

Signed-off-by: Igor Prusov 
Reviewed-by: Patrice Chotard 
Tested-by: Patrice Chotard 
---
 include/clk-uclass.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/clk-uclass.h b/include/clk-uclass.h
index a22f1a5d84..30621e4823 100644
--- a/include/clk-uclass.h
+++ b/include/clk-uclass.h
@@ -39,6 +39,9 @@ struct clk_ops {
int (*set_parent)(struct clk *clk, struct clk *parent);
int (*enable)(struct clk *clk);
int (*disable)(struct clk *clk);
+#if IS_ENABLED(CONFIG_CMD_CLK)
+   int (*dump)(struct udevice *dev);
+#endif
 };
 
 #if 0 /* For documentation only */
-- 
2.34.1

[PATCH v4 3/8] clk: k210: Move soc_clk_dump function

Move clock dump function to avoid forward declaration after switching to
dump in clk_ops.

Signed-off-by: Igor Prusov 
---
 drivers/clk/clk_k210.c | 92 +-
 1 file changed, 46 insertions(+), 46 deletions(-)

diff --git a/drivers/clk/clk_k210.c b/drivers/clk/clk_k210.c
index c534cc07e0..2f17152021 100644
--- a/drivers/clk/clk_k210.c
+++ b/drivers/clk/clk_k210.c
@@ -1238,52 +1238,6 @@ static int k210_clk_request(struct clk *clk)
return 0;
 }
 
-static const struct clk_ops k210_clk_ops = {
-   .request = k210_clk_request,
-   .set_rate = k210_clk_set_rate,
-   .get_rate = k210_clk_get_rate,
-   .set_parent = k210_clk_set_parent,
-   .enable = k210_clk_enable,
-   .disable = k210_clk_disable,
-};
-
-static int k210_clk_probe(struct udevice *dev)
-{
-   int ret;
-   struct k210_clk_priv *priv = dev_get_priv(dev);
-
-   priv->base = dev_read_addr_ptr(dev_get_parent(dev));
-   if (!priv->base)
-   return -EINVAL;
-
-   ret = clk_get_by_index(dev, 0, >in0);
-   if (ret)
-   return ret;
-
-   /*
-* Force setting defaults, even before relocation. This is so we can
-* set the clock rate for PLL1 before we relocate into aisram.
-*/
-   if (!(gd->flags & GD_FLG_RELOC))
-   clk_set_defaults(dev, CLK_DEFAULTS_POST_FORCE);
-
-   return 0;
-}
-
-static const struct udevice_id k210_clk_ids[] = {
-   { .compatible = "canaan,k210-clk" },
-   { },
-};
-
-U_BOOT_DRIVER(k210_clk) = {
-   .name = "k210_clk",
-   .id = UCLASS_CLK,
-   .of_match = k210_clk_ids,
-   .ops = _clk_ops,
-   .probe = k210_clk_probe,
-   .priv_auto = sizeof(struct k210_clk_priv),
-};
-
 #if IS_ENABLED(CONFIG_CMD_CLK)
 static char show_enabled(struct k210_clk_priv *priv, int id)
 {
@@ -1342,3 +1296,49 @@ int soc_clk_dump(void)
return 0;
 }
 #endif
+
+static const struct clk_ops k210_clk_ops = {
+   .request = k210_clk_request,
+   .set_rate = k210_clk_set_rate,
+   .get_rate = k210_clk_get_rate,
+   .set_parent = k210_clk_set_parent,
+   .enable = k210_clk_enable,
+   .disable = k210_clk_disable,
+};
+
+static int k210_clk_probe(struct udevice *dev)
+{
+   int ret;
+   struct k210_clk_priv *priv = dev_get_priv(dev);
+
+   priv->base = dev_read_addr_ptr(dev_get_parent(dev));
+   if (!priv->base)
+   return -EINVAL;
+
+   ret = clk_get_by_index(dev, 0, >in0);
+   if (ret)
+   return ret;
+
+   /*
+* Force setting defaults, even before relocation. This is so we can
+* set the clock rate for PLL1 before we relocate into aisram.
+*/
+   if (!(gd->flags & GD_FLG_RELOC))
+   clk_set_defaults(dev, CLK_DEFAULTS_POST_FORCE);
+
+   return 0;
+}
+
+static const struct udevice_id k210_clk_ids[] = {
+   { .compatible = "canaan,k210-clk" },
+   { },
+};
+
+U_BOOT_DRIVER(k210_clk) = {
+   .name = "k210_clk",
+   .id = UCLASS_CLK,
+   .of_match = k210_clk_ids,
+   .ops = _clk_ops,
+   .probe = k210_clk_probe,
+   .priv_auto = sizeof(struct k210_clk_priv),
+};
-- 
2.34.1

[PATCH v4 4/8] clk: amlogic: Move driver and ops structs

Move driver and ops structs to avoid forward declaration after switching
to dump in clk_ops.

Signed-off-by: Igor Prusov 
---
 drivers/clk/meson/a1.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/clk/meson/a1.c b/drivers/clk/meson/a1.c
index 1075ba7333..e3fa9db7d0 100644
--- a/drivers/clk/meson/a1.c
+++ b/drivers/clk/meson/a1.c
@@ -601,14 +601,6 @@ static int meson_clk_set_parent(struct clk *clk, struct 
clk *parent_clk)
return meson_mux_set_parent_by_id(clk, parent_clk->id);
 }
 
-static struct clk_ops meson_clk_ops = {
-   .disable= meson_clk_disable,
-   .enable = meson_clk_enable,
-   .get_rate   = meson_clk_get_rate,
-   .set_rate   = meson_clk_set_rate,
-   .set_parent = meson_clk_set_parent,
-};
-
 static int meson_clk_probe(struct udevice *dev)
 {
struct meson_clk *priv = dev_get_priv(dev);
@@ -638,15 +630,6 @@ static const struct udevice_id meson_clk_ids[] = {
{ }
 };
 
-U_BOOT_DRIVER(meson_clk) = {
-   .name   = "meson-clk-a1",
-   .id = UCLASS_CLK,
-   .of_match   = meson_clk_ids,
-   .priv_auto  = sizeof(struct meson_clk),
-   .ops= _clk_ops,
-   .probe  = meson_clk_probe,
-};
-
 static const char *meson_clk_get_name(struct clk *clk, int id)
 {
const struct meson_clk_info *info;
@@ -727,3 +710,20 @@ int soc_clk_dump(void)
 
return 0;
 }
+
+static struct clk_ops meson_clk_ops = {
+   .disable= meson_clk_disable,
+   .enable = meson_clk_enable,
+   .get_rate   = meson_clk_get_rate,
+   .set_rate   = meson_clk_set_rate,
+   .set_parent = meson_clk_set_parent,
+};
+
+U_BOOT_DRIVER(meson_clk) = {
+   .name   = "meson-clk-a1",
+   .id = UCLASS_CLK,
+   .of_match   = meson_clk_ids,
+   .priv_auto  = sizeof(struct meson_clk),
+   .ops= _clk_ops,
+   .probe  = meson_clk_probe,
+};
-- 
2.34.1

[PATCH v4 0/8] clk: Switch from soc_clk_dump to clk_ops function

Currently clock providers may override default implementation of
soc_clk_dump function to replace clk dump command output. This causes
confusing behaviour when u-boot is built with one of such drivers
enabled but still has clocks defined using CCF. For example, enabling
CMD_CLK and using clk dump on sandbox target will not show CCF clocks
because k210 driver overrides common soc_clk_dump.

Changelog:
 v1 -> v2:
 - Add missing static to dump functions

 v2 -> v3:
 - Make soc_clk_dump in cmd/clk.c static instead of removing __weak

 v3 -> v4:
 - Rebase and refactor dump for new Amlogic A1 clock controller driver

Igor Prusov (8):
  clk: zynq: Move soc_clk_dump to Zynq clock driver
  clk: ast2600: Move soc_clk_dump function
  clk: k210: Move soc_clk_dump function
  clk: amlogic: Move driver and ops structs
  clk: Add dump operation to clk_ops
  cmd: clk: Use dump function from clk_ops
  clk: treewide: switch to clock dump from clk_ops
  cmd: clk: Make soc_clk_dump static

 arch/arm/mach-zynq/clk.c   |  57 --
 arch/mips/mach-pic32/cpu.c |  23 --
 cmd/clk.c  |  13 +++-
 drivers/clk/aspeed/clk_ast2600.c   |  83 ++--
 drivers/clk/clk_k210.c | 103 -
 drivers/clk/clk_pic32.c|  39 ++
 drivers/clk/clk_versal.c   |   7 +-
 drivers/clk/clk_zynq.c |  51 
 drivers/clk/clk_zynqmp.c   |  13 ++--
 drivers/clk/imx/clk-imx8.c |  11 +--
 drivers/clk/meson/a1.c |  54 +
 drivers/clk/mvebu/armada-37xx-periph.c |   5 +-
 drivers/clk/stm32/clk-stm32mp1.c   |  29 ++-
 include/clk-uclass.h   |   3 +
 include/clk.h  |   2 -
 15 files changed, 244 insertions(+), 249 deletions(-)

-- 
2.34.1

[PATCH v4 2/8] clk: ast2600: Move soc_clk_dump function

Move clock dump function to avoid forward declaration after switching to
dump in clk_ops.

Signed-off-by: Igor Prusov 
---
 drivers/clk/aspeed/clk_ast2600.c | 70 
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/clk/aspeed/clk_ast2600.c b/drivers/clk/aspeed/clk_ast2600.c
index e5ada5b6d4..b3cc8392fa 100644
--- a/drivers/clk/aspeed/clk_ast2600.c
+++ b/drivers/clk/aspeed/clk_ast2600.c
@@ -1104,41 +1104,6 @@ static int ast2600_clk_enable(struct clk *clk)
return 0;
 }
 
-struct clk_ops ast2600_clk_ops = {
-   .get_rate = ast2600_clk_get_rate,
-   .set_rate = ast2600_clk_set_rate,
-   .enable = ast2600_clk_enable,
-};
-
-static int ast2600_clk_probe(struct udevice *dev)
-{
-   struct ast2600_clk_priv *priv = dev_get_priv(dev);
-
-   priv->scu = devfdt_get_addr_ptr(dev);
-   if (IS_ERR(priv->scu))
-   return PTR_ERR(priv->scu);
-
-   ast2600_init_rgmii_clk(priv->scu, _clk_defconfig);
-   ast2600_init_rmii_clk(priv->scu, _clk_defconfig);
-   ast2600_configure_mac12_clk(priv->scu);
-   ast2600_configure_mac34_clk(priv->scu);
-   ast2600_configure_rsa_ecc_clk(priv->scu);
-
-   return 0;
-}
-
-static int ast2600_clk_bind(struct udevice *dev)
-{
-   int ret;
-
-   /* The reset driver does not have a device node, so bind it here */
-   ret = device_bind_driver(gd->dm_root, "ast_sysreset", "reset", );
-   if (ret)
-   debug("Warning: No reset driver: ret=%d\n", ret);
-
-   return 0;
-}
-
 struct aspeed_clks {
ulong id;
const char *name;
@@ -1203,6 +1168,41 @@ int soc_clk_dump(void)
return 0;
 }
 
+struct clk_ops ast2600_clk_ops = {
+   .get_rate = ast2600_clk_get_rate,
+   .set_rate = ast2600_clk_set_rate,
+   .enable = ast2600_clk_enable,
+};
+
+static int ast2600_clk_probe(struct udevice *dev)
+{
+   struct ast2600_clk_priv *priv = dev_get_priv(dev);
+
+   priv->scu = devfdt_get_addr_ptr(dev);
+   if (IS_ERR(priv->scu))
+   return PTR_ERR(priv->scu);
+
+   ast2600_init_rgmii_clk(priv->scu, _clk_defconfig);
+   ast2600_init_rmii_clk(priv->scu, _clk_defconfig);
+   ast2600_configure_mac12_clk(priv->scu);
+   ast2600_configure_mac34_clk(priv->scu);
+   ast2600_configure_rsa_ecc_clk(priv->scu);
+
+   return 0;
+}
+
+static int ast2600_clk_bind(struct udevice *dev)
+{
+   int ret;
+
+   /* The reset driver does not have a device node, so bind it here */
+   ret = device_bind_driver(gd->dm_root, "ast_sysreset", "reset", );
+   if (ret)
+   debug("Warning: No reset driver: ret=%d\n", ret);
+
+   return 0;
+}
+
 static const struct udevice_id ast2600_clk_ids[] = {
{ .compatible = "aspeed,ast2600-scu", },
{ },
-- 
2.34.1

[PATCH v4 1/8] clk: zynq: Move soc_clk_dump to Zynq clock driver

Move clock dump function in preparation for switching to dump function
in clk_ops.

Signed-off-by: Igor Prusov 
Acked-by: Michal Simek 
---
 arch/arm/mach-zynq/clk.c | 57 ---
 drivers/clk/clk_zynq.c   | 58 
 2 files changed, 58 insertions(+), 57 deletions(-)

diff --git a/arch/arm/mach-zynq/clk.c b/arch/arm/mach-zynq/clk.c
index 1945f60e08..e6a67326dd 100644
--- a/arch/arm/mach-zynq/clk.c
+++ b/arch/arm/mach-zynq/clk.c
@@ -13,20 +13,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static const char * const clk_names[clk_max] = {
-   "armpll", "ddrpll", "iopll",
-   "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x",
-   "ddr2x", "ddr3x", "dci",
-   "lqspi", "smc", "pcap", "gem0", "gem1",
-   "fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1",
-   "sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1", "dma",
-   "usb0_aper", "usb1_aper", "gem0_aper", "gem1_aper",
-   "sdio0_aper", "sdio1_aper", "spi0_aper", "spi1_aper",
-   "can0_aper", "can1_aper", "i2c0_aper", "i2c1_aper",
-   "uart0_aper", "uart1_aper", "gpio_aper", "lqspi_aper",
-   "smc_aper", "swdt", "dbg_trc", "dbg_apb"
-};
-
 /**
  * set_cpu_clk_info() - Setup clock information
  *
@@ -65,46 +51,3 @@ int set_cpu_clk_info(void)
 
return 0;
 }
-
-/**
- * soc_clk_dump() - Print clock frequencies
- * Returns zero on success
- *
- * Implementation for the clk dump command.
- */
-int soc_clk_dump(void)
-{
-   struct udevice *dev;
-   int i, ret;
-
-   ret = uclass_get_device_by_driver(UCLASS_CLK,
-   DM_DRIVER_GET(zynq_clk), );
-   if (ret)
-   return ret;
-
-   printf("clk\t\tfrequency\n");
-   for (i = 0; i < clk_max; i++) {
-   const char *name = clk_names[i];
-   if (name) {
-   struct clk clk;
-   unsigned long rate;
-
-   clk.id = i;
-   ret = clk_request(dev, );
-   if (ret < 0)
-   return ret;
-
-   rate = clk_get_rate();
-
-   clk_free();
-
-   if ((rate == (unsigned long)-ENOSYS) ||
-   (rate == (unsigned long)-ENXIO))
-   printf("%10s%20s\n", name, "unknown");
-   else
-   printf("%10s%20lu\n", name, rate);
-   }
-   }
-
-   return 0;
-}
diff --git a/drivers/clk/clk_zynq.c b/drivers/clk/clk_zynq.c
index e80500e382..be5226175f 100644
--- a/drivers/clk/clk_zynq.c
+++ b/drivers/clk/clk_zynq.c
@@ -454,6 +454,64 @@ static int dummy_enable(struct clk *clk)
return 0;
 }
 
+static const char * const clk_names[clk_max] = {
+   "armpll", "ddrpll", "iopll",
+   "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x",
+   "ddr2x", "ddr3x", "dci",
+   "lqspi", "smc", "pcap", "gem0", "gem1",
+   "fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1",
+   "sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1", "dma",
+   "usb0_aper", "usb1_aper", "gem0_aper", "gem1_aper",
+   "sdio0_aper", "sdio1_aper", "spi0_aper", "spi1_aper",
+   "can0_aper", "can1_aper", "i2c0_aper", "i2c1_aper",
+   "uart0_aper", "uart1_aper", "gpio_aper", "lqspi_aper",
+   "smc_aper", "swdt", "dbg_trc", "dbg_apb"
+};
+
+/**
+ * soc_clk_dump() - Print clock frequencies
+ * Returns zero on success
+ *
+ * Implementation for the clk dump command.
+ */
+int soc_clk_dump(void)
+{
+   struct udevice *dev;
+   int i, ret;
+
+   ret = uclass_get_device_by_driver(UCLASS_CLK,
+ DM_DRIVER_GET(zynq_clk), );
+   if (ret)
+   return ret;
+
+   printf("clk\t\tfrequency\n");
+   for (i = 0; i < clk_max; i++) {
+   const char *name = clk_names[i];
+
+   if (name) {
+   struct clk clk;
+   unsigned long rate;
+
+   clk.id = i;
+   ret = clk_request(dev, );
+   if (ret < 0)
+   return ret;
+
+   rate = clk_get_rate();
+
+   clk_free();
+
+   if ((rate == (unsigned long)-ENOSYS) ||
+   (rate == (unsigned long)-ENXIO))
+   printf("%10s%20s\n", name, "unknown");
+   else
+   printf("%10s%20lu\n", name, rate);
+   }
+   }
+
+   return 0;
+}
+
 static struct clk_ops zynq_clk_ops = {
.get_rate = zynq_clk_get_rate,
 #ifndef CONFIG_SPL_BUILD
-- 
2.34.1

Re: [PATCH] bootm: Fix flags used for bootargs string substitution

On Tue, Oct 17, 2023 at 12:53:05PM +0200, Piotr Kubik wrote:

> Commit <51bb33846ad2> introduced a feature of bootargs

Checkpatch will complain that this should be:
In commit 51bb33846ad2 ("bootm: Support string substitution in
bootargs")
And this is the kind of thing I would fixup on applying if there was no
other feedback.  However:

> string substitution and changed a flag used in
> bootm_process_cmdline_env() call to be either true or false.
> With this flag value, condition in bootm_process_cmdline()
> `if (flags & BOOTM_CL_SUBST)` is never true
> and process_subst() is never called.
> 
> Signed-off-by: Piotr Kubik 
> ---
>  boot/bootm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/boot/bootm.c b/boot/bootm.c
> index 8f96a80d42..e96489e549 100644
> --- a/boot/bootm.c
> +++ b/boot/bootm.c
> @@ -778,7 +778,8 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag, int 
> argc,
>   if (!ret && (states & BOOTM_STATE_OS_BD_T))
>   ret = boot_fn(BOOTM_STATE_OS_BD_T, argc, argv, images);
>   if (!ret && (states & BOOTM_STATE_OS_PREP)) {
> - ret = bootm_process_cmdline_env(images->os.os == IH_OS_LINUX);
> + ret = bootm_process_cmdline_env(images->os.os == IH_OS_LINUX ?
> + 
> BOOTM_CL_ALL : 0);

This gets hard to read. I would prefer a comment and something like:
int flags = 0;
if (images->os.os == IH_OS_LINUX)
  flags = BOOTM_CL_ALL;
ret = bootm_process_cmdline_env(flags);

As the compiler should be just as smart, and that'll be clear about
what's going on.  Thanks.

-- 
Tom

signature.asc
Description: PGP signature

Re: env: Allow U-Boot scripts to be placed in a .env file

On Tue, Oct 17, 2023 at 10:14:13AM +0200, Wojciech Niziński wrote:
> Hello.
> 
> Very nice feature was introduced in commit:
> 
>     86b9c3e4e48ba47ef28781d06b97846aca74bc8e|
>     env: Allow U-Boot scripts to be placed in a .env file
> 
> This feature works as extension for old CFG_EXTRA_ENV_SETTINGS and make me
> confused why it doesn't work for configured default env file.
> 
> Now in U-Boot config we have two features related to external environment
> file:
> 
> 1st feature (introduced by mentioned commit):
> 
>     CONFIG_ENV_SOURCE_FILE "Environment file to use"
> 
> 2nd feature
> 
>     CONFIG_USE_DEFAULT_ENV_FILE "Create default environment from file"
> 
>     CONFIG_DEFAULT_ENV_FILE "Path to default environment file"
> 
> In 1st feature only basename of .env file can be specified. So env file can
> be located only in board dir which is a limitation for this nice feature:
> 
>     "The file must be in the board directory and have a .env extension, so
>     the resulting filename is typically
> board///.env"
> 
> In 2nd feature I can specify default env file as full path so it can be
> located everywhere - even outside U-Boot source - which is very nice when
> U-Boot is built by Buildroot. I can easily set path as system environment
> variable and it works:
> 
>     CONFIG_USE_DEFAULT_ENV_FILE=y
> CONFIG_DEFAULT_ENV_FILE="$(BR2_EXTERNAL_FOO_PATH)/board/foo/u-boot.env"
> 
> Unfortunately I cannot do the same for 1st feature without patching U-Boot
> sources to put my custom env file into board dir.
> 
> I can see two way of improving features:
>  1st: to extend 1st feature with ability to specify full patch to env file,
> or
>  2nd one: run the same parsing mechanism also for 2nd feature (default env
> file).

Your analysis of how things work is correct.  The intention is that, as
you noted, is that the plain text environment and CONFIG_ENV_SOURCE_FILE
replace the older default environment found in include/env_default.h and
often augmented by the board.h file via (formerly CONFIG now CFG)
EXTRA_ENV_SETTINGS and CONFIG_USE_DEFAULT_ENV_FILE to be the complete
replacement of the environment option.  So I think the next reasonable
step would be to be able to have plain text environment style files work
for CONFIG_USE_DEFAULT_ENV_FILE which I think you're saying doesn't
today.  But I think that yes, a patch to parse the new-style plain text
files for CONFIG_USE_DEFAULT_ENV_FILE would be good, and I suspect
buildroot has enough users of that feature that any corner cases with
trying to parse older files could be caught and fixed?

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH] riscv: Add Zbb support for building U-Boot

On Wed, Aug 09, 2023 at 06:49:30PM +0800, Yu Chien Peter Lin wrote:

> This patch adds ISA string to the -march to generate zbb instructions
> for U-Boot binaries, along with optimized string functions introduced
> from Linux kernel.
> 
> Signed-off-by: Yu Chien Peter Lin 
[snip]
> +config RISCV_ISA_ZBB
> + bool "Zbb extension support for bit manipulation instructions"
> + default n

The default is 'n' so we don't need this line.  This can be fixed
in-line while applying if there's no other feedback, thanks.

--
Tom


signature.asc
Description: PGP signature

Re: commit 83c63f0d118 (led: Move OF "label" property parsing to core)

2023-10-17 Thread Marek Vasut


On 10/17/23 15:29, Rasmus Villemoes wrote:

Hi,


Hi,


I'm trying to resurrect an old submission of a driver for ti,lp5562, so
had occasion to dig into drivers/led/. And I think commit 83c63f0d118 is
buggy or at least incomplete.

Many of the drivers that were subsequently modified to not do that
"label" parsing rely, in their .probe method, on the top node being
distinguished by not having a ->label. And led-uclass itself does that

 /* Ignore the top-level LED node */
 if (uc_plat->label && !strcmp(label, uc_plat->label))
 return uclass_get_device_tail(dev, 0, devp);

The drivers used to only do that label-parsing for subnodes of the top
node, so that worked, but the new code assigns some ->label for anything
bound to a LED uclass driver. There have been at least two patches to
individual drivers to fix this up since (the current top two patches
touching drivers/led/), but I think that's the wrong way to handle this.

At the same time, I actually think 83c63f0d118 didn't go far enough in
deduplicating, since all drivers are left with essentially the same loop:

static int led_gpio_bind(struct udevice *parent)
{
struct udevice *dev;
ofnode node;
int ret;

dev_for_each_subnode(node, parent) {
ret = device_bind_driver_to_node(parent, "gpio_led",
 ofnode_get_name(node),
 node, );
if (ret)
return ret;
}

return 0;
}

static int bcm6753_led_bind(struct udevice *parent)
{
ofnode node;

dev_for_each_subnode(node, parent) {
struct udevice *dev;
int ret;

ret = device_bind_driver_to_node(parent, "bcm6753-led",
 ofnode_get_name(node),
 node, );
if (ret)
return ret;
}

return 0;
}

and that string can, if I'm not mistaken, be gotten from
parent->driver->name.


Which string ? The "bcm6753-led" is driver name , so that would have to 
be parametrized.



So we really should be able to create a
generic_led_bind() that does exactly this loop + the "label" parsing,
remove the label parsing from post_bind (so it doesn't apply to the top
nodes)


Make sure you test the 'led' command. The LEDs might be bound, but not 
probed (so label parsing in LED probe would be too late), and if I 
recall it right, the label parsing has to be in post-bind for the labels 
to correctly show in the 'led' command listing.



, and switch all drivers over to this generic_led_bind().

Alternatively, we can still create a generic_led_bind() that just does
the loop as above, but then somehow prevent the top nodes from gaining
->label, say by not adding the nodename fallback if the node has a
"compatible" property (though that seems like a hack, maybe there's a
cleaner way).


I am all for generic_led_bind() .

Re: [PATCH 1/1] efi_loader: expose the device-tree file name

2023-10-17 Thread Mark Kettenis

> From: Heinrich Schuchardt 
> Date: Tue, 17 Oct 2023 10:55:07 +0200
> 
> Forward and backward compatibility of Linux kernel device-trees is
> sometimes missing. One solution approach is to load a kernel specific
> device-tree. This can either be done via a U-Boot scripts (like the one
> generated by Debian package flash-kernel or by a boot loader like GRUB.
> The boot loader approach currently requires to know the device-tree name
> before first boot which makes it unusable for generic images.

Even if the device trees are compatile, we often see that additonal
nodes get added at a later stage.  So the ability to load a more
complete device tree for the OS is useful and means a user doesn't
necessarily need to update U-Boot to make additional devices work in
their OS.

> Expose the device-tree file name as EFI variable FdtFile.
> This will allow bootloaders to load a kernel specific device-tree.

Right.  I'm considering adding support for loading device trees to the
OpenBSD bootloader and this feature would be really useful since it
would allow me to automagically load the right device tree from the
root filesystem of the OS.

Is my understanding right that this is a null-terminated (8-bit) ASCII
string?  Can this variable be documented somewhere, maybe together
with the EFI_DT_FIXUP_PROTOCOL?


> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_setup.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index e6de685e87..b24feb94dc 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -26,6 +26,27 @@ void __weak allow_unaligned(void)
>  {
>  }
>  
> +/**
> + * efi_init_fdtfile() - set EFI variable FdtFile
> + *
> + * Return:   status code
> + */
> +static efi_status_t efi_init_fdtfile(void)
> +{
> + char *val;
> +
> + val = env_get("fdtfile");
> + if (!val)
> + return EFI_SUCCESS;
> +
> + return efi_set_variable_int(u"FdtFile",
> + _u_boot_guid,
> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
> + EFI_VARIABLE_RUNTIME_ACCESS |
> + EFI_VARIABLE_READ_ONLY,
> + strlen(val) + 1, val, false);
> +}
> +
>  /**
>   * efi_init_platform_lang() - define supported languages
>   *
> @@ -250,6 +271,11 @@ efi_status_t efi_init_obj_list(void)
>   if (ret != EFI_SUCCESS)
>   goto out;
>  
> + /* Define EFI variable FdtFile */
> + ret = efi_init_fdtfile();
> + if (ret != EFI_SUCCESS)
> + goto out;
> +
>   /* Indicate supported features */
>   ret = efi_init_os_indications();
>   if (ret != EFI_SUCCESS)
> -- 
> 2.40.1
> 
>

Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues

2023-10-17 Thread Marek Vasut

On 10/17/23 16:16, Tom Rini wrote:

On Tue, Oct 17, 2023 at 03:48:37PM +0300, Eugen Hristev wrote:

On 10/16/23 22:30, Tom Rini wrote:

On Mon, Oct 16, 2023 at 08:34:16AM +0200, Michal Simek wrote:

On 10/13/23 17:15, Tom Rini wrote:

On Fri, Oct 13, 2023 at 11:11:04AM -0400, Da Xue wrote:

On Fri, Oct 13, 2023 at 7:47 AM Marek Vasut wrote:

On 10/13/23 06:53, Venkatesh Yadav Abbarapu wrote:

The xhci host controller driver trying to queue the URB's and it is
getting halted at the endpoint, thereby hitting the BUG_ON's.
Mostly these kind of random issues are seen on faulty boards.
Removing these BUG_ON's from the U-Boot xhci code, as in Linux kernel
xhci code BUG_ON/BUG's are removed entirely.
Please also note, that BUG_ON() is not recommended any more in the Linux
kernel.
Similar issue has been observed on TI AM437x board and they created a patch
in Linux kernel as below
https://patches.linaro.org/project/linux-usb/patch/1390250711-25840-1-git-send-email-ba...@ti.com/

Signed-off-by: Venkatesh Yadav Abbarapu

I already explained to Xilinx how to sync the driver with Linux and why
this is needed to move forward, multiple times, and even provided a
script which does most of the work automatically, since it is basically
automated process. Xilinx did not even bother to test the script and
provide any feedback.

Until that happens, this patch is rejected.

This patch also causes all of the USB devices on certain platforms to
not be detected:

scanning bus usb@c900 for devices... Device not responding to set address.

USB device not accepting new address (error=8000)

Yes, we are stuck at the impasse where the custodian is asking for
someone to try and do the re-sync, and everyone else will assist with
testing on other platforms, but the re-sync hasn't happened. Can we
please get someone from AMD to attempt the re-sync?

I would like to say that we have someone to do it. But I simply don't have
that person.

That is the big problem we face, yes. Eugen, I think you said you were
going to try and find time to do a re-sync, did you end up getting any?

Hi Tom,

Unfortunately at the moment I am working on a different project, so I do not
see any perspective to do this in the near future, although I would like to
do it and to help.
It may be the case that a company investing into an engineer to work on this
would be the only way.

In any case, do you think Marek would accept doing this incrementally , e.g.
now the driver is synced with 3.10, it would be easier to increment to 4.1
as a first step ?

Incremental updates feels like it might be less of a daunting path to
me, so I'd be agreeable. Marek?

I am fine with that obviously, in fact, I am fine with anything which is
not "pick a random patch from the middle of kernel git log, submit it,
make the driver into a mess of partial patch backports".

[PATCH] imx8mn-var-som: add manufacturer to target description

2023-10-17 Thread Hugo Villeneuve

From: Hugo Villeneuve 

Add Variscite manufacturer to the IMX8MN_VAR_SOM target menu label as
the majority of targets include the manufacturer as part of their menu
description/label and it helps when looking for a particular
manufacturer/board.

Signed-off-by: Hugo Villeneuve 
---
 arch/arm/mach-imx/imx8m/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index 3d62d7052e7..5cf862a8eb0 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -249,7 +249,7 @@ config TARGET_PICO_IMX8MQ
select IMX8M_LPDDR4
 
 config TARGET_IMX8MN_VAR_SOM
-   bool "imx8mn_var_som"
+   bool "Variscite imx8mn_var_som"
select BINMAN
select IMX8MN
select SUPPORT_SPL

base-commit: e65b5d35c9116485366bb08138043d51220551da
-- 
2.39.2

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

On Tue, Oct 17, 2023 at 04:31:27AM +0200, Marek Vasut wrote:

> RZ/G2L part 1, except for two serial port patches which I had to drop as they
> broke R2Dplus, they will come later via subsequent PR.
> 
> The following changes since commit 3c3f1626919cd93cbe6c56e3849937de5be18dbb:
> 
>   Merge tag 'dm-pull-13oct23' of 
> https://source.denx.de/u-boot/custodians/u-boot-dm (2023-10-14 10:50:20 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-sh.git master
> 
> for you to fetch changes up to 4e65545f7a35430710ce95bdddf9d683f7a3f72a:
> 
>   board: rzg2l: Add RZ/G2L SMARC EVK board (2023-10-17 03:27:42 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/1] efi_loader: expose the device-tree file name

On Tue, 17 Oct 2023 at 16:50, Heinrich Schuchardt
 wrote:
>
> Forward and backward compatibility of Linux kernel device-trees is
> sometimes missing. One solution approach is to load a kernel specific
> device-tree. This can either be done via a U-Boot scripts (like the one
> generated by Debian package flash-kernel or by a boot loader like GRUB.
> The boot loader approach currently requires to know the device-tree name
> before first boot which makes it unusable for generic images.
>
> Expose the device-tree file name as EFI variable FdtFile.
> This will allow bootloaders to load a kernel specific device-tree.
>
> The variable will not be exposed on ACPI based systems or if the
> environment variable fdtfile is not defined.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
> Use a unique GUID to enable future U-Boot independent
> standardization.
> Do not try to add the variable on ACPI based systems.
> ---
>  include/efi_loader.h   |  5 +
>  lib/efi_loader/efi_setup.c | 30 ++
>  2 files changed, 35 insertions(+)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index e24410505f..2faa1c191c 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -152,6 +152,11 @@ static inline efi_status_t efi_launch_capsules(void)
> EFI_GUID(0x8108ac4e, 0x9f11, 0x4d59, \
>  0x85, 0x0e, 0xe2, 0x1a, 0x52, 0x2c, 0x59, 0xb2)
>
> +/* Vendor GUID for the FdtFile variable */
> +#define VENDOR_FDTFILE_GUID \
> +   EFI_GUID(d45dde69, 0x3bd6, 0x40e0, \
> +0x90, 0xd5, 0x6b, 0x60, 0x6a, 0xa5, 0x77, 0x30)
> +
>  /* Use internal device tree when starting UEFI application */
>  #define EFI_FDT_USE_INTERNAL NULL
>
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index e6de685e87..71bcde645b 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -17,6 +17,8 @@
>
>  efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
>
> +efi_guid_t vendor_fdtfile_guid = VENDOR_FDTFILE_GUID;
> +
>  /*
>   * Allow unaligned memory access.
>   *
> @@ -26,6 +28,27 @@ void __weak allow_unaligned(void)
>  {
>  }
>
> +/**
> + * efi_init_fdtfile() - set EFI variable FdtFile
> + *
> + * Return: status code
> + */
> +static efi_status_t efi_init_fdtfile(void)
> +{
> +   char *val;
> +
> +   val = env_get("fdtfile");
> +   if (!val)
> +   return EFI_SUCCESS;
> +
> +   return efi_set_variable_int(u"FdtFile",
> +   _fdtfile_guid,
> +   EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +   EFI_VARIABLE_RUNTIME_ACCESS |
> +   EFI_VARIABLE_READ_ONLY,
> +   strlen(val) + 1, val, false);
> +}
> +
>  /**
>   * efi_init_platform_lang() - define supported languages
>   *
> @@ -250,6 +273,13 @@ efi_status_t efi_init_obj_list(void)
> if (ret != EFI_SUCCESS)
> goto out;
>
> +   /* Define EFI variable FdtFile */
> +   if (!CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)) {
> +   ret = efi_init_fdtfile();
> +   if (ret != EFI_SUCCESS)
> +   goto out;
> +   }
> +
> /* Indicate supported features */
> ret = efi_init_os_indications();
> if (ret != EFI_SUCCESS)
> --
> 2.40.1
>
Reviewed-by: Ilias Apalodimas

Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues

On Tue, Oct 17, 2023 at 03:48:37PM +0300, Eugen Hristev wrote:
> On 10/16/23 22:30, Tom Rini wrote:
> > On Mon, Oct 16, 2023 at 08:34:16AM +0200, Michal Simek wrote:
> > > 
> > > 
> > > On 10/13/23 17:15, Tom Rini wrote:
> > > > On Fri, Oct 13, 2023 at 11:11:04AM -0400, Da Xue wrote:
> > > > > On Fri, Oct 13, 2023 at 7:47 AM Marek Vasut  wrote:
> > > > > > 
> > > > > > On 10/13/23 06:53, Venkatesh Yadav Abbarapu wrote:
> > > > > > > The xhci host controller driver trying to queue the URB's and it 
> > > > > > > is
> > > > > > > getting halted at the endpoint, thereby hitting the BUG_ON's.
> > > > > > > Mostly these kind of random issues are seen on faulty boards.
> > > > > > > Removing these BUG_ON's from the U-Boot xhci code, as in Linux 
> > > > > > > kernel
> > > > > > > xhci code BUG_ON/BUG's are removed entirely.
> > > > > > > Please also note, that BUG_ON() is not recommended any more in 
> > > > > > > the Linux
> > > > > > > kernel.
> > > > > > > Similar issue has been observed on TI AM437x board and they 
> > > > > > > created a patch
> > > > > > > in Linux kernel as below
> > > > > > > https://patches.linaro.org/project/linux-usb/patch/1390250711-25840-1-git-send-email-ba...@ti.com/
> > > > > > > 
> > > > > > > Signed-off-by: Venkatesh Yadav Abbarapu 
> > > > > > > 
> > > > > > 
> > > > > > I already explained to Xilinx how to sync the driver with Linux and 
> > > > > > why
> > > > > > this is needed to move forward, multiple times, and even provided a
> > > > > > script which does most of the work automatically, since it is 
> > > > > > basically
> > > > > > automated process. Xilinx did not even bother to test the script and
> > > > > > provide any feedback.
> > > > > > 
> > > > > > Until that happens, this patch is rejected.
> > > > > 
> > > > > This patch also causes all of the USB devices on certain platforms to
> > > > > not be detected:
> > > > > 
> > > > > scanning bus usb@c900 for devices... Device not responding to set 
> > > > > address.
> > > > > 
> > > > > USB device not accepting new address (error=8000)
> > > > 
> > > > Yes, we are stuck at the impasse where the custodian is asking for
> > > > someone to try and do the re-sync, and everyone else will assist with
> > > > testing on other platforms, but the re-sync hasn't happened.  Can we
> > > > please get someone from AMD to attempt the re-sync?
> > > 
> > > I would like to say that we have someone to do it. But I simply don't have
> > > that person.
> > 
> > That is the big problem we face, yes.  Eugen, I think you said you were
> > going to try and find time to do a re-sync, did you end up getting any?
> > 
> 
> 
> Hi Tom,
> 
> Unfortunately at the moment I am working on a different project, so I do not
> see any perspective to do this in the near future, although I would like to
> do it and to help.
> It may be the case that a company investing into an engineer to work on this
> would be the only way.
> 
> In any case, do you think Marek would accept doing this incrementally , e.g.
> now the driver is synced with 3.10, it would be easier to increment to 4.1
> as a first step ?

Incremental updates feels like it might be less of a daunting path to
me, so I'd be agreeable.  Marek?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 21/32] efi: Rearrange the Kconfig for CMD_BOOTEFI_BOOTMGR

On Mon, Oct 16, 2023 at 04:28:12PM -0600, Simon Glass wrote:
> The command should not be used to enable library functionality. Add a
> new BOOTEFI_BOOTMGR Kconfig for that. Adjust the conditions so that the
> same code is built.
> 
> Signed-off-by: Simon Glass 
> Suggested-by: AKASHI Takahiro 
[snip]
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 621ed5e5b0fb..13cad6342c36 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -32,15 +32,14 @@ config EFI_LOADER
>  
>  if EFI_LOADER
>  
> -config CMD_BOOTEFI_BOOTMGR
> +config BOOTEFI_BOOTMGR
>   bool "UEFI Boot Manager"
> - depends on CMDLINE

This is another example of why I'm asking for re-ordering things so that
first you clean / re-order things then you make all of CMD depend on
CMDLINE.  This patch, aside from other feedback, is standalone, if you
do that.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 32/32] sandbox: Add a test for disabling CONFIG_CMDLINE

On Mon, Oct 16, 2023 at 04:28:23PM -0600, Simon Glass wrote:

> Now that everything is working, add a test to make sure that this
> builds correctly.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 22/32] efi: Update EFI_LOADER to depend on DM_ETH

On Mon, Oct 16, 2023 at 04:28:13PM -0600, Simon Glass wrote:

> Since efi_device_path.c calls eth_get_dev() and assumes that Ethernet is
> available, add it as an explicit dependency.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v2)
> 
> Changes in v2:
> - Add new patch to update EFI_LOADER to depend on DM_ETH
> 
>  lib/efi_loader/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 13cad6342c36..fca4b3eef270 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -11,6 +11,7 @@ config EFI_LOADER
>   # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
>   depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
>   depends on BLK
> + depends on DM_ETH
>   depends on !EFI_APP
>   default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
>   select CHARSET

Does this work for you Heinrich, or do you want to clarify the
dependencies (and re-organize the code as needed) around networking?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 19/32] video: Dont require the font command

On Mon, Oct 16, 2023 at 04:28:10PM -0600, Simon Glass wrote:
> While it is nice to have the font command, using 'select' makes it
> impossible to build the console code without it. Change this to use
> 'imply' instead.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  drivers/video/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index ab927641bb7a..21ea5c860cca 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -180,7 +180,7 @@ config CONSOLE_ROTATION
>  
>  config CONSOLE_TRUETYPE
>   bool "Support a console that uses TrueType fonts"
> - select CMD_SELECT_FONT
> + imply CMD_SELECT_FONT
>   help
> TrueTrype fonts can provide outline-drawing capability rather than
> needing to provide a bitmap for each font and size that is needed.

This is one of those cases where "if CMDLINE" makes sense to add
somewhere.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 18/32] video: Allow use without CONFIG_CMDLINE

On Mon, Oct 16, 2023 at 04:28:09PM -0600, Simon Glass wrote:

> Provide a fallback for when CONFIG_SYS_CBSIZE is not provided, so that
> the console can still be used.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  drivers/video/console_truetype.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/video/console_truetype.c 
> b/drivers/video/console_truetype.c
> index 14fb81e9563c..e4dad3f9a191 100644
> --- a/drivers/video/console_truetype.c
> +++ b/drivers/video/console_truetype.c
> @@ -125,7 +125,11 @@ struct pos_info {
>   * Allow one for each character on the command line plus one for each 
> newline.
>   * This is just an estimate, but it should not be exceeded.
>   */
> +#ifdef CONFIG_SYS_CBSIZE
>  #define POS_HISTORY_SIZE (CONFIG_SYS_CBSIZE * 11 / 10)
> +#else
> +#define POS_HISTORY_SIZE (250 * 11 / 10)
> +#endif
>  
>  /**
>   * struct console_tt_metrics - Information about a font / size combination

NAK, this either should be SYS_PBSIZE (output buffer) instead which you
move out from under CMDLINE or SYS_CBSIZE (input buffer) should also be
outside, and both get a help text to explain them a bit better.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 17/32] log: Allow use without CONFIG_CMDLINE

On Mon, Oct 16, 2023 at 04:28:08PM -0600, Simon Glass wrote:

> When CONFIG_SYS_CBSIZE is not used we need an alternative. For logging
> it seems that CONFIG_SYS_PBSIZE is a better choice anyway, so update
> this.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 16/32] net: Depend on CONFIG_CMDLINE

On Mon, Oct 16, 2023 at 04:28:07PM -0600, Simon Glass wrote:

> At present it isn't possible to use networking without the command line
> enabled. Add this as a condition.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Ramon Fried 
> ---
> 
> (no changes since v1)
> 
>  cmd/Kconfig | 1 +
>  net/Kconfig | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 148414f011df..c6ea5c860e33 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1694,6 +1694,7 @@ if NET
>  
>  menuconfig CMD_NET
>   bool "Network commands"
> + depends on CMDLINE
>   default y
>   imply NETDEVICES
>  
> diff --git a/net/Kconfig b/net/Kconfig
> index 4215889127c9..25d494e1db46 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -4,6 +4,7 @@
>  
>  menuconfig NET
>   bool "Networking support"
> + depends on CMDLINE
>   default y
>  
>  if NET

Please unwind this in the other direction.  What in network is depending
on cmdline in a non-trivial way?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 14/32] bootm: Allow building when cleanup functions are missing