Re: [v4 03/12] spi: aspeed: Add ASPEED SPI controller driver
Hi Chin-Ting, On Tue, 24 May 2022 at 05:58, Chin-Ting Kuo wrote: > > Add ASPEED BMC FMC/SPI memory controller driver with > spi-mem interface for AST2500 and AST2600 platform. Have you considered including 2400 support in your patch set? I have prepared a series that adds upstream support for the 2400. We already have support in other drivers (gpio, i2c, sdhci, timer, wdt) so there's no blocker in including support in your patch. Cheers, Joel > > There are three SPI memory controllers embedded in an ASPEED SoC. > - FMC: Named as Firmware Memory Controller. After AC on, MCU ROM >fetches initial device boot image from FMC chip select(CS) 0. > > - SPI1: Play the role of a SPI Master controller. Or, there is a > dedicated path for HOST(X86) to access its BIOS flash mounted > under BMC. spi-aspeed.c implements the control sequence when > SPI1 is a SPI master. > > - SPI2: It is a pure SPI flash controller. For most scenarios, flashes > mounted under it are for pure storage purpose. > > ASPEED SPI controller supports 1-1-1, 1-1-2 and 1-1-4 SPI flash mode. > Three types of command mode are supported, normal mode, command > read/write mode and user mode. > - Normal mode: Default mode. After power on, normal read command 03h or >13h is used to fetch boot image from SPI flash. >- AST2500: Only 03h command can be used after power on > or reset. >- AST2600: If FMC04[6:4] is set, 13h command is used, > otherwise, 03h command. >The address length is decided by FMC04[2:0]. > > - Command mode: SPI controller can send command and address > automatically when CPU read/write the related remapped > or decoded address area. The command used by this mode > can be configured by FMC10/14/18[23:16]. Also, the > address length is decided by FMC04[2:0]. This mode will > be implemented in the following patch series. > > - User mode: It is a traditional and pure SPI operation, where > SPI transmission is controlled by CPU. It is the main > mode in this patch. > > Each SPI controller in ASPEED SoC has its own decoded address mapping. > Within each SPI controller decoded address, driver can assign a specific > address region for each CS of a SPI controller. The decoded address > cannot overlap to each other. With normal mode and command mode, the > decoded address accessed by the CPU determines which CS is active. > When user mode is adopted, the CS decoded address is a FIFO, CPU can > send/receive any SPI transmission by accessing the related decoded > address for the target CS. > > Signed-off-by: Chin-Ting Kuo > --- > v2: Remove defconfig files from this patch. > > drivers/spi/Kconfig | 8 + > drivers/spi/Makefile | 1 + > drivers/spi/spi-aspeed.c | 822 +++ > 3 files changed, 831 insertions(+) > create mode 100644 drivers/spi/spi-aspeed.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index a1e515cb2b..a616294910 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -387,6 +387,14 @@ config SANDBOX_SPI > }; > }; > > +config SPI_ASPEED > + bool "ASPEED SPI controller driver" > + depends on DM_SPI && SPI_MEM > + default n > + help > + Enable ASPEED SPI controller driver for AST2500 > + and AST2600 SoCs. > + > config SPI_SIFIVE > bool "SiFive SPI driver" > help > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index 06e81b465b..36a4bd5dce 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -9,6 +9,7 @@ obj-y += spi-uclass.o > obj-$(CONFIG_CADENCE_QSPI) += cadence_qspi.o cadence_qspi_apb.o > obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o > obj-$(CONFIG_SOFT_SPI) += soft_spi.o > +obj-$(CONFIG_SPI_ASPEED) += spi-aspeed.o > obj-$(CONFIG_SPI_MEM) += spi-mem.o > obj-$(CONFIG_TI_QSPI) += ti_qspi.o > obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o > diff --git a/drivers/spi/spi-aspeed.c b/drivers/spi/spi-aspeed.c > new file mode 100644 > index 00..9574aff793 > --- /dev/null > +++ b/drivers/spi/spi-aspeed.c > @@ -0,0 +1,822 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * ASPEED FMC/SPI Controller driver > + * > + * Copyright (c) 2022 ASPEED Corporation. > + * Copyright (c) 2022 IBM Corporation. > + * > + * Author: > + * Chin-Ting Kuo > + * Cedric Le Goater > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* ASPEED FMC/SPI memory control register related */ > +#define REG_CE_TYPE_SETTING 0x00 > +#define REG_CE_ADDR_MODE_CTRL0x04 > +#define REG_INTR_CTRL_STATUS 0x08 > +#define REG_CE0_CTRL_REG
Re: [PATCH v8 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset
On Mon, Jul 4, 2022 at 11:42 AM JaimeLiao wrote:
>
> Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from
> 8D-8D-8D
> in the begging of probe.
>
> Command extension type is not standardized across flash vendors in DTR mode.
>
> For suiting different vendor flash devices, adding a flag to seperate types
> for
> soft reset on boot.
>
> Signed-off-by: JaimeLiao
> ---
> drivers/mtd/spi/Kconfig| 7 +++
> drivers/mtd/spi/spi-nor-core.c | 7 ++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> index f350c7e5dc..5bb1baa019 100644
> --- a/drivers/mtd/spi/Kconfig
> +++ b/drivers/mtd/spi/Kconfig
> @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS
> can support a type of operation in a much more refined way compared
> to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
>
> +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT
> + bool "Command extension type is INVERT for Software Reset on boot"
> + default n
> + help
> +Because of SFDP information can not be get before boot.
> +So define command extension type is INVERT when Software Reset on
> boot only.
> +
> config SPI_FLASH_SOFT_RESET
> bool "Software Reset support for SPI NOR flashes"
> help
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 5d319e4c0f..50460feaf8 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -3697,7 +3697,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> enum spi_nor_cmd_ext ext;
>
> ext = nor->cmd_ext_type;
> - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) {
> + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT)
> + nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
Better check those parts whose extension is not standard instead of CONFIG.
Jagan.
Re: [PATCH v2 1/7] config/ast2600: Enable CRC32
On Wed, Jun 29, 2022 at 04:35:19PM +0930, Joel Stanley wrote: > Useful for testing images with the default hash type. > > Reviewed-by: Chia-Wei Wang > Reviewed-by: Cédric Le Goater > Signed-off-by: Joel Stanley For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] misc: nuvoton: Add host interface configuartion driver
On Fri, Jun 24, 2022 at 04:24:37PM +0800, Jim Liu wrote: > add nuvoton BMC npcm750 host configuartion driver > > Signed-off-by: Jim Liu Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH RESEND 1/9] ARM: dts: ast2600: Update SDHCI nodes
On Thu, Jun 23, 2022 at 06:35:28PM +0930, Joel Stanley wrote: > Match the description used by the Linux kernel, except use scu instead > of syscon as the phandle. > > Signed-off-by: Joel Stanley For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 11/11] config/aspeed: Enable EEPROM options
On Thu, Jun 23, 2022 at 02:40:41PM +0930, Joel Stanley wrote: > To allow testing of the I2C driver, enable the eprom command and the > misc driver. > > Signed-off-by: Joel Stanley Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 10/11] config/ast2600: Enable I2C driver
On Thu, Jun 23, 2022 at 02:40:40PM +0930, Joel Stanley wrote: > Signed-off-by: Joel Stanley Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 09/11] i2c/aspeed: Add AST2600 compatible
On Thu, Jun 23, 2022 at 02:40:39PM +0930, Joel Stanley wrote: > Signed-off-by: Joel Stanley > Reviewed-by: Ryan Chen Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 08/11] i2c/aspeed: Fix reset control
On Thu, Jun 23, 2022 at 02:40:38PM +0930, Joel Stanley wrote: > The reset control was written for the ast2500 and directly programs the > clocking register. > > So we can share the code with other SoC generations use the reset device > to deassert the I2C reset line. > > Signed-off-by: Joel Stanley > Reviewed-by: Ryan Chen Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 07/11] reset/aspeed: Implement status callback
On Thu, Jun 23, 2022 at 02:40:37PM +0930, Joel Stanley wrote: > The I2C driver shares a reset line between buses, so allow it to test > the state of the reset line before resetting it. > > Signed-off-by: Joel Stanley > Reviewed-by: Ryan Chen Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 06/11] ARM: dts: ast2600-evb: Add I2C devices
On Thu, Jun 23, 2022 at 02:40:36PM +0930, Joel Stanley wrote: > The EVB has an EEPROM and ADT8490 temp sensor/fan controller on bus 7, > and a LM75 temp sensor on bus 8. > > Signed-off-by: Joel Stanley Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 05/11] ARM: dts: ast2500-evb: Add I2C devices
On Thu, Jun 23, 2022 at 02:40:35PM +0930, Joel Stanley wrote: > The EVB has an EEPROM on bus 3 and a LM75 temp sensor on bus 7. Enable > those busses we can test the I2C driver. > > Signed-off-by: Joel Stanley > Reviewed-by: Ryan Chen Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 04/11] ARM: dts: ast2600-evb: Remove redundant pinctrl
On Thu, Jun 23, 2022 at 02:40:34PM +0930, Joel Stanley wrote: > Now that these are in the dtsi we don't need them in the EVB device > tree. > > Signed-off-by: Joel Stanley Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 03/11] ARM: dts: ast2600: Disable I2C nodes by default
On Thu, Jun 23, 2022 at 02:40:33PM +0930, Joel Stanley wrote: > Allow boards to enable the buses they use. > > Signed-off-by: Joel Stanley > Reviewed-by: Ryan Chen Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 02/11] ARM: dts: ast2600: Add I2C reset properties
On Thu, Jun 23, 2022 at 02:40:32PM +0930, Joel Stanley wrote: > The same as the upstream Linux device tree, each i2c bus has a property > specifying the reset line. > > Signed-off-by: Joel Stanley > Reviewed-by: Ryan Chen Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 01/11] ARM: dts: ast2600: Add I2C pinctrl
On Thu, Jun 23, 2022 at 02:40:31PM +0930, Joel Stanley wrote: > From: Eddie James > > Set the pinctrl groups for each I2C bus. These are essential to > I2C operating correctly. > > Signed-off-by: Eddie James > Reviewed-by: Ryan Chen > Signed-off-by: Joel Stanley Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] soc: soc_ti_k3: identify j7200 SR2.0 SoCs
On Tue, Jun 21, 2022 at 04:36:03PM -0500, Bryan Brattlof wrote: > Anytime a new revision of a chip is produced, Texas Instruments > will increment the 4 bit VARIANT section of the CTRLMMR_WKUP_JTAGID > register by one. Typically this will be decoded as SR1.0 -> SR2.0 ... > however a few TI SoCs do not follow this convention. > > Rather than defining a revision string array for each SoC, use a > default revision string array for all TI SoCs that continue to follow > the typical 1.0 -> 2.0 revision scheme. > > Signed-off-by: Bryan Brattlof Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1] phy: nuvoton: add NPCM7xx phy control driver
On Tue, Jun 21, 2022 at 05:03:38PM +0800, Jim Liu wrote: > add BMC NPCM750 phy control driver > > Signed-off-by: Jim Liu Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] toradex: tdx-cfg-block: add new toradex oui range
On Mon, Jun 20, 2022 at 04:57:45PM +0200, Philippe Schenker wrote: > From: Philippe Schenker > > Add new Toradex MAC OUI (8c:06:cb), to the config block. With this change > we extend the possible serial-numbers as follows: > > For serial-numbers -16777215 OUI 00:14:2d is taken > For serial-numbers 16777216-33554431 OUI 8c:06:cb is taken > > Lower 24-bit of the serial number are used in the NIC part of the > MAC address, the complete serial number can be calculated using the OUI. > > Signed-off-by: Philippe Schenker > Reviewed-by: Francesco Dolcini > Reviewed-by: Fabio Estevam > Acked-by: Marcel Ziswiler Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] board: ti: common: board_detect: Do 1byte address checks first.
On Fri, Jun 17, 2022 at 01:26:12PM -0500, Nishanth Menon wrote: > Do 1 byte address checks first prior to doing 2 byte address checks. > When performing 2 byte addressing on 1 byte addressing eeprom, the > second byte is taken in as a write operation and ends up erasing the > eeprom region we want to preserve. > > While we could have theoretically handled this by ensuring the write > protect of the eeproms are properly managed, this is not true in case > where board are updated with 1 byte eeproms to handle supply status. > > Flipping the checks by checking for 1 byte addressing prior to 2 byte > addressing check prevents this problem at the minor cost of additional > overhead for boards with 2 byte addressing eeproms. > > Signed-off-by: Nishanth Menon > Reviewed-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] board: ti: common: Handle the legacy eeprom address width properly
On Fri, Jun 17, 2022 at 01:26:11PM -0500, Nishanth Menon wrote: > Due to supply chain issues, we are starting to see a mixture of eeprom > usage including the smaller 7-bit addressing eeproms such as 24c04 > used for eeproms. > > These eeproms don't respond well to 2 byte addressing and fail the > read operation. We do have a check to ensure that we are reading the > alternate addressing size, however the valid failure prevents us > from checking at 1 byte anymore. > > Rectify the same by falling through and depend on header data comparison > to ensure that we have valid data. > > Signed-off-by: Nishanth Menon > Reviewed-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] board: ti: common: Optimize boot when detecting consecutive bad records
On Fri, Jun 17, 2022 at 01:26:10PM -0500, Nishanth Menon wrote: > The eeprom data area is much bigger than the data we intend to store, > however, with bad programming, we might end up reading bad records over > and over till we run out of eeprom space. instead just exit when 10 > consecutive records are read. > > Signed-off-by: Nishanth Menon > Reviewed-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] firmware: ti_sci_static_data: Make file board agnostic
On Wed, Jun 15, 2022 at 07:33:05PM +0530, Vignesh Raghavendra wrote: > Static DMA channel data for R5 SPL is mostly board agnostic so use SOC > configs instead of EVM specific config to ease adding new board support. > > Drop J7200 EVM specific settings as its same as J721e > > Signed-off-by: Vignesh Raghavendra > Reviewed-by: Nishanth Menon Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/5] configs: am62x_evm_r5: Add CONFIG_NR_DRAM_BANKS as done in a53 defconfig
On Tue, Jun 14, 2022 at 05:45:34PM +0300, Georgi Vlaev wrote: > Add CONFIG_NR_DRAM_BANKS from am62x_evm_a53_defconfig as this is > needed to calculate the size of DDR that is available. > > Signed-off-by: Georgi Vlaev > Reviewed-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/5] board: ti: am62x: Account for DDR size fixups if ECC is enabled
On Tue, Jun 14, 2022 at 05:45:33PM +0300, Georgi Vlaev wrote: > Call into k3-ddrss driver to fixup device tree and resize > the available amount of DDR if ECC is enabled. > > A second fixup is required from A53 SPL to take the fixup > as done from R5 SPL and apply it to DT passed to A53 U-boot, > which in turn passes this to the OS. > > Signed-off-by: Georgi Vlaev > Reviewed-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/5] board: ti: am62x: Use fdt functions for ram and bank init
On Tue, Jun 14, 2022 at 05:45:32PM +0300, Georgi Vlaev wrote: > Use the appropriate fdtdec_setup_mem_size_base() call in > dram_init() and fdtdec_setup_bank_size() in dram_bank_init() > to pull these values from DT, where they are already available, > instead of hardcoding them. > > Signed-off-by: Georgi Vlaev > Reviewed-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/5] arm: dts: k3-am625-*: Mark memory with u-boot,dm-spl
On Tue, Jun 14, 2022 at 05:45:31PM +0300, Georgi Vlaev wrote: > Mark the memory node with u-boot,dm-spl so we can use it > from early SPL on both R5 and A53. > > Signed-off-by: Georgi Vlaev > Reviewed-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/5] arm: mach-k3: common: Use ddr_init in spl_enable_dcache
On Tue, Jun 14, 2022 at 05:45:30PM +0300, Georgi Vlaev wrote: > The spl_enable_dcache() function calls dram_init_banksize() > to get the total memory size. Normally the dram_init_banksize() > setups the memory banks, while the total size is reported > by ddr_init(). This worked so far for K3 since we set the > gd->ram_size in dram_init_banksize() as well. > > Signed-off-by: Georgi Vlaev > Reviewed-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] toradex: tdx-cfg-block: extend assembly version
On Mon, Jun 13, 2022 at 07:35:23PM +0200, Philippe Schenker wrote: > From: Philippe Schenker > > There are two decimal digits reserved to encode the module version and > revision. This code so far implemented A-Z which used 0-25 of this > range. > This commit extends the range to make use of all 99 numbers. After > capital letters the form with a hashtag and number (e.g. #26) is used. > > Examples: > > If the assembly version is between zero and 25 the numbering is as follows, > as it also has been before this commit: > 0: V0.0A > 1: V0.0B > ... > 25: V0.0Z > > New numbering of assembly version: > If the number is between 26 and 99 the new assembly version name is: > 26: V0.0#26 > 27: V0.0#27 > ... > 99: V0.0#99 > > Signed-off-by: Philippe Schenker > Reviewed-by: Francesco Dolcini > Acked-by: Marcel Ziswiler Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] toradex: tdx-cfg-block: use defines for string length
On Mon, Jun 13, 2022 at 07:35:22PM +0200, Philippe Schenker wrote: > From: Philippe Schenker > > With those defines the length can be reused and is in one place > extendable. > > Signed-off-by: Philippe Schenker > Reviewed-by: Francesco Dolcini > Acked-by: Marcel Ziswiler Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] toradex: tdx-cfg-block: use only snprintf
On Mon, Jun 13, 2022 at 07:35:21PM +0200, Philippe Schenker wrote: > From: Philippe Schenker > > Prevent memory issues that could appear with sprintf. Replace all > sprintf occurences with snprintf. > > Signed-off-by: Philippe Schenker > Reviewed-by: Francesco Dolcini > Acked-by: Marcel Ziswiler Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] board: ti: j721e: Return if there is an error while configuring SerDes
On Fri, Jun 10, 2022 at 06:23:38PM +0530, Aswath Govindraju wrote: > While configuring SerDes, errors could be encountered, in these cases, > return instead of going ahead. This is will help in booting even if > configuration of SerDes fails. > > Signed-off-by: Aswath Govindraju Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 2/2] arm: k3: j721e: add dynamic sf bus override support for j721e
On Fri, Jun 03, 2022 at 11:32:16AM +0530, Vaishnav Achath wrote: > implement overrides for spl_spi_boot_bus() and spl_spi_boot_cs() > lookup functions according to bootmode selection, so as to support > both QSPI and OSPI boot using the same build. > > Signed-off-by: Vaishnav Achath > Reviewed-by: Pratyush Yadav Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/2] common: spl: spl_spi: add support for dynamic override of sf bus
On Fri, Jun 03, 2022 at 11:32:15AM +0530, Vaishnav Achath wrote: > Currently the SPI flash to load from is defined through the compile > time config CONFIG_SF_DEFAULT_BUS and CONFIG_SF_DEFAULT_CS, this > prevents the loading of binaries from different SPI flash using the > same build.E.g. supporting QSPI flash boot and OSPI flash boot > on J721E platform is not possible due to this limitation. > > This commit adds lookup functions spl_spi_boot_bus() > and spl_spi_boot_cs for identifying the flash device based on the > selected boot device, when not overridden the lookup functions are > weakly defined in common/spl/spl_spi.c. > > Signed-off-by: Vaishnav Achath > Reviewed-by: Heiko Schocher Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/6] patman: Fix updating argument defaults from settings
Hi,
On Tue, Jul 5, 2022 at 11:16 AM Sean Anderson wrote:
>
> Hi Doug,
>
> On 7/1/22 4:23 PM, Douglas Anderson wrote:
> > Ever since commit 4600767d294d ("patman: Refactor how the default
> > subcommand works"), when I use patman on the Linux tree I get grumbles
> > about unknown tags. This is because the Linux default making
> > process_tags be False wasn't working anymore.
> >
> > It appears that the comment claiming that the defaults propagates
> > through all subparsers no longer works for some reason.
> >
> > We're already looking at all the subparsers anyway. Let's just update
> > each one.
> >
> > Fixes: 4600767d294d ("patman: Refactor how the default subcommand works")
> > Signed-off-by: Douglas Anderson
> > Tested-by: Brian Norris
> > Reviewed-by: Brian Norris
> > ---
> >
> > (no changes since v1)
> >
> > tools/patman/settings.py | 41 +---
> > 1 file changed, 22 insertions(+), 19 deletions(-)
> >
> > diff --git a/tools/patman/settings.py b/tools/patman/settings.py
> > index 7c2b5c196c06..5eefe3d1f55e 100644
> > --- a/tools/patman/settings.py
> > +++ b/tools/patman/settings.py
> > @@ -244,28 +244,31 @@ def _UpdateDefaults(main_parser, config):
> >if isinstance(action, argparse._SubParsersAction)
> >for _, subparser in action.choices.items()]
> >
> > +unknown_settings = set(name for name, val in config.items('settings'))
> > +
> > # Collect the defaults from each parser
> > -defaults = {}
> > for parser in parsers:
> > pdefs = parser.parse_known_args()[0]
> > -defaults.update(vars(pdefs))
> > -
> > -# Go through the settings and collect defaults
> > -for name, val in config.items('settings'):
> > -if name in defaults:
> > -default_val = defaults[name]
> > -if isinstance(default_val, bool):
> > -val = config.getboolean('settings', name)
> > -elif isinstance(default_val, int):
> > -val = config.getint('settings', name)
> > -elif isinstance(default_val, str):
> > -val = config.get('settings', name)
> > -defaults[name] = val
> > -else:
> > -print("WARNING: Unknown setting %s" % name)
> > -
> > -# Set all the defaults (this propagates through all subparsers)
> > -main_parser.set_defaults(**defaults)
> > +defaults = dict(vars(pdefs))
> > +
> > +# Go through the settings and collect defaults
> > +for name, val in config.items('settings'):
> > +if name in defaults:
> > +default_val = defaults[name]
> > +if isinstance(default_val, bool):
> > +val = config.getboolean('settings', name)
> > +elif isinstance(default_val, int):
> > +val = config.getint('settings', name)
> > +elif isinstance(default_val, str):
> > +val = config.get('settings', name)
> > +defaults[name] = val
> > +unknown_settings.discard(name)
> > +
> > +# Set all the defaults
> > +parser.set_defaults(**defaults)
> > +
> > +for name in sorted(unknown_settings):
> > +print("WARNING: Unknown setting %s" % name)
>
> Can you see if 4780f7d8a6b ("patman: Fix defaults not propagating to
> subparsers") [1] addresses this problem? The implementation is different,
> but I believe these should have the same effect.
To my mind the logic of your patch is a bit harder to follow, but I
believe you're correct that it accomplishes the same thing. ...and my
quick test also seems to confirm that yours works fine. Too bad it
wasn't already in "-next" or it would have saved me a bit of time...
I'm curious whether you agree that the logic in my patch is a little
simpler. Should I re-post it as a squashed revert of yours and then
apply mine and call it a "simplify" instead of a bugfix? ...or just
leave yours alone? If we leave yours alone, I guess my patch #2 needs
a trivial rebase to fix a merge conflict.
-Doug
Re: [PATCH] Kconfig: Fix SYS_MALLOC_F_LEN for i.MX8MQ
On 7/6/2022 5:01 PM, Heiko Thiery wrote: Hi Peng Am Di., 5. Juli 2022 um 18:04 Uhr schrieb Tom Rini : On Tue, Jul 05, 2022 at 05:20:46PM +0200, Heiko Thiery wrote: Hi Tom, Am Di., 5. Juli 2022 um 15:35 Uhr schrieb Tom Rini : On Tue, Jul 05, 2022 at 12:19:54PM +0200, Heiko Thiery wrote: Hi all, Am Mo., 11. Apr. 2022 um 14:29 Uhr schrieb Tom Rini : On Mon, Apr 11, 2022 at 05:07:04PM +0800, Peng Fan (OSS) wrote: From: Peng Fan i.MX8MQ use SYS_MALLOC_F_LEN 0x2000, not 0x1. The OCRAM_S only has 32KB memory, use 0x1 will make SPL not bootable. It is strange. You said the i.MX8MQ has 32KB OCRAM memory. That means a value of 0x8000 should be the max usable value. But I see when setting to this value my board does not start. Only when I set the value to 0xc000 the board starts. In the RM I see: - On-Chip RAM - OCRAM (128 KB) - On-Chip RAM for State Retention - OCRAM_S (32 KB) Yes. I said OCRAM_S only has 32KB. The MALLOC BASE is set in OCRAM_S. If your board has other settings, you could change that for your requirement. I think I have checked all boards, When I worked out this patch, I may overlook your board. Regards, Peng. Signed-off-by: Peng Fan Reviewed-by: Michael Trimarchi Reviewed-by: Fabio Estevam --- Kconfig | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Kconfig b/Kconfig index 6b1ddfc549e..3e95ec9d7b9 100644 --- a/Kconfig +++ b/Kconfig @@ -251,8 +251,10 @@ config SYS_MALLOC_F_LEN default 0x4000 if SANDBOX || RISCV default 0x2000 if (ARCH_MX7 || ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5 || \ ARCH_QEMU || ARCH_SUNXI || ARCH_OWL) - default 0x1 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_LS1012A || \ - ARCH_LS1021A || ARCH_LS1043A || ARCH_LS1046A) + default 0x1 if (ARCH_IMX8 || (ARCH_IMX8M && !IMX8MQ) || \ + ARCH_LS1012A || ARCH_LS1021A || ARCH_LS1043A || \ + ARCH_LS1046A) + default 0x2000 if IMX8MQ default 0x400 help Before relocation, memory is very limited on many platforms. Still, Note that we can put this with the rest of the 0x2000 default instances. And as an aside, imx8mq_phanbell_defconfig sets this to 0x4000. That said, I've applied this to master (with the location change I noted), thanks! -- Tom I just tested v2022.07-rc6 and noticed that by reducing the value the kontron pitx-imx8m (imx8mq) board does not start anymore. I locally increased the value to 0xc000 and the board works again. So should I increase the value just for this board or should I increase the default value for the IMX8MQ? I would _really_ like to see defaults per SoC. Even if that means saying "default 0xc000 if IMX8Q && SPL_FEAT_X" as I know with tight constraints on memory AND the need to have some of the bigger feature knobs enabled it can be tricky to get usable defaults. But what I really want to avoid are both the problem of everyone copy/pasting a value that's too big or too small and also avoid the problem of N boards needing the same fix because they all failed due to the same problem. I understand your concerns but the value that has to be adjusted is not SPL_SYS_MALLOC_F_LEN. Therefore I'm not sure if the '&& SPL_FEAT_X' would be correct here. Ah right, sorry. So yes, it's even more likely we should be able to come up with one default for the family. -- Tom -- Heiko
Re: [PATCH v6 00/25] Add support for MediaTek MT7621 SoC - v6
Hi Weijie, On 20.05.22 05:21, Weijie Gao wrote: This series will add support for MediaTek MT7621 SoC with two reference boards and related drivers. The MediaTek MT7621 is a network processor integrating a dual-core dual-threaded MIPS 1004Kc processor running at a normal frequency of 880MHz. This chip can be found in many wireless routers. This series add all basic drivers which are useful in u-boot, like usb, sdxc, ethernet, spi, nand and serial. Building the u-boot requires external binary blob which is described in doc/board/mediatek/mt7621.rst Thanks, Weijie I applied v6 to u-boot-mips/next for the upcoming merge window. I needed to add some fixups to make CI happy. Could you check if the changes are okay, especially the Kconfig migration of CONFIG_SYS_NAND_U_BOOT_OFFS? https://source.denx.de/u-boot/custodians/u-boot-mips/-/commits/next/ https://source.denx.de/u-boot/custodians/u-boot-mips/-/pipelines/12637 Thanks, Daniel
Re: [PATCH v1 1/6] rockchip: block: add Rockchip IDB block device
Hi Xavier,
Thank you for your comments.
This driver in it's current form does not seek to comply with the MTD frame
work.
Goal is to write boot blocks to NAND the Rockchip way in a memory limited
environment (usbplug) and to get rid of all the closed source tools !!
In this particular case with MTD nand_flash_ids of no use and no bch settings
it does makes sense to load a whole frame work for only page_op's.
On 7/5/22 16:17, Xavier Drudis Ferran wrote:
>
> Thanks for your work.
>
> El Tue, Jul 05, 2022 at 03:04:15PM +0200, Johan Jonker deia:
>> From: Johan Jonker
>>
>> The Rockchip SoCs with a NAND as boot device need
>> a special Rockchip IDB block device to transfer the data
>> from the rockusb gadget to the NAND driver.
>>
>
> Sorry for the fast browsing, lack of experience and possibly wrong and
> noisy comment (I'm no U-Boot expert), but if you have patience for my
> curiosity... This isn't a review, I haven't read it all, just some
> small parts.
>
>> diff --git a/arch/arm/mach-rockchip/rockchip_idb.c
>> b/arch/arm/mach-rockchip/rockchip_idb.c
>> new file mode 100644
>> index ..6243131d
>> --- /dev/null
>> +++ b/arch/arm/mach-rockchip/rockchip_idb.c
> [...]
>> +struct NandParaInfo {
>> +u8 id_bytes;
>> +u8 nand_id[6];
>> +u8 vendor;
>> +u8 die_per_chip;
>> +u8 sec_per_page;
>> +u16 page_per_blk;
>> +u8 cell;
>> +u8 plane_per_die;
>> +u16 blk_per_plane;
>> +u16 operation_opt;
>> +u8 lsb_mode;
>> +u8 read_retry_mode;
>> +u8 ecc_bits;
>> +u8 access_freq;
>> +u8 opt_mode;
>> +u8 die_gap;
>> +u8 bad_block_mode;
>> +u8 multi_plane_mode;
>> +u8 slc_mode;
>> +u8 reserved[5];
>> +};
>> +
>
> Is part of this info already represented in
> nand_flash_dev in include/linux/mtd/rawnand.h ?
See answer below.
>
> And is it worth merging somehow ?
> Or should
> this be synced to something external and the
> .h file I mentioned be synced to linux, so merging
> would be more trouble than it is worth ?
This is a structure used by the manufacturer tools, ko modules and usbplugs.
For now this is only used here. If more users appear a .h file might be better.
>
>> +
>> +u16 random_seed[] = {
Although Linux rockchip-nand-controller.c and U-boot rockchip_nfc.c don't have
it,
on MK808 with "H27UCG8T2ATR-BC" it has a NAND_NEED_SCRAMBLING flag.
In order to read anything written by a Rockchip tools after/beyond the boot
blocks.
Not sure how to enable/disable this? With a DT property? PLease advice!
rockchip,enable-randomizer ???
For writing boot blocks only it's not needed for now.
Please advice on whether to keep or remove the randomizer? Thanks!
{"H27UCG8T2ATR-BC 64G 3.3V 8-bit",
{ .id = {0xad, 0xde, 0x94, 0xda, 0x74, 0xc4} },
SZ_8K, SZ_8K, SZ_2M, NAND_NEED_SCRAMBLING, 6, 640,
NAND_ECC_INFO(40, SZ_1K)},
>> +0x576a, 0x05e8, 0x629d, 0x45a3,
>> +0x649c, 0x4bf0, 0x2342, 0x272e,
>> +0x7358, 0x4ff3, 0x73ec, 0x5f70,
> [...]
>> +0x3b2e, 0x7ec7, 0x4fd2, 0x5d28,
>> +0x751f, 0x3ef8, 0x39b1, 0x4e49,
>> +0x746b, 0x6ef6, 0x44be, 0x6db7,
>> +};
>
> Where does this come from ? Is it copyrightable ? If so, is it
> licensed ? fair use ? Does it need to be synced every so often with
> some external source ?
random_seed is a constant value for Rockchip only. See:
https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/rk_nand/rk_ftl_arm_v7.S#L25550
GPL-2.0+
>
>> +
>> +struct NandParaInfo NandFlashParaTbl[] = {
https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/rk_nand/rk_ftl_arm_v7.S#L25936
GPL-2.0+
>> +{6, {0x2c, 0x64, 0x44, 0x4b, 0xa9, 0x00}, 4, 1, 16, 256, 2, 2, 2048,
>> 0x01df, 3, 17, 40, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
>> +{6, {0x2c, 0x44, 0x44, 0x4b, 0xa9, 0x00}, 4, 1, 16, 256, 2, 2, 1064,
>> 0x01df, 3, 17, 40, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
>> +{6, {0x2c, 0x68, 0x04, 0x4a, 0xa9, 0x00}, 4, 1, 8, 256, 2, 2, 2048,
>> 0x011f, 1, 0, 24, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
> [...]
>> +{6, {0x98, 0xde, 0x94, 0x82, 0x76, 0x56}, 1, 1, 16, 256, 2, 2, 2062,
>> 0x05d1, 1, 33, 40, 32, 2, 1, 1, 0, 0, {0, 0, 0, 0, 0}},
> [...]
>> +{6, {0xec, 0xd5, 0x94, 0x76, 0x54, 0x43}, 0, 1, 16, 128, 2, 2, 1038,
>> 0x0119, 2, 0, 24, 36, 3, 1, 3, 0, 0, {0, 0, 0, 0, 0}},
>> +{6, {0xec, 0xd7, 0x14, 0x76, 0x54, 0xc2}, 0, 1, 16, 128, 2, 2, 2076,
>> 0x0491, 2, 0, 24, 40, 3, 1, 3, 0, 0, {0, 0, 0, 0, 0}},
>> +{6, {0xec, 0xde, 0x94, 0xc3, 0xa4, 0xca}, 0, 1, 32, 792, 2, 1, 688,
>> 0x04c1, 11, 50, 40, 32, 3, 1, 1, 0, 1, {0, 0, 0, 0, 0}},
>> +};
>> +
>
> Is this info partially duplicated in drivers/mtd/nand/raw/nand_ids.c ?
> Should it be merged and this added there somehow ? It seems to have
> more data, but I don't know if some items are deductible from others.
Reasons not to use nand_ids.c:
1:
>From the NandFlashParaTbl array only "4" NAND nand_flash_ids types
Re: [PATCH] arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on DHCOM
Hi,
On 6/30/22 16:19, Johann Neuhauser wrote:
PA13 and PA14 are used for USB power control and can't be used
to enforce fastboot or stm32prog mode by pressing a button.
Defining CONFIG_FASTBOOT/CONFIG_CMD_STM32PROG without this patch applied
results in fastboot/stm32prog always starting, because PA13/PA14 are always
low during boot. So drop the wrong trigger gpios definitions.
Signed-off-by: Johann Neuhauser
---
arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
index d73967ac1b5d..ee747a52bb7c 100644
--- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
@@ -27,8 +27,6 @@
config {
u-boot,boot-led = "heartbeat";
u-boot,error-led = "error";
- st,fastboot-gpios = < 13 GPIO_ACTIVE_LOW>;
- st,stm32prog-gpios = < 14 GPIO_ACTIVE_LOW>;
dh,som-coding-gpios = < 12 0>, < 13 0>, < 15
0>;
dh,ddr3-coding-gpios = < 6 0>, < 7 0>;
};
The support of these buttons GPIO A13 and A14 have be done for ST boards
EVx and DKx;
it is an internal request for Android support on top of OpenSTLinux.
and make no sense on DHCOM STM32MP15
USB_PWR_STAT USB Host over current indicator (active low) 174 I PA14 -
USB_PWR_EN USB Host power enable signal (active low) 176 O PA13 -
moreover, if you never use these properies "st,fastboot-gpios" and
"st,stm32prog-gpios" on DH boards,
you can also clean the code in board/dhelectronics/dh_stm32mp1/board.c,
board_key_check() can be removed.
=> it is called board_init()
This code was initially copied from 'board/st/stm32mp1/stm32mp1.c'
but after your patch I think it is not needed.
Anyway for this device tree patch
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [ANN] U-Boot v2022.01-rc3 released
On 7/6/22 10:47, Tom Rini wrote: On Wed, Jul 06, 2022 at 10:31:41AM -0400, Jesse Taube wrote: On 11/30/21 14:36, Tom Rini wrote: On Mon, Nov 29, 2021 at 09:35:52PM -0500, Jesse Taube wrote: On 11/29/21 11:28, Tom Rini wrote: Hey all, It's been two weeks since v2022.01-rc2, so here's -rc3. To repeat what I said with -rc2, we've enabled issue tracking on our gitlab instance. You can sign up and then be able to file issues at: https://source.denx.de/groups/u-boot/-/issues This is intended for everyone to be able to use, both custodians for their own needs (you can see for example Heinrich has filed something for UEFI and LMB) as well as users to just report bugs so they don't feel like they're lost in the mailing list. As noted with the last release, the -next branch is open and I'll sync in -rc3 shortly. Please feel free to get a PR ready now if you're able. In terms of a changelog, git log --merges v2022.01-rc2..v2022.01-rc3 contains what I've pulled but as always, better PR messages and tags will provide better results here. So we're now looking at regular releases every other Monday, and with final release on January 10th, 2022. Thanks all! Hey tom, Thank you for the update as always! I have a question about a recent commit, I hope its okay to ask here. In commit cd82f199852d88218e1f17f5ec07cdd9112a89c4 In arch/arm/lib/relocate.S:81 on my SBC it returns an invalid value. My soc is Thumb2 but the instruction `adr r3, relocate_code` assembles to `subw r3, pc, #3` which is not 32bit aligned. If i change the instruction to `adr.w r3, relocate_code` it evaluates to `subw r3, pc, #4`, which is. There is a slight problem as it seems to work fine on my laptop using Debian bullseye, but on my Desktop where I found this I'm running sid. They are both gcc-10. I have yet to find a way to consistently replicate it. What are your thoughts of this? It sounds like you have enough details here to file a bug with Debian and see where that leads. Sorry for replying to old messages but the bug has appeared again in a separate case the bug seems to be introduced in https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d3e52e120b68bf19552743fbc078e0a759f48cb7 The test code is as follows ``` .syntax unified .global bug; .align 4 bug: adr r3, bug .size bug, .-bug .type bug 2; // This changes offset from 4 to 3 in include/linux/linkage.h:ENDPROC //arm-linux-gnueabi-as -march=armv7-m -c -o bug.o bug.S && arm-linux-gnueabi-objdump --disassemble=bug bug.o ``` Releases >2.37 have this issue and causes some arm platforms in u-boot at /arch/arm/lib/relocate.S:81 adr r3, relocate_code I'm wondering if there should be a mitigation for this till binutils is patched. Thanks for being persistent on this. What would a mitigation look like? Other people have suggested to use `subw r3, pc, #4` and ifdef for different variants. We could also do `adr.w`, what do you recommend. Unfortunately I'm not very familiar with arm asm so I was just putting it out there because many here know more. I'll continue to look into fixes for u-boot. And look into fixes for binutils as 2.37 is now in buildroot and other tool and distros. I'm not sure if line 81 is the only one that is affected but if it is then its a much easier fix than every adr instruction. Thanks, Jesse
[PATCH 2/2] ARM: dts: stm32mp13: add SCMI nodes
Add the node for SCMI firmware with the associated reserved memory nodes
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32mp13-u-boot.dtsi | 20 +++
arch/arm/dts/stm32mp131.dtsi | 31 ++
2 files changed, 51 insertions(+)
diff --git a/arch/arm/dts/stm32mp13-u-boot.dtsi
b/arch/arm/dts/stm32mp13-u-boot.dtsi
index adc7e67ee58..01552adb7c4 100644
--- a/arch/arm/dts/stm32mp13-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp13-u-boot.dtsi
@@ -90,6 +90,26 @@
u-boot,dm-pre-reloc;
};
+ {
+ u-boot,dm-pre-reloc;
+};
+
+_clk {
+ u-boot,dm-pre-reloc;
+};
+
+_reset {
+ u-boot,dm-pre-reloc;
+};
+
+_shm {
+ u-boot,dm-pre-reloc;
+};
+
+_sram {
+ u-boot,dm-pre-reloc;
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi
index 652743fd06e..8f7af65e3ed 100644
--- a/arch/arm/dts/stm32mp131.dtsi
+++ b/arch/arm/dts/stm32mp131.dtsi
@@ -27,11 +27,42 @@
interrupt-parent = <>;
};
+ scmi_sram: sram@2000 {
+ compatible = "mmio-sram";
+ reg = <0x2000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x2000 0x1000>;
+
+ scmi_shm: scmi_shm@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0 0x80>;
+ };
+ };
+
firmware {
optee: optee {
method = "smc";
compatible = "linaro,optee-tz";
};
+
+ scmi: scmi {
+ compatible = "linaro,scmi-optee";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ linaro,optee-channel-id = <0>;
+ shmem = <_shm>;
+
+ scmi_clk: protocol@14 {
+ reg = <0x14>;
+ #clock-cells = <1>;
+ };
+
+ scmi_reset: protocol@16 {
+ reg = <0x16>;
+ #reset-cells = <1>;
+ };
+ };
};
clocks {
--
2.25.1
[PATCH 1/2] ARM: dts: stm32mp13: add OP-TEE nodes
Add the node for OP-TEE firmware with the associated reserved memory nodes
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32mp13-u-boot.dtsi | 4
arch/arm/dts/stm32mp131.dtsi | 7 +++
arch/arm/dts/stm32mp135f-dk.dts| 11 +++
3 files changed, 22 insertions(+)
diff --git a/arch/arm/dts/stm32mp13-u-boot.dtsi
b/arch/arm/dts/stm32mp13-u-boot.dtsi
index 1b5b3586905..adc7e67ee58 100644
--- a/arch/arm/dts/stm32mp13-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp13-u-boot.dtsi
@@ -82,6 +82,10 @@
u-boot,dm-pre-reloc;
};
+ {
+ u-boot,dm-pre-reloc;
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi
index 950e172e455..652743fd06e 100644
--- a/arch/arm/dts/stm32mp131.dtsi
+++ b/arch/arm/dts/stm32mp131.dtsi
@@ -27,6 +27,13 @@
interrupt-parent = <>;
};
+ firmware {
+ optee: optee {
+ method = "smc";
+ compatible = "linaro,optee-tz";
+ };
+ };
+
clocks {
clk_axi: clk-axi {
#clock-cells = <0>;
diff --git a/arch/arm/dts/stm32mp135f-dk.dts b/arch/arm/dts/stm32mp135f-dk.dts
index ee100d108ea..31c510f976a 100644
--- a/arch/arm/dts/stm32mp135f-dk.dts
+++ b/arch/arm/dts/stm32mp135f-dk.dts
@@ -23,6 +23,17 @@
reg = <0xc000 0x2000>;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ optee@de00 {
+ reg = <0xde00 0x200>;
+ no-map;
+ };
+ };
+
vdd_sd: vdd-sd {
compatible = "regulator-fixed";
regulator-name = "vdd_sd";
--
2.25.1
Re: Pull request efi-2022-07-rc7
On Wed, Jul 06, 2022 at 12:03:24PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit 0cc846dafcf6f6270c6587d6fe79011834d6e49a: > > Prepare v2022.07-rc6 (2022-07-04 08:18:33 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2022-07-rc7 > > for you to fetch changes up to 8fb9dbdea716ab764c7a3c544569f903cbfdd744: > > test/py: efi_secboot: add a test for a forged signed image > (2022-07-05 14:37:16 +0200) > > Gitlab-CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/12623 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/17] Convert CONFIG_FSL_FIXED_MMC_LOCATION et al to Kconfig
On Mon, Jun 20, 2022 at 08:07:42AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_FSL_FIXED_MMC_LOCATION >CONFIG_ESDHC_HC_BLK_ADDR > > Signed-off-by: Tom Rini For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] arch/Kconfig.nxp: Re-organize slightly
On Fri, Jun 17, 2022 at 04:24:31PM -0400, Tom Rini wrote: > Make all of the CHAIN_OF_TRUST options be under a single menu and add a > comment for the rest, so the resulting config file reads more clearly. > Remove duplicate CHAIN_OF_TRUST options from > board/congatec/common/Kconfig. Remove duplicate NXP_ESBC config > questions and move to arch/Kconfig.nxp. > > Signed-off-by: Tom Rini For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/8] Convert CONFIG_EXTRA_CLOCK to Kconfig
On Thu, Jun 16, 2022 at 02:04:33PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_EXTRA_CLOCK > > Signed-off-by: Tom Rini For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/13] Convert CONFIG_DW_ALTDESCRIPTOR to Kconfig
On Wed, Jun 15, 2022 at 12:03:43PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_DW_ALTDESCRIPTOR > > Signed-off-by: Tom Rini For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
RE: [RFC] Proposed location to host the firmware handoff specification.
Hi Varun, The intent is for the proposed location (a new repository hosted in tf.org) to be used to review proposed changes to this spec. The details of the contribution and review process will be debated in the ML once we reach consensus on the hosting location. Regards, Jose > -Original Message- > From: Varun Wadekar > Sent: 06 July 2022 12:58 > To: Jose Marinho ; Simon Glass > ; Rob Herring > Cc: t...@lists.trustedfirmware.org; u-boot@lists.denx.de; boot- > architect...@lists.linaro.org; François Ozog ; > Manish Pandey2 ; Joanna Farley > ; Ilias Apalodimas ; > Matteo Carlini ; Dan Handley > ; Harb Abdulhamid > (h...@amperecomputing.com) ; Samer El- > Haj-Mahmoud ; nd > Subject: RE: [RFC] Proposed location to host the firmware handoff > specification. > > Hi, > > My concern with a standalone gitlab project is that it might be treated as an > experiment by the wider community and be neglected. Do we have any > gitlab projects (tf.org or otherwise) that have some "official" value? > > @Jose, do you see the location getting used for all future spec reviews? If > yes, then the gitlab project will acquire some legitimacy over time and we can > start with it now. But if we see this as a one off, then I would prefer the > spec > being hosted on tf.org. > > For the actual mechanics, I prefer reviewing docs and later updates as > fragments instead of looking at the file and a separate changelog. So a > platform (gerrit, gitlab, etc) that facilitates the approach would be helpful > IMO. > > -Varun > > -Original Message- > From: Jose Marinho via TF-A > Sent: Wednesday, 6 July 2022 11:50 AM > To: Simon Glass ; Rob Herring > Cc: t...@lists.trustedfirmware.org; u-boot@lists.denx.de; boot- > architect...@lists.linaro.org; François Ozog ; > Manish Pandey2 ; Joanna Farley > ; Ilias Apalodimas ; > Matteo Carlini ; Dan Handley > ; Harb Abdulhamid > (h...@amperecomputing.com) ; Samer El- > Haj-Mahmoud ; nd > Subject: [TF-A] Re: [RFC] Proposed location to host the firmware handoff > specification. > > External email: Use caution opening links or attachments > > > Hi All, > > > -Original Message- > > From: Simon Glass > > Sent: 06 July 2022 09:34 > > To: Rob Herring > > Cc: Jose Marinho ; > > t...@lists.trustedfirmware.org; u-boot@lists.denx.de; > > boot-architect...@lists.linaro.org; François Ozog > > ; Manish Pandey2 > ; > > Joanna Farley ; Ilias Apalodimas > > ; Matteo Carlini > > ; Dan Handley ; Harb > > Abdulhamid > > (h...@amperecomputing.com) ; Samer > El- > > Haj-Mahmoud ; nd > > Subject: Re: [RFC] Proposed location to host the firmware handoff > > specification. > > > > Hi Rob, > > > > On Tue, 5 Jul 2022 at 11:27, Rob Herring wrote: > > > > > > On Tue, Jul 5, 2022 at 10:37 AM Simon Glass wrote: > > > > > > > > Hi Rob, > > > > > > > > On Tue, 5 Jul 2022 at 09:24, Rob Herring wrote: > > > > > > > > > > On Thu, Jun 30, 2022 at 3:24 AM Simon Glass > > wrote: > > > > > > > > > > > > Hi Jose, > > > > > > > > > > > > I don't think this is correct. TF-A is a project that aims to > > > > > > replace U-Boot SPL (and perhaps other components) with more > > > > > > closed firmware, e.g. the permissive license. > > > > > > > > > > > > This spec needs to be in a neutral place, not captive of one > > > > > > project. > > > > > > > > > > > > Given its close relationship to device tree, I suggest > > > > > > github.com/devicetree-org > > > > > > > > > > The only relationship to DT I see is DT is a payload as is ACPI. > > > > > So I don't think dt.org is the right place. > > > > > > > > Actually I was about to email you about this. Here's how I see it. > > > > > > > > DT is a base structure to allow self-describing data to be stored. > > > > This is in contrast with ACPI where there is just a header, but it > > > > is not possible to read the data without specific parsing code for > > > > the particular table types. Let's ignore ACPI for this discussion. > > > > > > > > Unfortunately DT has an overhead and is too expensive for early > > > > firmware use. It takes 3-4KB of code for libfdt as well as extra > > > > code and data to read properties, etc. > > > > > > > > Transfer List aims to bridge the gap, allowing simple C structures > > > > to be put into a tagged data structure. The intention is that > > > > anything more complex than that would use DT. > > > > > > > > So there is at least some relationship: simple stuff = Transfer > > > > list, complex stuff = DT. > > > > > > That's a stretch IMO. Perhaps if this was a new output (DTB) format > > > for easier parsing, I'd agree. It's related to DT only as much as > > > any other data passed between 2 boot components (remember > ATAGS?). > > > > Yes it is a stretch. I'm just making the case. > > > > > > > > > The Transfer List spec specifies the data format for each entry > > > > type (the analog to the schema). The DT provides the format and > > > > schema for more complicated stuff. > > > > > > > > We could perhaps put it in
Re: [ANN] U-Boot v2022.01-rc3 released
On Wed, Jul 06, 2022 at 10:31:41AM -0400, Jesse Taube wrote: > > > On 11/30/21 14:36, Tom Rini wrote: > > On Mon, Nov 29, 2021 at 09:35:52PM -0500, Jesse Taube wrote: > > > > > > > > > On 11/29/21 11:28, Tom Rini wrote: > > > > Hey all, > > > > > > > > It's been two weeks since v2022.01-rc2, so here's -rc3. > > > > > > > > To repeat what I said with -rc2, we've enabled issue tracking on our > > > > gitlab instance. You can sign up and then be able to file issues at: > > > > https://source.denx.de/groups/u-boot/-/issues > > > > > > > > This is intended for everyone to be able to use, both custodians for > > > > their own needs (you can see for example Heinrich has filed something > > > > for UEFI and LMB) as well as users to just report bugs so they don't > > > > feel like they're lost in the mailing list. > > > > > > > > As noted with the last release, the -next branch is open and I'll sync > > > > in -rc3 shortly. Please feel free to get a PR ready now if you're able. > > > > > > > > In terms of a changelog, > > > > git log --merges v2022.01-rc2..v2022.01-rc3 > > > > contains what I've pulled but as always, better PR messages and tags > > > > will provide better results here. > > > > > > > > So we're now looking at regular releases every other Monday, and with > > > > final release on January 10th, 2022. Thanks all! > > > > > > > Hey tom, > > > > > > Thank you for the update as always! > > > > > > I have a question about a recent commit, I hope its okay to ask here. > > > In commit cd82f199852d88218e1f17f5ec07cdd9112a89c4 > > > In arch/arm/lib/relocate.S:81 on my SBC it returns an invalid value. > > > My soc is Thumb2 but the instruction `adr r3, relocate_code` > > > assembles to `subw r3, pc, #3` which is not 32bit aligned. If i change the > > > instruction to `adr.w r3, relocate_code` it evaluates to `subw r3, pc, > > > #4`, > > > which is. > > > > > > There is a slight problem as it seems to work fine on my laptop using > > > Debian > > > bullseye, but on my Desktop where I found this I'm running sid. > > > They are both gcc-10. I have yet to find a way to consistently replicate > > > it. > > > > > > What are your thoughts of this? > > > > It sounds like you have enough details here to file a bug with Debian > > and see where that leads. > > > Sorry for replying to old messages but the bug has appeared again in a > separate case the bug seems to be introduced in > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d3e52e120b68bf19552743fbc078e0a759f48cb7 > > The test code is as follows > ``` > .syntax unified > > .global bug; > > .align 4 > > bug: > > adr r3, bug > > .size bug, .-bug > > .type bug 2; // This changes offset from 4 to 3 in > include/linux/linkage.h:ENDPROC > //arm-linux-gnueabi-as -march=armv7-m -c -o bug.o bug.S && > arm-linux-gnueabi-objdump --disassemble=bug bug.o > ``` > Releases >2.37 have this issue and causes some arm platforms in u-boot at > /arch/arm/lib/relocate.S:81 adr r3, relocate_code > > I'm wondering if there should be a mitigation for this till binutils is > patched. Thanks for being persistent on this. What would a mitigation look like? -- Tom signature.asc Description: PGP signature
Re: [ANN] U-Boot v2022.01-rc3 released
On 11/30/21 14:36, Tom Rini wrote: On Mon, Nov 29, 2021 at 09:35:52PM -0500, Jesse Taube wrote: On 11/29/21 11:28, Tom Rini wrote: Hey all, It's been two weeks since v2022.01-rc2, so here's -rc3. To repeat what I said with -rc2, we've enabled issue tracking on our gitlab instance. You can sign up and then be able to file issues at: https://source.denx.de/groups/u-boot/-/issues This is intended for everyone to be able to use, both custodians for their own needs (you can see for example Heinrich has filed something for UEFI and LMB) as well as users to just report bugs so they don't feel like they're lost in the mailing list. As noted with the last release, the -next branch is open and I'll sync in -rc3 shortly. Please feel free to get a PR ready now if you're able. In terms of a changelog, git log --merges v2022.01-rc2..v2022.01-rc3 contains what I've pulled but as always, better PR messages and tags will provide better results here. So we're now looking at regular releases every other Monday, and with final release on January 10th, 2022. Thanks all! Hey tom, Thank you for the update as always! I have a question about a recent commit, I hope its okay to ask here. In commit cd82f199852d88218e1f17f5ec07cdd9112a89c4 In arch/arm/lib/relocate.S:81 on my SBC it returns an invalid value. My soc is Thumb2 but the instruction `adr r3, relocate_code` assembles to `subw r3, pc, #3` which is not 32bit aligned. If i change the instruction to `adr.w r3, relocate_code` it evaluates to `subw r3, pc, #4`, which is. There is a slight problem as it seems to work fine on my laptop using Debian bullseye, but on my Desktop where I found this I'm running sid. They are both gcc-10. I have yet to find a way to consistently replicate it. What are your thoughts of this? It sounds like you have enough details here to file a bug with Debian and see where that leads. Sorry for replying to old messages but the bug has appeared again in a separate case the bug seems to be introduced in https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d3e52e120b68bf19552743fbc078e0a759f48cb7 The test code is as follows ``` .syntax unified .global bug; .align 4 bug: adr r3, bug .size bug, .-bug .type bug 2; // This changes offset from 4 to 3 in include/linux/linkage.h:ENDPROC //arm-linux-gnueabi-as -march=armv7-m -c -o bug.o bug.S && arm-linux-gnueabi-objdump --disassemble=bug bug.o ``` Releases >2.37 have this issue and causes some arm platforms in u-boot at /arch/arm/lib/relocate.S:81 adr r3, relocate_code I'm wondering if there should be a mitigation for this till binutils is patched. Thanks, Jesse
Re: [PATCH] efi_loader: Allow overlapped extra data for PE hashing
On Mon, 2022-06-27 at 16:32 +0200, Heinrich Schuchardt wrote:
> On 6/24/22 07:32, Su, Bao Cheng wrote:
> > During PE hashing, when holes exists between sections, the extra
> > data
> > calculated could be a dupulicated region of the last section.
> >
> > Such PE image with holes existing between sections may contain the
> > symbol table for the kernel, for example.
> >
> > The Authenticode_PE spec does not rule how to deal with such
> > scenario,
> > however, other tools such as pesign and sbsign both have the
> > overlapped
> > regions hashed. And EDK2 hash the overlapped area as well.
> >
> > Signed-off-by: Baocheng Su
> > ---
> > lib/efi_loader/efi_image_loader.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_image_loader.c
> > b/lib/efi_loader/efi_image_loader.c
> > index 9611398885..d85fb6ba08 100644
> > --- a/lib/efi_loader/efi_image_loader.c
> > +++ b/lib/efi_loader/efi_image_loader.c
> > @@ -481,7 +481,7 @@ bool efi_image_parse(void *efi, size_t len,
> > struct
> > efi_image_regions **regp,
> > EFI_PRINT("extra data for hash: %zu\n",
> > len - (bytes_hashed + authsz));
> > efi_image_region_add(regs, efi + bytes_hashed,
> > - efi + len - authsz, 0);
> > + efi + len - authsz, 1);
> > }
> >
> > /* Return Certificates Table */
>
> Let us consider the case that the sum of gaps between sections is
> greater than the size of the last section N.
>
> start[N] > efi + bytes_hashed
> end[N] < efi + len - authsz
>
> Sbsigntool and EDK II sort regions by start address before adding the
> extra data region and will accept this situation.
>
> U-Boot's efi_image_region_add(nocheck = 1) will throw an error "%s:
> new
> region already part of another\n".
>
This is the original code of efi_image_region_add:
```
for (i = 0; i < regs->num; i++) {
reg = >reg[i];
if (nocheck)
continue;
/* new data after registered region */
if (start >= reg->data + reg->size)
continue;
/* new data preceding registered region */
if (end <= reg->data) {
for (j = regs->num - 1; j >= i; j--)
memcpy(>reg[j + 1],
>reg[j],
sizeof(*reg));
break;
}
/* new data overlapping registered region */
EFI_PRINT("%s: new region already part of another\n",
__func__);
return EFI_INVALID_PARAMETER;
}
```
Notice the `if (nocheck) continue;`, I would not say the `new region
already part of another` be executed.
- Baocheng
> It seems that this patch is not a complete solution.
>
> Best regards
>
> Heinrich
Re: [PATCH v6 7/7] test: rng: Add a UT testcase for the rng command
On Mon, Jul 04, 2022 at 07:04:44PM +0530, Sughosh Ganu wrote:
> The 'rng' command dumps a number of random bytes on the console. Add a
> set of tests for the 'rng' command. The test function performs basic
> sanity testing of the command.
>
> Since a unit test is being added for the command, enable it by default
> in the sandbox platforms.
>
> Reviewed-by: Simon Glass
> Signed-off-by: Sughosh Ganu
> ---
> cmd/Kconfig | 1 +
> test/dm/rng.c | 29 +
> 2 files changed, 30 insertions(+)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 09193b61b9..eee5d44348 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1916,6 +1916,7 @@ config CMD_GETTIME
> config CMD_RNG
> bool "rng command"
> depends on DM_RNG
> + default y if SANDBOX
> select HEXDUMP
> help
> Print bytes from the hardware random number generator.
> diff --git a/test/dm/rng.c b/test/dm/rng.c
> index 5b34c93ed6..6d1f68848d 100644
> --- a/test/dm/rng.c
> +++ b/test/dm/rng.c
> @@ -25,3 +25,32 @@ static int dm_test_rng_read(struct unit_test_state *uts)
> return 0;
> }
> DM_TEST(dm_test_rng_read, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
> +
> +/* Test the rng command */
> +static int dm_test_rng_cmd(struct unit_test_state *uts)
> +{
> + struct udevice *dev;
> +
> + ut_assertok(uclass_get_device(UCLASS_RNG, 0, ));
> + ut_assertnonnull(dev);
> +
> + ut_assertok(console_record_reset_enable());
> +
> + run_command("rng", 0);
> + ut_assert_nextlinen(":");
> + ut_assert_nextlinen("0010:");
> + ut_assert_nextlinen("0020:");
> + ut_assert_nextlinen("0030:");
> + ut_assert_console_end();
> +
> + run_command("rng 0 10", 0);
> + ut_assert_nextlinen(":");
> + ut_assert_console_end();
> +
> + run_command("rng 20", 0);
> + ut_assert_nextlinen("No RNG device");
> + ut_assert_console_end();
> +
> + return 0;
> +}
> +DM_TEST(dm_test_rng_cmd, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT |
> UT_TESTF_CONSOLE_REC);
> --
> 2.25.1
>
Acked-by: Ilias Apalodimas
Re: [PATCH v6 5/7] cmd: rng: Use a statically allocated array for random bytes
On Mon, Jul 04, 2022 at 07:04:42PM +0530, Sughosh Ganu wrote:
> Use a statically allocated buffer on stack instead of using malloc for
> reading the random bytes. Using a local array is faster than
> allocating heap memory on every initiation of the command.
>
> Signed-off-by: Sughosh Ganu
> ---
> Changes since V5: None
>
> cmd/rng.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/cmd/rng.c b/cmd/rng.c
> index 2ddf27545f..81a23964b8 100644
> --- a/cmd/rng.c
> +++ b/cmd/rng.c
> @@ -14,9 +14,9 @@
> static int do_rng(struct cmd_tbl *cmdtp, int flag, int argc, char *const
> argv[])
> {
> size_t n;
> - struct udevice *dev;
> - void *buf;
> + u8 buf[64];
> int devnum;
> + struct udevice *dev;
> int ret = CMD_RET_SUCCESS;
>
> switch (argc) {
> @@ -41,11 +41,10 @@ static int do_rng(struct cmd_tbl *cmdtp, int flag, int
> argc, char *const argv[])
> return CMD_RET_FAILURE;
> }
>
> - buf = malloc(n);
> - if (!buf) {
> - printf("Out of memory\n");
> - return CMD_RET_FAILURE;
> - }
> + if (!n)
> + return 0;
> +
> + n = min(n, sizeof(buf));
>
> if (dm_rng_read(dev, buf, n)) {
> printf("Reading RNG failed\n");
> @@ -54,15 +53,13 @@ static int do_rng(struct cmd_tbl *cmdtp, int flag, int
> argc, char *const argv[])
> print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, n);
> }
>
> - free(buf);
> -
> return ret;
> }
>
> #ifdef CONFIG_SYS_LONGHELP
> static char rng_help_text[] =
> "[dev [n]]\n"
> - " - print n random bytes read from dev\n";
> + " - print n random bytes(max 64) read from dev\n";
> #endif
>
> U_BOOT_CMD(
> --
> 2.25.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH v6 2/7] tpm: rng: Add driver model interface for TPM RNG device
On Mon, Jul 04, 2022 at 07:04:39PM +0530, Sughosh Ganu wrote:
> The TPM device has a builtin random number generator(RNG)
> functionality. Expose the RNG functions of the TPM device to the
> driver model so that they can be used by the EFI_RNG_PROTOCOL if the
> protocol is installed.
>
> Also change the function arguments and return type of the random
> number functions to comply with the driver model api.
>
> Signed-off-by: Sughosh Ganu
> ---
> Changes since V5:
> * Use the dev_get_parent() interface for getting the TPM device when
> calling the tpm_get_random() function
>
> drivers/rng/Kconfig | 11 +++
> drivers/rng/Makefile | 1 +
> drivers/rng/tpm_rng.c | 23 +++
> lib/Kconfig | 1 +
> lib/tpm-v1.c | 13 +++--
> lib/tpm-v2.c | 6 +++---
> lib/tpm_api.c | 6 +++---
> 7 files changed, 49 insertions(+), 12 deletions(-)
> create mode 100644 drivers/rng/tpm_rng.c
>
> diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> index c10f7d345b..67c65311c7 100644
> --- a/drivers/rng/Kconfig
> +++ b/drivers/rng/Kconfig
> @@ -58,4 +58,15 @@ config RNG_IPROC200
> depends on DM_RNG
> help
> Enable random number generator for RPI4.
> +
> +config TPM_RNG
> + bool "Enable random number generator on TPM device"
> + depends on TPM
> + default y
> + help
> + The TPM device has an inbuilt random number generator
> + functionality. Enable random number generator on TPM
> + devices.
Maybe we discussed this on a previous version, but why do we want to have
this as a config option? Code size? A TPM will always be able to generate
a random number. Couldn't we compile this based on an existing TPM Kconfig
option?
> +
> +
> endif
> diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> index 435b3b965a..e4ca9c4149 100644
> --- a/drivers/rng/Makefile
> +++ b/drivers/rng/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_RNG_OPTEE) += optee_rng.o
> obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
> obj-$(CONFIG_RNG_ROCKCHIP) += rockchip_rng.o
> obj-$(CONFIG_RNG_IPROC200) += iproc_rng200.o
> +obj-$(CONFIG_TPM_RNG) += tpm_rng.o
> diff --git a/drivers/rng/tpm_rng.c b/drivers/rng/tpm_rng.c
> new file mode 100644
> index 00..1a5e9e2e4b
> --- /dev/null
> +++ b/drivers/rng/tpm_rng.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2022, Linaro Limited
> + */
> +
> +#include
> +#include
> +#include
> +
> +static int rng_tpm_random_read(struct udevice *dev, void *data, size_t count)
> +{
> + return tpm_get_random(dev_get_parent(dev), data, count);
> +}
> +
> +static const struct dm_rng_ops tpm_rng_ops = {
> + .read = rng_tpm_random_read,
> +};
> +
> +U_BOOT_DRIVER(tpm_rng) = {
> + .name = "tpm-rng",
> + .id = UCLASS_RNG,
> + .ops= _rng_ops,
> +};
> diff --git a/lib/Kconfig b/lib/Kconfig
> index acc0ac081a..17efaa4c80 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -358,6 +358,7 @@ source lib/crypt/Kconfig
> config TPM
> bool "Trusted Platform Module (TPM) Support"
> depends on DM
> + imply DM_RNG
> help
> This enables support for TPMs which can be used to provide security
> features for your board. The TPM can be connected via LPC or I2C
> diff --git a/lib/tpm-v1.c b/lib/tpm-v1.c
> index 22a769c587..f7091e5bc7 100644
> --- a/lib/tpm-v1.c
> +++ b/lib/tpm-v1.c
> @@ -9,12 +9,13 @@
> #include
> #include
> #include
> -#include
> -#include
> #include
> #include
> #include "tpm-utils.h"
>
> +#include
> +#include
> +
> #ifdef CONFIG_TPM_AUTH_SESSIONS
>
> #ifndef CONFIG_SHA1
> @@ -892,19 +893,19 @@ u32 tpm1_get_random(struct udevice *dev, void *data,
> u32 count)
> if (pack_byte_string(buf, sizeof(buf), "sd",
>0, command, sizeof(command),
>length_offset, this_bytes))
> - return TPM_LIB_ERROR;
> + return -EIO;
> err = tpm_sendrecv_command(dev, buf, response,
> _length);
> if (err)
> return err;
> if (unpack_byte_string(response, response_length, "d",
> data_size_offset, _size))
> - return TPM_LIB_ERROR;
> + return -EIO;
> if (data_size > count)
> - return TPM_LIB_ERROR;
> + return -EIO;
> if (unpack_byte_string(response, response_length, "s",
> data_offset, out, data_size))
> - return TPM_LIB_ERROR;
> + return -EIO;
>
> count -= data_size;
> out += data_size;
> diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> index 1bf627853a..abca9a14b0 100644
> --- a/lib/tpm-v2.c
> +++ b/lib/tpm-v2.c
> @@
[PATCH v2] toradex: tdx-cfg-block: add 0068 i.mx 8m mini sku
From: Philippe Schenker
Add new i.MX 8M Mini SKU to ConfigBlock handling.
0068: Verdin iMX8M Mini Quad 2GB WB IT No CAN
This SKU is identical to 0055 but without CAN. Mention this in the name
so those modules can be distinguished.
Signed-off-by: Philippe Schenker
Reviewed-by: Francesco Dolcini
---
Changes in v2:
- Added the define to is_wifi detection so the correct devicetree is
selected on boot.
- Shortened the name so the resulting string printed is no longer than
80 characters.
board/toradex/common/tdx-cfg-block.c| 13 -
board/toradex/common/tdx-cfg-block.h| 1 +
board/toradex/verdin-imx8mm/verdin-imx8mm.c | 3 ++-
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 6c8cf4592d..112e687ca6 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -145,6 +145,7 @@ const char * const toradex_modules[] = {
[65] = "Verdin iMX8M Plus QuadLite 1GB IT",
[66] = "Verdin iMX8M Plus Quad 8GB Wi-Fi / BT",
[67] = "Apalis iMX8 QuadMax 8GB Wi-Fi / BT IT",
+ [68] = "Verdin iMX8M Mini Quad 2GB WB IT No CAN",
};
const char * const toradex_carrier_boards[] = {
@@ -361,6 +362,7 @@ static int get_cfgblock_interactive(void)
char it = 'n';
char wb = 'n';
char mem8g = 'n';
+ char can = 'y';
int len = 0;
/* Unknown module by default */
@@ -387,6 +389,13 @@ static int get_cfgblock_interactive(void)
mem8g = console_buffer[0];
}
#endif
+#if defined(CONFIG_TARGET_VERDIN_IMX8MM)
+ if (is_cpu_type(MXC_CPU_IMX8MM) && (wb == 'y' || wb == 'Y')) {
+ sprintf(message, "Does your module have CAN? [y/N] ");
+ len = cli_readline(message);
+ can = console_buffer[0];
+ }
+#endif
#endif
soc = env_get("soc");
@@ -474,7 +483,9 @@ static int get_cfgblock_interactive(void)
else
tdx_hw_tag.prodid = VERDIN_IMX8MMDL;
} else if (is_cpu_type(MXC_CPU_IMX8MM)) {
- if (wb == 'y' || wb == 'Y')
+ if (can == 'n' || can == 'N')
+ tdx_hw_tag.prodid = VERDIN_IMX8MMQ_WIFI_BT_IT_NO_CAN;
+ else if (wb == 'y' || wb == 'Y')
tdx_hw_tag.prodid = VERDIN_IMX8MMQ_WIFI_BT_IT;
else
tdx_hw_tag.prodid = VERDIN_IMX8MMQ_IT;
diff --git a/board/toradex/common/tdx-cfg-block.h
b/board/toradex/common/tdx-cfg-block.h
index 43e662e41d..9697447158 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -88,6 +88,7 @@ enum {
VERDIN_IMX8MPQL_IT, /* 65 */
VERDIN_IMX8MPQ_8GB_WIFI_BT,
APALIS_IMX8QM_8GB_WIFI_BT_IT,
+ VERDIN_IMX8MMQ_WIFI_BT_IT_NO_CAN,
};
enum {
diff --git a/board/toradex/verdin-imx8mm/verdin-imx8mm.c
b/board/toradex/verdin-imx8mm/verdin-imx8mm.c
index c51c99b515..7597cd81f9 100644
--- a/board/toradex/verdin-imx8mm/verdin-imx8mm.c
+++ b/board/toradex/verdin-imx8mm/verdin-imx8mm.c
@@ -83,7 +83,8 @@ static void select_dt_from_module_version(void)
* device tree.
*/
is_wifi = (tdx_hw_tag.prodid == VERDIN_IMX8MMQ_WIFI_BT_IT) ||
- (tdx_hw_tag.prodid == VERDIN_IMX8MMDL_WIFI_BT_IT);
+ (tdx_hw_tag.prodid == VERDIN_IMX8MMDL_WIFI_BT_IT) ||
+ (tdx_hw_tag.prodid ==
VERDIN_IMX8MMQ_WIFI_BT_IT_NO_CAN);
}
switch (get_pcb_revision()) {
--
2.36.1
RE: [RFC] Proposed location to host the firmware handoff specification.
Hi, My concern with a standalone gitlab project is that it might be treated as an experiment by the wider community and be neglected. Do we have any gitlab projects (tf.org or otherwise) that have some "official" value? @Jose, do you see the location getting used for all future spec reviews? If yes, then the gitlab project will acquire some legitimacy over time and we can start with it now. But if we see this as a one off, then I would prefer the spec being hosted on tf.org. For the actual mechanics, I prefer reviewing docs and later updates as fragments instead of looking at the file and a separate changelog. So a platform (gerrit, gitlab, etc) that facilitates the approach would be helpful IMO. -Varun -Original Message- From: Jose Marinho via TF-A Sent: Wednesday, 6 July 2022 11:50 AM To: Simon Glass ; Rob Herring Cc: t...@lists.trustedfirmware.org; u-boot@lists.denx.de; boot-architect...@lists.linaro.org; François Ozog ; Manish Pandey2 ; Joanna Farley ; Ilias Apalodimas ; Matteo Carlini ; Dan Handley ; Harb Abdulhamid (h...@amperecomputing.com) ; Samer El-Haj-Mahmoud ; nd Subject: [TF-A] Re: [RFC] Proposed location to host the firmware handoff specification. External email: Use caution opening links or attachments Hi All, > -Original Message- > From: Simon Glass > Sent: 06 July 2022 09:34 > To: Rob Herring > Cc: Jose Marinho ; > t...@lists.trustedfirmware.org; u-boot@lists.denx.de; > boot-architect...@lists.linaro.org; François Ozog > ; Manish Pandey2 ; > Joanna Farley ; Ilias Apalodimas > ; Matteo Carlini > ; Dan Handley ; Harb > Abdulhamid > (h...@amperecomputing.com) ; Samer El- > Haj-Mahmoud ; nd > Subject: Re: [RFC] Proposed location to host the firmware handoff > specification. > > Hi Rob, > > On Tue, 5 Jul 2022 at 11:27, Rob Herring wrote: > > > > On Tue, Jul 5, 2022 at 10:37 AM Simon Glass wrote: > > > > > > Hi Rob, > > > > > > On Tue, 5 Jul 2022 at 09:24, Rob Herring wrote: > > > > > > > > On Thu, Jun 30, 2022 at 3:24 AM Simon Glass > wrote: > > > > > > > > > > Hi Jose, > > > > > > > > > > I don't think this is correct. TF-A is a project that aims to > > > > > replace U-Boot SPL (and perhaps other components) with more > > > > > closed firmware, e.g. the permissive license. > > > > > > > > > > This spec needs to be in a neutral place, not captive of one project. > > > > > > > > > > Given its close relationship to device tree, I suggest > > > > > github.com/devicetree-org > > > > > > > > The only relationship to DT I see is DT is a payload as is ACPI. > > > > So I don't think dt.org is the right place. > > > > > > Actually I was about to email you about this. Here's how I see it. > > > > > > DT is a base structure to allow self-describing data to be stored. > > > This is in contrast with ACPI where there is just a header, but it > > > is not possible to read the data without specific parsing code for > > > the particular table types. Let's ignore ACPI for this discussion. > > > > > > Unfortunately DT has an overhead and is too expensive for early > > > firmware use. It takes 3-4KB of code for libfdt as well as extra > > > code and data to read properties, etc. > > > > > > Transfer List aims to bridge the gap, allowing simple C structures > > > to be put into a tagged data structure. The intention is that > > > anything more complex than that would use DT. > > > > > > So there is at least some relationship: simple stuff = Transfer > > > list, complex stuff = DT. > > > > That's a stretch IMO. Perhaps if this was a new output (DTB) format > > for easier parsing, I'd agree. It's related to DT only as much as > > any other data passed between 2 boot components (remember ATAGS?). > > Yes it is a stretch. I'm just making the case. > > > > > > The Transfer List spec specifies the data format for each entry > > > type (the analog to the schema). The DT provides the format and > > > schema for more complicated stuff. > > > > > > We could perhaps put it in an entirely separate repo, but to me > > > there is a relationship with DT. > > > > It seems to me that TF is the main driver and user of this, so I > > don't see the issue with them hosting it at least to start as long > > as there's not barriers to contributions. It's just a namespace like > > devicetree-org. Personally, I'd be more concerned on what the source > > format is (I assume the plan is not to commit PDFs) and what the > > output generation is. GH has a lot of nice features to support that > > which we've used for the DT spec and EBBR. The default working plan is for the source format to be sphinx. Other alternatives/suggestions are welcome. The output generated should be html (pdf can be supported too for 0/negligible effort). This generation process can and will most likely evolve over time, depending on community direction/desire and the tools we have at our disposal. The process should be as automated as possible given any practical constraints .
[PATCH] console: Add option to keep it silent until env is loaded
Add a config-option which forces the console to stay silent until the
proper environment is loaded from flash.
This is important when the default environment does not silence the
console but no output must be printed when 'silent' is set in the flash
environment.
After the environment from flash is loaded, the console will be
silenced/unsilenced depending on it. If PRE_CONSOLE_BUFFER is also
used, the buffer will now be flushed if the console should not be
silenced.
Signed-off-by: Harald Seiler
---
common/Kconfig | 10 ++
common/console.c | 5 +
2 files changed, 15 insertions(+)
diff --git a/common/Kconfig b/common/Kconfig
index fdcf4536d0..506a4d6245 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -120,6 +120,16 @@ config SILENT_CONSOLE_UPDATE_ON_RELOC
(e.g. NAND). This option makes the value of the 'silent'
environment variable take effect at relocation.
+config SILENT_CONSOLE_UNTIL_ENV
+ bool "Keep console silent until environment is loaded"
+ depends on SILENT_CONSOLE
+ help
+ This option makes sure U-Boot will never use the console unless the
+ environment from flash does not contain the 'silent' variable. If
+ set, the console is kept silent until after the environment was
+ loaded. Use this in combination with PRE_CONSOLE_BUFFER to print out
+ earlier messages after loading the environment when allowed.
+
config PRE_CONSOLE_BUFFER
bool "Buffer characters before the console is available"
help
diff --git a/common/console.c b/common/console.c
index 0013d183ae..f0f5a9cf80 100644
--- a/common/console.c
+++ b/common/console.c
@@ -893,6 +893,11 @@ static bool console_update_silent(void)
if (!IS_ENABLED(CONFIG_SILENT_CONSOLE))
return false;
+ if (IS_ENABLED(CONFIG_SILENT_CONSOLE_UNTIL_ENV) && !(gd->flags &
GD_FLG_ENV_READY)) {
+ gd->flags |= GD_FLG_SILENT;
+ return false;
+ }
+
if (env_get("silent")) {
gd->flags |= GD_FLG_SILENT;
return false;
--
2.36.1
RE: [v4 03/12] spi: aspeed: Add ASPEED SPI controller driver
Hi Cédric, > -Original Message- > From: Cédric Le Goater > Sent: Monday, July 4, 2022 11:25 PM > Subject: Re: [v4 03/12] spi: aspeed: Add ASPEED SPI controller driver > > Hello Chin-Ting, > > On 7/3/22 10:47, Chin-Ting Kuo wrote: > > Hi Cédric, > > > > Thanks for the review. > > > >> -Original Message- > >> From: Cédric Le Goater > >> Sent: Friday, July 1, 2022 5:28 PM > >> To: Chin-Ting Kuo ; ChiaWei Wang > >> ; lu...@denx.de; sean...@gmail.com; > Ryan > >> Chen ; BMC-SW > ; > >> ja...@amarulasolutions.com; vigne...@ti.com; u-boot@lists.denx.de; > >> p.ya...@ti.com > >> Subject: Re: [v4 03/12] spi: aspeed: Add ASPEED SPI controller driver > >> > >> Hello Chin-Ting, > >> > >> On 5/24/22 07:56, Chin-Ting Kuo wrote: > >>> Add ASPEED BMC FMC/SPI memory controller driver with spi-mem > >>> interface for AST2500 and AST2600 platform. > >>> > >>> There are three SPI memory controllers embedded in an ASPEED SoC. > >>> - FMC: Named as Firmware Memory Controller. After AC on, MCU ROM > >>> fetches initial device boot image from FMC chip select(CS) 0. > >>> > >>> - SPI1: Play the role of a SPI Master controller. Or, there is a > >>> dedicated path for HOST(X86) to access its BIOS flash > mounted > >>> under BMC. spi-aspeed.c implements the control sequence > when > >>> SPI1 is a SPI master. > >>> > >>> - SPI2: It is a pure SPI flash controller. For most scenarios, flashes > >>> mounted under it are for pure storage purpose. > >>> > >>> ASPEED SPI controller supports 1-1-1, 1-1-2 and 1-1-4 SPI flash mode. > >>> Three types of command mode are supported, normal mode, command > >>> read/write mode and user mode. > >>> - Normal mode: Default mode. After power on, normal read command > 03h > >> or > >>> 13h is used to fetch boot image from SPI flash. > >>> - AST2500: Only 03h command can be used after > power > >> on > >>> or reset. > >>> - AST2600: If FMC04[6:4] is set, 13h command is > used, > >>> otherwise, 03h command. > >>> The address length is decided by FMC04[2:0]. > >>> > >>> - Command mode: SPI controller can send command and address > >>> automatically when CPU read/write the related > >> remapped > >>> or decoded address area. The command used by > this > >> mode > >>> can be configured by FMC10/14/18[23:16]. Also, > the > >>> address length is decided by FMC04[2:0]. This mode > >> will > >>> be implemented in the following patch series. > >>> > >>> - User mode: It is a traditional and pure SPI operation, where > >>>SPI transmission is controlled by CPU. It is the main > >>>mode in this patch. > >>> > >>> Each SPI controller in ASPEED SoC has its own decoded address mapping. > >>> Within each SPI controller decoded address, driver can assign a > >>> specific address region for each CS of a SPI controller. The decoded > >>> address cannot overlap to each other. With normal mode and command > >>> mode, the decoded address accessed by the CPU determines which CS is > >> active. > >>> When user mode is adopted, the CS decoded address is a FIFO, CPU can > >>> send/receive any SPI transmission by accessing the related decoded > >>> address for the target CS. > >>> > >>> Signed-off-by: Chin-Ting Kuo > >> > >> I would split the patch furthermore to ease reading. > > > > Okay, this will be update in the next version. > > > >>1 - Add basic support > >> > >>with default decoding ranges set for all possible CS, even > >>without a device. > >> > >>WE only have USER mode for now. So it's not important to > >>correctly set the ranges since we won't use them before > >>direct mapping is introduced. They should not overlap, > >>that's all. > >> > >>2 - decoding range adjustments > >> > >>On that topic, we might want to take the simple DT approach > >>with a "ranges" property defining the mapping windows of each > >>CE. I think it is safer than trying to compute perfect ranges > >>like on Linux. > >> > >>3 - clock settings > >> > >>That should simply be the property defined in the DT > >> > >> > >>> --- > >>> v2: Remove defconfig files from this patch. > >>> > >>>drivers/spi/Kconfig | 8 + > >>>drivers/spi/Makefile | 1 + > >>>drivers/spi/spi-aspeed.c | 822 > >> +++ > >>>3 files changed, 831 insertions(+) > >>>create mode 100644 drivers/spi/spi-aspeed.c > >>> > >>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index > >>> a1e515cb2b..a616294910 100644 > >>> --- a/drivers/spi/Kconfig > >>> +++ b/drivers/spi/Kconfig > >>> @@ -387,6 +387,14 @@ config SANDBOX_SPI > >>> }; > >>> }; > >>> > >>> +config SPI_ASPEED > >>>
[PATCH] spl: mmc: Use correct MMC device when loading image
When attempting to load images from multiple MMC devices in sequence,
spl_mmc_load() chooses the wrong device from the second attempt onwards.
The reason is that MMC initialization is only done on its first call and
spl_mmc_load() will then continue using this same device for all future
calls.
Fix this by checking the devnum of the "cached" device struct against
the one which is requested. If they match, use the cached one but if
they do not match, initialize the new device.
This fixes specifying multiple MMC devices in the SPL's boot order to
fall back when U-Boot Proper is corrupted or missing on the first
attempted MMC device.
Fixes: e1eb6ada4e38 ("spl: Make image loader infrastructure more universal")
Signed-off-by: Harald Seiler
---
common/spl/spl_mmc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index e1a7d25bd0..22c8a8097c 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -371,9 +371,11 @@ int spl_mmc_load(struct spl_image_info *spl_image,
u32 boot_mode;
int err = 0;
__maybe_unused int part = 0;
+ int mmc_dev;
- /* Perform peripheral init only once */
- if (!mmc) {
+ /* Perform peripheral init only once for an mmc device */
+ mmc_dev = spl_mmc_get_device_index(bootdev->boot_device);
+ if (!mmc || mmc->block_dev.devnum != mmc_dev) {
err = spl_mmc_find_device(, bootdev->boot_device);
if (err)
return err;
--
2.36.1
RE: [RFC] Proposed location to host the firmware handoff specification.
Hi All, > -Original Message- > From: Simon Glass > Sent: 06 July 2022 09:34 > To: Rob Herring > Cc: Jose Marinho ; t...@lists.trustedfirmware.org; > u-boot@lists.denx.de; boot-architect...@lists.linaro.org; François Ozog > ; Manish Pandey2 ; > Joanna Farley ; Ilias Apalodimas > ; Matteo Carlini ; > Dan Handley ; Harb Abdulhamid > (h...@amperecomputing.com) ; Samer El- > Haj-Mahmoud ; nd > Subject: Re: [RFC] Proposed location to host the firmware handoff > specification. > > Hi Rob, > > On Tue, 5 Jul 2022 at 11:27, Rob Herring wrote: > > > > On Tue, Jul 5, 2022 at 10:37 AM Simon Glass wrote: > > > > > > Hi Rob, > > > > > > On Tue, 5 Jul 2022 at 09:24, Rob Herring wrote: > > > > > > > > On Thu, Jun 30, 2022 at 3:24 AM Simon Glass > wrote: > > > > > > > > > > Hi Jose, > > > > > > > > > > I don't think this is correct. TF-A is a project that aims to > > > > > replace U-Boot SPL (and perhaps other components) with more > > > > > closed firmware, e.g. the permissive license. > > > > > > > > > > This spec needs to be in a neutral place, not captive of one project. > > > > > > > > > > Given its close relationship to device tree, I suggest > > > > > github.com/devicetree-org > > > > > > > > The only relationship to DT I see is DT is a payload as is ACPI. > > > > So I don't think dt.org is the right place. > > > > > > Actually I was about to email you about this. Here's how I see it. > > > > > > DT is a base structure to allow self-describing data to be stored. > > > This is in contrast with ACPI where there is just a header, but it > > > is not possible to read the data without specific parsing code for > > > the particular table types. Let's ignore ACPI for this discussion. > > > > > > Unfortunately DT has an overhead and is too expensive for early > > > firmware use. It takes 3-4KB of code for libfdt as well as extra > > > code and data to read properties, etc. > > > > > > Transfer List aims to bridge the gap, allowing simple C structures > > > to be put into a tagged data structure. The intention is that > > > anything more complex than that would use DT. > > > > > > So there is at least some relationship: simple stuff = Transfer > > > list, complex stuff = DT. > > > > That's a stretch IMO. Perhaps if this was a new output (DTB) format > > for easier parsing, I'd agree. It's related to DT only as much as any > > other data passed between 2 boot components (remember ATAGS?). > > Yes it is a stretch. I'm just making the case. > > > > > > The Transfer List spec specifies the data format for each entry type > > > (the analog to the schema). The DT provides the format and schema > > > for more complicated stuff. > > > > > > We could perhaps put it in an entirely separate repo, but to me > > > there is a relationship with DT. > > > > It seems to me that TF is the main driver and user of this, so I don't > > see the issue with them hosting it at least to start as long as > > there's not barriers to contributions. It's just a namespace like > > devicetree-org. Personally, I'd be more concerned on what the source > > format is (I assume the plan is not to commit PDFs) and what the > > output generation is. GH has a lot of nice features to support that > > which we've used for the DT spec and EBBR. The default working plan is for the source format to be sphinx. Other alternatives/suggestions are welcome. The output generated should be html (pdf can be supported too for 0/negligible effort). This generation process can and will most likely evolve over time, depending on community direction/desire and the tools we have at our disposal. The process should be as automated as possible given any practical constraints . Regards, Jose > > Yes the DT spec works well and I hope the same thing can be used. > > > > > I'm not saying no to devicetree-org either. If the consensus is to put > > it there, I really don't care so much as it takes less time to create > > a new repo there than to write this email. > > I do hope that this can become a standard beyond ARM, e.g. with Intel and > another i can think of. Intel is essentially trying to create a different > thing > independently, although has apparently adjusted to use device tree due to > its self-describing properties. I suspect that having this spec in an ARM site > would be a barrier to that. > > I am OK with ARM TF being the means to get this into the open, but not with > it being the final destination. > > If we cannot agree on anything better, I am happy with creating a new > project on github. We'll need to pick someone to own it and make final calls > when there is disagreement. > > Regards, > Simon
Pull request efi-2022-07-rc7
Dear Tom, The following changes since commit 0cc846dafcf6f6270c6587d6fe79011834d6e49a: Prepare v2022.07-rc6 (2022-07-04 08:18:33 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2022-07-rc7 for you to fetch changes up to 8fb9dbdea716ab764c7a3c544569f903cbfdd744: test/py: efi_secboot: add a test for a forged signed image (2022-07-05 14:37:16 +0200) Gitlab-CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/12623 Pull request efi-2022-07-rc7 UEFI: * correct verification of signed UEFI binaries AKASHI Takahiro (5): lib: crypto: add mscode_parser efi_loader: signature: export efi_hash_regions() efi_loader: image_loader: replace EFI_PRINT with log macros efi_loader: image_loader: add a missing digest verification for signed PE image test/py: efi_secboot: add a test for a forged signed image include/crypto/mscode.h | 43 include/efi_loader.h | 2 + lib/crypto/Kconfig| 9 ++ lib/crypto/Makefile | 12 +++ lib/crypto/mscode.asn1| 28 ++ lib/crypto/mscode_parser.c| 135 ++ lib/efi_loader/Kconfig| 1 + lib/efi_loader/efi_image_loader.c | 114 -- lib/efi_loader/efi_signature.c| 4 +- test/py/tests/test_efi_secboot/conftest.py| 3 + test/py/tests/test_efi_secboot/forge_image.sh | 5 + test/py/tests/test_efi_secboot/test_signed.py | 35 +++ 12 files changed, 361 insertions(+), 30 deletions(-) create mode 100644 include/crypto/mscode.h create mode 100644 lib/crypto/mscode.asn1 create mode 100644 lib/crypto/mscode_parser.c create mode 100644 test/py/tests/test_efi_secboot/forge_image.sh
[PATCH v2] doc: board: amlogic: add documentation on boot flow
This is a preliminary documentation introducing different boot sequences, and notably the recovery mode. Signed-off-by: Neil Armstrong Reviewed-by: Mattijs Korpershoek Reviewed-by: Simon Glass --- Changes since v1: - Christian Hewitt did an overall grammar correction of the text, meaning of the text hasn't changed, thus I kept the Reviewed-by tags doc/board/amlogic/boot-flow.rst | 134 doc/board/amlogic/index.rst | 1 + 2 files changed, 135 insertions(+) create mode 100644 doc/board/amlogic/boot-flow.rst diff --git a/doc/board/amlogic/boot-flow.rst b/doc/board/amlogic/boot-flow.rst new file mode 100644 index 00..1ca81f3c89 --- /dev/null +++ b/doc/board/amlogic/boot-flow.rst @@ -0,0 +1,134 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Amlogic SoC Boot Flow += + +The Amlogic SoCs have a pre-defined boot sequence in the SoC ROM code. Here are +the possible boot sources of different SoC families supported by U-Boot: + +GX* & AXG family + + ++--++---+---+---+---+ +| | 1| 2 | 3 |4 | 5 | ++==++===+===+===+===+ +| S905 | POC=0: SPI NOR | eMMC | NAND | SD Card | USB Device | +| S905X|| | | | | +| S905L|| | | | | +| S905W|| | | | | +| S912 || | | | | ++--++---+---+---+---+ +| S805X| POC=0: SPI NOR | eMMC | NAND | USB Device| - | +| A113D|| | | | | +| A113X|| | | | | ++--++---+---+---+---+ + +POC pin: `NAND_CLE` + +Some boards provide a button to force USB BOOT which disables the eMMC clock signal +to bypass the eMMC stage. Others have removable eMMC modules; removing the eMMC and +SDCard will allow boot from USB. + +An exception is the lafrite board (aml-s805x-xx) which has no SDCard slot and boots +from SPI. The only ways to boot the lafrite board from USB are: + + - Erase the first sectors of SPI NOR flash + - Insert an HDMI boot plug forcing boot over USB + +The VIM1 and initial VIM2 boards provide a test point on the eMMC signals to block +the storage from answering and continue to the next boot step. + +The USB Device boot uses the first USB interface. On some boards this port is only +available on an USB-A type connector and needs an special Type-A to Type-A cable to +communicate with the BootROM. + +G12* & SM1 family +- + ++---+---+---+---+---+---+---+ +| POC0 | POC1 | POC2 | 1 | 2 | 3 | 4 | ++===+===+===+===+===+===+===+ +| 0 | 0 | 0 | USB Device| SPI NOR | NAND/eMMC | SDCard| ++---+---+---+---+---+---+---+ +| 0 | 0 | 1 | USB Device| NAND/eMMC | SDCard| - | ++---+---+---+---+---+---+---+ +| 0 | 1 | 0 | SPI NOR | NAND/eMMC | SDCard| USB Device| ++---+---+---+---+---+---+---+ +| 0 | 1 | 1 | SPI NAND | NAND/eMMC | USB Device| - | ++---+---+---+---+---+---+---+ +| 1 | 0 | 0 | USB Device| SPI NOR | NAND/eMMC | SDCard| ++---+---+---+---+---+---+---+ +| 1 | 0 | 1 | USB Device| NAND/eMMC | SDCard| - | ++---+---+---+---+---+---+---+ +| 1 | 1 | 0 | SPI NOR | NAND/eMMC | SDCard| USB Device| ++---+---+---+---+---+---+---+ +| 1 | 1 | 1 | NAND/eMMC | SDCard| USB Device| - | ++---+---+---+---+---+---+---+ + +The last option (1/1/1) is the normal default seen on production devices. + + * POC0 pin: `BOOT_4` (0 and all other 1 means SPI NAND boot first) + * POC1 pin: `BOOT_5` (0 and all other 1 means USB Device boot first + * POC2 pin: `BOOT_6` (0 and all
Re: [PATCH] Kconfig: Fix SYS_MALLOC_F_LEN for i.MX8MQ
Hi Peng Am Di., 5. Juli 2022 um 18:04 Uhr schrieb Tom Rini : > > On Tue, Jul 05, 2022 at 05:20:46PM +0200, Heiko Thiery wrote: > > Hi Tom, > > > > Am Di., 5. Juli 2022 um 15:35 Uhr schrieb Tom Rini : > > > > > > On Tue, Jul 05, 2022 at 12:19:54PM +0200, Heiko Thiery wrote: > > > > Hi all, > > > > > > > > Am Mo., 11. Apr. 2022 um 14:29 Uhr schrieb Tom Rini > > > > : > > > > > > > > > > On Mon, Apr 11, 2022 at 05:07:04PM +0800, Peng Fan (OSS) wrote: > > > > > > > > > > > From: Peng Fan > > > > > > > > > > > > i.MX8MQ use SYS_MALLOC_F_LEN 0x2000, not 0x1. The OCRAM_S only > > > > > > has > > > > > > 32KB memory, use 0x1 will make SPL not bootable. It is strange. You said the i.MX8MQ has 32KB OCRAM memory. That means a value of 0x8000 should be the max usable value. But I see when setting to this value my board does not start. Only when I set the value to 0xc000 the board starts. In the RM I see: - On-Chip RAM - OCRAM (128 KB) - On-Chip RAM for State Retention - OCRAM_S (32 KB) > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > Reviewed-by: Michael Trimarchi > > > > > > Reviewed-by: Fabio Estevam > > > > > > --- > > > > > > Kconfig | 6 -- > > > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > > > > > diff --git a/Kconfig b/Kconfig > > > > > > index 6b1ddfc549e..3e95ec9d7b9 100644 > > > > > > --- a/Kconfig > > > > > > +++ b/Kconfig > > > > > > @@ -251,8 +251,10 @@ config SYS_MALLOC_F_LEN > > > > > > default 0x4000 if SANDBOX || RISCV > > > > > > default 0x2000 if (ARCH_MX7 || ARCH_MX7ULP || ARCH_MX6 || > > > > > > ARCH_MX5 || \ > > > > > > ARCH_QEMU || ARCH_SUNXI || ARCH_OWL) > > > > > > - default 0x1 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_LS1012A > > > > > > || \ > > > > > > - ARCH_LS1021A || ARCH_LS1043A || > > > > > > ARCH_LS1046A) > > > > > > + default 0x1 if (ARCH_IMX8 || (ARCH_IMX8M && !IMX8MQ) || \ > > > > > > + ARCH_LS1012A || ARCH_LS1021A || > > > > > > ARCH_LS1043A || \ > > > > > > + ARCH_LS1046A) > > > > > > + default 0x2000 if IMX8MQ > > > > > > default 0x400 > > > > > > help > > > > > > Before relocation, memory is very limited on many > > > > > > platforms. Still, > > > > > > > > > > Note that we can put this with the rest of the 0x2000 default > > > > > instances. > > > > > And as an aside, imx8mq_phanbell_defconfig sets this to 0x4000. That > > > > > said, I've applied this to master (with the location change I noted), > > > > > thanks! > > > > > > > > > > -- > > > > > Tom > > > > > > > > I just tested v2022.07-rc6 and noticed that by reducing the value the > > > > kontron pitx-imx8m (imx8mq) board does not start anymore. I locally > > > > increased the value to 0xc000 and the board works again. > > > > > > > > So should I increase the value just for this board or should I > > > > increase the default value for the IMX8MQ? > > > > > > I would _really_ like to see defaults per SoC. Even if that means > > > saying "default 0xc000 if IMX8Q && SPL_FEAT_X" as I know with tight > > > constraints on memory AND the need to have some of the bigger feature > > > knobs enabled it can be tricky to get usable defaults. But what I > > > really want to avoid are both the problem of everyone copy/pasting a > > > value that's too big or too small and also avoid the problem of N boards > > > needing the same fix because they all failed due to the same problem. > > > > I understand your concerns but the value that has to be adjusted is > > not SPL_SYS_MALLOC_F_LEN. Therefore I'm not sure if the '&& > > SPL_FEAT_X' would be correct here. > > Ah right, sorry. So yes, it's even more likely we should be able to > come up with one default for the family. > > -- > Tom -- Heiko
Re: [PATCH v6 1/7] tpm: Export the TPM-version functions
On Mon, Jul 04, 2022 at 07:04:38PM +0530, Sughosh Ganu wrote:
> From: Simon Glass
>
> These functions should really be available outside the TPM code, so that
> other callers can find out which version the TPM is. Rename them to have
> a tpm_ prefix() and add them to the header file.
>
> Signed-off-by: Simon Glass
> ---
> Changes since V5: None
>
> include/tpm_api.h | 10 ++
> lib/tpm_api.c | 92 +--
> 2 files changed, 51 insertions(+), 51 deletions(-)
>
> diff --git a/include/tpm_api.h b/include/tpm_api.h
> index ef45b43a8f..11aa14eb79 100644
> --- a/include/tpm_api.h
> +++ b/include/tpm_api.h
> @@ -319,4 +319,14 @@ u32 tpm_write_lock(struct udevice *dev, u32 index);
> */
> u32 tpm_resume(struct udevice *dev);
>
> +static inline bool tpm_is_v1(struct udevice *dev)
> +{
> + return IS_ENABLED(CONFIG_TPM_V1) && tpm_get_version(dev) == TPM_V1;
> +}
> +
> +static inline bool tpm_is_v2(struct udevice *dev)
> +{
> + return IS_ENABLED(CONFIG_TPM_V2) && tpm_get_version(dev) == TPM_V2;
> +}
> +
> #endif /* __TPM_API_H */
> diff --git a/lib/tpm_api.c b/lib/tpm_api.c
> index 4c662640a9..4ac4612c81 100644
> --- a/lib/tpm_api.c
> +++ b/lib/tpm_api.c
> @@ -11,21 +11,11 @@
> #include
> #include
>
> -static bool is_tpm1(struct udevice *dev)
> -{
> - return IS_ENABLED(CONFIG_TPM_V1) && tpm_get_version(dev) == TPM_V1;
> -}
> -
> -static bool is_tpm2(struct udevice *dev)
> -{
> - return IS_ENABLED(CONFIG_TPM_V2) && tpm_get_version(dev) == TPM_V2;
> -}
> -
> u32 tpm_startup(struct udevice *dev, enum tpm_startup_type mode)
> {
> - if (is_tpm1(dev)) {
> + if (tpm_is_v1(dev)) {
> return tpm1_startup(dev, mode);
> - } else if (is_tpm2(dev)) {
> + } else if (tpm_is_v2(dev)) {
> enum tpm2_startup_types type;
>
> switch (mode) {
> @@ -47,9 +37,9 @@ u32 tpm_startup(struct udevice *dev, enum tpm_startup_type
> mode)
>
> u32 tpm_resume(struct udevice *dev)
> {
> - if (is_tpm1(dev))
> + if (tpm_is_v1(dev))
> return tpm1_startup(dev, TPM_ST_STATE);
> - else if (is_tpm2(dev))
> + else if (tpm_is_v2(dev))
> return tpm2_startup(dev, TPM2_SU_STATE);
> else
> return -ENOSYS;
> @@ -57,9 +47,9 @@ u32 tpm_resume(struct udevice *dev)
>
> u32 tpm_self_test_full(struct udevice *dev)
> {
> - if (is_tpm1(dev))
> + if (tpm_is_v1(dev))
> return tpm1_self_test_full(dev);
> - else if (is_tpm2(dev))
> + else if (tpm_is_v2(dev))
> return tpm2_self_test(dev, TPMI_YES);
> else
> return -ENOSYS;
> @@ -67,9 +57,9 @@ u32 tpm_self_test_full(struct udevice *dev)
>
> u32 tpm_continue_self_test(struct udevice *dev)
> {
> - if (is_tpm1(dev))
> + if (tpm_is_v1(dev))
> return tpm1_continue_self_test(dev);
> - else if (is_tpm2(dev))
> + else if (tpm_is_v2(dev))
> return tpm2_self_test(dev, TPMI_NO);
> else
> return -ENOSYS;
> @@ -86,7 +76,7 @@ u32 tpm_clear_and_reenable(struct udevice *dev)
> return ret;
> }
>
> - if (is_tpm1(dev)) {
> + if (tpm_is_v1(dev)) {
> ret = tpm1_physical_enable(dev);
> if (ret != TPM_SUCCESS) {
> log_err("TPM: Can't set enabled state\n");
> @@ -105,9 +95,9 @@ u32 tpm_clear_and_reenable(struct udevice *dev)
>
> u32 tpm_nv_enable_locking(struct udevice *dev)
> {
> - if (is_tpm1(dev))
> + if (tpm_is_v1(dev))
> return tpm1_nv_define_space(dev, TPM_NV_INDEX_LOCK, 0, 0);
> - else if (is_tpm2(dev))
> + else if (tpm_is_v2(dev))
> return -ENOSYS;
> else
> return -ENOSYS;
> @@ -115,9 +105,9 @@ u32 tpm_nv_enable_locking(struct udevice *dev)
>
> u32 tpm_nv_read_value(struct udevice *dev, u32 index, void *data, u32 count)
> {
> - if (is_tpm1(dev))
> + if (tpm_is_v1(dev))
> return tpm1_nv_read_value(dev, index, data, count);
> - else if (is_tpm2(dev))
> + else if (tpm_is_v2(dev))
> return tpm2_nv_read_value(dev, index, data, count);
> else
> return -ENOSYS;
> @@ -126,9 +116,9 @@ u32 tpm_nv_read_value(struct udevice *dev, u32 index,
> void *data, u32 count)
> u32 tpm_nv_write_value(struct udevice *dev, u32 index, const void *data,
> u32 count)
> {
> - if (is_tpm1(dev))
> + if (tpm_is_v1(dev))
> return tpm1_nv_write_value(dev, index, data, count);
> - else if (is_tpm2(dev))
> + else if (tpm_is_v2(dev))
> return tpm2_nv_write_value(dev, index, data, count);
> else
> return -ENOSYS;
> @@ -141,9 +131,9 @@ u32 tpm_set_global_lock(struct udevice *dev)
>
> u32 tpm_write_lock(struct udevice *dev, u32 index)
> {
> - if (is_tpm1(dev))
> + if (tpm_is_v1(dev))
> return -ENOSYS;
> - else if
Re: [PATCH 6/9] dm: core: Support accessing core tags
Hi Takahiro, On Tue, 5 Jul 2022 at 19:27, AKASHI Takahiro wrote: > > Hi Simon, > > On Tue, Jul 05, 2022 at 02:27:54PM +0100, Simon Glass wrote: > > Hi, > > > > On Tue, 5 Jul 2022 at 13:39, Tom Rini wrote: > > > > > > On Tue, Jun 28, 2022 at 11:18:51PM +0900, AKASHI Takahiro wrote: > > > > On Tue, Jun 28, 2022 at 09:37:56AM -0400, Simon Glass wrote: > > > > > Hi Simon, > > > > > > > > > > On Sun, May 08, 2022 at 04:39:24AM -0600, Simon Glass wrote: > > > > > > At present tag numbers are only allocated for non-core data, > > > > > > meaning that > > > > > > the 'core' data, like priv and plat, are accessed through dedicated > > > > > > functions. > > > > > > > > > > > > For debugging and consistency it is convenient to use tags for this > > > > > > 'core' > > > > > > data too. Add support for this, with new tag numbers and functions > > > > > > to > > > > > > access the pointer and size for each. > > > > > > > > > > > > Update one of the test drivers so that the uclass-private data can > > > > > > be > > > > > > tested here. > > > > > > > > > > > > There is some code duplication with functions like > > > > > > device_alloc_priv() but > > > > > > this is not addressed for now. At some point, some rationalisation > > > > > > may > > > > > > help to reduce code size, but more thought it needed on that. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > --- > > > > > > > > > > > > drivers/core/device.c | 65 + > > > > > > drivers/misc/test_drv.c | 4 ++- > > > > > > include/dm/device.h | 25 + > > > > > > include/dm/tag.h| 13 ++- > > > > > > test/dm/core.c | 80 > > > > > > + > > > > > > tools/dtoc/test_dtoc.py | 4 +++ > > > > > > 6 files changed, 189 insertions(+), 2 deletions(-) > > > > > > > > > > > Applied to u-boot-dm, thanks! > > > > > > > > I expect you to reply to my comments: > > > > https://lists.denx.de/pipermail/u-boot/2022-May/483606.html > > > > > > > Oh I missed this as I have not been reading email for some months and > > did not notice this in patchwork. > > > > > Simon? This is why I haven't applied the PR for -next yet, I was > > > waiting for your comments here, thanks. > > > > The reason is that the tag functionality is optional and is not used > > for most boards. The new API is a core function. > > Please let me make sure your intension: Is this your answer to my question: > "Why not (enhance and) re-use dev_tag_get_ptr()? >Both functions, at least, share the syntax and even the semantics >from user's viewpoint." > > > I do expect to be able to rationalise things at some point once we > > have a bit more code in there, but perhaps in the opposite direction. > > So you have a concern that this kind of API (i.e. tag) might disappear > or be changed and diverge in incompatible(?) direction in the future > and you think that it's the best for now to have separate APIs for > different subsystems/users? It is more the other way around. The tag API is not used by most boards and is not (yet) a 'required' part of driver model. I have yet to invest enough time to figure out how this should all pan out, but my feeling is that, by making the private-data pointers into tags, we can save data space, if not code space. I am leaning towards joining tags up more so that we can use the 'tag' concept for private-data pointers, with the ability to add other tags as a separate feature which can be enabled or disabled. If we go that way, then dev_tag_get_ptr() will call the new function I've added for 'core' tags, otherwise look up its list. The goal of this patch (and series) is to provide stats to inform the future direction. Regards, Simon
Re: [RFC] Proposed location to host the firmware handoff specification.
Hi Rob, On Tue, 5 Jul 2022 at 11:27, Rob Herring wrote: > > On Tue, Jul 5, 2022 at 10:37 AM Simon Glass wrote: > > > > Hi Rob, > > > > On Tue, 5 Jul 2022 at 09:24, Rob Herring wrote: > > > > > > On Thu, Jun 30, 2022 at 3:24 AM Simon Glass wrote: > > > > > > > > Hi Jose, > > > > > > > > I don't think this is correct. TF-A is a project that aims to replace > > > > U-Boot SPL (and perhaps other components) with more closed firmware, > > > > e.g. the permissive license. > > > > > > > > This spec needs to be in a neutral place, not captive of one project. > > > > > > > > Given its close relationship to device tree, I suggest > > > > github.com/devicetree-org > > > > > > The only relationship to DT I see is DT is a payload as is ACPI. So I > > > don't think dt.org is the right place. > > > > Actually I was about to email you about this. Here's how I see it. > > > > DT is a base structure to allow self-describing data to be stored. > > This is in contrast with ACPI where there is just a header, but it is > > not possible to read the data without specific parsing code for the > > particular table types. Let's ignore ACPI for this discussion. > > > > Unfortunately DT has an overhead and is too expensive for early > > firmware use. It takes 3-4KB of code for libfdt as well as extra code > > and data to read properties, etc. > > > > Transfer List aims to bridge the gap, allowing simple C structures to > > be put into a tagged data structure. The intention is that anything > > more complex than that would use DT. > > > > So there is at least some relationship: simple stuff = Transfer list, > > complex stuff = DT. > > That's a stretch IMO. Perhaps if this was a new output (DTB) format > for easier parsing, I'd agree. It's related to DT only as much as any > other data passed between 2 boot components (remember ATAGS?). Yes it is a stretch. I'm just making the case. > > > The Transfer List spec specifies the data format for each entry type > > (the analog to the schema). The DT provides the format and schema for > > more complicated stuff. > > > > We could perhaps put it in an entirely separate repo, but to me there > > is a relationship with DT. > > It seems to me that TF is the main driver and user of this, so I don't > see the issue with them hosting it at least to start as long as > there's not barriers to contributions. It's just a namespace like > devicetree-org. Personally, I'd be more concerned on what the source > format is (I assume the plan is not to commit PDFs) and what the > output generation is. GH has a lot of nice features to support that > which we've used for the DT spec and EBBR. Yes the DT spec works well and I hope the same thing can be used. > > I'm not saying no to devicetree-org either. If the consensus is to put > it there, I really don't care so much as it takes less time to create > a new repo there than to write this email. I do hope that this can become a standard beyond ARM, e.g. with Intel and another i can think of. Intel is essentially trying to create a different thing independently, although has apparently adjusted to use device tree due to its self-describing properties. I suspect that having this spec in an ARM site would be a barrier to that. I am OK with ARM TF being the means to get this into the open, but not with it being the final destination. If we cannot agree on anything better, I am happy with creating a new project on github. We'll need to pick someone to own it and make final calls when there is disagreement. Regards, Simon
Re: [PATCH V4 01/49] spl: imx8mm: enlarge SPL_MAX_SIZE
Am 06.07.22 um 01:52 schrieb Peng Fan: > > > On 7/5/2022 2:50 PM, Frieder Schrempf wrote: >> Am 05.07.22 um 08:05 schrieb Peng Fan (OSS): >>> From: Peng Fan >>> >>> The CONFIG_SPL_MAX_SIZE could be 0x27000 for i.MX8MM when SPL_TEXT_BASE >>> set to 0x7E1000. >>> >>> Signed-off-by: Peng Fan >> >> I wonder if there is any more explanation for the maximum size that can >> be used. According to the RM, the TCML and TCMU area has a total size of >> 256 KB. But it seems only 156 KB is usable for the SPL!? > > Without binman to pack ddr firmware, ddr firmware will take 96KB > so 4KB + 156KB + 96KB = 256KB. With binman enabled in the future, > SPL_MAX_SIZE could be larger. With ddr firmware runtime on demand > loading ,it will larger!! Thanks for the explanation! That was the part I was missing. If you happen to respin this, it would be nice to have this explanation in the commit message.
