Re: [PATCH v2 0/4] FMP versioning support
On Mon, 6 Mar 2023 at 15:32, Takahiro Akashi wrote: > > On Mon, Mar 06, 2023 at 03:08:55PM +0900, Masahisa Kojima wrote: > > Hi Akashi-san, > > > > On Sat, 4 Mar 2023 at 10:28, Takahiro Akashi > > wrote: > > > > > > Kojima-san, > > > > > > On Wed, Mar 01, 2023 at 06:15:18PM +0900, Masahisa Kojima wrote: > > > > Firmware version management is not implemented in the current > > > > FMP implementation. This series aims to add the versioning support > > > > in FMP. > > > > > > I think that you need to think of A/B update case, especially > > > when a capsule update is *reverted* to an older version. > > > > A/B update(FWU) has their own version information in the Image Directory > > defined in FWU spec[1], this is not implemented yet on U-Boot. > > On second thought, I think A/B update(FWU) case should be excluded > > from the version management introduced by this series. > > I don't think it's a good idea to have two different implementations > for normal case and A/B update unless there is a good reason when > we use the same FMP driver. Yes, I think we need different FMP drivers for the normal case and A/B update case if we implement the different version management. It's just a thought that we can transfer the FWU specific code from lib/efi_loader/efi_capsule.c to FMP driver for FWU. Another idea is that we implement version management defined in FWU spec and it is also used for a normal case, but I'm not sure it is feasible. Thanks, Masahisa Kojima > > -Takahiro Akashi > > > > > > > In addition, please don't forget in the next patch set: > > > - update the man page of mkeficapsule command > > > - add test cases (in pytest) > > > > Yes, noted. > > > > [1] https://developer.arm.com/documentation/den0118/a/ > > > > Thanks, > > Masahisa Kojima > > > > > > > > -Takahiro Akashi > > > > > > > EDK2 reference implementation utilizes the FMP Payload Header > > > > inserted right before the capsule payload. With this series, > > > > U-Boot also follows the EDK2 implementation. > > > > > > > > Currently, there is no way to know the current running firmware > > > > version through the EFI interface. FMP->GetImageInfo() returns > > > > always 0 for the version number. So a user can not know that > > > > expected firmware is running after the capsule update. > > > > > > > > With this series applied, version number can be specified > > > > in the capsule file generation with mkeficapsule tool, then > > > > user can know the running firmware version through > > > > FMP->GetImageInfo() and ESRT. > > > > > > > > Note that this series does not mandate the FMP Payload Header, > > > > compatible with boards that are already using the existing > > > > U-Boot FMP implementation. > > > > If no FMP Payload Header is found in the capsule file, fw_version, > > > > lowest supported version, last attempt version and last attempt > > > > status is set to 0 and this is the same behavior as existing FMP > > > > implementation. > > > > > > > > Changes in v2: > > > > - add FMP Payload Header generation in mkeficapsule tool > > > > > > > > Masahisa Kojima (4): > > > > efi_loader: store firmware version into FmpState variable > > > > efi_loader: versioning support in GetImageInfo > > > > efi_loader: check lowest supported version in capsule update > > > > mkeficapsule: add FMP Payload Header > > > > > > > > lib/efi_loader/efi_firmware.c | 271 ++ > > > > tools/mkeficapsule.c | 81 +- > > > > 2 files changed, 319 insertions(+), 33 deletions(-) > > > > > > > > -- > > > > 2.17.1 > > > >
Re: [RESEND PATCH] arm: mvebu: Set common SPI flash default speed and mode
On 3/3/23 04:27, Tony Dinh wrote: CONFIG_SF_DEFAULT_SPEED is used in SPL SPI to configure and probe the flash device during DM SPI uclass probing process, if the spi-max-frequency is not available in the DTB. Currently the max frequency is not available, because of the probing mechanism in SPI uclass has not been fully updated to DM. The CONFIG_SF_DEFAULT_SPEED is set to 1Mhz if a board defconfig does not specify it. This speed is too slow and result in a few seconds delay while the u-boot image is loaded from flash. Based on a survey of the device tree specifications for MVEBU boards, a sane default value should be 10Mhz. The default of 10Mhz enables an almost instantaneously loading of the u-boot image. Note that this patch depends on this patch series (has been merged to u-boot-marvell/next): https://lists.denx.de/pipermail/u-boot/2023-March/511038.html - RESEND: correct spelling of SF_DEFAULT_MODE Signed-off-by: Tony Dinh Reviewed-by: Stefan Roese Thanks, Stefan --- arch/arm/mach-mvebu/Kconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index cdb1776a66..8f744e2177 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -424,6 +424,16 @@ config SECURED_MODE_CSK_INDEX default 0 depends on SECURED_MODE_IMAGE +config SF_DEFAULT_SPEED + int "Default speed for SPI flash in Hz" + default 1000 + depends on MVEBU_SPL_BOOT_DEVICE_SPI + +config SF_DEFAULT_MODE + hex "Default mode for SPI flash" + default 0x0 + depends on MVEBU_SPL_BOOT_DEVICE_SPI + source "board/solidrun/clearfog/Kconfig" source "board/kobol/helios4/Kconfig" Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v8 0/6] tpm: Support boot measurements
Hi Eddie, This has a few failures on the CI [0]. Please have a look and let me know if you can't understand the failures [0] https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/15471 Regards /Ilias On Fri, Mar 03, 2023 at 01:25:00PM -0600, Eddie James wrote: > This series adds support for measuring the boot images more generically > than the existing EFI support. Several EFI functions have been moved to > the TPM layer. The series includes optional measurement from the bootm > command. > A new test case has been added for the bootm measurement to test the new > path, and the sandbox TPM2 driver has been updated to support this use > case. > This series is based on Ilias' auto-startup series and Simon's additions. > > 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 comment for bootm_measure > - Fixed line length in bootm_measure > - 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: > - Re-ordered the patches to put the sandbox TPM driver patch second > - 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 > - Remove the !SANDBOX dependency for EFI TCG2 > - Only compile in the measurement u-boot command when CONFIG_MEASURED_BOOT >is enabled > > 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 > - Change PCR indexes for initrd and dtb > - Drop u8 casting in measurement test > - Use bullets in documentation > > 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 v2: > - Add documentation. > - Changed reserved memory address to the top of the RAM for sandbox dts. > - Add measure state to booti and bootz. > - Skip measurement for EFI images that should be measured > > Changes since v1: > - Refactor TPM layer functions to allow EFI system to use them, and >remove duplicate EFI functions. > - Add test case > - Drop #ifdefs for bootm > - Add devicetree measurement config option > - Update sandbox TPM driver > > Eddie James (6): > tpm: Fix spelling for tpmu_ha union > tpm: sandbox: Update for needed TPM2 capabilities > tpm: Support boot measurements > bootm: Support boot measurement > test: Add sandbox TPM boot measurement > doc: Add measured boot documentation > > arch/sandbox/dts/sandbox.dtsi | 13 + > arch/sandbox/dts/test.dts | 13 + > boot/Kconfig | 23 + > boot/bootm.c | 72 +++ > cmd/booti.c|1 + > cmd/bootm.c|2 + > cmd/bootz.c|1 + > configs/sandbox_defconfig |1 + > doc/usage/index.rst|1 + > doc/usage/measured_boot.rst| 23 + > drivers/tpm/tpm2_tis_sandbox.c | 100 ++- > include/bootm.h| 11 + > include/efi_tcg2.h | 44 -- > include/image.h|1 + > include/test/suites.h |1 + > include/tpm-v2.h | 255 +++- > lib/Kconfig|4 + > lib/efi_loader/Kconfig |2 - > lib/efi_loader/efi_tcg2.c | 1054 +++- > lib/tpm-v2.c | 815 > test/boot/Makefile |1 + > test/boot/measurement.c| 66 ++ > test/cmd_ut.c |4 + > 23 files changed, 1455 insertions(+), 1053 deletions(-) > create mode 100644 doc/usage/measured_boot.rst > create mode 100644 test/boot/measurement.c > > -- > 2.31.1 >
Re: [PATCH v2 0/4] FMP versioning support
On Mon, Mar 06, 2023 at 03:08:55PM +0900, Masahisa Kojima wrote: > Hi Akashi-san, > > On Sat, 4 Mar 2023 at 10:28, Takahiro Akashi > wrote: > > > > Kojima-san, > > > > On Wed, Mar 01, 2023 at 06:15:18PM +0900, Masahisa Kojima wrote: > > > Firmware version management is not implemented in the current > > > FMP implementation. This series aims to add the versioning support > > > in FMP. > > > > I think that you need to think of A/B update case, especially > > when a capsule update is *reverted* to an older version. > > A/B update(FWU) has their own version information in the Image Directory > defined in FWU spec[1], this is not implemented yet on U-Boot. > On second thought, I think A/B update(FWU) case should be excluded > from the version management introduced by this series. I don't think it's a good idea to have two different implementations for normal case and A/B update unless there is a good reason when we use the same FMP driver. -Takahiro Akashi > > > > In addition, please don't forget in the next patch set: > > - update the man page of mkeficapsule command > > - add test cases (in pytest) > > Yes, noted. > > [1] https://developer.arm.com/documentation/den0118/a/ > > Thanks, > Masahisa Kojima > > > > > -Takahiro Akashi > > > > > EDK2 reference implementation utilizes the FMP Payload Header > > > inserted right before the capsule payload. With this series, > > > U-Boot also follows the EDK2 implementation. > > > > > > Currently, there is no way to know the current running firmware > > > version through the EFI interface. FMP->GetImageInfo() returns > > > always 0 for the version number. So a user can not know that > > > expected firmware is running after the capsule update. > > > > > > With this series applied, version number can be specified > > > in the capsule file generation with mkeficapsule tool, then > > > user can know the running firmware version through > > > FMP->GetImageInfo() and ESRT. > > > > > > Note that this series does not mandate the FMP Payload Header, > > > compatible with boards that are already using the existing > > > U-Boot FMP implementation. > > > If no FMP Payload Header is found in the capsule file, fw_version, > > > lowest supported version, last attempt version and last attempt > > > status is set to 0 and this is the same behavior as existing FMP > > > implementation. > > > > > > Changes in v2: > > > - add FMP Payload Header generation in mkeficapsule tool > > > > > > Masahisa Kojima (4): > > > efi_loader: store firmware version into FmpState variable > > > efi_loader: versioning support in GetImageInfo > > > efi_loader: check lowest supported version in capsule update > > > mkeficapsule: add FMP Payload Header > > > > > > lib/efi_loader/efi_firmware.c | 271 ++ > > > tools/mkeficapsule.c | 81 +- > > > 2 files changed, 319 insertions(+), 33 deletions(-) > > > > > > -- > > > 2.17.1 > > >
Re: [PATCH 4/4] arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
On Sun, 5 Mar 2023 at 12:43, Pali Rohár wrote:
> On Sunday 05 March 2023 21:31:00 Martin Rowe wrote:
> > [upstream of vendor commit 19a96f7c40a8fc1d0a6546ac2418d966e5840a99]
> >
> > The Clearfog devices have only one SDHC device. This is either eMMC if
> > it is populated on the SOM or SDHC if not. The Linux device tree assumes
> > the SDHC case. Detect if the device is an eMMC and fixup the device-tree
> > so it will be detected by Linux.
> >
> > Ported from vendor repo at https://github.com/SolidRun/u-boot
> >
> > Signed-off-by: Martin Rowe
> > ---
> > board/solidrun/clearfog/clearfog.c | 42 ++
> > configs/clearfog_defconfig | 1 +
> > configs/clearfog_sata_defconfig| 1 +
> > configs/clearfog_spi_defconfig | 1 +
> > 4 files changed, 45 insertions(+)
> >
> > diff --git a/board/solidrun/clearfog/clearfog.c
> b/board/solidrun/clearfog/clearfog.c
> > index 03adb591d8..cafead3a1a 100644
> > --- a/board/solidrun/clearfog/clearfog.c
> > +++ b/board/solidrun/clearfog/clearfog.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -261,3 +262,44 @@ int board_late_init(void)
> >
> > return 0;
> > }
> > +
> > +static bool has_emmc(void)
> > +{
> > + struct mmc *mmc;
> > + mmc = find_mmc_device(0);
> > + if (!mmc)
> > + return 0;
> > + return (!mmc_init(mmc) && IS_MMC(mmc)) ? true : false;
> > +}
> > +
> > +/*
> > + * The Clearfog devices have only one SDHC device. This is either eMMC
> > + * if it is populated on the SOM or SDHC if not. The Linux device tree
> > + * assumes the SDHC case. Detect if the device is an eMMC and fixup the
> > + * device-tree so it will be detected by Linux.
> > + */
> > +int ft_board_setup(void *blob, struct bd_info *bd)
> > +{
> > + __maybe_unused int offset, rc;
> > +
> > + if (has_emmc()) {
> > + puts("Patching FDT so that eMMC is detected by kernel\n");
> > + offset = fdt_path_offset(blob,
> "/soc/internal-regs/sdhci@d8000");
>
> Do not use fixed DT paths when parsing Linux kernel DT files. Linux
> developers often changes DT node names in their DTS files which cause
> changing of DT paths and hence this code in bootloader stops working.
>
> I would suggest to find node offset by compatible string
> ("marvell,armada-380-sdhci"). Look for inspiration what I done in past:
>
> https://source.denx.de/u-boot/u-boot/-/commit/7cd67018dd7f754c66cf08a76397bbee254b32aa
>
Makes sense, I'll rework the patch.
> > + if (offset >= 0) {
> > + rc = fdt_delprop(blob, offset, "cd-gpios");
> > + if (rc == -FDT_ERR_NOTFOUND)
> > + return 0; /* Assume that the device tree
> is already customized for eMMC */
>
> I would suggest to always add "non-removable" property when it does not
> exist.
>
OK, that makes sense, too. I'll test that out.
> + if (rc) {
> > + printf("Unable to remove cd-gpios for
> eMMC, err=%s\n", fdt_strerror(rc));
> > + return rc;
>
> Normally it is not a good idea to return non-zero value from
> ft_board_setup() function because it "crashes" u-boot and stops booting
> kernel.
>
I think this might be an exception. If the board has eMMC there's a
reasonable chance that it's used for the root device. By the time Linux
tries and fails to mount the root device there are already reams of printks
on the serial console that make it hard to see the root cause all the way
back in u-boot. Failing early with an appropriate error message would be
more beneficial while troubleshooting this problem.
There's a corner case where you have an eMMC board and never use the eMMC
device (like my use case), so you wouldn't want to have it fail for
something that you don't use. I think we'll cause more issues for people
that can't mount their root device than for people that get an error for a
device they don't use.
Given I'm going to rework the logic here anyway it's likely this first
'return rc' will be removed, but I think it is worth retaining the one
below.
> + }
> > + rc = fdt_setprop_empty(blob, offset,
> "non-removable");
> > + if (rc) {
> > + printf("Unable to add non-removable for
> eMMC, err=%s\n", fdt_strerror(rc));
> > + return rc;
> > + }
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> > index f9cfa94e77..45b093c6d8 100644
> > --- a/configs/clearfog_defconfig
> > +++ b/configs/clearfog_defconfig
> > @@ -21,6 +21,7 @@ CONFIG_SYS_LOAD_ADDR=0x80
> > CONFIG_DEBUG_UART=y
> > CONFIG_AHCI=y
> > CONFIG_DISTRO_DEFAULTS=y
> > +CONFIG_OF_BOARD_SETUP=y
>
> Hint: To avoid having CONFIG_OF_BOARD_SETUP=y in every
Re: [PATCH u-boot-mvebu] ddr: marvell: a38x: Remove unused file seq_exec.h
On 3/4/23 13:26, Pali Rohár wrote: DDR code does not use seq_exec.h, so remove it. Signed-off-by: Pali Rohár Reviewed-by: Stefan Roese Thanks, Stefan --- drivers/ddr/marvell/a38x/ddr3_init.h | 1 - drivers/ddr/marvell/a38x/seq_exec.h | 64 2 files changed, 65 deletions(-) delete mode 100644 drivers/ddr/marvell/a38x/seq_exec.h diff --git a/drivers/ddr/marvell/a38x/ddr3_init.h b/drivers/ddr/marvell/a38x/ddr3_init.h index 055516b67e9c..f41a732e9a37 100644 --- a/drivers/ddr/marvell/a38x/ddr3_init.h +++ b/drivers/ddr/marvell/a38x/ddr3_init.h @@ -9,7 +9,6 @@ #include "ddr_ml_wrapper.h" #include "mv_ddr_plat.h" -#include "seq_exec.h" #include "ddr3_logging_def.h" #include "ddr3_training_hw_algo.h" #include "ddr3_training_ip.h" diff --git a/drivers/ddr/marvell/a38x/seq_exec.h b/drivers/ddr/marvell/a38x/seq_exec.h deleted file mode 100644 index fe0cb8f75df2.. Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Hi Pali, On 3/4/23 11:50, Pali Rohár wrote: Improve code for checking strapping pins which specifies boot mode source. Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore. Also could you check if SATA booting is still working correctly? Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete). Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch. No, theadorable only boots from SPI NOR. Thanks, Stefan
Re: [PATCH 3/4] arm: mvebu: clearfog: Add defconfig for SPI booting
On Sun, 5 Mar 2023 at 12:29, Pali Rohár wrote:
> On Sunday 05 March 2023 21:30:59 Martin Rowe wrote:
> > This new clearfog_spi_defconfig file is a copy of existing
> > clearfog_defconfig file modified to instruct build system to generate
> > final kwbimage for SPI booting and to store the environment in SPI.
> >
> > Signed-off-by: Martin Rowe
> > ---
> > configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> > copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (96%)
> >
> > diff --git a/configs/clearfog_sata_defconfig
> b/configs/clearfog_spi_defconfig
> > similarity index 96%
> > copy from configs/clearfog_sata_defconfig
> > copy to configs/clearfog_spi_defconfig
> > index b11d8746b0..d6695f31e6 100644
> > --- a/configs/clearfog_sata_defconfig
> > +++ b/configs/clearfog_spi_defconfig
> > @@ -10,7 +10,7 @@ CONFIG_NR_DRAM_BANKS=2
> > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
> > CONFIG_TARGET_CLEARFOG=y
> > -CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> > +CONFIG_ENV_SECT_SIZE=0x1
> > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> > CONFIG_SPL_TEXT_BASE=0x4030
> > CONFIG_SPL_MMC=y
> > @@ -19,6 +19,7 @@ CONFIG_SPL_STACK=0x4002c000
> > CONFIG_SPL=y
> > CONFIG_DEBUG_UART_BASE=0xf1012000
> > CONFIG_DEBUG_UART_CLOCK=25000
> > +CONFIG_SPL_LIBDISK_SUPPORT=y
>
> I think you do not need libdisk support in SPL which loads main u-boot
> from SPI.
>
Makes sense, I'll remove
> > CONFIG_SYS_LOAD_ADDR=0x80
> > CONFIG_DEBUG_UART=y
> > CONFIG_AHCI=y
> > @@ -48,6 +49,7 @@ CONFIG_CMD_USB=y
> > CONFIG_CMD_TFTPPUT=y
> > CONFIG_CMD_CACHE=y
> > CONFIG_CMD_TIME=y
> > +CONFIG_MVEBU_SATA_BOOT=y
>
> Should not be default bubt location SPI for SPI booting?
>
Yes, I'll fix
> CONFIG_ENV_OVERWRITE=y
> > CONFIG_ENV_MIN_ENTRIES=128
> > CONFIG_ARP_TIMEOUT=200
> > --
> > 2.39.2
> >
>
Re: [PATCH v2 0/4] FMP versioning support
Hi Akashi-san, On Sat, 4 Mar 2023 at 10:28, Takahiro Akashi wrote: > > Kojima-san, > > On Wed, Mar 01, 2023 at 06:15:18PM +0900, Masahisa Kojima wrote: > > Firmware version management is not implemented in the current > > FMP implementation. This series aims to add the versioning support > > in FMP. > > I think that you need to think of A/B update case, especially > when a capsule update is *reverted* to an older version. A/B update(FWU) has their own version information in the Image Directory defined in FWU spec[1], this is not implemented yet on U-Boot. On second thought, I think A/B update(FWU) case should be excluded from the version management introduced by this series. > > In addition, please don't forget in the next patch set: > - update the man page of mkeficapsule command > - add test cases (in pytest) Yes, noted. [1] https://developer.arm.com/documentation/den0118/a/ Thanks, Masahisa Kojima > > -Takahiro Akashi > > > EDK2 reference implementation utilizes the FMP Payload Header > > inserted right before the capsule payload. With this series, > > U-Boot also follows the EDK2 implementation. > > > > Currently, there is no way to know the current running firmware > > version through the EFI interface. FMP->GetImageInfo() returns > > always 0 for the version number. So a user can not know that > > expected firmware is running after the capsule update. > > > > With this series applied, version number can be specified > > in the capsule file generation with mkeficapsule tool, then > > user can know the running firmware version through > > FMP->GetImageInfo() and ESRT. > > > > Note that this series does not mandate the FMP Payload Header, > > compatible with boards that are already using the existing > > U-Boot FMP implementation. > > If no FMP Payload Header is found in the capsule file, fw_version, > > lowest supported version, last attempt version and last attempt > > status is set to 0 and this is the same behavior as existing FMP > > implementation. > > > > Changes in v2: > > - add FMP Payload Header generation in mkeficapsule tool > > > > Masahisa Kojima (4): > > efi_loader: store firmware version into FmpState variable > > efi_loader: versioning support in GetImageInfo > > efi_loader: check lowest supported version in capsule update > > mkeficapsule: add FMP Payload Header > > > > lib/efi_loader/efi_firmware.c | 271 ++ > > tools/mkeficapsule.c | 81 +- > > 2 files changed, 319 insertions(+), 33 deletions(-) > > > > -- > > 2.17.1 > >
Re: [PATCH 2/4] arm: mvebu: clearfog: Align defconfigs
On Sun, 5 Mar 2023 at 12:27, Pali Rohár wrote: > On Sunday 05 March 2023 21:30:58 Martin Rowe wrote: > > Ensure that functionality of generated configs is identical between SATA > > and MMC defconfigs for Clearfog boards. The only expected difference is > > the boot mode and environment location. > > > > Signed-off-by: Martin Rowe > > --- > > configs/clearfog_defconfig | 1 + > > configs/clearfog_sata_defconfig | 11 +++ > > 2 files changed, 8 insertions(+), 4 deletions(-) > > > > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig > > index 24e7c16ac7..f9cfa94e77 100644 > > --- a/configs/clearfog_defconfig > > +++ b/configs/clearfog_defconfig > > @@ -46,6 +46,7 @@ CONFIG_CMD_USB=y > > CONFIG_CMD_TFTPPUT=y > > CONFIG_CMD_CACHE=y > > CONFIG_CMD_TIME=y > > +CONFIG_MVEBU_SATA_BOOT=y > > MVEBU_*_BOOT is the default target for the bubt command. I guess that > you do not want to set default one to SATA for eMMC/SD boot. > Correct, I'll remove it. Anyway, when you are doing cleanup of clearfog defconfig files, what > about renaming clearfog_defconfig to clearfog_mmc_defconfig? > I considered this but left it as is since we have several years worth of support with that original name. It will make bisects easier if we keep it the same, but I don't feel strongly either way. Happy to rename it if you'd prefer. > > CONFIG_ENV_OVERWRITE=y > > CONFIG_ENV_MIN_ENTRIES=128 > > CONFIG_ARP_TIMEOUT=200 > > diff --git a/configs/clearfog_sata_defconfig > b/configs/clearfog_sata_defconfig > > index e9b36150ea..b11d8746b0 100644 > > --- a/configs/clearfog_sata_defconfig > > +++ b/configs/clearfog_sata_defconfig > > @@ -3,14 +3,19 @@ CONFIG_ARCH_CPU_INIT=y > > CONFIG_SYS_THUMB_BUILD=y > > CONFIG_ARCH_MVEBU=y > > CONFIG_TEXT_BASE=0x0080 > > +CONFIG_SPL_GPIO=y > > CONFIG_SPL_LIBCOMMON_SUPPORT=y > > CONFIG_SPL_LIBGENERIC_SUPPORT=y > > CONFIG_NR_DRAM_BANKS=2 > > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > > CONFIG_TARGET_CLEARFOG=y > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y > > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" > > CONFIG_SPL_TEXT_BASE=0x4030 > > +CONFIG_SPL_MMC=y > > SPL contains code just for loading main u-boot. So I think you do not > need MMC support in SPL code (symbols prefixed by CONFIG_SPL) which > loads u-boot from SATA. > Correct, I'll remove it. That's actually all of the changes removed (the rest are canonicalization or the resolved MMC issue), so I'll drop this patch completely in v2. > CONFIG_SPL_SERIAL=y > > +CONFIG_SPL_STACK=0x4002c000 > > CONFIG_SPL=y > > CONFIG_DEBUG_UART_BASE=0xf1012000 > > CONFIG_DEBUG_UART_CLOCK=25000 > > @@ -18,8 +23,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 > > CONFIG_DEBUG_UART=y > > CONFIG_AHCI=y > > CONFIG_DISTRO_DEFAULTS=y > > -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > > CONFIG_BOOTDELAY=3 > > CONFIG_USE_PREBOOT=y > > CONFIG_SYS_CONSOLE_INFO_QUIET=y > > @@ -31,7 +34,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 > > CONFIG_SPL_BSS_MAX_SIZE=0x4000 > > CONFIG_SPL_SYS_MALLOC_SIMPLE=y > > # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set > > -CONFIG_SPL_STACK=0x4002c000 > > CONFIG_SPL_I2C=y > > CONFIG_SYS_MAXARGS=32 > > CONFIG_CMD_TLV_EEPROM=y > > @@ -46,7 +48,6 @@ CONFIG_CMD_USB=y > > CONFIG_CMD_TFTPPUT=y > > CONFIG_CMD_CACHE=y > > CONFIG_CMD_TIME=y > > -CONFIG_CMD_MVEBU_BUBT=y > > CONFIG_ENV_OVERWRITE=y > > CONFIG_ENV_MIN_ENTRIES=128 > > CONFIG_ARP_TIMEOUT=200 > > @@ -59,6 +60,8 @@ CONFIG_DM_I2C=y > > CONFIG_SYS_I2C_MVTWSI=y > > CONFIG_I2C_EEPROM=y > > CONFIG_SPL_I2C_EEPROM=y > > +CONFIG_MMC_BROKEN_CD=y > > +CONFIG_SPL_DM_MMC=y > > CONFIG_SUPPORT_EMMC_BOOT=y > > CONFIG_MMC_SDHCI=y > > CONFIG_MMC_SDHCI_SDMA=y > > -- > > 2.39.2 > > >
[PATCH v4 3/4] Kconfig: j721e: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region
In non-combined boot flow for K3, all the firewalls are locked by default
until sysfw comes up. Rom configures some of the firewall for its usage
along with the SRAM for R5 but the PSRAM region is still locked.
The K3 MCU Scratchpad for j721e was set to a PSRAM region triggering the
firewall exception before sysfw came up. The exception started happening
after adding multi dtb support that accesses the scratchpad for reading
EEPROM contents.
The commit changes R5 MCU scratchpad for j721e to an SRAM region.
Old Map:
┌─┐ 0x41c0
│ SPL │
├─┤ 0x41c4 (approx)
│STACK│
├─┤ 0x41c85b20
│ Global data │
│ sizeof(struct global_data) = 0xd8 │
├─┤ gd->malloc_base = 0x41c85bfc
│HEAP │
│ CONFIG_SYS_MALLOC_F_LEN = 0x7 │
├─┤ CONFIG_SPL_BSS_START_ADDR
│ SPL BSS │ (0x41cf5bfc)
│ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
└─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
(0x41cffbfc)
New Map:
┌─┐ 0x41c0
│ SPL │
├─┤ 0x41c4 (approx)
│EMPTY│
├─┤ 0x41c81920
│STACK│
│ SPL_SIZE_LIMIT_PROVIDE_STACK=0x4000 │
├─┤ 0x41c85920
│ Global data │
│ sizeof(struct global_data) = 0xd8 │
├─┤ gd->malloc_base = 0x41c859f0
│HEAP │
│ CONFIG_SYS_MALLOC_F_LEN = 0x7 │
├─┤ CONFIG_SPL_BSS_START_ADDR
│ SPL BSS │ (0x41cf59f0)
│ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
├─┤ 0x41cff9fc
│ NEW MCU SCRATCHPAD │
│ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │
└─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
(0x41cffbfc)
Fixes: ab977c8b91b4 ("configs: j721s2_evm_r5: Enable support for building
multiple dtbs into FIT")
Signed-off-by: Manorit Chawdhry
[n-fran...@ti.com: SRAM allocation addressing diagram]
Signed-off-by: Neha Francis
Reviewed-by: Tom Rini
Reviewed-by: Kamlesh Gurudasani
---
arch/arm/mach-k3/Kconfig | 3 ++-
configs/j721e_evm_r5_defconfig | 10 --
doc/board/ti/j721e_evm.rst | 27 +++
3 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index a8c3a593d570..0991b42423a0 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -52,7 +52,8 @@ config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE
config SYS_K3_MCU_SCRATCHPAD_BASE
hex
default 0x4028 if SOC_K3_AM654
- default 0x4028 if SOC_K3_J721E || SOC_K3_J721S2
+ default 0x4028 if SOC_K3_J721S2
+ default 0x41cff9fc if SOC_K3_J721E
help
Describes the base address of MCU Scratchpad RAM.
diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig
index 476072659571..afe1f3a31306 100644
--- a/configs/j721e_evm_r5_defconfig
+++ b/configs/j721e_evm_r5_defconfig
@@ -21,10 +21,16 @@ CONFIG_SPL_MMC=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL_DRIVERS_MISC=y
CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_SIZE_LIMIT=0xf59f0
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
+CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x4000
CONFIG_SPL_FS_FAT=y
CONFIG_SPL_LIBDISK_SUPPORT=y
CONFIG_SPL_SPI_FLASH_SUPPORT=y
CONFIG_SPL_SPI=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x41cf59f0
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8008
@@ -32,9 +38,9 @@ CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_BOOTCOMMAND=y
# CONFIG_DISPLAY_CPUINFO is not set
-CONFIG_SPL_MAX_SIZE=0xc
+CONFIG_SPL_MAX_SIZE=0xf59f0
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-CONFIG_SPL_BSS_START_ADDR=0x41cf5bfc
+CONFIG_SPL_BSS_START_ADDR=0x41cf59f0
CONFIG_SPL_BSS_MAX_SIZE=0xa000
CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_STACK_R=y
diff --git a/doc/board/ti/j721e_evm.rst b/doc/board/ti/j721e_evm.rst
index e898601c41ea..ac0ae3d9226b 100644
--- a/doc/board/ti/j721e_evm.rst
+++ b/doc/board/ti/j721e_evm.rst
@@ -268,6 +268,33 @@ Image formats:
| +---+ |
+---+
+R5 Memory Map:
+--
+
+.. code-block:: text
+
+┌─┐ 0x41c0
+│ SPL │
+
[PATCH v4 4/4] arm: mach-k3: Increase SYSFW max image size
From: Dave Gerlach When booting with HS silicon, the system firmware image is 278270, which is slightly larger than currently allocated amount. This can cause unexpected behavior if this overlap interferes with other things in memory, so increase this with a slightly margin added as well to avoid any boot issues that can appear after system firmware gets loaded. Signed-off-by: Dave Gerlach Signed-off-by: Tero Kristo Signed-off-by: Manorit Chawdhry --- arch/arm/mach-k3/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index 0991b42423a0..bae0a827c29f 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -141,8 +141,7 @@ config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART config K3_SYSFW_IMAGE_SIZE_MAX int "Amount of memory dynamically allocated for loading SYSFW blob" depends on K3_LOAD_SYSFW - default 163840 if SOC_K3_AM625 || SOC_K3_AM62A7 - default 278000 + default 28 help Amount of memory (in bytes) reserved through dynamic allocation at runtime for loading the combined System Firmware and configuration image -- 2.34.1
[PATCH v4 2/4] configs: j721e: Merge the HS and non-HS defconfigs
K3 devices have runtime type board detection. Make the default defconfig
include the secure configuration. Then remove the HS specific config.
Non-HS devices will continue to boot due to runtime device type detection.
If TI_SECURE_DEV_PKG is not set the build will emit warnings, for non-HS
devices these can be ignored.
Signed-off-by: Manorit Chawdhry
Acked-by: Andrew Davis
---
MAINTAINERS| 2 -
configs/j721e_evm_a72_defconfig| 3 +-
configs/j721e_evm_r5_defconfig | 1 +
configs/j721e_hs_evm_a72_defconfig | 208 -
configs/j721e_hs_evm_r5_defconfig | 176
5 files changed, 3 insertions(+), 387 deletions(-)
delete mode 100644 configs/j721e_hs_evm_a72_defconfig
delete mode 100644 configs/j721e_hs_evm_r5_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 41c9f265f815..9e5e51b2eeeb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1462,8 +1462,6 @@ F:configs/am65x_hs_evm_r5_defconfig
F: configs/am65x_hs_evm_a53_defconfig
F: configs/j7200_hs_evm_a72_defconfig
F: configs/j7200_hs_evm_r5_defconfig
-F: configs/j721e_hs_evm_a72_defconfig
-F: configs/j721e_hs_evm_r5_defconfig
F: configs/j721s2_hs_evm_a72_defconfig
F: configs/j721s2_hs_evm_r5_defconfig
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 2190df1f3a51..48b48f43e7ec 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -1,5 +1,6 @@
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
@@ -30,7 +31,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; if test ${boot_fit} -eq 1; then run
get_fit_${boot}; run get_overlaystring; run run_fit; else; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
fi;"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig
index 16fa386792d4..476072659571 100644
--- a/configs/j721e_evm_r5_defconfig
+++ b/configs/j721e_evm_r5_defconfig
@@ -1,5 +1,6 @@
CONFIG_ARM=y
CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
CONFIG_SYS_MALLOC_LEN=0x200
CONFIG_SYS_MALLOC_F_LEN=0x7
CONFIG_SPL_GPIO=y
diff --git a/configs/j721e_hs_evm_a72_defconfig
b/configs/j721e_hs_evm_a72_defconfig
deleted file mode 100644
index 7aba55c2d488..
--- a/configs/j721e_hs_evm_a72_defconfig
+++ /dev/null
@@ -1,208 +0,0 @@
-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
-CONFIG_SPL_LIBCOMMON_SUPPORT=y
-CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_NR_DRAM_BANKS=2
-CONFIG_SOC_K3_J721E=y
-CONFIG_TARGET_J721E_A72_EVM=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048
-CONFIG_ENV_SIZE=0x2
-CONFIG_DM_GPIO=y
-CONFIG_SPL_DM_SPI=y
-CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-common-proc-board"
-CONFIG_SPL_TEXT_BASE=0x8008
-CONFIG_DM_RESET=y
-CONFIG_SPL_MMC=y
-CONFIG_SPL_SERIAL=y
-CONFIG_SPL_DRIVERS_MISC=y
-CONFIG_SPL_STACK_R_ADDR=0x8200
-CONFIG_SPL_FS_FAT=y
-CONFIG_SPL_LIBDISK_SUPPORT=y
-CONFIG_SPL_SPI_FLASH_SUPPORT=y
-CONFIG_SPL_SPI=y
-# CONFIG_PSCI_RESET is not set
-CONFIG_DISTRO_DEFAULTS=y
-# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
-CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; run get_fit_${boot}; run
get_overlay_${boot}; run run_fit"
-CONFIG_LOGLEVEL=7
-CONFIG_SPL_MAX_SIZE=0xc
-CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-CONFIG_SPL_BSS_START_ADDR=0x80a0
-CONFIG_SPL_BSS_MAX_SIZE=0x8
-CONFIG_SPL_BOARD_INIT=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-CONFIG_SPL_STACK_R=y
-CONFIG_SYS_SPL_MALLOC=y
-CONFIG_SYS_SPL_MALLOC_SIZE=0x80
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
-CONFIG_SPL_DMA=y
-CONFIG_SPL_ENV_SUPPORT=y
-CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
-CONFIG_SPL_I2C=y
-CONFIG_SPL_DM_MAILBOX=y
-CONFIG_SPL_MTD_SUPPORT=y
-CONFIG_SPL_DM_SPI_FLASH=y
-CONFIG_SPL_NOR_SUPPORT=y
-CONFIG_SPL_DM_RESET=y
-CONFIG_SPL_POWER_DOMAIN=y
-CONFIG_SPL_RAM_SUPPORT=y
-CONFIG_SPL_RAM_DEVICE=y
-# CONFIG_SPL_SPI_FLASH_TINY is not set
-CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
-CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
-CONFIG_SPL_USB_GADGET=y
-CONFIG_SPL_DFU=y
-CONFIG_SPL_YMODEM_SUPPORT=y
-CONFIG_SYS_MAXARGS=64
[PATCH v4 1/4] arm: k3: config.mk: Add missing dependencies on tispl.bin HS
From: Andrew Davis When building for secure devices using non-buildman based image generation the signed tispl.bin file is called tispl.bin_HS. Also build the unsigned tispl.bin file as expected. Signed-off-by: Andrew Davis Signed-off-by: Manorit Chawdhry --- arch/arm/mach-k3/config.mk | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk index 9306f2627d9a..cbf9c10210a6 100644 --- a/arch/arm/mach-k3/config.mk +++ b/arch/arm/mach-k3/config.mk @@ -68,6 +68,8 @@ ifeq ($(CONFIG_TI_SECURE_DEVICE),y) SPL_ITS := u-boot-spl-k3_HS.its $(SPL_ITS): export IS_HS=1 INPUTS-y += tispl.bin_HS +INPUTS-y += tispl.bin +tispl.bin: $(obj)/u-boot-spl-nodtb.bin_HS $(patsubst %,$(obj)/dts/%.dtb_HS,$(subst ",,$(CONFIG_SPL_OF_LIST))) else SPL_ITS := u-boot-spl-k3.its INPUTS-y += tispl.bin -- 2.34.1
[PATCH v4 0/4] J721E HS Fixes
This series fixes the support for J721E board along with some maintainance for it. v4: - Fix docs - applied reviewed-by v3: - drop fixes related to other boards ( make series j721e specific ) - memory map added in docs - applied reviewed-by v2: - Merge two series - Include some more commits that fix the gp builds when merging defconfigs - Update MAINTAINERS to remove hs related defconfigs - applied Acks Andrew Davis (1): arm: k3: config.mk: Add missing dependencies on tispl.bin HS Dave Gerlach (1): arm: mach-k3: Increase SYSFW max image size Manorit Chawdhry (2): configs: j721e: Merge the HS and non-HS defconfigs Kconfig: j721e: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region MAINTAINERS| 2 - arch/arm/mach-k3/Kconfig | 6 +- arch/arm/mach-k3/config.mk | 2 + configs/j721e_evm_a72_defconfig| 3 +- configs/j721e_evm_r5_defconfig | 11 +- configs/j721e_hs_evm_a72_defconfig | 208 - configs/j721e_hs_evm_r5_defconfig | 176 doc/board/ti/j721e_evm.rst | 27 8 files changed, 43 insertions(+), 392 deletions(-) delete mode 100644 configs/j721e_hs_evm_a72_defconfig delete mode 100644 configs/j721e_hs_evm_r5_defconfig -- 2.34.1
Re: [PATCH 1/4] arm: mvebu: clearfog: Fix MMC detection
On Sun, 5 Mar 2023 at 12:19, Pali Rohár wrote:
> On Sunday 05 March 2023 21:30:57 Martin Rowe wrote:
> > A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
> > both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.
>
> When you are sending defconfig changes, please do not put there
> unrelated canonicalization changes. Canonicalization of defconfigs are
> done semi-automatically when Tom regenerates them. So avoid
> CONFIG_SUPPORT_EMMC_BOOT and CONFIG_CMD_MVEBU_BUBT changes for eMMC
> related change.
>
Noted. I'll fix it up.
Anyway, I have looked at how MMC_BROKEN_CD is working in u-boot. The
> relevant part is sdhci_get_cd() function in drivers/mmc/sdhci.c file and
> in mmc_of_parse() function in drivers/mmc/mmc-uclass.c file.
>
> So instead of MMC_BROKEN_CD would not it be better the following u-boot
> specific patch? cd-gpios is completely ignored by u-boot when
> non-removable is set.
>
Both are fine with me. I initially went with MMC_BROKEN_CD since it seemed
like the established way. I've tested the patch below and the only issue is
in the corner case of non-MMC boot while expecting something from MMC, but
the error message is helpful enough ("Card did not respond to voltage
select! : -110"). I'll resubmit with your patch instead.
> diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
> b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
> index 96629294be4b..e725770c1899 100644
> --- a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
> +++ b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
> @@ -10,6 +10,7 @@
>
> {
> u-boot,dm-spl;
> + non-removable; /* assume that the card is always present, required
> for eMMC variant */
> };
>
> {
>
>
> > Signed-off-by: Martin Rowe
> > ---
> > configs/clearfog_defconfig | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> > index 8cd35f9f1a..24e7c16ac7 100644
> > --- a/configs/clearfog_defconfig
> > +++ b/configs/clearfog_defconfig
> > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
> > CONFIG_CMD_TFTPPUT=y
> > CONFIG_CMD_CACHE=y
> > CONFIG_CMD_TIME=y
> > -CONFIG_CMD_MVEBU_BUBT=y
> > CONFIG_ENV_OVERWRITE=y
> > CONFIG_ENV_MIN_ENTRIES=128
> > CONFIG_ARP_TIMEOUT=200
> > @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y
> > CONFIG_SYS_I2C_MVTWSI=y
> > CONFIG_I2C_EEPROM=y
> > CONFIG_SPL_I2C_EEPROM=y
> > -CONFIG_SUPPORT_EMMC_BOOT=y
> > +CONFIG_MMC_BROKEN_CD=y
> > CONFIG_MMC_SDHCI=y
> > CONFIG_MMC_SDHCI_SDMA=y
> > CONFIG_MMC_SDHCI_MV=y
> > --
> > 2.39.2
> >
>
Re: [PATCH v3 3/4] Kconfig: j721e: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region
On 12:34-20230303, Tom Rini wrote:
> On Fri, Mar 03, 2023 at 03:59:35PM +0530, Manorit Chawdhry wrote:
>
> > In non-combined boot flow for K3, all the firewalls are locked by default
> > until sysfw comes up. Rom configures some of the firewall for its usage
> > along with the SRAM for R5 but the PSRAM region is still locked.
> >
> > The K3 MCU Scratchpad for j721e was set to a PSRAM region triggering the
> > firewall exception before sysfw came up. The exception started happening
> > after adding multi dtb support that accesses the scratchpad for reading
> > EEPROM contents.
> >
> > The commit changes R5 MCU scratchpad for j721e to an SRAM region.
> >
> > Old Map:
> > ┌─┐ 0x41c0
> > │ SPL │
> > ├─┤ 0x41c4 (approx)
> > │STACK│
> > ├─┤ 0x41c85b20
> > │ Global data │
> > │ sizeof(struct global_data) = 0xd8 │
> > ├─┤ gd->malloc_base = 0x41c85bfc
> > │HEAP │
> > │ CONFIG_SYS_MALLOC_F_LEN = 0x7 │
> > ├─┤ CONFIG_SPL_BSS_START_ADDR
> > │ SPL BSS │ (0x41cf5bfc)
> > │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
> > └─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
> > (0x41cffbfc)
> >
> > New Map:
> > ┌─┐ 0x41c0
> > │ SPL │
> > ├─┤ 0x41c4 (approx)
> > │EMPTY│
> > ├─┤ 0x41c81920
> > │STACK│
> > │ SPL_SIZE_LIMIT_PROVIDE_STACK=0x4000 │
> > ├─┤ 0x41c85920
> > │ Global data │
> > │ sizeof(struct global_data) = 0xd8 │
> > ├─┤ gd->malloc_base = 0x41c859f0
> > │HEAP │
> > │ CONFIG_SYS_MALLOC_F_LEN = 0x7 │
> > ├─┤ CONFIG_SPL_BSS_START_ADDR
> > │ SPL BSS │ (0x41cf59f0)
> > │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
> > ├─┤ 0x41cff9fc
> > │ NEW MCU SCRATCHPAD │
> > │ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │
> > └─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
> > (0x41cffbfc)
> >
> > Fixes: ab977c8b91b4 ("configs: j721s2_evm_r5: Enable support for building
> > multiple dtbs into FIT")
> >
> > Signed-off-by: Manorit Chawdhry
> > [n-fran...@ti.com: SRAM allocation addressing diagram]
> > Signed-off-by: Neha Francis
> > Reviewed-by: Tom Rini
> > ---
> > arch/arm/mach-k3/Kconfig | 3 ++-
> > configs/j721e_evm_r5_defconfig | 10 --
> > doc/board/ti/j721e_evm.rst | 24
>
> OK, sorry. I'm glad you added this to the rst, but it's not a literal
> drop-in. The first issue is that "make htmldocs" notices indentation
> problems, and I was checking this because I'm not sure how what you did
> would render. Please make sure "make htmldocs" at least passes, and
> check the output in a browser as well to make sure the table reads
> well. FWIW, this is the same sphinx docbook stuff as the kernel, so
> there's probably some other examples in tree there you can look at if
> you can't find anything in-tree here that gets you the output you want.
>
Ah, am sorry, had no idea on this. Will run all this and send the next
revision, thanks for telling!
Thanks and regards,
Manorit
> --
> Tom
Re: [PATCH v3 00/17] Basic StarFive JH7110 RISC-V SoC support
On 2023/3/4 5:08, Conor Dooley wrote: > Hey Yanhong, > > On Fri, Mar 03, 2023 at 11:24:15AM +0800, Yanhong Wang wrote: >> This series of patches base on the latest branch/master, and add support >> for the StarFive JH7110 RISC-V SoC and VisionFive V2 board. In order for >> this to be achieved, the respective DT nodes have been added, and the >> required defconfigs have been added to the boards' defconfig. What is more, >> the basic required DM drivers have been added, such as reset, clock, pinctrl, >> uart, ram etc. >> >> Note that the register base address of reset controller is same with the >> clock controller. Therefore, there is no device tree node alone for reset >> driver. It binds device node in the clock driver. >> >> The u-boot-spl and u-boot has been tested on the StarFive VisionFive 2 >> boards which >> equip with JH7110 SoC and works normally. >> >> For more information and support, you can visit RVspace wiki[1]. > > I gave you some tested-bys for the series on the previous version, did > you omit those here intentionally? > Sorry, I forgot to add the information of tested-bys, it was not intentionally omitted. > Cheers, > Conor.
Re: [PATCH v3 16/17] riscv: dts: jh7110: Add initial StarFive VisionFive v2 board device tree
On 2023/3/4 5:20, Conor Dooley wrote:
> On Fri, Mar 03, 2023 at 11:24:31AM +0800, Yanhong Wang wrote:
>> Add initial device tree for StarFive VisionFive v2 board.
>>
>> Signed-off-by: Yanhong Wang
>> ---
>> arch/riscv/dts/Makefile | 3 +-
>> ...10-starfive-visionfive-2-v1.2a-u-boot.dtsi | 85 ++
>> .../jh7110-starfive-visionfive-2-v1.2a.dts| 12 +
>> ...10-starfive-visionfive-2-v1.3b-u-boot.dtsi | 85 ++
>> .../jh7110-starfive-visionfive-2-v1.3b.dts| 12 +
>> .../dts/jh7110-starfive-visionfive-2.dtsi | 253 ++
>> 6 files changed, 449 insertions(+), 1 deletion(-)
>> create mode 100644
>> arch/riscv/dts/jh7110-starfive-visionfive-2-v1.2a-u-boot.dtsi
>> create mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2-v1.2a.dts
>> create mode 100644
>> arch/riscv/dts/jh7110-starfive-visionfive-2-v1.3b-u-boot.dtsi
>> create mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2-v1.3b.dts
>> create mode 100644 arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
>
>> diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
>> b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
>> new file mode 100644
>> index 00..e669c2a26a
>> --- /dev/null
>> +++ b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
>> @@ -0,0 +1,253 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +/*
>> + * Copyright (C) 2022 StarFive Technology Co., Ltd.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "jh7110.dtsi"
>> +#include
>> +/ {
>> +aliases {
>> +serial0 =
>> +spi0 =
>> +mmc0 =
>> +mmc1 =
>> +};
>> +
>> +chosen {
>> +stdout-path = "serial0:115200";
>> +};
>> +
>> +cpus {
>> +timebase-frequency = <400>;
>> +};
>> +
>> +memory@4000 {
>> +device_type = "memory";
>> +reg = <0x0 0x4000 0x2 0x0>;
>> +};
>> +};
>> +
>
>> +_0 {
>> +status = "okay";
>> +};
>
> Please forgive me if I am missing something obvious, but should this be
> be in -u-boot.dtsi instead?
>
Thanks. I will move this node to -u-boot.dtsi.
> Cheers,
> Conor.
Re: [PATCH v3 02/17] cache: starfive: Add StarFive JH7110 support
On 2023/3/4 5:07, Conor Dooley wrote:
> On Fri, Mar 03, 2023 at 11:24:17AM +0800, Yanhong Wang wrote:
>> This adds support for the StarFive JH7110 SoC which also
>> feature this SiFive cache controller.
>>
>> Signed-off-by: Yanhong Wang
>> ---
>> drivers/cache/cache-sifive-ccache.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/cache/cache-sifive-ccache.c
>> b/drivers/cache/cache-sifive-ccache.c
>> index c8766f6242..c1bef0b4d3 100644
>> --- a/drivers/cache/cache-sifive-ccache.c
>> +++ b/drivers/cache/cache-sifive-ccache.c
>> @@ -62,6 +62,7 @@ static int sifive_ccache_probe(struct udevice *dev)
>> static const struct udevice_id sifive_ccache_ids[] = {
>> { .compatible = "sifive,fu540-c000-ccache" },
>> { .compatible = "sifive,fu740-c000-ccache" },
>> +{ .compatible = "starfive,jh7110-ccache" },
>
> Perhaps there's a u-boot policy I am not aware of, but why not just add
> "sifive,ccache0" here instead, since the jh7110's ccache is compatible
> with that?
>
Thanks. I will add "sifive,ccache0" here instead.
> Thanks,
> Conor.
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Hi Pali, On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár wrote: > > On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh wrote: > > > > > > Hi Pali, > > > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote: > > > > > > > > > > > Improve code for checking strapping pins which specifies boot mode > > > > > > source. > > > > > > > > > > > > Martin, could you test if Clearfog can be still configured into UART > > > > > > booting mode via HW switches and if it still works correctly? First > > > > > > patch is reverting UART related commit for Clearfog which I think > > > > > > it not > > > > > > needed anymore. > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the > > > > > switch that > > > > > you refactored in cpu.c/get_boot_device is all that gets processed. It > > > > > decides there is an error and returns BOOT_DEVICE_UART, probably > > > > > because of > > > > > the invalid boot workaround for broken UART selection that you > > > > > identified. > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or if I select > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or > > > > > SATA > > > > > defconfigs. I get the same result without this patch series applied, > > > > > though. > > > > > > > > > > The failed cases have the same output (other than kwboot header > > > > > patching > > > > > output) until after sending boot image data is complete. The output > > > > > stops > > > > > after: > > > > > > > > > > 98 % > > > > > [. > > > > > ] > > > > > Done > > > > > Finishing transfer > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > If I'm looking at the output correctly then SPL was booted, it correctly > > > > trained DDR RAM, returned back to bootrom, kwboot continued sending main > > > > u-boot and bootrom confirmed that transfer of both SPL and main u-boot > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I was sure was > > > > > working after the last patches but I can no longer reproduce a > > > > > successful > > > > > boot. > > > > > > > > Can you check that you are using _both_ mkimage and kwboot from version > > > > with applying _all_ my patches recently sent to ML? Because both mkimage > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > For me it looks like that either mkimage generated incorrect image size > > > > for SATA or SDIO image. Or kwboot incorrectly parsed that image size > > > > from kwbimage header and sent smaller image. > > > > > > > > > > > > > > > Also could you check if SATA booting is still working correctly? > > > > > > > > > > > > > > > > SATA works correctly. > > > > > > > > Perfect! > > > > > > > > > > > > > > > Tony, should address problems with SPI booting when it is > > > > > > configured to > > > > > > different configuration. In fourth commit I added all possible boot > > > > > > mode > > > > > > strapping pin configurations which are recognized by A385 bootrom > > > > > > (and > > > > > > not the only one described in the HW spec, which is incomplete). > > > > > > It works great! Here the strapping is SPI 1 (0x34), and the boot mode > > > is set to "Trying to boot from SPI" correctly. I'm having a problem > > > with SPL SPI probing the device. But I don't think it is not related > > > to this boot mode patch. There is something in SPL SPI that either I > > > don't understand or it is a bug. > > > > I meant "But I don't think it is related to this boot mode patch". > > 0x34 uses SPI controller 1. So maybe you need to adjust some config > options? In your log is usage of bus 0, so maybe this could be the > reason. Previously I did not use bus 1, and used the default bus 0 and it still works! so I've suspected there is some problem in SPL SPI (i.e. it works when it should not). But now default bus 0 no longer works. I am configuring bus 1, but I'm not yet successful. There are multiple places where bus 1 is needed to be specified. Also, might I also need -u-boot.dtsi to tag the spi1 as dm,pre-reloc ? Thanks, Tony > > > > > > U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - > > > 13:52:31 -0800) > > > High speed PHY - Version: 2.0 > > > Detected Device ID 6820 > > > board SerDes lanes topology details: > > > | Lane # | Speed | Type | > > > > > > | 0| 0 | SGMII0 | > > >
[PATCH] ARM: imx: Include on-SoM microSD in list of i.MX6 DHCOM boot devices
Add mmc1, which is mapped to optional on-SoM microSD socket, to the list of distro boot command boot devices. Signed-off-by: Marek Vasut --- Cc: Andreas Geisreiter Cc: Christoph Niedermaier Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Cc: u-b...@dh-electronics.com --- include/configs/dh_imx6.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/dh_imx6.h b/include/configs/dh_imx6.h index 54b2192b4a8..9d4addbc2f7 100644 --- a/include/configs/dh_imx6.h +++ b/include/configs/dh_imx6.h @@ -65,6 +65,7 @@ #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 0) \ + func(MMC, mmc, 1) \ func(MMC, mmc, 2) \ func(USB, usb, 1) \ func(SATA, sata, 0) \ -- 2.39.2
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh wrote: > > > > Hi Pali, > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote: > > > > > > > > > Improve code for checking strapping pins which specifies boot mode > > > > > source. > > > > > > > > > > Martin, could you test if Clearfog can be still configured into UART > > > > > booting mode via HW switches and if it still works correctly? First > > > > > patch is reverting UART related commit for Clearfog which I think it > > > > > not > > > > > needed anymore. > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch > > > > that > > > > you refactored in cpu.c/get_boot_device is all that gets processed. It > > > > decides there is an error and returns BOOT_DEVICE_UART, probably > > > > because of > > > > the invalid boot workaround for broken UART selection that you > > > > identified. > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > UART only works if I use the clearfog_spi_defconfig or if I select > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or > > > > SATA > > > > defconfigs. I get the same result without this patch series applied, > > > > though. > > > > > > > > The failed cases have the same output (other than kwboot header patching > > > > output) until after sending boot image data is complete. The output > > > > stops > > > > after: > > > > > > > > 98 % [. > > > > ] > > > > Done > > > > Finishing transfer > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just > > > instruct mkimage what to put into kwbimage header. > > > > > > If I'm looking at the output correctly then SPL was booted, it correctly > > > trained DDR RAM, returned back to bootrom, kwboot continued sending main > > > u-boot and bootrom confirmed that transfer of both SPL and main u-boot > > > is complete. But then there is no output from main u-boot. > > > > > > > It looks like an unrelated issue with kwboot.c, which I was sure was > > > > working after the last patches but I can no longer reproduce a > > > > successful > > > > boot. > > > > > > Can you check that you are using _both_ mkimage and kwboot from version > > > with applying _all_ my patches recently sent to ML? Because both mkimage > > > and kwboot have fixes for SATA and SDIO images. > > > > > > For me it looks like that either mkimage generated incorrect image size > > > for SATA or SDIO image. Or kwboot incorrectly parsed that image size > > > from kwbimage header and sent smaller image. > > > > > > > > > > > > Also could you check if SATA booting is still working correctly? > > > > > > > > > > > > > SATA works correctly. > > > > > > Perfect! > > > > > > > > > > > > Tony, should address problems with SPI booting when it is configured > > > > > to > > > > > different configuration. In fourth commit I added all possible boot > > > > > mode > > > > > strapping pin configurations which are recognized by A385 bootrom (and > > > > > not the only one described in the HW spec, which is incomplete). > > > > It works great! Here the strapping is SPI 1 (0x34), and the boot mode > > is set to "Trying to boot from SPI" correctly. I'm having a problem > > with SPL SPI probing the device. But I don't think it is not related > > to this boot mode patch. There is something in SPL SPI that either I > > don't understand or it is a bug. > > I meant "But I don't think it is related to this boot mode patch". 0x34 uses SPI controller 1. So maybe you need to adjust some config options? In your log is usage of bus 0, so maybe this could be the reason. > Thanks, > Tony > > > > > U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - > > 13:52:31 -0800) > > High speed PHY - Version: 2.0 > > Detected Device ID 6820 > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > > > | 0| 0 | SGMII0 | > > | 1| 3 | SATA0 | > > | 2| 3 | SATA1 | > > | 4| 5 | USB3 HOST0 | > > | 5| 5 | USB3 HOST1 | > > > > High speed PHY - Ended Successfully > > mv_ddr: 14.0.0 > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window > > mv_ddr: completed successfully > > SAR_REG=0xcb00934c boot_device=0x34 > > Trying to boot from SPI > > spl_spi_load_image sf_bus = 0 sf_cs = 0 > > spi_flash_probe spi_flash > > Invalid bus 0 (err=-19) > > SPI probe failed. > > Trying to boot from BOOTROM > > Returning to BootROM (return address 0x05c4)... > > BootROM: Image checksum verification PASSED > > > > Thanks, > > Tony > > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh wrote: > > Hi Pali, > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote: > > > > > > > Improve code for checking strapping pins which specifies boot mode > > > > source. > > > > > > > > Martin, could you test if Clearfog can be still configured into UART > > > > booting mode via HW switches and if it still works correctly? First > > > > patch is reverting UART related commit for Clearfog which I think it not > > > > needed anymore. > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch > > > that > > > you refactored in cpu.c/get_boot_device is all that gets processed. It > > > decides there is an error and returns BOOT_DEVICE_UART, probably because > > > of > > > the invalid boot workaround for broken UART selection that you identified. > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > UART only works if I use the clearfog_spi_defconfig or if I select > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA > > > defconfigs. I get the same result without this patch series applied, > > > though. > > > > > > The failed cases have the same output (other than kwboot header patching > > > output) until after sending boot image data is complete. The output stops > > > after: > > > > > > 98 % [. > > > ] > > > Done > > > Finishing transfer > > > [Type Ctrl-\ + c to quit] > > > > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just > > instruct mkimage what to put into kwbimage header. > > > > If I'm looking at the output correctly then SPL was booted, it correctly > > trained DDR RAM, returned back to bootrom, kwboot continued sending main > > u-boot and bootrom confirmed that transfer of both SPL and main u-boot > > is complete. But then there is no output from main u-boot. > > > > > It looks like an unrelated issue with kwboot.c, which I was sure was > > > working after the last patches but I can no longer reproduce a successful > > > boot. > > > > Can you check that you are using _both_ mkimage and kwboot from version > > with applying _all_ my patches recently sent to ML? Because both mkimage > > and kwboot have fixes for SATA and SDIO images. > > > > For me it looks like that either mkimage generated incorrect image size > > for SATA or SDIO image. Or kwboot incorrectly parsed that image size > > from kwbimage header and sent smaller image. > > > > > > > > > Also could you check if SATA booting is still working correctly? > > > > > > > > > > SATA works correctly. > > > > Perfect! > > > > > > > > > Tony, should address problems with SPI booting when it is configured to > > > > different configuration. In fourth commit I added all possible boot mode > > > > strapping pin configurations which are recognized by A385 bootrom (and > > > > not the only one described in the HW spec, which is incomplete). > > It works great! Here the strapping is SPI 1 (0x34), and the boot mode > is set to "Trying to boot from SPI" correctly. I'm having a problem > with SPL SPI probing the device. But I don't think it is not related > to this boot mode patch. There is something in SPL SPI that either I > don't understand or it is a bug. I meant "But I don't think it is related to this boot mode patch". Thanks, Tony > > U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - > 13:52:31 -0800) > High speed PHY - Version: 2.0 > Detected Device ID 6820 > board SerDes lanes topology details: > | Lane # | Speed | Type | > > | 0| 0 | SGMII0 | > | 1| 3 | SATA0 | > | 2| 3 | SATA1 | > | 4| 5 | USB3 HOST0 | > | 5| 5 | USB3 HOST1 | > > High speed PHY - Ended Successfully > mv_ddr: 14.0.0 > DDR4 Training Sequence - Switching XBAR Window to FastPath Window > mv_ddr: completed successfully > SAR_REG=0xcb00934c boot_device=0x34 > Trying to boot from SPI > spl_spi_load_image sf_bus = 0 sf_cs = 0 > spi_flash_probe spi_flash > Invalid bus 0 (err=-19) > SPI probe failed. > Trying to boot from BOOTROM > Returning to BootROM (return address 0x05c4)... > BootROM: Image checksum verification PASSED > > Thanks, > Tony > > > > > > > > > Stefan, do you have some AXP board with SATA boot source? Because I'm > > > > adding it for completeness in the last sixth patch. > > > > > > > > Pali Rohár (6): > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > arm: mvebu: Convert BOOT_FROM_* constants to function macros > > > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_*
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Hi Pali, On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote: > > > > > Improve code for checking strapping pins which specifies boot mode source. > > > > > > Martin, could you test if Clearfog can be still configured into UART > > > booting mode via HW switches and if it still works correctly? First > > > patch is reverting UART related commit for Clearfog which I think it not > > > needed anymore. > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that > > you refactored in cpu.c/get_boot_device is all that gets processed. It > > decides there is an error and returns BOOT_DEVICE_UART, probably because of > > the invalid boot workaround for broken UART selection that you identified. > > Ok, so I figured out correctly how this invalid mode works. > > > UART only works if I use the clearfog_spi_defconfig or if I select > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA > > defconfigs. I get the same result without this patch series applied, though. > > > > The failed cases have the same output (other than kwboot header patching > > output) until after sending boot image data is complete. The output stops > > after: > > > > 98 % [. > > ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just > instruct mkimage what to put into kwbimage header. > > If I'm looking at the output correctly then SPL was booted, it correctly > trained DDR RAM, returned back to bootrom, kwboot continued sending main > u-boot and bootrom confirmed that transfer of both SPL and main u-boot > is complete. But then there is no output from main u-boot. > > > It looks like an unrelated issue with kwboot.c, which I was sure was > > working after the last patches but I can no longer reproduce a successful > > boot. > > Can you check that you are using _both_ mkimage and kwboot from version > with applying _all_ my patches recently sent to ML? Because both mkimage > and kwboot have fixes for SATA and SDIO images. > > For me it looks like that either mkimage generated incorrect image size > for SATA or SDIO image. Or kwboot incorrectly parsed that image size > from kwbimage header and sent smaller image. > > > > > > Also could you check if SATA booting is still working correctly? > > > > > > > SATA works correctly. > > Perfect! > > > > > > Tony, should address problems with SPI booting when it is configured to > > > different configuration. In fourth commit I added all possible boot mode > > > strapping pin configurations which are recognized by A385 bootrom (and > > > not the only one described in the HW spec, which is incomplete). It works great! Here the strapping is SPI 1 (0x34), and the boot mode is set to "Trying to boot from SPI" correctly. I'm having a problem with SPL SPI probing the device. But I don't think it is not related to this boot mode patch. There is something in SPL SPI that either I don't understand or it is a bug. U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - 13:52:31 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type | | 0| 0 | SGMII0 | | 1| 3 | SATA0 | | 2| 3 | SATA1 | | 4| 5 | USB3 HOST0 | | 5| 5 | USB3 HOST1 | High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 0 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0x05c4)... BootROM: Image checksum verification PASSED Thanks, Tony > > > > > > Stefan, do you have some AXP board with SATA boot source? Because I'm > > > adding it for completeness in the last sixth patch. > > > > > > Pali Rohár (6): > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > arm: mvebu: Convert BOOT_FROM_* constants to function macros > > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > > > arch/arm/mach-mvebu/cpu.c | 20 ++--- > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 -- > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > -- > > > 2.20.1 > > > > > >
[PATCH] ARM: dts: imx: Add WDT bindings on DH i.MX6 DHSOM
Add WDT reboot bindings on DH i.MX6 DHSOM to permit the platform
to reboot via WDT in U-Boot. These are custom U-Boot bindings,
hence they are placed in -u-boot.dtsi .
Signed-off-by: Marek Vasut
---
Cc: Andreas Geisreiter
Cc: Christoph Niedermaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
Cc: u-b...@dh-electronics.com
---
arch/arm/dts/imx6qdl-dhcom-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/imx6qdl-dhcom-u-boot.dtsi
b/arch/arm/dts/imx6qdl-dhcom-u-boot.dtsi
index 190567ab7ba..06ad98bccf6 100644
--- a/arch/arm/dts/imx6qdl-dhcom-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-dhcom-u-boot.dtsi
@@ -8,6 +8,12 @@
aliases {
eeprom0 =
};
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ u-boot,dm-spl;
+ };
};
{
@@ -25,3 +31,7 @@
gpio = < 31 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ {
+ u-boot,dm-spl;
+};
--
2.39.2
[PATCH] ARM: imx: Convert DH i.MX6 DHSOM to DM_SERIAL
Enable CONFIG_DM_SERIAL on DH i.MX6 DHSOM to convert it to DM serial . Signed-off-by: Marek Vasut --- Cc: Andreas Geisreiter Cc: Christoph Niedermaier Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Cc: u-b...@dh-electronics.com --- configs/dh_imx6_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig index 035ad1d5c91..a6069bd34e9 100644 --- a/configs/dh_imx6_defconfig +++ b/configs/dh_imx6_defconfig @@ -99,6 +99,7 @@ CONFIG_PINCTRL_IMX6=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_SCSI=y +CONFIG_DM_SERIAL=y CONFIG_MXC_UART=y CONFIG_SPI=y CONFIG_DM_SPI=y -- 2.39.2
[PATCH 4/5] microblaze: drop CONFIG_NEEDS_MANUAL_RELOC
Microblaze and m68k are the only remaining architectures that still enable
CONFIG_NEEDS_MANUAL_RELOC by default.
Microblaze has had runtime relocation support using CONFIG_STATIC_RELA for
quite some time, since commit d58c007498 ("microblaze: Add support for run
time relocation"). Drop support for CONFIG_NEEDS_MANUAL_RELOC and make
runtime relocation the default, as the rest of the architectures do.
Signed-off-by: Ovidiu Panait
---
arch/microblaze/Kconfig | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index ce157a79cc..e38c9f6d71 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -4,19 +4,8 @@ menu "MicroBlaze architecture"
config SYS_ARCH
default "microblaze"
-config NEEDS_MANUAL_RELOC
- bool "Disable position-independent pre-relocation code"
- default y
- help
- U-Boot expects to be linked to a specific hard-coded address, and to
- be loaded to and run from that address. This option lifts that
- restriction, thus allowing the code to be loaded to and executed from
- almost any 4K aligned address. This logic relies on the relocation
- information that is embedded in the binary to support U-Boot
- relocating itself to the top-of-RAM later during execution.
-
config STATIC_RELA
- def_bool y if !NEEDS_MANUAL_RELOC
+ def_bool y
choice
prompt "Target select"
--
2.25.1
[PATCH 5/5] microblaze: drop remnants of manual reloc
Runtime relocation has been made the default for microblaze, so do the following cleanups: - drop all manual reloc codepaths in start.S - drop all STATIC_RELA ifdefs, as it is now enabled unconditionally in Kconfig Signed-off-by: Ovidiu Panait --- arch/microblaze/config.mk| 4 arch/microblaze/cpu/Makefile | 3 +-- arch/microblaze/cpu/start.S | 28 3 files changed, 1 insertion(+), 34 deletions(-) diff --git a/arch/microblaze/config.mk b/arch/microblaze/config.mk index 467c5ca1b1..64c3f31319 100644 --- a/arch/microblaze/config.mk +++ b/arch/microblaze/config.mk @@ -13,10 +13,6 @@ LDFLAGS_FINAL += --gc-sections ifeq ($(CONFIG_SPL_BUILD),) PLATFORM_CPPFLAGS += -fPIC -endif - -ifeq ($(CONFIG_STATIC_RELA),y) -PLATFORM_CPPFLAGS += -fPIC LDFLAGS_u-boot += -pic endif diff --git a/arch/microblaze/cpu/Makefile b/arch/microblaze/cpu/Makefile index 1c586a7de0..b8c1dcbe14 100644 --- a/arch/microblaze/cpu/Makefile +++ b/arch/microblaze/cpu/Makefile @@ -5,7 +5,6 @@ extra-y= start.o obj-y = irq.o -obj-y += interrupts.o cache.o exception.o cpuinfo.o -obj-$(CONFIG_STATIC_RELA) += relocate.o +obj-y += interrupts.o cache.o exception.o cpuinfo.o relocate.o obj-$(CONFIG_XILINX_MICROBLAZE0_PVR) += pvr.o obj-$(CONFIG_SPL_BUILD)+= spl.o diff --git a/arch/microblaze/cpu/start.S b/arch/microblaze/cpu/start.S index 7079d9e170..c1e0fcda0a 100644 --- a/arch/microblaze/cpu/start.S +++ b/arch/microblaze/cpu/start.S @@ -10,16 +10,11 @@ #include #include -#if defined(CONFIG_STATIC_RELA) #define SYM_ADDR(reg, reg_add, symbol) \ mfs r20, rpc; \ addik r20, r20, _GLOBAL_OFFSET_TABLE_ + 8; \ lwi reg, r20, symbol@GOT; \ addkreg, reg reg_add; -#else -#define SYM_ADDR(reg, reg_add, symbol) \ - addireg, reg_add, symbol -#endif .text .global _start @@ -35,7 +30,6 @@ _start: addir1, r0, CONFIG_SPL_STACK #else add r1, r0, r20 -#if defined(CONFIG_STATIC_RELA) bri 1f /* Force alignment for easier ASM code below */ @@ -67,7 +61,6 @@ uboot_sym_start: brlid r15, mb_fix_rela nop -#endif #endif addir1, r1, -4 /* Decrement SP to top of memory */ @@ -310,7 +303,6 @@ relocate_code: brlid r15, __setup_exceptions nop -#if defined(CONFIG_STATIC_RELA) /* reloc_offset is current location */ SYM_ADDR(r10, r0, _start) @@ -331,27 +323,7 @@ relocate_code: add r9, r9, r5 brlid r15, mb_fix_rela nop - /* end of code which does relocation */ -#else - /* Check if GOT exist */ - addik r21, r23, _got_start - addik r22, r23, _got_end - cmpur12, r21, r22 - beqir12, 2f /* No GOT table - jump over */ - - /* Skip last 3 entries plus 1 because of loop boundary below */ - addik r22, r22, -0x10 - -/* Relocate the GOT. */ -3: lw r12, r21, r0 /* Load entry */ - addkr12, r12, r23 /* Add reloc offset */ - sw r12, r21, r0 /* Save entry back */ - - cmpur12, r21, r22 /* Check if this cross boundary */ - bneid r12, 3b - addik r21. r21, 4 -#endif /* Flush caches to ensure consistency */ brlid r15, flush_cache_all -- 2.25.1
[PATCH 3/5] tools: relocate-rela: add support for handling 32-bit big endian files
Currently, a microblaze build with CONFIG_SYS_BIG_ENDIAN=y and
CONFIG_STATIC_RELA=y fails with:
tools/relocate-rela: Not supported machine type
ELF decoding failed
make[2]: *** [u-boot/Makefile:1306: u-boot-nodtb.bin] Error 1
To fix this, convert the 32-bit codepath to use the previously added
elf{16,32}_to_cpu() functions. The aarch64 codepath is left untouched.
This commit ensures that CI doesn't fail for the next patches which enable
runtime relocation by default for microblaze.
Signed-off-by: Ovidiu Panait
---
tools/relocate-rela.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
index 84531b23a6..2bc46a12d7 100644
--- a/tools/relocate-rela.c
+++ b/tools/relocate-rela.c
@@ -251,7 +251,7 @@ static int decode_elf32(FILE *felf, char **argv)
return 25;
}
- machine = le16_to_cpu(header.e_machine);
+ machine = elf16_to_cpu(header.e_machine);
debug("Machine %d\n", machine);
if (machine != EM_MICROBLAZE) {
@@ -259,10 +259,10 @@ static int decode_elf32(FILE *felf, char **argv)
return 30;
}
- text_base = le32_to_cpu(header.e_entry);
- section_header_base = le32_to_cpu(header.e_shoff);
- section_header_size = le16_to_cpu(header.e_shentsize) *
- le16_to_cpu(header.e_shnum);
+ text_base = elf32_to_cpu(header.e_entry);
+ section_header_base = elf32_to_cpu(header.e_shoff);
+ section_header_size = elf16_to_cpu(header.e_shentsize) *
+ elf16_to_cpu(header.e_shnum);
sh_table = malloc(section_header_size);
if (!sh_table) {
@@ -290,8 +290,8 @@ static int decode_elf32(FILE *felf, char **argv)
return 27;
}
- sh_index = le16_to_cpu(header.e_shstrndx);
- sh_size = le32_to_cpu(sh_table[sh_index].sh_size);
+ sh_index = elf16_to_cpu(header.e_shstrndx);
+ sh_size = elf32_to_cpu(sh_table[sh_index].sh_size);
debug("e_shstrndx %x, sh_size %lx\n", sh_index, sh_size);
sh_str = malloc(sh_size);
@@ -306,8 +306,8 @@ static int decode_elf32(FILE *felf, char **argv)
* Specifies the byte offset from the beginning of the file
* to the first byte in the section.
*/
- sh_offset = le32_to_cpu(sh_table[sh_index].sh_offset);
- sh_num = le16_to_cpu(header.e_shnum);
+ sh_offset = elf32_to_cpu(sh_table[sh_index].sh_offset);
+ sh_num = elf16_to_cpu(header.e_shnum);
ret = fseek(felf, sh_offset, SEEK_SET);
if (ret) {
@@ -329,13 +329,13 @@ static int decode_elf32(FILE *felf, char **argv)
}
for (i = 0; i < sh_num; i++) {
- char *sh_name = sh_str + le32_to_cpu(sh_table[i].sh_name);
+ char *sh_name = sh_str + elf32_to_cpu(sh_table[i].sh_name);
debug("%s\n", sh_name);
- sh_addr = le32_to_cpu(sh_table[i].sh_addr);
- sh_offset = le32_to_cpu(sh_table[i].sh_offset);
- sh_size = le32_to_cpu(sh_table[i].sh_size);
+ sh_addr = elf32_to_cpu(sh_table[i].sh_addr);
+ sh_offset = elf32_to_cpu(sh_table[i].sh_offset);
+ sh_size = elf32_to_cpu(sh_table[i].sh_size);
if (!strcmp(".rela.dyn", sh_name)) {
debug("Found section\t\".rela_dyn\"\n");
@@ -540,9 +540,9 @@ static int rela_elf32(char **argv, FILE *f)
PRIu32 " r_addend:\t%" PRIx32 "\n",
rela.r_offset, rela.r_info, rela.r_addend);
- swrela.r_offset = le32_to_cpu(rela.r_offset);
- swrela.r_info = le32_to_cpu(rela.r_info);
- swrela.r_addend = le32_to_cpu(rela.r_addend);
+ swrela.r_offset = elf32_to_cpu(rela.r_offset);
+ swrela.r_info = elf32_to_cpu(rela.r_info);
+ swrela.r_addend = elf32_to_cpu(rela.r_addend);
debug("SWRela:\toffset:\t%" PRIx32 " r_info:\t%"
PRIu32 " r_addend:\t%" PRIx32 "\n",
--
2.25.1
[PATCH 2/5] tools: relocate-rela: introduce elf16_to_cpu() and elf32_to_cpu()
Add elf16_to_cpu() and elf32_to_cpu() functions that allow to read data in
both big-endian and little-endian formats.
Signed-off-by: Ovidiu Panait
---
tools/relocate-rela.c | 20
1 file changed, 20 insertions(+)
diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
index 689e2d4655..84531b23a6 100644
--- a/tools/relocate-rela.c
+++ b/tools/relocate-rela.c
@@ -45,6 +45,7 @@
#endif
static int ei_class;
+static int ei_data;
static uint64_t rela_start, rela_end, text_base, dyn_start;
@@ -61,6 +62,22 @@ static void debug(const char *fmt, ...)
}
}
+static uint16_t elf16_to_cpu(uint16_t data)
+{
+ if (ei_data == 0x01)
+ return le16_to_cpu(data);
+
+ return be16_to_cpu(data);
+}
+
+static uint32_t elf32_to_cpu(uint32_t data)
+{
+ if (ei_data == 0x01)
+ return le32_to_cpu(data);
+
+ return be32_to_cpu(data);
+}
+
static bool supported_rela(Elf64_Rela *rela)
{
uint64_t mask = 0xULL; /* would be different on 32-bit */
@@ -384,6 +401,9 @@ static int decode_elf(char **argv)
ei_class = e_ident[4];
debug("EI_CLASS(1=32bit, 2=64bit) %d\n", ei_class);
+ ei_data = e_ident[5];
+ debug("EI_DATA(1=little endian, 2=big endian) %d\n", ei_data);
+
if (ei_class == 2)
return decode_elf64(felf, argv);
--
2.25.1
[PATCH 1/5] tools: relocate-rela: adjust le64_to_cpu -> le32_to_cpu in decode_elf32()
The sh_addr/sh_offset/sh_size fields in Elf32_Shdr are 32-bits wide, so
use le32_to_cpu() instead of the 64-bit variant.
Fixes: 5e0e1a86d327 ("tools: relocate-rela: Fix ELF decoding on big-endian
hosts")
Signed-off-by: Ovidiu Panait
---
tools/relocate-rela.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
index 2d2a2ed277..689e2d4655 100644
--- a/tools/relocate-rela.c
+++ b/tools/relocate-rela.c
@@ -316,9 +316,9 @@ static int decode_elf32(FILE *felf, char **argv)
debug("%s\n", sh_name);
- sh_addr = le64_to_cpu(sh_table[i].sh_addr);
- sh_offset = le64_to_cpu(sh_table[i].sh_offset);
- sh_size = le64_to_cpu(sh_table[i].sh_size);
+ sh_addr = le32_to_cpu(sh_table[i].sh_addr);
+ sh_offset = le32_to_cpu(sh_table[i].sh_offset);
+ sh_size = le32_to_cpu(sh_table[i].sh_size);
if (!strcmp(".rela.dyn", sh_name)) {
debug("Found section\t\".rela_dyn\"\n");
--
2.25.1
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Sunday 05 March 2023 12:46:34 Pali Rohár wrote:
> On Sunday 05 March 2023 02:24:27 Martin Rowe wrote:
> > On Sat, 4 Mar 2023 at 10:40, Pali Rohár wrote:
> >
> > > Boot configuration stored in EXT_CSC register is completely ignored by
> > > BootROM:
> > >
> > > https://lore.kernel.org/u-boot/CAOAjy5SYPPzWKok-BSGYwZwcKOQt_aZPgh6FTbrFd3F=8dm...@mail.gmail.com/
> > >
> > > Reflect this eMMC booting in documentation and in the code.
> > >
> > > Martin, can you test this patch series if SPL and main U-Boot is loaded
> > > from the same eMMC HW partition?
> > >
> >
> > boot0: u-boot
> >
> > Works fine, no issues.
> >
> >
> > boot0: zeroed
> > boot1: u-boot
> > user: zeroed
> >
> > It succeeds, eventually...
> > ==
> > BootROM - 1.73
> >
> > Booting from MMC
> > BootROM: Bad header at offset
> > BootROM: Bad header at offset 0020
> > Switching BootPartitions.
> >
> > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45
> > +1000)
> > High speed PHY - Version: 2.0
> > EEPROM TLV detection failed: Using static config for Clearfog Pro.
> > Detected Device ID 6828
> > board SerDes lanes topology details:
> > | Lane # | Speed | Type |
> >
> > | 0| 3 | SATA0 |
> > | 1| 0 | SGMII1 |
> > | 2| 5 | PCIe1 |
> > | 3| 5 | USB3 HOST1 |
> > | 4| 5 | PCIe2 |
> > | 5| 0 | SGMII2 |
> >
> > High speed PHY - Ended Successfully
> > mv_ddr: 14.0.0
> > DDR3 Training Sequence - Switching XBAR Window to FastPath Window
> > mv_ddr: completed successfully
> > Trying to boot from MMC1
> > ERROR: Invalid kwbimage v1
> > mmc_load_image_raw_sector: mmc block read error
> > spl: mmc: wrong boot mode
> > Trying to boot from BOOTROM
> > Returning to BootROM (return address 0x05c4)...
> > Timeout waiting card ready
> > BootROM: Image checksum verification PASSED
> >
> >
> > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 +1000)
> >
> > SoC: MV88F6828-A0 at 1600 MHz
> > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled)
> > Core: 38 devices, 22 uclasses, devicetree: separate
> > MMC: mv_sdh: 0
> > Loading Environment from MMC... *** Warning - bad CRC, using default
> > environment
> >
> > Model: SolidRun Clearfog A1
> > Board: SolidRun Clearfog Pro
> > Net:
> > Warning: ethernet@7 (eth1) using random MAC address - 12:07:8b:f9:7a:6f
> > eth1: ethernet@7
> > Warning: ethernet@3 (eth2) using random MAC address - ee:ed:f3:bb:c2:af
> > , eth2: ethernet@3
> > Warning: ethernet@34000 (eth3) using random MAC address - ae:34:b9:bb:28:c6
> > , eth3: ethernet@34000
> > Hit any key to stop autoboot: 0
> > =>
> > ==
> >
> > Between "Returning to BootROM" and "Timeout waiting card ready" takes
> > around 315 seconds. That's long enough that I thought it had hung
> > completely and I only noticed it continue because I left it running while
> > working on something else. I tried several things to reduce this timeout,
> > including reverting to the "non-removable" dts for shdci, but nothing seems
> > to affect it.
>
> Ok. So now it is in the state that it is working but is slow. Better
> than nothing.
>
> Message "Returning to BootROM" is printed by SPL and message
> "Timeout waiting card ready" is printed by BootROM. After printing
> "Returning to BootROM" is SPL jumping back to the BootROM so the delay
> is for sure in the BootROM. So seems that SPL reconfigures eMMC into
> state in which BootROM cannot work with it. Something timeouts, BootROM
> reconfigure/retry it and then it work again. It would be needed to
> investigate what is happening here. My guess is that this could have
> something with eMMC HW partition access, and code for switching
> partitions near SPL MMCSD_MODE_EMMCBOOT.
Try this change?
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index b20eac3dcd38..eb59c41a824e 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -297,11 +298,33 @@ u32 spl_boot_device(void)
#endif
+void restore_emmc_boot_part_config(void)
+{
+#ifdef CONFIG_SPL_MMC
+ struct mmc *mmc;
+ int ret;
+
+ mmc = find_mmc_device(0);
+ if (!mmc || !mmc->has_init || mmc->part_config == MMCPART_NOAVAILABLE)
+ return;
+
+ ret = mmc_set_part_conf(mmc,
+ EXT_CSD_EXTRACT_BOOT_ACK(mmc->part_config),
+ EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config),
+ EXT_CSD_EXTRACT_PARTITION_ACCESS(mmc->part_config));
+ if (ret)
+ printf("Failed to restore eMMC boot partition configuration\n");
+#endif
+}
+
int board_return_to_bootrom(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev)
{
u32 *regs =
Re: [PATCH 4/4] arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
On Sunday 05 March 2023 21:31:00 Martin Rowe wrote:
> [upstream of vendor commit 19a96f7c40a8fc1d0a6546ac2418d966e5840a99]
>
> The Clearfog devices have only one SDHC device. This is either eMMC if
> it is populated on the SOM or SDHC if not. The Linux device tree assumes
> the SDHC case. Detect if the device is an eMMC and fixup the device-tree
> so it will be detected by Linux.
>
> Ported from vendor repo at https://github.com/SolidRun/u-boot
>
> Signed-off-by: Martin Rowe
> ---
> board/solidrun/clearfog/clearfog.c | 42 ++
> configs/clearfog_defconfig | 1 +
> configs/clearfog_sata_defconfig| 1 +
> configs/clearfog_spi_defconfig | 1 +
> 4 files changed, 45 insertions(+)
>
> diff --git a/board/solidrun/clearfog/clearfog.c
> b/board/solidrun/clearfog/clearfog.c
> index 03adb591d8..cafead3a1a 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -261,3 +262,44 @@ int board_late_init(void)
>
> return 0;
> }
> +
> +static bool has_emmc(void)
> +{
> + struct mmc *mmc;
> + mmc = find_mmc_device(0);
> + if (!mmc)
> + return 0;
> + return (!mmc_init(mmc) && IS_MMC(mmc)) ? true : false;
> +}
> +
> +/*
> + * The Clearfog devices have only one SDHC device. This is either eMMC
> + * if it is populated on the SOM or SDHC if not. The Linux device tree
> + * assumes the SDHC case. Detect if the device is an eMMC and fixup the
> + * device-tree so it will be detected by Linux.
> + */
> +int ft_board_setup(void *blob, struct bd_info *bd)
> +{
> + __maybe_unused int offset, rc;
> +
> + if (has_emmc()) {
> + puts("Patching FDT so that eMMC is detected by kernel\n");
> + offset = fdt_path_offset(blob,
> "/soc/internal-regs/sdhci@d8000");
Do not use fixed DT paths when parsing Linux kernel DT files. Linux
developers often changes DT node names in their DTS files which cause
changing of DT paths and hence this code in bootloader stops working.
I would suggest to find node offset by compatible string
("marvell,armada-380-sdhci"). Look for inspiration what I done in past:
https://source.denx.de/u-boot/u-boot/-/commit/7cd67018dd7f754c66cf08a76397bbee254b32aa
> + if (offset >= 0) {
> + rc = fdt_delprop(blob, offset, "cd-gpios");
> + if (rc == -FDT_ERR_NOTFOUND)
> + return 0; /* Assume that the device tree is
> already customized for eMMC */
I would suggest to always add "non-removable" property when it does not
exist.
> + if (rc) {
> + printf("Unable to remove cd-gpios for eMMC,
> err=%s\n", fdt_strerror(rc));
> + return rc;
Normally it is not a good idea to return non-zero value from
ft_board_setup() function because it "crashes" u-boot and stops booting
kernel.
> + }
> + rc = fdt_setprop_empty(blob, offset, "non-removable");
> + if (rc) {
> + printf("Unable to add non-removable for eMMC,
> err=%s\n", fdt_strerror(rc));
> + return rc;
> + }
> + }
> + }
> +
> + return 0;
> +}
> diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> index f9cfa94e77..45b093c6d8 100644
> --- a/configs/clearfog_defconfig
> +++ b/configs/clearfog_defconfig
> @@ -21,6 +21,7 @@ CONFIG_SYS_LOAD_ADDR=0x80
> CONFIG_DEBUG_UART=y
> CONFIG_AHCI=y
> CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_OF_BOARD_SETUP=y
Hint: To avoid having CONFIG_OF_BOARD_SETUP=y in every defconfig file,
you can add "select OF_BOARD_SETUP" into "config TARGET_CLEARFOG"
section in arch/arm/mach-mvebu/Kconfig file.
> CONFIG_BOOTDELAY=3
> CONFIG_USE_PREBOOT=y
> CONFIG_SYS_CONSOLE_INFO_QUIET=y
> diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig
> index b11d8746b0..081ebd7e7a 100644
> --- a/configs/clearfog_sata_defconfig
> +++ b/configs/clearfog_sata_defconfig
> @@ -23,6 +23,7 @@ CONFIG_SYS_LOAD_ADDR=0x80
> CONFIG_DEBUG_UART=y
> CONFIG_AHCI=y
> CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_OF_BOARD_SETUP=y
> CONFIG_BOOTDELAY=3
> CONFIG_USE_PREBOOT=y
> CONFIG_SYS_CONSOLE_INFO_QUIET=y
> diff --git a/configs/clearfog_spi_defconfig b/configs/clearfog_spi_defconfig
> index d6695f31e6..6b9e817f68 100644
> --- a/configs/clearfog_spi_defconfig
> +++ b/configs/clearfog_spi_defconfig
> @@ -24,6 +24,7 @@ CONFIG_SYS_LOAD_ADDR=0x80
> CONFIG_DEBUG_UART=y
> CONFIG_AHCI=y
> CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_OF_BOARD_SETUP=y
> CONFIG_BOOTDELAY=3
> CONFIG_USE_PREBOOT=y
> CONFIG_SYS_CONSOLE_INFO_QUIET=y
> --
> 2.39.2
>
Re: [PATCH 3/4] arm: mvebu: clearfog: Add defconfig for SPI booting
On Sunday 05 March 2023 21:30:59 Martin Rowe wrote:
> This new clearfog_spi_defconfig file is a copy of existing
> clearfog_defconfig file modified to instruct build system to generate
> final kwbimage for SPI booting and to store the environment in SPI.
>
> Signed-off-by: Martin Rowe
> ---
> configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (96%)
>
> diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
> similarity index 96%
> copy from configs/clearfog_sata_defconfig
> copy to configs/clearfog_spi_defconfig
> index b11d8746b0..d6695f31e6 100644
> --- a/configs/clearfog_sata_defconfig
> +++ b/configs/clearfog_spi_defconfig
> @@ -10,7 +10,7 @@ CONFIG_NR_DRAM_BANKS=2
> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
> CONFIG_TARGET_CLEARFOG=y
> -CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> +CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> CONFIG_SPL_TEXT_BASE=0x4030
> CONFIG_SPL_MMC=y
> @@ -19,6 +19,7 @@ CONFIG_SPL_STACK=0x4002c000
> CONFIG_SPL=y
> CONFIG_DEBUG_UART_BASE=0xf1012000
> CONFIG_DEBUG_UART_CLOCK=25000
> +CONFIG_SPL_LIBDISK_SUPPORT=y
I think you do not need libdisk support in SPL which loads main u-boot
from SPI.
> CONFIG_SYS_LOAD_ADDR=0x80
> CONFIG_DEBUG_UART=y
> CONFIG_AHCI=y
> @@ -48,6 +49,7 @@ CONFIG_CMD_USB=y
> CONFIG_CMD_TFTPPUT=y
> CONFIG_CMD_CACHE=y
> CONFIG_CMD_TIME=y
> +CONFIG_MVEBU_SATA_BOOT=y
Should not be default bubt location SPI for SPI booting?
> CONFIG_ENV_OVERWRITE=y
> CONFIG_ENV_MIN_ENTRIES=128
> CONFIG_ARP_TIMEOUT=200
> --
> 2.39.2
>
Re: [PATCH 2/4] arm: mvebu: clearfog: Align defconfigs
On Sunday 05 March 2023 21:30:58 Martin Rowe wrote: > Ensure that functionality of generated configs is identical between SATA > and MMC defconfigs for Clearfog boards. The only expected difference is > the boot mode and environment location. > > Signed-off-by: Martin Rowe > --- > configs/clearfog_defconfig | 1 + > configs/clearfog_sata_defconfig | 11 +++ > 2 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig > index 24e7c16ac7..f9cfa94e77 100644 > --- a/configs/clearfog_defconfig > +++ b/configs/clearfog_defconfig > @@ -46,6 +46,7 @@ CONFIG_CMD_USB=y > CONFIG_CMD_TFTPPUT=y > CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > +CONFIG_MVEBU_SATA_BOOT=y MVEBU_*_BOOT is the default target for the bubt command. I guess that you do not want to set default one to SATA for eMMC/SD boot. Anyway, when you are doing cleanup of clearfog defconfig files, what about renaming clearfog_defconfig to clearfog_mmc_defconfig? > CONFIG_ENV_OVERWRITE=y > CONFIG_ENV_MIN_ENTRIES=128 > CONFIG_ARP_TIMEOUT=200 > diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig > index e9b36150ea..b11d8746b0 100644 > --- a/configs/clearfog_sata_defconfig > +++ b/configs/clearfog_sata_defconfig > @@ -3,14 +3,19 @@ CONFIG_ARCH_CPU_INIT=y > CONFIG_SYS_THUMB_BUILD=y > CONFIG_ARCH_MVEBU=y > CONFIG_TEXT_BASE=0x0080 > +CONFIG_SPL_GPIO=y > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > CONFIG_NR_DRAM_BANKS=2 > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > CONFIG_TARGET_CLEARFOG=y > CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" > CONFIG_SPL_TEXT_BASE=0x4030 > +CONFIG_SPL_MMC=y SPL contains code just for loading main u-boot. So I think you do not need MMC support in SPL code (symbols prefixed by CONFIG_SPL) which loads u-boot from SATA. > CONFIG_SPL_SERIAL=y > +CONFIG_SPL_STACK=0x4002c000 > CONFIG_SPL=y > CONFIG_DEBUG_UART_BASE=0xf1012000 > CONFIG_DEBUG_UART_CLOCK=25000 > @@ -18,8 +23,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 > CONFIG_DEBUG_UART=y > CONFIG_AHCI=y > CONFIG_DISTRO_DEFAULTS=y > -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > CONFIG_BOOTDELAY=3 > CONFIG_USE_PREBOOT=y > CONFIG_SYS_CONSOLE_INFO_QUIET=y > @@ -31,7 +34,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 > CONFIG_SPL_BSS_MAX_SIZE=0x4000 > CONFIG_SPL_SYS_MALLOC_SIMPLE=y > # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set > -CONFIG_SPL_STACK=0x4002c000 > CONFIG_SPL_I2C=y > CONFIG_SYS_MAXARGS=32 > CONFIG_CMD_TLV_EEPROM=y > @@ -46,7 +48,6 @@ CONFIG_CMD_USB=y > CONFIG_CMD_TFTPPUT=y > CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > -CONFIG_CMD_MVEBU_BUBT=y > CONFIG_ENV_OVERWRITE=y > CONFIG_ENV_MIN_ENTRIES=128 > CONFIG_ARP_TIMEOUT=200 > @@ -59,6 +60,8 @@ CONFIG_DM_I2C=y > CONFIG_SYS_I2C_MVTWSI=y > CONFIG_I2C_EEPROM=y > CONFIG_SPL_I2C_EEPROM=y > +CONFIG_MMC_BROKEN_CD=y > +CONFIG_SPL_DM_MMC=y > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_MMC_SDHCI=y > CONFIG_MMC_SDHCI_SDMA=y > -- > 2.39.2 >
Re: [PATCH 1/4] arm: mvebu: clearfog: Fix MMC detection
On Sunday 05 March 2023 21:30:57 Martin Rowe wrote:
> A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
> both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.
When you are sending defconfig changes, please do not put there
unrelated canonicalization changes. Canonicalization of defconfigs are
done semi-automatically when Tom regenerates them. So avoid
CONFIG_SUPPORT_EMMC_BOOT and CONFIG_CMD_MVEBU_BUBT changes for eMMC
related change.
Anyway, I have looked at how MMC_BROKEN_CD is working in u-boot. The
relevant part is sdhci_get_cd() function in drivers/mmc/sdhci.c file and
in mmc_of_parse() function in drivers/mmc/mmc-uclass.c file.
So instead of MMC_BROKEN_CD would not it be better the following u-boot
specific patch? cd-gpios is completely ignored by u-boot when
non-removable is set.
diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
index 96629294be4b..e725770c1899 100644
--- a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
+++ b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
@@ -10,6 +10,7 @@
{
u-boot,dm-spl;
+ non-removable; /* assume that the card is always present, required for
eMMC variant */
};
{
> Signed-off-by: Martin Rowe
> ---
> configs/clearfog_defconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> index 8cd35f9f1a..24e7c16ac7 100644
> --- a/configs/clearfog_defconfig
> +++ b/configs/clearfog_defconfig
> @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
> CONFIG_CMD_TFTPPUT=y
> CONFIG_CMD_CACHE=y
> CONFIG_CMD_TIME=y
> -CONFIG_CMD_MVEBU_BUBT=y
> CONFIG_ENV_OVERWRITE=y
> CONFIG_ENV_MIN_ENTRIES=128
> CONFIG_ARP_TIMEOUT=200
> @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y
> CONFIG_SYS_I2C_MVTWSI=y
> CONFIG_I2C_EEPROM=y
> CONFIG_SPL_I2C_EEPROM=y
> -CONFIG_SUPPORT_EMMC_BOOT=y
> +CONFIG_MMC_BROKEN_CD=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_SDMA=y
> CONFIG_MMC_SDHCI_MV=y
> --
> 2.39.2
>
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote: > > > Improve code for checking strapping pins which specifies boot mode source. > > > > Martin, could you test if Clearfog can be still configured into UART > > booting mode via HW switches and if it still works correctly? First > > patch is reverting UART related commit for Clearfog which I think it not > > needed anymore. > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that > you refactored in cpu.c/get_boot_device is all that gets processed. It > decides there is an error and returns BOOT_DEVICE_UART, probably because of > the invalid boot workaround for broken UART selection that you identified. Ok, so I figured out correctly how this invalid mode works. > UART only works if I use the clearfog_spi_defconfig or if I select > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA > defconfigs. I get the same result without this patch series applied, though. > > The failed cases have the same output (other than kwboot header patching > output) until after sending boot image data is complete. The output stops > after: > > 98 % [. > ] > Done > Finishing transfer > [Type Ctrl-\ + c to quit] > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header. If I'm looking at the output correctly then SPL was booted, it correctly trained DDR RAM, returned back to bootrom, kwboot continued sending main u-boot and bootrom confirmed that transfer of both SPL and main u-boot is complete. But then there is no output from main u-boot. > It looks like an unrelated issue with kwboot.c, which I was sure was > working after the last patches but I can no longer reproduce a successful > boot. Can you check that you are using _both_ mkimage and kwboot from version with applying _all_ my patches recently sent to ML? Because both mkimage and kwboot have fixes for SATA and SDIO images. For me it looks like that either mkimage generated incorrect image size for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image. > > > Also could you check if SATA booting is still working correctly? > > > > SATA works correctly. Perfect! > > > Tony, should address problems with SPI booting when it is configured to > > different configuration. In fourth commit I added all possible boot mode > > strapping pin configurations which are recognized by A385 bootrom (and > > not the only one described in the HW spec, which is incomplete). > > > > Stefan, do you have some AXP board with SATA boot source? Because I'm > > adding it for completeness in the last sixth patch. > > > > Pali Rohár (6): > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > arm: mvebu: Convert BOOT_FROM_* constants to function macros > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > arch/arm/mach-mvebu/cpu.c | 20 ++--- > > arch/arm/mach-mvebu/include/mach/soc.h | 41 -- > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > -- > > 2.20.1 > > > >
Re: [PATCH RFC u-boot-mvebu 3/6] arm: mvebu: Convert BOOT_FROM_* constants to function macros
On Sunday 05 March 2023 03:11:20 Martin Rowe wrote:
> On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote:
>
> > This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one
> > macro. And also allows to extend other BOOT_FROM_* macros for other
> > variants.
> >
> > Signed-off-by: Pali Rohár
> > ---
> > arch/arm/mach-mvebu/cpu.c | 16 +---
> > arch/arm/mach-mvebu/include/mach/soc.h | 25 -
> > 2 files changed, 21 insertions(+), 20 deletions(-)
> >
> > diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
> > index daa84c03fcdc..cb3f3afad269 100644
> > --- a/arch/arm/mach-mvebu/cpu.c
> > +++ b/arch/arm/mach-mvebu/cpu.c
> > @@ -98,24 +98,26 @@ u32 get_boot_device(void)
> > val = readl(CONFIG_SAR_REG);/* SAR - Sample At Reset */
> > boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS;
> > debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
> > - switch (boot_device) {
> > #ifdef BOOT_FROM_NAND
> > - case BOOT_FROM_NAND:
> > + if (BOOT_FROM_NAND(boot_device))
> > return BOOT_DEVICE_NAND;
> > #endif
> > #ifdef BOOT_FROM_MMC
> > - case BOOT_FROM_MMC:
> > - case BOOT_FROM_MMC_ALT:
> > + if (BOOT_FROM_MMC(boot_device))
> > return BOOT_DEVICE_MMC1;
> > #endif
> > - case BOOT_FROM_UART:
> > +#ifdef BOOT_FROM_UART
> > + if (BOOT_FROM_UART(boot_device))
> > return BOOT_DEVICE_UART;
> > +#endif
> > #ifdef BOOT_FROM_SATA
> > - case BOOT_FROM_SATA:
> > + if (BOOT_FROM_SATA(boot_device))
> > return BOOT_DEVICE_SATA;
> > #endif
> > - case BOOT_FROM_SPI:
> > +#ifdef BOOT_FROM_SPI
> > + if (BOOT_FROM_SPI(boot_device))
> > return BOOT_DEVICE_SPI;
> > +#endif
> > default:
> > return BOOT_DEVICE_BOOTROM;
> > };
> >
>
> This doesn't compile for me: the switch has only partially been converted
> so I get:
> arch/arm/mach-mvebu/cpu.c: In function 'get_boot_device':
> arch/arm/mach-mvebu/cpu.c:118:9: error: 'default' label not within a switch
> statement
> 118 | default:
> | ^~~
> arch/arm/mach-mvebu/cpu.c: At top level:
> arch/arm/mach-mvebu/cpu.c:121:1: error: expected identifier or '(' before
> '}' token
> 121 | }
> | ^
>
> Maybe remove the default and closing bracket lines and just return
> BOOT_DEVICE_BOOTROM if nothing else worked? That worked for me.
Yea, broken merge on my side which results in the incorrect patch. Fixup
for this patch is:
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index cb3f3afad269..4bff94394d41 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -118,9 +118,7 @@ u32 get_boot_device(void)
if (BOOT_FROM_SPI(boot_device))
return BOOT_DEVICE_SPI;
#endif
- default:
- return BOOT_DEVICE_BOOTROM;
- };
+ return BOOT_DEVICE_BOOTROM;
}
#if defined(CONFIG_DISPLAY_CPUINFO)
> diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
> > b/arch/arm/mach-mvebu/include/mach/soc.h
> > index 5fdce8fe4e7e..aa42db36a1ee 100644
> > --- a/arch/arm/mach-mvebu/include/mach/soc.h
> > +++ b/arch/arm/mach-mvebu/include/mach/soc.h
> > @@ -143,8 +143,8 @@
> > #define BOOT_DEV_SEL_OFFS 3
> > #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
> >
> > -#define BOOT_FROM_UART 0x30
> > -#define BOOT_FROM_SPI 0x38
> > +#define BOOT_FROM_UART(x) (x == 0x30)
> > +#define BOOT_FROM_SPI(x) (x == 0x38)
> >
> > #define CONFIG_SYS_TCLK((readl(CONFIG_SAR_REG) & BIT(20))
> > ? \
> > 2 : 16600)
> > @@ -160,12 +160,11 @@
> > #define BOOT_DEV_SEL_OFFS 4
> > #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
> >
> > -#define BOOT_FROM_NAND 0x0A
> > -#define BOOT_FROM_SATA 0x2A
> > -#define BOOT_FROM_UART 0x28
> > -#define BOOT_FROM_SPI 0x32
> > -#define BOOT_FROM_MMC 0x30
> > -#define BOOT_FROM_MMC_ALT 0x31
> > +#define BOOT_FROM_NAND(x) (x == 0x0A)
> > +#define BOOT_FROM_SATA(x) (x == 0x2A)
> > +#define BOOT_FROM_UART(x) (x == 0x28)
> > +#define BOOT_FROM_SPI(x) (x == 0x32)
> > +#define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31)
> >
> > #define CONFIG_SYS_TCLK((readl(CONFIG_SAR_REG) & BIT(15))
> > ? \
> > 2 : 25000)
> > @@ -182,9 +181,9 @@
> > #define BOOT_DEV_SEL_OFFS 11
> > #define BOOT_DEV_SEL_MASK (0x7 << BOOT_DEV_SEL_OFFS)
> >
> > -#define BOOT_FROM_NAND 0x1
> > -#define BOOT_FROM_UART 0x2
> > -#define BOOT_FROM_SPI 0x3
> > +#define BOOT_FROM_NAND(x) (x == 0x1)
> > +#define BOOT_FROM_UART(x) (x == 0x2)
> > +#define BOOT_FROM_SPI(x) (x == 0x3)
> >
> > #define CONFIG_SYS_TCLK
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Sunday 05 March 2023 02:24:27 Martin Rowe wrote: > On Sat, 4 Mar 2023 at 10:40, Pali Rohár wrote: > > > Boot configuration stored in EXT_CSC register is completely ignored by > > BootROM: > > > > https://lore.kernel.org/u-boot/CAOAjy5SYPPzWKok-BSGYwZwcKOQt_aZPgh6FTbrFd3F=8dm...@mail.gmail.com/ > > > > Reflect this eMMC booting in documentation and in the code. > > > > Martin, can you test this patch series if SPL and main U-Boot is loaded > > from the same eMMC HW partition? > > > > boot0: u-boot > > Works fine, no issues. > > > boot0: zeroed > boot1: u-boot > user: zeroed > > It succeeds, eventually... > == > BootROM - 1.73 > > Booting from MMC > BootROM: Bad header at offset > BootROM: Bad header at offset 0020 > Switching BootPartitions. > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 > +1000) > High speed PHY - Version: 2.0 > EEPROM TLV detection failed: Using static config for Clearfog Pro. > Detected Device ID 6828 > board SerDes lanes topology details: > | Lane # | Speed | Type | > > | 0| 3 | SATA0 | > | 1| 0 | SGMII1 | > | 2| 5 | PCIe1 | > | 3| 5 | USB3 HOST1 | > | 4| 5 | PCIe2 | > | 5| 0 | SGMII2 | > > High speed PHY - Ended Successfully > mv_ddr: 14.0.0 > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > mv_ddr: completed successfully > Trying to boot from MMC1 > ERROR: Invalid kwbimage v1 > mmc_load_image_raw_sector: mmc block read error > spl: mmc: wrong boot mode > Trying to boot from BOOTROM > Returning to BootROM (return address 0x05c4)... > Timeout waiting card ready > BootROM: Image checksum verification PASSED > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 +1000) > > SoC: MV88F6828-A0 at 1600 MHz > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > Core: 38 devices, 22 uclasses, devicetree: separate > MMC: mv_sdh: 0 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment > > Model: SolidRun Clearfog A1 > Board: SolidRun Clearfog Pro > Net: > Warning: ethernet@7 (eth1) using random MAC address - 12:07:8b:f9:7a:6f > eth1: ethernet@7 > Warning: ethernet@3 (eth2) using random MAC address - ee:ed:f3:bb:c2:af > , eth2: ethernet@3 > Warning: ethernet@34000 (eth3) using random MAC address - ae:34:b9:bb:28:c6 > , eth3: ethernet@34000 > Hit any key to stop autoboot: 0 > => > == > > Between "Returning to BootROM" and "Timeout waiting card ready" takes > around 315 seconds. That's long enough that I thought it had hung > completely and I only noticed it continue because I left it running while > working on something else. I tried several things to reduce this timeout, > including reverting to the "non-removable" dts for shdci, but nothing seems > to affect it. Ok. So now it is in the state that it is working but is slow. Better than nothing. Message "Returning to BootROM" is printed by SPL and message "Timeout waiting card ready" is printed by BootROM. After printing "Returning to BootROM" is SPL jumping back to the BootROM so the delay is for sure in the BootROM. So seems that SPL reconfigures eMMC into state in which BootROM cannot work with it. Something timeouts, BootROM reconfigure/retry it and then it work again. It would be needed to investigate what is happening here. My guess is that this could have something with eMMC HW partition access, and code for switching partitions near SPL MMCSD_MODE_EMMCBOOT. Could you try another test by completely erasing BOOT0, BOOT1 and USER data? And see what BootROM prints. > > When bootloader is stored on Boot 0, then SPL should take care of > > loading and executing main U-Boot. When it is stored on Boot 1 or User > > Data then SPL should return back to BootROM and let BootROM to load and > > execute main U-Boot. > > > > Pali Rohár (2): > > tools: kwboot: Fix MMC HW boot partitions info > > arm: mvebu: spl: Load proper U-Boot from eMMC Boot 0 partition > > > > arch/arm/mach-mvebu/Kconfig | 1 + > > arch/arm/mach-mvebu/spl.c | 13 +++-- > > tools/kwboot.c | 6 +++--- > > 3 files changed, 11 insertions(+), 9 deletions(-) > > > > -- > > 2.20.1 > > > >
Re: [PATCH 2/2] net: dhcp6: pxe: Add DHCP/PXE commands for IPv6
> From: Sean Edmond
>
> Adds commands to support DHCP and PXE with IPv6.
>
> New commands added (when IPv6 is enabled):
> - dhcp6
> - pxe get -ipv6
> - pxe boot -ipv6
>
> Signed-off-by: Sean Edmond
> ---
> boot/bootmeth_distro.c | 2 +-
> boot/bootmeth_pxe.c| 4 +-
> boot/pxe_utils.c | 3 +-
> cmd/net.c | 22 +++
> cmd/pxe.c | 86 +---
> --
> cmd/sysboot.c | 2 +-
> include/net.h | 2 +
> include/net6.h | 2 -
> include/pxe_utils.h| 10 -
> 9 files changed, 115 insertions(+), 18 deletions(-)
>
> diff --git a/boot/bootmeth_distro.c b/boot/bootmeth_distro.c
> index 356929828b..b4b73ecbf5 100644
> --- a/boot/bootmeth_distro.c
> +++ b/boot/bootmeth_distro.c
> @@ -150,7 +150,7 @@ static int distro_boot(struct udevice *dev,
> struct bootflow *bflow)
> info.dev = dev;
> info.bflow = bflow;
> ret = pxe_setup_ctx(, , distro_getfile, ,
> true,
> - bflow->subdir);
> + bflow->subdir, false);
> if (ret)
> return log_msg_ret("ctx", -EINVAL);
>
> diff --git a/boot/bootmeth_pxe.c b/boot/bootmeth_pxe.c
> index ecf8557af8..5a8af2bbd0 100644
> --- a/boot/bootmeth_pxe.c
> +++ b/boot/bootmeth_pxe.c
> @@ -70,7 +70,7 @@ static int distro_pxe_read_bootflow(struct udevice
> *dev, struct bootflow *bflow)
> addr = simple_strtoul(addr_str, NULL, 16);
>
> log_debug("calling pxe_get()\n");
> - ret = pxe_get(addr, , );
> + ret = pxe_get(addr, , , false);
> log_debug("pxe_get() returned %d\n", ret);
> if (ret)
> return log_msg_ret("pxeb", ret);
> @@ -146,7 +146,7 @@ static int distro_pxe_boot(struct udevice *dev,
> struct bootflow *bflow)
> info.bflow = bflow;
> info.cmdtp =
> ret = pxe_setup_ctx(ctx, , distro_pxe_getfile, ,
> false,
> - bflow->subdir);
> + bflow->subdir, false);
> if (ret)
> return log_msg_ret("ctx", -EINVAL);
>
> diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
> index 3a1e50f2b1..d13c47dd94 100644
> --- a/boot/pxe_utils.c
> +++ b/boot/pxe_utils.c
> @@ -1578,7 +1578,7 @@ void handle_pxe_menu(struct pxe_context *ctx,
> struct pxe_menu *cfg)
>
> int pxe_setup_ctx(struct pxe_context *ctx, struct cmd_tbl *cmdtp,
> pxe_getfile_func getfile, void *userdata,
> - bool allow_abs_path, const char *bootfile)
> + bool allow_abs_path, const char *bootfile, bool
> use_ipv6)
> {
> const char *last_slash;
> size_t path_len = 0;
> @@ -1588,6 +1588,7 @@ int pxe_setup_ctx(struct pxe_context *ctx,
> struct cmd_tbl *cmdtp,
> ctx->getfile = getfile;
> ctx->userdata = userdata;
> ctx->allow_abs_path = allow_abs_path;
> + ctx->use_ipv6 = use_ipv6;
>
> /* figure out the boot directory, if there is one */
> if (bootfile && strlen(bootfile) >= MAX_TFTP_PATH_LEN)
> diff --git a/cmd/net.c b/cmd/net.c
> index 4227321871..88d53d14d5 100644
> --- a/cmd/net.c
> +++ b/cmd/net.c
> @@ -111,6 +111,28 @@ U_BOOT_CMD(
> );
> #endif
>
> +#if defined(CONFIG_CMD_DHCP6)
> +static int do_dhcp6(struct cmd_tbl *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + int i;
> + int dhcp_argc;
> + char *dhcp_argv[] = {NULL, NULL, NULL, NULL};
> +
> + /* Add -ipv6 flag for autoload */
> + for (i = 0; i < argc; i++)
> + dhcp_argv[i] = argv[i];
> + dhcp_argc = argc + 1;
> + dhcp_argv[dhcp_argc - 1] = USE_IP6_CMD_PARAM;
> +
> + return netboot_common(DHCP6, cmdtp, dhcp_argc, dhcp_argv);
> +}
> +
> +U_BOOT_CMD(dhcp6, 3, 1, do_dhcp6,
> + "boot image via network using DHCPv6/TFTP protocol",
> + "[loadAddress] [[hostIPaddr:]bootfilename]");
> +#endif
> +
> #if defined(CONFIG_CMD_DHCP)
> static int do_dhcp(struct cmd_tbl *cmdtp, int flag, int argc,
>char *const argv[])
> diff --git a/cmd/pxe.c b/cmd/pxe.c
> index db8e4697f2..ebc44fd661 100644
> --- a/cmd/pxe.c
> +++ b/cmd/pxe.c
> @@ -11,6 +11,10 @@
>
> #include "pxe_utils.h"
>
> +#if IS_ENABLED(CONFIG_IPV6)
> +#include
> +#endif
> +
> #ifdef CONFIG_CMD_NET
> const char *pxe_default_paths[] = {
> #ifdef CONFIG_SYS_SOC
> @@ -29,12 +33,20 @@ static int do_get_tftp(struct pxe_context *ctx,
> const char *file_path,
> {
> char *tftp_argv[] = {"tftp", NULL, NULL, NULL};
> int ret;
> + int num_args;
>
> tftp_argv[1] = file_addr;
> tftp_argv[2] = (void *)file_path;
> + if (ctx->use_ipv6) {
> + tftp_argv[3] = USE_IP6_CMD_PARAM;
> + num_args = 4;
> + } else {
> + num_args = 3;
> + }
>
> - if (do_tftpb(ctx->cmdtp, 0, 3, tftp_argv))
> + if (do_tftpb(ctx->cmdtp, 0, num_args,
Re: [PATCH 1/2] net: dhcp6: Add DHCPv6 (DHCP for IPv6)
> From: Sean Edmond
>
> Adds DHCPv6 protocol to u-boot.
>
> Allows for address assignement with DHCPv6 4-message exchange
> (SOLICIT->ADVERTISE->REQUEST->REPLY). Includes DHCPv6 options
> required by RFC 8415. Also adds DHCPv6 options required
> for PXE boot.
>
> New configs added:
> - CMD_DHCP6
> - DHCP6_PXE_CLIENTARCH
> - DHCP6_PXE_DHCP_OPTION
> - DHCP6_ENTERPRISE_ID
>
> Possible enhancements:
> - Duplicate address detection on DHCPv6 assigned address
> - IPv6 address assignement through SLAAC
> - Sending/parsing other DHCPv6 options (NTP, DNS, etc...)
>
> Signed-off-by: Sean Edmond
> ---
> cmd/Kconfig | 26 ++
> include/net.h | 8 +-
> net/Makefile | 1 +
> net/dhcpv6.c | 741
> ++
> net/dhcpv6.h | 212 +++
> net/net.c | 12 +
> 6 files changed, 998 insertions(+), 2 deletions(-)
> create mode 100644 net/dhcpv6.c
> create mode 100644 net/dhcpv6.h
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index dc0446e02e..87813ddbb4 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1645,6 +1645,15 @@ config CMD_DHCP
> help
> Boot image via network using DHCP/TFTP protocol
>
> +config CMD_DHCP6
> + bool "dhcp6"
> + depends on IPV6
> + help
> + Boot image via network using DHCPv6/TFTP protocol using
> IPv6.
> +
> + Will perform 4-message exchange with DHCPv6 server,
> requesting
> + the minimum required options to TFTP boot. Complies with
> RFC 8415.
> +
> config BOOTP_MAY_FAIL
> bool "Allow for the BOOTP/DHCP server to not be found"
> depends on CMD_BOOTP
> @@ -1758,6 +1767,23 @@ config BOOTP_VCI_STRING
> default "U-Boot.arm" if ARM
> default "U-Boot"
>
> +if CMD_DHCP6
> +
> +config DHCP6_PXE_CLIENTARCH
> + hex
> + default 0x16 if ARM64
> + default 0x15 if ARM
> + default 0xFF
> +
> +config DHCP6_PXE_DHCP_OPTION
> + bool "Request & store 'pxe_configfile' from DHCP6 server"
> +
> +config DHCP6_ENTERPRISE_ID
> + int "Enterprise ID to send in DHCPv6 Vendor Class Option"
> + default 0
> +
> +endif
> +
> config CMD_TFTPBOOT
> bool "tftpboot"
> default y
> diff --git a/include/net.h b/include/net.h
> index 399af5e064..cac818e292 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -484,6 +484,10 @@ extern charnet_hostname[32]; /*
> Our hostname */
> #ifdef CONFIG_NET
> extern charnet_root_path[CONFIG_BOOTP_MAX_ROOT_PATH_LEN]; /*
> Our root path */
> #endif
> +#if defined(CONFIG_DHCP6_PXE_DHCP_OPTION)
> +/* Indicates whether the pxe path prefix / config file was specified
> in dhcp option */
> +extern char *pxelinux_configfile;
> +#endif
> /** END OF BOOTP EXTENTIONS **/
> extern u8 net_ethaddr[ARP_HLEN]; /* Our
> ethernet address */
> extern u8 net_server_ethaddr[ARP_HLEN]; /* Boot
> server enet address */
> @@ -504,8 +508,8 @@ extern
> ushort net_native_vlan;/* Our Native VLAN */
> extern int net_restart_wrap; /* Tried all network
> devices */
>
> enum proto_t {
> - BOOTP, RARP, ARP, TFTPGET, DHCP, PING, PING6, DNS, NFS, CDP,
> NETCONS,
> - SNTP, TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, UDP, NCSI,
> WGET
> + BOOTP, RARP, ARP, TFTPGET, DHCP, DHCP6, PING, PING6, DNS,
> NFS, CDP,
> + NETCONS, SNTP, TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL,
> UDP, NCSI, WGET
> };
>
> extern charnet_boot_file_name[1024];/* Boot File name */
> diff --git a/net/Makefile b/net/Makefile
> index bea000b206..5968110170 100644
> --- a/net/Makefile
> +++ b/net/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_IPV6) += net6.o
> obj-$(CONFIG_CMD_NFS) += nfs.o
> obj-$(CONFIG_CMD_PING) += ping.o
> obj-$(CONFIG_CMD_PING6) += ping6.o
> +obj-$(CONFIG_CMD_DHCP6) += dhcpv6.o
> obj-$(CONFIG_CMD_PCAP) += pcap.o
> obj-$(CONFIG_CMD_RARP) += rarp.o
> obj-$(CONFIG_CMD_SNTP) += sntp.o
> diff --git a/net/dhcpv6.c b/net/dhcpv6.c
> new file mode 100644
> index 00..0f0fa291d3
> --- /dev/null
> +++ b/net/dhcpv6.c
> @@ -0,0 +1,741 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) Microsoft Corporation
> + * Author: Sean Edmond
> + *
> + */
> +
> +/* Simple DHCP6 network layer implementation. */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "dhcpv6.h"
> +#include
> +#include
> +#include "net_rand.h"
> +
> +/* Copied from bootp */
> +#ifndef CONFIG_NET_RETRY_COUNT
> +# define TIMEOUT_COUNT 5 /* # of timeouts before giving up */
> +#else
> +# define TIMEOUT_COUNT (CONFIG_NET_RETRY_COUNT)
> +#endif
> +
> +#define PORT_DHCP6_S 547 /* DHCP6 server UDP port */
> +#define PORT_DHCP6_C 546 /* DHCP6 client UDP port */
> +
> +//default timeout parameters (in ms)
> +#define SOL_MAX_DELAY_MS 1000
> +#define SOL_TIMEOUT_MS 1000
>
Re: [PATCH 0/2] net: DHCPv6 protocol and commands
> From: Sean Edmond
>
> The recently integrated IPv6 patch series relies on the link-local
> address,
> or a statically assigned IPv6 address for network operations. This
> patch
> series adds IPv6 address assignment through DHCPv6.
>
> The implementation meets the requirements in RFC 8415 for
> "Client/Server
> Exchanges Involving Four Messages":
> https://www.rfc-editor.org/rfc/rfc8415
>
> The implementation sends/receives the minimum required DHCPv6 options
> to
> network boot.
>
> A new command (dhcp6) will execute the protocol. In addition, IPv6
> functionality has been extended to the existing pxe commands ("pxe
> get"
> and "pxe boot").
>
> Sean Edmond (2):
> net: dhcp6: Add DHCPv6 (DHCP for IPv6)
> net: dhcp6: pxe: Add DHCP/PXE commands for IPv6
>
> boot/bootmeth_distro.c | 2 +-
> boot/bootmeth_pxe.c| 4 +-
> boot/pxe_utils.c | 3 +-
> cmd/Kconfig| 26 ++
> cmd/net.c | 22 ++
> cmd/pxe.c | 86 -
> cmd/sysboot.c | 2 +-
> include/net.h | 10 +-
> include/net6.h | 2 -
> include/pxe_utils.h| 10 +-
> net/Makefile | 1 +
> net/dhcpv6.c | 741
> +
> net/dhcpv6.h | 212
> net/net.c | 12 +
> 14 files changed, 1113 insertions(+), 20 deletions(-)
> create mode 100644 net/dhcpv6.c
> create mode 100644 net/dhcpv6.h
>
> --
> 2.39.0
>
>
Hello! Very sorry for the long response!
I checked your patches and in general it looks good. Anyway I have made
some notes. It is up to you and maintainers to improve the code or not.
Moreover I've briefly tested it and it works.
=> dhcp6
: PHY present at 0
: Starting autonegotiation...
: Autonegotiation complete
: link up, 100Mbps full-duplex (lpa: 0x41e1)
DHCP6 SOLICIT 0
DHCP6 REQUEST 0
DHCP6 client bound to fe80::::42f2:e9ff:fe6d:beef
Notes:
1. Some comments have //-style. Better to use /**/
//global variable to track any updates from DHCP6 server
2. If you apply only the first patch you can add to config CMD_DHCP6
but when you run u-boot it won't be available. Looks like sth
incomplete. I think it would be much better to enable CMD_DHCP6 in the
second patch when you add do_dhcp6().
3. struct dhcp6_sm_params has invalid description. You copy-passed it
from the previous func.
4. Add CMD_DHCP6 to sandbox_*_defconfig
5. if CONFIG_DHCP6_PXE_DHCP_OPTION is not configured then you will get
"cmd/pxe.c:172:1: warning: label ‘error_exit’ defined but not used"
during a build
6. How to determine IPv6 address in dhcp6 command
=> help dhcp6
dhcp6 [loadAddress] [[hostIPaddr:]bootfilename]
In tftpboot []-notation is used to specify IPv6
7. net_set_timeout_handler(); has prototype void
net_set_timeout_handler(ulong iv, thand_f *f). Maybe it is better to
use net_set_timeout_handler(0, NULL); than net_set_timeout_handler(0,
0);
8. You moved #define USE_IP6_CMD_PARAM "-ipv6" from include/net6.h
to include/net.h
I think it is better to leave IPv6 defines in net6 header.
Thanks!
[PATCH 4/4] arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
[upstream of vendor commit 19a96f7c40a8fc1d0a6546ac2418d966e5840a99]
The Clearfog devices have only one SDHC device. This is either eMMC if
it is populated on the SOM or SDHC if not. The Linux device tree assumes
the SDHC case. Detect if the device is an eMMC and fixup the device-tree
so it will be detected by Linux.
Ported from vendor repo at https://github.com/SolidRun/u-boot
Signed-off-by: Martin Rowe
---
board/solidrun/clearfog/clearfog.c | 42 ++
configs/clearfog_defconfig | 1 +
configs/clearfog_sata_defconfig| 1 +
configs/clearfog_spi_defconfig | 1 +
4 files changed, 45 insertions(+)
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index 03adb591d8..cafead3a1a 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -261,3 +262,44 @@ int board_late_init(void)
return 0;
}
+
+static bool has_emmc(void)
+{
+ struct mmc *mmc;
+ mmc = find_mmc_device(0);
+ if (!mmc)
+ return 0;
+ return (!mmc_init(mmc) && IS_MMC(mmc)) ? true : false;
+}
+
+/*
+ * The Clearfog devices have only one SDHC device. This is either eMMC
+ * if it is populated on the SOM or SDHC if not. The Linux device tree
+ * assumes the SDHC case. Detect if the device is an eMMC and fixup the
+ * device-tree so it will be detected by Linux.
+ */
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ __maybe_unused int offset, rc;
+
+ if (has_emmc()) {
+ puts("Patching FDT so that eMMC is detected by kernel\n");
+ offset = fdt_path_offset(blob,
"/soc/internal-regs/sdhci@d8000");
+ if (offset >= 0) {
+ rc = fdt_delprop(blob, offset, "cd-gpios");
+ if (rc == -FDT_ERR_NOTFOUND)
+ return 0; /* Assume that the device tree is
already customized for eMMC */
+ if (rc) {
+ printf("Unable to remove cd-gpios for eMMC,
err=%s\n", fdt_strerror(rc));
+ return rc;
+ }
+ rc = fdt_setprop_empty(blob, offset, "non-removable");
+ if (rc) {
+ printf("Unable to add non-removable for eMMC,
err=%s\n", fdt_strerror(rc));
+ return rc;
+ }
+ }
+ }
+
+ return 0;
+}
diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index f9cfa94e77..45b093c6d8 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -21,6 +21,7 @@ CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
CONFIG_DISTRO_DEFAULTS=y
+CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTDELAY=3
CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig
index b11d8746b0..081ebd7e7a 100644
--- a/configs/clearfog_sata_defconfig
+++ b/configs/clearfog_sata_defconfig
@@ -23,6 +23,7 @@ CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
CONFIG_DISTRO_DEFAULTS=y
+CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTDELAY=3
CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
diff --git a/configs/clearfog_spi_defconfig b/configs/clearfog_spi_defconfig
index d6695f31e6..6b9e817f68 100644
--- a/configs/clearfog_spi_defconfig
+++ b/configs/clearfog_spi_defconfig
@@ -24,6 +24,7 @@ CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
CONFIG_DISTRO_DEFAULTS=y
+CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTDELAY=3
CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
--
2.39.2
[PATCH 3/4] arm: mvebu: clearfog: Add defconfig for SPI booting
This new clearfog_spi_defconfig file is a copy of existing
clearfog_defconfig file modified to instruct build system to generate
final kwbimage for SPI booting and to store the environment in SPI.
Signed-off-by: Martin Rowe
---
configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (96%)
diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
similarity index 96%
copy from configs/clearfog_sata_defconfig
copy to configs/clearfog_spi_defconfig
index b11d8746b0..d6695f31e6 100644
--- a/configs/clearfog_sata_defconfig
+++ b/configs/clearfog_spi_defconfig
@@ -10,7 +10,7 @@ CONFIG_NR_DRAM_BANKS=2
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
CONFIG_TARGET_CLEARFOG=y
-CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
+CONFIG_ENV_SECT_SIZE=0x1
CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
CONFIG_SPL_TEXT_BASE=0x4030
CONFIG_SPL_MMC=y
@@ -19,6 +19,7 @@ CONFIG_SPL_STACK=0x4002c000
CONFIG_SPL=y
CONFIG_DEBUG_UART_BASE=0xf1012000
CONFIG_DEBUG_UART_CLOCK=25000
+CONFIG_SPL_LIBDISK_SUPPORT=y
CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
@@ -48,6 +49,7 @@ CONFIG_CMD_USB=y
CONFIG_CMD_TFTPPUT=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_TIME=y
+CONFIG_MVEBU_SATA_BOOT=y
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_MIN_ENTRIES=128
CONFIG_ARP_TIMEOUT=200
--
2.39.2
[PATCH 2/4] arm: mvebu: clearfog: Align defconfigs
Ensure that functionality of generated configs is identical between SATA and MMC defconfigs for Clearfog boards. The only expected difference is the boot mode and environment location. Signed-off-by: Martin Rowe --- configs/clearfog_defconfig | 1 + configs/clearfog_sata_defconfig | 11 +++ 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 24e7c16ac7..f9cfa94e77 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -46,6 +46,7 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y +CONFIG_MVEBU_SATA_BOOT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig index e9b36150ea..b11d8746b0 100644 --- a/configs/clearfog_sata_defconfig +++ b/configs/clearfog_sata_defconfig @@ -3,14 +3,19 @@ CONFIG_ARCH_CPU_INIT=y CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_MVEBU=y CONFIG_TEXT_BASE=0x0080 +CONFIG_SPL_GPIO=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_TARGET_CLEARFOG=y CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" CONFIG_SPL_TEXT_BASE=0x4030 +CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xf1012000 CONFIG_DEBUG_UART_CLOCK=25000 @@ -18,8 +23,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_DEBUG_UART=y CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y @@ -31,7 +34,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 CONFIG_SPL_BSS_MAX_SIZE=0x4000 CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL_I2C=y CONFIG_SYS_MAXARGS=32 CONFIG_CMD_TLV_EEPROM=y @@ -46,7 +48,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,6 +60,8 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y +CONFIG_MMC_BROKEN_CD=y +CONFIG_SPL_DM_MMC=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y -- 2.39.2
[PATCH 1/4] arm: mvebu: clearfog: Fix MMC detection
A388 Clearfog MMC is either SD Card or eMMC with different behaviour for both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. Signed-off-by: Martin Rowe --- configs/clearfog_defconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 8cd35f9f1a..24e7c16ac7 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y -CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_BROKEN_CD=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_MV=y -- 2.39.2
[PATCH 0/4] arm: mvebu: clearfog: defconfig and eMMC updates
Minor defconfig and eMMC updates for SolidRun's A388 Clearfog devices.
Changes since initial discussion:
https://lists.denx.de/pipermail/u-boot/2023-February/510492.html
- CONFIG_SPL_SPI selected for SPI defconfig
- Runtime patching of kernel FDT added for eMMC detection
Note that this patch depends on this patch series (has been merged to
u-boot-marvell/next):
https://lists.denx.de/pipermail/u-boot/2023-March/511038.html
Signed-off-by: Martin Rowe
Martin Rowe (4):
arm: mvebu: clearfog: Fix MMC detection
arm: mvebu: clearfog: Align defconfigs
arm: mvebu: clearfog: Add defconfig for SPI booting
arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
board/solidrun/clearfog/clearfog.c| 42 +++
configs/clearfog_defconfig| 5 ++-
configs/clearfog_sata_defconfig | 12 --
...arfog_defconfig => clearfog_spi_defconfig} | 10 -
4 files changed, 61 insertions(+), 8 deletions(-)
copy configs/{clearfog_defconfig => clearfog_spi_defconfig} (91%)
--
2.39.2
