Re: [PATCH v4 10/17] board: starfive: add StarFive VisionFive v2 board support
Hi YanHong, There are some errors when "make htmldocs". I thought v4 was the final patch set and these are minor build errors, so I have fixed them up on my side. Now that since you are adding new defconfig and spinning a v5 patch set, could you also fix those build errors that came from "make htmldocs" as well? There mostly "Title underline too short." in "doc/board/starfive/visionfive2.rst" and an entry of "starfive/index" should be added in "doc/board/index.rst" in alphabetical order. CI results: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/597253#L183 Best regards, Leo On Thu, Mar 16, 2023 at 10:53:25AM +0800, Yanhong Wang wrote: > Add board support for StarFive VisionFive v2. > > Signed-off-by: Yanhong Wang > Tested-by: Conor Dooley > --- > board/starfive/visionfive2/MAINTAINERS| 7 + > board/starfive/visionfive2/Makefile | 7 + > board/starfive/visionfive2/spl.c | 87 > .../visionfive2/starfive_visionfive2.c| 40 ++ > doc/board/starfive/index.rst | 9 + > doc/board/starfive/visionfive2.rst| 492 ++ > include/configs/starfive-visionfive2.h| 49 ++ > 7 files changed, 691 insertions(+) > create mode 100644 board/starfive/visionfive2/MAINTAINERS > create mode 100644 board/starfive/visionfive2/Makefile > create mode 100644 board/starfive/visionfive2/spl.c > create mode 100644 board/starfive/visionfive2/starfive_visionfive2.c > create mode 100644 doc/board/starfive/index.rst > create mode 100644 doc/board/starfive/visionfive2.rst > create mode 100644 include/configs/starfive-visionfive2.h > > diff --git a/doc/board/starfive/index.rst b/doc/board/starfive/index.rst > new file mode 100644 > index 00..420433ea30 > --- /dev/null > +++ b/doc/board/starfive/index.rst > @@ -0,0 +1,9 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +StarFive > +== Title underline too short. > + > +.. toctree:: > + :maxdepth: 1 > + > + visionfive2 > diff --git a/doc/board/starfive/visionfive2.rst > b/doc/board/starfive/visionfive2.rst > new file mode 100644 > index 00..155358d29e > --- /dev/null > +++ b/doc/board/starfive/visionfive2.rst > @@ -0,0 +1,492 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +StarFive VisionFive2 > + Ditto. > + > +JH7110 RISC-V SoC > +- > +The JH7110 is 4+1 64-bit RISC-V SoC from StarFive. > + > +The StarFive VisionFive2 development platform is based on JH7110 and capable > +of running Linux. > + > +Mainline support > + > + > +The support for following drivers are already enabled: > + > +1. ns16550 UART Driver. > +2. StarFive JH7110 clock Driver. > +3. StarFive JH7110 reset Driver. > +4. Cadence QSPI controller Driver. > +5. MMC SPI Driver for MMC/SD support. > + > +Booting from MMC using U-Boot SPL > +--- > + Ditto. > +The current U-Boot port is supported in S-mode only and loaded from DRAM. > + > +A prior stage M-mode firmware/bootloader (e.g OpenSBI) is required to > +boot the u-boot.itb in S-mode and provide M-mode runtime services. > + > +Currently, the u-boot.itb is used as a dynamic of the OpenSBI FW_DYNAMIC > +firmware with the latest. > + > +Building > + > + > +1. Add the RISC-V toolchain to your PATH. > +2. Setup ARCH & cross compilation environment variable: > + > +.. code-block:: none > + > + export CROSS_COMPILE= > + > +Before building U-Boot SPL, OpenSBI must be built first. OpenSBI can be > +cloned and built for JH7110 as below: > + > +.. code-block:: console > + > + git clone https://github.com/riscv/opensbi.git > + cd opensbi > + make PLATFORM=generic FW_TEXT_START=0x4000 FW_OPTIONS=0 > + > +More detailed description of steps required to build FW_DYNAMIC firmware > +is beyond the scope of this document. Please refer OpenSBI documenation. > +(Note: OpenSBI git repo is at https://github.com/riscv/opensbi.git) > + > +Now build the U-Boot SPL and U-Boot proper > + > +.. code-block:: console > + > + cd > + make starfive_visionfive2_defconfig > + make > OPENSBI=$(opensbi_dir)/opensbi/build/platform/generic/firmware/fw_dynamic.bin > + > +This will generate spl/u-boot-spl.bin and FIT image (u-boot.itb) > + > +u-boot-spl.bin cannot be used directly on StarFive VisionFive2,we need > +to convert the u-boot-spl.bin to u-boot-spl.bin.normal.out with > +the below command: > + > + ./spl_tool -c -f $(Uboot_PATH)/spl/u-boot-spl.bin > + > +More detailed description of spl_tool,please refer spl_tool documenation. > +(Note: spl_tool git repo is at > https://github.com/starfive-tech/Tools/tree/master/spl_tool) > + > +This will generate u-boot-spl.bin.normal.out file. > + > +Flashing > + > + > +SPL loads the U-Boot SPL (u-boot-spl.bin.normal.out) from a partition with > GUID type > +2E54B353-1271-4842-806F-E436D6AF6985 > + > +U-Boot SPL expects a U-Boot FIT image (u-boot.itb) from a partition with GUID > +type
Re: [PATCH v4 16/17] riscv: dts: jh7110: Add initial StarFive VisionFive v2 board device tree
On 2023/3/21 5:25, Conor Dooley wrote: > On Thu, Mar 16, 2023 at 10:53:31AM +0800, Yanhong Wang wrote: >> Add initial device tree for StarFive VisionFive v2 board. >> >> Signed-off-by: Yanhong Wang >> Tested-by: Conor Dooley > > btw, are you running some sort of cc suppression argument to > send-email? There's not much reason to do so for submissions to a public > ML, and it would be nice to get subsequent revisions of a patchset that > I have given a tested-by for in my inbox. > Yes, the --suppress-cc=all parameter was added to the send-email. Do you suggest canceling this parameter? > Curious, > Conor.
Re: [PATCH v4 17/17] configs: starfive: add starfive_visionfive2_defconfig
On 2023/3/21 21:51, Andreas Schwab wrote: > On Mär 21 2023, yanhong wang wrote: > >> Except for CONFIG_DEFAULT_DEVICE_TREE and CONFIG_DEFAULT_FDT_FILE, >> 1.2a and 1.3b versions use the same config. >> >> Version 1.3b uses the following configuration: >> CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.3b" >> CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.3b.dtb" >> >> Version 1.2a uses the following configuration: >> CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.2a" >> CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.2a.dtb" >> >> Is it necessary to separate the configs for 1.2a and 1.3b as separate >> defconfig files? > > It makes a difference for when ethernet support is added. > The difference between 1.2a and 1.3b versions is mainly in ethernet, so the definition of dts is separated. Defconfig file in addition to the differences mentioned above, the others are the same. Your suggestion is to define defconfig file separately, is that right? If so, I will define the defconfig files of 1.2a and 1.3b independently in the next version.
Re: [PATCH 1/3] net: mvpp2: Replace PHY_INTERFACE_MODE_SGMII_2500 with SGMII and speed
On 3/19/23 20:45, Marek Behún wrote: On Sun, 19 Mar 2023 18:06:45 +0100 Marek Vasut wrote: Replace PHY_INTERFACE_MODE_SGMII_2500 with PHY_INTERFACE_MODE_SGMII and phydev->speed check where applicable. The PHY_INTERFACE_MODE_SGMII_2500 does not exist in Linux, so remove it from U-Boot too. Signed-off-by: Marek Vasut SGMII cannot operate on 2500mbps. As I explained to the author who added PHY_INTERFACE_MODE_SGMII_2500 to U-Boot (and the conversation didn't lead anywhere then), what I think happened here is that for some reason Marvell sometimes calls 2500base-x mode SGMII_2500. Meaning that they incorrectly interchange the names 2500base-x and sgmii_2500 as if they were the same thing. This is probably due to how 1000base-x and SGMII are similar and they do the same with those. The thing is, 1000base-x and SGMII are different protocols / interface modes. The difference is that they have different autonegotiation. SGMII allows also for speed autonegotiation, whilst 1000base-x only for flow control. The bits in the clause 37 link ability advertisement word have different meaning for 1000base-x than for sgmii. When SGMII negotiates lower speed, the actual serdes frequency does not change. The lower speed of 100mbps or 10mbps is achieved by repeating the word 10 or 100 times. The 2500base-x mode works the same way as 1000base-x mode, but at 2.5x the frequency. Calling it sgmii-2500 is wrong because it would mean that it also allows for lower speeds by repeating the words. In reality it is possible, on many controllers you can set SGMII mode at 2.5x normal frequency and then instead of 1000/100/10mbps speeds achieve 2500/250/25mbps. But this is not standardized anyway. Marek, your patch does a good thing getting rid of the sgmii-2500 constant, but you are still leaving the possibility of 2500mbps speed in SGMII mode... Thanks for the detailed explanation, I sent a V2 where I remove the SGMII 2500 . I hope I got the differences right in the V2 commit message.
Re: [PATCH 1/2] Dockerfile: Add m68k-softmmu to qemu
On 3/21/23 20:31, Tom Rini wrote: Given efforts to add an m68k target to CI, build qemu for it. Signed-off-by: Tom Rini --- Cc: Marek Vasut Reviewed-by: Marek Vasut +CC Angelo too.
Re: [PATCH v3 3/4] efi_loader: check lowest supported version in capsule update
On Tue, 21 Mar 2023 at 15:42, Heinrich Schuchardt wrote:
>
> On 3/20/23 06:54, Masahisa Kojima wrote:
> > The FMP Payload Header which EDK2 capsule generation scripts
> > insert contains lowest supported version.
> > This commit reads the lowest supported version stored in the
> > "FmpState" EFI non-volatile variable, then check if the
> > firmware version of ongoing capsule is equal or greater than
> > the lowest supported version.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > No changes since v2
> >
> > Changes in v2:
> > - add error message when the firmware version is lower than
> >lowest supported version
> >
> > lib/efi_loader/efi_firmware.c | 50 ++-
> > 1 file changed, 49 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
> > index 289456ecbb..8d6e32006d 100644
> > --- a/lib/efi_loader/efi_firmware.c
> > +++ b/lib/efi_loader/efi_firmware.c
> > @@ -391,6 +391,39 @@ void efi_firmware_parse_payload_header(const void
> > **p_image,
> > *p_image_size = image_size;
> > }
> >
> > +/**
> > + * efi_firmware_get_lowest_supported_version - get the lowest supported
> > version
> > + * @image_index: image_index
> > + *
> > + * Get the lowest supported version from FmpState variable.
> > + *
> > + * Return: lowest supported version, return 0 if reading
> > FmpState
> > + * variable failed
> > + */
> > +static
> > +u32 efi_firmware_get_lowest_supported_version(u8 image_index)
> > +{
> > + u16 varname[13]; /* u"FmpState" */
> > + efi_status_t ret;
> > + efi_uintn_t size;
> > + efi_guid_t *image_type_id;
> > + struct fmp_state var_state = { 0 };
> > +
> > + image_type_id = efi_firmware_get_image_type_id(image_index);
> > + if (!image_type_id)
> > + return 0;
> > +
> > + efi_create_indexed_name(varname, sizeof(varname), "FmpState",
> > + image_index);
> > + size = sizeof(var_state);
> > + ret = efi_get_variable_int(varname, image_type_id, NULL, ,
> > +_state, NULL);
> > + if (ret != EFI_SUCCESS)
> > + return 0;
> > +
> > + return var_state.lowest_supported_version;
> > +}
> > +
> > /**
> >* efi_firmware_verify_image - verify image
> >* @p_image:Pointer to new image
> > @@ -398,7 +431,8 @@ void efi_firmware_parse_payload_header(const void
> > **p_image,
> >* @image_index Image index
> >* @state Pointer to fmp state
> >*
> > - * Verify the capsule file
> > + * Verify the capsule authentication and check if the fw_version
> > + * is equal or greater than the lowest supported version.
> >*
> >* Return: status code
> >*/
> > @@ -409,10 +443,24 @@ efi_status_t efi_firmware_verify_image(const void
> > **p_image,
> > struct fmp_state *state)
> > {
> > efi_status_t ret;
> > + u32 lowest_supported_version;
> >
> > ret = efi_firmware_capsule_authenticate(p_image, p_image_size, state);
> > efi_firmware_parse_payload_header(p_image, p_image_size, state);
> >
> > + /* check lowest_supported_version if capsule authentication passes */
> > + if (ret == EFI_SUCCESS) {
> > + lowest_supported_version =
> > +
> > efi_firmware_get_lowest_supported_version(image_index);
> > + if (lowest_supported_version > state->fw_version) {
> > + printf("fw_version(%u) is too low(expected >%u).
> > Aborting update\n",
> > +state->fw_version, lowest_supported_version);
>
> Please, use log_warning() or log_err() instead of printf().
>
> The addressee is a user not a developer:
>
> "Firmware version %u too low. Expecting >= %u"
OK.
>
> We should have one central place where upon exit we write a message
> indicating that either the capsule update was successful or failed.
>
> "Firmware updated to version %u" : "Firmware update failed"
Yes, I will add the log output for the user.
Thanks,
Masahisa Kojima
>
> Best regards
>
> Heinrich
>
> > + state->last_attempt_status =
> > + LAST_ATTEMPT_STATUS_ERROR_INCORRECT_VERSION;
> > + ret = EFI_INVALID_PARAMETER;
> > + }
> > + }
> > +
> > return ret;
> > }
> >
>
Re: [PATCH v3 1/4] efi_loader: store firmware version into FmpState variable
On Tue, 21 Mar 2023 at 15:30, Heinrich Schuchardt wrote:
>
> On 3/20/23 06:54, Masahisa Kojima wrote:
> > Firmware version management is not implemented in the current
> > FMP protocol.
> > EDK2 reference implementation capsule generation script inserts
> > the FMP Payload Header right before the payload, it contains the
> > firmware version and lowest supported version.
> >
> > This commit utilizes the FMP Payload Header, read the header and
>
> %s/read/reads/
OK.
>
> > stores the firmware version, lowest supported version,
> > last attempt version and last attempt status into "FmpState"
> > EFI non-volatile variable. indicates the image index,
> > since FMP protocol handles multiple image indexes.
> >
> > This change is compatible with the existing FMP implementation.
> > This change does not mandate the FMP Payload Header.
> > If no FMP Payload Header is found in the capsule file, fw_version,
> > lowest supported version, last attempt version and last attempt
> > status is 0 and this is the same behavior as existing FMP
> > implementation.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > Changes in v3:
> > - exclude CONFIG_FWU_MULTI_BANK_UPDATE case
> > - set image_type_id as a vendor field of FmpState variable
> > - set READ_ONLY flag for FmpState variable
> > - add error code for FIT image case
> >
> > Changes in v2:
> > - modify indent
> >
> > lib/efi_loader/efi_firmware.c | 224 ++
> > 1 file changed, 201 insertions(+), 23 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
> > index 93e2b01c07..d6f3741024 100644
> > --- a/lib/efi_loader/efi_firmware.c
> > +++ b/lib/efi_loader/efi_firmware.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -36,6 +37,24 @@ struct fmp_payload_header {
> > u32 lowest_supported_version;
> > };
> >
> > +/**
> > + * struct fmp_state - fmp firmware update state
> > + *
> > + * This structure describes the state of the firmware update
> > + * through FMP protocol.
> > + *
> > + * @fw_version: Firmware versions used
> > + * @lowest_supported_version:Lowest supported version
> > + * @last_attempt_version:Last attempt version
> > + * @last_attempt_status: Last attempt status
> > + */
> > +struct fmp_state {
> > + u32 fw_version;
> > + u32 lowest_supported_version;
> > + u32 last_attempt_version;
> > + u32 last_attempt_status;
> > +};
> > +
> > __weak void set_dfu_alt_info(char *interface, char *devstr)
> > {
> > env_set("dfu_alt_info", update_info.dfu_string);
> > @@ -102,6 +121,29 @@ efi_status_t EFIAPI
> > efi_firmware_set_package_info_unsupported(
> > return EFI_EXIT(EFI_UNSUPPORTED);
> > }
> >
> > +/**
> > + * efi_firmware_get_image_type_id - get image_type_id
> > + * @image_index: image index
> > + *
> > + * Return the image_type_id identified by the image index.
> > + *
> > + * Return: pointer to the image_type_id, NULL if image_index is
> > invalid
> > + */
> > +static
> > +efi_guid_t *efi_firmware_get_image_type_id(u8 image_index)
> > +{
> > + int i;
> > + struct efi_fw_image *fw_array;
> > +
> > + fw_array = update_info.images;
> > + for (i = 0; i < num_image_type_guids; i++) {
> > + if (fw_array[i].image_index == image_index)
> > + return _array[i].image_type_id;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > /**
> >* efi_fill_image_desc_array - populate image descriptor array
> >* @image_info_size:Size of @image_info
> > @@ -182,6 +224,7 @@ static efi_status_t efi_fill_image_desc_array(
> >* efi_firmware_capsule_authenticate - authenticate the capsule if enabled
> >* @p_image:Pointer to new image
> >* @p_image_size: Pointer to size of new image
> > + * @statePointer to fmp state
> >*
> >* Authenticate the capsule if authentication is enabled.
> >* The image pointer and the image size are updated in case of success.
> > @@ -190,12 +233,11 @@ static efi_status_t efi_fill_image_desc_array(
> >*/
> > static
> > efi_status_t efi_firmware_capsule_authenticate(const void **p_image,
> > -efi_uintn_t *p_image_size)
> > +efi_uintn_t *p_image_size,
> > +struct fmp_state *state)
> > {
> > const void *image = *p_image;
> > efi_uintn_t image_size = *p_image_size;
> > - u32 fmp_hdr_signature;
> > - struct fmp_payload_header *header;
> > void *capsule_payload;
> > efi_status_t status;
> > efi_uintn_t capsule_payload_size;
> > @@ -209,8 +251,12 @@ efi_status_t efi_firmware_capsule_authenticate(const
> > void **p_image,
> >
> > if (status == EFI_SECURITY_VIOLATION) {
> >
[PATCH v2 3/4] rockchip: rk35xx: Fix boot with a large fdt blob
The TF-A blobs used to boot RK3568 and RK3588 boards is based on atf
v2.3. Mainline atf v2.3 contains an issue that could lead to a crash
when it fails to parse the fdt blob being passed as the platform param.
An issue that was fixed in atf v2.4.
The vendor TF-A seem to suffer from a similar issue, and this prevents
booting when fdt blob is large enough to trigger this condition.
Fix this by implying SPL_ATF_NO_PLATFORM_PARAM to let u-boot pass a
NULL pointer instead of the fdt blob as the platform param.
This fixes booting Radxa ROCK 3A after recent sync of device tree.
Fixes: 073d911ae64a ("rockchip: rk3568-rock-3a: Sync device tree from linux")
Signed-off-by: Jonas Karlman
---
v2:
- New patch
arch/arm/mach-rockchip/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index e5ac58ae60b5..d7e3784ba113 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -288,6 +288,7 @@ config ROCKCHIP_RK3568
select BOARD_LATE_INIT
select DM_REGULATOR_FIXED
select DM_RESET
+ imply SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
imply ROCKCHIP_COMMON_BOARD
imply ROCKCHIP_OTP
imply MISC_INIT_R
@@ -309,6 +310,7 @@ config ROCKCHIP_RK3588
select REGMAP
select SYSCON
select BOARD_LATE_INIT
+ imply SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
imply ROCKCHIP_COMMON_BOARD
imply ROCKCHIP_OTP
imply MISC_INIT_R
--
2.40.0
[PATCH v2 4/4] rockchip: rk35xx: Enable fdtoverlay and kernel compression
Add fdtoverlay_addr_r, kernel_comp_addr_r and imply use of OF_LIBFDT_OVERLAY on RK3568 and RK3588 to support fdtoverlay and kernel compression. Signed-off-by: Jonas Karlman Reviewed-by: Simon Glass --- v2: - Drop parts that convert to use bootstd - Collect r-b tag arch/arm/mach-rockchip/Kconfig | 2 ++ include/configs/rk3568_common.h | 7 ++- include/configs/rk3588_common.h | 7 ++- 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index d7e3784ba113..517326c8c5be 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -290,6 +290,7 @@ config ROCKCHIP_RK3568 select DM_RESET imply SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF imply ROCKCHIP_COMMON_BOARD + imply OF_LIBFDT_OVERLAY imply ROCKCHIP_OTP imply MISC_INIT_R help @@ -312,6 +313,7 @@ config ROCKCHIP_RK3588 select BOARD_LATE_INIT imply SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF imply ROCKCHIP_COMMON_BOARD + imply OF_LIBFDT_OVERLAY imply ROCKCHIP_OTP imply MISC_INIT_R help diff --git a/include/configs/rk3568_common.h b/include/configs/rk3568_common.h index a5e1dde50888..d6b5e7d89022 100644 --- a/include/configs/rk3568_common.h +++ b/include/configs/rk3568_common.h @@ -17,10 +17,15 @@ #define ENV_MEM_LAYOUT_SETTINGS\ "scriptaddr=0x00c0\0" \ + "script_offset_f=0xffe000\0"\ + "script_size_f=0x2000\0"\ "pxefile_addr_r=0x00e0\0" \ "fdt_addr_r=0x0a10\0" \ + "fdtoverlay_addr_r=0x0200\0"\ "kernel_addr_r=0x0208\0"\ - "ramdisk_addr_r=0x0a20\0" + "ramdisk_addr_r=0x0a20\0" \ + "kernel_comp_addr_r=0x0800\0" \ + "kernel_comp_size=0x200\0" #include #define CFG_EXTRA_ENV_SETTINGS \ diff --git a/include/configs/rk3588_common.h b/include/configs/rk3588_common.h index abd20139aaf3..b9f42717b751 100644 --- a/include/configs/rk3588_common.h +++ b/include/configs/rk3588_common.h @@ -16,10 +16,15 @@ #define ENV_MEM_LAYOUT_SETTINGS\ "scriptaddr=0x00c0\0" \ + "script_offset_f=0xffe000\0"\ + "script_size_f=0x2000\0"\ "pxefile_addr_r=0x00e0\0" \ "fdt_addr_r=0x0a10\0" \ + "fdtoverlay_addr_r=0x0200\0"\ "kernel_addr_r=0x0208\0"\ - "ramdisk_addr_r=0x0a20\0" + "ramdisk_addr_r=0x0a20\0" \ + "kernel_comp_addr_r=0x0800\0" \ + "kernel_comp_size=0x200\0" #include #define CFG_EXTRA_ENV_SETTINGS \ -- 2.40.0
[PATCH v2 2/4] rockchip: rk3588-rock-5b: Fix sdmmc boot
Running U-Boot from a SD-card on ROCK 5 Model B fails to load atf using
DMA and prints debug_uart messages.
U-Boot SPL 2023.04-rc3 (Mar 12 2023 - 00:30:16 +)
Trying to boot from MMC1
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256 error!
Bad hash value for 'hash' hash node in 'atf-1' image node
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
Use fifo-mode to disable DMA in SPL, add same-as-spl to boot-order and
remove DEBUG_UART_ANNOUNCE option to fix this.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
---
v2:
- Collect r-b tag
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 3 ++-
configs/rock5b-rk3588_defconfig | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 2386edf90deb..36d557b4934d 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -11,12 +11,13 @@
};
chosen {
- u-boot,spl-boot-order =
+ u-boot,spl-boot-order = "same-as-spl",
};
};
{
bus-width = <4>;
u-boot,dm-spl;
+ u-boot,spl-fifo-mode;
status = "okay";
};
diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index 66199387195a..3fcc6a26bb51 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -66,6 +66,5 @@ CONFIG_PWM_ROCKCHIP=y
CONFIG_SPL_RAM=y
CONFIG_BAUDRATE=150
CONFIG_DEBUG_UART_SHIFT=2
-CONFIG_DEBUG_UART_ANNOUNCE=y
CONFIG_SYSRESET=y
CONFIG_ERRNO_STR=y
--
2.40.0
[PATCH v2 1/4] rockchip: Use an external TPL binary on RK3588
There is no support to initialize DRAM on RK3588 SoCs using U-Boot TPL and instead an external TPL binary must be used to generate a bootable u-boot-rockchip.bin image. Enable ROCKCHIP_EXTERNAL_TPL by default for RK3588, add build steps for RK3588 to documentation and clean up CONFIG_BINMAN_FDT options. Signed-off-by: Jonas Karlman Reviewed-by: Jagan Teki --- v2: - Pre-req patch picked from [1] - Collect r-b tag [1] https://patchwork.ozlabs.org/project/uboot/patch/20230228213822.3583989-1-jo...@kwiboo.se/ arch/arm/mach-rockchip/Kconfig| 2 +- configs/neu6a-io-rk3588_defconfig | 1 - configs/rock-3a-rk3568_defconfig | 1 - configs/rock5b-rk3588_defconfig | 1 - doc/board/rockchip/rockchip.rst | 9 + 5 files changed, 10 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 0390431601f9..e5ac58ae60b5 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -428,7 +428,7 @@ config TPL_ROCKCHIP_COMMON_BOARD config ROCKCHIP_EXTERNAL_TPL bool "Use external TPL binary" - default y if ROCKCHIP_RK3568 + default y if ROCKCHIP_RK3568 || ROCKCHIP_RK3588 help Some Rockchip SoCs require an external TPL to initialize DRAM. Enable this option and build with ROCKCHIP_TPL=/path/to/ddr.bin to diff --git a/configs/neu6a-io-rk3588_defconfig b/configs/neu6a-io-rk3588_defconfig index fb5a2b7dbceb..33c03b58a16c 100644 --- a/configs/neu6a-io-rk3588_defconfig +++ b/configs/neu6a-io-rk3588_defconfig @@ -63,5 +63,4 @@ CONFIG_DM_RESET=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_SYSRESET=y -# CONFIG_BINMAN_FDT is not set CONFIG_ERRNO_STR=y diff --git a/configs/rock-3a-rk3568_defconfig b/configs/rock-3a-rk3568_defconfig index 1686c8c1aa5a..e16d98b07af9 100644 --- a/configs/rock-3a-rk3568_defconfig +++ b/configs/rock-3a-rk3568_defconfig @@ -70,5 +70,4 @@ CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_SYS_NS16550_MEM32=y CONFIG_SYSRESET=y -# CONFIG_BINMAN_FDT is not set CONFIG_ERRNO_STR=y diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig index f3026c7ea166..66199387195a 100644 --- a/configs/rock5b-rk3588_defconfig +++ b/configs/rock5b-rk3588_defconfig @@ -68,5 +68,4 @@ CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_SYSRESET=y -# CONFIG_BINMAN_FDT is not set CONFIG_ERRNO_STR=y diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index b5563b8f7f9e..1f88d15aad2a 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -185,6 +185,15 @@ To build rk3568 boards: make evb-rk3568_defconfig make CROSS_COMPILE=aarch64-linux-gnu- +To build rk3588 boards: + +.. code-block:: bash + +export BL31=../rkbin/bin/rk35/rk3588_bl31_v1.27.elf +export ROCKCHIP_TPL=../rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.08.bin +make rock5b-rk3588_defconfig +make CROSS_COMPILE=aarch64-linux-gnu- + Flashing -- 2.40.0
[PATCH v2 0/4] rockchip: Fixes for RK3568 and RK3588
This series contains fixes for RK3568 and RK3588. Patch 1 imply use of ROCKCHIP_TPL for RK3588 to generate bootable firmware image. Patch 2 fixes sdmmc boot on rk3588-rock-5b. Patch 3 fixes boot of rk3568-rock-3a, an issue introduced in v1. Patch 4 add fdtoverlay and compressed kernel addresses to env. The last patch is not a fix but some parts of it was included in v1, so I kept it in v2. Please consider these patches for v2023.04. Changes in v2: - Drop applied patches - Add the pre-req patch from [1] - Add patch to fix an issue introduced in v1 - Collect r-b tags This series can also be found at [2] [1] https://patchwork.ozlabs.org/project/uboot/patch/20230228213822.3583989-1-jo...@kwiboo.se/ [2] https://github.com/Kwiboo/u-boot-rockchip/commits/rk35xx-fixes-v2 Jonas Karlman (4): rockchip: Use an external TPL binary on RK3588 rockchip: rk3588-rock-5b: Fix sdmmc boot rockchip: rk35xx: Fix boot with a large fdt blob rockchip: rk35xx: Enable fdtoverlay and kernel compression arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 3 ++- arch/arm/mach-rockchip/Kconfig | 6 +- configs/neu6a-io-rk3588_defconfig | 1 - configs/rock-3a-rk3568_defconfig| 1 - configs/rock5b-rk3588_defconfig | 2 -- doc/board/rockchip/rockchip.rst | 9 + include/configs/rk3568_common.h | 7 ++- include/configs/rk3588_common.h | 7 ++- 8 files changed, 28 insertions(+), 8 deletions(-) -- 2.40.0
[PATCH v3 3/5] arm: dts: Import device tree for Broadcom Northstar
This brings in the main SoC device tree used by the
Broadcom Northstar chipset, i.e. BCM4709x and BCM5301x.
This is taken from the latest Linux kernel.
Cc: Rafał Miłecki
Signed-off-by: Linus Walleij
---
ChangeLog v1->v3:
- Bundle with the iproc nand and algo select patches
---
arch/arm/dts/bcm5301x.dtsi | 581
include/dt-bindings/clock/bcm-nsp.h | 51 +++
2 files changed, 632 insertions(+)
create mode 100644 arch/arm/dts/bcm5301x.dtsi
create mode 100644 include/dt-bindings/clock/bcm-nsp.h
diff --git a/arch/arm/dts/bcm5301x.dtsi b/arch/arm/dts/bcm5301x.dtsi
new file mode 100644
index ..5fc1b847f4aa
--- /dev/null
+++ b/arch/arm/dts/bcm5301x.dtsi
@@ -0,0 +1,581 @@
+/*
+ * Broadcom BCM470X / BCM5301X ARM platform code.
+ * Generic DTS part for all BCM53010, BCM53011, BCM53012, BCM53014, BCM53015,
+ * BCM53016, BCM53017, BCM53018, BCM4707, BCM4708 and BCM4709 SoCs
+ *
+ * Copyright 2013-2014 Hauke Mehrtens
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <>;
+
+ chipcommon-a-bus@1800 {
+ compatible = "simple-bus";
+ ranges = <0x 0x1800 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uart0: serial@300 {
+ compatible = "ns16550";
+ reg = <0x0300 0x100>;
+ interrupts = ;
+ clocks = <>;
+ status = "disabled";
+ };
+
+ uart1: serial@400 {
+ compatible = "ns16550";
+ reg = <0x0400 0x100>;
+ interrupts = ;
+ clocks = <>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart1>;
+ status = "disabled";
+ };
+ };
+
+ mpcore-bus@1900 {
+ compatible = "simple-bus";
+ ranges = <0x 0x1900 0x00023000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ a9pll: arm_clk@0 {
+ #clock-cells = <0>;
+ compatible = "brcm,nsp-armpll";
+ clocks = <>;
+ reg = <0x0 0x1000>;
+ };
+
+ scu@2 {
+ compatible = "arm,cortex-a9-scu";
+ reg = <0x2 0x100>;
+ };
+
+ timer@20200 {
+ compatible = "arm,cortex-a9-global-timer";
+ reg = <0x20200 0x100>;
+ interrupts = ;
+ clocks = <_clk>;
+ };
+
+ timer@20600 {
+ compatible = "arm,cortex-a9-twd-timer";
+ reg = <0x20600 0x20>;
+ interrupts = ;
+ clocks = <_clk>;
+ };
+
+ watchdog@20620 {
+ compatible = "arm,cortex-a9-twd-wdt";
+ reg = <0x20620 0x20>;
+ interrupts = ;
+ clocks = <_clk>;
+ };
+
+ gic: interrupt-controller@21000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x21000 0x1000>,
+ <0x20100 0x100>;
+ };
+
+ L2: cache-controller@22000 {
+ compatible = "arm,pl310-cache";
+ reg = <0x22000 0x1000>;
+ cache-unified;
+ arm,shared-override;
+ prefetch-data = <1>;
+ prefetch-instr = <1>;
+ cache-level = <2>;
+ };
+ };
+
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupts =
+ ,
+ ;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ osc: oscillator {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2500>;
+ };
+
+ iprocmed: iprocmed {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = < BCM_NSP_GENPLL_IPROCFAST_CLK>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
+
+ iprocslow: iprocslow {
+
[PATCH v3 4/5] arm: Add support for the Broadcom Northstar SoCs
The original Northstar is an ARM SoC series that comprise BCM4709x and BCM5301x and uses a dual-core Cortex A9, the global timer and a few other things. This series should not be confused with North Star Plus (NSP) which is partly supported by U-Boot already. The SoC is well supported by the Linux kernel and OpenWrt as it is used in many routers. Since we currently don't need any chip-specific quirks and can get the system up from just the device tree, a mach-* directory doesn't even need to be added, just some small Kconfig fragments. Cc: Rafał Miłecki Signed-off-by: Linus Walleij --- ChangeLog v1->v3: - Bundle with the iproc nand and algo select patches --- arch/arm/Kconfig | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index bd7fffcce0ba..ec129c6ff808 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -357,7 +357,7 @@ config SYS_ARM_ARCH choice prompt "Select the ARM data write cache policy" - default SYS_ARM_CACHE_WRITETHROUGH if TARGET_BCMCYGNUS || RZA1 + default SYS_ARM_CACHE_WRITETHROUGH if TARGET_BCMCYGNUS || TARGET_BCMNS || RZA1 default SYS_ARM_CACHE_WRITEBACK config SYS_ARM_CACHE_WRITEBACK @@ -670,6 +670,25 @@ config TARGET_BCMCYGNUS imply HASH_VERIFY imply NETDEVICES +config TARGET_BCMNS + bool "Support Broadcom Northstar" + select CPU_V7A + select DM + select DM_GPIO + select DM_SERIAL + select OF_CONTROL + select TIMER + select SYS_NS16550 + select ARM_GLOBAL_TIMER + imply SYS_THUMB_BUILD + imply MTD_RAW_NAND + imply NAND_BRCMNAND + imply NAND_BRCMNAND_IPROC + help + Support for Broadcom Northstar SoCs. NS is a dual-core 32-bit + ARMv7 Cortex-A9 SoC family including BCM4708, BCM47094, + BCM5301x etc. + config TARGET_BCMNS2 bool "Support Broadcom Northstar2" select ARM64 -- 2.39.2
[PATCH v3 5/5] board: Add new Broadcom Northstar board
This adds a simple Northstar "BRCMNS" board to be used with
the BCM4709x and BCM5301x chips.
The main intention is to use this with the D-Link DIR-890L
and DIR-885L routers for loading the kernel into RAM from
NAND memory using the BCH-1 ECC and using the separately
submitted SEAMA load command, so we are currently not adding
support for things such as networking.
If other board need other ECC for example, they need to
create a separate DTS file and augment the code, but I don't
know if any other users will turn up.
Cc: Rafał Miłecki
Signed-off-by: Linus Walleij
---
ChangeLog v1->v3:
- Bundle with the iproc nand and algo select patches
---
arch/arm/Kconfig | 1 +
arch/arm/dts/Makefile| 2 ++
arch/arm/dts/ns-board.dts| 57 ++
board/broadcom/bcmns/Kconfig | 12 +++
board/broadcom/bcmns/MAINTAINERS | 6
board/broadcom/bcmns/Makefile| 2 ++
board/broadcom/bcmns/ns.c| 60
configs/bcmns_defconfig | 41 ++
include/configs/bcmns.h | 49 ++
9 files changed, 230 insertions(+)
create mode 100644 arch/arm/dts/ns-board.dts
create mode 100644 board/broadcom/bcmns/Kconfig
create mode 100644 board/broadcom/bcmns/MAINTAINERS
create mode 100644 board/broadcom/bcmns/Makefile
create mode 100644 board/broadcom/bcmns/ns.c
create mode 100644 configs/bcmns_defconfig
create mode 100644 include/configs/bcmns.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ec129c6ff808..1556bec4a7f1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2285,6 +2285,7 @@ source "board/Marvell/octeontx2/Kconfig"
source "board/armltd/vexpress/Kconfig"
source "board/armltd/vexpress64/Kconfig"
source "board/cortina/presidio-asic/Kconfig"
+source "board/broadcom/bcmns/Kconfig"
source "board/broadcom/bcmns3/Kconfig"
source "board/cavium/thunderx/Kconfig"
source "board/eets/pdu001/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c160e884bf63..97a15f1d718c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1185,6 +1185,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
bcm2837-rpi-cm3-io3.dtb \
bcm2711-rpi-4-b.dtb
+dtb-$(CONFIG_TARGET_BCMNS) += ns-board.dtb
+
dtb-$(CONFIG_TARGET_BCMNS3) += ns3-board.dtb
dtb-$(CONFIG_ARCH_BCMSTB) += bcm7xxx.dtb
diff --git a/arch/arm/dts/ns-board.dts b/arch/arm/dts/ns-board.dts
new file mode 100644
index ..bc2a0dd1c961
--- /dev/null
+++ b/arch/arm/dts/ns-board.dts
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+#include "bcm5301x.dtsi"
+
+/ {
+ /*
+* The Northstar does not have a proper fallback compatible, but
+* these basic chips will suffice.
+*/
+ model = "Northstar model";
+ compatible = "brcm,bcm47094", "brcm,bcm4708";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <>;
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x0800>,
+ <0x8800 0x0800>;
+ };
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ nand-controller@18028000 {
+ nandcs: nand@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /*
+* Same as using the bcm5301x-nand-cs0-bch1.dtsi
+* include from the Linux kernel.
+*/
+ nand-ecc-algo = "bch";
+ nand-ecc-strength = <1>;
+ nand-ecc-step-size = <512>;
+
+ partitions {
+ compatible = "brcm,bcm947xx-cfe-partitions";
+ };
+ };
+ };
+};
+
+ {
+ clock-frequency = <12500>;
+ status = "okay";
+};
diff --git a/board/broadcom/bcmns/Kconfig b/board/broadcom/bcmns/Kconfig
new file mode 100644
index ..82f4709e2d2d
--- /dev/null
+++ b/board/broadcom/bcmns/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_BCMNS
+
+config SYS_BOARD
+ default "bcmns"
+
+config SYS_VENDOR
+ default "broadcom"
+
+config SYS_CONFIG_NAME
+ default "bcmns"
+
+endif
diff --git a/board/broadcom/bcmns/MAINTAINERS b/board/broadcom/bcmns/MAINTAINERS
new file mode 100644
index ..fd37c334a5b1
--- /dev/null
+++ b/board/broadcom/bcmns/MAINTAINERS
@@ -0,0 +1,6 @@
+BCMNS BOARD
+M: Linus Walleij
+S: Maintained
+F: board/broadcom/bcmnsp/
+F: configs/bcmnsp_defconfig
+F: include/configs/bcmnsp.h
diff --git a/board/broadcom/bcmns/Makefile b/board/broadcom/bcmns/Makefile
new file mode 100644
index ..8a6a8543a90b
--- /dev/null
+++
[PATCH v3 1/5] nand: brcmnand: add iproc support
Add support for the iproc Broadcom NAND controller,
used in Northstar SoCs for example. Based on the Linux
driver.
Cc: Philippe Reynes
Cc: Dario Binacchi
Acked-by: William Zhang
Reviewed-by: Michael Trimarchi
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Collect William Zhang's ACK
- Bundle with NorthStar enablement patches.
ChangeLog v1->v2:
- Check return value of dev_read_resource()
- Use devm_ioremap()
- Collect Michael's Review tag
---
drivers/mtd/nand/raw/Kconfig | 7 +
drivers/mtd/nand/raw/brcmnand/Makefile | 1 +
drivers/mtd/nand/raw/brcmnand/iproc_nand.c | 148 +
3 files changed, 156 insertions(+)
create mode 100644 drivers/mtd/nand/raw/brcmnand/iproc_nand.c
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 5b35da45f584..6a13bc1e228a 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -156,6 +156,13 @@ config NAND_BRCMNAND_63158
help
Enable support for broadcom nand driver on bcm63158.
+config NAND_BRCMNAND_IPROC
+ bool "Support Broadcom NAND controller on the iproc family"
+ depends on NAND_BRCMNAND
+ help
+ Enable support for broadcom nand driver on the Broadcom
+ iproc family such as Northstar (BCM5301x, BCM4708...)
+
config NAND_DAVINCI
bool "Support TI Davinci NAND controller"
select SYS_NAND_SELF_INIT if TARGET_DA850EVM
diff --git a/drivers/mtd/nand/raw/brcmnand/Makefile
b/drivers/mtd/nand/raw/brcmnand/Makefile
index f46a7edae321..0c6325aaa618 100644
--- a/drivers/mtd/nand/raw/brcmnand/Makefile
+++ b/drivers/mtd/nand/raw/brcmnand/Makefile
@@ -6,5 +6,6 @@ obj-$(CONFIG_NAND_BRCMNAND_6753) += bcm6753_nand.o
obj-$(CONFIG_NAND_BRCMNAND_68360) += bcm68360_nand.o
obj-$(CONFIG_NAND_BRCMNAND_6838) += bcm6838_nand.o
obj-$(CONFIG_NAND_BRCMNAND_6858) += bcm6858_nand.o
+obj-$(CONFIG_NAND_BRCMNAND_IPROC) += iproc_nand.o
obj-$(CONFIG_NAND_BRCMNAND) += brcmnand.o
obj-$(CONFIG_NAND_BRCMNAND) += brcmnand_compat.o
diff --git a/drivers/mtd/nand/raw/brcmnand/iproc_nand.c
b/drivers/mtd/nand/raw/brcmnand/iproc_nand.c
new file mode 100644
index ..69711d98ce1b
--- /dev/null
+++ b/drivers/mtd/nand/raw/brcmnand/iproc_nand.c
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Code borrowed from the Linux driver
+ * Copyright (C) 2015 Broadcom Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "brcmnand.h"
+
+struct iproc_nand_soc {
+ struct brcmnand_soc soc;
+ void __iomem *idm_base;
+ void __iomem *ext_base;
+};
+
+#define IPROC_NAND_CTLR_READY_OFFSET 0x10
+#define IPROC_NAND_CTLR_READY BIT(0)
+
+#define IPROC_NAND_IO_CTRL_OFFSET 0x00
+#define IPROC_NAND_APB_LE_MODE BIT(24)
+#define IPROC_NAND_INT_CTRL_READ_ENABLEBIT(6)
+
+static bool iproc_nand_intc_ack(struct brcmnand_soc *soc)
+{
+ struct iproc_nand_soc *priv =
+ container_of(soc, struct iproc_nand_soc, soc);
+ void __iomem *mmio = priv->ext_base + IPROC_NAND_CTLR_READY_OFFSET;
+ u32 val = brcmnand_readl(mmio);
+
+ if (val & IPROC_NAND_CTLR_READY) {
+ brcmnand_writel(IPROC_NAND_CTLR_READY, mmio);
+ return true;
+ }
+
+ return false;
+}
+
+static void iproc_nand_intc_set(struct brcmnand_soc *soc, bool en)
+{
+ struct iproc_nand_soc *priv =
+ container_of(soc, struct iproc_nand_soc, soc);
+ void __iomem *mmio = priv->idm_base + IPROC_NAND_IO_CTRL_OFFSET;
+ u32 val = brcmnand_readl(mmio);
+
+ if (en)
+ val |= IPROC_NAND_INT_CTRL_READ_ENABLE;
+ else
+ val &= ~IPROC_NAND_INT_CTRL_READ_ENABLE;
+
+ brcmnand_writel(val, mmio);
+}
+
+static void iproc_nand_apb_access(struct brcmnand_soc *soc, bool prepare,
+ bool is_param)
+{
+ struct iproc_nand_soc *priv =
+ container_of(soc, struct iproc_nand_soc, soc);
+ void __iomem *mmio = priv->idm_base + IPROC_NAND_IO_CTRL_OFFSET;
+ u32 val;
+
+ val = brcmnand_readl(mmio);
+
+ /*
+* In the case of BE or when dealing with NAND data, always configure
+* the APB bus to LE mode before accessing the FIFO and back to BE mode
+* after the access is done
+*/
+ if (IS_ENABLED(CONFIG_SYS_BIG_ENDIAN) || !is_param) {
+ if (prepare)
+ val |= IPROC_NAND_APB_LE_MODE;
+ else
+ val &= ~IPROC_NAND_APB_LE_MODE;
+ } else { /* when in LE accessing the parameter page, keep APB in BE */
+ val &= ~IPROC_NAND_APB_LE_MODE;
+ }
+
+ brcmnand_writel(val, mmio);
+}
+
+static int iproc_nand_probe(struct udevice *dev)
+{
+ struct udevice *pdev = dev;
+ struct iproc_nand_soc *priv = dev_get_priv(dev);
+ struct
[PATCH v3 2/5] mtd: rawnand: nand_base: Handle algorithm selection
For BRCMNAND with 1-bit BCH ECC (BCH-1) such as used on the
D-Link DIR-885L and DIR-890L routers, we need to explicitly
select the ECC like this in the device tree:
nand-ecc-algo = "bch";
nand-ecc-strength = <1>;
nand-ecc-step-size = <512>;
This is handled by the Linux kernel but U-Boot core does
not respect this. Fix it up by parsing the algorithm and
preserve the behaviour using this property to select
software BCH as far as possible.
Reviewed-by: Michael Trimarchi
Acked-by: William Zhang
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Collect review tags from Michael and William
- Resend with the NorthStar enablement patches
ChangeLog v1->v2:
- Drop pointless check for ecc_algo >= 0, it is always
>= 0.
---
drivers/mtd/nand/raw/nand_base.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 9eba360d55f3..c173fd09237a 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4487,6 +4487,7 @@ EXPORT_SYMBOL(nand_detect);
static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip, ofnode
node)
{
int ret, ecc_mode = -1, ecc_strength, ecc_step;
+ int ecc_algo = NAND_ECC_UNKNOWN;
const char *str;
ret = ofnode_read_s32_default(node, "nand-bus-width", -1);
@@ -4512,10 +4513,13 @@ static int nand_dt_init(struct mtd_info *mtd, struct
nand_chip *chip, ofnode nod
ecc_mode = NAND_ECC_SOFT_BCH;
}
- if (ecc_mode == NAND_ECC_SOFT) {
- str = ofnode_read_string(node, "nand-ecc-algo");
- if (str && !strcmp(str, "bch"))
+ str = ofnode_read_string(node, "nand-ecc-algo");
+ if (str && !strcmp(str, "bch")) {
+ ecc_algo = NAND_ECC_BCH;
+ if (ecc_mode == NAND_ECC_SOFT)
ecc_mode = NAND_ECC_SOFT_BCH;
+ } else if (!strcmp(str, "hamming")) {
+ ecc_algo = NAND_ECC_HAMMING;
}
ecc_strength = ofnode_read_s32_default(node,
@@ -4529,6 +4533,8 @@ static int nand_dt_init(struct mtd_info *mtd, struct
nand_chip *chip, ofnode nod
return -EINVAL;
}
+ chip->ecc.algo = ecc_algo;
+
if (ecc_mode >= 0)
chip->ecc.mode = ecc_mode;
--
2.39.2
[PATCH v3 0/5] Add Broadcom Northstar basic support
This adds the device trees and minimal code needed to run U-Boot on Broadcom Northstar SoCs. This is needed to properly boot the D-Link DIR-890L router as it refuse to directly boot compressed kernels bigger than 2MB, and well our compressed kernel is bigger than 2MB so let's put in U-Boot. While it is a bit tailored to this usecase (it can probably also be used with the DIR-885L without modifications) it forms a base that can be used to support more Northstar boards. I have this working with DIR-890L and OpenWrt: https://dflund.se/~triad/krad/dlink-dir-890l/ ChangeLog v1->v3: - Bundle with the iproc NAND and nand base pacthes as the iproc patch is a prerequisite. - Jump from v1->v3 as the other patches was at version v3. It is a bit of a mystery to me who can merge this patches... BRCM custodian? Linus Walleij (5): nand: brcmnand: add iproc support mtd: rawnand: nand_base: Handle algorithm selection arm: dts: Import device tree for Broadcom Northstar arm: Add support for the Broadcom Northstar SoCs board: Add new Broadcom Northstar board arch/arm/Kconfig | 22 +- arch/arm/dts/Makefile | 2 + arch/arm/dts/bcm5301x.dtsi | 581 + arch/arm/dts/ns-board.dts | 57 ++ board/broadcom/bcmns/Kconfig | 12 + board/broadcom/bcmns/MAINTAINERS | 6 + board/broadcom/bcmns/Makefile | 2 + board/broadcom/bcmns/ns.c | 60 +++ configs/bcmns_defconfig| 41 ++ drivers/mtd/nand/raw/Kconfig | 7 + drivers/mtd/nand/raw/brcmnand/Makefile | 1 + drivers/mtd/nand/raw/brcmnand/iproc_nand.c | 148 ++ drivers/mtd/nand/raw/nand_base.c | 12 +- include/configs/bcmns.h| 49 ++ include/dt-bindings/clock/bcm-nsp.h| 51 ++ 15 files changed, 1047 insertions(+), 4 deletions(-) create mode 100644 arch/arm/dts/bcm5301x.dtsi create mode 100644 arch/arm/dts/ns-board.dts create mode 100644 board/broadcom/bcmns/Kconfig create mode 100644 board/broadcom/bcmns/MAINTAINERS create mode 100644 board/broadcom/bcmns/Makefile create mode 100644 board/broadcom/bcmns/ns.c create mode 100644 configs/bcmns_defconfig create mode 100644 drivers/mtd/nand/raw/brcmnand/iproc_nand.c create mode 100644 include/configs/bcmns.h create mode 100644 include/dt-bindings/clock/bcm-nsp.h -- 2.39.2
Re: [PATCH 3/3] board: Add new Broadcom Northstar board
On Fri, Feb 10, 2023 at 6:49 PM Tom Rini wrote: > On Thu, Feb 02, 2023 at 12:37:45AM +0100, Linus Walleij wrote: > > > This adds a simple Northstar "BRCMNS" board to be used with > > the BCM4709x and BCM5301x chips. > > > > The main intention is to use this with the D-Link DIR-890L > > and DIR-885L routers for loading the kernel into RAM from > > NAND memory using the BCH-1 ECC and using the separately > > submitted SEAMA load command, so we are currently not adding > > support for things such as networking. > > > > If other board need other ECC for example, they need to > > create a separate DTS file and augment the code, but I don't > > know if any other users will turn up. > > > > Cc: Rafał Miłecki > > Signed-off-by: Linus Walleij > > As it stands, this fails to link: >arm: + bcmns > +(bcmns) arm-linux-gnueabi-ld.bfd: drivers/mtd/nand/raw/nand.o: in function > `nand_init': > +(bcmns) drivers/mtd/nand/raw/nand.c:159: undefined reference to > `board_nand_init' > +(bcmns) make[1]: *** [Makefile:1752: u-boot] Error 1 > +(bcmns) make: *** [Makefile:177: sub-make] Error 2 This is because the iproc NAND driver is a dependency, I will collect the ACKS on those and resend the whole bundle instead, thanks! Yours, Linus Walleij
Re: [PATCH 2/3] CI: Ensure that vpl test is run
On Tue, Feb 28, 2023 at 08:34:20PM -0700, Simon Glass wrote: > This is actually skipped at present due to the condition in the file. > Fix this by running all vpl tests. > > Signed-off-by: Simon Glass > --- > > .azure-pipelines.yml | 2 +- > .gitlab-ci.yml | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) This fails: https://source.denx.de/u-boot/u-boot/-/jobs/598435 -- Tom signature.asc Description: PGP signature
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tuesday 21 March 2023 20:56:02 Pali Rohár wrote: > On Tuesday 21 March 2023 18:25:56 Pali Rohár wrote: > > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár wrote: > > > > > > > On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > > > > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > > > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár wrote: > > > > > > > > > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > > > > > On Sun, 5 Mar 2023 at 11:55, 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I tested using the latest next branch which has those changes > > > > > > > > > in > > > > it. > > > > > > > Steps: > > > > > > > > > - Set UART boot mode on device > > > > > > > > > - make clean > > > > > > > > > - make clearfog_defconfig > > > > > > > > > - make > > > > > > > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > > > > > > > > > > > For me it looks
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tuesday 21 March 2023 18:25:56 Pali Rohár wrote: > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár wrote: > > > > > On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > > > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár wrote: > > > > > > > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > > > > On Sun, 5 Mar 2023 at 11:55, 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. > > > > > > > > > > > > > > > > > > > > > > > > > I tested using the latest next branch which has those changes in > > > it. > > > > > > Steps: > > > > > > > > - Set UART boot mode on device > > > > > > > > - make clean > > > > > > > > - make clearfog_defconfig > > > > > > > > - make > > > > > > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > > > > > Detected kwbimage v1 with SDIO boot signature > > > > > > > > Patching image boot signature to UART > > > > >
Re: [PATCH] efi_loader: define allow_unaligned as 'asm volatile'
On 3/20/23 18:13, Ilias Apalodimas wrote:
Tom reports that compiling with LTO & EFI breaks armv7 and arm11*
builds. The reason is that LTO (maybe a binutils bug?) replaces the
asm version of allow_unaligned() with the __weak definition of the
function. As a result EFI code ends up running with unaligned accesses
disabled and eventually crashes.
allow_unaligned() hardware specific variants are usually defined in .S
files. Switching those to inline assembly fixes the problem and the
linker keeps the correct version in the final binary
Reported-by: Tom Rini
Signed-off-by: Ilias Apalodimas
---
This is an alternative approach to
https://lore.kernel.org/u-boot/ZBRy1oSZ5iVFqrdV@hera/
since enabling unaligned accesses by default has been rejected in the past
arch/arm/cpu/arm11/Makefile | 4
arch/arm/cpu/arm11/cpu.c| 13 +
arch/arm/cpu/arm11/sctlr.S | 25 -
arch/arm/cpu/armv7/Makefile | 1 -
arch/arm/cpu/armv7/cpu.c| 11 +++
arch/arm/cpu/armv7/sctlr.S | 22 --
6 files changed, 24 insertions(+), 52 deletions(-)
delete mode 100644 arch/arm/cpu/arm11/sctlr.S
delete mode 100644 arch/arm/cpu/armv7/sctlr.S
diff --git a/arch/arm/cpu/arm11/Makefile b/arch/arm/cpu/arm11/Makefile
index 5dfa01ae8d05..5d721fce12b5 100644
--- a/arch/arm/cpu/arm11/Makefile
+++ b/arch/arm/cpu/arm11/Makefile
@@ -4,7 +4,3 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
obj-y = cpu.o
-
-ifneq ($(CONFIG_SPL_BUILD),y)
-obj-$(CONFIG_EFI_LOADER) += sctlr.o
-endif
diff --git a/arch/arm/cpu/arm11/cpu.c b/arch/arm/cpu/arm11/cpu.c
index ffe35111d589..b19c4fc4a6c2 100644
--- a/arch/arm/cpu/arm11/cpu.c
+++ b/arch/arm/cpu/arm11/cpu.c
@@ -111,3 +111,16 @@ void enable_caches(void)
#endif
}
#endif
+
+#if !IS_ENABLED(CONFIG_SPL_BUILD)
+void allow_unaligned(void)
+{
+ asm volatile(
+ "mrc p15, 0, r0, c1, c0, 0\n" //load system control register
+ "orr r0, r0, #1 << 22\n" //set unaligned data support flag
+ "bic r0, r0, #2\n" //clear aligned flag
+ "mcr p15, 0, r0, c1, c0, 0\n" // write system control register
+ "bxlr\n" //return
+ );
+}
+#endif
diff --git a/arch/arm/cpu/arm11/sctlr.S b/arch/arm/cpu/arm11/sctlr.S
deleted file mode 100644
index 74a7fc4a25b6..
--- a/arch/arm/cpu/arm11/sctlr.S
+++ /dev/null
@@ -1,25 +0,0 @@
-/* SPDX-License-Identifier:GPL-2.0+ */
-/*
- * Routines to access the system control register
- *
- * Copyright (c) 2019 Heinrich Schuchardt
- */
-
-#include
-
-/*
- * void allow_unaligned(void) - allow unaligned access
- *
- * This routine sets the enable unaligned data support flag and clears the
- * aligned flag in the system control register.
- * After calling this routine unaligned access does no longer leads to a
- * data abort or undefined behavior but is handled by the CPU.
- * For details see the "ARM Architecture Reference Manual" for ARMv6.
- */
-ENTRY(allow_unaligned)
- mrc p15, 0, r0, c1, c0, 0 @ load system control register
- orr r0, r0, #1 << 22 @ set unaligned data support flag
- bic r0, r0, #2 @ clear aligned flag
- mcr p15, 0, r0, c1, c0, 0 @ write system control register
- bx lr @ return
-ENDPROC(allow_unaligned)
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 653eef8ad79e..ca50f6e93e10 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -13,7 +13,6 @@ obj-y += syslib.o
obj-$(CONFIG_SYS_ARM_MPU) += mpu_v7r.o
ifneq ($(CONFIG_SPL_BUILD),y)
-obj-$(CONFIG_EFI_LOADER) += sctlr.o
obj-$(CONFIG_ARMV7_NONSEC) += exception_level.o
endif
diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index 68807d209978..9742fa65e3cf 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -83,3 +83,14 @@ int cleanup_before_linux(void)
{
return cleanup_before_linux_select(CBL_ALL);
}
+
+#if !IS_ENABLED(CONFIG_SPL_BUILD)
Why do we need this #if? The linker should eliminate unused functions.
Best regards
Heinrich
+void allow_unaligned(void)
+{
+ asm volatile(
+ "mrc p15, 0, r0, c1, c0, 0\n" //load system control register
+ "bic r0, r0, #2\n" //clear aligned flag
+ "mcr p15, 0, r0, c1, c0, 0\n" //write system control register
+ );
+}
+#endif
diff --git a/arch/arm/cpu/armv7/sctlr.S b/arch/arm/cpu/armv7/sctlr.S
deleted file mode 100644
index bd56e41afe18..
--- a/arch/arm/cpu/armv7/sctlr.S
+++ /dev/null
@@ -1,22 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Routines to access the system control register
- *
- * Copyright (c) 2018 Heinrich Schuchardt
- */
-
-#include
-
-/*
- * void allow_unaligned(void) - allow unaligned access
- *
- * This routine clears the aligned flag in the system control register.
- * After
[PATCH 1/2] Dockerfile: Add m68k-softmmu to qemu
Given efforts to add an m68k target to CI, build qemu for it. Signed-off-by: Tom Rini --- Cc: Marek Vasut --- tools/docker/Dockerfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index fdcb0c7f3d29..2d94ed9fbacf 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -182,7 +182,7 @@ RUN git clone https://gitlab.com/qemu-project/qemu.git /tmp/qemu && \ git config user.email u-b...@denx.de && \ # manually apply the bug fix for QEMU 6.1.0 Xilinx Zynq UART emulation codes wget -O - http://patchwork.ozlabs.org/project/qemu-devel/patch/20210823020813.25192-2-bmeng...@gmail.com/mbox/ | git am && \ - ./configure --prefix=/opt/qemu --target-list="aarch64-softmmu,arm-softmmu,i386-softmmu,mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu,ppc-softmmu,riscv32-softmmu,riscv64-softmmu,sh4-softmmu,x86_64-softmmu,xtensa-softmmu" && \ + ./configure --prefix=/opt/qemu --target-list="aarch64-softmmu,arm-softmmu,i386-softmmu,m68k-softmmu,mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu,ppc-softmmu,riscv32-softmmu,riscv64-softmmu,sh4-softmmu,x86_64-softmmu,xtensa-softmmu" && \ make -j$(nproc) all install && \ rm -rf /tmp/qemu -- 2.34.1
[PATCH 2/2] Dockerfile: Update to latest "Jammy" tag
Update to using the latest "Jammy" tag as our base. Signed-off-by: Tom Rini --- tools/docker/Dockerfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index 2d94ed9fbacf..bd02531be249 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -2,7 +2,7 @@ # This Dockerfile is used to build an image containing basic stuff to be used # to build U-Boot and run our test suites. -FROM ubuntu:jammy-20230126 +FROM ubuntu:jammy-20230308 MAINTAINER Tom Rini LABEL Description=" This image is for building U-Boot inside a container" -- 2.34.1
[PATCH] CI: Move to clang-16
As this is now the stable release, move to using that now for our tests. Signed-off-by: Tom Rini --- .azure-pipelines.yml| 6 +++--- .gitlab-ci.yml | 4 ++-- tools/docker/Dockerfile | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 61ada4d681f9..e5068fecf2fb 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -2,7 +2,7 @@ variables: windows_vm: windows-2019 ubuntu_vm: ubuntu-22.04 macos_vm: macOS-12 - ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20230126-17Feb2023 + ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20230126-21Mar2023 # Add '-u 0' options for Azure pipelines, otherwise we get "permission # denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer", # since our $(ci_runner_image) user is not root. @@ -254,7 +254,7 @@ stages: TEST_PY_BD: "sandbox" sandbox_clang: TEST_PY_BD: "sandbox" - OVERRIDE: "-O clang-14" + OVERRIDE: "-O clang-16" sandbox_nolto: TEST_PY_BD: "sandbox" BUILD_ENV: "NO_LTO=1" @@ -508,7 +508,7 @@ stages: OVERRIDE: "-a ASAN" sandbox_clang_asan: BUILDMAN: "sandbox" - OVERRIDE: "-O clang-14 -a ASAN" + OVERRIDE: "-O clang-16 -a ASAN" samsung_socfpga: BUILDMAN: "samsung socfpga" sun4i: diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index a89138701dcf..75a8270bc31b 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -2,7 +2,7 @@ # Grab our configured image. The source for this is found # in the u-boot tree at tools/docker/Dockerfile -image: trini/u-boot-gitlab-ci-runner:jammy-20230126-17Feb2023 +image: trini/u-boot-gitlab-ci-runner:jammy-20230126-21Mar2023 # We run some tests in different order, to catch some failures quicker. stages: @@ -266,7 +266,7 @@ sandbox test.py: sandbox with clang test.py: variables: TEST_PY_BD: "sandbox" -OVERRIDE: "-O clang-14" +OVERRIDE: "-O clang-16" <<: *buildman_and_testpy_dfn sandbox without LTO test.py: diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index fdcb0c7f3d29..109b033c4c99 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -12,7 +12,7 @@ ENV DEBIAN_FRONTEND=noninteractive # Add LLVM repository RUN apt-get update && apt-get install -y gnupg2 wget xz-utils && rm -rf /var/lib/apt/lists/* RUN wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - -RUN echo deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-14 main | tee /etc/apt/sources.list.d/llvm.list +RUN echo deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-16 main | tee /etc/apt/sources.list.d/llvm.list # Manually install the kernel.org "Crosstool" based toolchains for gcc-12.2.0 RUN wget -O - https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/x86_64-gcc-12.2.0-nolibc-aarch64-linux.tar.xz | tar -C /opt -xJ @@ -39,7 +39,7 @@ RUN apt-get update && apt-get install -y \ binutils-dev \ bison \ build-essential \ - clang-14 \ + clang-16 \ coreutils \ cpio \ cppcheck \ -- 2.34.1
Re: [PATCH 01/41] net: phy: aquantia: Staticize PHY driver entries
On Tue, Mar 21, 2023 at 03:39:16PM +0100, Michal Simek wrote: > Would be good if you also create cover letter which I can reply. > I have tested this series on Microblaze which is also using MANUAL > relocation (but we are removing it from 2023.07 release) and it is working > fine. Agree that a cover letter giving the big picture would have been nice, not really sure what I'm looking at here :-/ and especially whether there's anything to test on platforms which don't have CONFIG_NEEDS_MANUAL_RELOC.
[PATCH v2 2/3] net: mvpp2: Replace PHY_INTERFACE_MODE_SFI with 5GBASER/10GBASER/XAUI
Replace PHY_INTERFACE_MODE_SFI with PHY_INTERFACE_MODE_5GBASER,
PHY_INTERFACE_MODE_10GBASER and PHY_INTERFACE_MODE_XAUI to match
Linux PHY interface modes.
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "Marek Behún"
Cc: Joe Hershberger
Cc: Marek Vasut
Cc: Ramon Fried
Cc: Stefan Roese
Cc: Tim Harvey
Cc: Vladimir Oltean
---
V2: No change
---
drivers/net/mvpp2.c | 8 ++--
include/phy_interface.h | 2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
index c99d52c85d7..f407d8f6a81 100644
--- a/drivers/net/mvpp2.c
+++ b/drivers/net/mvpp2.c
@@ -3391,7 +3391,9 @@ static int gop_port_init(struct mvpp2_port *port)
gop_gmac_reset(port, 0);
break;
- case PHY_INTERFACE_MODE_SFI:
+ case PHY_INTERFACE_MODE_10GBASER:
+ case PHY_INTERFACE_MODE_5GBASER:
+ case PHY_INTERFACE_MODE_XAUI:
num_of_act_lanes = 2;
mac_num = 0;
/* configure PCS */
@@ -3442,7 +3444,9 @@ static void gop_port_enable(struct mvpp2_port *port, int
enable)
mvpp2_port_disable(port);
break;
- case PHY_INTERFACE_MODE_SFI:
+ case PHY_INTERFACE_MODE_10GBASER:
+ case PHY_INTERFACE_MODE_5GBASER:
+ case PHY_INTERFACE_MODE_XAUI:
gop_xlg_mac_port_enable(port, enable);
break;
diff --git a/include/phy_interface.h b/include/phy_interface.h
index fed3357b9a2..52af7e612b6 100644
--- a/include/phy_interface.h
+++ b/include/phy_interface.h
@@ -31,6 +31,7 @@ typedef enum {
PHY_INTERFACE_MODE_XGMII,
PHY_INTERFACE_MODE_XAUI,
PHY_INTERFACE_MODE_RXAUI,
+ PHY_INTERFACE_MODE_5GBASER,
PHY_INTERFACE_MODE_SFI,
PHY_INTERFACE_MODE_INTERNAL,
PHY_INTERFACE_MODE_25G_AUI,
@@ -62,6 +63,7 @@ static const char * const phy_interface_strings[] = {
[PHY_INTERFACE_MODE_XGMII] = "xgmii",
[PHY_INTERFACE_MODE_XAUI] = "xaui",
[PHY_INTERFACE_MODE_RXAUI] = "rxaui",
+ [PHY_INTERFACE_MODE_5GBASER]= "5gbase-r",
[PHY_INTERFACE_MODE_SFI]= "sfi",
[PHY_INTERFACE_MODE_INTERNAL] = "internal",
[PHY_INTERFACE_MODE_25G_AUI]= "25g-aui",
--
2.39.2
[PATCH v2 3/3] net: phy: Synchronize PHY interface modes with Linux
Synchronize PHY interface modes with Linux next 6.2.y commit:
0194b64578e90 ("net: phy: improve phy_read_poll_timeout")
Retain LX2160A/LX2162A PHY modes as those are not yet supported
by the Linux kernel, but isolate those with ifdeffery.
Isolate NCSI which are also not supported by Linux kernel. Note
that the ifdeffery cannot be avoided with IS_ENABLED() here due
to compilation of the entire conditional, which would fail in
case NCSI symbols are not available.
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "Marek Behún"
Cc: Joe Hershberger
Cc: Marek Vasut
Cc: Ramon Fried
Cc: Stefan Roese
Cc: Tim Harvey
Cc: Vladimir Oltean
---
V2: No change
---
drivers/net/phy/phy.c | 4 +++
include/phy_interface.h | 68 +
2 files changed, 53 insertions(+), 19 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 9b0e497f223..f720d0a7920 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1160,7 +1160,11 @@ int phy_clear_bits_mmd(struct phy_device *phydev, int
devad, u32 regnum, u16 val
bool phy_interface_is_ncsi(void)
{
+#ifdef CONFIG_PHY_NCSI
struct eth_pdata *pdata = dev_get_plat(eth_get_dev());
return pdata->phy_interface == PHY_INTERFACE_MODE_NCSI;
+#else
+ return 0;
+#endif
}
diff --git a/include/phy_interface.h b/include/phy_interface.h
index 52af7e612b6..31be3228c7c 100644
--- a/include/phy_interface.h
+++ b/include/phy_interface.h
@@ -14,65 +14,95 @@
typedef enum {
PHY_INTERFACE_MODE_NA, /* don't touch */
+ PHY_INTERFACE_MODE_INTERNAL,
PHY_INTERFACE_MODE_MII,
PHY_INTERFACE_MODE_GMII,
PHY_INTERFACE_MODE_SGMII,
- PHY_INTERFACE_MODE_SGMII_2500,
- PHY_INTERFACE_MODE_QSGMII,
PHY_INTERFACE_MODE_TBI,
+ PHY_INTERFACE_MODE_REVMII,
PHY_INTERFACE_MODE_RMII,
+ PHY_INTERFACE_MODE_REVRMII,
PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_RGMII_ID,
PHY_INTERFACE_MODE_RGMII_RXID,
PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI,
+ PHY_INTERFACE_MODE_SMII,
+ PHY_INTERFACE_MODE_XGMII,
+ PHY_INTERFACE_MODE_XLGMII,
+ PHY_INTERFACE_MODE_MOCA,
+ PHY_INTERFACE_MODE_QSGMII,
+ PHY_INTERFACE_MODE_TRGMII,
+ PHY_INTERFACE_MODE_100BASEX,
PHY_INTERFACE_MODE_1000BASEX,
PHY_INTERFACE_MODE_2500BASEX,
- PHY_INTERFACE_MODE_XGMII,
- PHY_INTERFACE_MODE_XAUI,
- PHY_INTERFACE_MODE_RXAUI,
PHY_INTERFACE_MODE_5GBASER,
- PHY_INTERFACE_MODE_SFI,
- PHY_INTERFACE_MODE_INTERNAL,
+ PHY_INTERFACE_MODE_RXAUI,
+ PHY_INTERFACE_MODE_XAUI,
+ /* 10GBASE-R, XFI, SFI - single lane 10G Serdes */
+ PHY_INTERFACE_MODE_10GBASER,
+ PHY_INTERFACE_MODE_25GBASER,
+ PHY_INTERFACE_MODE_USXGMII,
+ /* 10GBASE-KR - with Clause 73 AN */
+ PHY_INTERFACE_MODE_10GKR,
+ PHY_INTERFACE_MODE_QUSGMII,
+ PHY_INTERFACE_MODE_1000BASEKX,
+#if defined(CONFIG_ARCH_LX2160A) || defined(CONFIG_ARCH_LX2162A)
+ /* LX2160A SERDES modes */
PHY_INTERFACE_MODE_25G_AUI,
PHY_INTERFACE_MODE_XLAUI,
PHY_INTERFACE_MODE_CAUI2,
PHY_INTERFACE_MODE_CAUI4,
+#endif
+#if defined(CONFIG_PHY_NCSI)
PHY_INTERFACE_MODE_NCSI,
- PHY_INTERFACE_MODE_10GBASER,
- PHY_INTERFACE_MODE_USXGMII,
+#endif
PHY_INTERFACE_MODE_MAX,
} phy_interface_t;
static const char * const phy_interface_strings[] = {
- [PHY_INTERFACE_MODE_NA] = "",
+ [PHY_INTERFACE_MODE_NA] = "",
+ [PHY_INTERFACE_MODE_INTERNAL] = "internal",
[PHY_INTERFACE_MODE_MII]= "mii",
[PHY_INTERFACE_MODE_GMII] = "gmii",
[PHY_INTERFACE_MODE_SGMII] = "sgmii",
- [PHY_INTERFACE_MODE_SGMII_2500] = "sgmii-2500",
- [PHY_INTERFACE_MODE_QSGMII] = "qsgmii",
[PHY_INTERFACE_MODE_TBI]= "tbi",
+ [PHY_INTERFACE_MODE_REVMII] = "rev-mii",
[PHY_INTERFACE_MODE_RMII] = "rmii",
+ [PHY_INTERFACE_MODE_REVRMII]= "rev-rmii",
[PHY_INTERFACE_MODE_RGMII] = "rgmii",
[PHY_INTERFACE_MODE_RGMII_ID] = "rgmii-id",
[PHY_INTERFACE_MODE_RGMII_RXID] = "rgmii-rxid",
[PHY_INTERFACE_MODE_RGMII_TXID] = "rgmii-txid",
[PHY_INTERFACE_MODE_RTBI] = "rtbi",
+ [PHY_INTERFACE_MODE_SMII] = "smii",
+ [PHY_INTERFACE_MODE_XGMII] = "xgmii",
+ [PHY_INTERFACE_MODE_XLGMII] = "xlgmii",
+ [PHY_INTERFACE_MODE_MOCA] = "moca",
+ [PHY_INTERFACE_MODE_QSGMII] = "qsgmii",
+ [PHY_INTERFACE_MODE_TRGMII] = "trgmii",
[PHY_INTERFACE_MODE_1000BASEX] = "1000base-x",
+ [PHY_INTERFACE_MODE_1000BASEKX] =
[PATCH v2 1/3] net: mvpp2: Drop PHY_INTERFACE_MODE_SGMII_2500 support
This mode does not seem to be well defined and used anywhere, remove support
for it.
Based on discussion:
- 1000baseX does c37 AN of duplex+pause
- SGMII does AN of duplex+pause+speed, at lower speed bytes are repeated
10x/100x
- 2500baseX does not do AN, or does very different c73 AN
- SGMII 2500 behavior is unclear
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "Marek Behún"
Cc: Joe Hershberger
Cc: Marek Vasut
Cc: Ramon Fried
Cc: Stefan Roese
Cc: Tim Harvey
Cc: Vladimir Oltean
---
V2: Drop SGMII 2500 support, if it becomes required and/or standardized,
this patch can be reverted
---
drivers/net/mvpp2.c | 53 -
1 file changed, 53 deletions(-)
diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
index 1bad50d344c..c99d52c85d7 100644
--- a/drivers/net/mvpp2.c
+++ b/drivers/net/mvpp2.c
@@ -2871,7 +2871,6 @@ static void mvpp2_port_mii_set(struct mvpp2_port *port)
switch (port->phy_interface) {
case PHY_INTERFACE_MODE_SGMII:
- case PHY_INTERFACE_MODE_SGMII_2500:
val |= MVPP2_GMAC_INBAND_AN_MASK;
break;
case PHY_INTERFACE_MODE_1000BASEX:
@@ -2939,7 +2938,6 @@ static void mvpp2_port_loopback_set(struct mvpp2_port
*port)
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII_2500 ||
port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PCS_LB_EN_MASK;
@@ -3027,48 +3025,6 @@ static int gop_bypass_clk_cfg(struct mvpp2_port *port,
int en)
return 0;
}
-static void gop_gmac_sgmii2_5_cfg(struct mvpp2_port *port)
-{
- u32 val, thresh;
-
- /*
-* Configure minimal level of the Tx FIFO before the lower part
-* starts to read a packet
-*/
- thresh = MVPP2_SGMII2_5_TX_FIFO_MIN_TH;
- val = readl(port->base + MVPP2_GMAC_PORT_FIFO_CFG_1_REG);
- val &= ~MVPP2_GMAC_TX_FIFO_MIN_TH_ALL_MASK;
- val |= MVPP2_GMAC_TX_FIFO_MIN_TH_MASK(thresh);
- writel(val, port->base + MVPP2_GMAC_PORT_FIFO_CFG_1_REG);
-
- /* Disable bypass of sync module */
- val = readl(port->base + MVPP2_GMAC_CTRL_4_REG);
- val |= MVPP2_GMAC_CTRL4_SYNC_BYPASS_MASK;
- /* configure DP clock select according to mode */
- val |= MVPP2_GMAC_CTRL4_DP_CLK_SEL_MASK;
- /* configure QSGMII bypass according to mode */
- val |= MVPP2_GMAC_CTRL4_QSGMII_BYPASS_ACTIVE_MASK;
- writel(val, port->base + MVPP2_GMAC_CTRL_4_REG);
-
- val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
- /*
-* Configure GIG MAC to SGMII mode connected to a fiber
-* transceiver
-*/
- val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
- writel(val, port->base + MVPP2_GMAC_CTRL_0_REG);
-
- /* configure AN 0x9268 */
- val = MVPP2_GMAC_EN_PCS_AN |
- MVPP2_GMAC_AN_BYPASS_EN |
- MVPP2_GMAC_CONFIG_MII_SPEED |
- MVPP2_GMAC_CONFIG_GMII_SPEED |
- MVPP2_GMAC_FC_ADV_EN|
- MVPP2_GMAC_CONFIG_FULL_DUPLEX |
- MVPP2_GMAC_CHOOSE_SAMPLE_TX_CONFIG;
- writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
-}
-
static void gop_gmac_sgmii_cfg(struct mvpp2_port *port)
{
u32 val, thresh;
@@ -3239,9 +3195,6 @@ static int gop_gmac_mode_cfg(struct mvpp2_port *port)
case PHY_INTERFACE_MODE_SGMII:
gop_gmac_sgmii_cfg(port);
break;
- case PHY_INTERFACE_MODE_SGMII_2500:
- gop_gmac_sgmii2_5_cfg(port);
- break;
case PHY_INTERFACE_MODE_1000BASEX:
gop_gmac_1000basex_cfg(port);
break;
@@ -3422,7 +3375,6 @@ static int gop_port_init(struct mvpp2_port *port)
break;
case PHY_INTERFACE_MODE_SGMII:
- case PHY_INTERFACE_MODE_SGMII_2500:
case PHY_INTERFACE_MODE_1000BASEX:
case PHY_INTERFACE_MODE_2500BASEX:
/* configure PCS */
@@ -3482,7 +3434,6 @@ static void gop_port_enable(struct mvpp2_port *port, int
enable)
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_SGMII:
- case PHY_INTERFACE_MODE_SGMII_2500:
case PHY_INTERFACE_MODE_1000BASEX:
case PHY_INTERFACE_MODE_2500BASEX:
if (enable)
@@ -3519,7 +3470,6 @@ static u32 mvpp2_netc_cfg_create(int gop_id,
phy_interface_t phy_type)
if (gop_id == 2) {
if (phy_type == PHY_INTERFACE_MODE_SGMII ||
- phy_type == PHY_INTERFACE_MODE_SGMII_2500 ||
phy_type == PHY_INTERFACE_MODE_1000BASEX ||
phy_type == PHY_INTERFACE_MODE_2500BASEX)
val |= MV_NETC_GE_MAC2_SGMII;
@@ -3530,7 +3480,6 @@ static u32
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > On Mon, 20 Mar 2023 at 21:33, Pali Rohár wrote: > > > On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár wrote: > > > > > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > > > On Sun, 5 Mar 2023 at 11:55, 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. > > > > > > > > > > > > > > > > > > > > > > I tested using the latest next branch which has those changes in > > it. > > > > > Steps: > > > > > > > - Set UART boot mode on device > > > > > > > - make clean > > > > > > > - make clearfog_defconfig > > > > > > > - make > > > > > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > > > > Detected kwbimage v1 with SDIO boot signature > > > > > > > Patching image boot signature to UART > > > > > > > Aligning image header to Xmodem block size > > > > > > > Sending boot message. Please reboot the target...\ > > > > > > > Sending boot image header (113408 bytes)... > > > > > > > 0 % > > > > > > > > > > > > > > [..] > > > > > > > > > > > > > > 94 %
Re: [PATCH] serial: zynqmp: Fetch baudrate from dtb and update
On Tue, Mar 14, 2023 at 02:16:27PM +0530, Venkatesh Yadav Abbarapu wrote:
> From: Algapally Santosh Sagar
>
> The baudrate configured in .config is taken by default by serial. If
> change of baudrate is required then the .config needs to changed and
> u-boot recompilation is required or the u-boot environment needs to be
> updated.
>
> To avoid this, support is added to fetch the baudrate directly from the
> device tree file and update.
> The serial, prints the log with the configured baudrate in the dtb.
> The commit c4df0f6f315c ("arm: mvebu: Espressobin: Set default value for
> $fdtfile env variable") is taken as reference for changing the default
> environment variable.
>
> The default environment stores the default baudrate value, When default
> baudrate and dtb baudrate are not same glitches are seen on the serial.
> So, the environment also needs to be updated with the dtb baudrate to
> avoid the glitches on the serial.
>
> Signed-off-by: Algapally Santosh Sagar
> Signed-off-by: Venkatesh Yadav Abbarapu
> ---
> drivers/serial/Kconfig | 8 +++
> drivers/serial/serial-uclass.c | 32 ++
> include/configs/xilinx_zynqmp.h | 10 -
> include/fdtdec.h| 8 +++
> include/serial.h| 1 +
> lib/fdtdec.c| 40 +
> 6 files changed, 98 insertions(+), 1 deletion(-)
Conceptually? OK.
Implementation? So, this relies on DEFAULT_ENV_IS_RW but that's not in
Kconfig. I think it's an easy enough option to move to Kconfig and
select when needed (first by armada-37xx platforms, then when
SERIAL_DT_BAUD is set).
Then:
> diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
> index 011f0034c5..79d0a2a214 100644
> --- a/include/configs/xilinx_zynqmp.h
> +++ b/include/configs/xilinx_zynqmp.h
> @@ -15,6 +15,13 @@
> #define GICC_BASE0xF902
>
> /* Serial setup */
> +#if CONFIG_IS_ENABLED(SERIAL_DT_BAUD)
This would end up not patching in SPL, so just #ifdef.
> +#define DEFAULT_ENV_IS_RW
> +#define ENV_RW_FILLER "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
Isn't this two too short?
baudrate=115200 | wc -c
16
And that doesn't include that you need a null at the end. And, since
this is a generic option, we need to go about modifying
include/env_default.h. Given that BAUDRATE is an option, I think we
should go about patching the baudrate entry, and make it be something
like:
#if defined(CONFIG_BAUDRATE) && (CONFIG_BAUDRATE >= 0)
"baudrate=" __stringify(CONFIG_BAUDRATE)"\0"
#ifdef CONFIG_SERIAL_DT_BAUD
... more padding, so that we can extend it up to 800 ...
#endif
#endif
--
Tom
signature.asc
Description: PGP signature
[PATCH 1/3] dm: adc: add iMX93 ADC support
This commit adds driver for iMX93 ADC.
The driver is implemented using driver model and provides
ADC uclass's methods for ADC single channel operations:
- adc_start_channel()
- adc_channel_data()
- adc_stop()
ADC features:
- channels: 4
- resolution: 12-bit
Signed-off-by: Luca Ellero
---
drivers/adc/Kconfig | 8 ++
drivers/adc/Makefile| 1 +
drivers/adc/imx93-adc.c | 290
3 files changed, 299 insertions(+)
create mode 100644 drivers/adc/imx93-adc.c
diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
index e719c38bb3..4336732dee 100644
--- a/drivers/adc/Kconfig
+++ b/drivers/adc/Kconfig
@@ -63,3 +63,11 @@ config STM32_ADC
- core driver to deal with common resources
- child driver to deal with individual ADC resources (declare ADC
device and associated channels, start/stop conversions)
+
+config ADC_IMX93
+ bool "Enable NXP IMX93 ADC driver"
+ help
+ This enables basic driver for NXP IMX93 ADC.
+ It provides:
+ - 4 analog input channels
+ - 12-bit resolution
diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
index c1387f3a34..5336c82097 100644
--- a/drivers/adc/Makefile
+++ b/drivers/adc/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_ADC_SANDBOX) += sandbox.o
obj-$(CONFIG_SARADC_ROCKCHIP) += rockchip-saradc.o
obj-$(CONFIG_SARADC_MESON) += meson-saradc.o
obj-$(CONFIG_STM32_ADC) += stm32-adc.o stm32-adc-core.o
+obj-$(CONFIG_ADC_IMX93) += imx93-adc.o
diff --git a/drivers/adc/imx93-adc.c b/drivers/adc/imx93-adc.c
new file mode 100644
index 00..41d04e0426
--- /dev/null
+++ b/drivers/adc/imx93-adc.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 ASEM Srl
+ * Author: Luca Ellero
+ *
+ * Originally based on NXP linux-imx kernel v5.15 drivers/iio/adc/imx93_adc.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IMX93_ADC_MCR 0x00
+#define IMX93_ADC_MSR 0x04
+#define IMX93_ADC_ISR 0x10
+#define IMX93_ADC_IMR 0x20
+#define IMX93_ADC_CIMR00x24
+#define IMX93_ADC_CTR0 0x94
+#define IMX93_ADC_NCMR00xA4
+#define IMX93_ADC_PCDR00x100
+#define IMX93_ADC_PCDR10x104
+#define IMX93_ADC_PCDR20x108
+#define IMX93_ADC_PCDR30x10c
+#define IMX93_ADC_PCDR40x110
+#define IMX93_ADC_PCDR50x114
+#define IMX93_ADC_PCDR60x118
+#define IMX93_ADC_PCDR70x11c
+#define IMX93_ADC_CALSTAT 0x39C
+
+#define IMX93_ADC_MCR_MODE_MASKBIT(29)
+#define IMX93_ADC_MCR_NSTART_MASK BIT(24)
+#define IMX93_ADC_MCR_CALSTART_MASKBIT(14)
+#define IMX93_ADC_MCR_ADCLKSE_MASK BIT(8)
+#define IMX93_ADC_MCR_PWDN_MASKBIT(0)
+
+#define IMX93_ADC_MSR_CALFAIL_MASK BIT(30)
+#define IMX93_ADC_MSR_CALBUSY_MASK BIT(29)
+#define IMX93_ADC_MSR_ADCSTATUS_MASK GENMASK(2, 0)
+
+#define IMX93_ADC_ISR_EOC_MASK BIT(1)
+
+#define IMX93_ADC_IMR_EOC_MASK BIT(1)
+#define IMX93_ADC_IMR_ECH_MASK BIT(0)
+
+#define IMX93_ADC_PCDR_CDATA_MASK GENMASK(11, 0)
+
+#define IDLE 0
+#define POWER_DOWN 1
+#define WAIT_STATE 2
+#define BUSY_IN_CALIBRATION3
+#define SAMPLE 4
+#define CONVERSION 6
+
+#define IMX93_ADC_MAX_CHANNEL 3
+#define IMX93_ADC_DAT_MASK 0xfff
+#define IMX93_ADC_TIMEOUT 10
+
+struct imx93_adc_priv {
+ int active_channel;
+ void __iomem *regs;
+ struct clk ipg_clk;
+};
+
+static void imx93_adc_power_down(struct imx93_adc_priv *adc)
+{
+ u32 mcr, msr;
+ int ret;
+
+ mcr = readl(adc->regs + IMX93_ADC_MCR);
+ mcr |= FIELD_PREP(IMX93_ADC_MCR_PWDN_MASK, 1);
+ writel(mcr, adc->regs + IMX93_ADC_MCR);
+
+ ret = readl_poll_timeout(adc->regs + IMX93_ADC_MSR, msr,
+ ((msr & IMX93_ADC_MSR_ADCSTATUS_MASK) == POWER_DOWN), 50);
+ if (ret == -ETIMEDOUT)
+ pr_warn("ADC not in power down mode, current MSR: %x\n", msr);
+}
+
+static void imx93_adc_power_up(struct imx93_adc_priv *adc)
+{
+ u32 mcr;
+
+ /* bring ADC out of power down state, in idle state */
+ mcr = readl(adc->regs + IMX93_ADC_MCR);
+ mcr &= ~FIELD_PREP(IMX93_ADC_MCR_PWDN_MASK, 1);
+ writel(mcr, adc->regs + IMX93_ADC_MCR);
+}
+
+static void imx93_adc_config_ad_clk(struct imx93_adc_priv *adc)
+{
+ u32 mcr;
+
+ /* put adc in power down mode */
+ imx93_adc_power_down(adc);
+
+ /* config the AD_CLK equal to bus clock */
+ mcr = readl(adc->regs + IMX93_ADC_MCR);
+ mcr |=
[PATCH 3/3] imx93_evk: defconfig: add adc support
iMX93 ADC features: - 4 channels - 12 bit resolution Signed-off-by: Luca Ellero --- configs/imx93_11x11_evk_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/imx93_11x11_evk_defconfig b/configs/imx93_11x11_evk_defconfig index 477fb25807..fa929dd4ec 100644 --- a/configs/imx93_11x11_evk_defconfig +++ b/configs/imx93_11x11_evk_defconfig @@ -82,6 +82,7 @@ CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_DM=y CONFIG_REGMAP=y CONFIG_SYSCON=y +CONFIG_ADC_IMX93=y CONFIG_IMX_RGPIO2P=y CONFIG_DM_PCA953X=y CONFIG_DM_I2C=y -- 2.25.1
[PATCH 2/3] imx93_evk: add adc node to dts file
This node uses imx93_adc driver under drivers/adc.
The node is added keeping dts file in sync with iMX9 evk Linux
devicetree.
Signed-off-by: Luca Ellero
---
arch/arm/dts/imx93-11x11-evk.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/imx93-11x11-evk.dts b/arch/arm/dts/imx93-11x11-evk.dts
index b3a5a3d71e..91f99cebae 100644
--- a/arch/arm/dts/imx93-11x11-evk.dts
+++ b/arch/arm/dts/imx93-11x11-evk.dts
@@ -58,6 +58,10 @@
};
+ {
+ status = "okay";
+};
+
{
#address-cells = <1>;
#size-cells = <0>;
--
2.25.1
[PATCH v5 0/3] imx93: add ADC support
Add ADC support for NXP iMX93 Changes for v2: - add "static" to functions - enable ADC in iMX93 EVK Changes for v3: - split in 3 commits - keep dts file in sync with Linux devicetree - add comments to commits Changes for v4: - add imx93_adc_power_down() in imx93_adc_stop() Changes for v5: - simplify code - remove redundant code - add clock handling Luca Ellero (3): dm: adc: add iMX93 ADC support imx93_evk: add adc node to dts file imx93_evk: defconfig: add adc support arch/arm/dts/imx93-11x11-evk.dts | 4 + configs/imx93_11x11_evk_defconfig | 1 + drivers/adc/Kconfig | 8 + drivers/adc/Makefile | 1 + drivers/adc/imx93-adc.c | 290 ++ 5 files changed, 304 insertions(+) create mode 100644 drivers/adc/imx93-adc.c -- 2.25.1
Re: [PATCH v2 01/10] arm: dts: introduce j784s4 dtbs from linux kernel
Hi Hari! On March 21, 2023 thus sayeth Hari Nagalla: > Introduce the basic j784s4 SoC dtbs from the linux kernel along with > the new j784s4 specific pinmux definitions that we will use to generate > the dtbs for the u-boot-spl and u-boot binaries. > We should probably specify which kernel version this is from, just to help our future selves happy. > Signed-off-by: Apurva Nandan > Signed-off-by: Hari Nagalla > --- > arch/arm/dts/k3-j784s4-evm.dts | 196 + > arch/arm/dts/k3-j784s4-main.dtsi | 1007 > arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi | 311 > arch/arm/dts/k3-j784s4.dtsi| 287 +++ > include/dt-bindings/pinctrl/k3.h |3 + > 5 files changed, 1804 insertions(+) > create mode 100644 arch/arm/dts/k3-j784s4-evm.dts > create mode 100644 arch/arm/dts/k3-j784s4-main.dtsi > create mode 100644 arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi > create mode 100644 arch/arm/dts/k3-j784s4.dtsi > ~Bryan
Re: [PULL] u-boot-sh/master
On Mon, Mar 20, 2023 at 11:51:26PM +0100, Marek Vasut wrote: > A single reset controller driver (part of the clock driver) fix > for v2023.04 release. > > The following changes since commit 318af47668aa2347ca9bbf2114cb9af1d8739aca: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-coldfire (2023-03-15 12:03:17 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sh.git master > > for you to fetch changes up to afafaa2a8f3f0ef38fc55c5d830890adb508549f: > > clk: renesas: Pack reset identifier before look up (2023-03-20 02:46:44 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: fat: do not mangle short filenames
On Tue, Mar 21, 2023 at 04:53:22PM +0100, Stefan Herbrechtsmeier wrote: > > Am 21.03.2023 um 16:35 schrieb Tom Rini: > > On Tue, Mar 21, 2023 at 08:43:07AM +0100, Stefan Herbrechtsmeier wrote: > > > Am 20.03.2023 um 18:01 schrieb Tom Rini: > > > > On Fri, Mar 17, 2023 at 01:04:13PM +0100, Stefan Herbrechtsmeier wrote: > > > > > > > > > From: Stefan Herbrechtsmeier > > > > > > > > > > Do not mangle lower or mixed case filenames which fit into the upper > > > > > case 8.3 short filename. This ensures FAT standard compatible short > > > > > filenames (SFN) to support systems without long filename (LFN) support > > > > > like boot roms (ex. SFN BOOT.BIN instead of BOOT~1.BIN for LFN > > > > > boot.bin). > > > > > > > > > > Signed-off-by: Stefan Herbrechtsmeier > > > > > > > > > > > > > > > --- > > > > > > > > > >fs/fat/fat_write.c | 11 +++ > > > > >1 file changed, 7 insertions(+), 4 deletions(-) > > > > Can we update test/py/tests/test_fs/ somewhere to have a test for this > > > > case? Thanks. > > > What is the recommended approach to test internal behavior? The short name > > > isn't avialable at the terminal because u-boot support VFAT. > > Well, you triggered this problem with a filesystem that had contents > > that were "just so" and then didn't work as expected, yes? > > > No, I write a file to a file system and the boot rom do not find the file > because the name was wrong (BOOT~1.BIN instead of BOOT.BIN). > > The mdir command shows the short and long file name. I will add a > test_fat.py with a test. Ah, ok, and great, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: fat: do not mangle short filenames
Am 21.03.2023 um 16:35 schrieb Tom Rini: On Tue, Mar 21, 2023 at 08:43:07AM +0100, Stefan Herbrechtsmeier wrote: Am 20.03.2023 um 18:01 schrieb Tom Rini: On Fri, Mar 17, 2023 at 01:04:13PM +0100, Stefan Herbrechtsmeier wrote: From: Stefan Herbrechtsmeier Do not mangle lower or mixed case filenames which fit into the upper case 8.3 short filename. This ensures FAT standard compatible short filenames (SFN) to support systems without long filename (LFN) support like boot roms (ex. SFN BOOT.BIN instead of BOOT~1.BIN for LFN boot.bin). Signed-off-by: Stefan Herbrechtsmeier --- fs/fat/fat_write.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) Can we update test/py/tests/test_fs/ somewhere to have a test for this case? Thanks. What is the recommended approach to test internal behavior? The short name isn't avialable at the terminal because u-boot support VFAT. Well, you triggered this problem with a filesystem that had contents that were "just so" and then didn't work as expected, yes? No, I write a file to a file system and the boot rom do not find the file because the name was wrong (BOOT~1.BIN instead of BOOT.BIN). The mdir command shows the short and long file name. I will add a test_fat.py with a test. Regards Stefan
Re: [PATCH v2 03/10] arm: K3: Add basic support for J784S4 SoC definition
On Tue, Mar 21, 2023 at 09:10:21AM -0500, Hari Nagalla wrote: Please include at least the usual one line summary here. [snip] > diff --git a/include/configs/j784s4_evm.h b/include/configs/j784s4_evm.h > new file mode 100644 > index 00..3e429fb036 > --- /dev/null > +++ b/include/configs/j784s4_evm.h > @@ -0,0 +1,49 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Configuration header file for K3 J784S4 EVM > + * > + * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ > + * Hari Nagalla > + */ > + > +#ifndef __CONFIG_J784S4_EVM_H > +#define __CONFIG_J784S4_EVM_H > + > +#include > +#include > +#include > + > +/* DDR Configuration */ > +#define CFG_SYS_SDRAM_BASE1 0x88000 > + > +#ifdef CONFIG_CMD_MMC > +#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1) > +#else > +#define DISTRO_BOOT_DEV_MMC(func) > +#endif > + > +#ifdef CONFIG_CMD_PXE > +#define DISTRO_BOOT_DEV_PXE(func) func(PXE, pxe, na) > +#else > +#define DISTRO_BOOT_DEV_PXE(func) > +#endif > + > +#ifdef CONFIG_CMD_DHCP > +#define DISTRO_BOOT_DEV_DHCP(func) func(DHCP, dhcp, na) > +#else > +#define DISTRO_BOOT_DEV_DHCP(func) > +#endif > + > +#define BOOT_TARGET_DEVICES(func) \ > + DISTRO_BOOT_DEV_MMC(func) \ > + DISTRO_BOOT_DEV_PXE(func) \ > + DISTRO_BOOT_DEV_DHCP(func) I think you should look at using BOOTSTD here, to start with, rather than the distro_bootcmd macros. Converting the rest of K3 to use this as well can be a later task. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 02/10] arm: dts: introduce j784s4 u-boot dtbs
On Tue, Mar 21, 2023 at 09:10:20AM -0500, Hari Nagalla wrote:
> Introduce the base dts files needed for u-boot or to augment the linux
> dtbs for use in the u-boot-spl and u-boot binaries.
>
> Signed-off-by: Apurva Nandan
> Signed-off-by: Hari Nagalla
> ---
> arch/arm/dts/Makefile|2 +
> arch/arm/dts/k3-j784s4-ddr-evm-lp4-4266.dtsi | 8757 +
> arch/arm/dts/k3-j784s4-ddr.dtsi | 8858 ++
> arch/arm/dts/k3-j784s4-evm-u-boot.dtsi | 135 +
> arch/arm/dts/k3-j784s4-r5-evm.dts| 209 +
> 5 files changed, 17961 insertions(+)
> create mode 100644 arch/arm/dts/k3-j784s4-ddr-evm-lp4-4266.dtsi
> create mode 100644 arch/arm/dts/k3-j784s4-ddr.dtsi
> create mode 100644 arch/arm/dts/k3-j784s4-evm-u-boot.dtsi
> create mode 100644 arch/arm/dts/k3-j784s4-r5-evm.dts
Good news/bad news.
[snip]
> + msmc0: msmc {
[snip]
> + u-boot,dm-spl;
This is now "bootph-pre-ram" and gets sent upstream to Linux, as the
binding is there now. Please do that and then rework the first patch to
be a sync from -next or similar, that contains these changes.
And yes, this is the first example I found of properties that should be
bootph-* now instead, and there's some bindings you have in-progress and
so yes, will include these for now in the -u-boot.dtsi file. But others
don't, and this needs to be on top of -next and CI passing.
--
Tom
signature.asc
Description: PGP signature
Re: Pull request: u-boot-rockchip-20230319
On Sun, Mar 19, 2023 at 02:52:22PM +0800, Kever Yang wrote: > Hi Tom, > > Please pull the fixes for rockchip platform: > - Fix for rockchip timer driver; > - Fix for rk3568 and rk3588 boot device and clock driver; > - Fix for rk3568 reset handler; > - Fix for rk3568 sdhci DLL at 52MHz; > > CI: > https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/15648 > > Thanks, > - Kever > > The following changes since commit 318af47668aa2347ca9bbf2114cb9af1d8739aca: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-coldfire (2023-03-15 12:03:17 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20230319 > > for you to fetch changes up to d35a1392c5d17e067d16b7b096565b16af495f34: > > arm: dts: rockchip: rk3188-radxarock-u-boot: remove timer compatible > replacement (2023-03-19 14:12:01 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/next
On Sat, Mar 18, 2023 at 05:52:50PM +0100, Marek Vasut wrote: > The following changes since commit cefd0449d6df77eb0edb8a6800a441f9cd4e3653: > > Merge tag 'xilinx-for-v2023.07-rc1' of > https://source.denx.de/u-boot/custodians/u-boot-microblaze into next > (2023-03-16 12:18:30 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sh.git next > > for you to fetch changes up to 6254c5f7e176311eb8bd57817f85d1eed1c362cb: > > serial: sh: Make indent consistent (2023-03-18 12:04:02 +0100) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: fat: do not mangle short filenames
On Tue, Mar 21, 2023 at 08:43:07AM +0100, Stefan Herbrechtsmeier wrote: > Am 20.03.2023 um 18:01 schrieb Tom Rini: > > On Fri, Mar 17, 2023 at 01:04:13PM +0100, Stefan Herbrechtsmeier wrote: > > > > > From: Stefan Herbrechtsmeier > > > > > > Do not mangle lower or mixed case filenames which fit into the upper > > > case 8.3 short filename. This ensures FAT standard compatible short > > > filenames (SFN) to support systems without long filename (LFN) support > > > like boot roms (ex. SFN BOOT.BIN instead of BOOT~1.BIN for LFN > > > boot.bin). > > > > > > Signed-off-by: Stefan Herbrechtsmeier > > > > > > > > > --- > > > > > > fs/fat/fat_write.c | 11 +++ > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > Can we update test/py/tests/test_fs/ somewhere to have a test for this > > case? Thanks. > > What is the recommended approach to test internal behavior? The short name > isn't avialable at the terminal because u-boot support VFAT. Well, you triggered this problem with a filesystem that had contents that were "just so" and then didn't work as expected, yes? -- Tom signature.asc Description: PGP signature
Re: [PATCH] include: configs: am65x_evm: Change to using .env
On Tue, Mar 21, 2023 at 06:23:30PM +0530, Nikhil M Jain wrote: > Move to using .env file for setting up environment variables for am65x. > > Signed-off-by: Nikhil M Jain Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] fdt: Make fdt addr -q quieter
On 3/21/23 14:01, Peter Hoyes wrote: From: Peter Hoyes 64597346 "fdt: Add -q option to fdt addr for distro_bootcmd" introduced the -q option for fdt addr, which sets the current working fdt address without printing any output. baf41410 "fdt: Show a message when the working FDT changes" made the utility function set_working_fdt_addr (in cmd/fdt.c) output a message on each invocation, even if called via fdt addr -q, in which case its output is now slightly noisier. To fix this, split out set_working_fdt_addr into set_working_fdt_addr plus the static function set_working_fdt_addr_quiet. set_working_fdt_addr_quiet can be called by "quiet" fdt cmd logic and set_working_fdt_addr is exported (as before) to other boot logic. The latter calls the former. Remove the assertion from the fdt addr test case when calling with the -q argument. Signed-off-by: Peter Hoyes Reviewed-by: Marek Vasut Thanks !
Re: [PATCH] serial: zynqmp: Fetch baudrate from dtb and update
Hi Simon and Tom,
On 3/14/23 09:46, Venkatesh Yadav Abbarapu wrote:
From: Algapally Santosh Sagar
The baudrate configured in .config is taken by default by serial. If
change of baudrate is required then the .config needs to changed and
u-boot recompilation is required or the u-boot environment needs to be
updated.
To avoid this, support is added to fetch the baudrate directly from the
device tree file and update.
The serial, prints the log with the configured baudrate in the dtb.
The commit c4df0f6f315c ("arm: mvebu: Espressobin: Set default value for
$fdtfile env variable") is taken as reference for changing the default
environment variable.
The default environment stores the default baudrate value, When default
baudrate and dtb baudrate are not same glitches are seen on the serial.
So, the environment also needs to be updated with the dtb baudrate to
avoid the glitches on the serial.
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Venkatesh Yadav Abbarapu
I reviewed this patch internally and would like to get your opinion about it.
The problematic part is around ENV_RW_FILLER that's why I want to make sure that
the patch is going in the right direction.
Thanks,
Michal
Re: [PATCH] configs: am62ax: enable secure device configs by default
Bryan Brattlof writes: > TI's security enforcing SoCs will authenticate each binary it loads by > comparing it's signature with keys etched into the SoC during the boot > up process. The am62ax family of SoCs by default will have some level of > security enforcement checking. To keep things as simple as possible, > enable the CONFIG_TI_SECURE_DEVICE options by default so all levels of > secure SoCs will work out of the box > > Enable the CONFIG_TI_SECURE_DEVICE by default > > Signed-off-by: Bryan Brattlof Reviewed-by: Kamlesh Gurudasani
Re: [PATCH 01/41] net: phy: aquantia: Staticize PHY driver entries
Hi, On 3/19/23 18:02, Marek Vasut wrote: These struct phy_driver ... instances are local to this source code file, staticize them. No functional change. Signed-off-by: Marek Vasut --- Cc: "Ariel D'Alessandro" Cc: "Cédric Le Goater" Cc: "Marek Behún" Cc: Alex Nemirovsky Cc: Haolin Li Cc: Heinrich Schuchardt Cc: Joe Hershberger Cc: Joel Stanley Cc: Josua Mayer Cc: Marek Vasut Cc: Michael Trimarchi Cc: Michal Simek Cc: Nate Drude Cc: Neil Armstrong Cc: Radu Pirea Cc: Ramon Fried Cc: Samuel Mendoza-Jonas Cc: Stefan Roese Cc: T Karthik Reddy Cc: Tim Harvey Cc: Vladimir Oltean Cc: u-boot-amlo...@groups.io --- drivers/net/phy/aquantia.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) Would be good if you also create cover letter which I can reply. I have tested this series on Microblaze which is also using MANUAL relocation (but we are removing it from 2023.07 release) and it is working fine. I also went over all these patches and changes look good to me. That's why for all patches feel free to add Acked-by: Michal Simek Tested-by: Michal Simek #microblaze (MANUAL_RELOC) Thanks, Michal
Re: [PATCH v2 03/10] arm: K3: Add basic support for J784S4 SoC definition
On 3/21/23 9:10 AM, Hari Nagalla wrote: Signed-off-by: Apurva Nandan Signed-off-by: Bryan Bratloff Signed-off-by: Nishant Menon Signed-off-by: Hari Nagalla --- arch/arm/mach-k3/Kconfig | 16 +- arch/arm/mach-k3/Makefile | 2 + arch/arm/mach-k3/arm64-mmu.c | 41 +++ arch/arm/mach-k3/include/mach/hardware.h | 4 + .../mach-k3/include/mach/j784s4_hardware.h| 41 +++ arch/arm/mach-k3/include/mach/j784s4_spl.h| 46 +++ arch/arm/mach-k3/include/mach/spl.h | 6 +- arch/arm/mach-k3/j784s4/Makefile | 5 + arch/arm/mach-k3/j784s4/dev-data.c| 97 ++ arch/arm/mach-k3/j784s4_init.c| 319 ++ board/ti/j784s4/j784s4.env| 108 ++ include/configs/j784s4_evm.h | 49 +++ 12 files changed, 727 insertions(+), 7 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/j784s4_hardware.h create mode 100644 arch/arm/mach-k3/include/mach/j784s4_spl.h create mode 100644 arch/arm/mach-k3/j784s4/Makefile create mode 100644 arch/arm/mach-k3/j784s4/dev-data.c create mode 100644 arch/arm/mach-k3/j784s4_init.c create mode 100644 board/ti/j784s4/j784s4.env create mode 100644 include/configs/j784s4_evm.h diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index a8c3a593d5..3a9be0a590 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -22,6 +22,9 @@ config SOC_K3_AM625 config SOC_K3_AM62A7 bool "TI's K3 based AM62A7 SoC Family Support" +config SOC_K3_J784S4 + bool "TI's K3 based J784S4 SoC Family Support" + endchoice config SYS_SOC @@ -30,7 +33,7 @@ config SYS_SOC config SYS_K3_NON_SECURE_MSRAM_SIZE hex default 0x8 if SOC_K3_AM654 - default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 + default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default 0x1c if SOC_K3_AM642 default 0x3c000 if SOC_K3_AM625 || SOC_K3_AM62A7 help @@ -42,7 +45,7 @@ config SYS_K3_NON_SECURE_MSRAM_SIZE config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE hex default 0x58000 if SOC_K3_AM654 - default 0xc if SOC_K3_J721E || SOC_K3_J721S2 + default 0xc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default 0x18 if SOC_K3_AM642 default 0x38000 if SOC_K3_AM625 || SOC_K3_AM62A7 help @@ -52,14 +55,14 @@ 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_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 help Describes the base address of MCU Scratchpad RAM. config SYS_K3_MCU_SCRATCHPAD_SIZE hex default 0x200 if SOC_K3_AM654 - default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 + default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 help Describes the size of MCU Scratchpad RAM. @@ -67,7 +70,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX hex default 0x41c7fbfc if SOC_K3_AM654 default 0x41cffbfc if SOC_K3_J721E - default 0x41cfdbfc if SOC_K3_J721S2 + default 0x41cfdbfc if SOC_K3_J721S2 || SOC_K3_J784S4 default 0x701bebfc if SOC_K3_AM642 default 0x43c3f290 if SOC_K3_AM625 default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R @@ -172,7 +175,7 @@ config K3_ATF_LOAD_ADDR config K3_DM_FW bool "Separate DM firmware image" - depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN + depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7 || SOC_K3_J784S4) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN default y help Enabling this will indicate that the system has separate DM @@ -194,4 +197,5 @@ source "board/ti/am62ax/Kconfig" source "board/ti/j721e/Kconfig" source "board/siemens/iot2050/Kconfig" source "board/ti/j721s2/Kconfig" +source "board/ti/j784s4/Kconfig" endif diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile index b5bc236781..14cf85ad38 100644 --- a/arch/arm/mach-k3/Makefile +++ b/arch/arm/mach-k3/Makefile @@ -7,6 +7,7 @@ obj-$(CONFIG_SOC_K3_J721E) += j721e/ j7200/ obj-$(CONFIG_SOC_K3_J721S2) += j721s2/ obj-$(CONFIG_SOC_K3_AM625) += am62x/ obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/ +obj-$(CONFIG_SOC_K3_J784S4) += j784s4/ obj-$(CONFIG_ARM64) += arm64-mmu.o obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o obj-$(CONFIG_ARM64) += cache.o @@ -17,6 +18,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o obj-$(CONFIG_SOC_K3_AM642) += am642_init.o obj-$(CONFIG_SOC_K3_AM625) += am625_init.o obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o +obj-$(CONFIG_SOC_K3_J784S4) += j784s4_init.o
[PATCH v2 05/10] clk: clk-k3: Add support for J784S4 SoC
Add support for J784S4 SoC.
Signed-off-by: Apurva Nandan
Signed-off-by: Hari Nagalla
---
arch/arm/mach-k3/j784s4/clk-data.c | 428 +
drivers/clk/ti/clk-k3.c| 6 +
include/k3-clk.h | 1 +
3 files changed, 435 insertions(+)
create mode 100644 arch/arm/mach-k3/j784s4/clk-data.c
diff --git a/arch/arm/mach-k3/j784s4/clk-data.c
b/arch/arm/mach-k3/j784s4/clk-data.c
new file mode 100644
index 00..1c9f0698ea
--- /dev/null
+++ b/arch/arm/mach-k3/j784s4/clk-data.c
@@ -0,0 +1,428 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * J784S4 specific clock platform data
+ *
+ * This file is auto generated. Please do not hand edit and report any issues
+ * to Bryan Brattlof .
+ *
+ * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include
+#include "k3-clk.h"
+
+static const char * const gluelogic_hfosc0_clkout_parents[] = {
+ "osc_19_2_mhz",
+ "osc_20_mhz",
+ "osc_24_mhz",
+ "osc_25_mhz",
+ "osc_26_mhz",
+ "osc_27_mhz",
+};
+
+static const char * const mcu_ospi0_iclk_sel_out0_parents[] = {
+ "board_0_mcu_ospi0_dqs_out",
+ "fss_mcu_0_ospi_0_ospi_oclk_clk",
+};
+
+static const char * const mcu_ospi1_iclk_sel_out0_parents[] = {
+ "board_0_mcu_ospi1_dqs_out",
+ "fss_mcu_0_ospi_1_ospi_oclk_clk",
+};
+
+static const char * const wkup_fref_clksel_out0_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "j7am_wakeup_16ff_wkup_0_wkup_rcosc_12p5m_clk",
+};
+
+static const char * const k3_pll_ctrl_wrap_wkup_0_sysclkout_clk_parents[] = {
+ "wkup_fref_clksel_out0",
+ "hsdiv1_16fft_mcu_0_hsdivout0_clk",
+};
+
+static const char * const mcu_ospi_ref_clk_sel_out0_parents[] = {
+ "hsdiv4_16fft_mcu_1_hsdivout4_clk",
+ "hsdiv4_16fft_mcu_2_hsdivout4_clk",
+};
+
+static const char * const mcu_ospi_ref_clk_sel_out1_parents[] = {
+ "hsdiv4_16fft_mcu_1_hsdivout4_clk",
+ "hsdiv4_16fft_mcu_2_hsdivout4_clk",
+};
+
+static const char * const wkup_gpio0_clksel_out0_parents[] = {
+ "k3_pll_ctrl_wrap_wkup_0_chip_div1_clk_clk",
+ "k3_pll_ctrl_wrap_wkup_0_chip_div1_clk_clk",
+ "j7am_wakeup_16ff_wkup_0_wkup_rcosc_32k_clk",
+ "j7am_wakeup_16ff_wkup_0_wkup_rcosc_12p5m_clk",
+};
+
+static const char * const mcu_usart_clksel_out0_parents[] = {
+ "hsdiv4_16fft_mcu_1_hsdivout3_clk",
+ "postdiv3_16fft_main_1_hsdivout5_clk",
+};
+
+static const char * const wkup_i2c_mcupll_bypass_out0_parents[] = {
+ "hsdiv4_16fft_mcu_1_hsdivout3_clk",
+ "gluelogic_hfosc0_clkout",
+};
+
+static const char * const main_pll_hfosc_sel_out0_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out1_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out12_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out19_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out2_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out26_0_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out27_0_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out28_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out3_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out7_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out8_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const usb0_refclk_sel_out0_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "board_0_hfosc1_clk_out",
+};
+
+static const char * const emmcsd1_lb_clksel_out0_parents[] = {
+ "board_0_mmc1_clklb_out",
+ "board_0_mmc1_clk_out",
+};
+
+static const char * const mcu_clkout_mux_out0_parents[] = {
+ "hsdiv4_16fft_mcu_2_hsdivout0_clk",
+ "hsdiv4_16fft_mcu_2_hsdivout0_clk",
+};
+
+static const char * const k3_pll_ctrl_wrap_main_0_sysclkout_clk_parents[] = {
+ "main_pll_hfosc_sel_out0",
+ "hsdiv4_16fft_main_0_hsdivout0_clk",
+};
+
+static const char * const dpi0_ext_clksel_out0_parents[] = {
+ "hsdiv1_16fft_main_19_hsdivout0_clk",
+ "board_0_vout0_extpclkin_out",
+};
+
+static const char * const emmcsd_refclk_sel_out0_parents[] = {
+
[PATCH v2 01/10] arm: dts: introduce j784s4 dtbs from linux kernel
Introduce the basic j784s4 SoC dtbs from the linux kernel along with
the new j784s4 specific pinmux definitions that we will use to generate
the dtbs for the u-boot-spl and u-boot binaries.
Signed-off-by: Apurva Nandan
Signed-off-by: Hari Nagalla
---
arch/arm/dts/k3-j784s4-evm.dts | 196 +
arch/arm/dts/k3-j784s4-main.dtsi | 1007
arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi | 311
arch/arm/dts/k3-j784s4.dtsi| 287 +++
include/dt-bindings/pinctrl/k3.h |3 +
5 files changed, 1804 insertions(+)
create mode 100644 arch/arm/dts/k3-j784s4-evm.dts
create mode 100644 arch/arm/dts/k3-j784s4-main.dtsi
create mode 100644 arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi
create mode 100644 arch/arm/dts/k3-j784s4.dtsi
diff --git a/arch/arm/dts/k3-j784s4-evm.dts b/arch/arm/dts/k3-j784s4-evm.dts
new file mode 100644
index 00..8cd4a7ecc1
--- /dev/null
+++ b/arch/arm/dts/k3-j784s4-evm.dts
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ *
+ * EVM Board Schematics: https://www.ti.com/lit/zip/sprr458
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "k3-j784s4.dtsi"
+
+/ {
+ compatible = "ti,j784s4-evm", "ti,j784s4";
+ model = "Texas Instruments J784S4 EVM";
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ aliases {
+ serial2 = _uart8;
+ mmc1 = _sdhci1;
+ i2c0 = _i2c0;
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ /* 32G RAM */
+ reg = <0x00 0x8000 0x00 0x8000>,
+ <0x08 0x8000 0x07 0x8000>;
+ };
+
+ reserved_memory: reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_ddr: optee@9e80 {
+ reg = <0x00 0x9e80 0x00 0x0180>;
+ no-map;
+ };
+ };
+
+ evm_12v0: regulator-evm12v0 {
+ /* main supply */
+ compatible = "regulator-fixed";
+ regulator-name = "evm_12v0";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vsys_3v3: regulator-vsys3v3 {
+ /* Output of LM5140 */
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <_12v0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vsys_5v0: regulator-vsys5v0 {
+ /* Output of LM5140 */
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_5v0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_12v0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_mmc1: regulator-sd {
+ /* Output of TPS22918 */
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_mmc1";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ enable-active-high;
+ vin-supply = <_3v3>;
+ gpio = < 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ vdd_sd_dv: regulator-TLV71033 {
+ /* Output of TLV71033 */
+ compatible = "regulator-gpio";
+ regulator-name = "tlv71033";
+ pinctrl-names = "default";
+ pinctrl-0 = <_sd_dv_pins_default>;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ vin-supply = <_5v0>;
+ gpios = <_gpio0 8 GPIO_ACTIVE_HIGH>;
+ states = <180 0x0>,
+<330 0x1>;
+ };
+};
+
+_pmx0 {
+ main_uart8_pins_default: main-uart8-pins-default {
+ pinctrl-single,pins = <
+ J784S4_IOPAD(0x040, PIN_INPUT, 14) /* (AF37)
MCASP0_AXR0.UART8_CTSn */
+ J784S4_IOPAD(0x044, PIN_OUTPUT, 14) /* (AG37)
MCASP0_AXR1.UART8_RTSn */
+ J784S4_IOPAD(0x0d0, PIN_INPUT, 11) /* (AP38)
SPI0_CS1.UART8_RXD */
+ J784S4_IOPAD(0x0d4, PIN_OUTPUT, 11) /* (AN38)
SPI0_CLK.UART8_TXD */
+ >;
+ };
+
+ main_i2c0_pins_default: main-i2c0-pins-default {
+ pinctrl-single,pins = <
+ J784S4_IOPAD(0x0e0, PIN_INPUT_PULLUP, 0) /* (AN36)
I2C0_SCL */
+
[PATCH v2 03/10] arm: K3: Add basic support for J784S4 SoC definition
Signed-off-by: Apurva Nandan Signed-off-by: Bryan Bratloff Signed-off-by: Nishant Menon Signed-off-by: Hari Nagalla --- arch/arm/mach-k3/Kconfig | 16 +- arch/arm/mach-k3/Makefile | 2 + arch/arm/mach-k3/arm64-mmu.c | 41 +++ arch/arm/mach-k3/include/mach/hardware.h | 4 + .../mach-k3/include/mach/j784s4_hardware.h| 41 +++ arch/arm/mach-k3/include/mach/j784s4_spl.h| 46 +++ arch/arm/mach-k3/include/mach/spl.h | 6 +- arch/arm/mach-k3/j784s4/Makefile | 5 + arch/arm/mach-k3/j784s4/dev-data.c| 97 ++ arch/arm/mach-k3/j784s4_init.c| 319 ++ board/ti/j784s4/j784s4.env| 108 ++ include/configs/j784s4_evm.h | 49 +++ 12 files changed, 727 insertions(+), 7 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/j784s4_hardware.h create mode 100644 arch/arm/mach-k3/include/mach/j784s4_spl.h create mode 100644 arch/arm/mach-k3/j784s4/Makefile create mode 100644 arch/arm/mach-k3/j784s4/dev-data.c create mode 100644 arch/arm/mach-k3/j784s4_init.c create mode 100644 board/ti/j784s4/j784s4.env create mode 100644 include/configs/j784s4_evm.h diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index a8c3a593d5..3a9be0a590 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -22,6 +22,9 @@ config SOC_K3_AM625 config SOC_K3_AM62A7 bool "TI's K3 based AM62A7 SoC Family Support" +config SOC_K3_J784S4 + bool "TI's K3 based J784S4 SoC Family Support" + endchoice config SYS_SOC @@ -30,7 +33,7 @@ config SYS_SOC config SYS_K3_NON_SECURE_MSRAM_SIZE hex default 0x8 if SOC_K3_AM654 - default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 + default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default 0x1c if SOC_K3_AM642 default 0x3c000 if SOC_K3_AM625 || SOC_K3_AM62A7 help @@ -42,7 +45,7 @@ config SYS_K3_NON_SECURE_MSRAM_SIZE config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE hex default 0x58000 if SOC_K3_AM654 - default 0xc if SOC_K3_J721E || SOC_K3_J721S2 + default 0xc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default 0x18 if SOC_K3_AM642 default 0x38000 if SOC_K3_AM625 || SOC_K3_AM62A7 help @@ -52,14 +55,14 @@ 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_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 help Describes the base address of MCU Scratchpad RAM. config SYS_K3_MCU_SCRATCHPAD_SIZE hex default 0x200 if SOC_K3_AM654 - default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 + default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 help Describes the size of MCU Scratchpad RAM. @@ -67,7 +70,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX hex default 0x41c7fbfc if SOC_K3_AM654 default 0x41cffbfc if SOC_K3_J721E - default 0x41cfdbfc if SOC_K3_J721S2 + default 0x41cfdbfc if SOC_K3_J721S2 || SOC_K3_J784S4 default 0x701bebfc if SOC_K3_AM642 default 0x43c3f290 if SOC_K3_AM625 default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R @@ -172,7 +175,7 @@ config K3_ATF_LOAD_ADDR config K3_DM_FW bool "Separate DM firmware image" - depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN + depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7 || SOC_K3_J784S4) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN default y help Enabling this will indicate that the system has separate DM @@ -194,4 +197,5 @@ source "board/ti/am62ax/Kconfig" source "board/ti/j721e/Kconfig" source "board/siemens/iot2050/Kconfig" source "board/ti/j721s2/Kconfig" +source "board/ti/j784s4/Kconfig" endif diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile index b5bc236781..14cf85ad38 100644 --- a/arch/arm/mach-k3/Makefile +++ b/arch/arm/mach-k3/Makefile @@ -7,6 +7,7 @@ obj-$(CONFIG_SOC_K3_J721E) += j721e/ j7200/ obj-$(CONFIG_SOC_K3_J721S2) += j721s2/ obj-$(CONFIG_SOC_K3_AM625) += am62x/ obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/ +obj-$(CONFIG_SOC_K3_J784S4) += j784s4/ obj-$(CONFIG_ARM64) += arm64-mmu.o obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o obj-$(CONFIG_ARM64) += cache.o @@ -17,6 +18,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o obj-$(CONFIG_SOC_K3_AM642) += am642_init.o obj-$(CONFIG_SOC_K3_AM625) += am625_init.o obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o +obj-$(CONFIG_SOC_K3_J784S4) += j784s4_init.o obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o endif obj-y += common.o security.o diff --git
[PATCH v2 07/10] ram: k3-ddrss: Add support for J784S4 SoC
Add support for DDR subsystem in J784S4 SoC. Signed-off-by: Apurva Nandan Signed-off-by: Hari Nagalla --- drivers/ram/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig index e085119963..fac8c9314b 100644 --- a/drivers/ram/Kconfig +++ b/drivers/ram/Kconfig @@ -62,7 +62,7 @@ choice depends on K3_DDRSS prompt "K3 DDRSS Arch Support" - default K3_J721E_DDRSS if SOC_K3_J721E || SOC_K3_J721S2 + default K3_J721E_DDRSS if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default K3_AM64_DDRSS if SOC_K3_AM642 default K3_AM64_DDRSS if SOC_K3_AM625 default K3_AM62A_DDRSS if SOC_K3_AM62A7 -- 2.17.1
[PATCH v2 04/10] drivers: dma: Add support for J784S4
Add support for DMA in J784S4 SoC.
Signed-off-by: Apurva Nandan
Signed-off-by: Hari Nagalla
---
drivers/dma/ti/Makefile | 1 +
drivers/dma/ti/k3-psil-j784s4.c | 166 ++
drivers/dma/ti/k3-psil-priv.h | 1 +
drivers/dma/ti/k3-psil.c | 2 +
drivers/firmware/ti_sci_static_data.h | 35 ++
5 files changed, 205 insertions(+)
create mode 100644 drivers/dma/ti/k3-psil-j784s4.c
diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
index 6807eb8e8b..bd4ce68d9c 100644
--- a/drivers/dma/ti/Makefile
+++ b/drivers/dma/ti/Makefile
@@ -8,3 +8,4 @@ k3-psil-data-$(CONFIG_SOC_K3_J721E) += k3-psil-j721e.o
k3-psil-data-$(CONFIG_SOC_K3_J721S2) += k3-psil-j721s2.o
k3-psil-data-$(CONFIG_SOC_K3_AM642) += k3-psil-am64.o
k3-psil-data-$(CONFIG_SOC_K3_AM625) += k3-psil-am62.o
+k3-psil-data-$(CONFIG_SOC_K3_J784S4) += k3-psil-j784s4.o
diff --git a/drivers/dma/ti/k3-psil-j784s4.c b/drivers/dma/ti/k3-psil-j784s4.c
new file mode 100644
index 00..d62d5e9c33
--- /dev/null
+++ b/drivers/dma/ti/k3-psil-j784s4.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com
+ */
+#include
+
+#include "k3-psil-priv.h"
+
+#define PSIL_PDMA_XY_TR(x) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_PDMA_XY, \
+ }, \
+ }
+
+#define PSIL_PDMA_XY_PKT(x)\
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_PDMA_XY, \
+ .pkt_mode = 1, \
+ }, \
+ }
+
+#define PSIL_PDMA_MCASP(x) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_PDMA_XY, \
+ .pdma_acc32 = 1,\
+ .pdma_burst = 1,\
+ }, \
+ }
+
+#define PSIL_ETHERNET(x) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_NATIVE, \
+ .pkt_mode = 1, \
+ .needs_epib = 1,\
+ .psd_size = 16, \
+ }, \
+ }
+
+#define PSIL_SA2UL(x, tx) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_NATIVE, \
+ .pkt_mode = 1, \
+ .needs_epib = 1,\
+ .psd_size = 64, \
+ .notdpkt = tx, \
+ }, \
+ }
+
+/* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
+static struct psil_ep j784s4_src_ep_map[] = {
+ /* PDMA_MCASP - McASP0-4 */
+ PSIL_PDMA_MCASP(0x4400),
+ PSIL_PDMA_MCASP(0x4401),
+ PSIL_PDMA_MCASP(0x4402),
+ PSIL_PDMA_MCASP(0x4403),
+ PSIL_PDMA_MCASP(0x4404),
+ /* PDMA_SPI_G0 - SPI0-3 */
+ PSIL_PDMA_XY_PKT(0x4600),
+ PSIL_PDMA_XY_PKT(0x4601),
+ PSIL_PDMA_XY_PKT(0x4602),
+ PSIL_PDMA_XY_PKT(0x4603),
+ PSIL_PDMA_XY_PKT(0x4604),
+ PSIL_PDMA_XY_PKT(0x4605),
+ PSIL_PDMA_XY_PKT(0x4606),
+ PSIL_PDMA_XY_PKT(0x4607),
+ PSIL_PDMA_XY_PKT(0x4608),
+ PSIL_PDMA_XY_PKT(0x4609),
+ PSIL_PDMA_XY_PKT(0x460a),
+ PSIL_PDMA_XY_PKT(0x460b),
+ PSIL_PDMA_XY_PKT(0x460c),
+ PSIL_PDMA_XY_PKT(0x460d),
+ PSIL_PDMA_XY_PKT(0x460e),
+ PSIL_PDMA_XY_PKT(0x460f),
+ /* PDMA_SPI_G1 - SPI4-7 */
+ PSIL_PDMA_XY_PKT(0x4610),
+ PSIL_PDMA_XY_PKT(0x4611),
+ PSIL_PDMA_XY_PKT(0x4612),
+ PSIL_PDMA_XY_PKT(0x4613),
+ PSIL_PDMA_XY_PKT(0x4614),
+ PSIL_PDMA_XY_PKT(0x4615),
+ PSIL_PDMA_XY_PKT(0x4616),
+ PSIL_PDMA_XY_PKT(0x4617),
+ PSIL_PDMA_XY_PKT(0x4618),
+ PSIL_PDMA_XY_PKT(0x4619),
+ PSIL_PDMA_XY_PKT(0x461a),
+ PSIL_PDMA_XY_PKT(0x461b),
+
[PATCH v2 09/10] board: ti: j784s4: Add board support for J784S4 SoC
Add board support for J784S4 SoC.
Signed-off-by: Hari Nagalla
---
board/ti/j784s4/Kconfig | 61 +
board/ti/j784s4/MAINTAINERS | 7 +
board/ti/j784s4/Makefile | 8 ++
board/ti/j784s4/evm.c| 105 +++
configs/j784s4_evm_a72_defconfig | 213 +++
configs/j784s4_evm_r5_defconfig | 179 ++
6 files changed, 573 insertions(+)
create mode 100644 board/ti/j784s4/Kconfig
create mode 100644 board/ti/j784s4/MAINTAINERS
create mode 100644 board/ti/j784s4/Makefile
create mode 100644 board/ti/j784s4/evm.c
create mode 100644 configs/j784s4_evm_a72_defconfig
create mode 100644 configs/j784s4_evm_r5_defconfig
diff --git a/board/ti/j784s4/Kconfig b/board/ti/j784s4/Kconfig
new file mode 100644
index 00..9b6e3bb3c4
--- /dev/null
+++ b/board/ti/j784s4/Kconfig
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+# Hari Nagalla
+
+choice
+ prompt "K3 J784S4 board"
+ optional
+
+config TARGET_J784S4_A72_EVM
+ bool "TI K3 based J784S4 EVM running on A72"
+ select ARM64
+ select SOC_K3_J784S4
+ select BOARD_LATE_INIT
+ select SYS_DISABLE_DCACHE_OPS
+
+config TARGET_J784S4_R5_EVM
+ bool "TI K3 based J784S4 EVM running on R5"
+ select CPU_V7R
+ select SYS_THUMB_BUILD
+ select SOC_K3_J784S4
+ select K3_LOAD_SYSFW
+ select RAM
+ select SPL_RAM
+ select K3_DDRSS
+ imply SYS_K3_SPL_ATF
+
+endchoice
+
+if TARGET_J784S4_A72_EVM
+
+config SYS_BOARD
+ default "j784s4"
+
+config SYS_VENDOR
+ default "ti"
+
+config SYS_CONFIG_NAME
+ default "j784s4_evm"
+
+source "board/ti/common/Kconfig"
+
+endif
+
+if TARGET_J784S4_R5_EVM
+
+config SYS_BOARD
+ default "j784s4"
+
+config SYS_VENDOR
+ default "ti"
+
+config SYS_CONFIG_NAME
+ default "j784s4_evm"
+
+config SPL_LDSCRIPT
+ default "arch/arm/mach-omap2/u-boot-spl.lds"
+
+source "board/ti/common/Kconfig"
+
+endif
diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
new file mode 100644
index 00..7b45e409c6
--- /dev/null
+++ b/board/ti/j784s4/MAINTAINERS
@@ -0,0 +1,7 @@
+J784S4 BOARD
+M: Hari Nagalla
+S: Maintained
+F: board/ti/j784s4
+F: include/configs/j784s4_evm.h
+F: configs/j784s4_evm_r5_defconfig
+F: configs/j784s4_evm_a72_defconfig
diff --git a/board/ti/j784s4/Makefile b/board/ti/j784s4/Makefile
new file mode 100644
index 00..fc98b24a2d
--- /dev/null
+++ b/board/ti/j784s4/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+# Hari Nagalla
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += evm.o
diff --git a/board/ti/j784s4/evm.c b/board/ti/j784s4/evm.c
new file mode 100644
index 00..13b6162329
--- /dev/null
+++ b/board/ti/j784s4/evm.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Board specific initialization for J784S4 EVM
+ *
+ * Copyright (C) 2022 Texas Instruments Incorporated - http://www.ti.com/
+ * Hari Nagalla
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../common/board_detect.h"
+
+#define board_is_j784s4_evm() board_ti_k3_is("J784S4-EVM")
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ return 0;
+}
+
+int dram_init(void)
+{
+#ifdef CONFIG_PHYS_64BIT
+ gd->ram_size = 0x1;
+#else
+ gd->ram_size = 0x8000;
+#endif
+
+ return 0;
+}
+
+phys_size_t board_get_usable_ram_top(phys_size_t total_size)
+{
+#ifdef CONFIG_PHYS_64BIT
+ /* Limit RAM used by U-Boot to the DDR low region */
+ if (gd->ram_top > 0x1)
+ return 0x1;
+#endif
+
+ return gd->ram_top;
+}
+
+int dram_init_banksize(void)
+{
+ /* Bank 0 declares the memory available in the DDR low region */
+ gd->bd->bi_dram[0].start = CFG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = 0x7fff;
+ gd->ram_size = 0x8000;
+
+#ifdef CONFIG_PHYS_64BIT
+ /* Bank 1 declares the memory available in the DDR high region */
+ gd->bd->bi_dram[1].start = CFG_SYS_SDRAM_BASE1;
+ gd->bd->bi_dram[1].size = 0x77fff;
+ gd->ram_size = 0x8;
+#endif
+
+ return 0;
+}
+
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ int ret;
+
+ ret = fdt_fixup_msmc_ram(blob, "/bus@10", "sram@7000");
+ if (ret < 0)
+ ret = fdt_fixup_msmc_ram(blob, "/interconnect@10",
+"sram@7000");
+ if (ret)
+ printf("%s: fixing up msmc ram failed %d\n", __func__, ret);
+
+ return ret;
+}
+#endif
+
+int
[PATCH v2 08/10] soc: ti: k3-socinfo: Add entry for J784S4 SoC
Add support for J784S4 SoC Identification. Signed-off-by: Hari Nagalla --- drivers/soc/soc_ti_k3.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c index 8af0ac7051..caf8db9574 100644 --- a/drivers/soc/soc_ti_k3.c +++ b/drivers/soc/soc_ti_k3.c @@ -17,6 +17,7 @@ #define J721S2 0xbb75 #define AM62X 0xbb7e #define AM62AX 0xbb8d +#define J784S4 0xbb80 #define JTAG_ID_VARIANT_SHIFT 28 #define JTAG_ID_VARIANT_MASK (0xf << 28) @@ -54,9 +55,14 @@ static const char *get_family_string(u32 idreg) case AM62X: family = "AM62X"; break; + case AM62AX: family = "AM62AX"; + + case J784S4: + family = "J784S4"; break; + default: family = "Unknown Silicon"; }; -- 2.17.1
[PATCH v2 00/10] Introduce initial TI's J784S4 support
Hello Everyone! This series will introduce basic support (SD and UART) support for Texas Instruments J784S4 EVM. The J784S4 SoC device tree patches are taken from kernel patch submissions and will be updated as they are accepted and merged to the kernel tree. All other patches are specific to SPL and u-boot and do not have dependency on other trees. Appreciate a review for acceptance to u-boot tree. Here are some of the salient features of the J784S4 automotive grade application processor: The J784S4 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration in automotive, ADAS and industrial applications requiring AI at the network edge. This SoC extends the K3 Jacinto 7 family of SoCs with focus on raising performance and integration while providing interfaces, memory architecture and compute performance for multi-sensor, high concurrency applications. Some highlights of this SoC are: * Up to 8 Cortex-A72s, four clusters of lockstep capable dual Cortex-R5F MCUs, 4 C7x floating point vector DSPs with Matrix Multiply Accelerator(MMA) for deep learning and CNN. * 3D GPU: Automotive grade IMG BXS-4-64 * Vision Processing Accelerator (VPAC) with image signal processor and Depth and Motion Processing Accelerator (DMPAC) * Three CSI2.0 4L RX plus two CSI2.0 4L TX, two DSI Tx, one eDP/DP and one DPI interface. * Integrated gigabit ethernet switch, up to 8 ports (TDA4VH), two ports support 10Gb USXGMII; Two 4 lane PCIe-GEN3 controllers, USB3.0 Dual-role device subsystems, Up to 20 MCANs, among other peripherals. See J784S4 Technical Reference Manual (SPRUJ52 - JUNE 2022) for further details: http://www.ti.com/lit/zip/spruj52 In addtion, the J784S4 EVM board is designed for TI J784S4 SoC. It supports the following interfaces: * 32 GB DDR4 RAM * x2 Gigabit Ethernet interfaces capable of working in Switch and MAC mode * x1 Input Audio Jack, x1 Output Audio Jack * x1 USB2.0 Hub with two Type A host and x1 USB 3.1 Type-C Port * x2 4L PCIe connector * x1 UHS-1 capable micro-SD card slot * 512 Mbit OSPI flash, 1 Gbit Octal NAND flash, 512 Mbit QSPI flash, UFS flash. * x6 UART through UART-USB bridge * XDS110 for onboard JTAG debug using USB * Temperature sensors, user push buttons and LEDs * 40-pin User Expansion Connector * x2 ENET Expansion Connector, x1 GESI expander, x2 Display connector * x1 15-pin CSI header * x6 MCAN instances Schematics: https://www.ti.com/lit/zip/sprr458 bootlog: https://paste.sr.ht/~hnagalla/f14840abc854519f912923662f1fdc8075d92107 Changes in v2: - Refactored environement scripts to 'j784s4.env' and removed scripts not needed for basic board bootup. - Imported the J7874S4 basic device tree files from v6.2 linux kernel. - Moved j784s4 clock definitions and clock data into one patch/commit. - coalesce board commits into one commit. Hari Nagalla (10): arm: dts: introduce j784s4 dtbs from linux kernel arm: dts: introduce j784s4 u-boot dtbs arm: K3: Add basic support for J784S4 SoC definition drivers: dma: Add support for J784S4 clk: clk-k3: Add support for J784S4 SoC power: domain: ti: Add support for J784S4 SoC ram: k3-ddrss: Add support for J784S4 SoC soc: ti: k3-socinfo: Add entry for J784S4 SoC board: ti: j784s4: Add board support for J784S4 SoC dt-bindings: ti-serdes-mux: Add defines for J784S4 SoC arch/arm/dts/Makefile |2 + arch/arm/dts/k3-j784s4-ddr-evm-lp4-4266.dtsi | 8757 arch/arm/dts/k3-j784s4-ddr.dtsi | 8858 + arch/arm/dts/k3-j784s4-evm-u-boot.dtsi| 135 + arch/arm/dts/k3-j784s4-evm.dts| 196 + arch/arm/dts/k3-j784s4-main.dtsi | 1007 ++ arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi| 311 + arch/arm/dts/k3-j784s4-r5-evm.dts | 209 + arch/arm/dts/k3-j784s4.dtsi | 287 + arch/arm/mach-k3/Kconfig | 16 +- arch/arm/mach-k3/Makefile |2 + arch/arm/mach-k3/arm64-mmu.c | 41 + arch/arm/mach-k3/include/mach/hardware.h |4 + .../mach-k3/include/mach/j784s4_hardware.h| 41 + arch/arm/mach-k3/include/mach/j784s4_spl.h| 46 + arch/arm/mach-k3/include/mach/spl.h |6 +- arch/arm/mach-k3/j784s4/Makefile |5 + arch/arm/mach-k3/j784s4/clk-data.c| 428 + arch/arm/mach-k3/j784s4/dev-data.c| 97 + arch/arm/mach-k3/j784s4_init.c| 319 + board/ti/j784s4/Kconfig | 61 + board/ti/j784s4/MAINTAINERS |7 + board/ti/j784s4/Makefile |8 + board/ti/j784s4/evm.c | 105 + board/ti/j784s4/j784s4.env| 108 + configs/j784s4_evm_a72_defconfig | 213 + configs/j784s4_evm_r5_defconfig | 179 + drivers/clk/ti/clk-k3.c |6 + drivers/dma/ti/Makefile
[PATCH v2 06/10] power: domain: ti: Add support for J784S4 SoC
Add support for J784S4 SoC.
Signed-off-by: Apurva Nandan
Signed-off-by: Hari Nagalla
---
drivers/power/domain/ti-power-domain.c | 6 ++
include/k3-dev.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/power/domain/ti-power-domain.c
b/drivers/power/domain/ti-power-domain.c
index 9e7151307c..0ff174e57e 100644
--- a/drivers/power/domain/ti-power-domain.c
+++ b/drivers/power/domain/ti-power-domain.c
@@ -98,6 +98,12 @@ static const struct soc_attr ti_k3_soc_pd_data[] = {
.family = "AM62AX",
.data = _pd_platdata,
},
+#endif
+#ifdef CONFIG_SOC_K3_J784S4
+ {
+ .family = "J784S4",
+ .data = _pd_platdata,
+ },
#endif
{ /* sentinel */ }
};
diff --git a/include/k3-dev.h b/include/k3-dev.h
index d288ae3be7..59970866f1 100644
--- a/include/k3-dev.h
+++ b/include/k3-dev.h
@@ -80,6 +80,7 @@ extern const struct ti_k3_pd_platdata j7200_pd_platdata;
extern const struct ti_k3_pd_platdata j721s2_pd_platdata;
extern const struct ti_k3_pd_platdata am62x_pd_platdata;
extern const struct ti_k3_pd_platdata am62ax_pd_platdata;
+extern const struct ti_k3_pd_platdata j784s4_pd_platdata;
u8 ti_pd_state(struct ti_pd *pd);
u8 lpsc_get_state(struct ti_lpsc *lpsc);
--
2.17.1
[PATCH v2 10/10] dt-bindings: ti-serdes-mux: Add defines for J784S4 SoC
There are 4 instances of SERDES modules, with each instance supporting 4 lanes. Signed-off-by: Matthew Ranostay Signed-off-by: Hari Nagalla --- include/dt-bindings/mux/ti-serdes.h | 62 + 1 file changed, 62 insertions(+) diff --git a/include/dt-bindings/mux/ti-serdes.h b/include/dt-bindings/mux/ti-serdes.h index d3116c52ab..669ca2d6ab 100644 --- a/include/dt-bindings/mux/ti-serdes.h +++ b/include/dt-bindings/mux/ti-serdes.h @@ -117,4 +117,66 @@ #define J721S2_SERDES0_LANE3_USB 0x2 #define J721S2_SERDES0_LANE3_IP4_UNUSED0x3 +/* J784S4 */ + +#define J784S4_SERDES0_LANE0_IP1_UNUSED0x0 +#define J784S4_SERDES0_LANE0_PCIE1_LANE0 0x1 +#define J784S4_SERDES0_LANE0_IP3_UNUSED0x2 +#define J784S4_SERDES0_LANE0_IP4_UNUSED0x3 + +#define J784S4_SERDES0_LANE1_IP1_UNUSED0x0 +#define J784S4_SERDES0_LANE1_PCIE1_LANE1 0x1 +#define J784S4_SERDES0_LANE1_IP3_UNUSED0x2 +#define J784S4_SERDES0_LANE1_IP4_UNUSED0x3 + +#define J784S4_SERDES0_LANE2_PCIE3_LANE0 0x0 +#define J784S4_SERDES0_LANE2_PCIE1_LANE2 0x1 +#define J784S4_SERDES0_LANE2_IP3_UNUSED0x2 +#define J784S4_SERDES0_LANE2_IP4_UNUSED0x3 + +#define J784S4_SERDES0_LANE3_PCIE3_LANE1 0x0 +#define J784S4_SERDES0_LANE3_PCIE1_LANE3 0x1 +#define J784S4_SERDES0_LANE3_USB 0x2 +#define J784S4_SERDES0_LANE3_IP4_UNUSED0x3 + +#define J784S4_SERDES1_LANE0_QSGMII_LANE3 0x0 +#define J784S4_SERDES1_LANE0_PCIE0_LANE0 0x1 +#define J784S4_SERDES1_LANE0_IP3_UNUSED0x2 +#define J784S4_SERDES1_LANE0_IP4_UNUSED0x3 + +#define J784S4_SERDES1_LANE1_QSGMII_LANE4 0x0 +#define J784S4_SERDES1_LANE1_PCIE0_LANE1 0x1 +#define J784S4_SERDES1_LANE1_IP3_UNUSED0x2 +#define J784S4_SERDES1_LANE1_IP4_UNUSED0x3 + +#define J784S4_SERDES1_LANE2_QSGMII_LANE1 0x0 +#define J784S4_SERDES1_LANE2_PCIE0_LANE2 0x1 +#define J784S4_SERDES1_LANE2_PCIE2_LANE0 0x2 +#define J784S4_SERDES1_LANE2_IP4_UNUSED0x3 + +#define J784S4_SERDES1_LANE3_QSGMII_LANE2 0x0 +#define J784S4_SERDES1_LANE3_PCIE0_LANE3 0x1 +#define J784S4_SERDES1_LANE3_PCIE2_LANE1 0x2 +#define J784S4_SERDES1_LANE3_IP4_UNUSED0x3 + +#define J784S4_SERDES2_LANE0_QSGMII_LANE5 0x0 +#define J784S4_SERDES2_LANE0_IP2_UNUSED0x1 +#define J784S4_SERDES2_LANE0_IP3_UNUSED0x2 +#define J784S4_SERDES2_LANE0_IP4_UNUSED0x3 + +#define J784S4_SERDES2_LANE1_QSGMII_LANE6 0x0 +#define J784S4_SERDES2_LANE1_IP2_UNUSED0x1 +#define J784S4_SERDES2_LANE1_IP3_UNUSED0x2 +#define J784S4_SERDES2_LANE1_IP4_UNUSED0x3 + +#define J784S4_SERDES2_LANE2_QSGMII_LANE7 0x0 +#define J784S4_SERDES2_LANE2_QSGMII_LANE1 0x1 +#define J784S4_SERDES2_LANE2_IP3_UNUSED0x2 +#define J784S4_SERDES2_LANE2_IP4_UNUSED0x3 + +#define J784S4_SERDES2_LANE3_QSGMII_LANE8 0x0 +#define J784S4_SERDES2_LANE3_QSGMII_LANE2 0x1 +#define J784S4_SERDES2_LANE3_IP3_UNUSED0x2 +#define J784S4_SERDES2_LANE3_IP4_UNUSED0x3 + #endif /* _DT_BINDINGS_MUX_TI_SERDES */ -- 2.17.1
Re: [PATCH 1/2] lmb: Fix LMB_MEMORY_REGIONS flag usage
On 3/21/23 13:58, Patrick Delaunay wrote:
Remove test on CONFIG_LMB_MEMORY_REGIONS introduced by commit
7c1860fce4e3 ("lmb: Fix lmb property's defination under struct lmb").
This code in lmb_init() is strange, because if CONFIG_LMB_USE_MAX_REGIONS
and CONFIG_LMB_MEMORY_REGIONS are not defined, the implicit #else is empty
and the required initialization are not done:
lmb->memory.max = ?
lmb->reserved.max = ?
But this setting is not possible:
- CONFIG_LMB_USE_MAX_REGIONS not defined
- CONFIG_LMB_MEMORY_REGIONS not defined
because CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS are
defined as soon as the CONFIG_LMB_USE_MAX_REGIONS is not defined.
This patch removes this impossible case #elif and I add some
explanation in lmb.h to explain why in the struct lmb {} the lmb
property's should is defined if CONFIG_LMB_MEMORY_REGIONS is NOT defined.
Fixes: 5e2548c1d6e03 ("lmb: Fix LMB_MEMORY_REGIONS flag usage")
Reported-by: Mark Millard
Signed-off-by: Patrick Delaunay
---
include/lmb.h | 20 +++-
lib/lmb.c | 2 +-
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/include/lmb.h b/include/lmb.h
index 7298c2ccc403..f70463ac5440 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -35,6 +35,24 @@ struct lmb_property {
enum lmb_flags flags;
};
+/*
+ * For regions size management, see LMB configuration in KConfig
+ * all the #if test are done with CONFIG_LMB_USE_MAX_REGIONS (boolean)
+ *
+ * case 1. CONFIG_LMB_USE_MAX_REGIONS is defined (legacy mode)
+ * => CONFIG_LMB_MAX_REGIONS is used to configure the region size,
+ * direclty in the array lmb_region.region[], with the same
+ * configuration for memory reion and reseserved region.
+ *
+ * case 2. CONFIG_LMB_USE_MAX_REGIONS is not defined, the size of each
+ * region is configurated *independently* with
+ * => CONFIG_LMB_MEMORY_REGIONS: struct lmb.memory_regions
+ * => CONFIG_LMB_RESERVED_REGIONS: struct lmb.reserved_regions
+ * lmb_region.region is only a pointer to the correct buffer,
+ * initialized in lmb_init(). This configuration is useful to manage
+ * more reserved memory regions with CONFIG_LMB_RESERVED_REGIONS.
+ */
+
/**
* struct lmb_region - Description of a set of region.
*
@@ -68,7 +86,7 @@ struct lmb_region {
struct lmb {
struct lmb_region memory;
struct lmb_region reserved;
-#ifdef CONFIG_LMB_MEMORY_REGIONS
+#if !IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
struct lmb_property memory_regions[CONFIG_LMB_MEMORY_REGIONS];
struct lmb_property reserved_regions[CONFIG_LMB_RESERVED_REGIONS];
#endif
diff --git a/lib/lmb.c b/lib/lmb.c
index 2444b2a62121..8fbe453dfa9d 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -110,7 +110,7 @@ void lmb_init(struct lmb *lmb)
#if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
lmb->memory.max = CONFIG_LMB_MAX_REGIONS;
lmb->reserved.max = CONFIG_LMB_MAX_REGIONS;
-#elif defined(CONFIG_LMB_MEMORY_REGIONS)
+#else
lmb->memory.max = CONFIG_LMB_MEMORY_REGIONS;
lmb->reserved.max = CONFIG_LMB_RESERVED_REGIONS;
lmb->memory.region = lmb->memory_regions;
I just build this patch for our platforms and got this.
M
02: lmb: Fix LMB_MEMORY_REGIONS flag usage
aarch64: + xilinx_versal_mini xilinx_versal_mini_emmc0
xilinx_versal_mini_emmc1 xilinx_versal_mini_ospi xilinx_versal_mini_qspi
xilinx_versal_net_mini xilinx_zynqmp_mini xilinx_zynqmp_mini_emmc0
xilinx_zynqmp_mini_emmc1 xilinx_zynqmp_mini_nand xilinx_zynqmp_mini_nand_single
xilinx_zynqmp_mini_qspi
arm: + zynq_cse_nand zynq_cse_nor zynq_cse_qspi
+In file included from ../include/image.h:34:0,
+ from ../include/bootm.h:10,
+ from ../arch/arm/cpu/armv8/exception_level.c:12:
+../include/lmb.h:90:37: error: ‘CONFIG_LMB_MEMORY_REGIONS’ undeclared here (not
in a function)
+ struct lmb_property memory_regions[CONFIG_LMB_MEMORY_REGIONS];
+ ^
+../include/lmb.h:91:39: error: ‘CONFIG_LMB_RESERVED_REGIONS’ undeclared here
(not in a function)
+ struct lmb_property reserved_regions[CONFIG_LMB_RESERVED_REGIONS];
+ ^~~
+make[2]: *** [../scripts/Makefile.build:257:
arch/arm/cpu/armv8/exception_level.o] Error 1
+make[1]: *** [Makefile:1847: arch/arm/cpu/armv8] Error 2
+make: *** [Makefile:177: sub-make] Error 2
+In file included from ../arch/arm/lib/stack.c:15:0:
+make[2]: *** [../scripts/Makefile.build:257: arch/arm/lib/stack.o] Error 1
+make[1]: *** [Makefile:1847: arch/arm/lib] Error 2
Re: [PATCH v4 17/17] configs: starfive: add starfive_visionfive2_defconfig
On Mär 21 2023, yanhong wang wrote: > Except for CONFIG_DEFAULT_DEVICE_TREE and CONFIG_DEFAULT_FDT_FILE, > 1.2a and 1.3b versions use the same config. > > Version 1.3b uses the following configuration: > CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.3b" > CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.3b.dtb" > > Version 1.2a uses the following configuration: > CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.2a" > CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.2a.dtb" > > Is it necessary to separate the configs for 1.2a and 1.3b as separate > defconfig files? It makes a difference for when ethernet support is added. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH 2/2] efi_loader: fix device-path for USB devices
On 3/20/23 19:39, Simon Glass wrote:
Hi Heinrich,
On Mon, 20 Mar 2023 at 09:58, Heinrich Schuchardt
wrote:
On 3/19/23 20:29, Simon Glass wrote:
Hi Heinrich,
On Mon, 20 Mar 2023 at 04:25, Heinrich Schuchardt
wrote:
EFI device paths for block devices must be unique. If a non-unique device
path is discovered, probing of the block device fails.
Currently we use UsbClass() device path nodes. As multiple devices may
have the same vendor and product id these are non-unique. Instead we
should use Usb() device path nodes. They include the USB port on the
parent hub. Hence they are unique.
A USB storage device may contain multiple logical units. These can be
modeled as Ctrl() nodes.
Reported-by: Patrick Delaunay
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path.c | 45 +++-
1 file changed, 33 insertions(+), 12 deletions(-)
Reviewed-by: Simon Glass
[..]
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 3b267b713e..b6dd575b13 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -147,7 +147,7 @@ struct efi_device_path *efi_dp_shorten(struct
efi_device_path *dp)
* in practice fallback.efi just uses MEDIA:HARD_DRIVE
* so not sure when we would see these other cases.
*/
- if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB_CLASS) ||
+ if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB) ||
EFI_DP_TYPE(dp, MEDIA_DEVICE, HARD_DRIVE_PATH) ||
EFI_DP_TYPE(dp, MEDIA_DEVICE, FILE_PATH))
return dp;
@@ -564,6 +564,11 @@ __maybe_unused static unsigned int dp_size(struct udevice
*dev)
return dp_size(dev->parent)
+ sizeof(struct efi_device_path_vendor) + 1;
#endif
+#ifdef CONFIG_USB
+ case UCLASS_MASS_STORAGE:
Can we do:
case UCLASS_MASS_STORAGE:
if (IS_ENABLED(CONFIG_USB)) {
...
}
?
That should be possible too. Didn't you want to get rid of IS_ENABLED()?
CONFIG_IS_ENABLED() would work here too.
I was wanting to get rid of CONFIG_IS_ENABLED() for things that don't
have an SPL Kconfig, then eventually get rid of CONFIG_IS_ENABLED().
I've got a bit lost in all the problems though.
The whole way that we create device paths is not consistent. We should
have a device path node for each DM device.
With v2023.07 I want to add
struct efi_device_path *(*get_dp_node)(struct udevice *dev);
to struct uclass_driver and move the generation of device path nodes to
the individual uclass drivers.
We could also send an event (EVT_EFI_GET_DP_NODE) and connect it that
way...ie would add less space to driver model. But yes it would be
good to line up EFI and DM a bit better.
The type of device-path node to be created is uclass specific:
For an NVMe device we will always create a NVMe() node.
For a block device we will always create a Ctrl() node with the LUN number.
...
For drivers that don't implement the method yet we can create a VenHw()
node per default with uclass-id and device number encoded in the node.
You suggested yourself that the DM and the EFI implementation should be
tightly integrated.
I cannot see what the use of an event should be. Why should each udevice
register to an event when all we need is a simple function like:
#if CONFIG_IS_ENABLED(EFI_LOADER)
struct efi_device_path *uclass_get_dp_node(struct udevice *dev)
{
struct uclass *uc;
struct efi_device_path_uboot *dp;
uc = dev->uclass;
if (uc->uc_drv->get_dp_node)
return uc->uc_drv->get_dp_node(dev);
dp = efi_alloc(sizeof(struct efi_device_path_uboot));
if (!dp)
return NULL;
dp->dp.type = DEVICE_PATH_TYPE_HARDWARE_DEVICE;
dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_VENDOR;
dp->dp.length = sizeof(struct efi_device_path_uboot);
dp->guid = efi_u_boot_guid;
dp->uclass_id = uc->uc_drv->id;
dp->seq_ = dev->seq_;
return >dp;
}
#endif
Best regards
Heinrich
Re: [PATCH 29/33] doc: boards: amlogic: update documentation for WeTek Core2
> On 20 Mar 2023, at 10:40 pm, Simon Glass wrote: > > Hi Christian, > > On Tue, 21 Mar 2023 at 06:05, Christian Hewitt > wrote: >> >> Improve documentation. >> >> Signed-off-by: Christian Hewitt >> --- >> doc/board/amlogic/wetek-core2.rst | 83 +-- >> 1 file changed, 47 insertions(+), 36 deletions(-) > > This should really move to binman. Would you like to take a look? > > I sent a patch for this a while ago but it needs something to review > and try out. > > https://patchwork.ozlabs.org/project/uboot/patch/20220110031413.1970836-39-...@chromium.org/ > > I am happy to do more on it as needed. Hello Simon, For now this is just a cleanup but longer-term (won’t be quick) I can take a look. Do you have that series rebased against current and in a repo somewhere for easier cherry-picking? Christian
[PATCH v2] fdt: Make fdt addr -q quieter
From: Peter Hoyes
64597346 "fdt: Add -q option to fdt addr for distro_bootcmd" introduced
the -q option for fdt addr, which sets the current working fdt address
without printing any output.
baf41410 "fdt: Show a message when the working FDT changes" made the
utility function set_working_fdt_addr (in cmd/fdt.c) output a message
on each invocation, even if called via fdt addr -q, in which case its
output is now slightly noisier.
To fix this, split out set_working_fdt_addr into set_working_fdt_addr
plus the static function set_working_fdt_addr_quiet.
set_working_fdt_addr_quiet can be called by "quiet" fdt cmd logic and
set_working_fdt_addr is exported (as before) to other boot logic. The
latter calls the former.
Remove the assertion from the fdt addr test case when calling with the
-q argument.
Signed-off-by: Peter Hoyes
---
cmd/fdt.c | 19 ++-
test/cmd/fdt.c | 1 -
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/cmd/fdt.c b/cmd/fdt.c
index f38fe909c3..f1f2ef6a12 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -36,16 +36,21 @@ static int is_printable_string(const void *data, int len);
*/
struct fdt_header *working_fdt;
-void set_working_fdt_addr(ulong addr)
+static void set_working_fdt_addr_quiet(ulong addr)
{
void *buf;
- printf("Working FDT set to %lx\n", addr);
buf = map_sysmem(addr, 0);
working_fdt = buf;
env_set_hex("fdtaddr", addr);
}
+void set_working_fdt_addr(ulong addr)
+{
+ printf("Working FDT set to %lx\n", addr);
+ set_working_fdt_addr_quiet(addr);
+}
+
/*
* Get a value from the fdt and format it to be set in the environment
*/
@@ -192,10 +197,14 @@ static int do_fdt(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
if ((quiet && fdt_check_header(blob)) ||
(!quiet && !fdt_valid()))
return 1;
- if (control)
+ if (control) {
gd->fdt_blob = blob;
- else
- set_working_fdt_addr(addr);
+ } else {
+ if (quiet)
+ set_working_fdt_addr_quiet(addr);
+ else
+ set_working_fdt_addr(addr);
+ }
if (argc >= 2) {
int len;
diff --git a/test/cmd/fdt.c b/test/cmd/fdt.c
index cdbaf8c425..85b96c614b 100644
--- a/test/cmd/fdt.c
+++ b/test/cmd/fdt.c
@@ -229,7 +229,6 @@ static int fdt_test_addr_resize(struct unit_test_state *uts)
/* ...quietly */
ut_assertok(run_commandf("fdt addr -q %08x %x", addr, sizeof(fdt) / 4));
- ut_assert_nextline("Working FDT set to %lx", addr);
ut_assertok(ut_check_console_end(uts));
/* We cannot easily provoke errors in fdt_open_into(), so ignore that */
--
2.34.1
[PATCH 1/2] lmb: Fix LMB_MEMORY_REGIONS flag usage
Remove test on CONFIG_LMB_MEMORY_REGIONS introduced by commit
7c1860fce4e3 ("lmb: Fix lmb property's defination under struct lmb").
This code in lmb_init() is strange, because if CONFIG_LMB_USE_MAX_REGIONS
and CONFIG_LMB_MEMORY_REGIONS are not defined, the implicit #else is empty
and the required initialization are not done:
lmb->memory.max = ?
lmb->reserved.max = ?
But this setting is not possible:
- CONFIG_LMB_USE_MAX_REGIONS not defined
- CONFIG_LMB_MEMORY_REGIONS not defined
because CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS are
defined as soon as the CONFIG_LMB_USE_MAX_REGIONS is not defined.
This patch removes this impossible case #elif and I add some
explanation in lmb.h to explain why in the struct lmb {} the lmb
property's should is defined if CONFIG_LMB_MEMORY_REGIONS is NOT defined.
Fixes: 5e2548c1d6e03 ("lmb: Fix LMB_MEMORY_REGIONS flag usage")
Reported-by: Mark Millard
Signed-off-by: Patrick Delaunay
---
include/lmb.h | 20 +++-
lib/lmb.c | 2 +-
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/include/lmb.h b/include/lmb.h
index 7298c2ccc403..f70463ac5440 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -35,6 +35,24 @@ struct lmb_property {
enum lmb_flags flags;
};
+/*
+ * For regions size management, see LMB configuration in KConfig
+ * all the #if test are done with CONFIG_LMB_USE_MAX_REGIONS (boolean)
+ *
+ * case 1. CONFIG_LMB_USE_MAX_REGIONS is defined (legacy mode)
+ * => CONFIG_LMB_MAX_REGIONS is used to configure the region size,
+ * direclty in the array lmb_region.region[], with the same
+ * configuration for memory reion and reseserved region.
+ *
+ * case 2. CONFIG_LMB_USE_MAX_REGIONS is not defined, the size of each
+ * region is configurated *independently* with
+ * => CONFIG_LMB_MEMORY_REGIONS: struct lmb.memory_regions
+ * => CONFIG_LMB_RESERVED_REGIONS: struct lmb.reserved_regions
+ * lmb_region.region is only a pointer to the correct buffer,
+ * initialized in lmb_init(). This configuration is useful to manage
+ * more reserved memory regions with CONFIG_LMB_RESERVED_REGIONS.
+ */
+
/**
* struct lmb_region - Description of a set of region.
*
@@ -68,7 +86,7 @@ struct lmb_region {
struct lmb {
struct lmb_region memory;
struct lmb_region reserved;
-#ifdef CONFIG_LMB_MEMORY_REGIONS
+#if !IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
struct lmb_property memory_regions[CONFIG_LMB_MEMORY_REGIONS];
struct lmb_property reserved_regions[CONFIG_LMB_RESERVED_REGIONS];
#endif
diff --git a/lib/lmb.c b/lib/lmb.c
index 2444b2a62121..8fbe453dfa9d 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -110,7 +110,7 @@ void lmb_init(struct lmb *lmb)
#if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
lmb->memory.max = CONFIG_LMB_MAX_REGIONS;
lmb->reserved.max = CONFIG_LMB_MAX_REGIONS;
-#elif defined(CONFIG_LMB_MEMORY_REGIONS)
+#else
lmb->memory.max = CONFIG_LMB_MEMORY_REGIONS;
lmb->reserved.max = CONFIG_LMB_RESERVED_REGIONS;
lmb->memory.region = lmb->memory_regions;
--
2.25.1
[PATCH 2/2] lmb: add max number of region in lmb_dump_region() output
Add the max number of region in lmb dump; this patch allows to
check the limit for usage of the LMB regions, memory or reserved.
Result on STM32MP157C-DK2:
STM32MP> bdinfo
.
lmb_dump_all:
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x6 / max = 0x10
reserved[0][0x1000-0x10045fff], 0x00046000 bytes flags: 4
reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
reserved[3][0xd400-0xd7ff], 0x0400 bytes flags: 4
reserved[4][0xdcae5000-0xdfff], 0x0351b000 bytes flags: 0
reserved[5][0xddafb5b8-0xdfff], 0x02504a48 bytes flags: 0
Reported-by: Mark Millard
Signed-off-by: Patrick Delaunay
---
lib/lmb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index 8fbe453dfa9d..b2c233edb64e 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -27,7 +27,7 @@ static void lmb_dump_region(struct lmb_region *rgn, char
*name)
enum lmb_flags flags;
int i;
- printf(" %s.cnt = 0x%lx\n", name, rgn->cnt);
+ printf(" %s.cnt = 0x%lx / max = 0x%lx\n", name, rgn->cnt, rgn->max);
for (i = 0; i < rgn->cnt; i++) {
base = rgn->region[i].base;
--
2.25.1
[PATCH] include: configs: am65x_evm: Change to using .env
Move to using .env file for setting up environment variables for am65x.
Signed-off-by: Nikhil M Jain
---
board/ti/am65x/am65x.env| 47 +
include/configs/am65x_evm.h | 68 -
2 files changed, 47 insertions(+), 68 deletions(-)
create mode 100644 board/ti/am65x/am65x.env
diff --git a/board/ti/am65x/am65x.env b/board/ti/am65x/am65x.env
new file mode 100644
index 00..a048b47071
--- /dev/null
+++ b/board/ti/am65x/am65x.env
@@ -0,0 +1,47 @@
+#include
+#include
+#include
+#if CONFIG_CMD_REMOTEPROC
+#include
+#endif
+
+findfdt=
+ setenv name_fdt k3-am654-base-board.dtb;
+ setenv fdtfile ${name_fdt}
+name_kern=Image
+console=ttyS2,115200n8
+args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
+ ${mtdparts}
+run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
+
+boot=mmc
+mmcdev=1
+bootpart=1:2
+bootdir=/boot
+rd_spec=-
+init_mmc=run args_all args_mmc
+get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}
+get_overlay_mmc=
+ fdt address ${fdtaddr};
+ fdt resize 0x10;
+ for overlay in $name_overlays;
+ do;
+ load mmc ${bootpart} ${dtboaddr} ${bootdir}/${overlay} &&
+ fdt apply ${dtboaddr};
+ done;
+get_kern_mmc=load mmc ${bootpart} ${loadaddr}
+ ${bootdir}/${name_kern}
+get_fit_mmc=load mmc ${bootpart} ${addr_fit}
+ ${bootdir}/${name_fit}
+partitions=name=root,start=0,size=-,uuid=${uuid_gpt_rootfs}
+
+init_ubi=
+run args_all args_ubi;
+sf probe;
+ubi part ospi.rootfs;
+ubifsmount ubi:rootfs;
+get_kern_ubi=ubifsload ${loadaddr} ${bootdir}/${name_kern}
+get_fdt_ubi=ubifsload ${fdtaddr} ${bootdir}/${name_fdt}
+args_ubi=setenv bootargs console=${console} ${optargs}
+rootfstype=ubifs root=ubi0:rootfs rw ubi.mtd=ospi.rootfs
+
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index 33dd6cfdfa..c54957300a 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -17,66 +17,6 @@
/* DDR Configuration */
#define CFG_SYS_SDRAM_BASE10x88000
-#define PARTS_DEFAULT \
- /* Linux partitions */ \
- "name=rootfs,start=0,size=-,uuid=${uuid_gpt_rootfs}\0"
-
-/* U-Boot general configuration */
-#define EXTRA_ENV_AM65X_BOARD_SETTINGS \
- "findfdt=" \
- "setenv name_fdt k3-am654-base-board.dtb;" \
- "setenv fdtfile ${name_fdt}\0" \
- "name_kern=Image\0" \
- "console=ttyS2,115200n8\0" \
- "stdin=serial,usbkbd\0" \
- "args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 " \
- "${mtdparts}\0" \
- "run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}\0"\
-
-/* U-Boot MMC-specific configuration */
-#define EXTRA_ENV_AM65X_BOARD_SETTINGS_MMC \
- "boot=mmc\0"\
- "mmcdev=1\0"\
- "bootpart=1:2\0"\
- "bootdir=/boot\0" \
- "rd_spec=-\0" \
- "init_mmc=run args_all args_mmc\0" \
- "get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}\0" \
- "get_overlay_mmc=" \
- "fdt address ${fdtaddr};" \
- "fdt resize 0x10;" \
- "for overlay in $name_overlays;"\
- "do;" \
- "load mmc ${bootpart} ${dtboaddr} ${bootdir}/${overlay};"
\
- "fdt apply ${dtboaddr};"\
- "done;\0" \
- "get_kern_mmc=load mmc ${bootpart} ${loadaddr} "\
- "${bootdir}/${name_kern}\0" \
- "get_fit_mmc=load mmc ${bootpart} ${addr_fit} " \
- "${bootdir}/${name_fit}\0" \
- "partitions=" PARTS_DEFAULT
-
-#ifdef DEFAULT_RPROCS
-#undef DEFAULT_RPROCS
-#endif
-#define DEFAULT_RPROCS "" \
- "0 /lib/firmware/am65x-mcu-r5f0_0-fw " \
- "1 /lib/firmware/am65x-mcu-r5f0_1-fw "
-
-#define EXTRA_ENV_AM65X_BOARD_SETTINGS_UBI \
- "init_ubi=run args_all args_ubi; sf probe; "\
-
RE: [PATCH] i2c: correct I2C deblock logic
> -Original Message- > From: Alexander Kochetkov > Sent: 2023年3月21日 17:50 > To: Bough Chen > Cc: h...@denx.de; ma...@denx.de; u-boot@lists.denx.de; dl-uboot-imx > ; xypron.g...@gmx.de; Simon Glass > > Subject: Re: [PATCH] i2c: correct I2C deblock logic > > Hi Haibo. > > Nice catch! Agree with you patch. But may be fix problem in general? > I suggest to add GPIOD_ACTIVE_LOW to the GPIOD_MASK_DIR mask to fix > problems 1, 2, 4. > Not sure if that logically correct. What do you think? Hi Alexander I will have a try, and test on my side. Best Regards Haibo Chen > > I grepped the code for ‘dm_gpio_set_dir_flags’ and found another places > affected by the bug. > > 1. u-boot/drivers/spi/mxc_spi.c: > ret = dm_gpio_set_dir_flags(>cs_gpios[i], > GPIOD_IS_OUT | > GPIOD_ACTIVE_LOW); > > Here GPIOD_ACTIVE_LOW is passed to dm_gpio_set_dir_flags() and filtered out > by dm_gpio_set_dir_flags(). > GPIOD_ACTIVE_LOW can be added to GPIOD_MASK_DIR mask to fix that. > > 2. u-boot/drivers/spi/mvebu_a3700_spi.c: > ret = dm_gpio_set_dir_flags(>cs_gpios[i], > GPIOD_IS_OUT | > GPIOD_ACTIVE_LOW); Same as 1. > > 3. u-boot/drivers/phy/allwinner/phy-sun4i-usb.c: > ret = dm_gpio_set_dir_flags(>gpio_id_det, > GPIOD_IS_IN | > GPIOD_PULL_UP); > > Here GPIOD_PULL_UP is passed to dm_gpio_set_dir_flags() and filtered out by > dm_gpio_set_dir_flags(). > Looks, like we have to introduce dm_gpio_set_pull_flags() and use it together > with dm_gpio_set_dir_flags(). > > 4. u-boot/drivers/i2c/i2c-uclass.c > dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT | > > GPIOD_ACTIVE_LOW | > > GPIOD_IS_OUT_ACTIVE); Same as 1. Your patch cover that bug. > > > > > > 21 марта 2023 г., в 11:37, Bough Chen > написал(а): > > > >> -Original Message- > >> From: Alexander Kochetkov > >> Sent: 2023年3月20日 16:03 > >> To: h...@denx.de > >> Cc: Bough Chen ; ma...@denx.de; > >> u-boot@lists.denx.de; dl-uboot-imx ; > >> xypron.g...@gmx.de; Simon Glass > >> Subject: Re: [PATCH] i2c: correct I2C deblock logic > >> > >> Hello! > >> > >> The patch doesn’t add new functionality to the code. > >> May be it makes code more readable. But in later case the patch > >> description should be corrected and Fixes tag removed. > > > > Hi Alexander, > > > > This patch not only make the code more readable, but also really fix a bug. > > In our current code, we will call i2c_gpio_set_pin(scl_pin, 1) and then > i2c_gpio_set_pin(scl_pin, 0). > > After the i2c_gpio_set_pin(scl_pin, 0), the flags contain GPIOD_ACTIVE_LOW. > > Though for SDA, it will first call i2c_gpio_set_pin(sda_pin, 0) then > > i2c_gpio_set_pin(sda_pin, 1), but i2c_gpio_set_pin-> dm_gpio_set_dir_flags-> > dm_gpio_clrset_flags, it only clear GPIOD_MASK_DIR, this has no impact with > GPIOD_ACTIVE_LOW. So this GPIOD_ACTIVE_LOW keep in flags. > > Then call i2c_gpio_get_pin by using dm_gpio_get_value(pin) will get > > the wrong data, let the function i2c_deblock_gpio_loop always return > > -EREMOTEIO > > > > Best Regards > > Haibo Chen > > > >> > >> The flag GPIOD_ACTIVE_LOW affects return value dm_gpio_get_value(). > >> And return value doesn’t depends on the DTS settings. It depends on > >> the flag passed to dm_gpio_set_dir_flags(). Usually the code parses > >> DTS and provide the correct flag to the dm_gpio_set_dir_flags(). > >> > >> So the patch adds flag GPIOD_ACTIVE_LOW to the > >> dm_gpio_set_dir_flags() and as expected this negates the return value > >> of dm_gpio_get_value(). So in order to keep the code correct the > >> patch also fixes adds negotiation to dm_gpio_get_value(). > >> > >> Alexander. > >> > >> > >> > >>> 20 марта 2023 г., в 10:44, Heiko Schocher написал(а): > >>> > >>> Hi! > >>> > >>> On 13.03.23 03:55, Bough Chen wrote: > > -Original Message- > > From: Bough Chen > > Sent: 2023年2月10日 17:27 > > To: h...@denx.de; al.koc...@gmail.com; ma...@denx.de > > Cc: u-boot@lists.denx.de; dl-uboot-imx ; > > xypron.g...@gmx.de; Bough Chen > > Subject: [PATCH] i2c: correct I2C deblock logic > > > > From: Haibo Chen > > > > Current code use dm_gpio_get_value() to get SDA and SCL value, and > > the value depends on the flag GPIOD_ACTIVE_LOW. When toggle SCL to > > wait slave release SDA, the SDA are config as GPIOD_IS_IN, and > > whether contain the GPIOD_ACTIVE_LOW depends on the DTS setting. > > Usually, for I2C GPIO, we use GPIOD_ACTIVE_LOW flag in DTS, so if > > the SDA is in low level, then > > dm_gpio_get_value() will return 1, current code logic will stop > > the SCL toggle wrongly, cause the I2C deblock not work as expect. > > > > This patch force set the GPIOD_ACTIVE_LOW for both GPIOD_IS_IN and > > GPIOD_IS_OUT, and make the return value of i2c_gpio_get_pin() > > eaqual to the physical voltage logic level. > > > > Hi, > >
Re: [PATCH] i2c: correct I2C deblock logic
Hi Haibo.
Nice catch! Agree with you patch. But may be fix problem in general?
I suggest to add GPIOD_ACTIVE_LOW to the GPIOD_MASK_DIR mask to fix problems 1,
2, 4.
Not sure if that logically correct. What do you think?
I grepped the code for ‘dm_gpio_set_dir_flags’ and found another places
affected by the bug.
1. u-boot/drivers/spi/mxc_spi.c:
ret = dm_gpio_set_dir_flags(>cs_gpios[i],
GPIOD_IS_OUT | GPIOD_ACTIVE_LOW);
Here GPIOD_ACTIVE_LOW is passed to dm_gpio_set_dir_flags() and filtered out by
dm_gpio_set_dir_flags().
GPIOD_ACTIVE_LOW can be added to GPIOD_MASK_DIR mask to fix that.
2. u-boot/drivers/spi/mvebu_a3700_spi.c:
ret = dm_gpio_set_dir_flags(>cs_gpios[i],
GPIOD_IS_OUT | GPIOD_ACTIVE_LOW);
Same as 1.
3. u-boot/drivers/phy/allwinner/phy-sun4i-usb.c:
ret = dm_gpio_set_dir_flags(>gpio_id_det,
GPIOD_IS_IN | GPIOD_PULL_UP);
Here GPIOD_PULL_UP is passed to dm_gpio_set_dir_flags() and filtered out by
dm_gpio_set_dir_flags().
Looks, like we have to introduce dm_gpio_set_pull_flags() and use it together
with dm_gpio_set_dir_flags().
4. u-boot/drivers/i2c/i2c-uclass.c
dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT |
GPIOD_ACTIVE_LOW |
GPIOD_IS_OUT_ACTIVE);
Same as 1. Your patch cover that bug.
> 21 марта 2023 г., в 11:37, Bough Chen написал(а):
>
>> -Original Message-
>> From: Alexander Kochetkov
>> Sent: 2023年3月20日 16:03
>> To: h...@denx.de
>> Cc: Bough Chen ; ma...@denx.de;
>> u-boot@lists.denx.de; dl-uboot-imx ;
>> xypron.g...@gmx.de; Simon Glass
>> Subject: Re: [PATCH] i2c: correct I2C deblock logic
>>
>> Hello!
>>
>> The patch doesn’t add new functionality to the code.
>> May be it makes code more readable. But in later case the patch description
>> should be corrected and Fixes tag removed.
>
> Hi Alexander,
>
> This patch not only make the code more readable, but also really fix a bug.
> In our current code, we will call i2c_gpio_set_pin(scl_pin, 1) and then
> i2c_gpio_set_pin(scl_pin, 0).
> After the i2c_gpio_set_pin(scl_pin, 0), the flags contain GPIOD_ACTIVE_LOW.
> Though for SDA, it will first call i2c_gpio_set_pin(sda_pin, 0) then
> i2c_gpio_set_pin(sda_pin, 1), but
> i2c_gpio_set_pin-> dm_gpio_set_dir_flags-> dm_gpio_clrset_flags, it only
> clear GPIOD_MASK_DIR, this has no impact with GPIOD_ACTIVE_LOW. So this
> GPIOD_ACTIVE_LOW keep in flags.
> Then call i2c_gpio_get_pin by using dm_gpio_get_value(pin) will get the wrong
> data, let the function i2c_deblock_gpio_loop always return -EREMOTEIO
>
> Best Regards
> Haibo Chen
>
>>
>> The flag GPIOD_ACTIVE_LOW affects return value dm_gpio_get_value().
>> And return value doesn’t depends on the DTS settings. It depends on the flag
>> passed to dm_gpio_set_dir_flags(). Usually the code parses DTS and provide
>> the
>> correct flag to the dm_gpio_set_dir_flags().
>>
>> So the patch adds flag GPIOD_ACTIVE_LOW to the dm_gpio_set_dir_flags() and
>> as expected this negates the return value of dm_gpio_get_value(). So in
>> order to
>> keep the code correct the patch also fixes adds negotiation to
>> dm_gpio_get_value().
>>
>> Alexander.
>>
>>
>>
>>> 20 марта 2023 г., в 10:44, Heiko Schocher написал(а):
>>>
>>> Hi!
>>>
>>> On 13.03.23 03:55, Bough Chen wrote:
> -Original Message-
> From: Bough Chen
> Sent: 2023年2月10日 17:27
> To: h...@denx.de; al.koc...@gmail.com; ma...@denx.de
> Cc: u-boot@lists.denx.de; dl-uboot-imx ;
> xypron.g...@gmx.de; Bough Chen
> Subject: [PATCH] i2c: correct I2C deblock logic
>
> From: Haibo Chen
>
> Current code use dm_gpio_get_value() to get SDA and SCL value, and
> the value depends on the flag GPIOD_ACTIVE_LOW. When toggle SCL to
> wait slave release SDA, the SDA are config as GPIOD_IS_IN, and
> whether contain the GPIOD_ACTIVE_LOW depends on the DTS setting.
> Usually, for I2C GPIO, we use GPIOD_ACTIVE_LOW flag in DTS, so if
> the SDA is in low level, then
> dm_gpio_get_value() will return 1, current code logic will stop the
> SCL toggle wrongly, cause the I2C deblock not work as expect.
>
> This patch force set the GPIOD_ACTIVE_LOW for both GPIOD_IS_IN and
> GPIOD_IS_OUT, and make the return value of i2c_gpio_get_pin() eaqual
> to the physical voltage logic level.
>
Hi,
Any comments for this patch, just a reminder in case you miss it.
>>>
>>> Indeed, I missed this patch, sorry!
>>> Your explanation sounds reasonable to me, but I wonder if nobody
>>> tapped into this problem... it would be good to have some test reports
>>> from others! Also added Simon, as he did a lot of work in this space.
>>>
>>> Thanks!
>>>
>>> bye,
>>> Heiko
Best Regards
Haibo Chen
> Fixes: aa54192d4a87 ("dm:
RE: [PATCH] i2c: correct I2C deblock logic
> -Original Message-
> From: Alexander Kochetkov
> Sent: 2023年3月20日 16:03
> To: h...@denx.de
> Cc: Bough Chen ; ma...@denx.de;
> u-boot@lists.denx.de; dl-uboot-imx ;
> xypron.g...@gmx.de; Simon Glass
> Subject: Re: [PATCH] i2c: correct I2C deblock logic
>
> Hello!
>
> The patch doesn’t add new functionality to the code.
> May be it makes code more readable. But in later case the patch description
> should be corrected and Fixes tag removed.
Hi Alexander,
This patch not only make the code more readable, but also really fix a bug.
In our current code, we will call i2c_gpio_set_pin(scl_pin, 1) and then
i2c_gpio_set_pin(scl_pin, 0).
After the i2c_gpio_set_pin(scl_pin, 0), the flags contain GPIOD_ACTIVE_LOW.
Though for SDA, it will first call i2c_gpio_set_pin(sda_pin, 0) then
i2c_gpio_set_pin(sda_pin, 1), but
i2c_gpio_set_pin-> dm_gpio_set_dir_flags-> dm_gpio_clrset_flags, it only clear
GPIOD_MASK_DIR, this has no impact with GPIOD_ACTIVE_LOW. So this
GPIOD_ACTIVE_LOW keep in flags.
Then call i2c_gpio_get_pin by using dm_gpio_get_value(pin) will get the wrong
data, let the function i2c_deblock_gpio_loop always return -EREMOTEIO
Best Regards
Haibo Chen
>
> The flag GPIOD_ACTIVE_LOW affects return value dm_gpio_get_value().
> And return value doesn’t depends on the DTS settings. It depends on the flag
> passed to dm_gpio_set_dir_flags(). Usually the code parses DTS and provide the
> correct flag to the dm_gpio_set_dir_flags().
>
> So the patch adds flag GPIOD_ACTIVE_LOW to the dm_gpio_set_dir_flags() and
> as expected this negates the return value of dm_gpio_get_value(). So in order
> to
> keep the code correct the patch also fixes adds negotiation to
> dm_gpio_get_value().
>
> Alexander.
>
>
>
> > 20 марта 2023 г., в 10:44, Heiko Schocher написал(а):
> >
> > Hi!
> >
> > On 13.03.23 03:55, Bough Chen wrote:
> >>> -Original Message-
> >>> From: Bough Chen
> >>> Sent: 2023年2月10日 17:27
> >>> To: h...@denx.de; al.koc...@gmail.com; ma...@denx.de
> >>> Cc: u-boot@lists.denx.de; dl-uboot-imx ;
> >>> xypron.g...@gmx.de; Bough Chen
> >>> Subject: [PATCH] i2c: correct I2C deblock logic
> >>>
> >>> From: Haibo Chen
> >>>
> >>> Current code use dm_gpio_get_value() to get SDA and SCL value, and
> >>> the value depends on the flag GPIOD_ACTIVE_LOW. When toggle SCL to
> >>> wait slave release SDA, the SDA are config as GPIOD_IS_IN, and
> >>> whether contain the GPIOD_ACTIVE_LOW depends on the DTS setting.
> >>> Usually, for I2C GPIO, we use GPIOD_ACTIVE_LOW flag in DTS, so if
> >>> the SDA is in low level, then
> >>> dm_gpio_get_value() will return 1, current code logic will stop the
> >>> SCL toggle wrongly, cause the I2C deblock not work as expect.
> >>>
> >>> This patch force set the GPIOD_ACTIVE_LOW for both GPIOD_IS_IN and
> >>> GPIOD_IS_OUT, and make the return value of i2c_gpio_get_pin() eaqual
> >>> to the physical voltage logic level.
> >>>
> >>
> >> Hi,
> >>
> >> Any comments for this patch, just a reminder in case you miss it.
> >
> > Indeed, I missed this patch, sorry!
> > Your explanation sounds reasonable to me, but I wonder if nobody
> > tapped into this problem... it would be good to have some test reports
> > from others! Also added Simon, as he did a lot of work in this space.
> >
> > Thanks!
> >
> > bye,
> > Heiko
> >>
> >> Best Regards
> >> Haibo Chen
> >>
> >>> Fixes: aa54192d4a87 ("dm: i2c: implement gpio-based I2C deblock")
> >>> Signed-off-by: Haibo Chen
> >>> ---
> >>> drivers/i2c/i2c-uclass.c | 5 +++--
> >>> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
> >>> index
> >>> 8d9a89ed89..4dc707c659 100644
> >>> --- a/drivers/i2c/i2c-uclass.c
> >>> +++ b/drivers/i2c/i2c-uclass.c
> >>> @@ -505,7 +505,8 @@ uint i2c_get_chip_addr_offset_mask(struct
> >>> udevice
> >>> *dev) static void i2c_gpio_set_pin(struct gpio_desc *pin, int bit) {
> >>> if (bit)
> >>> - dm_gpio_set_dir_flags(pin, GPIOD_IS_IN);
> >>> + dm_gpio_set_dir_flags(pin, GPIOD_IS_IN |
> >>> +GPIOD_ACTIVE_LOW);
> >>> else
> >>> dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT |
> >>> GPIOD_ACTIVE_LOW |
> >>> @@ -514,7 +515,7 @@ static void i2c_gpio_set_pin(struct gpio_desc
> >>> *pin, int
> >>> bit)
> >>>
> >>> static int i2c_gpio_get_pin(struct gpio_desc *pin) {
> >>> - return dm_gpio_get_value(pin);
> >>> + return !dm_gpio_get_value(pin);
> >>> }
> >>>
> >>> int i2c_deblock_gpio_loop(struct gpio_desc *sda_pin,
> >>> --
> >>> 2.34.1
> >>
> >
> > --
> > DENX Software Engineering GmbH, Managing Director: Erika Unter
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Mon, 20 Mar 2023 at 21:33, Pali Rohár wrote: > On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár wrote: > > > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > > On Sun, 5 Mar 2023 at 11:55, 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. > > > > > > > > > > > > > > > > > > > I tested using the latest next branch which has those changes in > it. > > > > Steps: > > > > > > - Set UART boot mode on device > > > > > > - make clean > > > > > > - make clearfog_defconfig > > > > > > - make > > > > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > > > Detected kwbimage v1 with SDIO boot signature > > > > > > Patching image boot signature to UART > > > > > > Aligning image header to Xmodem block size > > > > > > Sending boot message. Please reboot the target...\ > > > > > > Sending boot image header (113408 bytes)... > > > > > > 0 % > > > > > > > > > > > [..] > > > > > > > > > > > > 94 % [.. > > > > > > ] > > > > > > Done > > > > > > > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31 > +1000) > > > > > > High speed PHY - Version: 2.0 > > > > > > EEPROM TLV detection failed: Using static config for Clearfog > Pro. > > > > > > Detected Device ID 6828 > > > > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tuesday 21 March 2023 08:03:45 Martin Rowe wrote: > On Mon, 20 Mar 2023 at 19:42, Pali Rohár wrote: > > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > Dedicated UART still works, patching an MMC for UART with kwboot still > > > hangs after finishing transfer; no change. > > > > One more question. Did you set boot mode HW switches to UART position? > > Or are they in MMC position and magic boot pattern from kwboot triggers > > UART boot? > > > > HW switches to UART position. Could you try also the second option. Put it into mmc position and use kwboot with magic pattern for booting? Just to ensure that if some HW reset occurs we will see boot log of mmc u-boot.
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote: > On Mon, 20 Mar 2023 at 17:33, Pali Rohár wrote: > > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote: > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár wrote: > > > > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár wrote: > > > > > > > > > > > Could you try to print mmc->part_config (ideally as early as > > possible)? > > > > > > > > > > > > > > > > In SPL mmc->part_config is 255 > > > > > In main u-boot at the start of clearfog.c board_init() > > mmc->part_config > > > > is > > > > > 255 > > > > > In main u-boot at the start of clearfog.c checkboard() > > mmc->part_config > > > > is > > > > > 8 (ack: 0, partition_enable: 1, access: 0) > > > > > > > > 255 is uninitialized value. > > > > > > > > > If I set partition_enable to 2, I get the same result except the > > value is > > > > > 16 (ack: 0, partition_enable: 2, access: 0) instead of 8 for the > > last > > > > value > > > > > > > > Try to change "access" bits. > > > > > > > > > > > > > > BootROM - 1.73 > > > > > > > > > > Booting from MMC > > > > > > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > > 10:05:32 > > > > > +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 > > > > > spl.c spl_boot_device part_config = 255 > > > > > Trying to boot from MMC1 > > > > > > > > > > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 > > +1000) > > > > > > > > > > SoC: MV88F6828-A0 at 1600 MHz > > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > > > > clearfog.c board_init part_config = 255 > > > > > 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 > > > > > clearfog.c checkboard part_config = 8 > > > > > Board: SolidRun Clearfog Pro > > > > > Net: > > > > > Warning: ethernet@7 (eth1) using random MAC address - > > > > 32:16:0e:b4:d1:d8 > > > > > eth1: ethernet@7 > > > > > Warning: ethernet@3 (eth2) using random MAC address - > > > > 72:30:3f:79:07:12 > > > > > , eth2: ethernet@3 > > > > > Warning: ethernet@34000 (eth3) using random MAC address - > > > > 82:fb:71:23:46:4f > > > > > , eth3: ethernet@34000 > > > > > Hit any key to stop autoboot: 0 > > > > > => mmc partconf 0 > > > > > EXT_CSD[179], PARTITION_CONFIG: > > > > > BOOT_ACK: 0x0 > > > > > BOOT_PARTITION_ENABLE: 0x1 > > > > > PARTITION_ACCESS: 0x0 > > > > > > > > > > > > > > > > > > > > BootROM - 1.73 > > > > > > > > > > Booting from MMC > > > > > > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > > 10:05:32 > > > > > +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 > > > > > spl.c spl_boot_device part_config = 255 > > > > > Trying to boot from MMC1 > > > > > > > > > > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 > > +1000) > > > > > > > > > > SoC: MV88F6828-A0 at 1600 MHz > > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > > > > clearfog.c board_init part_config = 255 > > > > > 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 > > > > > clearfog.c checkboard part_config = 16 > > > > > Board: SolidRun Clearfog Pro > > > > > Net: > > > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Mon, 20 Mar 2023 at 19:42, Pali Rohár wrote: > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > Dedicated UART still works, patching an MMC for UART with kwboot still > > hangs after finishing transfer; no change. > > One more question. Did you set boot mode HW switches to UART position? > Or are they in MMC position and magic boot pattern from kwboot triggers > UART boot? > HW switches to UART position.
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Mon, 20 Mar 2023 at 17:33, Pali Rohár wrote: > On Monday 20 March 2023 11:48:59 Martin Rowe wrote: > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár wrote: > > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár wrote: > > > > > > > > > Could you try to print mmc->part_config (ideally as early as > possible)? > > > > > > > > > > > > > In SPL mmc->part_config is 255 > > > > In main u-boot at the start of clearfog.c board_init() > mmc->part_config > > > is > > > > 255 > > > > In main u-boot at the start of clearfog.c checkboard() > mmc->part_config > > > is > > > > 8 (ack: 0, partition_enable: 1, access: 0) > > > > > > 255 is uninitialized value. > > > > > > > If I set partition_enable to 2, I get the same result except the > value is > > > > 16 (ack: 0, partition_enable: 2, access: 0) instead of 8 for the > last > > > value > > > > > > Try to change "access" bits. > > > > > > > > > > > BootROM - 1.73 > > > > > > > > Booting from MMC > > > > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > 10:05:32 > > > > +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 > > > > spl.c spl_boot_device part_config = 255 > > > > Trying to boot from MMC1 > > > > > > > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 > +1000) > > > > > > > > SoC: MV88F6828-A0 at 1600 MHz > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > > > clearfog.c board_init part_config = 255 > > > > 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 > > > > clearfog.c checkboard part_config = 8 > > > > Board: SolidRun Clearfog Pro > > > > Net: > > > > Warning: ethernet@7 (eth1) using random MAC address - > > > 32:16:0e:b4:d1:d8 > > > > eth1: ethernet@7 > > > > Warning: ethernet@3 (eth2) using random MAC address - > > > 72:30:3f:79:07:12 > > > > , eth2: ethernet@3 > > > > Warning: ethernet@34000 (eth3) using random MAC address - > > > 82:fb:71:23:46:4f > > > > , eth3: ethernet@34000 > > > > Hit any key to stop autoboot: 0 > > > > => mmc partconf 0 > > > > EXT_CSD[179], PARTITION_CONFIG: > > > > BOOT_ACK: 0x0 > > > > BOOT_PARTITION_ENABLE: 0x1 > > > > PARTITION_ACCESS: 0x0 > > > > > > > > > > > > > > > > BootROM - 1.73 > > > > > > > > Booting from MMC > > > > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > 10:05:32 > > > > +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 > > > > spl.c spl_boot_device part_config = 255 > > > > Trying to boot from MMC1 > > > > > > > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 > +1000) > > > > > > > > SoC: MV88F6828-A0 at 1600 MHz > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > > > clearfog.c board_init part_config = 255 > > > > 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 > > > > clearfog.c checkboard part_config = 16 > > > > Board: SolidRun Clearfog Pro > > > > Net: > > > > Warning: ethernet@7 (eth1) using random MAC address - > > > 92:5a:fc:14:e8:f6 > > > > eth1: ethernet@7 > > > > Warning: ethernet@3 (eth2) using random MAC address - > > > 42:9c:d8:3a:cb:b2 > > > > , eth2: ethernet@3 > > > > Warning: ethernet@34000 (eth3) using random MAC address - > > > c6:99:20:f4:02:a0 > > > > ,
Re: [PATCH] pci: Handle failed calloc in decode_regions()
Am So., 4. Dez. 2022 um 22:22 Uhr schrieb Pierre-Clément Tosi
:
>
> Hi,
>
> On Fri, Dec 02, 2022 at 08:38:37PM +0100, s...@geanix.com wrote:
> >
> > Quoting Pierre-Clément Tosi :
> >
> > > Add a check for calloc() failing to allocate the requested memory.
> > >
> > > Make decode_regions() return an error code.
> > >
> > > Cc: Bin Meng
> > > Cc: Simon Glass
> > > Cc: Stefan Roese
> > > Signed-off-by: Pierre-Clément Tosi
> > > ---
> >
> > Hi,
> >
> > We upgraded from v2022.04 -> v2022.10, and this PATCH breaks PCI (scsi/sata)
> > support for x86_64.
> > I have seen this in qemu, i havn't had the time to test this on real
> > hardware.
> >
> > Steps to reproduce:
> > $ make efi-x86_payload64_defconfig && make -j32 && scripts/build-efi.sh
> > -sPrp
>
Breaks my use case too and is basically a revert of
https://source.denx.de/u-boot/u-boot/-/commit/f2825f6ec0bb50e7bd9376828a32212f1961f979
In my use case we are using coreboot for different Intel SoCs with a
generic U-Boot payload.
> Decompiling the resulting u-boot.dtb shows
>
> pci {
> compatible = "pci-x86";
> u-boot,dm-pre-reloc;
> };
>
Yes.. that is what can be found here:
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/x86/dts/coreboot.dts#L34
> which isn't supported by the patch as we return -EINVAL when missing "ranges".
> The rationale here was that the property seemed mandatory (see [1] and [2]);
> was
> this a misunderstanding of potential corner cases?
>
At the moment I would like to revert this change.
> OTOH, I see that most DTS using "pci-x86" (a pseudo-device intended to act as
> a
> PCI bus) actually provide "ranges". In particular, a comment added by
> 0ced70a0bb7a ("x86: tpl: Add a fake PCI bus") states that
>
> The BARs are allocated statically in the device tree.
>
> So I'll let others comment on this but either:
>
> - arch/x86/dts/efi-x86_payload.dts (and a few other DTS) is missing "ranges";
> or
> - pci_uclass_pre_probe() should treat UCLASS_SIMPLE_BUS differently.
>
> [1]:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> [2]: IEEE Std 1275-1994
>
> >
> > Br,
> > /Sean
> >
> > > drivers/pci/pci-uclass.c | 15 ++-
> > > 1 file changed, 10 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> > > index 970ee1adf1..2c85e78a13 100644
> > > --- a/drivers/pci/pci-uclass.c
> > > +++ b/drivers/pci/pci-uclass.c
> > > @@ -954,7 +954,7 @@ int pci_bind_bus_devices(struct udevice *bus)
> > > return 0;
> > > }
> > >
> > > -static void decode_regions(struct pci_controller *hose, ofnode
> > > parent_node,
> > > +static int decode_regions(struct pci_controller *hose, ofnode
> > > parent_node,
> > >ofnode node)
> > > {
> > > int pci_addr_cells, addr_cells, size_cells;
> > > @@ -968,7 +968,7 @@ static void decode_regions(struct pci_controller
> > > *hose, ofnode parent_node,
> > > prop = ofnode_get_property(node, "ranges", );
> > > if (!prop) {
> > > debug("%s: Cannot decode regions\n", __func__);
> > > - return;
> > > + return -EINVAL;
> > > }
> > >
> > > pci_addr_cells = ofnode_read_simple_addr_cells(node);
> > > @@ -986,6 +986,8 @@ static void decode_regions(struct pci_controller
> > > *hose, ofnode parent_node,
> > > max_regions = len / cells_per_record + CONFIG_NR_DRAM_BANKS;
> > > hose->regions = (struct pci_region *)
> > > calloc(1, max_regions * sizeof(struct pci_region));
> > > + if (!hose->regions)
> > > + return -ENOMEM;
> > >
> > > for (i = 0; i < max_regions; i++, len -= cells_per_record) {
> > > u64 pci_addr, addr, size;
> > > @@ -1053,7 +1055,7 @@ static void decode_regions(struct pci_controller
> > > *hose, ofnode parent_node,
> > > /* Add a region for our local memory */
> > > bd = gd->bd;
> > > if (!bd)
> > > - return;
> > > + return 0;
> > >
> > > for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
> > > if (bd->bi_dram[i].size) {
> > > @@ -1068,7 +1070,7 @@ static void decode_regions(struct pci_controller
> > > *hose, ofnode parent_node,
> > > }
> > > }
> > >
> > > - return;
> > > + return 0;
> > > }
> > >
> > > static int pci_uclass_pre_probe(struct udevice *bus)
> > > @@ -1097,7 +1099,10 @@ static int pci_uclass_pre_probe(struct udevice
> > > *bus)
> > > /* For bridges, use the top-level PCI controller */
> > > if (!device_is_on_pci_bus(bus)) {
> > > hose->ctlr = bus;
> > > - decode_regions(hose, dev_ofnode(bus->parent),
> > > dev_ofnode(bus));
> > > + ret = decode_regions(hose, dev_ofnode(bus->parent),
> > > +dev_ofnode(bus));
> > > + if (ret)
> > > + return ret;
> > > } else {
> > > struct pci_controller *parent_hose;
> > >
> > > --
> > >
Re: [PATCH] fs: fat: do not mangle short filenames
Am 20.03.2023 um 18:01 schrieb Tom Rini: On Fri, Mar 17, 2023 at 01:04:13PM +0100, Stefan Herbrechtsmeier wrote: From: Stefan Herbrechtsmeier Do not mangle lower or mixed case filenames which fit into the upper case 8.3 short filename. This ensures FAT standard compatible short filenames (SFN) to support systems without long filename (LFN) support like boot roms (ex. SFN BOOT.BIN instead of BOOT~1.BIN for LFN boot.bin). Signed-off-by: Stefan Herbrechtsmeier --- fs/fat/fat_write.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) Can we update test/py/tests/test_fs/ somewhere to have a test for this case? Thanks. What is the recommended approach to test internal behavior? The short name isn't avialable at the terminal because u-boot support VFAT.
Re: [PATCH v3 3/4] efi_loader: check lowest supported version in capsule update
On 3/20/23 06:54, Masahisa Kojima wrote:
The FMP Payload Header which EDK2 capsule generation scripts
insert contains lowest supported version.
This commit reads the lowest supported version stored in the
"FmpState" EFI non-volatile variable, then check if the
firmware version of ongoing capsule is equal or greater than
the lowest supported version.
Signed-off-by: Masahisa Kojima
---
No changes since v2
Changes in v2:
- add error message when the firmware version is lower than
lowest supported version
lib/efi_loader/efi_firmware.c | 50 ++-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
index 289456ecbb..8d6e32006d 100644
--- a/lib/efi_loader/efi_firmware.c
+++ b/lib/efi_loader/efi_firmware.c
@@ -391,6 +391,39 @@ void efi_firmware_parse_payload_header(const void
**p_image,
*p_image_size = image_size;
}
+/**
+ * efi_firmware_get_lowest_supported_version - get the lowest supported version
+ * @image_index: image_index
+ *
+ * Get the lowest supported version from FmpState variable.
+ *
+ * Return: lowest supported version, return 0 if reading
FmpState
+ * variable failed
+ */
+static
+u32 efi_firmware_get_lowest_supported_version(u8 image_index)
+{
+ u16 varname[13]; /* u"FmpState" */
+ efi_status_t ret;
+ efi_uintn_t size;
+ efi_guid_t *image_type_id;
+ struct fmp_state var_state = { 0 };
+
+ image_type_id = efi_firmware_get_image_type_id(image_index);
+ if (!image_type_id)
+ return 0;
+
+ efi_create_indexed_name(varname, sizeof(varname), "FmpState",
+ image_index);
+ size = sizeof(var_state);
+ ret = efi_get_variable_int(varname, image_type_id, NULL, ,
+ _state, NULL);
+ if (ret != EFI_SUCCESS)
+ return 0;
+
+ return var_state.lowest_supported_version;
+}
+
/**
* efi_firmware_verify_image - verify image
* @p_image: Pointer to new image
@@ -398,7 +431,8 @@ void efi_firmware_parse_payload_header(const void **p_image,
* @image_index Image index
* @state Pointer to fmp state
*
- * Verify the capsule file
+ * Verify the capsule authentication and check if the fw_version
+ * is equal or greater than the lowest supported version.
*
* Return:status code
*/
@@ -409,10 +443,24 @@ efi_status_t efi_firmware_verify_image(const void
**p_image,
struct fmp_state *state)
{
efi_status_t ret;
+ u32 lowest_supported_version;
ret = efi_firmware_capsule_authenticate(p_image, p_image_size, state);
efi_firmware_parse_payload_header(p_image, p_image_size, state);
+ /* check lowest_supported_version if capsule authentication passes */
+ if (ret == EFI_SUCCESS) {
+ lowest_supported_version =
+ efi_firmware_get_lowest_supported_version(image_index);
+ if (lowest_supported_version > state->fw_version) {
+ printf("fw_version(%u) is too low(expected >%u). Aborting
update\n",
+ state->fw_version, lowest_supported_version);
Please, use log_warning() or log_err() instead of printf().
The addressee is a user not a developer:
"Firmware version %u too low. Expecting >= %u"
We should have one central place where upon exit we write a message
indicating that either the capsule update was successful or failed.
"Firmware updated to version %u" : "Firmware update failed"
Best regards
Heinrich
+ state->last_attempt_status =
+ LAST_ATTEMPT_STATUS_ERROR_INCORRECT_VERSION;
+ ret = EFI_INVALID_PARAMETER;
+ }
+ }
+
return ret;
}
Re: [PATCH v3 1/4] efi_loader: store firmware version into FmpState variable
On 3/20/23 06:54, Masahisa Kojima wrote:
Firmware version management is not implemented in the current
FMP protocol.
EDK2 reference implementation capsule generation script inserts
the FMP Payload Header right before the payload, it contains the
firmware version and lowest supported version.
This commit utilizes the FMP Payload Header, read the header and
%s/read/reads/
stores the firmware version, lowest supported version,
last attempt version and last attempt status into "FmpState"
EFI non-volatile variable. indicates the image index,
since FMP protocol handles multiple image indexes.
This change is compatible with the existing FMP implementation.
This change does not mandate the FMP Payload Header.
If no FMP Payload Header is found in the capsule file, fw_version,
lowest supported version, last attempt version and last attempt
status is 0 and this is the same behavior as existing FMP
implementation.
Signed-off-by: Masahisa Kojima
---
Changes in v3:
- exclude CONFIG_FWU_MULTI_BANK_UPDATE case
- set image_type_id as a vendor field of FmpState variable
- set READ_ONLY flag for FmpState variable
- add error code for FIT image case
Changes in v2:
- modify indent
lib/efi_loader/efi_firmware.c | 224 ++
1 file changed, 201 insertions(+), 23 deletions(-)
diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
index 93e2b01c07..d6f3741024 100644
--- a/lib/efi_loader/efi_firmware.c
+++ b/lib/efi_loader/efi_firmware.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -36,6 +37,24 @@ struct fmp_payload_header {
u32 lowest_supported_version;
};
+/**
+ * struct fmp_state - fmp firmware update state
+ *
+ * This structure describes the state of the firmware update
+ * through FMP protocol.
+ *
+ * @fw_version:Firmware versions used
+ * @lowest_supported_version: Lowest supported version
+ * @last_attempt_version: Last attempt version
+ * @last_attempt_status: Last attempt status
+ */
+struct fmp_state {
+ u32 fw_version;
+ u32 lowest_supported_version;
+ u32 last_attempt_version;
+ u32 last_attempt_status;
+};
+
__weak void set_dfu_alt_info(char *interface, char *devstr)
{
env_set("dfu_alt_info", update_info.dfu_string);
@@ -102,6 +121,29 @@ efi_status_t EFIAPI
efi_firmware_set_package_info_unsupported(
return EFI_EXIT(EFI_UNSUPPORTED);
}
+/**
+ * efi_firmware_get_image_type_id - get image_type_id
+ * @image_index: image index
+ *
+ * Return the image_type_id identified by the image index.
+ *
+ * Return: pointer to the image_type_id, NULL if image_index is
invalid
+ */
+static
+efi_guid_t *efi_firmware_get_image_type_id(u8 image_index)
+{
+ int i;
+ struct efi_fw_image *fw_array;
+
+ fw_array = update_info.images;
+ for (i = 0; i < num_image_type_guids; i++) {
+ if (fw_array[i].image_index == image_index)
+ return _array[i].image_type_id;
+ }
+
+ return NULL;
+}
+
/**
* efi_fill_image_desc_array - populate image descriptor array
* @image_info_size: Size of @image_info
@@ -182,6 +224,7 @@ static efi_status_t efi_fill_image_desc_array(
* efi_firmware_capsule_authenticate - authenticate the capsule if enabled
* @p_image: Pointer to new image
* @p_image_size: Pointer to size of new image
+ * @state Pointer to fmp state
*
* Authenticate the capsule if authentication is enabled.
* The image pointer and the image size are updated in case of success.
@@ -190,12 +233,11 @@ static efi_status_t efi_fill_image_desc_array(
*/
static
efi_status_t efi_firmware_capsule_authenticate(const void **p_image,
- efi_uintn_t *p_image_size)
+ efi_uintn_t *p_image_size,
+ struct fmp_state *state)
{
const void *image = *p_image;
efi_uintn_t image_size = *p_image_size;
- u32 fmp_hdr_signature;
- struct fmp_payload_header *header;
void *capsule_payload;
efi_status_t status;
efi_uintn_t capsule_payload_size;
@@ -209,8 +251,12 @@ efi_status_t efi_firmware_capsule_authenticate(const void
**p_image,
if (status == EFI_SECURITY_VIOLATION) {
printf("Capsule authentication check failed. Aborting
update\n");
+ state->last_attempt_status =
+ LAST_ATTEMPT_STATUS_ERROR_AUTH_ERROR;
return status;
} else if (status != EFI_SUCCESS) {
+ state->last_attempt_status =
+ LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL;
return status;
}
@@ -222,24 +268,130 @@ efi_status_t
