Re: [PATCH 07/29] i2c: mediatek: fix I2C usability for MT7981
Hello Weijie Gao On 19.07.23 11:16, Weijie Gao wrote: > MT7981 actually uses MediaTek I2C controller v3 instead of v1. > This patch adds support for I2C controller v3 fix fixes the I2C usability > for MT7981. > > Signed-off-by: Sam Shih > Signed-off-by: Weijie Gao > --- > drivers/i2c/mtk_i2c.c | 45 +-- > 1 file changed, 43 insertions(+), 2 deletions(-) Thanks! Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v4 2/3] riscv: Add SPL_ZERO_MEM_BEFORE_USE implementation
On Wed, Aug 09, 2023 at 09:11:32PM +0800, Shengyu Qu wrote: > Add the actual support code for SPL_ZERO_MEM_BEFORE_USE and remove > existing Starfive JH7110's L2 LIM clean code, since existing code has > following issues: > 1. Each hart (in the middle of a function call) overwriting its own > stack and other harts' stacks. > (data-race and data-corruption) > 2. Lottery winner hart can be doing "board_init_f_init_reserve", > while other harts are in the middle of zeroing L2 LIM. > (data-race) > > Signed-off-by: Bo Gan > Signed-off-by: Shengyu Qu > --- > Changes since v2: > - Fix typo (ZERO_MEM_BEFORE_USE to SPL_ZERO_MEM_BEFORE_USE) > Changes since v3: > - Revert v3's fix since original implementation is actually right > --- > arch/riscv/cpu/jh7110/spl.c | 25 - > arch/riscv/cpu/start.S | 12 > common/init/board_init.c| 3 +++ > 3 files changed, 15 insertions(+), 25 deletions(-) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH 1/3] fdt: common API to populate kaslr seed
Hi Sean, On Wed, 9 Aug 2023 at 16:35, Sean Edmond wrote: > > > On 2023-08-08 7:03 p.m., Simon Glass wrote: > > Hi, > > > > On Fri, 4 Aug 2023 at 17:34, wrote: > >> From: Dhananjay Phadke > >> > >> fdt_fixup_kaslr_seed() will update given FDT with random seed value. > >> Source for random seed can be TPM or RNG driver in u-boot or sec > >> firmware (ARM). > >> > >> Signed-off-by: Dhananjay Phadke > >> --- > >> arch/arm/cpu/armv8/sec_firmware.c | 32 +++ > >> common/fdt_support.c | 31 ++ > >> include/fdt_support.h | 3 +++ > >> 3 files changed, 41 insertions(+), 25 deletions(-) > > We need to find a way to use the ofnode API here. > > > >> diff --git a/arch/arm/cpu/armv8/sec_firmware.c > >> b/arch/arm/cpu/armv8/sec_firmware.c > >> index c0e8726346..84ba49924e 100644 > >> --- a/arch/arm/cpu/armv8/sec_firmware.c > >> +++ b/arch/arm/cpu/armv8/sec_firmware.c > >> @@ -411,46 +411,28 @@ int sec_firmware_init(const void *sec_firmware_img, > >> /* > >>* fdt_fix_kaslr - Add kalsr-seed node in Device tree > >>* @fdt: Device tree > >> - * @eret: 0 in case of error, 1 for success > >> + * @eret: 0 for success > >>*/ > >> int fdt_fixup_kaslr(void *fdt) > > You could pass an oftree to this function, e.g. obtained with: > > > > oftree_from_fdt(fdt) > > The common API I added is fdt_fixup_kaslr_seed(), which was added to > "common/fdt_support.c". > > There are 3 callers: > sec_firmware_init()->fdt_fixup_kaslr_seed() > do_kaslr_seed()->fdt_fixup_kaslr_seed() > image_setup_libfdt()->fdt_tpm_kaslr_seed->fdt_fixup_kaslr_seed() > > I think the ask is to create a common API that uses the ofnode API. So, > instead of fdt_fixup_kaslr_seed() I can create > ofnode_fixup_kaslr_seed()? Where should it live? If you like you could add common/ofnode_support.c ? But it is OK to have it in the same file, I think. > Are you also wanting > the callers (eg. fdt_tpm_kaslr_seed, fdt_fixup_kaslr) to take oftree as > input too? So far as you can go, yes. Also you may want to pass an ofnode (the root node) so that things can deal with adding their stuff to any node. Regards, Simon
Re: [PATCH] arm_ffa: use debug logs
On Wed, 9 Aug 2023 at 05:47, Abdellatif El Khlifi wrote: > > replace info logs with debug logs > > Signed-off-by: Abdellatif El Khlifi > Cc: Tom Rini > Cc: Simon Glass > --- > doc/arch/arm64.ffa.rst | 2 +- > drivers/firmware/arm-ffa/arm-ffa-uclass.c | 4 ++-- > drivers/firmware/arm-ffa/arm-ffa.c | 2 +- > drivers/firmware/arm-ffa/ffa-emul-uclass.c | 2 +- > drivers/firmware/arm-ffa/sandbox_ffa.c | 2 +- > 5 files changed, 6 insertions(+), 6 deletions(-) > Reviewed-by: Simon Glass Thanks, Simon
Re: NVMe support on RPi CM4 board
Hi Luis, On Wed, 9 Aug 2023 at 10:43, Luis Alfredo da Silva wrote: > > Hi Simon, I enabled the next four variables > > CONFIG_NVME_PCI=y > CONFIG_NVME=y > CONFIG_CMD_NVME=y > CONFIG_PCI=y > > how different is CONFIG_NVME_PCI from NVME_PCI, I took the latter value from > several configs files in u-boot repo and from [1] I just left off the CONFIG as they all have that. This looks right to me. Assuming that the NVMe controller appears in 'dm tree' perhaps you can enable debugging in the driver and see why it is not working? Regards, Simon > > > [1] > https://github.com/u-boot/u-boot/blob/ef8336e2705fce2502383f25d68188c6b1f94dd0/doc/develop/driver-model/nvme.rst#L44 > > El mar, 8 ago 2023 a las 22:05, Simon Glass () escribió: >> >> Hi Luis, >> >> On Tue, 8 Aug 2023 at 17:09, Luis Alfredo da Silva >> wrote: >> > >> > I compiled u-boot version 2023-07 and boot it on a RPi CM4 using a PCIe M.2 >> > NVMe drive, but it doesn't appear to be working. >> > >> > Once u-boot has started and boot successfully it recognizes the PCIe device >> > giving me the next output >> > >> > U-Boot> pci >> > BusDevFun VendorId DeviceId Device Class Sub-Class >> > _ >> > 00.00.00 0x14e4 0x2711 Bridge device 0x04 >> > 01.00.00 0x1c5c 0x174a Mass storage controller 0x08 >> > >> > but when trying to use the nvme scan and nvme info there is not output. >> > >> > NVMe drive has two partitions 1st is a FAT partition, and 2nd is a EXT4 >> > partition, the RPi firmware recognizes the FAT partition and u-boot boot >> > correctly. >> > >> > I don't know if this worked before, but I saw in the mailing list that >> > there could be already support for other ARM64 boards. >> >> Is NVME_PCI enabled? >> >> Regards, >> SImon
Re: [PATCH v10 03/10] tpm: Support boot measurements
Hi Eddie, On Mon, 7 Aug 2023 at 09:17, Eddie James wrote: > > Add TPM2 functions to support boot measurement. This includes > starting up the TPM, initializing/appending the event log, and > measuring the U-Boot version. Much of the code was used in the > EFI subsystem, so remove it there and use the common functions. > > Signed-off-by: Eddie James > --- > Changes since v8: > - Fix log parsing again - any data corruption seen while replaying the >event log was failing the entire measurement. > - Added an option to ignore the existing log. This should only be used >for systems that know that U-Boot is the first stage bootloader. This >is necessary because the reserved memory region may persist through >resets and so U-Boot attempts to append to the previous boot's log. > > Changes since v7: > - Change name of tcg2_init_log and add more documentation > - Add a check, when parsing the event log header, to ensure that the >previous stage bootloader used all the active PCRs. > - Change name of tcg2_log_find_end > - Fix the greater than or equal to check to exit the log parsing > - Make sure log_position is 0 if there is any error discovering the log > - Return errors parsing the log if the data is corrupt so that we don't >end up with half a log > > Changes since v6: > - Added Linaro copyright for all the EFI moved code > - Changed tcg2_init_log (and by extension, tcg2_measurement_init) to >copy any discovered event log to the user's log if passed in. > > Changes since v5: > - Remove unused platform_get_eventlog in efi_tcg2.c > - First look for tpm_event_log_* properties instead of linux,sml-* > - Fix efi_tcg2.c compilation > - Select SHA* configs > > Changes since v4: > - Remove tcg2_measure_event function and check for NULL data in >tcg2_measure_data > - Use tpm_auto_startup > - Fix efi_tcg2.c compilation for removing tcg2_pcr_read function > > Changes since v3: > - Reordered headers > - Refactored more of EFI code into common code > Removed digest_info structure and instead used the common alg_to_mask > and alg_to_len > Improved event log parsing in common code to get it equivalent to EFI > Common code now extends PCR if previous bootloader stage couldn't > No need to allocate memory in the common code, so EFI copies the > discovered buffer like it did before > Rename efi measure_event function > > Changes since v1: > - Refactor TPM layer functions to allow EFI system to use them, and >remove duplicate EFI functions > > include/efi_tcg2.h| 44 -- > include/tpm-v2.h | 259 + > lib/Kconfig |4 + > lib/efi_loader/efi_tcg2.c | 1054 +++-- > lib/tpm-v2.c | 814 > 5 files changed, 1154 insertions(+), 1021 deletions(-) This is adding a lot more code to the TPM implementation and I see you have added more tests. But do we have enough unit testing in test/dm/tpm.c for these new functions? Regards, Simon
Re: [PATCH 09/20] pinctrl: sunxi: add Allwinner D1 pinctrl description
On 7/21/23 07:45, Andre Przywara wrote:
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index fc80fe50b14..c6115112688 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -748,6 +748,28 @@ static const struct sunxi_pinctrl_desc __maybe_unused
sun50i_h616_r_pinctrl_desc
.num_banks = 1,
};
+static const struct sunxi_pinctrl_function sun20i_d1_pinctrl_functions[] = {
+ { "emac", 8 },/* PE0-PE15 */
+ { "gpio_in", 0 },
+ { "gpio_out", 1 },
+ { "mmc0", 2 },/* PF0-PF5 */
+ { "mmc2", 3 },/* PC1-PC7 */
+ { "spi0", 2 },/* PC2-PC7 */
+#if IS_ENABLED(CONFIG_UART0_PORT_F)
+ { "uart0",3 },/* PF2-PF4 */
/* PF2, PF4 */ ?
+#else
+ { "uart0",6 },/* PB2-PB3 */
/* PB0-PB1 */ ?
+#endif
+ { "uart3",7 },/* PB6-PB9 */
/* PB6-PB7 */ ?
+};
Cheers,
Sam
Re: [PATCH 1/3] fdt: common API to populate kaslr seed
On 2023-08-08 7:03 p.m., Simon Glass wrote:
Hi,
On Fri, 4 Aug 2023 at 17:34, wrote:
From: Dhananjay Phadke
fdt_fixup_kaslr_seed() will update given FDT with random seed value.
Source for random seed can be TPM or RNG driver in u-boot or sec
firmware (ARM).
Signed-off-by: Dhananjay Phadke
---
arch/arm/cpu/armv8/sec_firmware.c | 32 +++
common/fdt_support.c | 31 ++
include/fdt_support.h | 3 +++
3 files changed, 41 insertions(+), 25 deletions(-)
We need to find a way to use the ofnode API here.
diff --git a/arch/arm/cpu/armv8/sec_firmware.c
b/arch/arm/cpu/armv8/sec_firmware.c
index c0e8726346..84ba49924e 100644
--- a/arch/arm/cpu/armv8/sec_firmware.c
+++ b/arch/arm/cpu/armv8/sec_firmware.c
@@ -411,46 +411,28 @@ int sec_firmware_init(const void *sec_firmware_img,
/*
* fdt_fix_kaslr - Add kalsr-seed node in Device tree
* @fdt: Device tree
- * @eret: 0 in case of error, 1 for success
+ * @eret: 0 for success
*/
int fdt_fixup_kaslr(void *fdt)
You could pass an oftree to this function, e.g. obtained with:
oftree_from_fdt(fdt)
The common API I added is fdt_fixup_kaslr_seed(), which was added to
"common/fdt_support.c".
There are 3 callers:
sec_firmware_init()->fdt_fixup_kaslr_seed()
do_kaslr_seed()->fdt_fixup_kaslr_seed()
image_setup_libfdt()->fdt_tpm_kaslr_seed->fdt_fixup_kaslr_seed()
I think the ask is to create a common API that uses the ofnode API. So,
instead of fdt_fixup_kaslr_seed() I can create
ofnode_fixup_kaslr_seed()? Where should it live? Are you also wanting
the callers (eg. fdt_tpm_kaslr_seed, fdt_fixup_kaslr) to take oftree as
input too?
{
- int nodeoffset;
- int err, ret = 0;
- u8 rand[8];
+ int ret = 0;
#if defined(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT)
+ u8 rand[8];
+
/* Check if random seed generation is supported */
if (sec_firmware_support_hwrng() == false) {
printf("WARNING: SEC firmware not running, no kaslr-seed\n");
- return 0;
+ return -EOPNOTSUPP;
}
err = sec_firmware_get_random(rand, 8);
if (err < 0) {
printf("WARNING: No random number to set kaslr-seed\n");
- return 0;
- }
-
- err = fdt_check_header(fdt);
- if (err < 0) {
- printf("fdt_chosen: %s\n", fdt_strerror(err));
- return 0;
+ return ret;
}
- /* find or create "/chosen" node. */
- nodeoffset = fdt_find_or_add_subnode(fdt, 0, "chosen");
- if (nodeoffset < 0)
- return 0;
-
- err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", rand,
- sizeof(rand));
- if (err < 0) {
- printf("WARNING: can't set kaslr-seed %s.\n",
- fdt_strerror(err));
- return 0;
- }
- ret = 1;
+ ret = fdt_fixup_kaslr_seed(fdt, rand, sizeof(rand));
#endif
return ret;
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 5e49078f8c..35d4f26dbd 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -631,6 +631,37 @@ void fdt_fixup_ethernet(void *fdt)
}
}
+/*
+ * fdt_fix_kaslr_seed - Add kalsr-seed node in Device tree
+ * @fdt: Device tree
+ * @eret: 0 for success
+ */
+int fdt_fixup_kaslr_seed(void *fdt, const u8 *seed, int len)
+{
+ int nodeoffset;
+ int err;
+
+ err = fdt_check_header(fdt);
+ if (err < 0) {
+ printf("fdt_chosen: %s\n", fdt_strerror(err));
+ return err;
+ }
+
+ /* find or create "/chosen" node. */
+ nodeoffset = fdt_find_or_add_subnode(fdt, 0, "chosen");
+ if (nodeoffset < 0)
+ return -ENOENT;
+
+ err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", seed, len);
+ if (err < 0) {
+ printf("WARNING: can't set kaslr-seed %s.\n",
+ fdt_strerror(err));
+ return err;
+ }
+
+ return 0;
+}
+
int fdt_record_loadable(void *blob, u32 index, const char *name,
uintptr_t load_addr, u32 size, uintptr_t entry_point,
const char *type, const char *os, const char *arch)
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 2cd8366898..d74ef4e0a7 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -121,6 +121,9 @@ static inline int fdt_fixup_memory_banks(void *blob, u64
start[], u64 size[],
#endif
void fdt_fixup_ethernet(void *fdt);
+
+int fdt_fixup_kaslr_seed(void *fdt, const u8 *seed, int len);
Please get in the habit of adding full comments to exported functions.
+
int fdt_find_and_setprop(void *fdt, const char *node, const char *prop,
const void *val, int len, int create);
void
Re: [PATCH 19/20] ARM: dts: sunxi: add Allwinner T113-s SoC .dtsi
On 7/21/23 07:46, Andre Przywara wrote:
The Allwinner T113-s SoC is apparently using the same (or at least a very
similar) die as the D1/D1s, but replaces the single RISC-V core with
two Arm Cortex-A7 cores.
Since the D1 core .dtsi already describes all common peripherals, we
just need a DT describing the ARM specific peripherals: the CPU cores,
the Generic Timer, the GIC and the PMU.
We include the core .dtsi directly from the riscv DT directory.
The ARM core version of the DT specifies the CPUX watchdog as
"reserved", which means it won't be recognised by U-Boot. Override this
in our generic sunxi-u-boot.dtsi, to let U-Boot pick up this watchdog,
so that the generic reset driver will work.
Signed-off-by: Andre Przywara
Reviewed-by: Sam Edwards
Tested-by: Sam Edwards
diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
index af419c7e590..a0c8abb7033 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -23,6 +23,13 @@
};
};
+/* Let U-Boot be the firmware layer that controls the watchdog. */
+#ifdef CONFIG_MACH_SUN8I_R528
+ {
+ status = "okay";
+};
+#endif
+
{
u-boot-sunxi-with-spl {
filename = "u-boot-sunxi-with-spl.bin";
Nice!!
Thanks,
Sam
Re: [PATCH 08/20] sunxi: introduce NCAT2 generation model
On 7/21/23 07:45, Andre Przywara wrote: Allwinner seems to typically stick to a common MMIO memory map for several SoCs, but from time to time does some breaking changes, which also introduce new generations of some peripherals. The last time this happened with the H6, which apart from re-organising the base addresses also changed the clock controller significantly. We added a CONFIG_SUN50I_GEN_H6 symbol back then to mark SoCs sharing those traits. Now the Allwinner D1 changes the memory map again, and also extends the pincontroller, among other peripherals. To mark this generation of SoCs, add a CONFIG_SUNXI_GEN_NCAT2 symbol, this name is reportedly used in the Allwinner BSP code, and prevents us from inventing our own name. Add this new symbol to some guards that were already checking for the H6 generation, since many features are shared between the two (like the renovated clock controller). This paves the way to introduce a first user of this generation. Signed-off-by: Andre Przywara Reviewed-by: Sam Edwards Tested-by: Sam Edwards Thanks, Sam
Re: [PATCH 07/20] pinctrl: sunxi: add new D1 pinctrl support
On 7/21/23 07:45, Andre Przywara wrote: For the first time since at least the Allwinner A10 SoCs, the D1 (and related cores) use a new pincontroller MMIO register layout, so we cannot use our hardcoded, fixed offsets anymore. Ideally this would all be handled by devicetree and DM drivers, but for the DT-less SPL we still need the legacy interfaces. Add a new Kconfig symbol to differenciate between the two generations of pincontrollers, and just use that to just switch some basic symbols. The rest is already abstracted enough, so works out of the box. Signed-off-by: Andre Przywara Reviewed-by: Sam Edwards Tested-by: Sam Edwards Thanks, Sam
Re: [PATCH 03/20] pinctrl: sunxi: add GPIO in/out wrappers
On 7/21/23 07:45, Andre Przywara wrote:
So far we were open-coding the pincontroller's GPIO output/input access
in each function using that.
Provide functions that wrap that nicely, and follow the existing pattern
(set/get_{bank,}), so users don't need to know about the internals, and
we can abstract the new D1 pinctrl more easily.
Signed-off-by: Andre Przywara
Reviewed-by: Sam Edwards
Tested-by: Sam Edwards
Thanks,
Sam
Re: [PATCH 02/20] sunxi: remove CONFIG_MACPWR
Hi Andre, Ditto my response to the previous patch. On 7/21/23 07:45, Andre Przywara wrote: The CONFIG_MACPWR Kconfig symbol is used to point to a GPIO that enables the power for the Ethernet "MAC" (mostly PHY, really). In the DT this is described with the phy-supply property in the MAC DT node, pointing to a (GPIO controlled) regulator. Since we need Ethernet only in U-Boot proper, and use a DM driver there, we should use the DT instead of hardcoding this. Add code to the sun8i_emac and sunxi_emac drivers to check the DT for that regulator and enable it, at probe time. Then drop the current code from board.c, which was doing that job before. This allows us to remove the MACPWR Kconfig definition and the respective values from the defconfigs. Signed-off-by: Andre Przywara Reviewed-by: Sam Edwards Thanks, Sam
Re: [PATCH 01/20] net: sunxi_emac: chase DT nodes to find PHY regulator
Hi Andre, Looks good to me! My target doesn't have PHY on a regulator, so no test result for this one. On 7/21/23 07:45, Andre Przywara wrote: At the moment the sun4i EMAC driver relies on hardcoded CONFIG_MACPWR Kconfig symbols to enable potential PHY regulators. As we want to get rid of those, we need to find the regulator by chasing up the DT. The sun4i-emac binding puts the PHY regulator into the MDIO node, which is the parent of the PHY device. U-Boot does not have (and does not need) an MDIO driver, so we need to chase down the regulator through the EMAC node: we follow the "phy-handle" property to find the PHY node, then go up to its parent, where we find the "phy-supply" link to the regulator. Let U-Boot find the associated regulator device, and put that into the private device struct, so we can find and enable the regulator at probe time, later. Signed-off-by: Andre Przywara Reviewed-by: Sam Edwards Thanks, Sam
Re: [PATCHv5 11/13] net/lwip: connection between cmd and lwip apps
On Wed, 9 Aug 2023 at 00:13, Ilias Apalodimas
wrote:
> Hi Maxim
>
> [...]
>
> > > > +static int lwip_empty_tmo(void) { return 0; };
> > > > +int (*ulwip_tmo)(void) = lwip_empty_tmo;
> > > > +void ulwip_set_tmo(int (*tmo)(void))
> > > > +{
> > > > + ulwip_tmo = tmo;
> > > > +}
> > > > +
> > > > +static void ulwip_clear_tmo(void)
> > > > +{
> > > > + ulwip_tmo = lwip_empty_tmo;
> > > > +}
> > > > +
> > > > +static void ulwip_timeout_handler(void)
> > > > +{
> > > > + eth_halt();
> > > > + ulwip_tmo();
> > > > + net_set_state(NETLOOP_FAIL);/* we did not get the reply */
> > >
> > > I am not sure what I am reading here. You use callbacks a few lines
> above
> > > to set a timeout function. But only set it for dhcp. On top of that
> the
> > > function for DHCP has a case for a *successful* asignment of ip
> addresses.
> > > Why are we setting the state to fail? And why are we complicating this
> by
> > > assigning and removing callbacks if it's only used for dhcp?
> > >
> > >
> > I need two time out callbacks here:
> > 1. Trap rx polling loop if lwip application works too long. It is used
> when
> > code goes to net_loop() code to poll rx packets
> > and nobody interrupts this loop. This timeout is used for all cmds (lwip
> > apps).
> >
> > 2. Trap lwip application after specific timeout and then check some
> state.
> > That is case for DHCP, where LWIP DHCP does not have
> > callback for changing state. And I need to know when to stop polling
> loop.
>
> Yes but is there a reason to reassing those callback to a function ptr?
> Just define them and use them
>
>
I added a more detailed description to this time out function for the next
version. The reason
here is the following - there is no scheduler. cmd just starts lwip
application. But in fact it does
only initialization and in most cases you need to go to the polling loop.
Then after polling
loop you need to return to 1. back to U-boot console. or 2. back to lwip
application to print some message,
or get some lwip state or run something else. This return is done with
this timeout callback. Which
looks logical to me to have a timeout callback in the same file as
application code.
> [...]
>
> > > > + ret = ulwip_dhcp();
> > > > +
> > > > + net_set_timeout_handler(2000UL, ulwip_timeout_handler);
> > > > +
> > > > + ulwip_loop();
> > > > + if (IS_ENABLED(CONFIG_CMD_TFTPBOOT)) {
> > > > + ulwip_clear_tmo();
> > > > +
> > > > + filename = env_get("bootfile");
> > > > + if (!filename) {
> > > > + printf("no bootfile\n");
> > > > + return CMD_RET_FAILURE;
> > >
> > > Why is this a failure? You just have the tftp command enabled but dont
> > > want to download anything
> > >
> > > thanks, if dhcp did not return filename, but only IP, then nothing to
> > download. It's not an error.
>
> Yes but downloading a file is not mandatory, it depends on a DHCP option.
> If you
> want to emulate this behaviour, you need to fail only if 'bootfile' is
> set but
> cant be downloaded.
>
> >
> >
> > > > + }
> > > > +
>
>
> Regards
> /Ilias
>
Re: Please pull u-boot-x86
On Thu, Aug 10, 2023 at 12:38:14AM +0800, Bin Meng wrote: > Hi Tom, > > CI: https://source.denx.de/u-boot/custodians/u-boot-x86/-/pipelines/17270 > > The following changes since commit ef8336e2705fce2502383f25d68188c6b1f94dd0: > > Merge branch '2023-08-08-introuce-Arm-FF-A-support' (2023-08-08 > 15:23:16 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-x86.git > tags/x86-pull-20230809 > > for you to fetch changes up to 9234b77b9d42ebd77585091a072b4ab958ba83ed: > > x86: qemu-x86: Convert to text environment (2023-08-09 23:31:12 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request for doc-2023-10-rc3
On Wed, Aug 09, 2023 at 12:18:16PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit ef8336e2705fce2502383f25d68188c6b1f94dd0: > > Merge branch '2023-08-08-introuce-Arm-FF-A-support' (2023-08-08 > 15:23:16 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/doc-2023-10-rc3 > > for you to fetch changes up to fa43709b8d7aa30b6d1039dce854c5eea86f122f: > > doc: Begin adding a best practices document for board ports > (2023-08-09 08:41:52 +0200) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/17254 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] please pull fsl-qoriq-2023-8-9
On Wed, Aug 09, 2023 at 07:29:22AM +, Peng Fan wrote: > Hi Tom, > > Please pull fsl-qoriq-2023-8-9, only one minor cleanup patch. > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] Revert "lib: string: Fix strlcpy return value", fix callers
On Mon, Aug 07, 2023 at 09:45:37AM +0200, Rasmus Villemoes wrote: > On 14/07/2023 13.24, Matthias Schiffer wrote: > > Both the Linux kernel and libbsd agree that strlcpy() should always > > return strlen(src) and not include the NUL termination. The incorrect > > U-Boot implementation makes it impossible to check the return value for > > truncation, and breaks code written with the usual implementation in > > mind (for example, fdtdec_add_reserved_memory() was subtly broken). > > So while we're fixing non-standard string function behaviour, can we > _please_ finally fix strncpy() so it follows C/POSIX? > > https://lore.kernel.org/u-boot/52bc92d4-8651-48df-3577-043aa2e16...@prevas.dk/ > > Note in particular the very last paragraph. > > To rephrase and give a concrete example, what I'm worried about is us > importing some file system code that (correctly) uses strncpy() to fully > initialize some memory buffer, then writes that out to disk - but with > our crippled strncpy(), the result is potential garbage on-disk, which > both our own read implementation (which is likely also just copied) and > the kernel's may subsequently choke on. > > Correctness first, please. If there are any performance problems, those > should be identified individually and perhaps rewritten to not use > strncpy() after verifying that not zeroing the tail is ok for that call > site. Yes, I agree it would be good to make this change. -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] treewide: unify the linker symbol reference format
On Thu, Aug 03, 2023 at 09:47:17AM +0800, Shiji Yang wrote: > Now all linker symbols are declared as type char[]. Though we can > reference the address via both the array name 'var' and its address > ''. It's better to unify them to avoid confusing developers. > This patch converts all '' linker symbol refrences to the most > commonly used format 'var'. > > Signed-off-by: Shiji Yang > Reviewed-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] treewide: rework linker symbol declarations in sections header
On Thu, Aug 03, 2023 at 09:47:16AM +0800, Shiji Yang wrote:
> 1. Convert all linker symbols to char[] type so that we can get the
>corresponding address by calling array name 'var' or its address
>''. In this way, we can avoid some potential issues[1].
> 2. Remove unused symbol '_TEXT_BASE'. It has been abandoned and has
>not been referenced by any source code.
> 3. Move '__data_end' to the arch x86's own sections header as it's
>only used by x86 arch.
> 4. Remove some duplicate declared linker symbols. Now we use the
>standard header file to declare them.
>
> [1] This patch fixes the boot failure on MIPS target. Error log:
> SPL: Image overlaps SPL
>
> Fixes: 1b8a1be1a1f1 ("spl: spl_legacy: Fix spl_end address")
> Signed-off-by: Shiji Yang
> Reviewed-by: Tom Rini
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] Kconfigs: Correct default of "0" on hex type entries
On Wed, Aug 02, 2023 at 11:09:43AM -0400, Tom Rini wrote: > It is not a parse error to have a default value of "0" for a "hex" type > entry, instead of "0x0". However, "0" and "0x0" are not treated the > same even by the tools themselves. Correct this by changing the default > value from "0" to "0x0" for all hex type questions that had the > incorrect default. Fix one instance (in two configs) of a default of "0" > being used on a hex question to be "0x0". Remove the cases where a > defconfig had set a value of "0x0" to be used as the default had been > "0". > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
On Tue, Jul 11, 2023 at 04:20:46PM -0500, Jason Kacines wrote: > Add support to config fragments (.config) located in the /board > directory. This will allow only base defconfigs to live in /configs and > all fragments to live in their respective device directory in /board/.. > > Signed-off-by: Jason Kacines Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Please pull u-boot-x86
Hi Tom, CI: https://source.denx.de/u-boot/custodians/u-boot-x86/-/pipelines/17270 The following changes since commit ef8336e2705fce2502383f25d68188c6b1f94dd0: Merge branch '2023-08-08-introuce-Arm-FF-A-support' (2023-08-08 15:23:16 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-x86.git tags/x86-pull-20230809 for you to fetch changes up to 9234b77b9d42ebd77585091a072b4ab958ba83ed: x86: qemu-x86: Convert to text environment (2023-08-09 23:31:12 +0800) - x86: Fixes for distro booting - x86: Move some boards to text environment Simon Glass (36): usb: Return -ENOENT when no devices are found lib: Suppress E when writing error-string output bootstd: Rename bootdev_setup_sibling_blk() bootstd: Correct creating of bootdev sibling bootstd: Add some more debugging in the bootdev uclass x86: coreboot: Update doc for CBFS access x86: spl: Drop unwanted debug() video: Tidy up Makefile rule for video x86: Run QEMU machine setup in SPL Revert "x86: Switch QEMU over to use the bochs driver" x86: Correct copying of BIOS mode information video: Add a Kconfig option for SPL video handoff x86: Enable useful options for qemu-86 x86: Update qemu documentation doc: Explain how to avoid the distro-boot scripts env: Use include/env for text-environment includes env: Explain how to use #include files in text environment x86: Drop CFG_SYS_STACK_SIZE x86: i8254: Include required ibmpc.h header x86: edison: Drop inclusion of ibmpc.h x86: Drop inclusion of ibmpc.h x86: Drop unused distro settings x86: Add a common include for environment settings x86: coreboot: Convert to text environment x86: crownbay: Convert to text environment x86: bayleybay: Convert to text environment x86: galileo: Convert to text environment x86: edison: Convert to text environment x86: cherryhill: Convert to text environment x86: cougarcanyon2: Convert to text environment x86: minnowmax: Convert to text environment x86: slimbootloader: Convert to text environment x86: efi-x86_app: Convert to text environment x86: efi-x86_payload: Convert to text environment x86: qemu: Add required linux/sizes.h include x86: qemu-x86: Convert to text environment arch/x86/cpu/qemu/Kconfig | 2 +- arch/x86/cpu/qemu/dram.c | 1 + arch/x86/cpu/qemu/e820.c | 1 + arch/x86/cpu/qemu/qemu.c | 2 +- arch/x86/include/asm/qemu.h| 14 ++ arch/x86/lib/bios.c| 2 +- arch/x86/lib/i8254.c | 1 + arch/x86/lib/physmem.c | 3 ++- arch/x86/lib/spl.c | 4 +++- board/coreboot/coreboot/coreboot.env | 9 + board/efi/efi-x86_app/efi-x86_app.env | 6 ++ board/efi/efi-x86_payload/efi-x86_payload.env | 6 ++ board/emulation/qemu-x86/qemu-x86.env | 6 ++ board/intel/bayleybay/bayleybay.env| 9 + board/intel/cherryhill/cherryhill.env | 9 + board/intel/cougarcanyon2/cougarcanyon2.env| 6 ++ board/intel/crownbay/crownbay.env | 6 ++ board/intel/edison/edison.env | 6 ++ board/intel/galileo/galileo.env| 11 +++ board/intel/minnowmax/minnowmax.env| 11 +++ board/intel/slimbootloader/slimbootloader.env | 23 +++ board/keymile/km83xx/km83xx.env| 4 ++-- board/keymile/kmcent2/kmcent2.env | 2 +- board/keymile/pg-wcom-ls102xa/pg-wcom-expu1.env| 2 +- board/keymile/pg-wcom-ls102xa/pg-wcom-seli8.env| 2 +- board/siemens/iot2050/iot2050.env | 2 +- board/ti/am62ax/am62ax.env | 4 ++-- board/ti/am62x/am62x.env | 4 ++-- board/ti/am64x/am64x.env | 6 +++--- board/ti/am65x/am65x.env | 8 board/ti/j721e/j721e.env | 10 +- board/ti/j721s2/j721s2.env | 10 +- board/ti/ks2_evm/k2e_evm.env | 4 ++-- board/ti/ks2_evm/k2g_evm.env | 6 +++--- board/ti/ks2_evm/k2hk_evm.env | 4 ++-- board/ti/ks2_evm/k2l_evm.env | 4 ++-- bo
Re: [PATCH v2 0/9] x86: Fixes for distro booting
On Wed, 9 Aug 2023 at 09:40, Bin Meng wrote: > > Hi Simon, > > On Wed, Aug 9, 2023 at 11:09 PM Simon Glass wrote: > > > > Hi Bin, > > > > Any word on this, please? I would like to get distros running in qemu > > and after that we still need to resolve the board_f problem upstream. > > > > Sorry it took so long. I've prepared the branch and am waiting for CI > to complete before I can send the PR. Thank you Bin.
Re: [PATCH v2 0/9] x86: Fixes for distro booting
Hi Simon, On Wed, Aug 9, 2023 at 11:09 PM Simon Glass wrote: > > Hi Bin, > > Any word on this, please? I would like to get distros running in qemu > and after that we still need to resolve the board_f problem upstream. > Sorry it took so long. I've prepared the branch and am waiting for CI to complete before I can send the PR. Regards, Bin
Re: [PATCH v3 5/9] board_f: Fix corruption of relocaddr
On Thu, Aug 3, 2023 at 7:03 PM Bin Meng wrote:
>
> On Thu, Aug 3, 2023 at 6:37 PM Bin Meng wrote:
> >
> > On Tue, Aug 1, 2023 at 12:00 AM Simon Glass wrote:
> > >
> > > When the video framebuffer comes from the bloblist, we should not change
> > > relocaddr to this address, since it interfers with the normal memory
> >
> > typo: interferes
> >
> > > allocation.
> > >
> > > This fixes a boot loop in qemu-x86_64
> > >
> > > Signed-off-by: Simon Glass
> > > Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from SPL to
> > > u-boot")
> > > Suggested-by: Nikhil M Jain
> > > ---
> > >
> > > Changes in v3:
> > > - Reword the Kconfig help as suggested
> > >
> > > Changes in v2:
> > > - Add a Kconfig as the suggested conditional did not work
> > >
> > > common/board_f.c | 3 ++-
> > > drivers/video/Kconfig | 9 +
> > > 2 files changed, 11 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/common/board_f.c b/common/board_f.c
> > > index 7d2c380e91e..5173d0a0c2d 100644
> > > --- a/common/board_f.c
> > > +++ b/common/board_f.c
> > > @@ -419,7 +419,8 @@ static int reserve_video(void)
> > > if (!ho)
> > > return log_msg_ret("blf", -ENOENT);
> > > video_reserve_from_bloblist(ho);
> > > - gd->relocaddr = ho->fb;
> > > + if (IS_ENABLED(CONFIG_VIDEO_RESERVE_SPL))
> > > + gd->relocaddr = ho->fb;
> > > } else if (CONFIG_IS_ENABLED(VIDEO)) {
> > > ulong addr;
> > > int ret;
> > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > index b41dc60cec5..f2e56204d52 100644
> > > --- a/drivers/video/Kconfig
> > > +++ b/drivers/video/Kconfig
> > > @@ -1106,6 +1106,15 @@ config SPL_VIDEO_REMOVE
> > > if this option is enabled video driver will be removed at the
> > > end of
> > > SPL stage, beforeloading the next stage.
> > >
> > > +config VIDEO_RESERVE_SPL
> > > + bool
> > > + help
> > > + This adjusts reserve_video() to redirect memory reservation
> > > when it
> > > + sees a video handoff blob (BLOBLISTT_U_BOOT_VIDEO). This avoids
> > > the
> > > + memory used for framebuffer from being allocated by U-Boot
> > > proper,
> > > + thus preventing any further memory reservations done by U-Boot
> > > proper
> > > + from overwriting the framebuffer.
> > > +
> > > if SPL_SPLASH_SCREEN
> > >
> > > config SPL_SPLASH_SCREEN_ALIGN
> >
> > Reviewed-by: Bin Meng
>
> applied to u-boot-x86, thanks!
Dropped this one from the x86 queue per the discussion.
Regards,
Bin
Re: [PATCH 3/3] arm: qemu: Enable usb keyboard as an input device
On Wed, Aug 9, 2023 at 3:19 AM Alper Nebi Yasak
wrote:
>
> Commit 02be57caf730 ("riscv: qemu: Enable usb keyboard as an input
> device") adds PCI xHCI support to QEMU RISC-V virtual machines and
> enables using a USB keyboard as one of the input devices. Similarly,
> enable those for ARM virtual machines as well.
>
> Signed-off-by: Alper Nebi Yasak
> ---
>
> arch/arm/Kconfig | 5 +
> board/emulation/qemu-arm/qemu-arm.c | 5 +
> board/emulation/qemu-arm/qemu-arm.env | 2 +-
> configs/qemu_arm64_defconfig | 2 --
> configs/qemu_arm_defconfig| 2 --
> doc/board/emulation/qemu-arm.rst | 4
> 6 files changed, 15 insertions(+), 5 deletions(-)
>
Reviewed-by: Bin Meng
Re: [PATCH 2/3] arm: qemu: Enable PRE_CONSOLE_BUFFER
On Wed, Aug 9, 2023 at 3:19 AM Alper Nebi Yasak
wrote:
>
> Commit 608b80b5b855 ("riscv: qemu: Enable PRE_CONSOLE_BUFFER") enables
> buffering console messages for QEMU RISC-V virtual machines so those
> printed before the video console is available will still show up on the
> display. Similarly, enable it for ARM virtual machines as well.
>
> Signed-off-by: Alper Nebi Yasak
> ---
> Not sure about the address, here are select values from bdinfo and env:
>
> DRAM bank = 0x
> -> start= 0x4000
> -> size = 0x0800
> relocaddr = 0x476d6000
> fdt_blob= 0x46595d90
> lmb_dump_all:
> memory.cnt = 0x1 / max = 0x10
> memory[0] [0x4000-0x47ff], 0x0800 bytes flags: 0
> reserved.cnt = 0x2 / max = 0x10
> reserved[0][0x45591000-0x47ff], 0x02a6f000 bytes flags: 0
> reserved[1][0x46591760-0x47ff], 0x01a6e8a0 bytes flags: 0
> TLB addr= 0x47fe
> irq_sp = 0x46595d80
> sp start= 0x46595d80
>
> fdt_addr= 0x4000
> scriptaddr = 0x4020
> loadaddr= 0x4020
> pxefile_addr_r = 0x4030
> kernel_addr_r = 0x4040
> ramdisk_addr_r = 0x4400
> fdtcontroladdr = 465e5ea0
>
> arch/arm/Kconfig | 1 +
> board/emulation/qemu-arm/Kconfig | 4
> 2 files changed, 5 insertions(+)
>
Reviewed-by: Bin Meng
Re: [PATCH 1/3] arm: qemu: Enable Bochs video support
On Wed, Aug 9, 2023 at 3:19 AM Alper Nebi Yasak
wrote:
>
> Commit 716161663ec49 ("riscv: qemu: Enable Bochs video support") enables
> a video console for QEMU RISC-V virtual machines using an emulated Bochs
> VGA card. Similarly, enable it for ARM virtual machines as well.
>
> Signed-off-by: Alper Nebi Yasak
> ---
>
> arch/arm/Kconfig | 4
> board/emulation/qemu-arm/qemu-arm.env | 3 +++
> doc/board/emulation/qemu-arm.rst | 4
> 3 files changed, 11 insertions(+)
>
Reviewed-by: Bin Meng
Re: [PATCH v2 0/9] x86: Fixes for distro booting
Hi Bin, Any word on this, please? I would like to get distros running in qemu and after that we still need to resolve the board_f problem upstream. Regards, Simon On Sun, 6 Aug 2023 at 19:35, Bin Meng wrote: > > Hi Simon, > > On Sun, Aug 6, 2023 at 11:02 PM Simon Glass wrote: > > > > Hi Bin, > > > > On Thu, 3 Aug 2023 at 05:05, Bin Meng wrote: > > > > > > On Mon, Jul 31, 2023 at 1:16 AM Simon Glass wrote: > > > > > > > > This series collects together various fixes found whn testing out > > > > booting > > > > of distros using QEMU on x86. Together they improve functionality, but > > > > it > > > > is not perfect yet. Some notes are included as to the current state. > > > > > > > > Changes in v2: > > > > Use SPL_ instead of SPL_TPL_ > > > > - Drop unnecessary IS_ENABLED(CONFIG_X86) > > > > - Add a note that this reproduces reliably > > > > - Add a Kconfig as the suggested conditional did not work > > > > - Use sizeof(struct vesa_mode_info) instead > > > > > > > > Simon Glass (9): > > > > x86: spl: Drop unwanted debug() > > > > video: Tidy up Makefile rule for video > > > > x86: Run QEMU machine setup in SPL > > > > Revert "x86: Switch QEMU over to use the bochs driver" > > > > board_f: Fix corruption of relocaddr > > > > x86: Correct copying of BIOS mode information > > > > video: Add a Kconfig option for SPL video handoff > > > > x86: Enable useful options for qemu-86 > > > > x86: Update qemu documentation > > > > > > > > arch/x86/cpu/qemu/Kconfig| 2 +- > > > > arch/x86/cpu/qemu/qemu.c | 2 +- > > > > arch/x86/include/asm/qemu.h | 14 + > > > > arch/x86/lib/bios.c | 2 +- > > > > arch/x86/lib/spl.c | 4 +- > > > > common/board_f.c | 6 +-- > > > > configs/qemu-x86_64_defconfig| 4 ++ > > > > configs/qemu-x86_defconfig | 12 + > > > > doc/board/emulation/qemu-x86.rst | 88 ++-- > > > > drivers/Makefile | 4 +- > > > > drivers/video/Kconfig| 18 +++ > > > > drivers/video/video-uclass.c | 2 +- > > > > 12 files changed, 144 insertions(+), 14 deletions(-) > > > > create mode 100644 arch/x86/include/asm/qemu.h > > > > > > > > > > series applied to u-boot-x86, thanks! > > > > Are you planning to send another x86 pull request soon? You could drop > > the board_f patch and let Tom deal with it. > > Yes, I plan to send another PR soon. > > Regards, > Bin
[PATCH 3/4] at91: sam9x60-curiosity: Add proper LED support
Copied dts pieces from Linux Kernel. Support is optional for now, to
make it work the following options have to be enabled: CONFIG_LED,
CONFIG_LED_GPIO, CONFIG_CMD_LED.
Signed-off-by: Alexander Dahl
---
.../dts/at91-sam9x60_curiosity-u-boot.dtsi| 18 +++
arch/arm/dts/at91-sam9x60_curiosity.dts | 30 +++
.../sam9x60_curiosity/sam9x60_curiosity.c | 18 +++
3 files changed, 66 insertions(+)
diff --git a/arch/arm/dts/at91-sam9x60_curiosity-u-boot.dtsi
b/arch/arm/dts/at91-sam9x60_curiosity-u-boot.dtsi
index a1b76e94d1..dd4623311c 100644
--- a/arch/arm/dts/at91-sam9x60_curiosity-u-boot.dtsi
+++ b/arch/arm/dts/at91-sam9x60_curiosity-u-boot.dtsi
@@ -20,6 +20,24 @@
chosen {
bootph-all;
};
+
+ config {
+ u-boot,boot-led = "blue";
+ };
+
+ leds {
+ led-red {
+ default-state = "off";
+ };
+
+ led-green {
+ default-state = "off";
+ };
+
+ led-blue {
+ default-state = "off";
+ };
+ };
};
{
diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts
b/arch/arm/dts/at91-sam9x60_curiosity.dts
index 2547b4527c..244cacfe1b 100644
--- a/arch/arm/dts/at91-sam9x60_curiosity.dts
+++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
@@ -33,6 +33,28 @@
};
};
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio_leds>;
+
+ led-red {
+ label = "red";
+ gpios = < 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-green {
+ label = "green";
+ gpios = < 19 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-blue {
+ label = "blue";
+ gpios = < 21 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
onewire_tm: onewire {
gpios = < 14 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
@@ -167,6 +189,14 @@
};
};
+ leds {
+ pinctrl_gpio_leds: gpio-leds {
+ atmel,pins = ;
+ };
+ };
+
nand {
pinctrl_nand_oe_we: nand-oe-we-0 {
atmel,pins =
diff --git a/board/atmel/sam9x60_curiosity/sam9x60_curiosity.c
b/board/atmel/sam9x60_curiosity/sam9x60_curiosity.c
index 0fe0de9fde..f53d359404 100644
--- a/board/atmel/sam9x60_curiosity/sam9x60_curiosity.c
+++ b/board/atmel/sam9x60_curiosity/sam9x60_curiosity.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -18,6 +19,7 @@
#include
#include
#include
+#include
extern void at91_pda_detect(void);
@@ -27,9 +29,25 @@ void at91_prepare_cpu_var(void);
static void board_leds_init(void)
{
+#if CONFIG_IS_ENABLED(LED)
+ const char *led_name;
+ struct udevice *dev;
+ int ret;
+
+ led_name = ofnode_conf_read_str("u-boot,boot-led");
+ if (!led_name)
+ return;
+
+ ret = led_get_by_label(led_name, );
+ if (ret)
+ return;
+
+ led_set_state(dev, LEDST_ON);
+#else
at91_set_pio_output(AT91_PIO_PORTD, 17, 0); /* LED RED */
at91_set_pio_output(AT91_PIO_PORTD, 19, 0); /* LED GREEN */
at91_set_pio_output(AT91_PIO_PORTD, 21, 1); /* LED BLUE */
+#endif
}
int board_late_init(void)
--
2.30.2
[PATCH 4/4] ARM: dts: at91: sam9x60-curiosity: Add user button support
Copied as is from Linux Kernel. Works out of the box if the following
config options are enabled: CONFIG_BUTTON, CONFIG_BUTTON_GPIO,
CONFIG_CMD_BUTTON, CONFIG_DM_GPIO.
Signed-off-by: Alexander Dahl
---
arch/arm/dts/at91-sam9x60_curiosity.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts
b/arch/arm/dts/at91-sam9x60_curiosity.dts
index 244cacfe1b..99867d2bf8 100644
--- a/arch/arm/dts/at91-sam9x60_curiosity.dts
+++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
@@ -7,6 +7,7 @@
* Author: Durai Manickam KR
*/
/dts-v1/;
+#include
#include
#include "sam9x60.dtsi"
@@ -33,6 +34,19 @@
};
};
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <_key_gpio_default>;
+
+ button-user {
+ label = "PB_USER";
+ gpios = < 29 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ wakeup-source;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -189,6 +203,12 @@
};
};
+ gpio-keys {
+ pinctrl_key_gpio_default: pinctrl-key-gpio {
+ atmel,pins = ;
+ };
+ };
+
leds {
pinctrl_gpio_leds: gpio-leds {
atmel,pins =
[PATCH 0/4] at91: sam9x60-curiosity: Misc improvements
Hei hei, while working with the sam9x60-curiosity board I noticed some things still have rough edges on U-Boot shell for that device. With these patches (and some more config options enabled), the following commands now work as expected: reset, led, button. The whole series is based on atmel/next. Note: some things here might be useful to implement for other Microchip boards. However I currently only have this one board, and I'm not sure if this is a direction appreciated by Microchip? So you might see all this as suggestion. Greets Alex Alexander Dahl (4): configs: at91: sam9x60_curiosity: Sync both defconfig variants configs: at91: sam9x60: Switch to new reset driver at91: sam9x60-curiosity: Add proper LED support ARM: dts: at91: sam9x60-curiosity: Add user button support .../dts/at91-sam9x60_curiosity-u-boot.dtsi| 18 +++ arch/arm/dts/at91-sam9x60_curiosity.dts | 50 +++ .../sam9x60_curiosity/sam9x60_curiosity.c | 18 +++ configs/sam9x60_curiosity_mmc1_defconfig | 4 +- configs/sam9x60_curiosity_mmc_defconfig | 15 +- configs/sam9x60ek_mmc_defconfig | 4 +- configs/sam9x60ek_nandflash_defconfig | 4 +- configs/sam9x60ek_qspiflash_defconfig | 4 +- 8 files changed, 108 insertions(+), 9 deletions(-) base-commit: 87d1cac49d265ead979ff75bda36c45fa9025193 -- 2.30.2
[PATCH 2/4] configs: at91: sam9x60: Switch to new reset driver
Since commit 61040097a9d1 ("reset: at91: Add reset driver for basic
assert/deassert operations") the compatible "microchip,sam9x60-rstc" for
the sam9x60 reset controller in sam9x60.dtsi is not handled by
CONFIG_SYSRESET_AT91 anymore, but by CONFIG_RESET_AT91 now. This
resulted in the following error message, when trying to reset from
U-Boot shell:
U-Boot> reset
resetting ...
System reset not supported on this platform
### ERROR ### Please RESET the board ###
Fixed with the switch to the new driver. Tested on sam9x60-curiosity
board. Defconfigs for sam9x60ek adapted in the same way, but without
testing. These should be all sam9x60 boards affected in U-Boot here.
Signed-off-by: Alexander Dahl
---
configs/sam9x60_curiosity_mmc1_defconfig | 4 ++--
configs/sam9x60_curiosity_mmc_defconfig | 4 ++--
configs/sam9x60ek_mmc_defconfig | 4 ++--
configs/sam9x60ek_nandflash_defconfig| 4 ++--
configs/sam9x60ek_qspiflash_defconfig| 4 ++--
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/configs/sam9x60_curiosity_mmc1_defconfig
b/configs/sam9x60_curiosity_mmc1_defconfig
index 21b2cc2edd..e8781b363b 100644
--- a/configs/sam9x60_curiosity_mmc1_defconfig
+++ b/configs/sam9x60_curiosity_mmc1_defconfig
@@ -14,6 +14,7 @@ CONFIG_DM_GPIO=y
CONFIG_DEFAULT_DEVICE_TREE="at91-sam9x60_curiosity"
CONFIG_SYS_PROMPT="U-Boot> "
CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_DM_RESET=y
CONFIG_DEBUG_UART_BASE=0xf200
CONFIG_DEBUG_UART_CLOCK=2
CONFIG_DEBUG_UART_BOARD_INIT=y
@@ -79,11 +80,10 @@ CONFIG_PHY_MICREL=y
CONFIG_MACB=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_AT91=y
+CONFIG_RESET_AT91=y
CONFIG_DM_SERIAL=y
CONFIG_DEBUG_UART_ANNOUNCE=y
CONFIG_ATMEL_USART=y
-CONFIG_SYSRESET=y
-CONFIG_SYSRESET_AT91=y
CONFIG_TIMER=y
CONFIG_MCHP_PIT64B_TIMER=y
CONFIG_W1=y
diff --git a/configs/sam9x60_curiosity_mmc_defconfig
b/configs/sam9x60_curiosity_mmc_defconfig
index 269f015989..0f57588d8b 100644
--- a/configs/sam9x60_curiosity_mmc_defconfig
+++ b/configs/sam9x60_curiosity_mmc_defconfig
@@ -14,6 +14,7 @@ CONFIG_DM_GPIO=y
CONFIG_DEFAULT_DEVICE_TREE="at91-sam9x60_curiosity"
CONFIG_SYS_PROMPT="U-Boot> "
CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_DM_RESET=y
CONFIG_DEBUG_UART_BASE=0xf200
CONFIG_DEBUG_UART_CLOCK=2
CONFIG_DEBUG_UART_BOARD_INIT=y
@@ -79,11 +80,10 @@ CONFIG_PHY_MICREL=y
CONFIG_MACB=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_AT91=y
+CONFIG_RESET_AT91=y
CONFIG_DM_SERIAL=y
CONFIG_DEBUG_UART_ANNOUNCE=y
CONFIG_ATMEL_USART=y
-CONFIG_SYSRESET=y
-CONFIG_SYSRESET_AT91=y
CONFIG_TIMER=y
CONFIG_MCHP_PIT64B_TIMER=y
CONFIG_W1=y
diff --git a/configs/sam9x60ek_mmc_defconfig b/configs/sam9x60ek_mmc_defconfig
index 2a1399748c..446caceba0 100644
--- a/configs/sam9x60ek_mmc_defconfig
+++ b/configs/sam9x60ek_mmc_defconfig
@@ -15,6 +15,7 @@ CONFIG_DM_GPIO=y
CONFIG_DEFAULT_DEVICE_TREE="sam9x60ek"
CONFIG_SYS_PROMPT="U-Boot> "
CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_DM_RESET=y
CONFIG_DEBUG_UART_BASE=0xf200
CONFIG_DEBUG_UART_CLOCK=2
CONFIG_DEBUG_UART_BOARD_INIT=y
@@ -87,14 +88,13 @@ CONFIG_PHY_MICREL=y
CONFIG_MACB=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_AT91=y
+CONFIG_RESET_AT91=y
CONFIG_DM_SERIAL=y
CONFIG_DEBUG_UART_ANNOUNCE=y
CONFIG_ATMEL_USART=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_ATMEL_QSPI=y
-CONFIG_SYSRESET=y
-CONFIG_SYSRESET_AT91=y
CONFIG_TIMER=y
CONFIG_ATMEL_PIT_TIMER=y
CONFIG_W1=y
diff --git a/configs/sam9x60ek_nandflash_defconfig
b/configs/sam9x60ek_nandflash_defconfig
index c6c4686658..acaa16ee49 100644
--- a/configs/sam9x60ek_nandflash_defconfig
+++ b/configs/sam9x60ek_nandflash_defconfig
@@ -14,6 +14,7 @@ CONFIG_DM_GPIO=y
CONFIG_DEFAULT_DEVICE_TREE="sam9x60ek"
CONFIG_SYS_PROMPT="U-Boot> "
CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_DM_RESET=y
CONFIG_DEBUG_UART_BASE=0xf200
CONFIG_DEBUG_UART_CLOCK=2
CONFIG_DEBUG_UART_BOARD_INIT=y
@@ -89,14 +90,13 @@ CONFIG_PHY_MICREL=y
CONFIG_MACB=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_AT91=y
+CONFIG_RESET_AT91=y
CONFIG_DM_SERIAL=y
CONFIG_DEBUG_UART_ANNOUNCE=y
CONFIG_ATMEL_USART=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_ATMEL_QSPI=y
-CONFIG_SYSRESET=y
-CONFIG_SYSRESET_AT91=y
CONFIG_TIMER=y
CONFIG_ATMEL_PIT_TIMER=y
CONFIG_W1=y
diff --git a/configs/sam9x60ek_qspiflash_defconfig
b/configs/sam9x60ek_qspiflash_defconfig
index ef2e2db8b8..6fb79214e5 100644
--- a/configs/sam9x60ek_qspiflash_defconfig
+++ b/configs/sam9x60ek_qspiflash_defconfig
@@ -14,6 +14,7 @@ CONFIG_DM_GPIO=y
CONFIG_DEFAULT_DEVICE_TREE="sam9x60ek"
CONFIG_SYS_PROMPT="U-Boot> "
CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_DM_RESET=y
CONFIG_DEBUG_UART_BASE=0xf200
CONFIG_DEBUG_UART_CLOCK=2
CONFIG_DEBUG_UART_BOARD_INIT=y
@@ -88,14 +89,13 @@ CONFIG_PHY_MICREL=y
CONFIG_MACB=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_AT91=y
+CONFIG_RESET_AT91=y
CONFIG_DM_SERIAL=y
CONFIG_DEBUG_UART_ANNOUNCE=y
CONFIG_ATMEL_USART=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_ATMEL_QSPI=y
-CONFIG_SYSRESET=y
-CONFIG_SYSRESET_AT91=y
CONFIG_TIMER=y
CONFIG_ATMEL_PIT_TIMER=y
[PATCH 1/4] configs: at91: sam9x60_curiosity: Sync both defconfig variants
The board has two SD card slots and we have two defconfigs for booting from either the first (micro SD) named 'sam9x60_curiosity_mmc_defconfig' or the second (full size SD) named 'sam9x60_curiosity_mmc1_defconfig'. For comparable Microchip boards (sama5d27-som1-ek, sama5d29-curiosity, sama7g5ek) with two card slots the defconfigs only differ in BOOTARGS, BOOTCOMMAND, and ENV_FAT_DEVICE_AND_PART and the same should be the case for sam9x60_curiosity. Here the 'mmc1' config has more options enabled to support the raw NAND flash populated on the board, so the 'mmc' config (for mmc0) was adapted by enabling additional options, instead of removing options from mmc1. Signed-off-by: Alexander Dahl --- configs/sam9x60_curiosity_mmc_defconfig | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/configs/sam9x60_curiosity_mmc_defconfig b/configs/sam9x60_curiosity_mmc_defconfig index 10937d67d7..269f015989 100644 --- a/configs/sam9x60_curiosity_mmc_defconfig +++ b/configs/sam9x60_curiosity_mmc_defconfig @@ -23,7 +23,7 @@ CONFIG_FIT=y CONFIG_SD_BOOT=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="mem=128M console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait" +CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait" CONFIG_USE_BOOTCOMMAND=y CONFIG_BOOTCOMMAND="fatload mmc 0:1 0x2100 at91-sam9x60_curiosity.dtb; fatload mmc 0:1 0x2200 zImage; bootz 0x2200 - 0x2100" CONFIG_SYS_CONSOLE_IS_IN_ENV=y @@ -38,6 +38,8 @@ CONFIG_CMD_DM=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_NAND=y +CONFIG_CMD_NAND_TRIMFFS=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y CONFIG_BOOTP_BOOTFILESIZE=y @@ -50,6 +52,8 @@ CONFIG_OF_CONTROL=y CONFIG_ENV_IS_IN_FAT=y CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_REGMAP=y +CONFIG_SYSCON=y CONFIG_CLK=y CONFIG_CLK_CCF=y CONFIG_CLK_AT91=y @@ -60,10 +64,17 @@ CONFIG_CPU=y CONFIG_AT91_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_AT91=y +CONFIG_ATMEL_EBI=y +CONFIG_MFD_ATMEL_SMC=y CONFIG_I2C_EEPROM=y CONFIG_MICROCHIP_FLEXCOM=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ATMEL=y +CONFIG_MTD=y +CONFIG_DM_MTD=y +CONFIG_MTD_RAW_NAND=y +CONFIG_DM_NAND_ATMEL=y +CONFIG_SYS_NAND_ONFI_DETECTION=y CONFIG_PHY_MICREL=y CONFIG_MACB=y CONFIG_PINCTRL=y @@ -71,6 +82,8 @@ CONFIG_PINCTRL_AT91=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_ATMEL_USART=y +CONFIG_SYSRESET=y +CONFIG_SYSRESET_AT91=y CONFIG_TIMER=y CONFIG_MCHP_PIT64B_TIMER=y CONFIG_W1=y -- 2.30.2
Re: [PATCH v11 3/8] tpm: Support boot measurements
On 8/9/23 05:43, Ilias Apalodimas wrote: On Wed, 9 Aug 2023 at 13:42, Heinrich Schuchardt wrote: On 8/9/23 10:34, Ilias Apalodimas wrote: Hi Eddie On Mon, Aug 07, 2023 at 02:25:37PM -0500, Eddie James wrote: Add TPM2 functions to support boot measurement. This includes starting up the TPM, initializing/appending the event log, and measuring the U-Boot version. Much of the code was used in the EFI subsystem, so remove it there and use the common functions. Signed-off-by: Eddie James --- Changes since v10: - Fix compile warning for armv7 (thanks Ilias) This doesn't apply cleanly and I think it's because of commit d12c3efe53107. This was merged after my rebase. Can you rebase on top of -master and resend? Tom has started moving new stuff into next as the merge window is closed. Ah good point, I was going to let this soak on -next anyway. So please rebase against -next I did base this series on next actually, so it should apply there already (unless there are conflicting changes since Monday). Please let me know if I do need to rebase it. Thanks, Eddie Thanks /Ilias Best regards Heinrich
[PATCH v4 3/3] riscv: cpu: jh7110: Select SPL_ZERO_MEM_BEFORE_USE
Add Kconfig item for Starfive JH7110 to select SPL_ZERO_MEM_BEFORE_USE. Signed-off-by: Bo Gan Signed-off-by: Shengyu Qu Reviewed-by: Leo Yu-Chi Liang --- arch/riscv/cpu/jh7110/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/cpu/jh7110/Kconfig b/arch/riscv/cpu/jh7110/Kconfig index 4d9581165b..2e26d0731f 100644 --- a/arch/riscv/cpu/jh7110/Kconfig +++ b/arch/riscv/cpu/jh7110/Kconfig @@ -13,6 +13,7 @@ config STARFIVE_JH7110 select SUPPORT_SPL select SPL_RAM if SPL select SPL_STARFIVE_DDR + select SPL_ZERO_MEM_BEFORE_USE select PINCTRL_STARFIVE_JH7110 imply MMC imply MMC_BROKEN_CD -- 2.41.0
[PATCH v4 2/3] riscv: Add SPL_ZERO_MEM_BEFORE_USE implementation
Add the actual support code for SPL_ZERO_MEM_BEFORE_USE and remove
existing Starfive JH7110's L2 LIM clean code, since existing code has
following issues:
1. Each hart (in the middle of a function call) overwriting its own
stack and other harts' stacks.
(data-race and data-corruption)
2. Lottery winner hart can be doing "board_init_f_init_reserve",
while other harts are in the middle of zeroing L2 LIM.
(data-race)
Signed-off-by: Bo Gan
Signed-off-by: Shengyu Qu
---
Changes since v2:
- Fix typo (ZERO_MEM_BEFORE_USE to SPL_ZERO_MEM_BEFORE_USE)
Changes since v3:
- Revert v3's fix since original implementation is actually right
---
arch/riscv/cpu/jh7110/spl.c | 25 -
arch/riscv/cpu/start.S | 12
common/init/board_init.c| 3 +++
3 files changed, 15 insertions(+), 25 deletions(-)
diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c
index 72adcefa0e..4047b10efe 100644
--- a/arch/riscv/cpu/jh7110/spl.c
+++ b/arch/riscv/cpu/jh7110/spl.c
@@ -13,7 +13,6 @@
#include
#define CSR_U74_FEATURE_DISABLE0x7c1
-#define L2_LIM_MEM_END 0x81FUL
DECLARE_GLOBAL_DATA_PTR;
@@ -59,9 +58,6 @@ int spl_soc_init(void)
void harts_early_init(void)
{
- ulong *ptr;
- u8 *tmp;
- ulong len, remain;
/*
* Feature Disable CSR
*
@@ -70,25 +66,4 @@ void harts_early_init(void)
*/
if (CONFIG_IS_ENABLED(RISCV_MMODE))
csr_write(CSR_U74_FEATURE_DISABLE, 0);
-
- /* clear L2 LIM memory
-* set __bss_end to 0x81F region to zero
-* The L2 Cache Controller supports ECC. ECC is applied to SRAM.
-* If it is not cleared, the ECC part is invalid, and an ECC error
-* will be reported when reading data.
-*/
- ptr = (ulong *)&__bss_end;
- len = L2_LIM_MEM_END - (ulong)&__bss_end;
- remain = len % sizeof(ulong);
- len /= sizeof(ulong);
-
- while (len--)
- *ptr++ = 0;
-
- /* clear the remain bytes */
- if (remain) {
- tmp = (u8 *)ptr;
- while (remain--)
- *tmp++ = 0;
- }
}
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 59d58a5a57..30cf674370 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -111,6 +111,18 @@ call_board_init_f:
* It's essential before any function call, otherwise, we get data-race.
*/
+/* clear stack if necessary */
+#if CONFIG_IS_ENABLED(ZERO_MEM_BEFORE_USE)
+clear_stack:
+ li t1, 1
+ sllit1, t1, CONFIG_STACK_SIZE_SHIFT
+ sub t1, sp, t1
+clear_stack_loop:
+ SREGzero, 0(t1) /* t1 is always 16 byte aligned */
+ addit1, t1, REGBYTES
+ blt t1, sp, clear_stack_loop
+#endif
+
call_board_init_f_0:
/* find top of reserve space */
#if CONFIG_IS_ENABLED(SMP)
diff --git a/common/init/board_init.c b/common/init/board_init.c
index 96ffb79a98..ab8c508ad8 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -162,6 +162,9 @@ void board_init_f_init_reserve(ulong base)
#if CONFIG_VAL(SYS_MALLOC_F_LEN)
/* go down one 'early malloc arena' */
gd->malloc_base = base;
+#if CONFIG_IS_ENABLED(ZERO_MEM_BEFORE_USE)
+ memset((void *)base, '\0', CONFIG_VAL(SYS_MALLOC_F_LEN));
+#endif
#endif
if (CONFIG_IS_ENABLED(SYS_REPORT_STACK_F_USAGE))
--
2.41.0
[PATCH v4 1/3] riscv: Kconfig: Add SPL_ZERO_MEM_BEFORE_USE
Add a Kconfig item to allow SPL to clear stack/GD/malloc area before using them. Signed-off-by: Bo Gan Signed-off-by: Shengyu Qu Reviewed-by: Leo Yu-Chi Liang --- arch/riscv/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 867cbcbe74..6771d8d919 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -64,6 +64,14 @@ config SPL_SYS_DCACHE_OFF help Do not enable data cache in SPL. +config SPL_ZERO_MEM_BEFORE_USE + bool "Zero memory before use" + depends on SPL + default n + help + Zero stack/GD/malloc area in SPL before using them, this is needed for + Sifive core devices that uses L2 cache to store SPL. + # board-specific options below source "board/AndesTech/ae350/Kconfig" source "board/emulation/qemu-riscv/Kconfig" -- 2.41.0
[PATCH v4 0/3] arch: riscv: jh7110: Correctly zero L2 LIM
This series is the second version of Bo Gan's L2 LIM series. Original author hasn't sent v2 for almost 2 months, so I decided to take over this series. Background information: JH7110 SPL runs in L2 LIM (2M in size mapped at 0x800). It consists of 16 0x2 sized regions, each one can be used as either L2 cache way or SRAM (not both). From top to bottom, there're ways 0-15. The way 0 is always enabled, at most 0x1e can be used. In SPL, we don't enable any cache ways, thus all 15 (except way 0) ways can be used. However, due to HW requirement, we must zero the LIM before use. This is because ECC is applied to LIM, and if not cleared first, the ECC part is invalid, which can trigger ECC errors when reading/writing data. There are several issues currently. We clear L2 LIM from __bss_end to 0x81F in `harts_early_init`. This is wrong because: 1. Each hart (in the middle of a function call) overwriting its own stack and other harts' stacks. (data-race and data-corruption) 2. Lottery winner hart can be doing `board_init_f_init_reserve`, while other harts're in the middle of zeroing L2 LIM. (data-race) To fix this, we split the job, such that there's one and only one owner of zeroing a specific region (No data-race). A new SPL config option `SPL_ZERO_MEM_BEFORE_USE` is introduced. Allowing The zeroing to happen in the same code path. (much easier to reason about). Changes since v1: - Separate single patch into several patches Changes since v2: - Fix typo (ZERO_MEM_BEFORE_USE to SPL_ZERO_MEM_BEFORE_USE) Changes since v3: - Revert v3's fix since original implementation is actually right Shengyu Qu (3): riscv: Kconfig: Add SPL_ZERO_MEM_BEFORE_USE riscv: Add SPL_ZERO_MEM_BEFORE_USE implementation riscv: cpu: jh7110: Select SPL_ZERO_MEM_BEFORE_USE arch/riscv/Kconfig| 8 arch/riscv/cpu/jh7110/Kconfig | 1 + arch/riscv/cpu/jh7110/spl.c | 25 - arch/riscv/cpu/start.S| 12 common/init/board_init.c | 3 +++ 5 files changed, 24 insertions(+), 25 deletions(-) -- 2.41.0
Re: [PATCH v3 2/3] riscv: Add SPL_ZERO_MEM_BEFORE_USE implementation
Hi Leo,
Seems you are right. I'll send v4 to fix this. Thank you.
Best regards,
Shengyu
Hi Shengyu,
On Tue, Aug 08, 2023 at 08:39:56PM +0800, Shengyu Qu wrote:
Add the actual support code for SPL_ZERO_MEM_BEFORE_USE and remove
existing Starfive JH7110's L2 LIM clean code, since existing code has
following issues:
1. Each hart (in the middle of a function call) overwriting its own
stack and other harts' stacks.
(data-race and data-corruption)
2. Lottery winner hart can be doing "board_init_f_init_reserve",
while other harts are in the middle of zeroing L2 LIM.
(data-race)
Signed-off-by: Bo Gan
Signed-off-by: Shengyu Qu
---
Changes since v2:
- Fix typo (ZERO_MEM_BEFORE_USE to SPL_ZERO_MEM_BEFORE_USE)
---
arch/riscv/cpu/jh7110/spl.c | 25 -
arch/riscv/cpu/start.S | 12
common/init/board_init.c| 3 +++
3 files changed, 15 insertions(+), 25 deletions(-)
diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c
index 72adcefa0e..4047b10efe 100644
--- a/arch/riscv/cpu/jh7110/spl.c
+++ b/arch/riscv/cpu/jh7110/spl.c
@@ -13,7 +13,6 @@
#include
#define CSR_U74_FEATURE_DISABLE 0x7c1
-#define L2_LIM_MEM_END 0x81FUL
DECLARE_GLOBAL_DATA_PTR;
@@ -59,9 +58,6 @@ int spl_soc_init(void)
void harts_early_init(void)
{
- ulong *ptr;
- u8 *tmp;
- ulong len, remain;
/*
* Feature Disable CSR
*
@@ -70,25 +66,4 @@ void harts_early_init(void)
*/
if (CONFIG_IS_ENABLED(RISCV_MMODE))
csr_write(CSR_U74_FEATURE_DISABLE, 0);
-
- /* clear L2 LIM memory
-* set __bss_end to 0x81F region to zero
-* The L2 Cache Controller supports ECC. ECC is applied to SRAM.
-* If it is not cleared, the ECC part is invalid, and an ECC error
-* will be reported when reading data.
-*/
- ptr = (ulong *)&__bss_end;
- len = L2_LIM_MEM_END - (ulong)&__bss_end;
- remain = len % sizeof(ulong);
- len /= sizeof(ulong);
-
- while (len--)
- *ptr++ = 0;
-
- /* clear the remain bytes */
- if (remain) {
- tmp = (u8 *)ptr;
- while (remain--)
- *tmp++ = 0;
- }
}
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 59d58a5a57..930309d8d2 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -111,6 +111,18 @@ call_board_init_f:
* It's essential before any function call, otherwise, we get data-race.
*/
+/* clear stack if necessary */
+#if CONFIG_IS_ENABLED(SPL_ZERO_MEM_BEFORE_USE)
I think what you have in v2 patch was the correct one.
Could you refer to include/linux/kconfig.h to check if
this usage fits your expectation ?
+clear_stack:
+ li t1, 1
+ sllit1, t1, CONFIG_STACK_SIZE_SHIFT
+ sub t1, sp, t1
+clear_stack_loop:
+ SREGzero, 0(t1) /* t1 is always 16 byte aligned */
+ addit1, t1, REGBYTES
+ blt t1, sp, clear_stack_loop
+#endif
+
call_board_init_f_0:
/* find top of reserve space */
#if CONFIG_IS_ENABLED(SMP)
diff --git a/common/init/board_init.c b/common/init/board_init.c
index 96ffb79a98..51d9ec9a13 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -162,6 +162,9 @@ void board_init_f_init_reserve(ulong base)
#if CONFIG_VAL(SYS_MALLOC_F_LEN)
/* go down one 'early malloc arena' */
gd->malloc_base = base;
+#if CONFIG_IS_ENABLED(SPL_ZERO_MEM_BEFORE_USE)
Ditto.
Best regards,
Leo
+ memset((void *)base, '\0', CONFIG_VAL(SYS_MALLOC_F_LEN));
+#endif
#endif
if (CONFIG_IS_ENABLED(SYS_REPORT_STACK_F_USAGE))
--
2.41.0
OpenPGP_0xE3520CC91929C8E7.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] usb: dwc3: Fix remove function if there is no ulpi_reset gpio
On 8/9/23 05:33, Venkatesh Yadav Abbarapu wrote:
As ulpi_reset gpio is now optional, we need to check it when doing
the 'dwc3_generic_remove' function. Check if it is declared before
accessing the ulpi_reset.
Fixes: 237d1f60b1d ("usb: dwc3: Use the devm_gpiod_get_optional()
API for reset gpio")
Applied, thanks
Re: [U-BOOT-TEST-HOOKS][PATCH v2 1/1] qemu-riscv: enable virtio-rng-device
On Mon, 31 Jul 2023 11:05:06 +0200, Heinrich Schuchardt wrote: > Linux' KASLR uses the EFI_RNG_PROTOCOL as entropy source. We should > enable CONFIG_DM_RNG in U-Boot. For the EFI unit test for the protocol to > succeed a virtio RNG device has to be provided when invoking QEMU. > > Applied, thanks! [1/1] qemu-riscv: enable virtio-rng-device commit: 2d8182047358fee6f36ebb887c19e573396cd23a Best regards, -- Tom
Re: [PATCH v2 1/2] arm64: dts: rockchip: Sync DT from linux-next
Hi Kever,
On Wed, 26 Jul 2023 at 13:55, Jagan Teki wrote:
>
> On Wed, 26 Jul 2023 at 13:42, Kever Yang wrote:
> >
> > Hi Jagan,
> >
> > On 2023/7/19 16:17, Jagan Teki wrote:
> > > Sync the linux-next from below commit,
> > > commit <1642bf66e270> ("arm64: dts: rockchip: add USB2 to
> > > rk3588s-rock5a")
> >
> > How much difference for the linux-next and the latest linux release version?
> >
> > It would be better if we can have sync with a release version unless
> > many important patches are on the way.
>
> My initial idea is to pick standard rc but there are some usb patches
> are on top of linux-next so I took those.
>
>
> >
> > >
> > > Also rops the duplicate usb nodes from rk3588s-u-boot.dtsi
> > >
> > > Signed-off-by: Jagan Teki
> > > ---
> > > Changes for v2:
> > > - Keep sdhci modes for ROCK5B
> > >
> > > arch/arm/dts/rk3588-edgeble-neu6a.dtsi | 1 -
> > > arch/arm/dts/rk3588-edgeble-neu6b-io.dts | 66 +++
> > > arch/arm/dts/rk3588-edgeble-neu6b.dtsi | 359 ++-
> > > arch/arm/dts/rk3588-evb1-v10.dts | 720 ++-
> > > arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 7 -
> > > arch/arm/dts/rk3588-rock-5b.dts | 578 +-
> > > arch/arm/dts/rk3588.dtsi | 112
> > > arch/arm/dts/rk3588s-u-boot.dtsi | 119
> > > arch/arm/dts/rk3588s.dtsi| 499 +++-
> > > include/dt-bindings/ata/ahci.h | 20 +
> >
> > Why need this ahci header file in the patch?
>
> linux SATA node rk3588.dtsi is including this.
I don't understand whether it was ignored or forgotten. As I said
before, this sync would require in the tree in MW or earliest for
better testing functions. Please let me know your comments if you
planned anything.
Thanks,
Jagan.
[PATCH] usb: dwc3: Fix remove function if there is no ulpi_reset gpio
As ulpi_reset gpio is now optional, we need to check it when doing
the 'dwc3_generic_remove' function. Check if it is declared before
accessing the ulpi_reset.
Fixes: 237d1f60b1d ("usb: dwc3: Use the devm_gpiod_get_optional()
API for reset gpio")
Reported-by: Thomas Nizan
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/usb/dwc3/dwc3-generic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index b3ed728fd8..7f0af05855 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -145,7 +145,8 @@ static int dwc3_generic_remove(struct udevice *dev,
struct dwc3 *dwc3 = >dwc3;
if (CONFIG_IS_ENABLED(DM_GPIO) &&
- device_is_compatible(dev->parent, "xlnx,zynqmp-dwc3")) {
+ device_is_compatible(dev->parent, "xlnx,zynqmp-dwc3") &&
+ priv->ulpi_reset) {
struct gpio_desc *ulpi_reset = priv->ulpi_reset;
dm_gpio_free(ulpi_reset->dev, ulpi_reset);
--
2.17.1
[PATCH] arm_ffa: use debug logs
replace info logs with debug logs
Signed-off-by: Abdellatif El Khlifi
Cc: Tom Rini
Cc: Simon Glass
---
doc/arch/arm64.ffa.rst | 2 +-
drivers/firmware/arm-ffa/arm-ffa-uclass.c | 4 ++--
drivers/firmware/arm-ffa/arm-ffa.c | 2 +-
drivers/firmware/arm-ffa/ffa-emul-uclass.c | 2 +-
drivers/firmware/arm-ffa/sandbox_ffa.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/doc/arch/arm64.ffa.rst b/doc/arch/arm64.ffa.rst
index 325fb80346..4ecdc31716 100644
--- a/doc/arch/arm64.ffa.rst
+++ b/doc/arch/arm64.ffa.rst
@@ -231,7 +231,7 @@ Please refer the command documentation at
:doc:`../usage/cmd/armffa`
Example of boot logs with FF-A enabled
--
-For example, when using FF-A with Corstone-1000 the logs are as follows:
+For example, when using FF-A with Corstone-1000, debug logs enabled, the
output is as follows:
::
diff --git a/drivers/firmware/arm-ffa/arm-ffa-uclass.c
b/drivers/firmware/arm-ffa/arm-ffa-uclass.c
index ffa9d81fa7..8c17b19eaf 100644
--- a/drivers/firmware/arm-ffa/arm-ffa-uclass.c
+++ b/drivers/firmware/arm-ffa/arm-ffa-uclass.c
@@ -201,11 +201,11 @@ int ffa_get_version_hdlr(struct udevice *dev)
major = GET_FFA_MAJOR_VERSION(res.a0);
minor = GET_FFA_MINOR_VERSION(res.a0);
- log_info("FF-A driver %d.%d\nFF-A framework %d.%d\n",
+ log_debug("FF-A driver %d.%d\nFF-A framework %d.%d\n",
FFA_MAJOR_VERSION, FFA_MINOR_VERSION, major, minor);
if (major == FFA_MAJOR_VERSION && minor >= FFA_MINOR_VERSION) {
- log_info("FF-A versions are compatible\n");
+ log_debug("FF-A versions are compatible\n");
if (dev) {
uc_priv = dev_get_uclass_priv(dev);
diff --git a/drivers/firmware/arm-ffa/arm-ffa.c
b/drivers/firmware/arm-ffa/arm-ffa.c
index 68df75bd9e..ee0bf9a55b 100644
--- a/drivers/firmware/arm-ffa/arm-ffa.c
+++ b/drivers/firmware/arm-ffa/arm-ffa.c
@@ -42,7 +42,7 @@ static bool arm_ffa_discover(struct udevice *dev)
{
int ret;
- log_info("Arm FF-A framework discovery\n");
+ log_debug("Arm FF-A framework discovery\n");
ret = ffa_get_version_hdlr(dev);
if (ret)
diff --git a/drivers/firmware/arm-ffa/ffa-emul-uclass.c
b/drivers/firmware/arm-ffa/ffa-emul-uclass.c
index 5562bbaac3..4bf9f6041f 100644
--- a/drivers/firmware/arm-ffa/ffa-emul-uclass.c
+++ b/drivers/firmware/arm-ffa/ffa-emul-uclass.c
@@ -695,7 +695,7 @@ int ffa_emul_find(struct udevice *dev, struct udevice
**emulp)
return ret;
}
- log_info("FF-A emulator ready to use\n");
+ log_debug("FF-A emulator ready to use\n");
return 0;
}
diff --git a/drivers/firmware/arm-ffa/sandbox_ffa.c
b/drivers/firmware/arm-ffa/sandbox_ffa.c
index ef9491ccea..11142429c0 100644
--- a/drivers/firmware/arm-ffa/sandbox_ffa.c
+++ b/drivers/firmware/arm-ffa/sandbox_ffa.c
@@ -30,7 +30,7 @@ static int sandbox_ffa_discover(struct udevice *dev)
int ret;
struct udevice *emul;
- log_info("Emulated FF-A framework discovery\n");
+ log_debug("Emulated FF-A framework discovery\n");
ret = ffa_emul_find(dev, );
if (ret) {
--
2.25.1
[PATCH] riscv: Add Zbb support for building U-Boot
This patch adds ISA string to the -march to generate zbb instructions for U-Boot binaries, along with optimized string functions introduced from Linux kernel. Signed-off-by: Yu Chien Peter Lin --- arch/riscv/Kconfig | 92 + arch/riscv/Makefile | 5 +- arch/riscv/include/asm/string.h | 18 ++ arch/riscv/lib/Makefile | 3 + arch/riscv/lib/strcmp_zbb.S | 81 + arch/riscv/lib/strlen_zbb.S | 101 arch/riscv/lib/strncmp_zbb.S| 94 + 7 files changed, 393 insertions(+), 1 deletion(-) create mode 100644 arch/riscv/lib/strcmp_zbb.S create mode 100644 arch/riscv/lib/strlen_zbb.S create mode 100644 arch/riscv/lib/strncmp_zbb.S diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 867cbcbe74..49dd714e99 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -177,6 +177,98 @@ config RISCV_ISA_D riscv32 ABI from ilp32 to ilp32d and the riscv64 ABI from lp64 to lp64d. +config RISCV_ISA_ZBB + bool "Zbb extension support for bit manipulation instructions" + default n + help + Adds ZBB extension (basic bit manipulation) to the ISA subsets + that the toolchain is allowed to emit when building U-Boot. + The Zbb extension provides instructions to accelerate a number + of bit-specific operations (count bit population, sign extending, + bitrotation, etc) and enables optimized string routines. + +menu "Use assembly optimized implementation of string routines" + +config USE_ARCH_STRLEN + bool "Use an assembly optimized implementation of strlen" + default y + depends on RISCV_ISA_ZBB + help + Enable the generation of an optimized version of strlen using + Zbb extension. + +config SPL_USE_ARCH_STRLEN + bool "Use an assembly optimized implementation of strlen for SPL" + default y if USE_ARCH_STRLEN + depends on RISCV_ISA_ZBB + depends on SPL + help + Enable the generation of an optimized version of strlen using + Zbb extension. + +config TPL_USE_ARCH_STRLEN + bool "Use an assembly optimized implementation of strlen for TPL" + default y if USE_ARCH_STRLEN + depends on RISCV_ISA_ZBB + depends on TPL + help + Enable the generation of an optimized version of strlen using + Zbb extension. + +config USE_ARCH_STRCMP + bool "Use an assembly optimized implementation of strcmp" + default y + depends on RISCV_ISA_ZBB + help + Enable the generation of an optimized version of strcmp using + Zbb extension. + +config SPL_USE_ARCH_STRCMP + bool "Use an assembly optimized implementation of strcmp for SPL" + default y if USE_ARCH_STRCMP + depends on RISCV_ISA_ZBB + depends on SPL + help + Enable the generation of an optimized version of strcmp using + Zbb extension. + +config TPL_USE_ARCH_STRCMP + bool "Use an assembly optimized implementation of strcmp for TPL" + default y if USE_ARCH_STRCMP + depends on RISCV_ISA_ZBB + depends on TPL + help + Enable the generation of an optimized version of strcmp using + Zbb extension. + +config USE_ARCH_STRNCMP + bool "Use an assembly optimized implementation of strncmp" + default y + depends on RISCV_ISA_ZBB + help + Enable the generation of an optimized version of strncmp using + Zbb extension. + +config SPL_USE_ARCH_STRNCMP + bool "Use an assembly optimized implementation of strncmp for SPL" + default y if USE_ARCH_STRNCMP + depends on RISCV_ISA_ZBB + depends on SPL + help + Enable the generation of an optimized version of strncmp using + Zbb extension. + +config TPL_USE_ARCH_STRNCMP + bool "Use an assembly optimized implementation of strncmp for TPL" + default y if USE_ARCH_STRNCMP + depends on RISCV_ISA_ZBB + depends on TPL + help + Enable the generation of an optimized version of strncmp using + Zbb extension. + +endmenu + config RISCV_ISA_A def_bool y diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index 4963b5109b..b3ef87078b 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -24,6 +24,9 @@ endif ifeq ($(CONFIG_RISCV_ISA_C),y) ARCH_C = c endif +ifeq ($(CONFIG_RISCV_ISA_ZBB),y) + ARCH_ZBB = _zbb +endif ifeq ($(CONFIG_CMODEL_MEDLOW),y) CMODEL = medlow endif @@ -32,7 +35,7 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y) endif -RISCV_MARCH = $(ARCH_BASE)$(ARCH_A)$(ARCH_F)$(ARCH_D)$(ARCH_C) +RISCV_MARCH = $(ARCH_BASE)$(ARCH_A)$(ARCH_F)$(ARCH_D)$(ARCH_C)$(ARCH_ZBB) ABI = $(ABI_BASE)$(ABI_D) # Newer binutils versions default to ISA spec version 20191213 which moves some diff --git
Re: [PATCH v11 3/8] tpm: Support boot measurements
On Wed, 9 Aug 2023 at 13:42, Heinrich Schuchardt wrote: > > On 8/9/23 10:34, Ilias Apalodimas wrote: > > Hi Eddie > > > > > > On Mon, Aug 07, 2023 at 02:25:37PM -0500, Eddie James wrote: > >> Add TPM2 functions to support boot measurement. This includes > >> starting up the TPM, initializing/appending the event log, and > >> measuring the U-Boot version. Much of the code was used in the > >> EFI subsystem, so remove it there and use the common functions. > >> > >> Signed-off-by: Eddie James > >> --- > >> Changes since v10: > >> - Fix compile warning for armv7 (thanks Ilias) > >> > > > > This doesn't apply cleanly and I think it's because of commit > > d12c3efe53107. This was merged after my rebase. Can you rebase on top of > > -master and resend? > > Tom has started moving new stuff into next as the merge window is closed. Ah good point, I was going to let this soak on -next anyway. So please rebase against -next Thanks /Ilias > > Best regards > > Heinrich
Re: [PATCH v11 3/8] tpm: Support boot measurements
On 8/9/23 10:34, Ilias Apalodimas wrote: Hi Eddie On Mon, Aug 07, 2023 at 02:25:37PM -0500, Eddie James wrote: Add TPM2 functions to support boot measurement. This includes starting up the TPM, initializing/appending the event log, and measuring the U-Boot version. Much of the code was used in the EFI subsystem, so remove it there and use the common functions. Signed-off-by: Eddie James --- Changes since v10: - Fix compile warning for armv7 (thanks Ilias) This doesn't apply cleanly and I think it's because of commit d12c3efe53107. This was merged after my rebase. Can you rebase on top of -master and resend? Tom has started moving new stuff into next as the merge window is closed. Best regards Heinrich
Pull request for doc-2023-10-rc3
Dear Tom, The following changes since commit ef8336e2705fce2502383f25d68188c6b1f94dd0: Merge branch '2023-08-08-introuce-Arm-FF-A-support' (2023-08-08 15:23:16 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/doc-2023-10-rc3 for you to fetch changes up to fa43709b8d7aa30b6d1039dce854c5eea86f122f: doc: Begin adding a best practices document for board ports (2023-08-09 08:41:52 +0200) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/17254 Pull request for doc-2023-10-rc3 Documentation: * Update examples for imx8mp_evk * OpenOCD debugging guide for TI K3 boards * Explain using gadget devices on TI boards * Describe best practices for board ports Fabio Estevam (2): doc: imx8mp_evk: Remove unneeded export ATF_LOAD_ADDR line doc: imx8mp_evk: Use in-tree build in the example Jason Kacines (1): doc: board: ti: k3: Add a guide to debugging with OpenOCD Jit Loon Lim (1): doc: Add the link for the documentation of the .its Marcel Ziswiler (1): doc: board: toradex: fix verdin module output Miquel Raynal (1): doc: ti: Explain how the various gadget devices can be used Tom Rini (1): doc: Begin adding a best practices document for board ports doc/board/nxp/imx8mp_evk.rst | 17 +- doc/board/ti/am335x_evm.rst| 62 +++ doc/board/ti/am62x_sk.rst | 24 + doc/board/ti/am65x_evm.rst | 24 + doc/board/ti/img/openocd-overview.svg | 580 + doc/board/ti/j7200_evm.rst | 24 + doc/board/ti/j721e_evm.rst | 24 + doc/board/ti/k3.rst| 514 ++ doc/board/toradex/verdin-am62.rst | 111 ++-- doc/board/toradex/verdin-imx8mm.rst| 61 ++- doc/board/toradex/verdin-imx8mp.rst| 70 +-- doc/develop/board_best_practices.rst | 26 + doc/develop/index.rst | 1 + .../fpga/altera-socfpga-a10-fpga-mgr.txt | 3 + 14 files changed, 1418 insertions(+), 123 deletions(-) create mode 100644 doc/board/ti/img/openocd-overview.svg create mode 100644 doc/develop/board_best_practices.rst
Re: [PATCH v11 3/8] tpm: Support boot measurements
Hi Eddie
On Mon, Aug 07, 2023 at 02:25:37PM -0500, Eddie James wrote:
> Add TPM2 functions to support boot measurement. This includes
> starting up the TPM, initializing/appending the event log, and
> measuring the U-Boot version. Much of the code was used in the
> EFI subsystem, so remove it there and use the common functions.
>
> Signed-off-by: Eddie James
> ---
> Changes since v10:
> - Fix compile warning for armv7 (thanks Ilias)
>
This doesn't apply cleanly and I think it's because of commit
d12c3efe53107. This was merged after my rebase. Can you rebase on top of
-master and resend?
Thanks
/Ilias
> Changes since v8:
> - Fix log parsing again - any data corruption seen while replaying the
>event log was failing the entire measurement.
> - Added an option to ignore the existing log. This should only be used
>for systems that know that U-Boot is the first stage bootloader. This
>is necessary because the reserved memory region may persist through
>resets and so U-Boot attempts to append to the previous boot's log.
>
> Changes since v7:
> - Change name of tcg2_init_log and add more documentation
> - Add a check, when parsing the event log header, to ensure that the
>previous stage bootloader used all the active PCRs.
> - Change name of tcg2_log_find_end
> - Fix the greater than or equal to check to exit the log parsing
> - Make sure log_position is 0 if there is any error discovering the log
> - Return errors parsing the log if the data is corrupt so that we don't
>end up with half a log
>
> Changes since v6:
> - Added Linaro copyright for all the EFI moved code
> - Changed tcg2_init_log (and by extension, tcg2_measurement_init) to
>copy any discovered event log to the user's log if passed in.
>
> Changes since v5:
> - Remove unused platform_get_eventlog in efi_tcg2.c
> - First look for tpm_event_log_* properties instead of linux,sml-*
> - Fix efi_tcg2.c compilation
> - Select SHA* configs
>
> Changes since v4:
> - Remove tcg2_measure_event function and check for NULL data in
>tcg2_measure_data
> - Use tpm_auto_startup
> - Fix efi_tcg2.c compilation for removing tcg2_pcr_read function
>
> Changes since v3:
> - Reordered headers
> - Refactored more of EFI code into common code
> Removed digest_info structure and instead used the common alg_to_mask
> and alg_to_len
> Improved event log parsing in common code to get it equivalent to EFI
> Common code now extends PCR if previous bootloader stage couldn't
> No need to allocate memory in the common code, so EFI copies the
> discovered buffer like it did before
> Rename efi measure_event function
>
> Changes since v1:
> - Refactor TPM layer functions to allow EFI system to use them, and
>remove duplicate EFI functions
>
> include/efi_tcg2.h| 44 --
> include/tpm-v2.h | 259 +
> lib/Kconfig |4 +
> lib/efi_loader/efi_tcg2.c | 1054 +++--
> lib/tpm-v2.c | 814
> 5 files changed, 1154 insertions(+), 1021 deletions(-)
>
> diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
> index b1c3abd097..b21c5cb3dd 100644
> --- a/include/efi_tcg2.h
> +++ b/include/efi_tcg2.h
> @@ -129,50 +129,6 @@ struct efi_tcg2_boot_service_capability {
> #define BOOT_SERVICE_CAPABILITY_MIN \
> offsetof(struct efi_tcg2_boot_service_capability, number_of_pcr_banks)
>
> -#define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
> -#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MAJOR_TPM2 2
> -#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MINOR_TPM2 0
> -#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_ERRATA_TPM2 2
> -
> -/**
> - * struct TCG_EfiSpecIdEventAlgorithmSize - hashing algorithm information
> - *
> - * @algorithm_id: algorithm defined in enum tpm2_algorithms
> - * @digest_size:size of the algorithm
> - */
> -struct tcg_efi_spec_id_event_algorithm_size {
> - u16 algorithm_id;
> - u16 digest_size;
> -} __packed;
> -
> -/**
> - * struct TCG_EfiSpecIDEventStruct - content of the event log header
> - *
> - * @signature: signature, set to Spec ID Event03
> - * @platform_class: class defined in TCG ACPI Specification
> - * Client Common Header.
> - * @spec_version_minor: minor version
> - * @spec_version_major: major version
> - * @spec_version_errata: major version
> - * @uintn_size: size of the efi_uintn_t fields used in
> various
> - * data structures used in this specification.
> - * 0x01 indicates u32 and 0x02 indicates u64
> - * @number_of_algorithms:hashing algorithms used in this event log
> - * @digest_sizes:array of number_of_algorithms pairs
> - * 1st member defines the algorithm id
> - * 2nd member
Re: [PATCH 0/2] mtd: nand: raw: atmel: R/B gpio on sam9x60
Hello, just a short supplement … Am Wed, Aug 09, 2023 at 09:40:15AM +0200 schrieb Alexander Dahl: > Hello everyone, > > I had a closer look into the SAMA5D2 Series Datasheet and the SAM9X60 > Data Sheet again. See below. > > Am Tue, Aug 08, 2023 at 05:00:48PM +0200 schrieb Alexander Dahl: > > Hello Mihai, > > > > Am Tue, Aug 08, 2023 at 01:40:26PM + schrieb mihai.s...@microchip.com: > > > Hi Alex, > > > > > > Please find bellow my answer: > > > > > > -- > > > > > > Added Mihai who tested this a lot at some point in time > > > > > > Eugen > > > > > > On 8/8/23 16:02, Alexander Dahl wrote: > > > > Hello everyone, > > > > > > > > this is a patch series wtih some real fixes _and_ a question or some > > > > kind of support request in the cover letter. I would be happy if > > > > anyone could read the cover letter carefully and answer to that one > > > > what might be the problem I see. O:-) > > > > > > > > I'm currently working on the sam9x60-curiosity board and especially > > > > trying to get it booting from onboard raw NAND flash. As reported in > > > > my last series I got the flash recognized already. However > > > > interacting with it was terribly slow, because nand_wait_ready() > > > > calling > > > > atmel_nand_dev_ready() ran into a 400ms timeout in several occasions, > > > > especially when reading from the device. Reading a single block > > > > triggered that timeout two times per page, which summed up to over 50 > > > > seconds for 64 × 4096 = 256k Bytes! > > > > > > > > (You can have U-Boot print that warning from nand_wait_ready() by > > > > increasing the console log level to at least "warn".) > > > > > > > > Note: the dts from atmel/next seems correct to me, I double checked > > > > that again. My own debug log messages showed the GPIO is accessed, > > > > and if you add enough debug messages sometimes the timeout is not > > > > reached, so I'm sure the NAND chip eventually switches that R/B line > > > > and the code correctly sees that, that line level change however takes > > > > ages, something between 400ms and 500ms most of the times. > > > > > > > > I vaguely remembered on SAMA5D2 the old atmel raw nand driver is used > > > > which does not support reading the R/B signal, but nevertheless works. > > > > I'm not familiar in detail with those raw NAND flash chips, but as far > > > > as I can understand, there are other ways to determine if the chip is > > > > ready or busy. So after I removed that rb-gpio parameter from > > > > 'at91-sam9x60_curiosity.dts' I ran into the bug fixed by patch 2. > > > > Maybe I should add: currently there are two different drivers for > > atmel raw nand controllers in U-Boot, the old non-DM driver used by > > sam9g20 or sama5 based boards for example and a new driver used by > > sam9x60 based boards. We are talking about sam9x60 and the new driver > > in 'drivers/mtd/nand/raw/atmel/nand-controller.c' here. > > The old one is enabled by CONFIG_NAND_ATMEL, the new one by > CONFIG_DM_NAND_ATMEL instead. > > > > > With that patch applied _and_ rb-gpio still removed from dts, raw NAND > > > > access is reasonably fast on sam9x60-curiosity board. (You might want > > > > to rebase to atmel/next for testing this.) Not sure if I should send > > > > a patch for that dts change, because I suppose it's a workaround only > > > > and not addressing the actual cause? > > > > > > > > I think the fix is correct in itself, I tested different combinations > > > > and compared with the driver in Linux, however … > > > > > > > > Can anyone explain to me, why flash access is sooo slow if the R/B > > > > gpio is used? Especially in comparision to Linux, where I don't need > > > > to remove that thing from dts and it works reasonably fast? > > > > > > // I'm sorry for quoting (email is sent from Outlook) > > > # Please add in your board dts: atmel,rb = <0> > > > > Although the new U-Boot driver tests for that, it is not documented in > > U-Boot devicetree bindings. According to Linux kernel (v6.4) device > > tree binding documentation it is only meaningful for sama5. Those > > binding documentation was added to Linux back in 2019 by Boris > > Brezillon. And that line is not present in the dts file for > > sam9x60-curiosity in Linux, so access is fast on Linux without that > > line (this is the part I don't understand yet). > > > > From what I saw in datasheets sam9x60 and sama5d2 have different > > controllers (named 'SMC' and 'HSMC') and the U-Boot driver reflects > > that. That's why I did not add 'atmel,rb' to dts before, I though SMC > > is the older one which does not support native R/B line handling? > > (And because I took it from U-Boot sam9x60ek.dts which also does not have > > it.) > > > > Nevertheless, I tried to add it now in U-Boot as you suggested > > (although without adapting pinctrl), and to my suprise it works … o.O > > > > Trying the same in Linux leads to not finding a
Re: [PATCH 0/2] mtd: nand: raw: atmel: R/B gpio on sam9x60
Hello everyone, I had a closer look into the SAMA5D2 Series Datasheet and the SAM9X60 Data Sheet again. See below. Am Tue, Aug 08, 2023 at 05:00:48PM +0200 schrieb Alexander Dahl: > Hello Mihai, > > Am Tue, Aug 08, 2023 at 01:40:26PM + schrieb mihai.s...@microchip.com: > > Hi Alex, > > > > Please find bellow my answer: > > > > -- > > > > Added Mihai who tested this a lot at some point in time > > > > Eugen > > > > On 8/8/23 16:02, Alexander Dahl wrote: > > > Hello everyone, > > > > > > this is a patch series wtih some real fixes _and_ a question or some > > > kind of support request in the cover letter. I would be happy if > > > anyone could read the cover letter carefully and answer to that one > > > what might be the problem I see. O:-) > > > > > > I'm currently working on the sam9x60-curiosity board and especially > > > trying to get it booting from onboard raw NAND flash. As reported in > > > my last series I got the flash recognized already. However > > > interacting with it was terribly slow, because nand_wait_ready() > > > calling > > > atmel_nand_dev_ready() ran into a 400ms timeout in several occasions, > > > especially when reading from the device. Reading a single block > > > triggered that timeout two times per page, which summed up to over 50 > > > seconds for 64 × 4096 = 256k Bytes! > > > > > > (You can have U-Boot print that warning from nand_wait_ready() by > > > increasing the console log level to at least "warn".) > > > > > > Note: the dts from atmel/next seems correct to me, I double checked > > > that again. My own debug log messages showed the GPIO is accessed, > > > and if you add enough debug messages sometimes the timeout is not > > > reached, so I'm sure the NAND chip eventually switches that R/B line > > > and the code correctly sees that, that line level change however takes > > > ages, something between 400ms and 500ms most of the times. > > > > > > I vaguely remembered on SAMA5D2 the old atmel raw nand driver is used > > > which does not support reading the R/B signal, but nevertheless works. > > > I'm not familiar in detail with those raw NAND flash chips, but as far > > > as I can understand, there are other ways to determine if the chip is > > > ready or busy. So after I removed that rb-gpio parameter from > > > 'at91-sam9x60_curiosity.dts' I ran into the bug fixed by patch 2. > > Maybe I should add: currently there are two different drivers for > atmel raw nand controllers in U-Boot, the old non-DM driver used by > sam9g20 or sama5 based boards for example and a new driver used by > sam9x60 based boards. We are talking about sam9x60 and the new driver > in 'drivers/mtd/nand/raw/atmel/nand-controller.c' here. The old one is enabled by CONFIG_NAND_ATMEL, the new one by CONFIG_DM_NAND_ATMEL instead. > > > With that patch applied _and_ rb-gpio still removed from dts, raw NAND > > > access is reasonably fast on sam9x60-curiosity board. (You might want > > > to rebase to atmel/next for testing this.) Not sure if I should send > > > a patch for that dts change, because I suppose it's a workaround only > > > and not addressing the actual cause? > > > > > > I think the fix is correct in itself, I tested different combinations > > > and compared with the driver in Linux, however … > > > > > > Can anyone explain to me, why flash access is sooo slow if the R/B > > > gpio is used? Especially in comparision to Linux, where I don't need > > > to remove that thing from dts and it works reasonably fast? > > > > // I'm sorry for quoting (email is sent from Outlook) > > # Please add in your board dts: atmel,rb = <0> > > Although the new U-Boot driver tests for that, it is not documented in > U-Boot devicetree bindings. According to Linux kernel (v6.4) device > tree binding documentation it is only meaningful for sama5. Those > binding documentation was added to Linux back in 2019 by Boris > Brezillon. And that line is not present in the dts file for > sam9x60-curiosity in Linux, so access is fast on Linux without that > line (this is the part I don't understand yet). > > From what I saw in datasheets sam9x60 and sama5d2 have different > controllers (named 'SMC' and 'HSMC') and the U-Boot driver reflects > that. That's why I did not add 'atmel,rb' to dts before, I though SMC > is the older one which does not support native R/B line handling? > (And because I took it from U-Boot sam9x60ek.dts which also does not have > it.) > > Nevertheless, I tried to add it now in U-Boot as you suggested > (although without adapting pinctrl), and to my suprise it works … o.O > > Trying the same in Linux leads to not finding a NAND device and thus > failing of the atmel-nand-controller driver probe. >From datasheet POV this all makes sense. The HSMC on SAMA5D2 has a native NANDRDY signal/peripheral function to handle the R/B pin of the flash and can do the low level communication by itself with an embedded Nand Flash
[GIT PULL] please pull fsl-qoriq-2023-8-9
Hi Tom, Please pull fsl-qoriq-2023-8-9, only one minor cleanup patch. -- Drop one unused function for layerscape -- CI: https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/commit/0f621ca9b92098ee08b944c5138e398059fcf6ee Thanks, Peng. The following changes since commit ef8336e2705fce2502383f25d68188c6b1f94dd0: Merge branch '2023-08-08-introuce-Arm-FF-A-support' (2023-08-08 15:23:16 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git tags/fsl-qoriq-2023-8-9 for you to fetch changes up to 0f621ca9b92098ee08b944c5138e398059fcf6ee: arm64: fsl: layerscape: Remove unused functions (2023-08-09 16:17:53 +0800) Shenlin Liang (1): arm64: fsl: layerscape: Remove unused functions arch/arm/cpu/armv8/fsl-layerscape/soc.c | 5 - 1 file changed, 5 deletions(-)
Re: [RESEND, v1 4/4] configs: riscv: starfive: Add VF2 PCIe USB3 XHCI support
On Mon, Aug 07, 2023 at 04:53:38PM +0800, Minda Chen wrote: > Add XHCI_PCI to enable usb3-host functions. > Also add usb command and keyboard config. > > Signed-off-by: Minda Chen > --- > configs/starfive_visionfive2_defconfig | 5 + > 1 file changed, 5 insertions(+) Reviewed-by: Leo Yu-Chi Liang
Re: [RESEND, v1 3/4] riscv: starfive: Add SYS_CACHE_SHIFT_6 to enable SYS_CACHELINE_SIZE
On Mon, Aug 07, 2023 at 04:53:37PM +0800, Minda Chen wrote: > Some device driver need SYS_CACHELINE_SIZE macro. Add StarFive > SYS_CACHE_SHIFT_6 to enable it. > > Signed-off-by: Minda Chen > --- > arch/riscv/cpu/jh7110/Kconfig | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Leo Yu-Chi Liang
Re: [RESEND,v1 2/4] riscv: dts: starfive: Enable pcie0 dts node
On Mon, Aug 07, 2023 at 04:53:36PM +0800, Minda Chen wrote: > In StarFive VF2 board. pcie0 connect to VTI usb controller. > Enable it to support usb host. > > Signed-off-by: Minda Chen > --- > arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Leo Yu-Chi Liang
Re: [RESEND,v1 1/4] pci: plda: Get correct ECAM offset in multiple PCIe RC case
On Mon, Aug 07, 2023 at 04:53:35PM +0800, Minda Chen wrote: > Get the correct ECAM offset and record the secondary bus > number in Multiple RC case. > > Signed-off-by: Minda Chen > --- > drivers/pci/pcie_plda_common.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH v1] configs: starfive: Enable environment in SPI flash support
On Tue, Aug 08, 2023 at 09:14:36PM +0800, Shengyu Qu wrote: > On Starfive Visionfive 2, the u-boot environment settings are saved to > on-board SPI flash. Enable relative configs by default and set offset > and size according to upstream linux dts. > > Signed-off-by: Shengyu Qu > --- > configs/starfive_visionfive2_defconfig | 9 + > 1 file changed, 9 insertions(+) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH v3 3/3] riscv: cpu: jh7110: Select SPL_ZERO_MEM_BEFORE_USE
On Tue, Aug 08, 2023 at 08:39:57PM +0800, Shengyu Qu wrote: > Add Kconfig item for Starfive JH7110 to select SPL_ZERO_MEM_BEFORE_USE. > > Signed-off-by: Bo Gan > Signed-off-by: Shengyu Qu > --- > arch/riscv/cpu/jh7110/Kconfig | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH v3 2/3] riscv: Add SPL_ZERO_MEM_BEFORE_USE implementation
Hi Shengyu,
On Tue, Aug 08, 2023 at 08:39:56PM +0800, Shengyu Qu wrote:
> Add the actual support code for SPL_ZERO_MEM_BEFORE_USE and remove
> existing Starfive JH7110's L2 LIM clean code, since existing code has
> following issues:
> 1. Each hart (in the middle of a function call) overwriting its own
> stack and other harts' stacks.
> (data-race and data-corruption)
> 2. Lottery winner hart can be doing "board_init_f_init_reserve",
> while other harts are in the middle of zeroing L2 LIM.
> (data-race)
>
> Signed-off-by: Bo Gan
> Signed-off-by: Shengyu Qu
> ---
> Changes since v2:
> - Fix typo (ZERO_MEM_BEFORE_USE to SPL_ZERO_MEM_BEFORE_USE)
> ---
> arch/riscv/cpu/jh7110/spl.c | 25 -
> arch/riscv/cpu/start.S | 12
> common/init/board_init.c| 3 +++
> 3 files changed, 15 insertions(+), 25 deletions(-)
>
> diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c
> index 72adcefa0e..4047b10efe 100644
> --- a/arch/riscv/cpu/jh7110/spl.c
> +++ b/arch/riscv/cpu/jh7110/spl.c
> @@ -13,7 +13,6 @@
> #include
>
> #define CSR_U74_FEATURE_DISABLE 0x7c1
> -#define L2_LIM_MEM_END 0x81FUL
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -59,9 +58,6 @@ int spl_soc_init(void)
>
> void harts_early_init(void)
> {
> - ulong *ptr;
> - u8 *tmp;
> - ulong len, remain;
> /*
>* Feature Disable CSR
>*
> @@ -70,25 +66,4 @@ void harts_early_init(void)
>*/
> if (CONFIG_IS_ENABLED(RISCV_MMODE))
> csr_write(CSR_U74_FEATURE_DISABLE, 0);
> -
> - /* clear L2 LIM memory
> - * set __bss_end to 0x81F region to zero
> - * The L2 Cache Controller supports ECC. ECC is applied to SRAM.
> - * If it is not cleared, the ECC part is invalid, and an ECC error
> - * will be reported when reading data.
> - */
> - ptr = (ulong *)&__bss_end;
> - len = L2_LIM_MEM_END - (ulong)&__bss_end;
> - remain = len % sizeof(ulong);
> - len /= sizeof(ulong);
> -
> - while (len--)
> - *ptr++ = 0;
> -
> - /* clear the remain bytes */
> - if (remain) {
> - tmp = (u8 *)ptr;
> - while (remain--)
> - *tmp++ = 0;
> - }
> }
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index 59d58a5a57..930309d8d2 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -111,6 +111,18 @@ call_board_init_f:
> * It's essential before any function call, otherwise, we get data-race.
> */
>
> +/* clear stack if necessary */
> +#if CONFIG_IS_ENABLED(SPL_ZERO_MEM_BEFORE_USE)
I think what you have in v2 patch was the correct one.
Could you refer to include/linux/kconfig.h to check if
this usage fits your expectation ?
> +clear_stack:
> + li t1, 1
> + sllit1, t1, CONFIG_STACK_SIZE_SHIFT
> + sub t1, sp, t1
> +clear_stack_loop:
> + SREGzero, 0(t1) /* t1 is always 16 byte aligned */
> + addit1, t1, REGBYTES
> + blt t1, sp, clear_stack_loop
> +#endif
> +
> call_board_init_f_0:
> /* find top of reserve space */
> #if CONFIG_IS_ENABLED(SMP)
> diff --git a/common/init/board_init.c b/common/init/board_init.c
> index 96ffb79a98..51d9ec9a13 100644
> --- a/common/init/board_init.c
> +++ b/common/init/board_init.c
> @@ -162,6 +162,9 @@ void board_init_f_init_reserve(ulong base)
> #if CONFIG_VAL(SYS_MALLOC_F_LEN)
> /* go down one 'early malloc arena' */
> gd->malloc_base = base;
> +#if CONFIG_IS_ENABLED(SPL_ZERO_MEM_BEFORE_USE)
Ditto.
Best regards,
Leo
> + memset((void *)base, '\0', CONFIG_VAL(SYS_MALLOC_F_LEN));
> +#endif
> #endif
>
> if (CONFIG_IS_ENABLED(SYS_REPORT_STACK_F_USAGE))
> --
> 2.41.0
>
Re: [PATCH v3 1/3] riscv: Kconfig: Add SPL_ZERO_MEM_BEFORE_USE
On Tue, Aug 08, 2023 at 08:39:55PM +0800, Shengyu Qu wrote: > Add a Kconfig item to allow SPL to clear stack/GD/malloc area before > using them. > > Signed-off-by: Bo Gan > Signed-off-by: Shengyu Qu > --- > arch/riscv/Kconfig | 8 > 1 file changed, 8 insertions(+) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH 2/2] configs: Make TI_SECURE_DEVICE default for K3
On 03.08.23 16:54, Andrew Davis wrote: > All K3 boards now are secure by default, instead of setting this in each > defconfig, make it implied by the ARCH config. > > The only exception is IOT2050, which I do not believe will have any > problems with being a TI_SECURE_DEVICE, but for now turn it off to keep > its config the same. The IOT2050 firmware is not using TI_SECURE_DEVICE because it serves non-HS devices by default as well. Secure boot on HS devices can be enabled by applying an extra config fragment like [1]. So it's indeed better to keep this off for the IO2050 to avoid untested side effects. E.g., we would probably lose legacy image booting in non-secure mode. Jan [1] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/secure-boot.cfg > > Signed-off-by: Andrew Davis > --- > arch/arm/Kconfig | 1 + > configs/am62ax_evm_a53_defconfig | 1 - > configs/am62ax_evm_r5_defconfig | 1 - > configs/am62x_evm_a53_defconfig | 1 - > configs/am62x_evm_r5_defconfig | 1 - > configs/am64x_evm_a53_defconfig | 1 - > configs/am64x_evm_r5_defconfig | 1 - > configs/iot2050_defconfig| 1 + > configs/j7200_evm_a72_defconfig | 1 - > configs/j7200_evm_r5_defconfig | 1 - > configs/j721e_evm_a72_defconfig | 1 - > configs/j721e_evm_r5_defconfig | 1 - > configs/j721s2_evm_a72_defconfig | 1 - > configs/j721s2_evm_r5_defconfig | 1 - > 14 files changed, 2 insertions(+), 12 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 97c25b4f146..8ad6c5582ce 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -787,6 +787,7 @@ config ARCH_K3 > select FIT > select REGEX > select FIT_SIGNATURE if ARM64 > + imply TI_SECURE_DEVICE > > config ARCH_OMAP2PLUS > bool "TI OMAP2+" > diff --git a/configs/am62ax_evm_a53_defconfig > b/configs/am62ax_evm_a53_defconfig > index 773cf3a591c..d0a34c75505 100644 > --- a/configs/am62ax_evm_a53_defconfig > +++ b/configs/am62ax_evm_a53_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > diff --git a/configs/am62ax_evm_r5_defconfig b/configs/am62ax_evm_r5_defconfig > index 05c30cbba19..2c1110d227f 100644 > --- a/configs/am62ax_evm_r5_defconfig > +++ b/configs/am62ax_evm_r5_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_F_LEN=0x9000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig > index d55caabe22c..1d05cecbcde 100644 > --- a/configs/am62x_evm_a53_defconfig > +++ b/configs/am62x_evm_a53_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig > index 3c5f3672984..9dd2930dc89 100644 > --- a/configs/am62x_evm_r5_defconfig > +++ b/configs/am62x_evm_r5_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x0800 > CONFIG_SYS_MALLOC_F_LEN=0x9000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig > index 9bdb767f9e6..d1d46c61075 100644 > --- a/configs/am64x_evm_a53_defconfig > +++ b/configs/am64x_evm_a53_defconfig > @@ -1,7 +1,6 @@ > CONFIG_ARM=y > CONFIG_SKIP_LOWLEVEL_INIT=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_GPIO=y > diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig > index 45d32658cff..96cb437b10b 100644 > --- a/configs/am64x_evm_r5_defconfig > +++ b/configs/am64x_evm_r5_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8 > CONFIG_SPL_GPIO=y > diff --git a/configs/iot2050_defconfig b/configs/iot2050_defconfig > index bcbaa92ee89..ad9217ff86a 100644 > --- a/configs/iot2050_defconfig > +++ b/configs/iot2050_defconfig > @@ -1,6 +1,7 @@ > CONFIG_ARM=y > CONFIG_SKIP_LOWLEVEL_INIT=y > CONFIG_ARCH_K3=y > +# CONFIG_TI_SECURE_DEVICE is not set > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_GPIO=y > diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig > index c68d52537e5..a9f5d36ffe3 100644 > --- a/configs/j7200_evm_a72_defconfig > +++ b/configs/j7200_evm_a72_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_GPIO=y > diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig > index
