Re: [PATCH v2 0/4] arm: Add Analog Devices SC5xx Machine Type
On Wed, Apr 24, 2024 at 08:03:59PM -0400, Greg Malysa wrote: > This series adds support for the ADI SC5xx machine type and includes two > core drivers that are required for being able to boot any board--a UART > driver, the gptimer driver which is used as a clock reference (CNTVCNT > is not supported on the armv7 sc5xx SoCs) and the clock tree driver. Our > corresponding Linux support relies on u-boot configuring the clocks > correctly before booting, so it is not possible to boot any board > without the CGU/CDU configuration happening here. There are also no > board files, device trees, or defconfigs included here, but some common > definitions that will be used to build board files currently are. The > sc5xx SoCs themselves include many armv7 families (sc57x, sc58x, and > sc594) all using an ARM Cortex-A5, and one armv8 family (sc598) indended > to be a drop-in replacement for the SC594 in terms of peripherals, with > a Cortex-A55 instead. > > Some of the configuration code in dmcinit and clkinit is quite scary and > causes a lot of checkpatch violations. It is modified from code > initially provided by ADI, but it has not been fully rewritten. There's > a question of how important it is to clean up this code--it has some > quality violations, but it has been in use (including in production) for > over two years and is known to work for performing the low level SoC > initialization, while a rewrite might introduce timing or sequence bugs > that could take a significant amount of time to detect in the future. I gave the series a cursory look, and CI is also happy. I will put this in to the -next branch sometime soon after it opens, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH] configs: am62x_evm_r5: Increase size of malloc_simple heap after relocation
On Mon, Apr 29, 2024 at 04:49:36PM -0500, Judith Mendez wrote:
> On AM62x SK we can see a boot failure with signature "alloc space
> exhausted", so fix by increasing size of SPL_STACK_R_MALLOC_SIMPLE_LEN.
>
> Fixes: 128f81290b ("arm: dts: k3: binman: am625: add support for signing
> TIFSSTUB Images")
> Signed-off-by: Judith Mendez
> Tested-by: Alexander Sverdlin
> Reviewed-by: Bryan Brattlof
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] net: consider option-length when parsing NIS domain
On Tue, Apr 23, 2024 at 09:09:44AM +0200, Heinrich Schuchardt wrote:
> When parsing option 40 (network information service domain) the
> option length is in variable 'oplen' and not in 'size'.
>
> Addresses-Coverity-ID: 492765 Uninitialized variables (UNINIT)
> Fixes: 8ab388bfdbcf ("net: add support to parse the NIS domain for the dhcp
> options")
> Signed-off-by: Heinrich Schuchardt
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v1 3/3] board: arbel: Limit the dram effective size to bank0 maximal size
On Tue, Apr 23, 2024 at 03:22:10PM +0800, Jim Liu wrote: > For 4GB dram size, the dram is divided into 2 banks and > the address space of these 2 banks are not concatenated. > Limit the gd->ram_top to not exceed bank0 top to prevent > accessing invalid memory region. > > Signed-off-by: Jim Liu Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] MAINTAINERS: update Broadcom BCMBCA maintainer
On Thu, 02 May 2024 22:23:43 -0700, William Zhang wrote: > Joel is no longer with Broadcom. Remove his email from bcmbca maintainer > list and replace him with myself for stack protection maintainer. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v1 2/3] configs: arbel: increase u-boot mapping size
On Tue, Apr 23, 2024 at 03:22:09PM +0800, Jim Liu wrote: > When u-boot enable CONFIG_SYS_BOOT_RAMDISK_HIGH, rootfs image relocated > from FIU address space to memory address before jump to kernel. > > Since Arbel reserved memory from 0x to 0x0620 for tip image, > and rootfs image may too large that cannot found a suitable location > before 128MB(0x800), so increase mapping size from 128MB to 192MB. > > Signed-off-by: Jim Liu Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 1/3] Arm: npcm: fix npcm7xx boot to kernel error
On Tue, Apr 23, 2024 at 03:22:08PM +0800, Jim Liu wrote: > Add mem and console env information and modify the wrong earlycon env. > > Signed-off-by: Jim Liu Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1] spi: npcm_pspi: Reset HW in driver probe
On Tue, Apr 23, 2024 at 02:38:42PM +0800, Jim Liu wrote: > Reset HW to clear old status and use default data mode(8-bit). > > Signed-off-by: Jim Liu Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] cmd: gpt: initialize partition table
On Mon, Apr 22, 2024 at 11:47:33PM +0530, Kishan Dudhatra wrote: > Change in v2: > - Fix applies to all block devices, not just MMC. > > If partition init is not completed within the gpt write, > the gpt partition list will not be updated. > > Signed-off-by: Kishan Dudhatra > > diff --git a/cmd/gpt.c b/cmd/gpt.c > index d7e96529a6..7aaf1889a5 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] binman: Fix typo in mkimage etype description
On Fri, Apr 26, 2024 at 12:54:08AM +0200, Marek Vasut wrote: > Fix a typo, no functional change. > > Signed-off-by: Marek Vasut > Reviewed-by: Quentin Schulz Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] tools: typo arguemnts
On Fri, Apr 19, 2024 at 01:37:46PM +0200, Heinrich Schuchardt wrote: > %s/arguemnts/arguemnts/ > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] event: typo arguemnts
On Fri, Apr 19, 2024 at 01:37:45PM +0200, Heinrich Schuchardt wrote: > %s/arguemnts/arguments/ > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 4/4] configs: visionfive2: enable SPL_YMODEM_SUPPORT
On Fri, May 3, 2024 at 2:01 AM Heinrich Schuchardt wrote: > > We can use U-Boot for recovering JH7110 based boards via UART > if CONFIG_SPL_YMODEM_SUPPORT=y. > > * Send u-boot-spl.normal.out via XMODEM. > * Send u-boot.itb via YMODEM. > > Signed-off-by: Heinrich Schuchardt > --- > v2: > no change > --- > configs/starfive_visionfive2_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/starfive_visionfive2_defconfig > b/configs/starfive_visionfive2_defconfig > index 3bbd1dbd67c..174ac24dc74 100644 > --- a/configs/starfive_visionfive2_defconfig > +++ b/configs/starfive_visionfive2_defconfig > @@ -62,6 +62,7 @@ CONFIG_SPL_I2C=y > CONFIG_SPL_DM_SPI_FLASH=y > CONFIG_SPL_DM_RESET=y > CONFIG_SPL_SPI_LOAD=y > +CONFIG_SPL_YMODEM_SUPPORT=y > CONFIG_SYS_PROMPT="StarFive # " > CONFIG_CMD_EEPROM=y > CONFIG_SYS_EEPROM_SIZE=512 > -- > 2.43.0 > Reviewed-by: E. Shattow
Re: [PATCH v2 2/4] board: add support for Milk-V Mars CM
On Fri, May 3, 2024 at 2:00 AM Heinrich Schuchardt
wrote:
>
> We already support the VisionFive 2 and the Milk-V Mars board by
> patching the VisionFive 2 device tree. With this patch the same
> is done for the Milk-V Mars CM.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> rename spl_fdt_fixup_marc() to spl_fdt_fixup_mars_cm()
> rename device-trees for Mars CM and Mars CM Lite
> change model and compatible properties
> ---
> board/starfive/visionfive2/spl.c | 28 ++-
> .../visionfive2/starfive_visionfive2.c| 11 +++-
> 2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/board/starfive/visionfive2/spl.c
> b/board/starfive/visionfive2/spl.c
> index ca61b5be227..b555189556a 100644
> --- a/board/starfive/visionfive2/spl.c
> +++ b/board/starfive/visionfive2/spl.c
> @@ -129,6 +129,30 @@ void spl_fdt_fixup_mars(void *fdt)
> }
> }
>
> +void spl_fdt_fixup_mars_cm(void *fdt)
> +{
> + const char *compat;
> + const char *model;
> +
> + spl_fdt_fixup_mars(fdt);
> +
> + if (!get_mmc_size_from_eeprom()) {
> + int offset;
> +
> + model = "Milk-V Mars CM Lite";
> + compat = "milkv,mars-cm-lite\0starfive,jh7110";
> +
> + offset = fdt_path_offset(fdt,
> "/soc/pinctrl/mmc0-pins/mmc0-pins-rest");
> + /* GPIOMUX(22, GPOUT_SYS_SDIO0_RST, GPOEN_ENABLE, GPI_NONE) */
> + fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016);
> + } else {
> + model = "Milk-V Mars CM";
> + compat = "milkv,mars-cm\0starfive,jh7110";
> + }
> + fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat,
> sizeof(compat));
> + fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", model);
> +}
> +
> void spl_fdt_fixup_version_a(void *fdt)
> {
> static const char compat[] =
> "starfive,visionfive-2-v1.2a\0starfive,jh7110";
> @@ -236,7 +260,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
> pr_err("Can't read EEPROM\n");
> return;
> }
> - if (!strncmp(product_id, "MARS", 4)) {
> + if (!strncmp(product_id, "MARC", 4)) {
> + spl_fdt_fixup_mars_cm(spl_image->fdt_addr);
> + } else if (!strncmp(product_id, "MARS", 4)) {
> spl_fdt_fixup_mars(spl_image->fdt_addr);
> } else if (!strncmp(product_id, "VF7110", 6)) {
> version = get_pcb_revision_from_eeprom();
> diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
> b/board/starfive/visionfive2/starfive_visionfive2.c
> index a86bca533b2..6be53489626 100644
> --- a/board/starfive/visionfive2/starfive_visionfive2.c
> +++ b/board/starfive/visionfive2/starfive_visionfive2.c
> @@ -19,6 +19,10 @@ DECLARE_GLOBAL_DATA_PTR;
> #define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000
> #define FDTFILE_MILK_V_MARS \
> "starfive/jh7110-milkv-mars.dtb"
> +#define FDTFILE_MILK_V_MARS_CM \
> + "starfive/jh7110-milkv-mars-cm.dtb"
> +#define FDTFILE_MILK_V_MARS_CM_LITE \
> + "starfive/jh7110-milkv-mars-cm-lite.dtb"
> #define FDTFILE_VISIONFIVE2_1_2A \
> "starfive/jh7110-starfive-visionfive-2-v1.2a.dtb"
> #define FDTFILE_VISIONFIVE2_1_3B \
> @@ -61,7 +65,12 @@ static void set_fdtfile(void)
> log_err("Can't read EEPROM\n");
> return;
> }
> - if (!strncmp(product_id, "MARS", 4)) {
> + if (!strncmp(product_id, "MARC", 4)) {
> + if (get_mmc_size_from_eeprom())
> + fdtfile = FDTFILE_MILK_V_MARS_CM;
> + else
> + fdtfile = FDTFILE_MILK_V_MARS_CM_LITE;
> + } else if (!strncmp(product_id, "MARS", 4)) {
> fdtfile = FDTFILE_MILK_V_MARS;
> } else if (!strncmp(product_id, "VF7110", 6)) {
> version = get_pcb_revision_from_eeprom();
> --
> 2.43.0
>
on Mars CM Lite and DFRobot mini router carrier
Tested-by: E. Shattow
Reviewed-by: E. Shattow
Re: [PATCH v2 3/4] doc: Milk-V Mars CM and Milk-V Mars CM Lite
Hi, looking good to me except $fdtfile filename changes were missed to match the code, and then testing inspires a few more things to suggest. On Fri, May 3, 2024 at 2:01 AM Heinrich Schuchardt wrote: > > Provide a man-page describing the usage of U-Boot on > the Milk-V Mars CM and Milk-V Mars CM Lite boards. > > Signed-off-by: Heinrich Schuchardt > --- > v2: > refer to tio as tool for booting via UART > describe how to update serial number > description updates as suggested by E. Shattow > --- > doc/board/starfive/index.rst | 1 + > doc/board/starfive/milk-v_mars_cm.rst | 183 ++ > 2 files changed, 184 insertions(+) > create mode 100644 doc/board/starfive/milk-v_mars_cm.rst > > diff --git a/doc/board/starfive/index.rst b/doc/board/starfive/index.rst > index 2762bf74c11..afa85ad2540 100644 > --- a/doc/board/starfive/index.rst > +++ b/doc/board/starfive/index.rst > @@ -7,4 +7,5 @@ StarFive > :maxdepth: 1 > > milk-v_mars.rst > + milk-v_mars_cm.rst > visionfive2 > diff --git a/doc/board/starfive/milk-v_mars_cm.rst > b/doc/board/starfive/milk-v_mars_cm.rst > new file mode 100644 > index 000..d2be064d94c > --- /dev/null > +++ b/doc/board/starfive/milk-v_mars_cm.rst > @@ -0,0 +1,183 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +Milk-V Mars CM > +== > + > +U-Boot for the Milk-V Mars CM uses the same U-Boot binaries as the > VisionFive 2 > +board. In U-Boot SPL the actual board is detected and the device-tree patched > +accordingly. > + > +The Milk-V Mars CM Lite comes without eMMC and needs a different pin muxing > +than the Milk-V Mars CM. The availability and size of the eMMC shows up in > the > +serial number displayed by the *mac* command, e.g. > +MARC-V10-2340-D002E016-0304. The number after the E is the MMC size. > U-Boot > +takes a value of E000 as an indicator for the Lite version. Unfortunately the > +vendor has not set this value correctly on some Lite boards. > + > +Please, use CONFIG_STARFIVE_NO_EMMC=y if EEPROM data indicates eMMC is > present > +on the Milk-V Mars CM Lite. Otherwise you will not be able to read from the > +SD-card. > + > +The serial number can be corrected using the *mac* command: > + > +.. code-block:: > + > +mac read_eeprom > +mac product_id MARC-V10-2340-D002E000-0304 > +mac write_eeprom > + > +By default the EEPROM is write protected. The write protection may be > overcome > +by connecting the "GND" and "EN" test pads on top of the module. With adding boards based on VisionFive2 and having different vendor info in EEPROM, the mac command should be extended for setting vendor info from user input. Vendor info is currently not changeable back to "MILK-V" after *mac initialize* sets vendor as "StarFive Technology Co., Ltd." If mac command can be extended then the documentation here is sufficient, else some description warning the user not to *mac initialize* on platforms other than VisionFive2 from StarFive. > + > +Building > + > + > +1. Add the RISC-V toolchain to your PATH. > +2. Setup ARCH & cross compilation environment variable: > + > +.. code-block:: none > + > + export CROSS_COMPILE= > + > +The M-mode software OpenSBI provides the supervisor binary interface (SBI) > and > +is responsible for the switch to S-Mode. It is a prerequisite to build > U-Boot. > +Support for the JH7110 was introduced in OpenSBI 1.2. It is recommended to > use > +a current release. > + > +.. code-block:: console > + > + git clone https://github.com/riscv/opensbi.git > + cd opensbi > + make PLATFORM=generic FW_TEXT_START=0x4000 > + > +(*FW_TEXT_START* is not needed anymore after OpenSBI patch d4d2582eef7a > +"firmware: remove FW_TEXT_START" which should appear in OpenSBI 1.5.) > + > +Now build the U-Boot SPL and U-Boot proper. > + > +.. code-block:: console > + > + cd > + make starfive_visionfive2_defconfig > + make > OPENSBI=$(opensbi_dir)/build/platform/generic/firmware/fw_dynamic.bin > + > +This will generate the U-Boot SPL image (spl/u-boot-spl.bin.normal.out) as > well > +as the FIT image (u-boot.itb) with OpenSBI and U-Boot. > + > +Device-tree selection > +~ > + > +Depending on the board version U-Boot sets variable $fdtfile to either > +starfive/jh7110-milkv-mars-cm-emmc.dtb (for the generic version or > +starfive/jh7110-milkv-mars-cm-sdcard.dtb (for the Lite version). "Depending on the board version U-Boot sets variable $fdtfile to either starfive/jh7110-milkv-mars-cm.dtb (with eMMC storage) or starfive/jh7110-milkv-mars-cm-lite.dtb (without eMMC storage)." > + > +To overrule this selection the variable can be set manually and saved in the > +environment > + > +:: > + > +setenv fdtfile my_device-tree.dtb > +env save env set fdtfile my_device-tree.dtb env save > + > +or the configuration variable CONFIG_DEFAULT_FDT_FILE can be used to set to > +provide a default value. An additi
Re: [PATCH v2 1/4] board: starfive: function to read eMMC size
On Fri, May 3, 2024 at 2:01 AM Heinrich Schuchardt
wrote:
>
> The EEPROM provides information about the size of the eMMC.
> Provide a new function get_mmc_size_from_eeprom() to read it.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> fix typos in get_mmc_size_from_eeprom() description
> ---
> arch/riscv/include/asm/arch-jh7110/eeprom.h| 7 +++
> board/starfive/visionfive2/Kconfig | 9 +
> .../visionfive2/visionfive2-i2c-eeprom.c | 18 ++
> 3 files changed, 34 insertions(+)
>
> diff --git a/arch/riscv/include/asm/arch-jh7110/eeprom.h
> b/arch/riscv/include/asm/arch-jh7110/eeprom.h
> index 62d184aeb57..45ad2a5f7bc 100644
> --- a/arch/riscv/include/asm/arch-jh7110/eeprom.h
> +++ b/arch/riscv/include/asm/arch-jh7110/eeprom.h
> @@ -12,6 +12,13 @@
> u8 get_pcb_revision_from_eeprom(void);
> u32 get_ddr_size_from_eeprom(void);
>
> +/**
> + * get_mmc_size_from_eeprom() - read eMMC size from EEPROM
> + *
> + * @return: size in GiB or 0 on error.
> + */
> +u32 get_mmc_size_from_eeprom(void);
> +
> /**
> * get_product_id_from_eeprom - get product ID string
> *
> diff --git a/board/starfive/visionfive2/Kconfig
> b/board/starfive/visionfive2/Kconfig
> index 2186a939646..d7e8a7a7d78 100644
> --- a/board/starfive/visionfive2/Kconfig
> +++ b/board/starfive/visionfive2/Kconfig
> @@ -50,4 +50,13 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> imply PHY_LIB
> imply PHY_MSCC
>
> +config STARFIVE_NO_EMMC
> + bool "Report eMMC size as zero"
> + help
> + The serial number string in the EEPROM is meant to report the
> + size of onboard eMMC. Unfortunately some Milk-V Mars CM Lite
> + modules without eMMC show a non-zero size here.
> +
> + Set to 'Y' if you have a Mars CM Lite module.
> +
> endif
> diff --git a/board/starfive/visionfive2/visionfive2-i2c-eeprom.c
> b/board/starfive/visionfive2/visionfive2-i2c-eeprom.c
> index 5095a0e9fdb..9648a270494 100644
> --- a/board/starfive/visionfive2/visionfive2-i2c-eeprom.c
> +++ b/board/starfive/visionfive2/visionfive2-i2c-eeprom.c
> @@ -548,6 +548,24 @@ u32 get_ddr_size_from_eeprom(void)
> return hextoul(&pbuf.eeprom.atom1.data.pstr[14], NULL);
> }
>
> +u32 get_mmc_size_from_eeprom(void)
> +{
> + u32 size;
> +
> + if (IS_ENABLED(CONFIG_STARFIVE_NO_EMMC))
> + return 0;
> +
> + if (read_eeprom())
> + return 0;
> +
> + size = dectoul(&pbuf.eeprom.atom1.data.pstr[19], NULL);
> +
> + if (pbuf.eeprom.atom1.data.pstr[21] == 'T')
> + size <<= 10;
> +
> + return size;
> +}
> +
> U_BOOT_LONGHELP(mac,
> "\n"
> "- display EEPROM content\n"
> --
> 2.43.0
>
Reviewed-by: E. Shattow
Re: [PATCH 1/2] dm: core: add support for fallback drivers
On Fri, May 03, 2024 at 05:53:11PM +0200, Caleb Connolly wrote:
> Hi all,
>
> Sorry for the slow follow-up.
>
> On 11/04/2024 04:37, Sean Anderson wrote:
> > On 4/10/24 15:44, Tom Rini wrote:
> > > On Wed, Apr 10, 2024 at 07:27:17PM +0200, Heinrich Schuchardt wrote:
> > > >
> > > >
> > > > Am 10. April 2024 19:06:57 MESZ schrieb Caleb Connolly
> > > > :
> > > > > Introduce support for a uclass to provide a fallback/stub driver which
> > > > > can be used when no device is found for a given node. This might be
> > > > > useful for handling non-essential clock controllers like the RPMh on
> > > > > Qualcomm platforms, or during early bringup to get UART output before
> > > > > a
> > > > > real clock driver has been created.
> > > > >
> > > > > Signed-off-by: Caleb Connolly
> > > > > ---
> > > > > drivers/core/Kconfig | 10 ++
> > > > > drivers/core/uclass.c | 24 +++-
> > > > > include/dm/uclass.h | 3 +++
> > > > > 3 files changed, 36 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
> > > > > index 1081d61fcf01..09075b9b7a15 100644
> > > > > --- a/drivers/core/Kconfig
> > > > > +++ b/drivers/core/Kconfig
> > > > > @@ -466,5 +466,15 @@ config BOUNCE_BUFFER
> > > > >
> > > > > A second possible use of bounce buffers is their ability to
> > > > > provide aligned buffers for DMA operations.
> > > > >
> > > > > +menuconfig FALLBACK_DRIVERS
> > > >
> > > > Wouldn't it be preferable to mark individual drivers as fallback
> > > > drivers in their declaration?
> > > >
> > > > This would allow alternative fallback drivers and would not
> > > > require any definitions at uclass level.
> > > >
> > > > Just by building a fallback driver you would enable the fallback
> > > > behavior for its uclass.
> > >
> > > I think some of this is addressed in the cover letter. My concern /
> > > questions come down to I think just a matter of naming. Both "fallback"
> > > and "stub" are used at times. As a concept, we have some areas where we
> > > need a no-op driver because whereas the DT describes a relationship in
> > > the hardware, here in U-Boot we can just accept things as configured. To
> > > me "fallback" implies more functionality of the driver when it's really
> > > just a generic no-op driver to fill in the dependencies within the tree.
> > > Can we rename things a bit along those lines?
>
> Yes, will do. I originally used "stub" but then decided "fallback" was
> better, but I think you're right that stub is the right way to go here. As I
> agree that "fallback" implies some kind of real implementation.
> > >
> >
> > I would rather just have a stub driver with compatibles for all clocks
> > we want
> > it to match. I think having a generic fallback driver could cause issues
> > in the
> > future if we need to switch over to using a real driver.
>
> I don't think either approach is significantly better from a developer
> perspective. With my patches if there a driver with a matching compatible
> available then you will NEVER bind the stub, even if probe fails on the real
> driver. With your proposal we'd have to remember to remove the compatible
> from the stub driver or risk the race condition when binding drivers.
>
> There is another subtle but important difference if we were to use a
> compatible list in the stub. It turns out that CONFIG_OF_LIVE affects the
> bind behaviour - U-Boot won't try to bind the children of a node with no
> driver when using the livetree. This is arguably more "correct", as usually
> child devices depend on their parent, so we save some cycles by not binding
> unsupported devices.
>
> But, the RPM clock controller which I originally implemented this feature
> for is such a case, this is the DT (simplified for brevity):
>
> rpm: remoteproc {
> compatible = "qcom,sm6115-rpm-proc", "qcom,rpm-proc";
>
> glink-edge {
> compatible = "qcom,glink-rpm";
>
> rpm_requests: rpm-requests {
> compatible = "qcom,rpm-sm6115";
>
> rpmcc: clock-controller {
> compatible = "qcom,rpmcc-sm6115", "qcom,rpmcc";
> };
> };
> };
>
> With livetree (which we use on qcom) we would need to stub not just the
> rpmcc but also the rpm-requests, the glink bus, and the remoteproc (yeah
> these platforms are a bit silly, I know XD).
>
> However with the fallback solution as implemented in these patches, we
> totally sidestep this issue by directly binding the node on-demand,
> something we can only safely do for a stub driver as we don't need the
> parent devices.
>
> So I can either:
>
> 1) Make OF_LIVE behave like flattree and descend into all nodes (I don't
> know if this would cause any issues, but I think the livetree behaviour is
> more "correct" tbh).
> 2) Add stubs for all 3 of the parent nodes (and manually maintain a table of
> compatibles for clock drivers we want to stub).
> 3) Stick with this approach of bindin
Re: [PATCH v4] test/py: net_boot: Add test cases for net boot
On Fri, May 03, 2024 at 05:39:46PM +0530, Love Kumar wrote:
> Add tests for booting image using tftpboot/pxe boot commands, tftpboot
> boot case loads the FIT image into DDR and boots using bootm command
> whereas pxe boot cases downloads the pxe configuration file from the
> TFTP server and interprets it to boot the images mentioned in the pxe
> configurations file.
> This test relies on boardenv_* containing configuration values including
> the parameter 'pattern'. tftpboot/pxe boot cases boots the Linux till the
> boot log pattern value is matched. For example, if the parameter
> 'pattern' is defined as 'login:', it will boot till login prompt.
>
> Signed-off-by: Love Kumar
I'm not quite sure where the problem is, next. After enabling FIT image
support in my build so I can use the image I have on hand:
U-Boot> tftpboot 20 v6.6/image.fit.nocomp
Waiting for Ethernet connection... done.
Using smsc95xx_eth device
TFTP from server 192.168.1.10; our IP address is 192.168.1.100
Filename 'v6.6/image.fit.nocomp'.
Load address: 0x20
Loading: ## 82 MiB
3.2 MiB/s
done
Bytes transferred = 85984256 (5200400 hex)
U-Boot> U-Boot> crc32 20 $filesize
CRC32 for 0020 ... 054003ff ==> 754c839a
U-Boot> U-Boot> bootm 20
## Loading kernel from FIT Image at 0020 ...
Could not find configuration node
ERROR -2: can't get kernel image!
U-Boot>
And in u_boot_boardenv_rpi_arm64.py:
env__tftp_boot_test_skip = False
env__net_tftp_bootable_file = {
'fn': 'v6.6/image.fit.nocomp',
'addr': 0x0020,
'size': 85984256,
'crc32': '754c839a',
'pattern': 'Linux',
'config': 'conf-852',
}
But it's not trying to boot conf-852 but instead just passing the
address. This image lacks a default config, which your example has and I
think is why the tests work in your case.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v4] test/py: net_boot: Add test cases for net boot
On Fri, May 03, 2024 at 05:39:46PM +0530, Love Kumar wrote: > Add tests for booting image using tftpboot/pxe boot commands, tftpboot > boot case loads the FIT image into DDR and boots using bootm command > whereas pxe boot cases downloads the pxe configuration file from the > TFTP server and interprets it to boot the images mentioned in the pxe > configurations file. > This test relies on boardenv_* containing configuration values including > the parameter 'pattern'. tftpboot/pxe boot cases boots the Linux till the > boot log pattern value is matched. For example, if the parameter > 'pattern' is defined as 'login:', it will boot till login prompt. > > Signed-off-by: Love Kumar > --- > Changes in v2: > - Expand commit message > Changes in v3: > - Add the config option to skip the test > - Remove imi command to check FIT image config > - Configure static networking only if DHCP fails > Changes in v4: > - Use configured timeout for tftpboot Getting closer! Can we make this more robust and check for failure strings too? For example: U-Boot> tftpboot 20 v6.6/image.fit.nocomp Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.1.10; our IP address is 192.168.1.100 Filename 'v6.6/image.fit.nocomp'. Load address: 0x20 Loading: ## 82 MiB 2.7 MiB/s done Bytes transferred = 85984256 (5200400 hex) U-Boot> U-Boot> crc32 20 $filesize CRC32 for 0020 ... 054003ff ==> 754c839a U-Boot> U-Boot> bootm 20 Wrong Image Type for bootm command ERROR -91: can't get kernel image! U-Boot> This only fails when we hit timeout. -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/5] dma: ti: k3-udma: invalidate prepared buffers before pushing to recv ring
Hello Matthias, On Fri, 2024-04-26 at 10:02 +0200, Matthias Schiffer wrote: > Buffers must not have an unclean cache before being used for DMA - a > pending write-back may corrupt the next dev-to-mem transfer otherwise. > > This was consistently noticeable during long TFTP transfers, when an ARP > request is answered by U-Boot in the middle of the transfer: > > As U-Boot's arp_receive() reuses the receive buffer to prepare its > reply packet, the beginning of one of the next incoming TFTP packets > is overwritten by the ARP reply. The corrupted packet is ignored, but > the TFTP transfer stalls for a few seconds until a timeout is detected > and a retransmit is triggered. > > Signed-off-by: Matthias Schiffer thanks for the series! I've tested it on a custom AM625-based board issuing a a couple of pings: am65_cpsw_nuss ethernet@800: K3 CPSW: nuss_ver: 0x6BA01103 cpsw_ver: 0x6BA81103 ale_ver: 0x00290105 Ports:2 Net: eth0: ethernet@800port@1 Autobooting in 3 seconds, press "" to stop U-Boot# ping 192.168.251.10 ti-udma dma-controller@485c: k3_dmaring Ring probed rings:150, sci-dev-id:30 ti-udma dma-controller@485c: dma-ring-reset-quirk: disabled am65_cpsw_nuss_port ethernet@800port@1: K3 CPSW: rflow_id_base: 19 link up on port 1, speed 100, full duplex Using ethernet@800port@1 device host 192.168.251.10 is alive U-Boot# ping 192.168.251.10 am65_cpsw_nuss_port ethernet@800port@1: K3 CPSW: rflow_id_base: 19 link up on port 1, speed 100, full duplex Using ethernet@800port@1 device host 192.168.251.10 is alive This sequence looks exactly the same with your patches and without. Therefore for the whole series: Tested-by: Alexander Sverdlin > --- > drivers/dma/ti/k3-udma.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c > index 4e6f7f570c5..8f6d396653e 100644 > --- a/drivers/dma/ti/k3-udma.c > +++ b/drivers/dma/ti/k3-udma.c > @@ -2678,6 +2678,9 @@ int udma_prepare_rcv_buf(struct dma *dma, void *dst, > size_t size) > cppi5_hdesc_set_pktlen(desc_rx, size); > cppi5_hdesc_attach_buf(desc_rx, dma_dst, size, dma_dst, size); > > + invalidate_dcache_range((unsigned long)dma_dst, > + (unsigned long)(dma_dst + size)); > + > flush_dcache_range((unsigned long)desc_rx, > ALIGN((unsigned long)desc_rx + > uc->config.hdesc_size, > ARCH_DMA_MINALIGN)); -- Alexander Sverdlin Siemens AG www.siemens.com
usb boot
Hello, I have a little problem. If I boot via usb, uboot does not download the uboot.env file at startup, but if I run the saveenv command, it will save the variables in the same directory where u-boot.bin lies. Best regards, Dmitry Voronin
Re: [PATCH v2 0/2] introduce basic support for TI's am625-lp-sk
Sorry everyone I hit send a little to fast on this one! On May 3, 2024 thus sayeth Bryan Brattlof: > Hello Everyone! > > The am625-lp-sk is a variant of the am625-sk showcasing the low-power > features of the am625 SoC Family. Because it's essentially a board and > package spin of the am625-sk I've inherited the am625 configuration and > overridden what was needed. > > This is a new spin of Nitin's original work which has been updated > significantly since October 2023 > > https://lore.kernel.org/u-boot/20231030110138.1347603-1-n-ya...@ti.com/ > > Unfortunately a patch is need on top of this series to boot: > > https://lore.kernel.org/u-boot/20240429214936.15187-1...@ti.com > > For those of us interested here is proof of life using buildroot: > >https://paste.sr.ht/~bryanb/40f7787f7760bee383aa8fbc342a29e8544dbdab > > Thank you for reviewing > ~Bryan > > Signed-off-by: Bryan Brattlof > --- > Changes in v2: > - updated copyright year > - Link to v1: > https://lore.kernel.org/r/20240429-am62q-wip-v1-0-927fd2e0a...@ti.com > Didn't actually fixup the copyright year. Just sent out v3 which actually did what I said I was going to :/ Sorry for the spam. ~Bryan
[PATCH v3 1/2] arm: dts: add U-Boot dtbs for the am625-lp-sk
From: Nitin Yadav
Add the U-Boot device tree overrides for the am62x-lp-sk reference
board.
Signed-off-by: Nitin Yadav
Reviewed-by: Dhruva Gole
Signed-off-by: Bryan Brattlof
---
arch/arm/dts/k3-am62-lp-sk-binman.dtsi | 21 +
arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi | 17 +
arch/arm/dts/k3-am62-lp4-50-800-800.dtsi | 2190 ++
arch/arm/dts/k3-am62-r5-lp-sk.dts| 82 ++
4 files changed, 2310 insertions(+)
diff --git a/arch/arm/dts/k3-am62-lp-sk-binman.dtsi
b/arch/arm/dts/k3-am62-lp-sk-binman.dtsi
new file mode 100644
index 0..18341d0d3f2e7
--- /dev/null
+++ b/arch/arm/dts/k3-am62-lp-sk-binman.dtsi
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+#include "k3-am625-sk-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM625_A53_EVM
+
+#define SPL_AM62_LP_SK_DTB "spl/dts/ti/k3-am62-lp-sk.dtb"
+
+&spl_am625_sk_dtb {
+ filename = SPL_AM62_LP_SK_DTB;
+};
+
+&spl_am625_sk_dtb_unsigned {
+ filename = SPL_AM62_LP_SK_DTB;
+};
+
+#endif
diff --git a/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi
b/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi
new file mode 100644
index 0..cbcc7f3bb45cb
--- /dev/null
+++ b/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AM62x LP SK dts file for SPLs
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-am62-lp-sk-binman.dtsi"
+
+/ {
+ chosen {
+ tick-timer = &main_timer0;
+ };
+};
+
+&main_timer0 {
+ clock-frequency = <2500>;
+};
diff --git a/arch/arm/dts/k3-am62-lp4-50-800-800.dtsi
b/arch/arm/dts/k3-am62-lp4-50-800-800.dtsi
new file mode 100644
index 0..c255ae6530f5b
--- /dev/null
+++ b/arch/arm/dts/k3-am62-lp4-50-800-800.dtsi
@@ -0,0 +1,2190 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * This file was generated with the
+ * AM62x SysConfig DDR Subsystem Register Configuration Tool v0.09.07
+ * Wed Mar 01 2023 17:52:11 GMT-0600 (Central Standard Time)
+ * DDR Type: LPDDR4
+ * F0 = 50MHzF1 = NA F2 = 800MHz
+ * Density (per channel): 16Gb
+ * Write DBI: Enable
+ * Number of Ranks: 1
+ */
+
+#define DDRSS_PLL_FHS_CNT 3
+#define DDRSS_PLL_FREQUENCY_1 4
+#define DDRSS_PLL_FREQUENCY_2 4
+
+#define DDRSS_CTL_0_DATA 0x0B00
+#define DDRSS_CTL_1_DATA 0x
+#define DDRSS_CTL_2_DATA 0x
+#define DDRSS_CTL_3_DATA 0x
+#define DDRSS_CTL_4_DATA 0x
+#define DDRSS_CTL_5_DATA 0x
+#define DDRSS_CTL_6_DATA 0x
+#define DDRSS_CTL_7_DATA 0x2710
+#define DDRSS_CTL_8_DATA 0x000186A0
+#define DDRSS_CTL_9_DATA 0x0005
+#define DDRSS_CTL_10_DATA 0x0064
+#define DDRSS_CTL_11_DATA 0x00027100
+#define DDRSS_CTL_12_DATA 0x00186A00
+#define DDRSS_CTL_13_DATA 0x0005
+#define DDRSS_CTL_14_DATA 0x0640
+#define DDRSS_CTL_15_DATA 0x00027100
+#define DDRSS_CTL_16_DATA 0x00186A00
+#define DDRSS_CTL_17_DATA 0x0005
+#define DDRSS_CTL_18_DATA 0x0640
+#define DDRSS_CTL_19_DATA 0x01010100
+#define DDRSS_CTL_20_DATA 0x01010100
+#define DDRSS_CTL_21_DATA 0x01000110
+#define DDRSS_CTL_22_DATA 0x02010002
+#define DDRSS_CTL_23_DATA 0x000A
+#define DDRSS_CTL_24_DATA 0x000186A0
+#define DDRSS_CTL_25_DATA 0x
+#define DDRSS_CTL_26_DATA 0x
+#define DDRSS_CTL_27_DATA 0x
+#define DDRSS_CTL_28_DATA 0x
+#define DDRSS_CTL_29_DATA 0x00020200
+#define DDRSS_CTL_30_DATA 0x
+#define DDRSS_CTL_31_DATA 0x
+#define DDRSS_CTL_32_DATA 0x
+#define DDRSS_CTL_33_DATA 0x
+#define DDRSS_CTL_34_DATA 0x0810
+#define DDRSS_CTL_35_DATA 0x2020
+#define DDRSS_CTL_36_DATA 0x
+#define DDRSS_CTL_37_DATA 0x
+#define DDRSS_CTL_38_DATA 0x040C
+#define DDRSS_CTL_39_DATA 0x
+#define DDRSS_CTL_40_DATA 0x081C
+#define DDRSS_CTL_41_DATA 0x
+#define DDRSS_CTL_42_DATA 0x081C
+#define DDRSS_CTL_43_DATA 0x
+#define DDRSS_CTL_44_DATA 0x05000804
+#define DDRSS_CTL_45_DATA 0x0700
+#define DDRSS_CTL_46_DATA 0x09090004
+#define DDRSS_CTL_47_DATA 0x0203
+#define DDRSS_CTL_48_DATA 0x00320007
+#define DDRSS_CTL_49_DATA 0x09090023
+#define DDRSS_CTL_50_DATA 0x190F
+#define DDRSS_CTL_51_DATA 0x00320007
+#define DDRSS_CTL_52_DATA 0x09090023
+#define DDRSS_CTL_53_DATA 0x0900190F
+#define DDRSS_CTL_54_DATA 0x000A0A09
+#define DDRSS_CTL_55_DATA 0x040006DB
+#define DDRSS_CTL_56_DATA 0x09092004
+#define DDRSS_CTL_57_DATA 0x0C0A
+#define DDRSS_CTL_58_DATA 0x06006DB0
+#define DDRSS_CTL_59_DATA 0x09092006
+#define DDRSS_CTL_60_DATA 0x0C0A
+#define DDRSS_CTL_61_DATA 0x06006DB0
+#define DDRSS_CTL_62_DATA 0x03042006
+#define DDRSS_CTL_63_DATA 0x04050002
+#define DDRSS_CTL_64_DATA 0x100F100F
+#define DDRSS_CTL_65_DATA 0x01010008
+#define DDRSS_CTL_66_DATA 0x041F1F07
+#define DDRSS_CTL_67_DATA 0x0303
+#define DDRSS_CTL_68_DATA 0x111
[PATCH v3 0/2] introduce basic support for TI's am625-lp-sk
Hello Everyone! The am625-lp-sk is a variant of the am625-sk showcasing the low-power features of the am625 SoC Family. Because it's essentially a board and package spin of the am625-sk I've inherited the am625 configuration and overridden what was needed. This is a new spin of Nitin's original work which has been updated significantly since October 2023 https://lore.kernel.org/u-boot/20231030110138.1347603-1-n-ya...@ti.com/ Unfortunately a patch is need on top of this series to boot: https://lore.kernel.org/u-boot/20240429214936.15187-1...@ti.com For those of us interested here is proof of life using buildroot: https://paste.sr.ht/~bryanb/40f7787f7760bee383aa8fbc342a29e8544dbdab Thank you for reviewing ~Bryan Signed-off-by: Bryan Brattlof --- Changes in v3: - actually update the copyright year - Link to v2: https://lore.kernel.org/r/20240429-am62q-wip-v2-0-e78f09174...@ti.com Changes in v2: - updated copyright year - Link to v1: https://lore.kernel.org/r/20240429-am62q-wip-v1-0-927fd2e0a...@ti.com --- Bryan Brattlof (1): configs: add defconfigs for the am625-lp-sk Nitin Yadav (1): arm: dts: add U-Boot dtbs for the am625-lp-sk arch/arm/dts/k3-am62-lp-sk-binman.dtsi | 21 + arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi | 17 + arch/arm/dts/k3-am62-lp4-50-800-800.dtsi | 2190 ++ arch/arm/dts/k3-am62-r5-lp-sk.dts| 82 ++ configs/am62x_lp_sk_a53_defconfig|3 + configs/am62x_lp_sk_r5_defconfig |2 + 6 files changed, 2315 insertions(+) --- base-commit: 714d31ca73fe1dd7a8217afc4a9f6a35ef7a9c01 change-id: 20240429-am62q-wip-f3453de038fb Best regards, -- Bryan Brattlof
[PATCH v3 2/2] configs: add defconfigs for the am625-lp-sk
The am62x-lp-sk is a package and reference board spin of the am62x-sk to showcase the low-power features of the am62x SoC family. Because it so closely resembles the am62x-sk board, use the preprocessor to inherit its configuration making the needed changes for this board where necessary. Reviewed-by: Dhruva Gole Signed-off-by: Bryan Brattlof --- configs/am62x_lp_sk_a53_defconfig | 3 +++ configs/am62x_lp_sk_r5_defconfig | 2 ++ 2 files changed, 5 insertions(+) diff --git a/configs/am62x_lp_sk_a53_defconfig b/configs/am62x_lp_sk_a53_defconfig new file mode 100644 index 0..904b2142b2f53 --- /dev/null +++ b/configs/am62x_lp_sk_a53_defconfig @@ -0,0 +1,3 @@ +#include +CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am62-lp-sk" +CONFIG_OF_UPSTREAM=y diff --git a/configs/am62x_lp_sk_r5_defconfig b/configs/am62x_lp_sk_r5_defconfig new file mode 100644 index 0..93b3922e6fec5 --- /dev/null +++ b/configs/am62x_lp_sk_r5_defconfig @@ -0,0 +1,2 @@ +#include +CONFIG_DEFAULT_DEVICE_TREE="k3-am62-r5-lp-sk" -- 2.43.2
Re: [PATCH v3] configs: rk3588-turing-rk1: disable SPI flash by default
Hi Sam,
On 5/2/24 10:07 PM, Sam Edwards wrote:
While the Turing RK1 board has a pad on the PCB for SPI flash, it is
not populated at the factory: supporting SPI flash boot is a user
modification, not an out-of-the-box feature. The defconfig for this
board should therefore not be enabling the SPI flash image nor SPI
support in the SPL, as it causes confusion among downstream users as to
whether the SPI image needs to be distributed.
Fixes: 153ac950a599 ("board: rockchip: Add the Turing RK1 SoM")
Suggested-by: Florian Klink
Signed-off-by: Sam Edwards
Acked-by: Joshua Riek
Reviewed-by: Jonas Karlman
Reviewed=by: Quentin Schulz
Thanks,
Quentin
[PATCH v2 1/2] arm: dts: add U-Boot dtbs for the am625-lp-sk
From: Nitin Yadav
Add the U-Boot device tree overrides for the am62x-lp-sk reference
board.
Signed-off-by: Nitin Yadav
Reviewed-by: Dhruva Gole
Signed-off-by: Bryan Brattlof
---
arch/arm/dts/k3-am62-lp-sk-binman.dtsi | 21 +
arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi | 17 +
arch/arm/dts/k3-am62-lp4-50-800-800.dtsi | 2190 ++
arch/arm/dts/k3-am62-r5-lp-sk.dts| 82 ++
4 files changed, 2310 insertions(+)
diff --git a/arch/arm/dts/k3-am62-lp-sk-binman.dtsi
b/arch/arm/dts/k3-am62-lp-sk-binman.dtsi
new file mode 100644
index 0..de425a4b54f81
--- /dev/null
+++ b/arch/arm/dts/k3-am62-lp-sk-binman.dtsi
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+#include "k3-am625-sk-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM625_A53_EVM
+
+#define SPL_AM62_LP_SK_DTB "spl/dts/ti/k3-am62-lp-sk.dtb"
+
+&spl_am625_sk_dtb {
+ filename = SPL_AM62_LP_SK_DTB;
+};
+
+&spl_am625_sk_dtb_unsigned {
+ filename = SPL_AM62_LP_SK_DTB;
+};
+
+#endif
diff --git a/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi
b/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi
new file mode 100644
index 0..08f572446657e
--- /dev/null
+++ b/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AM62x LP SK dts file for SPLs
+ * Copyright (C) 2021-2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-am62-lp-sk-binman.dtsi"
+
+/ {
+ chosen {
+ tick-timer = &main_timer0;
+ };
+};
+
+&main_timer0 {
+ clock-frequency = <2500>;
+};
diff --git a/arch/arm/dts/k3-am62-lp4-50-800-800.dtsi
b/arch/arm/dts/k3-am62-lp4-50-800-800.dtsi
new file mode 100644
index 0..c255ae6530f5b
--- /dev/null
+++ b/arch/arm/dts/k3-am62-lp4-50-800-800.dtsi
@@ -0,0 +1,2190 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * This file was generated with the
+ * AM62x SysConfig DDR Subsystem Register Configuration Tool v0.09.07
+ * Wed Mar 01 2023 17:52:11 GMT-0600 (Central Standard Time)
+ * DDR Type: LPDDR4
+ * F0 = 50MHzF1 = NA F2 = 800MHz
+ * Density (per channel): 16Gb
+ * Write DBI: Enable
+ * Number of Ranks: 1
+ */
+
+#define DDRSS_PLL_FHS_CNT 3
+#define DDRSS_PLL_FREQUENCY_1 4
+#define DDRSS_PLL_FREQUENCY_2 4
+
+#define DDRSS_CTL_0_DATA 0x0B00
+#define DDRSS_CTL_1_DATA 0x
+#define DDRSS_CTL_2_DATA 0x
+#define DDRSS_CTL_3_DATA 0x
+#define DDRSS_CTL_4_DATA 0x
+#define DDRSS_CTL_5_DATA 0x
+#define DDRSS_CTL_6_DATA 0x
+#define DDRSS_CTL_7_DATA 0x2710
+#define DDRSS_CTL_8_DATA 0x000186A0
+#define DDRSS_CTL_9_DATA 0x0005
+#define DDRSS_CTL_10_DATA 0x0064
+#define DDRSS_CTL_11_DATA 0x00027100
+#define DDRSS_CTL_12_DATA 0x00186A00
+#define DDRSS_CTL_13_DATA 0x0005
+#define DDRSS_CTL_14_DATA 0x0640
+#define DDRSS_CTL_15_DATA 0x00027100
+#define DDRSS_CTL_16_DATA 0x00186A00
+#define DDRSS_CTL_17_DATA 0x0005
+#define DDRSS_CTL_18_DATA 0x0640
+#define DDRSS_CTL_19_DATA 0x01010100
+#define DDRSS_CTL_20_DATA 0x01010100
+#define DDRSS_CTL_21_DATA 0x01000110
+#define DDRSS_CTL_22_DATA 0x02010002
+#define DDRSS_CTL_23_DATA 0x000A
+#define DDRSS_CTL_24_DATA 0x000186A0
+#define DDRSS_CTL_25_DATA 0x
+#define DDRSS_CTL_26_DATA 0x
+#define DDRSS_CTL_27_DATA 0x
+#define DDRSS_CTL_28_DATA 0x
+#define DDRSS_CTL_29_DATA 0x00020200
+#define DDRSS_CTL_30_DATA 0x
+#define DDRSS_CTL_31_DATA 0x
+#define DDRSS_CTL_32_DATA 0x
+#define DDRSS_CTL_33_DATA 0x
+#define DDRSS_CTL_34_DATA 0x0810
+#define DDRSS_CTL_35_DATA 0x2020
+#define DDRSS_CTL_36_DATA 0x
+#define DDRSS_CTL_37_DATA 0x
+#define DDRSS_CTL_38_DATA 0x040C
+#define DDRSS_CTL_39_DATA 0x
+#define DDRSS_CTL_40_DATA 0x081C
+#define DDRSS_CTL_41_DATA 0x
+#define DDRSS_CTL_42_DATA 0x081C
+#define DDRSS_CTL_43_DATA 0x
+#define DDRSS_CTL_44_DATA 0x05000804
+#define DDRSS_CTL_45_DATA 0x0700
+#define DDRSS_CTL_46_DATA 0x09090004
+#define DDRSS_CTL_47_DATA 0x0203
+#define DDRSS_CTL_48_DATA 0x00320007
+#define DDRSS_CTL_49_DATA 0x09090023
+#define DDRSS_CTL_50_DATA 0x190F
+#define DDRSS_CTL_51_DATA 0x00320007
+#define DDRSS_CTL_52_DATA 0x09090023
+#define DDRSS_CTL_53_DATA 0x0900190F
+#define DDRSS_CTL_54_DATA 0x000A0A09
+#define DDRSS_CTL_55_DATA 0x040006DB
+#define DDRSS_CTL_56_DATA 0x09092004
+#define DDRSS_CTL_57_DATA 0x0C0A
+#define DDRSS_CTL_58_DATA 0x06006DB0
+#define DDRSS_CTL_59_DATA 0x09092006
+#define DDRSS_CTL_60_DATA 0x0C0A
+#define DDRSS_CTL_61_DATA 0x06006DB0
+#define DDRSS_CTL_62_DATA 0x03042006
+#define DDRSS_CTL_63_DATA 0x04050002
+#define DDRSS_CTL_64_DATA 0x100F100F
+#define DDRSS_CTL_65_DATA 0x01010008
+#define DDRSS_CTL_66_DATA 0x041F1F07
+#define DDRSS_CTL_67_DATA 0x0303
+#define DDRSS_CTL_68_DATA 0x00
[PATCH v2 2/2] configs: add defconfigs for the am625-lp-sk
The am62x-lp-sk is a package and reference board spin of the am62x-sk to showcase the low-power features of the am62x SoC family. Because it so closely resembles the am62x-sk board, use the preprocessor to inherit its configuration making the needed changes for this board where necessary. Reviewed-by: Dhruva Gole Signed-off-by: Bryan Brattlof --- configs/am62x_lp_sk_a53_defconfig | 3 +++ configs/am62x_lp_sk_r5_defconfig | 2 ++ 2 files changed, 5 insertions(+) diff --git a/configs/am62x_lp_sk_a53_defconfig b/configs/am62x_lp_sk_a53_defconfig new file mode 100644 index 0..904b2142b2f53 --- /dev/null +++ b/configs/am62x_lp_sk_a53_defconfig @@ -0,0 +1,3 @@ +#include +CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am62-lp-sk" +CONFIG_OF_UPSTREAM=y diff --git a/configs/am62x_lp_sk_r5_defconfig b/configs/am62x_lp_sk_r5_defconfig new file mode 100644 index 0..93b3922e6fec5 --- /dev/null +++ b/configs/am62x_lp_sk_r5_defconfig @@ -0,0 +1,2 @@ +#include +CONFIG_DEFAULT_DEVICE_TREE="k3-am62-r5-lp-sk" -- 2.43.2
[PATCH v2 0/2] introduce basic support for TI's am625-lp-sk
Hello Everyone! The am625-lp-sk is a variant of the am625-sk showcasing the low-power features of the am625 SoC Family. Because it's essentially a board and package spin of the am625-sk I've inherited the am625 configuration and overridden what was needed. This is a new spin of Nitin's original work which has been updated significantly since October 2023 https://lore.kernel.org/u-boot/20231030110138.1347603-1-n-ya...@ti.com/ Unfortunately a patch is need on top of this series to boot: https://lore.kernel.org/u-boot/20240429214936.15187-1...@ti.com For those of us interested here is proof of life using buildroot: https://paste.sr.ht/~bryanb/40f7787f7760bee383aa8fbc342a29e8544dbdab Thank you for reviewing ~Bryan Signed-off-by: Bryan Brattlof --- Changes in v2: - updated copyright year - Link to v1: https://lore.kernel.org/r/20240429-am62q-wip-v1-0-927fd2e0a...@ti.com --- Bryan Brattlof (1): configs: add defconfigs for the am625-lp-sk Nitin Yadav (1): arm: dts: add U-Boot dtbs for the am625-lp-sk arch/arm/dts/k3-am62-lp-sk-binman.dtsi | 21 + arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi | 17 + arch/arm/dts/k3-am62-lp4-50-800-800.dtsi | 2190 ++ arch/arm/dts/k3-am62-r5-lp-sk.dts| 82 ++ configs/am62x_lp_sk_a53_defconfig|3 + configs/am62x_lp_sk_r5_defconfig |2 + 6 files changed, 2315 insertions(+) --- base-commit: 714d31ca73fe1dd7a8217afc4a9f6a35ef7a9c01 change-id: 20240429-am62q-wip-f3453de038fb Best regards, -- Bryan Brattlof
Re: [PATCH 1/2] dm: core: add support for fallback drivers
On 10/04/2024 19:27, Heinrich Schuchardt wrote:
Am 10. April 2024 19:06:57 MESZ schrieb Caleb Connolly
:
Introduce support for a uclass to provide a fallback/stub driver which
can be used when no device is found for a given node. This might be
useful for handling non-essential clock controllers like the RPMh on
Qualcomm platforms, or during early bringup to get UART output before a
real clock driver has been created.
Signed-off-by: Caleb Connolly
---
drivers/core/Kconfig | 10 ++
drivers/core/uclass.c | 24 +++-
include/dm/uclass.h | 3 +++
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 1081d61fcf01..09075b9b7a15 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -466,5 +466,15 @@ config BOUNCE_BUFFER
A second possible use of bounce buffers is their ability to
provide aligned buffers for DMA operations.
+menuconfig FALLBACK_DRIVERS
Wouldn't it be preferable to mark individual drivers as fallback drivers in
their declaration?
This would allow alternative fallback drivers and would not require any
definitions at uclass level.
I don't see an obvious usecase for having multiple stub drivers for a
given uclass. Maybe as a result of that, I have no idea how we'd go
about choosing which stub to use if multiple were available.
I don't think it would be particularly hard to switch over if at some
point in the future we have such a need, but I don't see a benefit to
this added complexity now.
Just by building a fallback driver you would enable the fallback behavior for
its uclass.
I could drop the CONFIG_FALLBACK_DRIVERS option, it's just there to make
it possible to opt in/out of all stub drivers at once, but maybe this
isn't very useful.
Kind Regards,
Best regards
Heinrich
+ bool "Enable per-uclass fallback drivers"
+ depends on DM
+ help
+ If a driver requests a resource (like a clock) from a node which
+ isn't bound to a driver, the driver model will look for a fallback
+ driver to "stub" the resource. These stubs usually do nothing and
+ are therefore only suitable in instances where the resource is not
+ required.
+
endmenu
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index e46d5717aa62..91d3a48d77b8 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -378,8 +378,26 @@ int uclass_find_device_by_of_offset(enum uclass_id id, int
node,
return -ENODEV;
}
+static int uclass_bind_fallback(struct uclass *uc, ofnode node, struct udevice
**devp)
+{
+ struct driver *drv;
+
+ log(LOGC_DM, LOGL_ERR, " - binding fallback '%s' driver '%s'\n",
+ uc->uc_drv->name, uc->uc_drv->fallback_drv_name);
+
+ drv = lists_driver_lookup_name(uc->uc_drv->fallback_drv_name);
+ if (!drv) {
+ log(LOGC_DM, LOGL_DEBUG, " - Can't find stub driver '%s' for
uclass '%s'\n",
+ uc->uc_drv->fallback_drv_name, uc->uc_drv->name);
+ return -ENOENT;
+ }
+
+ return device_bind_with_driver_data(gd->dm_root, drv,
+ ofnode_get_name(node), 0, node, devp);
+}
+
int uclass_find_device_by_ofnode(enum uclass_id id, ofnode node,
struct udevice **devp)
{
struct uclass *uc;
@@ -401,9 +419,13 @@ int uclass_find_device_by_ofnode(enum uclass_id id, ofnode
node,
*devp = dev;
goto done;
}
}
- ret = -ENODEV;
+
+ if (CONFIG_IS_ENABLED(FALLBACK_DRIVERS) &&
uc->uc_drv->fallback_drv_name)
+ ret = uclass_bind_fallback(uc, node, devp);
+ else
+ ret = -ENODEV;
done:
log(LOGC_DM, LOGL_DEBUG, " - result for %s: %s (ret=%d)\n",
ofnode_get_name(node), *devp ? (*devp)->name : "(none)", ret);
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index 456eef7f2f31..b99e36485bc5 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -67,8 +67,10 @@ struct udevice;
* @child_pre_probe: Called before a child in this uclass is probed
* @child_post_probe: Called after a child in this uclass is probed
* @init: Called to set up the uclass
* @destroy: Called to destroy the uclass
+ * @stub_drv_name: Name of a stub driver to use for devices that are not
+ * supported by any other driver.
* @priv_auto: If non-zero this is the size of the private data
* to be allocated in the uclass's ->priv pointer. If zero, then the uclass
* driver is responsible for allocating any data required.
* @per_device_auto: Each device can hold private data owned
@@ -98,8 +100,9 @@ struct uclass_driver {
int (*child_pre_probe)(struct udevice *dev);
int (*child_post_probe)(struct udevice *dev);
int (*init)(struct uclass *class);
int (*destroy)(struct uclass *class);
+ const char *fal
Re: [PATCH] scripts: gen_compile_commands: fix invalid escape sequence warning
Hello,
thanks for this fix!
Em sex., 3 de mai. de 2024 às 15:20, Caleb Connolly <
caleb.conno...@linaro.org> escreveu:
> Since Python 3.12 unrecognised escape sequences trigger a SyntaxWarning.
> Convert the '\#' string to a raw string so the backslash is correctly
> used as a literal.
>
> Ported from Linux commit dae4a0171e25 ("gen_compile_commands: fix invalid
> escape sequence warning").
>
> This updates the script to be in-line with Linux 6.9-rc6.
>
> Signed-off-by: Caleb Connolly
> ---
> scripts/gen_compile_commands.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/gen_compile_commands.py
> b/scripts/gen_compile_commands.py
> index fec513e55474..e746a929 100755
> --- a/scripts/gen_compile_commands.py
> +++ b/scripts/gen_compile_commands.py
> @@ -171,9 +171,9 @@ def process_line(root_directory, command_prefix,
> file_path):
> # The .cmd files are intended to be included directly by Make, so they
> # escape the pound sign '#', either as '\#' or '$(pound)' (depending
> on the
> # kernel version). The compile_commands.json file is not interepreted
> # by Make, so this code replaces the escaped version with '#'.
> -prefix = command_prefix.replace('\#', '#').replace('$(pound)', '#')
> +prefix = command_prefix.replace(r'\#', '#').replace('$(pound)', '#')
>
> # Return the canonical path, eliminating any symbolic links
> encountered in the path.
> abs_path = os.path.realpath(os.path.join(root_directory, file_path))
> if not os.path.exists(abs_path):
> --
> 2.45.0
>
>
Reviewed-by: João Marcos Costa
--
Atenciosamente,
João Marcos Costa
Re: [PATCH 1/2] dm: core: add support for fallback drivers
Hi all,
Sorry for the slow follow-up.
On 11/04/2024 04:37, Sean Anderson wrote:
On 4/10/24 15:44, Tom Rini wrote:
On Wed, Apr 10, 2024 at 07:27:17PM +0200, Heinrich Schuchardt wrote:
Am 10. April 2024 19:06:57 MESZ schrieb Caleb Connolly
:
Introduce support for a uclass to provide a fallback/stub driver which
can be used when no device is found for a given node. This might be
useful for handling non-essential clock controllers like the RPMh on
Qualcomm platforms, or during early bringup to get UART output before a
real clock driver has been created.
Signed-off-by: Caleb Connolly
---
drivers/core/Kconfig | 10 ++
drivers/core/uclass.c | 24 +++-
include/dm/uclass.h | 3 +++
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 1081d61fcf01..09075b9b7a15 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -466,5 +466,15 @@ config BOUNCE_BUFFER
A second possible use of bounce buffers is their ability to
provide aligned buffers for DMA operations.
+menuconfig FALLBACK_DRIVERS
Wouldn't it be preferable to mark individual drivers as fallback
drivers in their declaration?
This would allow alternative fallback drivers and would not require
any definitions at uclass level.
Just by building a fallback driver you would enable the fallback
behavior for its uclass.
I think some of this is addressed in the cover letter. My concern /
questions come down to I think just a matter of naming. Both "fallback"
and "stub" are used at times. As a concept, we have some areas where we
need a no-op driver because whereas the DT describes a relationship in
the hardware, here in U-Boot we can just accept things as configured. To
me "fallback" implies more functionality of the driver when it's really
just a generic no-op driver to fill in the dependencies within the tree.
Can we rename things a bit along those lines?
Yes, will do. I originally used "stub" but then decided "fallback" was
better, but I think you're right that stub is the right way to go here.
As I agree that "fallback" implies some kind of real implementation.
I would rather just have a stub driver with compatibles for all clocks
we want
it to match. I think having a generic fallback driver could cause issues
in the
future if we need to switch over to using a real driver.
I don't think either approach is significantly better from a developer
perspective. With my patches if there a driver with a matching
compatible available then you will NEVER bind the stub, even if probe
fails on the real driver. With your proposal we'd have to remember to
remove the compatible from the stub driver or risk the race condition
when binding drivers.
There is another subtle but important difference if we were to use a
compatible list in the stub. It turns out that CONFIG_OF_LIVE affects
the bind behaviour - U-Boot won't try to bind the children of a node
with no driver when using the livetree. This is arguably more "correct",
as usually child devices depend on their parent, so we save some cycles
by not binding unsupported devices.
But, the RPM clock controller which I originally implemented this
feature for is such a case, this is the DT (simplified for brevity):
rpm: remoteproc {
compatible = "qcom,sm6115-rpm-proc", "qcom,rpm-proc";
glink-edge {
compatible = "qcom,glink-rpm";
rpm_requests: rpm-requests {
compatible = "qcom,rpm-sm6115";
rpmcc: clock-controller {
compatible = "qcom,rpmcc-sm6115", "qcom,rpmcc";
};
};
};
With livetree (which we use on qcom) we would need to stub not just the
rpmcc but also the rpm-requests, the glink bus, and the remoteproc (yeah
these platforms are a bit silly, I know XD).
However with the fallback solution as implemented in these patches, we
totally sidestep this issue by directly binding the node on-demand,
something we can only safely do for a stub driver as we don't need the
parent devices.
So I can either:
1) Make OF_LIVE behave like flattree and descend into all nodes (I don't
know if this would cause any issues, but I think the livetree behaviour
is more "correct" tbh).
2) Add stubs for all 3 of the parent nodes (and manually maintain a
table of compatibles for clock drivers we want to stub).
3) Stick with this approach of binding the stub as a last resort.
Obviously I've already put the time into 3, and that would still be my
preferred approach, but I'm open to other ideas.
--Sean
--
// Caleb (they/them)
Re: [PATCH] configs: am62x_evm_r5: Increase size of malloc_simple heap after relocation
Thanks Judith!
On April 29, 2024 thus sayeth Judith Mendez:
> On AM62x SK we can see a boot failure with signature "alloc space
> exhausted", so fix by increasing size of SPL_STACK_R_MALLOC_SIMPLE_LEN.
>
> Fixes: 128f81290b ("arm: dts: k3: binman: am625: add support for signing
> TIFSSTUB Images")
> Signed-off-by: Judith Mendez
> ---
> configs/am62x_evm_r5_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
This fixes the 62 for me
Reviewed-by: Bryan Brattlof
~Bryan
Re: [PATCH V2] board: rockchip: Add Indiedroid Nova
Hi Chris,
On 5/2/24 8:57 PM, Chris Morgan wrote:
From: Chris Morgan
The Indiedroid Nova is a Rockchip RK3588S based SBC from Indiedroid.
Specifications:
Rockchip RK3588S SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
4/8/16GB memory LPDDR4x
Mali G610MC4 GPU
Optional eMMC
2x USB 2.0, 2x USB 3.0, 1x USB 3.0 C port with DP Alt
1x MIPI-CSI Port (4-lane or 2x 2-lane)
1x MIPI-DSI 4-lane connector
1x Micro HDMI 2.1 output, 1x DP 1.4 output
Gigabit Ethernet
Realtek RTL8821CS WiFi
4 pin debug UART connector
40 pin GPIO header
Size: 85mm x 56mm (Raspberry Pi Form Factor)
Kernel commit:
3900160e164b ("arm64: dts: rockchip: Add Indiedroid Nova board")
Signed-off-by: Chris Morgan
---
Changes since V1:
- Refactored to use the upstream Linux device tree now that that is
an option.
Lucky you, I still have to wait for a bump of the upstream dts repo
"copy" to be able to use this for Tiger (will be in v6.9, so not too
long to wait for anymore :) ).
- Added board to doc/board/rockchip/rockchip.rst.
---
arch/arm/mach-rockchip/rk3588/Kconfig | 10
board/indiedroid/nova/Kconfig | 12 +
board/indiedroid/nova/MAINTAINERS | 6 +++
configs/nova-rk3588s_defconfig| 70 +++
doc/board/rockchip/rockchip.rst | 1 +
include/configs/nova-rk3588s.h| 15 ++
6 files changed, 114 insertions(+)
create mode 100644 board/indiedroid/nova/Kconfig
create mode 100644 board/indiedroid/nova/MAINTAINERS
create mode 100644 configs/nova-rk3588s_defconfig
create mode 100644 include/configs/nova-rk3588s.h
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig
b/arch/arm/mach-rockchip/rk3588/Kconfig
index 39049ab35a..820e979abb 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -78,6 +78,15 @@ config TARGET_NANOPCT6_RK3588
Power: 5.5*2.1mm DC Jack, 12VDC input
Dimensions: 110x80x1.6mm (without case) / 86x114.5x30mm (with case)
+config TARGET_NOVA_RK3588
+ bool "Indiedroid Nova RK3588"
+ select BOARD_LATE_INIT
+ help
+ Indiedroid Nova is a Rockchip RK3588s based SBC by Indiedroid.
+ It comes in configurations from 4GB of RAM to 16GB of RAM,
+ includes socket for eMMC storage, an SDMMC slot, and a 40-pin
+ GPIO header for expansion.
+
config TARGET_RK3588_NEU6
bool "Edgeble Neural Compute Module 6(Neu6) SoM"
select BOARD_LATE_INIT
@@ -223,6 +232,7 @@ config TEXT_BASE
source "board/edgeble/neural-compute-module-6/Kconfig"
source "board/friendlyelec/nanopc-t6-rk3588/Kconfig"
+source "board/indiedroid/nova/Kconfig"
source "board/pine64/quartzpro64-rk3588/Kconfig"
source "board/turing/turing-rk1-rk3588/Kconfig"
source "board/radxa/rock5a-rk3588s/Kconfig"
diff --git a/board/indiedroid/nova/Kconfig b/board/indiedroid/nova/Kconfig
new file mode 100644
index 00..271d15a0ed
--- /dev/null
+++ b/board/indiedroid/nova/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_NOVA_RK3588
+
+config SYS_BOARD
+ default "nova-rk3588s"
+
+config SYS_VENDOR
+ default "indiedroid"
+
+config SYS_CONFIG_NAME
+ default "nova-rk3588s"
+
+endif
diff --git a/board/indiedroid/nova/MAINTAINERS
b/board/indiedroid/nova/MAINTAINERS
new file mode 100644
index 00..9c56d01bf0
--- /dev/null
+++ b/board/indiedroid/nova/MAINTAINERS
@@ -0,0 +1,6 @@
+INDIEDROID-NOVA-RK3588
+M: Chris Morgan
+S: Maintained
+F: board/indiedroid/nova
+F: include/configs/nova-rk3588s.h
+F: configs/indiedroid-nova-rk3588_defconfig
Typo here, missing an s after rk3588 :)
Looking good to me otherwise.
Cheers,
Quentin
[PATCH] scripts: gen_compile_commands: fix invalid escape sequence warning
Since Python 3.12 unrecognised escape sequences trigger a SyntaxWarning.
Convert the '\#' string to a raw string so the backslash is correctly
used as a literal.
Ported from Linux commit dae4a0171e25 ("gen_compile_commands: fix invalid
escape sequence warning").
This updates the script to be in-line with Linux 6.9-rc6.
Signed-off-by: Caleb Connolly
---
scripts/gen_compile_commands.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/gen_compile_commands.py b/scripts/gen_compile_commands.py
index fec513e55474..e746a929 100755
--- a/scripts/gen_compile_commands.py
+++ b/scripts/gen_compile_commands.py
@@ -171,9 +171,9 @@ def process_line(root_directory, command_prefix, file_path):
# The .cmd files are intended to be included directly by Make, so they
# escape the pound sign '#', either as '\#' or '$(pound)' (depending on the
# kernel version). The compile_commands.json file is not interepreted
# by Make, so this code replaces the escaped version with '#'.
-prefix = command_prefix.replace('\#', '#').replace('$(pound)', '#')
+prefix = command_prefix.replace(r'\#', '#').replace('$(pound)', '#')
# Return the canonical path, eliminating any symbolic links encountered in
the path.
abs_path = os.path.realpath(os.path.join(root_directory, file_path))
if not os.path.exists(abs_path):
--
2.45.0
Re: [PATCH 1/2] arm: dts: add U-Boot dtbs for the am625-lp-sk
On May 3, 2024 thus sayeth Dhruva Gole:
> On Apr 30, 2024 at 14:57:45 -0500, Bryan Brattlof wrote:
> > From: Nitin Yadav
> >
> > Add the U-Boot device tree overrides for the am62x-lp-sk reference
> > board.
> >
> > Signed-off-by: Nitin Yadav
> > Signed-off-by: Bryan Brattlof
> > ---
> > arch/arm/dts/k3-am62-lp-sk-binman.dtsi | 21 +
> > arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi | 17 +
> > arch/arm/dts/k3-am62-lp4-50-800-800.dtsi | 2190
> > ++
> > arch/arm/dts/k3-am62-r5-lp-sk.dts| 82 ++
> > 4 files changed, 2310 insertions(+)
> >
> > diff --git a/arch/arm/dts/k3-am62-lp-sk-binman.dtsi
> > b/arch/arm/dts/k3-am62-lp-sk-binman.dtsi
> > new file mode 100644
> > index 0..de425a4b54f81
> > --- /dev/null
> > +++ b/arch/arm/dts/k3-am62-lp-sk-binman.dtsi
> > @@ -0,0 +1,21 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
>
> Can make this 2024, here and everywhere else.
>
> > + */
> > +
> > +#include "k3-binman.dtsi"
> > +#include "k3-am625-sk-binman.dtsi"
> > +
> > +#ifdef CONFIG_TARGET_AM625_A53_EVM
> > +
> > +#define SPL_AM62_LP_SK_DTB "spl/dts/ti/k3-am62-lp-sk.dtb"
> > +
> > +&spl_am625_sk_dtb {
> > + filename = SPL_AM62_LP_SK_DTB;
> > +};
> > +
> > +&spl_am625_sk_dtb_unsigned {
> > + filename = SPL_AM62_LP_SK_DTB;
> > +};
> > +
> > +#endif
> > diff --git a/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi
> > b/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi
> > new file mode 100644
> > index 0..08f572446657e
> > --- /dev/null
> > +++ b/arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi
> > @@ -0,0 +1,17 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * AM62x LP SK dts file for SPLs
> > + * Copyright (C) 2021-2023 Texas Instruments Incorporated -
> > https://www.ti.com/
>
> 2024 ^^
>
> [...]
>
> With that fixed,
> Reviewed-by: Dhruva Gole
>
Okay I'll get that fixed for v2
~Bryan
Re: [PATCH 63/81] soc: Remove and add needed includes
On May 1, 2024 thus sayeth Tom Rini: > Remove from this driver directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini > --- > Cc: Tom Rini > Cc: Simon Glass > Cc: Michal Simek > Cc: Nishanth Menon > Cc: Roger Quadros > Cc: Apurva Nandan > Cc: Hari Nagalla > Cc: Bryan Brattlof > --- > drivers/soc/soc-uclass.c| 1 - > drivers/soc/soc_sandbox.c | 1 - > drivers/soc/soc_ti_k3.c | 1 - > drivers/soc/soc_xilinx_versal.c | 1 - > drivers/soc/soc_xilinx_versal_net.c | 1 - > drivers/soc/soc_xilinx_zynqmp.c | 1 - > drivers/soc/ti/k3-navss-ringacc.c | 1 - > drivers/soc/ti/keystone_serdes.c| 1 - > drivers/soc/ti/pruss.c | 1 - > 9 files changed, 9 deletions(-) > ... > > diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c > index 3a4e58bba671..b585e47d46fe 100644 > --- a/drivers/soc/soc_ti_k3.c > +++ b/drivers/soc/soc_ti_k3.c > @@ -4,7 +4,6 @@ > * Dave Gerlach > */ > > -#include > #include > #include > Thanks Tom! Reviewed-by: Bryan Brattlof ~Bryan
Re: [PATCH] rockchip: Correct UUID for root partitions
Hi Chris,
On 4/26/24 5:33 PM, Chris Morgan wrote:
From: Chris Morgan
For root partitions, the UUID should still be random but the partition
type uuid should either be b921b045-1df0-41c3-af44-4c6f280d3fae for
aarch64 or 69dad710-2ce4-4e3c-b16c-21a1d49abed3 for aarch32. Correct
the attribute so it is the partition type that is hard coded and not
the partition unique identifier.
Note that in order for "type" to be used the config option
CONFIG_PARTITION_TYPE_GUID must be enabled. If this option is not
enabled then the type is ignored and instead the partition type
remains the generic ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 for a
Linux data partition.
Fixes: 42ec247e6988 ("rockchip: use UUID for root partitions")
Signed-off-by: Chris Morgan
---
include/configs/rockchip-common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/rockchip-common.h
b/include/configs/rockchip-common.h
index 9121bba373..f620579248 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -26,7 +26,7 @@
"name=loader2,start=8MB,size=4MB,uuid=${uuid_gpt_loader2};" \
"name=trust,size=4M,uuid=${uuid_gpt_atf};" \
"name=boot,size=112M,bootable,uuid=${uuid_gpt_boot};" \
- "name=rootfs,size=-,uuid="ROOT_UUID
+ "name=rootfs,size=-,uuid=${uuid_gpt_rootfs},type="ROOT_UUID
I would recommend to rename ROOT_UUID to ROOT_GUID also, since it's what
it is, c.f.
https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
BTW, it seems that type is optional, so maybe we could afford to just
remove the whole thing? I don't see anything else defining that type
parameter?
c.f. https://elixir.bootlin.com/u-boot/latest/source/cmd/gpt.c#L536
Also, this code is guarded by CONFIG_PARTITION_TYPE_GUID which seems to
only be enabled for RK3399 and no other SoC or Rockchip board... so not
sure it's *THAT* useful (or if it is, are we missing out on enabling on
other boards/SoCs).
Additionally, I cannot find anything setting uuid_gpt_rootfs environment
variable anywhere. I'm a bit lost to be honest. Are we maybe randomly
generating this uuid at runtime? (RANDOM_UUID is implied by CMD_GPT
after all so it isn't too much of a stretch).
Cheers,
Quentin
Re: [PATCH] configs: Make USB_GADGET_MANUFACTURER consistent over all PHYTEC boards
Hi Benjamin, On Fri, May 3, 2024 at 4:01 AM Benjamin Hahn wrote: > -CONFIG_USB_GADGET_MANUFACTURER="FSL" > +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" > CONFIG_USB_GADGET_VENDOR_NUM=0x0525 > CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 ... > -CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" > +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" > CONFIG_USB_GADGET_VENDOR_NUM=0x0451 > CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 What about making VENDOR_NUM/PRODUCT_NUM consistent as well?
Re: [PATCH 73/81] usb: Remove and add needed includes
Hi Tom,
On jeu., mai 02, 2024 at 08:51, Tom Rini wrote:
> On Thu, May 02, 2024 at 09:40:52AM +0200, Mattijs Korpershoek wrote:
>> Hi Tom,
>>
>> Thank you for the patch
>>
>> On mer., mai 01, 2024 at 19:31, Tom Rini wrote:
>>
>> > Remove from this driver directory and when needed
>> > add missing include files directly.
>> >
>> > Signed-off-by: Tom Rini
>>
>> [...]
>>
>> > diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
>> > index fedcf7869295..38c5928faed5 100644
>> > --- a/drivers/usb/host/xhci-rcar.c
>> > +++ b/drivers/usb/host/xhci-rcar.c
>> > @@ -5,7 +5,6 @@
>> > * Renesas RCar USB HOST xHCI Controller
>> > */
>> >
>> > -#include
>> > #include
>> > #include
>> > #include
>> > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>> > index 910c5f3352b8..1360a5940fa0 100644
>> > --- a/drivers/usb/host/xhci-ring.c
>> > +++ b/drivers/usb/host/xhci-ring.c
>> > @@ -13,7 +13,6 @@
>> > *Vikas Sajjan
>> > */
>> >
>> > -#include
>>
>> This generates the following build warning with
>> khadas-vim3_android_defconfig:
>>
>> drivers/usb/host/xhci-ring.c: In function 'xhci_wait_for_event':
>> drivers/usb/host/xhci-ring.c:464:28: warning: implicit declaration of
>> function 'get_timer'; did you mean 'get_mem'?
>> [-Wimplicit-function-declaration]
>> 464 | unsigned long ts = get_timer(0);
>> |^
>> |get_mem
>>
>> Adding: "#include " fixes the warning.
>>
>> With the above fix included:
>>
>> Reviewed-by: Mattijs Korpershoek
>
> Did you have the full series applied? I don't see the warning here (nor
> in CI) and I suspect that:
> https://patchwork.ozlabs.org/project/uboot/patch/20240502013138.2383421-9-tr...@konsulko.com/
> is what resolves this warning.
No, I did not apply the full series. I had some conflicts on both:
- master: ff0de1f0557e ("Merge patch series "Update PHYTEC SOM Detection"")
- next: bc39e0677816 ("Subtree merge tag 'v6.8-dts' of devicetree-rebasing repo
[1] into dts/upstream")
The above patch resolves the warning, indeed!
Thanks
>
> --
> Tom
Re: [PATCH 65/81] spi: Remove and add needed includes
On 5/2/24 03:31, Tom Rini wrote: Remove from this driver directory and when needed add missing include files directly. Signed-off-by: Tom Rini --- Cc: Jagan Teki Cc: Tom Rini Cc: Anand Gore Cc: William Zhang Cc: Kursad Oney Cc: Joel Peshkin Cc: Philippe Reynes Cc: Alex Nemirovsky Cc: Michal Simek Cc: Stefan Roese Cc: Neil Armstrong Cc: Gregory CLEMENT Cc: Lars Povlsen Cc: Horatiu Vultur Cc: Ryder Lee Cc: Weijie Gao Cc: Chunfeng Yun Cc: GSS_MTK_Uboot_upstream Cc: Nobuhiro Iwamatsu Cc: Marek Vasut Cc: Simon Glass Cc: Chin-Ting Kuo Cc: "Cédric Le Goater" Cc: Aspeed BMC SW team Cc: Ryan Chen Cc: Chia-Wei Wang Cc: Joel Stanley Cc: Robert Marko Cc: Luka Kovacic Cc: Luka Perkov Cc: Masahisa Kojima Cc: Patrick Delaunay Cc: Patrice Chotard Cc: Thierry Reding Cc: Svyatoslav Ryhel Cc: Kunihiko Hayashi Cc: Dai Okamura For spi-aspeed-smc.c, Reviewed-by: Cédric Le Goater Thanks, C.
[PATCH v4] test/py: net_boot: Add test cases for net boot
Add tests for booting image using tftpboot/pxe boot commands, tftpboot
boot case loads the FIT image into DDR and boots using bootm command
whereas pxe boot cases downloads the pxe configuration file from the
TFTP server and interprets it to boot the images mentioned in the pxe
configurations file.
This test relies on boardenv_* containing configuration values including
the parameter 'pattern'. tftpboot/pxe boot cases boots the Linux till the
boot log pattern value is matched. For example, if the parameter
'pattern' is defined as 'login:', it will boot till login prompt.
Signed-off-by: Love Kumar
---
Changes in v2:
- Expand commit message
Changes in v3:
- Add the config option to skip the test
- Remove imi command to check FIT image config
- Configure static networking only if DHCP fails
Changes in v4:
- Use configured timeout for tftpboot
---
test/py/tests/test_net_boot.py | 394 +
1 file changed, 394 insertions(+)
create mode 100644 test/py/tests/test_net_boot.py
diff --git a/test/py/tests/test_net_boot.py b/test/py/tests/test_net_boot.py
new file mode 100644
index ..fb0fb7e80414
--- /dev/null
+++ b/test/py/tests/test_net_boot.py
@@ -0,0 +1,394 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+import pytest
+import u_boot_utils
+import test_net
+
+"""
+Note: This test relies on boardenv_* containing configuration values to define
+which the network environment available for testing. Without this, this test
+will be automatically skipped.
+
+For example:
+
+# Details regarding a boot image file that may be read from a TFTP server. This
+# variable may be omitted or set to None if TFTP boot testing is not possible
+# or desired.
+env__net_tftp_bootable_file = {
+'fn': 'image.ub',
+'addr': 0x1000,
+'size': 5058624,
+'crc32': 'c2244b26',
+'pattern': 'Linux',
+'config': 'config@2',
+'timeout': 5,
+}
+
+# False or omitted if a TFTP boot test should be tested.
+# If TFTP boot testing is not possible or desired, set this variable to True.
+# For example: If FIT image is not proper to boot
+env__tftp_boot_test_skip = False
+
+# Here is the example of FIT image configurations:
+configurations {
+default = "config@1";
+config@1 {
+description = "Boot Linux kernel with config@1";
+kernel = "kernel@0";
+fdt = "fdt@0";
+ramdisk = "ramdisk@0";
+hash@1 {
+algo = "sha1";
+};
+};
+config@2 {
+description = "Boot Linux kernel with config@2";
+kernel = "kernel@1";
+fdt = "fdt@1";
+ramdisk = "ramdisk@1";
+hash@1 {
+algo = "sha1";
+};
+};
+};
+
+# Details regarding a file that may be read from a TFTP server. This variable
+# may be omitted or set to None if PXE testing is not possible or desired.
+env__net_pxe_bootable_file = {
+'fn': 'default',
+'addr': 0x1000,
+'size': 74,
+'timeout': 5,
+'pattern': 'Linux',
+'valid_label': '1',
+'invalid_label': '2',
+'exp_str_invalid': 'Skipping install for failure retrieving',
+'local_label': '3',
+'exp_str_local': 'missing environment variable: localcmd',
+'empty_label': '4',
+'exp_str_empty': 'No kernel given, skipping boot',
+}
+
+# False or omitted if a PXE boot test should be tested.
+# If PXE boot testing is not possible or desired, set this variable to True.
+# For example: If pxe configuration file is not proper to boot
+env__pxe_boot_test_skip = False
+
+# Here is the example of pxe configuration file ordered based on the execution
+# flow:
+1) /tftpboot/pxelinux.cfg/default-arm-zynqmp
+
+menu include pxelinux.cfg/default-arm
+timeout 50
+
+default Linux
+
+2) /tftpboot/pxelinux.cfg/default-arm
+
+menu title Linux boot selections
+menu include pxelinux.cfg/default
+
+label install
+menu label Invalid boot
+kernel kernels/install.bin
+append console=ttyAMA0,38400 debug earlyprintk
+initrd initrds/uzInitrdDebInstall
+
+label local
+menu label Local boot
+append root=/dev/sdb1
+localboot 1
+
+label boot
+menu label Empty boot
+
+3) /tftpboot/pxelinux.cfg/default
+
+label Linux
+menu label Boot kernel
+kernel Image
+fdt system.dtb
+initrd rootfs.cpio.gz.u-boot
+"""
+
+def setup_tftpboot_boot(u_boot_console):
+f = u_boot_console.config.env.get('env__net_tftp_bootable_file', None)
+if not f:
+pytest.skip('No TFTP bootable file to read')
+
+test_net.test_net_dhcp(u_boot_console)
+if not test_net.net_set_up:
+test_net.test_net_setup_static(u_boot_console)
+
+addr = f.get('addr', None)
+if not addr:
+addr = u_boot_utils.find_ram_base(u_boot_console)
+
+fn = f['fn']
+timeout = f.get('timeout', 5)
+
+with u_boot_console.temporary_timeout(timeout):
+output = u_boot_c
[PATCH v2 3/4] doc: Milk-V Mars CM and Milk-V Mars CM Lite
Provide a man-page describing the usage of U-Boot on the Milk-V Mars CM and Milk-V Mars CM Lite boards. Signed-off-by: Heinrich Schuchardt --- v2: refer to tio as tool for booting via UART describe how to update serial number description updates as suggested by E. Shattow --- doc/board/starfive/index.rst | 1 + doc/board/starfive/milk-v_mars_cm.rst | 183 ++ 2 files changed, 184 insertions(+) create mode 100644 doc/board/starfive/milk-v_mars_cm.rst diff --git a/doc/board/starfive/index.rst b/doc/board/starfive/index.rst index 2762bf74c11..afa85ad2540 100644 --- a/doc/board/starfive/index.rst +++ b/doc/board/starfive/index.rst @@ -7,4 +7,5 @@ StarFive :maxdepth: 1 milk-v_mars.rst + milk-v_mars_cm.rst visionfive2 diff --git a/doc/board/starfive/milk-v_mars_cm.rst b/doc/board/starfive/milk-v_mars_cm.rst new file mode 100644 index 000..d2be064d94c --- /dev/null +++ b/doc/board/starfive/milk-v_mars_cm.rst @@ -0,0 +1,183 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Milk-V Mars CM +== + +U-Boot for the Milk-V Mars CM uses the same U-Boot binaries as the VisionFive 2 +board. In U-Boot SPL the actual board is detected and the device-tree patched +accordingly. + +The Milk-V Mars CM Lite comes without eMMC and needs a different pin muxing +than the Milk-V Mars CM. The availability and size of the eMMC shows up in the +serial number displayed by the *mac* command, e.g. +MARC-V10-2340-D002E016-0304. The number after the E is the MMC size. U-Boot +takes a value of E000 as an indicator for the Lite version. Unfortunately the +vendor has not set this value correctly on some Lite boards. + +Please, use CONFIG_STARFIVE_NO_EMMC=y if EEPROM data indicates eMMC is present +on the Milk-V Mars CM Lite. Otherwise you will not be able to read from the +SD-card. + +The serial number can be corrected using the *mac* command: + +.. code-block:: + +mac read_eeprom +mac product_id MARC-V10-2340-D002E000-0304 +mac write_eeprom + +By default the EEPROM is write protected. The write protection may be overcome +by connecting the "GND" and "EN" test pads on top of the module. + +Building + + +1. Add the RISC-V toolchain to your PATH. +2. Setup ARCH & cross compilation environment variable: + +.. code-block:: none + + export CROSS_COMPILE= + +The M-mode software OpenSBI provides the supervisor binary interface (SBI) and +is responsible for the switch to S-Mode. It is a prerequisite to build U-Boot. +Support for the JH7110 was introduced in OpenSBI 1.2. It is recommended to use +a current release. + +.. code-block:: console + + git clone https://github.com/riscv/opensbi.git + cd opensbi + make PLATFORM=generic FW_TEXT_START=0x4000 + +(*FW_TEXT_START* is not needed anymore after OpenSBI patch d4d2582eef7a +"firmware: remove FW_TEXT_START" which should appear in OpenSBI 1.5.) + +Now build the U-Boot SPL and U-Boot proper. + +.. code-block:: console + + cd + make starfive_visionfive2_defconfig + make OPENSBI=$(opensbi_dir)/build/platform/generic/firmware/fw_dynamic.bin + +This will generate the U-Boot SPL image (spl/u-boot-spl.bin.normal.out) as well +as the FIT image (u-boot.itb) with OpenSBI and U-Boot. + +Device-tree selection +~ + +Depending on the board version U-Boot sets variable $fdtfile to either +starfive/jh7110-milkv-mars-cm-emmc.dtb (for the generic version or +starfive/jh7110-milkv-mars-cm-sdcard.dtb (for the Lite version). + +To overrule this selection the variable can be set manually and saved in the +environment + +:: + +setenv fdtfile my_device-tree.dtb +env save + +or the configuration variable CONFIG_DEFAULT_FDT_FILE can be used to set to +provide a default value. + +Boot source selection +~ + +The low speed connector nRPIBOOT line is used to switch the boot source. + +* If nRPIBOOT is connected to ground, the board boots from UART. +* If nRPIBOOT is not connected, the board boots from SPI flash. + +Compute module boards typically have a switch or jumper for this line. + +Flashing a new U-Boot version +~ + +U-Boot SPL is provided as file spl/u-boot-spl.bin.normal.out. Main U-Boot is +in file u-boot.itb. + +Assuming your new U-Boot version is on partition 1 of an SD-card you could +install it to the SPI flash with: + +:: + +sf probe +load mmc 0:1 $kernel_addr_r u-boot-spl.bin.normal.out +sf update $kernel_addr_r 0 $filesize +load mmc 0:1 $kernel_addr_r u-boot.itb +sf update $kernel_addr_r 0x10 $filesize + +For loading the files from a TFTP server refer to the dhcp and tftpboot +commands. + +After updating U-Boot you may want to reboot and reset the environment to the +default. + +:: + +env default -f -a +env save + +Booting from UART +~ + +For booting via UART U-Boot must be built with CONFIG_SPL_YMODEM_SUPPORT=y. + +With nRPIBOOT connec
[PATCH v2 4/4] configs: visionfive2: enable SPL_YMODEM_SUPPORT
We can use U-Boot for recovering JH7110 based boards via UART if CONFIG_SPL_YMODEM_SUPPORT=y. * Send u-boot-spl.normal.out via XMODEM. * Send u-boot.itb via YMODEM. Signed-off-by: Heinrich Schuchardt --- v2: no change --- configs/starfive_visionfive2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/starfive_visionfive2_defconfig b/configs/starfive_visionfive2_defconfig index 3bbd1dbd67c..174ac24dc74 100644 --- a/configs/starfive_visionfive2_defconfig +++ b/configs/starfive_visionfive2_defconfig @@ -62,6 +62,7 @@ CONFIG_SPL_I2C=y CONFIG_SPL_DM_SPI_FLASH=y CONFIG_SPL_DM_RESET=y CONFIG_SPL_SPI_LOAD=y +CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_SYS_PROMPT="StarFive # " CONFIG_CMD_EEPROM=y CONFIG_SYS_EEPROM_SIZE=512 -- 2.43.0
[PATCH v2 1/4] board: starfive: function to read eMMC size
The EEPROM provides information about the size of the eMMC.
Provide a new function get_mmc_size_from_eeprom() to read it.
Signed-off-by: Heinrich Schuchardt
---
v2:
fix typos in get_mmc_size_from_eeprom() description
---
arch/riscv/include/asm/arch-jh7110/eeprom.h| 7 +++
board/starfive/visionfive2/Kconfig | 9 +
.../visionfive2/visionfive2-i2c-eeprom.c | 18 ++
3 files changed, 34 insertions(+)
diff --git a/arch/riscv/include/asm/arch-jh7110/eeprom.h
b/arch/riscv/include/asm/arch-jh7110/eeprom.h
index 62d184aeb57..45ad2a5f7bc 100644
--- a/arch/riscv/include/asm/arch-jh7110/eeprom.h
+++ b/arch/riscv/include/asm/arch-jh7110/eeprom.h
@@ -12,6 +12,13 @@
u8 get_pcb_revision_from_eeprom(void);
u32 get_ddr_size_from_eeprom(void);
+/**
+ * get_mmc_size_from_eeprom() - read eMMC size from EEPROM
+ *
+ * @return: size in GiB or 0 on error.
+ */
+u32 get_mmc_size_from_eeprom(void);
+
/**
* get_product_id_from_eeprom - get product ID string
*
diff --git a/board/starfive/visionfive2/Kconfig
b/board/starfive/visionfive2/Kconfig
index 2186a939646..d7e8a7a7d78 100644
--- a/board/starfive/visionfive2/Kconfig
+++ b/board/starfive/visionfive2/Kconfig
@@ -50,4 +50,13 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply PHY_LIB
imply PHY_MSCC
+config STARFIVE_NO_EMMC
+ bool "Report eMMC size as zero"
+ help
+ The serial number string in the EEPROM is meant to report the
+ size of onboard eMMC. Unfortunately some Milk-V Mars CM Lite
+ modules without eMMC show a non-zero size here.
+
+ Set to 'Y' if you have a Mars CM Lite module.
+
endif
diff --git a/board/starfive/visionfive2/visionfive2-i2c-eeprom.c
b/board/starfive/visionfive2/visionfive2-i2c-eeprom.c
index 5095a0e9fdb..9648a270494 100644
--- a/board/starfive/visionfive2/visionfive2-i2c-eeprom.c
+++ b/board/starfive/visionfive2/visionfive2-i2c-eeprom.c
@@ -548,6 +548,24 @@ u32 get_ddr_size_from_eeprom(void)
return hextoul(&pbuf.eeprom.atom1.data.pstr[14], NULL);
}
+u32 get_mmc_size_from_eeprom(void)
+{
+ u32 size;
+
+ if (IS_ENABLED(CONFIG_STARFIVE_NO_EMMC))
+ return 0;
+
+ if (read_eeprom())
+ return 0;
+
+ size = dectoul(&pbuf.eeprom.atom1.data.pstr[19], NULL);
+
+ if (pbuf.eeprom.atom1.data.pstr[21] == 'T')
+ size <<= 10;
+
+ return size;
+}
+
U_BOOT_LONGHELP(mac,
"\n"
"- display EEPROM content\n"
--
2.43.0
[PATCH v2 2/4] board: add support for Milk-V Mars CM
We already support the VisionFive 2 and the Milk-V Mars board by
patching the VisionFive 2 device tree. With this patch the same
is done for the Milk-V Mars CM.
Signed-off-by: Heinrich Schuchardt
---
v2:
rename spl_fdt_fixup_marc() to spl_fdt_fixup_mars_cm()
rename device-trees for Mars CM and Mars CM Lite
change model and compatible properties
---
board/starfive/visionfive2/spl.c | 28 ++-
.../visionfive2/starfive_visionfive2.c| 11 +++-
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c
index ca61b5be227..b555189556a 100644
--- a/board/starfive/visionfive2/spl.c
+++ b/board/starfive/visionfive2/spl.c
@@ -129,6 +129,30 @@ void spl_fdt_fixup_mars(void *fdt)
}
}
+void spl_fdt_fixup_mars_cm(void *fdt)
+{
+ const char *compat;
+ const char *model;
+
+ spl_fdt_fixup_mars(fdt);
+
+ if (!get_mmc_size_from_eeprom()) {
+ int offset;
+
+ model = "Milk-V Mars CM Lite";
+ compat = "milkv,mars-cm-lite\0starfive,jh7110";
+
+ offset = fdt_path_offset(fdt,
"/soc/pinctrl/mmc0-pins/mmc0-pins-rest");
+ /* GPIOMUX(22, GPOUT_SYS_SDIO0_RST, GPOEN_ENABLE, GPI_NONE) */
+ fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016);
+ } else {
+ model = "Milk-V Mars CM";
+ compat = "milkv,mars-cm\0starfive,jh7110";
+ }
+ fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat,
sizeof(compat));
+ fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", model);
+}
+
void spl_fdt_fixup_version_a(void *fdt)
{
static const char compat[] =
"starfive,visionfive-2-v1.2a\0starfive,jh7110";
@@ -236,7 +260,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
pr_err("Can't read EEPROM\n");
return;
}
- if (!strncmp(product_id, "MARS", 4)) {
+ if (!strncmp(product_id, "MARC", 4)) {
+ spl_fdt_fixup_mars_cm(spl_image->fdt_addr);
+ } else if (!strncmp(product_id, "MARS", 4)) {
spl_fdt_fixup_mars(spl_image->fdt_addr);
} else if (!strncmp(product_id, "VF7110", 6)) {
version = get_pcb_revision_from_eeprom();
diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
b/board/starfive/visionfive2/starfive_visionfive2.c
index a86bca533b2..6be53489626 100644
--- a/board/starfive/visionfive2/starfive_visionfive2.c
+++ b/board/starfive/visionfive2/starfive_visionfive2.c
@@ -19,6 +19,10 @@ DECLARE_GLOBAL_DATA_PTR;
#define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000
#define FDTFILE_MILK_V_MARS \
"starfive/jh7110-milkv-mars.dtb"
+#define FDTFILE_MILK_V_MARS_CM \
+ "starfive/jh7110-milkv-mars-cm.dtb"
+#define FDTFILE_MILK_V_MARS_CM_LITE \
+ "starfive/jh7110-milkv-mars-cm-lite.dtb"
#define FDTFILE_VISIONFIVE2_1_2A \
"starfive/jh7110-starfive-visionfive-2-v1.2a.dtb"
#define FDTFILE_VISIONFIVE2_1_3B \
@@ -61,7 +65,12 @@ static void set_fdtfile(void)
log_err("Can't read EEPROM\n");
return;
}
- if (!strncmp(product_id, "MARS", 4)) {
+ if (!strncmp(product_id, "MARC", 4)) {
+ if (get_mmc_size_from_eeprom())
+ fdtfile = FDTFILE_MILK_V_MARS_CM;
+ else
+ fdtfile = FDTFILE_MILK_V_MARS_CM_LITE;
+ } else if (!strncmp(product_id, "MARS", 4)) {
fdtfile = FDTFILE_MILK_V_MARS;
} else if (!strncmp(product_id, "VF7110", 6)) {
version = get_pcb_revision_from_eeprom();
--
2.43.0
[PATCH v2 0/4] board: starfive: add Milk-V Mars CM support
With this series the Milk-V Mars CM board can be booted. NVMe, SD-card, Ethernet, UART are working but not USB. The first series Milk-V Mars CM Lite board (the version without eMMC) uses incorrect series numbers indicating eMMC presence. For these CONFIG_STARFIVE_NO_EMMC=y must be set to indicate that eMMC is not present. Thanks to E. Shattow for all the helpful discussions. He figured out what needed to be patched in the device-tree. v2: fix typos in get_mmc_size_from_eeprom() description rename spl_fdt_fixup_marc() to spl_fdt_fixup_mars_cm() rename device-trees for Mars CM and Mars CM Lite change model and compatible properties refer to tio as tool for booting via UART describe how to update serial number Heinrich Schuchardt (4): board: starfive: function to read eMMC size board: add support for Milk-V Mars CM doc: Milk-V Mars CM and Milk-V Mars CM Lite configs: visionfive2: enable SPL_YMODEM_SUPPORT arch/riscv/include/asm/arch-jh7110/eeprom.h | 7 + board/starfive/visionfive2/Kconfig| 9 + board/starfive/visionfive2/spl.c | 28 ++- .../visionfive2/starfive_visionfive2.c| 11 +- .../visionfive2/visionfive2-i2c-eeprom.c | 18 ++ configs/starfive_visionfive2_defconfig| 1 + doc/board/starfive/index.rst | 1 + doc/board/starfive/milk-v_mars_cm.rst | 183 ++ 8 files changed, 256 insertions(+), 2 deletions(-) create mode 100644 doc/board/starfive/milk-v_mars_cm.rst -- 2.43.0
[PATCH 5/5] net: dwc_eth_qos: Add glue driver for Intel MAC
Add dwc_eth_qos glue driver for the Intel Elkhart-Lake SOC.
Signed-off-by: Philip Oberfichtner
---
drivers/net/Kconfig | 7 +
drivers/net/Makefile| 1 +
drivers/net/dwc_eth_qos.h | 1 +
drivers/net/dwc_eth_qos_intel.c | 446
drivers/net/dwc_eth_qos_intel.h | 58 +
include/pci_ids.h | 9 +
6 files changed, 522 insertions(+)
create mode 100644 drivers/net/dwc_eth_qos_intel.c
create mode 100644 drivers/net/dwc_eth_qos_intel.h
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b2d7b49976..b23fe55792 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -225,6 +225,13 @@ config DWC_ETH_QOS_IMX
The Synopsys Designware Ethernet QOS IP block with the specific
configuration used in IMX soc.
+config DWC_ETH_QOS_INTEL
+ bool "Synopsys DWC Ethernet QOS device support for Intel"
+ depends on DWC_ETH_QOS
+ help
+ The Synopsys Designware Ethernet QOS IP block with the specific
+ configuration used in the Intel Elkhart-Lake soc.
+
config DWC_ETH_QOS_ROCKCHIP
bool "Synopsys DWC Ethernet QOS device support for Rockchip SoCs"
depends on DWC_ETH_QOS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index dc3404519d..bd62c65dd5 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_DRIVER_DM9000) += dm9000x.o
obj-$(CONFIG_DSA_SANDBOX) += dsa_sandbox.o
obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
obj-$(CONFIG_DWC_ETH_QOS_IMX) += dwc_eth_qos_imx.o
+obj-$(CONFIG_DWC_ETH_QOS_INTEL) += dwc_eth_qos_intel.o
obj-$(CONFIG_DWC_ETH_QOS_ROCKCHIP) += dwc_eth_qos_rockchip.o
obj-$(CONFIG_DWC_ETH_QOS_QCOM) += dwc_eth_qos_qcom.o
obj-$(CONFIG_DWC_ETH_QOS_STARFIVE) += dwc_eth_qos_starfive.o
diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h
index 7984582c49..f8ce7a41a2 100644
--- a/drivers/net/dwc_eth_qos.h
+++ b/drivers/net/dwc_eth_qos.h
@@ -295,6 +295,7 @@ void *eqos_get_driver_data(struct udevice *dev);
fdt_addr_t eqos_get_base_addr_dt(struct udevice *dev);
extern struct eqos_config eqos_imx_config;
+extern struct eqos_config eqos_intel_config;
extern struct eqos_config eqos_rockchip_config;
extern struct eqos_config eqos_qcom_config;
extern struct eqos_config eqos_stm32mp13_config;
diff --git a/drivers/net/dwc_eth_qos_intel.c b/drivers/net/dwc_eth_qos_intel.c
new file mode 100644
index 00..39952ef52a
--- /dev/null
+++ b/drivers/net/dwc_eth_qos_intel.c
@@ -0,0 +1,446 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 DENX Software Engineering GmbH
+ * Philip Oberfichtner
+ *
+ * Based on linux v6.1.38, especially drivers/net/ethernet/stmicro/stmmac
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dwc_eth_qos.h"
+#include "dwc_eth_qos_intel.h"
+
+static struct pci_device_id intel_pci_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EHL_RGMII1G) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EHL_SGMII1) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EHL_SGMII2G5) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EHL_PSE0_RGMII1G)
},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EHL_PSE0_SGMII1G)
},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_EHL_PSE0_SGMII2G5) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EHL_PSE1_RGMII1G)
},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EHL_PSE1_SGMII1G)
},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_EHL_PSE1_SGMII2G5) },
+ {}
+};
+
+static int __pci_config(struct udevice *dev)
+{
+ u32 val;
+
+ /* Try to enable I/O accesses and bus-mastering */
+ dm_pci_read_config32(dev, PCI_COMMAND, &val);
+ val |= PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
+ dm_pci_write_config32(dev, PCI_COMMAND, val);
+
+ /* Make sure it worked */
+ dm_pci_read_config32(dev, PCI_COMMAND, &val);
+ if (!(val & PCI_COMMAND_MEMORY)) {
+ pr_err("%s: Can't enable I/O memory\n", __func__);
+ return -ENOSPC;
+ }
+ if (!(val & PCI_COMMAND_MASTER)) {
+ pr_err("%s: Can't enable bus-mastering\n", __func__);
+ return -EPERM;
+ }
+
+ return 0;
+}
+
+static void __limit_fifo_size(struct udevice *dev)
+{
+ /*
+* As described in Intel Erratum EHL22, Document Number: 636674-2.1,
+* the PSE GbE Controllers advertise a wrong RX and TX fifo size.
+* Software should limit this value to 64KB.
+*/
+ struct eqos_priv *eqos = dev_get_priv(dev);
+
+ eqos->tx_fifo_sz = 0x8000;
+ eqos->rx_fifo_sz = 0x8000;
+}
+
+static int __serdes_status_poll(struct udevice *dev,
+ unsigned char phyaddr, unsigned char phyreg,
+ unsigned short mask, unsigned sho
[PATCH 4/5] net: dwc_eth_qos: Implement bind() for PCI devices
PCI devices do not necessarily use a device tree. Implement a bind()
function to assign unique device names in that case.
Signed-off-by: Philip Oberfichtner
---
drivers/net/dwc_eth_qos.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 36412d1c83..fdd64f074a 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1376,6 +1376,21 @@ static int eqos_remove_resources_tegra186(struct udevice
*dev)
return 0;
}
+static int eqos_bind(struct udevice *dev)
+{
+ static int dev_num;
+ const size_t name_sz = 16;
+ char name[name_sz];
+
+ /* Device name defaults to DT node name. */
+ if (ofnode_valid(dev_ofnode(dev)))
+ return 0;
+
+ /* Assign unique names in case there is no DT node. */
+ snprintf(name, name_sz, "eth_eqos#%d", dev_num++);
+ return device_set_name(dev, name);
+}
+
/*
* Get driver data based on the device tree. Boards not using a device tree can
* overwrite this function.
@@ -1597,6 +1612,7 @@ U_BOOT_DRIVER(eth_eqos) = {
.name = "eth_eqos",
.id = UCLASS_ETH,
.of_match = of_match_ptr(eqos_ids),
+ .bind = eqos_bind,
.probe = eqos_probe,
.remove = eqos_remove,
.ops = &eqos_ops,
--
2.39.2
[PATCH 3/5] net: dwc_eth_qos: Adapt probe() for PCI devices
PCI devices do not necessarily use a device tree. In that case, the
driver currently fails to find eqos->config and eqos->regs.
This commit factors out the respective functionality. Device tree usage
remains default, but board specific implementations will be possible as
well.
Signed-off-by: Philip Oberfichtner
---
drivers/net/dwc_eth_qos.c | 28 +---
drivers/net/dwc_eth_qos.h | 3 +++
drivers/net/dwc_eth_qos_imx.c | 1 +
drivers/net/dwc_eth_qos_qcom.c | 1 +
drivers/net/dwc_eth_qos_rockchip.c | 1 +
drivers/net/dwc_eth_qos_starfive.c | 1 +
drivers/net/dwc_eth_qos_stm32.c| 1 +
7 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 4dd532b671..36412d1c83 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1376,6 +1376,21 @@ static int eqos_remove_resources_tegra186(struct udevice
*dev)
return 0;
}
+/*
+ * Get driver data based on the device tree. Boards not using a device tree can
+ * overwrite this function.
+ */
+__weak void *eqos_get_driver_data(struct udevice *dev)
+{
+ return (void *)dev_get_driver_data(dev);
+}
+
+/* Function to get base address, useable for all boards having a device tree.
*/
+fdt_addr_t eqos_get_base_addr_dt(struct udevice *dev)
+{
+ return dev_read_addr(dev);
+}
+
static int eqos_probe(struct udevice *dev)
{
struct eqos_priv *eqos = dev_get_priv(dev);
@@ -1384,13 +1399,19 @@ static int eqos_probe(struct udevice *dev)
debug("%s(dev=%p):\n", __func__, dev);
eqos->dev = dev;
- eqos->config = (void *)dev_get_driver_data(dev);
- eqos->regs = dev_read_addr(dev);
+ eqos->config = eqos_get_driver_data(dev);
+ if (!eqos->config) {
+ pr_err("Failed to get driver data.\n");
+ return -ENODEV;
+ }
+
+ eqos->regs = eqos->config->ops->eqos_get_base_addr(dev);
if (eqos->regs == FDT_ADDR_T_NONE) {
- pr_err("dev_read_addr() failed\n");
+ pr_err("Failed to get device address.\n");
return -ENODEV;
}
+
eqos->mac_regs = (void *)(eqos->regs + EQOS_MAC_REGS_BASE);
eqos->mtl_regs = (void *)(eqos->regs + EQOS_MTL_REGS_BASE);
eqos->dma_regs = (void *)(eqos->regs + EQOS_DMA_REGS_BASE);
@@ -1497,6 +1518,7 @@ static struct eqos_ops eqos_tegra186_ops = {
.eqos_flush_buffer = eqos_flush_buffer_tegra186,
.eqos_probe_resources = eqos_probe_resources_tegra186,
.eqos_remove_resources = eqos_remove_resources_tegra186,
+ .eqos_get_base_addr = eqos_get_base_addr_dt,
.eqos_stop_resets = eqos_stop_resets_tegra186,
.eqos_start_resets = eqos_start_resets_tegra186,
.eqos_stop_clks = eqos_stop_clks_tegra186,
diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h
index c6e1f76caf..7984582c49 100644
--- a/drivers/net/dwc_eth_qos.h
+++ b/drivers/net/dwc_eth_qos.h
@@ -239,6 +239,7 @@ struct eqos_ops {
void (*eqos_flush_buffer)(void *buf, size_t size);
int (*eqos_probe_resources)(struct udevice *dev);
int (*eqos_remove_resources)(struct udevice *dev);
+ fdt_addr_t (*eqos_get_base_addr)(struct udevice *dev);
int (*eqos_stop_resets)(struct udevice *dev);
int (*eqos_start_resets)(struct udevice *dev);
int (*eqos_stop_clks)(struct udevice *dev);
@@ -290,6 +291,8 @@ void eqos_flush_desc_generic(void *desc);
void eqos_inval_buffer_generic(void *buf, size_t size);
void eqos_flush_buffer_generic(void *buf, size_t size);
int eqos_null_ops(struct udevice *dev);
+void *eqos_get_driver_data(struct udevice *dev);
+fdt_addr_t eqos_get_base_addr_dt(struct udevice *dev);
extern struct eqos_config eqos_imx_config;
extern struct eqos_config eqos_rockchip_config;
diff --git a/drivers/net/dwc_eth_qos_imx.c b/drivers/net/dwc_eth_qos_imx.c
index 9c4e390441..21dbf45a22 100644
--- a/drivers/net/dwc_eth_qos_imx.c
+++ b/drivers/net/dwc_eth_qos_imx.c
@@ -218,6 +218,7 @@ static struct eqos_ops eqos_imx_ops = {
.eqos_flush_buffer = eqos_flush_buffer_generic,
.eqos_probe_resources = eqos_probe_resources_imx,
.eqos_remove_resources = eqos_remove_resources_imx,
+ .eqos_get_base_addr = eqos_get_base_addr_dt,
.eqos_stop_resets = eqos_null_ops,
.eqos_start_resets = eqos_null_ops,
.eqos_stop_clks = eqos_stop_clks_imx,
diff --git a/drivers/net/dwc_eth_qos_qcom.c b/drivers/net/dwc_eth_qos_qcom.c
index 8178138fc6..78213e5ca0 100644
--- a/drivers/net/dwc_eth_qos_qcom.c
+++ b/drivers/net/dwc_eth_qos_qcom.c
@@ -589,6 +589,7 @@ static struct eqos_ops eqos_qcom_ops = {
.eqos_flush_buffer = eqos_flush_buffer_generic,
.eqos_probe_resources = eqos_probe_resources_qcom,
.eqos_remove_resources = eqos_remove_resources_qcom,
+ .eqos_get_base_addr = eqos_get_base_addr_dt,
.eqos_stop_resets = eqos_null_ops,
[PATCH 2/5] net: dwc_eth_qos: Fix header to be self-contained
Before this commit, usage of this header relied on a specific include order. Fix it by including all dependencies. Signed-off-by: Philip Oberfichtner --- drivers/net/dwc_eth_qos.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h index d6ed3830be..c6e1f76caf 100644 --- a/drivers/net/dwc_eth_qos.h +++ b/drivers/net/dwc_eth_qos.h @@ -3,8 +3,11 @@ * Copyright 2022 NXP */ -#include +#include +#include #include +#include +#include /* Core registers */ -- 2.39.2
[PATCH 1/5] x86: provide mb() macro
Implement memory barrier using mfence. Linux does it equivalently [1].
"The MFENCE instruction establishes a memory fence for both loads and
stores" [2].
[1] linux/arch/x86/include/asm/barrier.h
[2] Intel® 64 and IA-32 Architectures Software Developer’s Manual
Signed-off-by: Philip Oberfichtner
---
arch/x86/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 5efb2e1b21..936ad6f588 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -244,6 +244,7 @@ static inline void sync(void)
* have some advantages to use them instead of the simple one here.
*/
#define dmb() __asm__ __volatile__ ("" : : : "memory")
+#define mb() __asm__ __volatile__ ("mfence" : : : "memory")
#define __iormb() dmb()
#define __iowmb() dmb()
--
2.39.2
[PATCH 0/5] net: dwc_eth_qos: Add glue driver for Intel MAC
This patch series implements the dwc_eth_qos glue driver for Intel SOCs. Before doing that, a few general adaptions to the dwc_eth_qos.c main driver are required. Most notably, the preparation for PCI based driver instances, which do not necessarily use a device tree. This patch series depends on: "net: dwc_eth_qos: mdio: Implement clause 45": https://patchwork.ozlabs.org/project/uboot/patch/20240423085158.29246-1-...@denx.de/ Philip Oberfichtner (5): x86: provide mb() macro net: dwc_eth_qos: Fix header to be self-contained net: dwc_eth_qos: Adapt probe() for PCI devices net: dwc_eth_qos: Implement bind() for PCI devices net: dwc_eth_qos: Add glue driver for Intel MAC arch/x86/include/asm/io.h | 1 + drivers/net/Kconfig| 7 + drivers/net/Makefile | 1 + drivers/net/dwc_eth_qos.c | 44 ++- drivers/net/dwc_eth_qos.h | 9 +- drivers/net/dwc_eth_qos_imx.c | 1 + drivers/net/dwc_eth_qos_intel.c| 446 + drivers/net/dwc_eth_qos_intel.h| 58 drivers/net/dwc_eth_qos_qcom.c | 1 + drivers/net/dwc_eth_qos_rockchip.c | 1 + drivers/net/dwc_eth_qos_starfive.c | 1 + drivers/net/dwc_eth_qos_stm32.c| 1 + include/pci_ids.h | 9 + 13 files changed, 576 insertions(+), 4 deletions(-) create mode 100644 drivers/net/dwc_eth_qos_intel.c create mode 100644 drivers/net/dwc_eth_qos_intel.h -- 2.39.2
Re: [PATCH 103/149] board: phytec: Remove and add needed includes
Am 01.05.24 um 04:42 schrieb Tom Rini: Remove from this board vendor directory and when needed add missing include files directly. Signed-off-by: Tom Rini Acked-by: Wadim Egorov --- Cc: Martyn Welch Cc: Parthiban Nallathambi Cc: "Albert ARIBAUD (3ADEV)" Cc: Niel Fourie Cc: Teresa Remmet Cc: Wadim Egorov Cc: Simon Glass Cc: Philipp Tomsich Cc: Kever Yang Cc: Yannic Moog Cc: Daniel Schultz Cc: Benjamin Hahn Cc: Fabio Estevam --- board/phytec/common/imx8m_som_detection.c| 1 - board/phytec/common/phytec_som_detection.c | 1 - board/phytec/pcl063/spl.c| 2 +- board/phytec/pcm052/pcm052.c | 1 - board/phytec/pcm058/pcm058.c | 1 - board/phytec/phycore_am335x_r2/board.c | 2 +- board/phytec/phycore_am335x_r2/mux.c | 1 - board/phytec/phycore_imx8mm/phycore-imx8mm.c | 1 - board/phytec/phycore_imx8mm/spl.c| 1 - board/phytec/phycore_imx8mp/phycore-imx8mp.c | 1 - board/phytec/phycore_imx8mp/spl.c| 1 - board/phytec/phycore_rk3288/phycore-rk3288.c | 1 - 12 files changed, 2 insertions(+), 12 deletions(-) diff --git a/board/phytec/common/imx8m_som_detection.c b/board/phytec/common/imx8m_som_detection.c index ee34a5b95791..bfd60ffb7773 100644 --- a/board/phytec/common/imx8m_som_detection.c +++ b/board/phytec/common/imx8m_som_detection.c @@ -4,7 +4,6 @@ * Author: Teresa Remmet */ -#include #include #include #include diff --git a/board/phytec/common/phytec_som_detection.c b/board/phytec/common/phytec_som_detection.c index 78c173df20d4..b14bb3dbb7fa 100644 --- a/board/phytec/common/phytec_som_detection.c +++ b/board/phytec/common/phytec_som_detection.c @@ -4,7 +4,6 @@ * Author: Teresa Remmet */ -#include #include #include #include diff --git a/board/phytec/pcl063/spl.c b/board/phytec/pcl063/spl.c index b6d459fdfce6..b98c46dbcbd4 100644 --- a/board/phytec/pcl063/spl.c +++ b/board/phytec/pcl063/spl.c @@ -6,7 +6,7 @@ * Copyright (C) 2015-2016 Stefan Roese */ -#include +#include #include #include #include diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c index 0f7235979b04..20f2aac332da 100644 --- a/board/phytec/pcm052/pcm052.c +++ b/board/phytec/pcm052/pcm052.c @@ -6,7 +6,6 @@ * Copyright 2013 Freescale Semiconductor, Inc. */ -#include #include #include #include diff --git a/board/phytec/pcm058/pcm058.c b/board/phytec/pcm058/pcm058.c index b37c6fe218da..ecc5b75d8d42 100644 --- a/board/phytec/pcm058/pcm058.c +++ b/board/phytec/pcm058/pcm058.c @@ -9,7 +9,6 @@ * Both NAND and eMMC cannot be set because they share the * same pins (SD4) */ -#include #include #include #include diff --git a/board/phytec/phycore_am335x_r2/board.c b/board/phytec/phycore_am335x_r2/board.c index 5700effbd3f6..2022525651dc 100644 --- a/board/phytec/phycore_am335x_r2/board.c +++ b/board/phytec/phycore_am335x_r2/board.c @@ -10,7 +10,7 @@ * Copyright (C) 2019 DENX Software Engineering GmbH */ -#include +#include #include #include #include diff --git a/board/phytec/phycore_am335x_r2/mux.c b/board/phytec/phycore_am335x_r2/mux.c index 7091c985ba12..bb1c48da0fe5 100644 --- a/board/phytec/phycore_am335x_r2/mux.c +++ b/board/phytec/phycore_am335x_r2/mux.c @@ -6,7 +6,6 @@ * Copyright (C) 2019 DENX Software Engineering GmbH */ -#include #include #include #include diff --git a/board/phytec/phycore_imx8mm/phycore-imx8mm.c b/board/phytec/phycore_imx8mm/phycore-imx8mm.c index ef6472916903..06cffbca3a69 100644 --- a/board/phytec/phycore_imx8mm/phycore-imx8mm.c +++ b/board/phytec/phycore_imx8mm/phycore-imx8mm.c @@ -4,7 +4,6 @@ * Author: Teresa Remmet */ -#include #include #include #include diff --git a/board/phytec/phycore_imx8mm/spl.c b/board/phytec/phycore_imx8mm/spl.c index 690a51f7a72e..8d858590a39b 100644 --- a/board/phytec/phycore_imx8mm/spl.c +++ b/board/phytec/phycore_imx8mm/spl.c @@ -4,7 +4,6 @@ * Author: Teresa Remmet */ -#include #include #include #include diff --git a/board/phytec/phycore_imx8mp/phycore-imx8mp.c b/board/phytec/phycore_imx8mp/phycore-imx8mp.c index dbdd6bb79373..35683591433c 100644 --- a/board/phytec/phycore_imx8mp/phycore-imx8mp.c +++ b/board/phytec/phycore_imx8mp/phycore-imx8mp.c @@ -4,7 +4,6 @@ * Author: Teresa Remmet */ -#include #include #include #include diff --git a/board/phytec/phycore_imx8mp/spl.c b/board/phytec/phycore_imx8mp/spl.c index df158024654e..352f803e4541 100644 --- a/board/phytec/phycore_imx8mp/spl.c +++ b/board/phytec/phycore_imx8mp/spl.c @@ -4,7 +4,6 @@ * Author: Teresa Remmet */ -#include #include #include #include diff --git a/board/phytec/phycore_rk3288/phycore-rk3288.c b/board/phytec/phycore_rk3288/phycore-rk3288.c index 1ddb4a4f8085..a970634b4c33 100644 --- a/board/phytec/phycore_rk3288/phycore-rk3288.c +++ b/board/phytec/p
Re: [PATCH] configs: Make USB_GADGET_MANUFACTURER consistent over all PHYTEC boards
Am 03.05.24 um 09:00 schrieb Benjamin Hahn: Set CONFIG_USB_GADGET_MANUFACTURER to PHYTEC for all PHYTEC boards. Signed-off-by: Benjamin Hahn Acked-by: Wadim Egorov --- configs/phycore-imx8mp_defconfig | 2 +- configs/phycore_am64x_a53_defconfig | 2 +- configs/phycore_am64x_r5_defconfig | 2 +- configs/phycore_pcl063_defconfig | 2 +- configs/phycore_pcl063_ull_defconfig | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/configs/phycore-imx8mp_defconfig b/configs/phycore-imx8mp_defconfig index e9a287cb441f..9f42edd72324 100644 --- a/configs/phycore-imx8mp_defconfig +++ b/configs/phycore-imx8mp_defconfig @@ -147,7 +147,7 @@ CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_IMX_WATCHDOG=y diff --git a/configs/phycore_am64x_a53_defconfig b/configs/phycore_am64x_a53_defconfig index 1a9359773b45..9b52f8ad0644 100644 --- a/configs/phycore_am64x_a53_defconfig +++ b/configs/phycore_am64x_a53_defconfig @@ -159,7 +159,7 @@ CONFIG_USB_CDNS3=y CONFIG_USB_CDNS3_GADGET=y CONFIG_USB_CDNS3_HOST=y CONFIG_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 CONFIG_USB_GADGET_DOWNLOAD=y diff --git a/configs/phycore_am64x_r5_defconfig b/configs/phycore_am64x_r5_defconfig index 61d784fa17f6..15a7e7089e73 100644 --- a/configs/phycore_am64x_r5_defconfig +++ b/configs/phycore_am64x_r5_defconfig @@ -171,7 +171,7 @@ CONFIG_USB_STORAGE=y CONFIG_SPL_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_SPL_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 CONFIG_USB_GADGET_DOWNLOAD=y diff --git a/configs/phycore_pcl063_defconfig b/configs/phycore_pcl063_defconfig index 017054a8e12b..2f6b158a6772 100644 --- a/configs/phycore_pcl063_defconfig +++ b/configs/phycore_pcl063_defconfig @@ -62,7 +62,7 @@ CONFIG_IMX_THERMAL=y CONFIG_USB=y CONFIG_SPL_USB_HOST=y CONFIG_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Phytec" +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff CONFIG_CI_UDC=y diff --git a/configs/phycore_pcl063_ull_defconfig b/configs/phycore_pcl063_ull_defconfig index b3da43a5bf1e..b42a410da69c 100644 --- a/configs/phycore_pcl063_ull_defconfig +++ b/configs/phycore_pcl063_ull_defconfig @@ -53,7 +53,7 @@ CONFIG_IMX_THERMAL=y CONFIG_USB=y CONFIG_SPL_USB_HOST=y CONFIG_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Phytec" +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff CONFIG_CI_UDC=y --- base-commit: 6fdb021f148f598a67eb3cac5e3eb4a569cdaacd change-id: 20240503-wip-bhahn-bspimx8m-3196-c1ebd0bab6ac Best regards,
[PATCH v2] clk: Revise help text for clk_get_parent_rate()
The function returns the rate of the parent clock, the previous text
made no sense at all.
Fixes: 4aa78300a025 ("dm: clk: Define clk_get_parent_rate() for clk operations")
Signed-off-by: Alexander Dahl
Reviewed-by: Sean Anderson
---
Notes:
v2:
- Collected tags
include/clk.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/clk.h b/include/clk.h
index af23e4f3475..045e923a529 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -444,7 +444,7 @@ ulong clk_get_rate(struct clk *clk);
struct clk *clk_get_parent(struct clk *clk);
/**
- * clk_get_parent_rate() - Get parent of current clock rate.
+ * clk_get_parent_rate() - Get rate of current clock's parent.
* @clk: A clock struct that was previously successfully requested by
* clk_request/get_by_*().
*
base-commit: c92d48f8b2909d08584f17612a23d959467f14b8
--
2.39.2
[PATCH] configs: Make USB_GADGET_MANUFACTURER consistent over all PHYTEC boards
Set CONFIG_USB_GADGET_MANUFACTURER to PHYTEC for all PHYTEC boards. Signed-off-by: Benjamin Hahn --- configs/phycore-imx8mp_defconfig | 2 +- configs/phycore_am64x_a53_defconfig | 2 +- configs/phycore_am64x_r5_defconfig | 2 +- configs/phycore_pcl063_defconfig | 2 +- configs/phycore_pcl063_ull_defconfig | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/configs/phycore-imx8mp_defconfig b/configs/phycore-imx8mp_defconfig index e9a287cb441f..9f42edd72324 100644 --- a/configs/phycore-imx8mp_defconfig +++ b/configs/phycore-imx8mp_defconfig @@ -147,7 +147,7 @@ CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_IMX_WATCHDOG=y diff --git a/configs/phycore_am64x_a53_defconfig b/configs/phycore_am64x_a53_defconfig index 1a9359773b45..9b52f8ad0644 100644 --- a/configs/phycore_am64x_a53_defconfig +++ b/configs/phycore_am64x_a53_defconfig @@ -159,7 +159,7 @@ CONFIG_USB_CDNS3=y CONFIG_USB_CDNS3_GADGET=y CONFIG_USB_CDNS3_HOST=y CONFIG_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 CONFIG_USB_GADGET_DOWNLOAD=y diff --git a/configs/phycore_am64x_r5_defconfig b/configs/phycore_am64x_r5_defconfig index 61d784fa17f6..15a7e7089e73 100644 --- a/configs/phycore_am64x_r5_defconfig +++ b/configs/phycore_am64x_r5_defconfig @@ -171,7 +171,7 @@ CONFIG_USB_STORAGE=y CONFIG_SPL_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_SPL_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 CONFIG_USB_GADGET_DOWNLOAD=y diff --git a/configs/phycore_pcl063_defconfig b/configs/phycore_pcl063_defconfig index 017054a8e12b..2f6b158a6772 100644 --- a/configs/phycore_pcl063_defconfig +++ b/configs/phycore_pcl063_defconfig @@ -62,7 +62,7 @@ CONFIG_IMX_THERMAL=y CONFIG_USB=y CONFIG_SPL_USB_HOST=y CONFIG_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Phytec" +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff CONFIG_CI_UDC=y diff --git a/configs/phycore_pcl063_ull_defconfig b/configs/phycore_pcl063_ull_defconfig index b3da43a5bf1e..b42a410da69c 100644 --- a/configs/phycore_pcl063_ull_defconfig +++ b/configs/phycore_pcl063_ull_defconfig @@ -53,7 +53,7 @@ CONFIG_IMX_THERMAL=y CONFIG_USB=y CONFIG_SPL_USB_HOST=y CONFIG_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Phytec" +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff CONFIG_CI_UDC=y --- base-commit: 6fdb021f148f598a67eb3cac5e3eb4a569cdaacd change-id: 20240503-wip-bhahn-bspimx8m-3196-c1ebd0bab6ac Best regards, -- Benjamin Hahn
