Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi Michael On 05/04/24 13:12, Michael Walle wrote: Hi, On Thu Apr 4, 2024 at 11:10 AM CEST, Neha Malcom Francis wrote: But again in the interest of time... this would mean this cleaning up effort be kept on hold. If we can agree to move to using the generator later as the final solution, can we pick up this series for now? Agreed. I just saw the new RFC for the j722s support. It should also make use of this cleanup then, btw. Right, I'll sync with J722S efforts as well. So is this series good to go? -michael -- Thanking You Neha Malcom Francis
Re: [PATCH] net: ti: am65-cpsw: Fix buffer overflow
On Wed, 03 Apr 2024 16:31:55 +0200, Michael Walle wrote: > The device name is a concatenation of the device node name of the cpsw > device and of the device node name of the port. In my case that is > > ethernet@800 > port@1 > > First the buffer is really too small, but more importantly, there is no > boundary check. Use snprintf() and increase the buffer size. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v1] arm: mach-k3: common: EFI loader map memory below ram top
On Thu, 28 Mar 2024 10:05:48 +, Vitor Soares wrote: > During the boot, the EFI loader maps the memory from ram_top to ram_end > as EFI_BOOT_SERVICES_DATA. When LMB does boot_fdt_add_mem_rsv_regions() > to OPTEE, TFA, R5, and M4F DMA/memory "no-map" for the kernel it produces > the following error message: > > ERROR: reserving fdt memory region failed (addr=9cb0 size=10 flags=4) > ERROR: reserving fdt memory region failed (addr=9cc0 size=e0 flags=4) > ERROR: reserving fdt memory region failed (addr=9da0 size=10 flags=4) > ERROR: reserving fdt memory region failed (addr=9db0 size=c0 flags=4) > ERROR: reserving fdt memory region failed (addr=9e78 size=8 flags=4) > ERROR: reserving fdt memory region failed (addr=9e80 size=180 flags=4) > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] am625x_evm_a53: Tweak boot command to set fdt
On Tue, 26 Mar 2024 14:26:33 +, Martyn Welch wrote: > With the current config for tha SK-AM62, fdtfile isn't set in the U-Boot > environment. When using bootflow to boot from a block device, where the > extlinux.conf file specifies `fdtdir`, a fallback device tree is being > constructed from the `soc` (`k3`) and `board` (`am62x`) environment > variables, resulting in u-Boot trying to retrieve > `/dtbs/6.8.1+/k3-am62x.dtb`. This file doesn't exist. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] tools: binman: ti_board_cfg: improve error message
On Tue, 26 Mar 2024 10:39:34 +0100, Michael Walle wrote: > When there is a lint error the user gets the following cryptic message: > > binman: Node '/path/to/some/node': Yamllint error: 18: comments > > This isn't very helpful. Improve the message to tell the user that the > number is actually a line number and also tell the user in which file > they have to look. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] binman: ti-secure: Enable debug extension for combined boot
On Tue, 26 Mar 2024 13:37:06 +0530, Manorit Chawdhry wrote: > To debug using jtag, ROM needs to unlock jtag debugging on HS devices > and it does that looking at this debug extension. > > Add the debug extension and enable it by default. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 0/2] arm: mach-k3: am62: change a53 clock frequency by speed grade
On Wed, 20 Mar 2024 09:16:30 -0300, Joao Paulo Goncalves wrote: > From: Joao Paulo Goncalves > > This series introduces a method to dynamically set the AM62 A53 CPU frequency > based on its speed grade. It adds a new function to retrieve the A53 frequency > value by reading the speed grade from the hardware. Subsequently, it adjusts > the > Cortex R5 device tree at runtime with the frequency value before initializing > the remote processor. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] configs: am6*_evm_a53_defconfig: Enable config to support mmc rescan
On Tue, 19 Mar 2024 13:43:43 -0500, Judith Mendez wrote: > Enable MMC_SPEED_MODE_SET config option in defconfig to enable > mmc rescan for various Sitara devices. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 0/3] arm: Add Analog Devices SC5xx Machine Type
I'm afraid I have to admit I don't know. I'll work with our IT team to make sure we can run CI locally, and when v2 comes around the answer will be yes. On Thu, Apr 11, 2024 at 7:52 PM Tom Rini wrote: > > On Thu, Apr 11, 2024 at 07:37:27PM -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 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. The clock tree itself is only used by the UART in this minimal > > patch set, but is of course broadly useful for all other peripheral > > drivers to be submitted in future patch sets. There are also no board > > files or defconfigs included here, but some common definitions that will > > be used to build board files currently are. > > > > 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 bugs that could take a > > significant amount of time to detect in the future. > > > > Please provide any feedback or comments that will be helpful in creating > > a v2 of this patch that will be ready to submit for inclusion into the > > main tree, as well as general observations that we should consider in > > other driver patches before submitting them. > > Does this series pass CI currently? Thanks. > > -- > Tom -- Greg Malysa Timesys Corporation
Re: [PATCH 1/3] arch: arm: Add Analog Devices SC5xx machine type
Hi Tom, Thanks for the quick feedback. I'll go through our patches and review the #include usage as part of preparing for v2, and we'll work out switching to the plain text environment as well. I'll drop the custom compiler options and make sure we weren't actually relying on them--possibly it was just necessary for the initial set of init code we started with. I believe we're not using the mach type constants anywhere so that will be straightforward to drop as well. Thanks, Greg On Thu, Apr 11, 2024 at 7:58 PM Tom Rini wrote: > > On Thu, Apr 11, 2024 at 07:37:28PM -0400, Greg Malysa wrote: > > > From: Nathan Barrett-Morrison > > > > Add support for the SC5xx machine type from Analog Devices. This > > includes support for the SC57x, SC58x, SC59x, and SC59x-64 SoCs, which > > have many common features such as common ADI IP blocks, and SHARC DSP > > cores. This commit introduces core functionality required for all boards > > using an SC5xx SoC, such as: > > > > - SPL configuration > > - Required CPU hooks such as reset > > - Boot ROM interaction to load the stage 2 bootloader in the reference > > configuration. Other options are possible but not officially supported > > at this time > > - SoC-common configuration expected to be reused by all boards > > - Early initialization for system clocks and DDR controller > > > > Co-developed-by: Greg Malysa > > Signed-off-by: Greg Malysa > > Co-developed-by: Ian Roberts > > Signed-off-by: Ian Roberts > > Signed-off-by: Vasileios Bimpikas > > Signed-off-by: Utsav Agarwal > > Signed-off-by: Arturs Artamonovs > > Signed-off-by: Nathan Barrett-Morrison > > > > --- > > > > > > --- > > MAINTAINERS | 13 + > > arch/arm/Kconfig | 6 + > > arch/arm/Makefile| 1 + > > arch/arm/include/asm/arch-adi/sc5xx/sc5xx.h | 115 +++ > > arch/arm/include/asm/arch-adi/sc5xx/soc.h| 18 + > > arch/arm/include/asm/arch-adi/sc5xx/spl.h| 41 + > > arch/arm/include/asm/mach-types.h| 4 + > > We shouldn't be adding more to mach-types.h. > > > arch/arm/mach-sc5xx/Kconfig | 464 + > > Here and elsewhere I think I saw whitespace issues (help should be > ) in the entries, along with adding "default n" for > new options, and that's not needed as n is the default. > > [snip] > > diff --git a/arch/arm/mach-sc5xx/config.mk b/arch/arm/mach-sc5xx/config.mk > > new file mode 100644 > > index 00..b80644d6dc > > --- /dev/null > > +++ b/arch/arm/mach-sc5xx/config.mk > [snip] > > +ifndef CONFIG_SC59X_64 > > + # Select the Analog Devices processor. > > + PLATFORM_RELFLAGS += -fno-stack-protector -std=gnu89 > > +endif > > We should be using the defaults here. > > Also: > - Please switch to plain text environment instead of defining in board.h > and so on. > - Audit your #include usage, I saw more that is likely needed > for example. > > -- > Tom -- Greg Malysa Timesys Corporation
Re: [PATCH RFC 00/15] Support SPI NAND booting on the T113
On Thu, Apr 11, 2024 at 05:27:08PM -0600, Sam Edwards wrote:
> Hi John,
>
> It doesn't look like I was sent the whole series (only 00 and 01), but
> I was able to find it on Patchwork and sift through it. A few general
> comments follow:
>
> The introduction of `SUNXI_BOOTED_FROM_SPINAND` is the right call,
> since the newer sunxis use this for SPI-NAND, and
> `SUNXI_BOOTED_FROM_SPI` for SPI-NOR. The older sunxis, however, will
> use `SUNXI_BOOTED_FROM_SPI` for "it's either SPI-NAND or SPI-NOR, have
> fun figuring out which." While the rationale in 09/15 ("Instead of
> trying to boot from SPI NAND then SPI NOR in series, select one based
> on the current boot device.") is solid, we still need some code
> (perhaps in/called from `sunxi_get_boot_device`?) to handle the
> `SUNXI_BOOTED_FROM_SPI` case by performing flash type detection --
> disabled for those sunxis known to use `SUNXI_BOOTED_FROM_SPINAND`, of
> course.
Is there already code that can do this probing somewhere in U-Boot?
I'd rather not try and support older boards with an ambiguous boot
method, they already don't work.
> 06/15 ("sunxi: enable support for SPI NAND booting on SUNIV") should
> be dropped from the series. You are updating `suniv_get_boot_source`
> when introducing `SUNXI_BOOTED_FROM_SPINAND` anyway, so you can just
> hook up `SUNIV_BOOTED_FROM_NAND` at that time (and a heads-up: I think
> you got it wired backwards in this version of the series).
Some of the redunancy in patches are from including Icenowy's patchset.
> On a more fundamental note: I am hesitant about the overall approach
> of having NAND reading code in `arch/arm/mach-sunxi/spl_spi_sunxi.c`.
> NANDs are more complex than NORs (requiring e.g. bad block handling)
> and U-Boot generally keeps the SPL load methods in
> `common/spl/spl_*.c`. It's good that the UBI-on-SPI-NAND method is
> hooked up there, but the "U-Boot image follows the (good) blocks of
> the SPL in NAND" method should probably live in the same directory.
>
> Here's what I'd like to explore: can we introduce a
> `common/spl/spl_spinand.c` and update the `drivers/mtd/nand/spi/*.c`
> code to support running in SPL? This way
> `arch/arm/mach-sunxi/spl_spi_sunxi.c` must only provide the SPL-mode
> implementation of SPI -- that is, the actual sunxi-specific bit. Also,
> updating the `drivers/mtd/nand/spi/*.c` drivers for SPL-friendliness
> will mean dropping those `SPL_SPINAND_{PAGE,BLOCK}_SIZE` configuration
> options: the tables in the drivers will be the ones providing those
> after NAND autodetection.
This is a little bit of a mess:
common/spl/spl_spi.c implements general SPI NOR reading
drivers/mtd/spi/sf-uclass.c wraps SPI flash access using DM
drivers/spi/spi-sunxi.c implements the SPI controller
arch/arm/mach-sunxi/spl_spi_sunxi.c overrides spl_spi
It would be good to somehow have spl_spi provide functions spl_spi
uses instead of having spl_spi_sunxi implement it directly.
common/spl/spl_nand.c implements general NAND reading
common/spl/spl_ubi.c implements UBI reading
drivers/mtd/nand/raw/sunxi_nand.c implements sunxi NAND reading
drivers/mtd/nand/raw/nand_spl_simple.c implmements a generic solution
drivers/mtd/nand/raw/sunxi_nand_spl.c implements sunxi SPL NAND reading
spl_ubi requires nand_spl_simple callbacks, sunxi_nand_spl doesn't
implement these.
It's possible spl_spi, spl_nand and spl_ubi all work if the DM code is
used for sunxi. Maybe that's a good goal here? Getting DM in SPL working
on these boards then hooking it in to spl_ubi seems like it could solve
some pain. I'm not too concerned about old SoCs at this point.
For non-DM Adding spl_spinand would work for the case of reading the
next good block. I'm not actually sure if the SPI NAND code supports the
bad block table yet. But we would still need an API for spl_ubi to
access.
>
> Thoughts?
>
> Cheers,
> Sam
John.
Re: [PATCH 1/4] arm: davinci: Migrate da850-evm to OF_UPSTREAM
On Wed, Apr 03, 2024 at 10:00:09PM -0500, Adam Ford wrote: > The da850-evm can remove the U-Boot device trees if migrated > to OF_UPSTREAM. This means pointing the device trees to the > ti/davinci directory. > > Signed-off-by: Adam Ford This series leads to failure to build for omapl138_lcdk and lego_ev3 or was I supposed to bring in something else first? Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] arch: arm: Add Analog Devices SC5xx machine type
On Thu, Apr 11, 2024 at 07:37:28PM -0400, Greg Malysa wrote: > From: Nathan Barrett-Morrison > > Add support for the SC5xx machine type from Analog Devices. This > includes support for the SC57x, SC58x, SC59x, and SC59x-64 SoCs, which > have many common features such as common ADI IP blocks, and SHARC DSP > cores. This commit introduces core functionality required for all boards > using an SC5xx SoC, such as: > > - SPL configuration > - Required CPU hooks such as reset > - Boot ROM interaction to load the stage 2 bootloader in the reference > configuration. Other options are possible but not officially supported > at this time > - SoC-common configuration expected to be reused by all boards > - Early initialization for system clocks and DDR controller > > Co-developed-by: Greg Malysa > Signed-off-by: Greg Malysa > Co-developed-by: Ian Roberts > Signed-off-by: Ian Roberts > Signed-off-by: Vasileios Bimpikas > Signed-off-by: Utsav Agarwal > Signed-off-by: Arturs Artamonovs > Signed-off-by: Nathan Barrett-Morrison > > --- > > > --- > MAINTAINERS | 13 + > arch/arm/Kconfig | 6 + > arch/arm/Makefile| 1 + > arch/arm/include/asm/arch-adi/sc5xx/sc5xx.h | 115 +++ > arch/arm/include/asm/arch-adi/sc5xx/soc.h| 18 + > arch/arm/include/asm/arch-adi/sc5xx/spl.h| 41 + > arch/arm/include/asm/mach-types.h| 4 + We shouldn't be adding more to mach-types.h. > arch/arm/mach-sc5xx/Kconfig | 464 + Here and elsewhere I think I saw whitespace issues (help should be ) in the entries, along with adding "default n" for new options, and that's not needed as n is the default. [snip] > diff --git a/arch/arm/mach-sc5xx/config.mk b/arch/arm/mach-sc5xx/config.mk > new file mode 100644 > index 00..b80644d6dc > --- /dev/null > +++ b/arch/arm/mach-sc5xx/config.mk [snip] > +ifndef CONFIG_SC59X_64 > + # Select the Analog Devices processor. > + PLATFORM_RELFLAGS += -fno-stack-protector -std=gnu89 > +endif We should be using the defaults here. Also: - Please switch to plain text environment instead of defining in board.h and so on. - Audit your #include usage, I saw more that is likely needed for example. -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/3] arm: Add Analog Devices SC5xx Machine Type
On Thu, Apr 11, 2024 at 07:37:27PM -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 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. The clock tree itself is only used by the UART in this minimal > patch set, but is of course broadly useful for all other peripheral > drivers to be submitted in future patch sets. There are also no board > files or defconfigs included here, but some common definitions that will > be used to build board files currently are. > > 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 bugs that could take a > significant amount of time to detect in the future. > > Please provide any feedback or comments that will be helpful in creating > a v2 of this patch that will be ready to submit for inclusion into the > main tree, as well as general observations that we should consider in > other driver patches before submitting them. Does this series pass CI currently? Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] board: rockchip: Add the Turing RK1 SoM
Hey Sam,
On 24-04-11 16:35:57, Sam Edwards wrote:
On Thu, Apr 11, 2024 at 1:29 AM Florian Klink wrote:
On 23-12-14 18:46:47, Joshua Riek wrote:
>The Turing RK1 is a Rockchip RK3588 based SoM from Turing Machines.
>
>Specifications:
>
>Rockchip RK3588 SoC
>4x ARM Cortex-A76, 4x ARM Cortex-A55
>8/16/32GB memory LPDDR4x
>Mali G610MC4 GPU
>32GB eMMC HS400
>2x USB 2.0, 2x USB 3.0
>2x MIPI CSI 4x lanes
>1x MIPI-DSI DPHY 2x lanes
>PCIe 2.0 x1, PCIe 3.0 x4
>1x HDMI 2.1 output, 1x DP 1.4 output
>Gigabit Ethernet
>Size: 69.6mm x 45mm (260-pin SO-DIMM connector)
>
>Kernel commit:
>2806a69f3fef ("arm64: dts: rockchip: Add Turing RK1 SoM support")
[…]
>diff --git a/configs/turing-rk1-rk3588_defconfig
b/configs/turing-rk1-rk3588_defconfig
>new file mode 100644
>index 00..289f2da775
>--- /dev/null
>+++ b/configs/turing-rk1-rk3588_defconfig
>@@ -0,0 +1,133 @@
>+CONFIG_ARM=y
>+CONFIG_SKIP_LOWLEVEL_INIT=y
>+CONFIG_SYS_HAS_NONCACHED_MEMORY=y
>+CONFIG_COUNTER_FREQUENCY=2400
>+CONFIG_ARCH_ROCKCHIP=y
>+CONFIG_TEXT_BASE=0x00a0
>+CONFIG_SPL_LIBCOMMON_SUPPORT=y
>+CONFIG_SPL_LIBGENERIC_SUPPORT=y
>+CONFIG_NR_DRAM_BANKS=2
>+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
>+CONFIG_SF_DEFAULT_SPEED=2400
>+CONFIG_SF_DEFAULT_MODE=0x2000
>+CONFIG_DEFAULT_DEVICE_TREE="rk3588-turing-rk1"
>+CONFIG_ROCKCHIP_RK3588=y
>+CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
>+CONFIG_ROCKCHIP_SPI_IMAGE=y
Hi Florian,
Thanks for getting in touch!
Does the RK1 have an SPI chip attached, and is is possible to flash
u-boot into SPI and boot from it?
The answer you want is "no." Though the RK1 does have an unpopulated
pad for SPI flash, actually installing one would be a pretty involved
user modification, and those users almost certainly can/will build the
SPI boot image themselves.
This has sparked some confusion on whether "u-boot-rockchip-spi.bin"
should be provided in a downstream build or not.
Ah yeah the CONFIG_ROCKCHIP_SPI_IMAGE=y might not be a sensible
default given that 99.9% of users don't need it. Is that config entry
the main thing creating the confusion? I think it should be removed
here in U-Boot if so.
Yes, it caused a "u-boot-rockchip-spi.bin" to be produced, and we were
wondering on whether it should be provided as a result of our build to
downstream users [1].
Removing it from the `defconfig` sounds like the best way to prevent
this confusion. If people solder on a SPI Flash manually, they probably
know how to re-add it to the uboot config ;-)
Could you send a patch for that?
Note that the RK1 is a little different from most RK3588 boards in
that UART9 at 115200 baud is the generally-accepted debug UART (due
both to the popularity of pairing it with the Turing Pi 2
clusterboard, and for pin-compatibility with most NVIDIA Jetson SoMs),
and setting this very early in boot requires using Rockchip's
"ddrbin_tool" to change the configuration embedded in the ddrbin/TPL
image. If you're already supporting other targets that require ddrbin
configuration changes, please add these for RK1:
uart id=9
uart iomux=0
uart baudrate=115200
...but if this would require going significantly out of your way,
don't worry about it. IIUC this is only required to get TPL+SPL output
routed correctly: the U-Boot monitor + kernel will still
(re)initialize UART9 appropriately.
We currently simply use
`bin/rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.16.bin`
from https://github.com/rockchip-linux/rkbin for all RK3588 targets as
`ROCKCHIP_TPL`.
There doesn't seem to be a RK1-specific blob in the repo, and so far
we're not invoking the closed-source x86_64-linux-only
`tools/ddrbin_tool` binary to produce an alternative version of the SPL
for other targets either.
So if it also works without doing that (maybe with a little bit less
debug serial output during early boot) we'd probably keep it like this
;-)
Thanks,
Florian
[1]: https://github.com/NixOS/nixpkgs/pull/302138#discussion_r1560349114
[PATCH 1/3] arch: arm: Add Analog Devices SC5xx machine type
From: Nathan Barrett-Morrison Add support for the SC5xx machine type from Analog Devices. This includes support for the SC57x, SC58x, SC59x, and SC59x-64 SoCs, which have many common features such as common ADI IP blocks, and SHARC DSP cores. This commit introduces core functionality required for all boards using an SC5xx SoC, such as: - SPL configuration - Required CPU hooks such as reset - Boot ROM interaction to load the stage 2 bootloader in the reference configuration. Other options are possible but not officially supported at this time - SoC-common configuration expected to be reused by all boards - Early initialization for system clocks and DDR controller Co-developed-by: Greg Malysa Signed-off-by: Greg Malysa Co-developed-by: Ian Roberts Signed-off-by: Ian Roberts Signed-off-by: Vasileios Bimpikas Signed-off-by: Utsav Agarwal Signed-off-by: Arturs Artamonovs Signed-off-by: Nathan Barrett-Morrison --- --- MAINTAINERS | 13 + arch/arm/Kconfig | 6 + arch/arm/Makefile| 1 + arch/arm/include/asm/arch-adi/sc5xx/sc5xx.h | 115 +++ arch/arm/include/asm/arch-adi/sc5xx/soc.h| 18 + arch/arm/include/asm/arch-adi/sc5xx/spl.h| 41 + arch/arm/include/asm/mach-types.h| 4 + arch/arm/mach-sc5xx/Kconfig | 464 + arch/arm/mach-sc5xx/Makefile | 19 + arch/arm/mach-sc5xx/config.mk| 21 + arch/arm/mach-sc5xx/init/Makefile| 11 + arch/arm/mach-sc5xx/init/clkinit.c | 543 +++ arch/arm/mach-sc5xx/init/clkinit.h | 18 + arch/arm/mach-sc5xx/init/dmcinit.c | 973 +++ arch/arm/mach-sc5xx/init/dmcinit.h | 29 + arch/arm/mach-sc5xx/init/init.c | 68 ++ arch/arm/mach-sc5xx/init/init.h | 37 + arch/arm/mach-sc5xx/init/mem/is43tr16512bl.h | 63 ++ arch/arm/mach-sc5xx/init/mem/mt41k128m16jt.h | 51 + arch/arm/mach-sc5xx/init/mem/mt41k512m16ha.h | 51 + arch/arm/mach-sc5xx/init/mem/mt47h128m16rt.h | 50 + arch/arm/mach-sc5xx/rcu.c| 22 + arch/arm/mach-sc5xx/sc57x.c | 21 + arch/arm/mach-sc5xx/sc58x.c | 21 + arch/arm/mach-sc5xx/sc59x.c | 32 + arch/arm/mach-sc5xx/sc59x_64.c | 36 + arch/arm/mach-sc5xx/soc.c| 142 +++ arch/arm/mach-sc5xx/spl.c| 140 +++ include/configs/sc_adi_common.h | 226 + 29 files changed, 3236 insertions(+) create mode 100644 arch/arm/include/asm/arch-adi/sc5xx/sc5xx.h create mode 100644 arch/arm/include/asm/arch-adi/sc5xx/soc.h create mode 100644 arch/arm/include/asm/arch-adi/sc5xx/spl.h create mode 100644 arch/arm/mach-sc5xx/Kconfig create mode 100644 arch/arm/mach-sc5xx/Makefile create mode 100644 arch/arm/mach-sc5xx/config.mk create mode 100644 arch/arm/mach-sc5xx/init/Makefile create mode 100644 arch/arm/mach-sc5xx/init/clkinit.c create mode 100644 arch/arm/mach-sc5xx/init/clkinit.h create mode 100644 arch/arm/mach-sc5xx/init/dmcinit.c create mode 100644 arch/arm/mach-sc5xx/init/dmcinit.h create mode 100644 arch/arm/mach-sc5xx/init/init.c create mode 100644 arch/arm/mach-sc5xx/init/init.h create mode 100644 arch/arm/mach-sc5xx/init/mem/is43tr16512bl.h create mode 100644 arch/arm/mach-sc5xx/init/mem/mt41k128m16jt.h create mode 100644 arch/arm/mach-sc5xx/init/mem/mt41k512m16ha.h create mode 100644 arch/arm/mach-sc5xx/init/mem/mt47h128m16rt.h create mode 100644 arch/arm/mach-sc5xx/rcu.c create mode 100644 arch/arm/mach-sc5xx/sc57x.c create mode 100644 arch/arm/mach-sc5xx/sc58x.c create mode 100644 arch/arm/mach-sc5xx/sc59x.c create mode 100644 arch/arm/mach-sc5xx/sc59x_64.c create mode 100644 arch/arm/mach-sc5xx/soc.c create mode 100644 arch/arm/mach-sc5xx/spl.c create mode 100644 include/configs/sc_adi_common.h diff --git a/MAINTAINERS b/MAINTAINERS index 83fd68e3f3..9693b86ddd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -598,6 +598,19 @@ R: Marc Murphy S: Supported F: arch/arm/dts/am335x-sancloud* +ARM SC5XX +M: Nathan Barrett-Morrison +M: Greg Malysa +M: Ian Roberts +M: Vasileios Bimpikas +M: Utsav Agarwal +M: Arturs Artamonovs +S: Supported +T: git https://github.com/analogdevicesinc/lnxdsp-u-boot +F: arch/arm/include/asm/arch-adi/ +F: arch/arm/mach-sc5xx/ +F: include/configs/sc_adi_common.h + ARM SNAPDRAGON M: Caleb Connolly M: Neil Armstrong diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index a0842e1933..fdaf4e23d0 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1843,6 +1843,10 @@ config TARGET_LS1046AFRWY development platform that supports the QorIQ LS1046A Layerscape Architecture processor. +config ARCH_SC5XX + bool "Analog Devices SC5XX-processor family" + select STATIC_MACH_TYPE + config TARGET_SL28
[PATCH 0/3] arm: Add Analog Devices SC5xx Machine Type
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 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. The clock tree itself is only used by the UART in this minimal patch set, but is of course broadly useful for all other peripheral drivers to be submitted in future patch sets. There are also no board files or defconfigs included here, but some common definitions that will be used to build board files currently are. 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 bugs that could take a significant amount of time to detect in the future. Please provide any feedback or comments that will be helpful in creating a v2 of this patch that will be ready to submit for inclusion into the main tree, as well as general observations that we should consider in other driver patches before submitting them. Thank you! Nathan Barrett-Morrison (3): arch: arm: Add Analog Devices SC5xx machine type drivers: clk: adi: Add in SC5XX-family clock driver drivers: serial: Add in UART for ADI SC5XX-family processors MAINTAINERS | 15 + arch/arm/Kconfig | 6 + arch/arm/Makefile| 1 + arch/arm/include/asm/arch-adi/sc5xx/sc5xx.h | 115 +++ arch/arm/include/asm/arch-adi/sc5xx/soc.h| 18 + arch/arm/include/asm/arch-adi/sc5xx/spl.h| 41 + arch/arm/include/asm/mach-types.h| 4 + arch/arm/mach-sc5xx/Kconfig | 464 + arch/arm/mach-sc5xx/Makefile | 19 + arch/arm/mach-sc5xx/config.mk| 21 + arch/arm/mach-sc5xx/init/Makefile| 11 + arch/arm/mach-sc5xx/init/clkinit.c | 543 +++ arch/arm/mach-sc5xx/init/clkinit.h | 18 + arch/arm/mach-sc5xx/init/dmcinit.c | 973 +++ arch/arm/mach-sc5xx/init/dmcinit.h | 29 + arch/arm/mach-sc5xx/init/init.c | 68 ++ arch/arm/mach-sc5xx/init/init.h | 37 + arch/arm/mach-sc5xx/init/mem/is43tr16512bl.h | 63 ++ arch/arm/mach-sc5xx/init/mem/mt41k128m16jt.h | 51 + arch/arm/mach-sc5xx/init/mem/mt41k512m16ha.h | 51 + arch/arm/mach-sc5xx/init/mem/mt47h128m16rt.h | 50 + arch/arm/mach-sc5xx/rcu.c| 22 + arch/arm/mach-sc5xx/sc57x.c | 21 + arch/arm/mach-sc5xx/sc58x.c | 21 + arch/arm/mach-sc5xx/sc59x.c | 32 + arch/arm/mach-sc5xx/sc59x_64.c | 36 + arch/arm/mach-sc5xx/soc.c| 142 +++ arch/arm/mach-sc5xx/spl.c| 140 +++ drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/adi/Kconfig | 83 ++ drivers/clk/adi/Makefile | 16 + drivers/clk/adi/clk-adi-pll.c| 94 ++ drivers/clk/adi/clk-adi-sc57x.c | 205 drivers/clk/adi/clk-adi-sc58x.c | 221 + drivers/clk/adi/clk-adi-sc594.c | 230 + drivers/clk/adi/clk-adi-sc598.c | 307 ++ drivers/clk/adi/clk-shared.c | 48 + drivers/clk/adi/clk.h| 122 +++ drivers/serial/Makefile | 1 + drivers/serial/serial_adi_uart4.c| 228 + include/configs/sc_adi_common.h | 226 + include/dt-bindings/clock/adi-sc5xx-clock.h | 271 ++ 43 files changed, 5066 insertions(+) create mode 100644 arch/arm/include/asm/arch-adi/sc5xx/sc5xx.h create mode 100644 arch/arm/include/asm/arch-adi/sc5xx/soc.h create mode 100644 arch/arm/include/asm/arch-adi/sc5xx/spl.h create mode 100644 arch/arm/mach-sc5xx/Kconfig create mode 100644 arch/arm/mach-sc5xx/Makefile create mode 100644 arch/arm/mach-sc5xx/config.mk create mode 100644 arch/arm/mach-sc5xx/init/Makefile create mode 100644 arch/arm/mach-sc5xx/init/clkinit.c create mode 100644 arch/arm/mach-sc5xx/init/clkinit.h create mode 100644 arch/arm/mach-sc5xx/init/dmcinit.c create mode 100644 arch/arm/mach-sc5xx/init/dmcinit.h create mode 100644 arch/arm/mach-sc5xx/init/init.c create mode 100644 arch/arm/mach-sc5xx/init/init.h create mode 100644 arch/arm/mach-sc5xx/init/mem/is43tr16512bl.h create mode 100644 arch/arm/mach-sc5xx/init/mem/mt41k128m16jt.h create mode 100
[PATCH 2/3] drivers: clk: adi: Add in SC5XX-family clock driver
From: Nathan Barrett-Morrison This adds support for the SC5XX clock trees which are required for reading clock speeds on the SoCs. This is largely a port of the same support for Linux, which has not yet been submitted upstream. Co-developed-by: Greg Malysa Signed-off-by: Greg Malysa Co-developed-by: Ian Roberts Signed-off-by: Ian Roberts Signed-off-by: Vasileios Bimpikas Signed-off-by: Utsav Agarwal Signed-off-by: Arturs Artamonovs Signed-off-by: Nathan Barrett-Morrison --- MAINTAINERS | 1 + drivers/clk/Kconfig | 1 + drivers/clk/Makefile| 1 + drivers/clk/adi/Kconfig | 83 ++ drivers/clk/adi/Makefile| 16 + drivers/clk/adi/clk-adi-pll.c | 94 ++ drivers/clk/adi/clk-adi-sc57x.c | 205 + drivers/clk/adi/clk-adi-sc58x.c | 221 ++ drivers/clk/adi/clk-adi-sc594.c | 230 +++ drivers/clk/adi/clk-adi-sc598.c | 307 drivers/clk/adi/clk-shared.c| 48 +++ drivers/clk/adi/clk.h | 122 include/dt-bindings/clock/adi-sc5xx-clock.h | 271 + 13 files changed, 1600 insertions(+) create mode 100644 drivers/clk/adi/Kconfig create mode 100644 drivers/clk/adi/Makefile create mode 100644 drivers/clk/adi/clk-adi-pll.c create mode 100644 drivers/clk/adi/clk-adi-sc57x.c create mode 100644 drivers/clk/adi/clk-adi-sc58x.c create mode 100644 drivers/clk/adi/clk-adi-sc594.c create mode 100644 drivers/clk/adi/clk-adi-sc598.c create mode 100644 drivers/clk/adi/clk-shared.c create mode 100644 drivers/clk/adi/clk.h create mode 100644 include/dt-bindings/clock/adi-sc5xx-clock.h diff --git a/MAINTAINERS b/MAINTAINERS index 9693b86ddd..a9f52a6c7e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -609,6 +609,7 @@ S: Supported T: git https://github.com/analogdevicesinc/lnxdsp-u-boot F: arch/arm/include/asm/arch-adi/ F: arch/arm/mach-sc5xx/ +F: drivers/clk/adi/ F: include/configs/sc_adi_common.h ARM SNAPDRAGON diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 017dd260a5..d8c619add4 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -246,6 +246,7 @@ config CLK_ZYNQMP This clock driver adds support for clock realted settings for ZynqMP platform. +source "drivers/clk/adi/Kconfig" source "drivers/clk/analogbits/Kconfig" source "drivers/clk/at91/Kconfig" source "drivers/clk/exynos/Kconfig" diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index 638ad04bae..847b9b2911 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-fixed-factor.o obj-$(CONFIG_$(SPL_TPL_)CLK_COMPOSITE_CCF) += clk-composite.o obj-$(CONFIG_$(SPL_TPL_)CLK_GPIO) += clk-gpio.o +obj-y += adi/ obj-y += analogbits/ obj-y += imx/ obj-$(CONFIG_CLK_JH7110) += starfive/ diff --git a/drivers/clk/adi/Kconfig b/drivers/clk/adi/Kconfig new file mode 100644 index 00..5745bedf88 --- /dev/null +++ b/drivers/clk/adi/Kconfig @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: GPL-2.0-or-later +# +# (C) Copyright 2022 - Analog Devices, Inc. +# +# Written and/or maintained by Timesys Corporation +# +# Contact: Nathan Barrett-Morrison +# Contact: Greg Malysa +# + +config COMMON_CLK_ADI_SHARED + bool "Enable shared ADI clock framework code" + help + Required for shared code between SoC clock drivers. Automatically + selected by an appropriate SoC-specific clock driver version. + +config COMMON_CLK_ADI_SC598 + bool "Clock driver for ADI SC598 SoCs" + select DM + select CLK + select CLK_CCF + select OF_CONTROL + select CMD_CLK + select SPL_DM if SPL + select SPL_CLK if SPL + select SPL_CLK_CCF if SPL + select SPL_OF_CONTROL if SPL + select COMMON_CLK_ADI_SHARED + depends on SC59X_64 + help + This driver supports the system clocks on Analog Devices SC598-series + SoCs. It includes CGU and CDU clocks and supports gating unused clocks. + Modifying PLL configuration is not supported; that must be done prior + to booting the kernel. Clock dividers after the PLLs may be configured. + +config COMMON_CLK_ADI_SC594 + bool "Clock driver for ADI SC594 SoCs" + select DM + select CLK + select CLK_CCF + select OF_CONTROL + select CMD_CLK + select SPL_DM if SPL + select SPL_CLK if SPL + select SPL_CLK_CCF if SPL + select SPL_OF_CONTROL if SPL + select COMMON_CLK_ADI_SHARED + depends on SC59X + help + This driver supports the system clocks on Analog Devices SC594-series + SoCs. It includes CGU and CDU clocks and supports gating unused clocks. + Modifying PLL configuration is not supported; that
[PATCH 3/3] drivers: serial: Add in UART for ADI SC5XX-family processors
From: Nathan Barrett-Morrison
Co-developed-by: Greg Malysa
Signed-off-by: Greg Malysa
Co-developed-by: Ian Roberts
Signed-off-by: Ian Roberts
Signed-off-by: Vasileios Bimpikas
Signed-off-by: Utsav Agarwal
Signed-off-by: Arturs Artamonovs
Signed-off-by: Nathan Barrett-Morrison
---
MAINTAINERS | 1 +
drivers/serial/Makefile | 1 +
drivers/serial/serial_adi_uart4.c | 228 ++
3 files changed, 230 insertions(+)
create mode 100644 drivers/serial/serial_adi_uart4.c
diff --git a/MAINTAINERS b/MAINTAINERS
index a9f52a6c7e..b1f206bb05 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -610,6 +610,7 @@ T: git https://github.com/analogdevicesinc/lnxdsp-u-boot
F: arch/arm/include/asm/arch-adi/
F: arch/arm/mach-sc5xx/
F: drivers/clk/adi/
+F: drivers/serial/serial_adi_uart4.c
F: include/configs/sc_adi_common.h
ARM SNAPDRAGON
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 403ab1ded6..dbe598b740 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -65,3 +65,4 @@ obj-$(CONFIG_S5P4418_PL011_SERIAL) += serial_s5p4418_pl011.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_USB_TTY) += usbtty.o
endif
+obj-$(CONFIG_UART4_SERIAL) += serial_adi_uart4.o
diff --git a/drivers/serial/serial_adi_uart4.c
b/drivers/serial/serial_adi_uart4.c
new file mode 100644
index 00..b92ce3ddd1
--- /dev/null
+++ b/drivers/serial/serial_adi_uart4.c
@@ -0,0 +1,228 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2022 - Analog Devices, Inc.
+ *
+ * Written and/or maintained by Timesys Corporation
+ *
+ * Converted to driver model by Nathan Barrett-Morrison
+ *
+ * Contact: Nathan Barrett-Morrison
+ * Contact: Greg Malysa
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * UART4 Masks
+ */
+
+/* UART_CONTROL */
+#define UENBIT(0)
+#define LOOP_ENA BIT(1)
+#define UMOD (3 << 4)
+#define UMOD_UART (0 << 4)
+#define UMOD_MDB BIT(4)
+#define UMOD_IRDA BIT(4)
+#define WLS(3 << 8)
+#define WLS_5 (0 << 8)
+#define WLS_6 BIT(8)
+#define WLS_7 (2 << 8)
+#define WLS_8 (3 << 8)
+#define STBBIT(12)
+#define STBH BIT(13)
+#define PENBIT(14)
+#define EPSBIT(15)
+#define STPBIT(16)
+#define FPEBIT(17)
+#define FFEBIT(18)
+#define SB BIT(19)
+#define FCPOL BIT(22)
+#define RPOLC BIT(23)
+#define TPOLC BIT(24)
+#define MRTS BIT(25)
+#define XOFF BIT(26)
+#define ARTS BIT(27)
+#define ACTS BIT(28)
+#define RFIT BIT(29)
+#define RFRT BIT(30)
+
+/* UART_STATUS */
+#define DR BIT(0)
+#define OE BIT(1)
+#define PE BIT(2)
+#define FE BIT(3)
+#define BI BIT(4)
+#define THRE BIT(5)
+#define TEMT BIT(7)
+#define TFIBIT(8)
+#define ASTKY BIT(9)
+#define ADDR BIT(10)
+#define RO BIT(11)
+#define SCTS BIT(12)
+#define CTSBIT(16)
+#define RFCS BIT(17)
+
+/* UART_EMASK */
+#define ERBFI BIT(0)
+#define ETBEI BIT(1)
+#define ELSI BIT(2)
+#define EDSSI BIT(3)
+#define EDTPTI BIT(4)
+#define ETFI BIT(5)
+#define ERFCI BIT(6)
+#define EAWI BIT(7)
+#define ERXS BIT(8)
+#define ETXS BIT(9)
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct uart4_reg {
+ u32 revid;
+ u32 control;
+ u32 status;
+ u32 scr;
+ u32 clock;
+ u32 emask;
+ u32 emaskst;
+ u32 emaskcl;
+ u32 rbr;
+ u32 thr;
+ u32 taip;
+ u32 tsr;
+ u32 rsr;
+ u32 txdiv_cnt;
+ u32 rxdiv_cnt;
+};
+
+struct adi_uart4_platdata {
+ // Hardware registers
+ struct uart4_reg *regs;
+
+ // Enable divide-by-one baud rate setting
+ bool edbo;
+};
+
+static int adi_uart4_set_brg(struct udevice *dev, int baudrate)
+{
+ struct adi_uart4_platdata *plat = dev_get_plat(dev);
+ struct uart4_reg *regs = plat->regs;
+ u32 divisor, uart_base_clk_rate;
+ struct clk uart_base_clk;
+
+ if (clk_get_by_index(dev, 0, &uart_base_clk)) {
+ printf("%s: Could not get UART base clock\n", dev->name);
+ return -1;
+ }
+
+ uart_base_clk_rate = clk_get_r
Re: [PATCH v2 0/2] sunxi, usb: UDC/DM gadget model support
On Thu, Apr 11, 2024 at 03:53:51PM -0600, Sam Edwards wrote: > Hi John, Hi Sam, > Ahh I see the problem. In U-Boot, `ubi` isn't actually a block device: > it's implemented as a stub in the block layer, and the filesystem > layer redirects `ubi` accesses to the currently-mounted ubifs instead. > But the `ums` command works on the block layer, so it's not being > intercepted, and instead hitting that stub and likely crashing. In the > spirit of the Linux ubiblock driver, I have another patchset[1] I've > been working on[2] to expose static ubivols as true read-only block > devices. Note that this only works for static volumes: the access > semantics of dynamic volumes are too flash-like to support block > device access, so accessing them with `ums` likely will never work > like users expect. I'll give a patchset a test when I can. > Still, there could be some interaction issue between `ums`<->USB that > I haven't identified. Could you try with mmc (if available) or a > ramdisk (otherwise) just to confirm that `ums` is fine? I'll try testing with those if possible. I did find out that fastboot actually works, and is much, much faster than DFU for some reason. John. > > Regards, > Sam > > [1] > https://lore.kernel.org/u-boot/20230812000606.72319-1-cfswo...@gmail.com/T/ > [2] Not very diligently; if you're interested in helping test it, I'd > love to get back to it.
Re: [PATCH RFC 00/15] Support SPI NAND booting on the T113
On Wed, Apr 10, 2024 at 10:26 PM John Watts wrote:
>
> This series is my current working and tested setup for booting from
> SPI NAND chips on the Allwinner T113.
>
> I have included the following patches from others. I may have modified
> them to work with the latest mainline:
>
> https://lore.kernel.org/all/20221014030520.3067228-1-...@icenowy.me/
> https://lore.kernel.org/all/2023133432.755363-2-biguncle...@gmail.com/
>
> Hopefully this can get the ball rolling on how to properly implement
> SPI NAND support in mainline U-Boot.
>
> Signed-off-by: John Watts
Hi John,
It doesn't look like I was sent the whole series (only 00 and 01), but
I was able to find it on Patchwork and sift through it. A few general
comments follow:
The introduction of `SUNXI_BOOTED_FROM_SPINAND` is the right call,
since the newer sunxis use this for SPI-NAND, and
`SUNXI_BOOTED_FROM_SPI` for SPI-NOR. The older sunxis, however, will
use `SUNXI_BOOTED_FROM_SPI` for "it's either SPI-NAND or SPI-NOR, have
fun figuring out which." While the rationale in 09/15 ("Instead of
trying to boot from SPI NAND then SPI NOR in series, select one based
on the current boot device.") is solid, we still need some code
(perhaps in/called from `sunxi_get_boot_device`?) to handle the
`SUNXI_BOOTED_FROM_SPI` case by performing flash type detection --
disabled for those sunxis known to use `SUNXI_BOOTED_FROM_SPINAND`, of
course.
06/15 ("sunxi: enable support for SPI NAND booting on SUNIV") should
be dropped from the series. You are updating `suniv_get_boot_source`
when introducing `SUNXI_BOOTED_FROM_SPINAND` anyway, so you can just
hook up `SUNIV_BOOTED_FROM_NAND` at that time (and a heads-up: I think
you got it wired backwards in this version of the series).
On a more fundamental note: I am hesitant about the overall approach
of having NAND reading code in `arch/arm/mach-sunxi/spl_spi_sunxi.c`.
NANDs are more complex than NORs (requiring e.g. bad block handling)
and U-Boot generally keeps the SPL load methods in
`common/spl/spl_*.c`. It's good that the UBI-on-SPI-NAND method is
hooked up there, but the "U-Boot image follows the (good) blocks of
the SPL in NAND" method should probably live in the same directory.
Here's what I'd like to explore: can we introduce a
`common/spl/spl_spinand.c` and update the `drivers/mtd/nand/spi/*.c`
code to support running in SPL? This way
`arch/arm/mach-sunxi/spl_spi_sunxi.c` must only provide the SPL-mode
implementation of SPI -- that is, the actual sunxi-specific bit. Also,
updating the `drivers/mtd/nand/spi/*.c` drivers for SPL-friendliness
will mean dropping those `SPL_SPINAND_{PAGE,BLOCK}_SIZE` configuration
options: the tables in the drivers will be the ones providing those
after NAND autodetection.
Thoughts?
Cheers,
Sam
> ---
> Icenowy Zheng (5):
> sunxi: SPL SPI: extract code for doing SPI transfer
> sunxi: SPL SPI: add support for read command with 2 byte address
> sunxi: SPL SPI: allow multiple boot attempt
> sunxi: SPL SPI: add initial support for booting from SPI NAND
> sunxi: enable support for SPI NAND booting on SUNIV
>
> John Watts (9):
> sunxi: Separate boot device and boot position
> spl: Add BOOT_DEVICE_SPINAND option
> sunxi: Implement BOOT_DEVICE_SPINAND in SPL
> spl: Add SPL_SPINAND configuration options
> sunxi: Use SPL_SPINAND for configuration
> nand: Add spinand_ helper functions
> sunxi: Implement spinand_ helpers
> spl: Support SPI NAND boot in UBI
> spl: Support loading FIT images in UBI
>
> Maksim Kiselev (1):
> sunxi: SPL SPI: Add SPI boot support for the Allwinner R528/T113 SoCs
>
> arch/arm/include/asm/arch-sunxi/spl.h | 3 +-
> arch/arm/include/asm/spl.h| 1 +
> arch/arm/mach-sunxi/Kconfig | 2 +-
> arch/arm/mach-sunxi/board.c | 31 +--
> arch/arm/mach-sunxi/spl_spi_sunxi.c | 348
> +-
> arch/mips/include/asm/spl.h | 1 +
> arch/riscv/include/asm/spl.h | 1 +
> arch/sandbox/include/asm/spl.h| 1 +
> common/spl/Kconfig| 21 ++
> common/spl/spl_ubi.c | 49 -
> include/nand.h| 3 +
> 11 files changed, 354 insertions(+), 107 deletions(-)
> ---
> base-commit: 777c28460947371ada40868dc994dfe8537d7115
> change-id: 20240411-spinand-eb7d8319813b
>
> Best regards,
> --
> John Watts
>
[PATCH 00/11] cadence-qspi: Add DTR support including PHY mode calibration
This series introduces support for DTR mode for the Cadence QSPI/OSPI IP. We have been developing it against the SC594/SC598 from ADI, so there are some limitations specific to our hardware's capabilities. Ideally this series could be enhanced with features introduced in a patch series submitted by AMD, but currently no work has been done to reconcile the two. So this is somewhere between an RFC patch and a patch series we wish to submit as-is for inclusion. Beyond the specific support for the QSPI peripheral, this series also introduces a more general calibration framework as part of the spi system in order to facilitate integration of calibration support for other controllers within a consistent approach. Ian Roberts (11): mtd: spi-nor: Add calibration hook for high speed SPI mtd: spi-nor: Octal DTR support for IS25*x spi: cadence-quadspi: Enable DDR bit for DTR commands spi: cadence-quadspi: enable opcode extension based on command length spi: cadence-quadspi: disable automatic write enable spi: cadence-quadspi: unconditionally disable auto status register reads spi: cadence-quadspi: Remove redundant DTR state spi: cadence-quadspi: Direct mode does not support zero length addresses spi: cadence-quadspi: Add support for memory DMA channel transfers spi: cadence-quadspi: Add DT control of max Read Delay Capture value spi: cadence-quadspi: Implement high speed calibration doc/device-tree-bindings/spi/spi-bus.txt | 4 + doc/device-tree-bindings/spi/spi-cadence.txt | 11 + drivers/mtd/spi/Kconfig | 12 + drivers/mtd/spi/spi-nor-core.c | 246 drivers/mtd/spi/spi-nor-ids.c| 6 +- drivers/spi/cadence_qspi.c | 444 ++ drivers/spi/cadence_qspi.h | 105 +++- drivers/spi/cadence_qspi_apb.c | 572 +++ drivers/spi/spi-mem.c| 24 + include/linux/mtd/spi-nor.h | 13 + include/spi-mem.h| 19 + 11 files changed, 1226 insertions(+), 230 deletions(-) -- 2.43.2
[PATCH 11/11] spi: cadence-quadspi: Implement high speed calibration
From: Ian Roberts
Implement the spi-mem calibration hook for high speed flash operation for
use on the SC59x SOCs. The Cadence controller IP has support for the DQS
signal and a PHY mode that facilitates speeds greater than 50MHz.
At high speeds, the IO lines must be calibrated for signal propagation
delay. This calibration is intended to be executed in the final IO
configuration mode. That is, if 8-lane DDR IO operation is the use case,
calibration must occur while that mode is enabled. For example, there
might be excess noise on a single IO lane while operating in 8-lane mode
that then limits the speed of the entire bus. SPI bus drivers are not
involved in the control of the SPI flash chip operating mode, and
performing the switch is done by the SPI-nor subsystem. To add to this
complexity, different IO modes use different command sets, and different
flash chips may also modify this command set further. Thus, we must lean
on the spi-nor subsystem through the spi-mem calibration function for the
most portable implementation of calibration.
The original calibration code in this driver only calibrates the Read
Delay Capture value, over a single lane, over only 3 bytes in the readid
command. This produces unreliable calibrations in single IO mode and is
unusable in DDR or multi-IO modes.
The prior calibration implementation is replaced in favor of the new
approach when CONFIG_SPI_FLASH_HS_CALIB is defined. The old
implementation is still available when not defined. However, the previous
implementation has been tweaked to take advantage of code reuse and to
fix an invalid SPI chip select read from the dm_spi_ops set_speed
callback. It would always return the same invalid CS number, never
triggering a recalibration if the chip changes. However, this driver was
not implemented with support for multiple chips on the bus in mind
anyway. For example:
* of_to_plat only scans the first subnode for flash-specific
configuration, and thus only a single copy of this info is declared in
the plat and priv structs.
* Defining cdns,read-delay overrides any automatic recalibration that
would normally occur from a chip select change to this single value.
A few additional comments, checks, and renames have been made to make
this more clear. The new calibration implementation explicitly disallows
changing the chip after calibration until it is properly implemented in
the driver. The legacy implementation will still allow the chip to change
but now correctly trigger a recalibration after the chip select changes.
The issue with cdns,read-delay and multi-IO modes is only fixed in the
new implementation.
Co-developed-by: Nathan Barrett-Morrison
Signed-off-by: Nathan Barrett-Morrison
Signed-off-by: Greg Malysa
Signed-off-by: Ian Roberts
---
doc/device-tree-bindings/spi/spi-cadence.txt | 9 +
drivers/spi/cadence_qspi.c | 392 +--
drivers/spi/cadence_qspi.h | 77 ++--
drivers/spi/cadence_qspi_apb.c | 327 ++--
4 files changed, 641 insertions(+), 164 deletions(-)
diff --git a/doc/device-tree-bindings/spi/spi-cadence.txt
b/doc/device-tree-bindings/spi/spi-cadence.txt
index 9bd7ef8bed..4ee0b628e3 100644
--- a/doc/device-tree-bindings/spi/spi-cadence.txt
+++ b/doc/device-tree-bindings/spi/spi-cadence.txt
@@ -31,3 +31,12 @@ connected flash properties
n_ss_out low and first bit transfer
- cdns,max-read-delay : Max safe value to use for the read capture delay
during auto calibration.
+- cdns,spi-calib-frequency : Max safe SPI clock frequency to use before bus
+calibration is performed.
+- cdns,dqs : Enable use of the DQS signal with the flash chip.
+- cdns,phy : Enable use of the high-speed PHY feature with the
+ flash chip. Generally required for speeds higher
+ than 50MHz.
+- cdns,read-delay : Optional pre-calibrated Read Delay Capture value.
+- cdns,phyrxdly: Optional pre-calibrated PHY RX Delay value.
+- cdns,phytxdly: Optional pre-calibrated PHY TX Delay value.
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 3778a469d4..1db3167a5b 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -30,6 +31,20 @@
#define CQSPI_READ 2
#define CQSPI_WRITE3
+static bool is_calibrated(struct cadence_spi_priv *priv,
+ struct spi_slave *slave)
+{
+ return (priv->qspi_calibrated_hz == priv->req_hz) &&
+ (priv->qspi_calibrated_cs == spi_chip_select(slave->dev));
+}
+
+static void set_calibrated(struct cadence_spi_priv *priv,
+ struct spi_slave *slave)
+{
+ priv->qspi_calibrated_hz = priv->req_hz;
+ priv->qspi_ca
[PATCH 07/11] spi: cadence-quadspi: Remove redundant DTR state
From: Ian Roberts
cadence_spi_mem_supports_op() already checks that every memory operation
either has all DTR booleans set or cleared. Thus, there is no need to
store a cached dtr value. The command DTR state can be used since it is
not optional like the other fields.
Co-developed-by: Nathan Barrett-Morrison
Signed-off-by: Nathan Barrett-Morrison
Signed-off-by: Greg Malysa
Signed-off-by: Ian Roberts
---
drivers/spi/cadence_qspi.c | 6 ++
drivers/spi/cadence_qspi.h | 1 -
drivers/spi/cadence_qspi_apb.c | 27 ---
3 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index f4593c47b8..a2644d9e11 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -362,6 +362,12 @@ static bool cadence_spi_mem_supports_op(struct spi_slave
*slave,
bool all_true, all_false;
/*
+* For an op to be DTR, cmd phase along with every other non-empty
+* phase should have dtr field set to 1. If an op phase has zero
+* nbytes, ignore its dtr field; otherwise, check its dtr field.
+* Also, dummy checks not performed here Since supports_op()
+* already checks that all or none of the fields are DTR.
+*
* op->dummy.dtr is required for converting nbytes into ncycles.
* Also, don't check the dtr field of the op phase having zero nbytes.
*/
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 355919cb23..5704f5a3f6 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -265,7 +265,6 @@ struct cadence_spi_priv {
u8 inst_width;
u8 addr_width;
u8 data_width;
- booldtr;
};
/* Functions call declaration */
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index d347cb8d47..2600370f85 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -120,17 +120,6 @@ static int cadence_qspi_set_protocol(struct
cadence_spi_priv *priv,
{
int ret;
- /*
-* For an op to be DTR, cmd phase along with every other non-empty
-* phase should have dtr field set to 1. If an op phase has zero
-* nbytes, ignore its dtr field; otherwise, check its dtr field.
-* Also, dummy checks not performed here Since supports_op()
-* already checks that all or none of the fields are DTR.
-*/
- priv->dtr = op->cmd.dtr &&
- (!op->addr.nbytes || op->addr.dtr) &&
- (!op->data.nbytes || op->data.dtr);
-
ret = cadence_qspi_buswidth_to_inst_type(op->cmd.buswidth);
if (ret < 0)
return ret;
@@ -449,7 +438,7 @@ int cadence_qspi_apb_command_read_setup(struct
cadence_spi_priv *priv,
return ret;
ret = cadence_qspi_enable_dtr(priv, op, CQSPI_REG_OP_EXT_STIG_LSB,
- priv->dtr);
+ op->cmd.dtr);
if (ret)
return ret;
@@ -484,13 +473,13 @@ int cadence_qspi_apb_command_read(struct cadence_spi_priv
*priv,
return log_msg_ret("QSPI: Invalid command length", -EINVAL);
}
- if (opcode == CMD_4BYTE_OCTAL_READ && !priv->dtr)
+ if (opcode == CMD_4BYTE_OCTAL_READ && !op->cmd.dtr)
opcode = CMD_4BYTE_FAST_READ;
reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB;
/* Set up dummy cycles. */
- dummy_clk = cadence_qspi_calc_dummy(op, priv->dtr);
+ dummy_clk = cadence_qspi_calc_dummy(op, op->cmd.dtr);
if (dummy_clk > CQSPI_DUMMY_CLKS_MAX)
return -ENOTSUPP;
@@ -547,7 +536,7 @@ int cadence_qspi_apb_command_write_setup(struct
cadence_spi_priv *priv,
return ret;
ret = cadence_qspi_enable_dtr(priv, op, CQSPI_REG_OP_EXT_STIG_LSB,
- priv->dtr);
+ op->cmd.dtr);
if (ret)
return ret;
@@ -597,7 +586,7 @@ int cadence_qspi_apb_command_write(struct cadence_spi_priv
*priv,
}
/* Set up dummy cycles. */
- dummy_clk = cadence_qspi_calc_dummy(op, priv->dtr);
+ dummy_clk = cadence_qspi_calc_dummy(op, op->cmd.dtr);
if (dummy_clk > CQSPI_DUMMY_CLKS_MAX)
return -EOPNOTSUPP;
@@ -645,7 +634,7 @@ int cadence_qspi_apb_read_setup(struct cadence_spi_priv
*priv,
return ret;
ret = cadence_qspi_enable_dtr(priv, op, CQSPI_REG_OP_EXT_READ_LSB,
- priv->dtr);
+ op->cmd.dtr);
if (ret)
return ret;
@@ -673,7 +662,7 @@ int cadence_qspi_apb_read_setup(struct cadence_spi_priv
*priv,
if (dummy_bytes) {
/* Convert to clock cycles. */
- dummy_clk = cadence_qs
[PATCH 10/11] spi: cadence-quadspi: Add DT control of max Read Delay Capture value
From: Ian Roberts
On some SOCs (eg sc59x), attempting to use too high of a Read
Delay Capture value can cause the controller DMA to lock up. Thus,
add a device tree configuration property to allow controlling
the max Read Delay Capture value.
Co-developed-by: Nathan Barrett-Morrison
Signed-off-by: Nathan Barrett-Morrison
Signed-off-by: Greg Malysa
Signed-off-by: Ian Roberts
---
doc/device-tree-bindings/spi/spi-cadence.txt | 2 ++
drivers/spi/cadence_qspi.c | 9 -
drivers/spi/cadence_qspi.h | 2 ++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/doc/device-tree-bindings/spi/spi-cadence.txt
b/doc/device-tree-bindings/spi/spi-cadence.txt
index 69e02c1c4b..9bd7ef8bed 100644
--- a/doc/device-tree-bindings/spi/spi-cadence.txt
+++ b/doc/device-tree-bindings/spi/spi-cadence.txt
@@ -29,3 +29,5 @@ connected flash properties
select (n_ss_out).
- cdns,tslch-ns: Delay in master reference clocks between
setting
n_ss_out low and first bit transfer
+- cdns,max-read-delay : Max safe value to use for the read capture delay
+ during auto calibration.
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index a5e921cae7..3778a469d4 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -104,7 +104,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
/* use back the intended clock and find low range */
cadence_spi_write_speed(bus, hz);
- for (i = 0; i < CQSPI_READ_CAPTURE_MAX_DELAY; i++) {
+ for (i = 0; i < priv->max_read_delay; i++) {
/* Disable QSPI */
cadence_qspi_apb_controller_disable(base);
@@ -246,6 +246,7 @@ static int cadence_spi_probe(struct udevice *bus)
priv->fifo_depth= plat->fifo_depth;
priv->fifo_width= plat->fifo_width;
priv->trigger_address = plat->trigger_address;
+ priv->max_read_delay= plat->max_read_delay;
priv->read_delay= plat->read_delay;
priv->ahbsize = plat->ahbsize;
priv->max_hz= plat->max_hz;
@@ -456,6 +457,10 @@ static int cadence_spi_of_to_plat(struct udevice *bus)
plat->is_dma = dev_read_bool(bus, "cdns,is-dma");
+ plat->max_read_delay = dev_read_u32_default(bus,
+ "cdns,max-read-delay",
+
CQSPI_READ_CAPTURE_MAX_DELAY);
+
/* All other parameters are embedded in the child node */
subnode = cadence_qspi_get_subnode(bus);
if (!ofnode_valid(subnode)) {
@@ -484,6 +489,8 @@ static int cadence_spi_of_to_plat(struct udevice *bus)
*/
plat->read_delay = ofnode_read_s32_default(subnode, "cdns,read-delay",
-1);
+ if (plat->read_delay > plat->max_read_delay)
+ plat->read_delay = plat->max_read_delay;
debug("%s: regbase=%p ahbbase=%p max-frequency=%d page-size=%d\n",
__func__, plat->regbase, plat->ahbbase, plat->max_hz,
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 9c15d3c6df..d7a02f0870 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -214,6 +214,7 @@ struct cadence_spi_plat {
fdt_addr_t ahbsize;
booluse_dac_mode;
int read_delay;
+ int max_read_delay;
/* Flash parameters */
u32 page_size;
@@ -260,6 +261,7 @@ struct cadence_spi_priv {
unsigned intprevious_hz;
u32 wr_delay;
int read_delay;
+ int max_read_delay;
struct reset_ctl_bulk *resets;
u32 page_size;
--
2.43.2
[PATCH 09/11] spi: cadence-quadspi: Add support for memory DMA channel transfers
From: Ian Roberts
On the SC59x platform, the Cadence SPI IP block can use memory DMA
channels to execute transactions. Existing Cadence DMA support attempts
appears to be SOC specific and not generic. Thus, framework to use the
DMA subsystem was added. On the SC59x, DMA to the Cadence SPI block is
connected via memory DMA instead of peripheral DMA. In addition, some
of the memory DMA channels are recommended over others for better
transaction performance. This initial implementation simply uses the
recommended memory channel indicated from the device tree. Peripheral
DMA support can be added later for platforms that need it.
Co-developed-by: Nathan Barrett-Morrison
Signed-off-by: Nathan Barrett-Morrison
Signed-off-by: Greg Malysa
Signed-off-by: Ian Roberts
---
drivers/spi/cadence_qspi.c | 47
drivers/spi/cadence_qspi.h | 31 +--
drivers/spi/cadence_qspi_apb.c | 99 ++
3 files changed, 164 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index a2644d9e11..a5e921cae7 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -7,6 +7,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -194,6 +196,42 @@ static int cadence_spi_set_speed(struct udevice *bus, uint
hz)
return 0;
}
+#if CONFIG_IS_ENABLED(DMA_CHANNELS)
+static int cadence_spi_probe_dma(struct udevice *bus)
+{
+ struct cadence_spi_priv *priv = dev_get_priv(bus);
+ struct dma_dev_priv *dma_uc;
+ int hasdma;
+ int ret;
+
+ hasdma = (ofnode_read_u32(dev_ofnode(bus), "dmas", NULL) == 0) &&
+(ofnode_read_u32(dev_ofnode(bus), "dma-names", NULL) == 0);
+ if (!hasdma)
+ return 0;
+
+ ret = dma_get_by_name(bus, "dst", &priv->dstdma);
+ if (ret != 0)
+ return 0;
+
+ dma_uc = dev_get_uclass_priv(priv->dstdma.dev);
+
+ if (dma_uc->supported == DMA_SUPPORTS_MEM_TO_MEM) {
+ /* We were given a specific DMA channel that only
+* supports mem-to-mem transactions.
+*/
+ priv->hasdma = hasdma;
+ priv->ops.direct_read_copy = cadence_qspi_apb_read_copy_mdma;
+ priv->ops.direct_write_copy = cadence_qspi_apb_write_copy_mdma;
+ return 0;
+ }
+
+ /* Todo: Implement device DMA channel modes when needed
+* (DMA_SUPPORTS_MEM_TO_DEV, DMA_SUPPORTS_DEV_TO_MEM).
+*/
+ return -ENOSYS;
+}
+#endif
+
static int cadence_spi_probe(struct udevice *bus)
{
struct cadence_spi_plat *plat = dev_get_plat(bus);
@@ -219,6 +257,9 @@ static int cadence_spi_probe(struct udevice *bus)
priv->tchsh_ns = plat->tchsh_ns;
priv->tslch_ns = plat->tslch_ns;
+ priv->ops.direct_read_copy = cadence_qspi_apb_direct_read_copy;
+ priv->ops.direct_write_copy = cadence_qspi_apb_direct_write_copy;
+
if (IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE))
xilinx_pm_request(PM_REQUEST_NODE, PM_DEV_OSPI,
ZYNQMP_PM_CAPABILITY_ACCESS,
ZYNQMP_PM_MAX_QOS,
@@ -252,6 +293,12 @@ static int cadence_spi_probe(struct udevice *bus)
priv->wr_delay = 50 * DIV_ROUND_UP(NSEC_PER_SEC, priv->ref_clk_hz);
+ if (CONFIG_IS_ENABLED(DMA_CHANNELS)) {
+ ret = cadence_spi_probe_dma(bus);
+ if (ret)
+ return ret;
+ }
+
/* Versal and Versal-NET use spi calibration to set read delay */
if (CONFIG_IS_ENABLED(ARCH_VERSAL) ||
CONFIG_IS_ENABLED(ARCH_VERSAL_NET))
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 5704f5a3f6..9c15d3c6df 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -223,7 +223,16 @@ struct cadence_spi_plat {
u32 tchsh_ns;
u32 tslch_ns;
- boolis_dma;
+ boolis_dma;
+};
+
+struct cadence_spi_priv;
+
+struct cadence_drv_ops {
+ int (*direct_read_copy)(struct cadence_spi_priv *priv,
+ void *dst, u64 src, size_t len);
+ int (*direct_write_copy)(struct cadence_spi_priv *priv,
+const void *src, u64 dst, size_t len);
};
struct cadence_spi_priv {
@@ -234,11 +243,17 @@ struct cadence_spi_priv {
unsigned intfifo_depth;
unsigned intfifo_width;
unsigned inttrigger_address;
- fdt_addr_t ahbsize;
+ fdt_addr_t ahbsize;
size_t cmd_len;
u8 cmd_buf[32];
size_t data_len;
+ boolhasdma;
+#if CONFIG_IS_ENABLED(DMA_CHANNELS)
+ struct dma dstdma;
+#endif
+ struct cadence_drv_ops ops;
+
int qspi_is_init;
unsigned intqspi_calibrated_hz;
unsign
[PATCH 08/11] spi: cadence-quadspi: Direct mode does not support zero length addresses
From: Ian Roberts
It is not possible to configure the Cadence SPI IP block to use a zero
length address in DMA read or write commands.
Co-developed-by: Nathan Barrett-Morrison
Signed-off-by: Nathan Barrett-Morrison
Signed-off-by: Greg Malysa
Signed-off-by: Ian Roberts
---
drivers/spi/cadence_qspi_apb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 2600370f85..340889c271 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -784,7 +784,7 @@ int cadence_qspi_apb_read_execute(struct cadence_spi_priv
*priv,
cadence_qspi_apb_enable_linear_mode(true);
- if (priv->use_dac_mode && (from + len < priv->ahbsize)) {
+ if (op->addr.nbytes && priv->use_dac_mode && (from + len <
priv->ahbsize)) {
if (len < 256 ||
dma_memcpy(buf, priv->ahbbase + from, len) < 0) {
memcpy_fromio(buf, priv->ahbbase + from, len);
@@ -970,7 +970,7 @@ int cadence_qspi_apb_write_execute(struct cadence_spi_priv
*priv,
size_t len = op->data.nbytes;
cadence_qspi_apb_enable_linear_mode(true);
- if (priv->use_dac_mode && (to + len < priv->ahbsize)) {
+ if (op->addr.nbytes && priv->use_dac_mode && (to + len <
priv->ahbsize)) {
memcpy_toio(priv->ahbbase + to, buf, len);
if (!cadence_qspi_wait_idle(priv->regbase))
return -EIO;
--
2.43.2
[PATCH 06/11] spi: cadence-quadspi: unconditionally disable auto status register reads
From: Ian Roberts
In addition to the given reason for the conditional disable
of this feature for DTR:
Theoretically, some flashes have their WIP bit in different
bit positions or have a different bit polarity. spi-nor
currently does not have an interface in place to dictate
this information to this driver for proper configuration.
The default of the controller hardware has this status register
auto polling without expiration. This means that if there is any
controller misconfiguration or communication failure, it will
completely lock up the controller.
Thus, unconditionally disable this feature for now.
Co-developed-by: Nathan Barrett-Morrison
Signed-off-by: Nathan Barrett-Morrison
Signed-off-by: Greg Malysa
Signed-off-by: Ian Roberts
---
drivers/spi/cadence_qspi_apb.c | 46 ++
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 176cff5338..d347cb8d47 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -853,19 +853,29 @@ int cadence_qspi_apb_write_setup(struct cadence_spi_priv
*priv,
writel(op->addr.val, priv->regbase + CQSPI_REG_INDIRECTWRSTARTADDR);
- if (priv->dtr) {
- /*
-* Some flashes like the cypress Semper flash expect a 4-byte
-* dummy address with the Read SR command in DTR mode, but this
-* controller does not support sending address with the Read SR
-* command. So, disable write completion polling on the
-* controller's side. spi-nor will take care of polling the
-* status register.
-*/
- reg = readl(priv->regbase + CQSPI_REG_WR_COMPLETION_CTRL);
- reg |= CQSPI_REG_WR_DISABLE_AUTO_POLL;
- writel(reg, priv->regbase + CQSPI_REG_WR_COMPLETION_CTRL);
- }
+ /*
+* Some flashes like the cypress Semper flash expect a 4-byte
+* dummy address with the Read SR command in DTR mode, but this
+* controller does not support sending address with the Read SR
+* command. So, disable write completion polling on the
+* controller's side. spi-nor will take care of polling the
+* status register.
+*
+* Theoretically, some flashes have their WIP bit in different
+* bit positions or have a different bit polarity. spi-nor
+* currently does not have an interface in place to dictate
+* this information to this driver for proper configuration.
+*
+* The default of the controller hardware has this status register
+* auto polling without expiration. This means that if there is any
+* controller misconfiguration or communication failure, it will
+* completely lock up the controller.
+*
+* Thus, unconditionally disable this feature for now.
+*/
+ reg = readl(priv->regbase + CQSPI_REG_WR_COMPLETION_CTRL);
+ reg |= CQSPI_REG_WR_DISABLE_AUTO_POLL;
+ writel(reg, priv->regbase + CQSPI_REG_WR_COMPLETION_CTRL);
reg = readl(priv->regbase + CQSPI_REG_SIZE);
reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
@@ -970,16 +980,8 @@ int cadence_qspi_apb_write_execute(struct cadence_spi_priv
*priv,
const void *buf = op->data.buf.out;
size_t len = op->data.nbytes;
- /*
-* Some flashes like the Cypress Semper flash expect a dummy 4-byte
-* address (all 0s) with the read status register command in DTR mode.
-* But this controller does not support sending dummy address bytes to
-* the flash when it is polling the write completion register in DTR
-* mode. So, we can not use direct mode when in DTR mode for writing
-* data.
-*/
cadence_qspi_apb_enable_linear_mode(true);
- if (!priv->dtr && priv->use_dac_mode && (to + len < priv->ahbsize)) {
+ if (priv->use_dac_mode && (to + len < priv->ahbsize)) {
memcpy_toio(priv->ahbbase + to, buf, len);
if (!cadence_qspi_wait_idle(priv->regbase))
return -EIO;
--
2.43.2
[PATCH 01/11] mtd: spi-nor: Add calibration hook for high speed SPI
From: Ian Roberts High speed SPI flash chip operation, such as speeds greater than 50MHz, require a calibration of the data lines to determine the correct signal propagation delay. This calibration delay will vary based on flash chip, operating frequency, board trace length, and board temperature to a smaller extent. To my knowledge, JEDEC doesn't have a well defined standard for how calibration should be implemented by flash chip manufacturers. The few flash chip datasheets I have viewed from chips that do support such high speed operation implement very different methods for assisting in calibration, such as: * No provision for calibration. * Independent "data learning" commands. * Scratch data registers. * Predefined bit patterns inserted before read data contents (preamble). Thus, the simplest and most portable solution to calibrate appears to be to simply read and compare a known data pattern from the flash array. During SPI flash probe, calibration is initialized after the SFDP read, but before read command selection. At this stage, higher speeds, more advanced read commands, and additional IO lanes, and dual data rate options have not yet been enabled. Communication is most reliable at this stage to read out a pattern to then check against later. The most basic and widely supported read commands are then used to read out the data pattern. The default is to read 2 flash pages worth of data at the first address in flash. Commonly, this is where a bootloader might be located on the chip. While a bootloader is not an ideal pattern, two pages worth of data hopefully contains enough entropy to calibrate successfully. This can be further customized with two new flash chip device tree parameters: * 'calibration-offset' The flash chip address offset where the pattern data is located. * 'calibration-length' The length of pattern data. The calibration step is then called at the end of the chip probe, right after all advanced IO modes have been enabled, such as multiple IO lanes and SDR/DDR modes. Another solution to the high speed calibration issue is to perform the calibration offline and then to simply apply the calibration at boot. This skips a potentially lengthy calibration process. However, this change set also serves as an ideal hook for controller drivers to also simply apply any pre-calibrated values. Early commands in the probe process, such as RDID, RDSFDP, and RDAY may have slower operating frequencies. As, for example, the JEDEC spec only requires that RDSFDP and RDAY to support at least up to 50MHz frequency. Thus it is ideal to probe the chip at lower frequencies with more reliable IO modes, such as a low frequency with one lane at a single data rate. This patch implements: * SPI-mem API function for drivers to implement to perform calibration. * Read pattern data through reliable methods. * Call SPI-mem API calibration function with a read check function that uses probed read commands and all enabled fast IO modes. Co-developed-by: Nathan Barrett-Morrison Signed-off-by: Nathan Barrett-Morrison Signed-off-by: Greg Malysa Signed-off-by: Ian Roberts --- --- doc/device-tree-bindings/spi/spi-bus.txt | 4 + drivers/mtd/spi/Kconfig | 12 ++ drivers/mtd/spi/spi-nor-core.c | 168 +++ drivers/spi/spi-mem.c| 24 include/linux/mtd/spi-nor.h | 7 + include/spi-mem.h| 19 +++ 6 files changed, 234 insertions(+) diff --git a/doc/device-tree-bindings/spi/spi-bus.txt b/doc/device-tree-bindings/spi/spi-bus.txt index e57897ac0c..654d388cac 100644 --- a/doc/device-tree-bindings/spi/spi-bus.txt +++ b/doc/device-tree-bindings/spi/spi-bus.txt @@ -61,6 +61,10 @@ contain the following properties. used for MISO. Defaults to 1 if not present. - spi-half-duplex - (optional) Indicates that the SPI bus should wait for a header byte before reading data from the slave. +- calibration-offset - (optional) Check pattern offset location for high- + speed calibration. +- calibration-length - (optional) Check pattern length for high-speed + calibration. Some SPI controllers and devices support Dual and Quad SPI transfer mode. It allows data in SPI system transferred in 2 wires(DUAL) or 4 wires(QUAD). diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index d068b7860e..ed0335d9ba 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -127,6 +127,18 @@ config SPI_FLASH_SOFT_RESET_ON_BOOT that are not supposed to be handed to U-Boot in Octal DTR mode, even if they _do_ support the Soft Reset sequence. +config SPI_FLASH_HS_CALIB + bool "Support for high-speed SPI flash calibration" + default n + help +Modern flash chips and controllers that operate at speeds higher than +50MHz require delays in the signal lines t
[PATCH 04/11] spi: cadence-quadspi: enable opcode extension based on command length
From: Ian Roberts
Some flash chips use dual opcodes in other modes. For example, the
Macronix MX66 requires dual opcodes for STR octal operation. Thus,
enable opcode extension based on the length of the command instead
of the DTR mode of the controller.
Co-developed-by: Nathan Barrett-Morrison
Signed-off-by: Nathan Barrett-Morrison
Signed-off-by: Greg Malysa
Signed-off-by: Ian Roberts
---
drivers/spi/cadence_qspi_apb.c | 66 +-
1 file changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 34cacf1880..eb9f4ed63d 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -412,19 +412,27 @@ static int cadence_qspi_enable_dtr(struct
cadence_spi_priv *priv,
reg = readl(priv->regbase + CQSPI_REG_CONFIG);
- if (enable) {
- reg |= CQSPI_REG_CONFIG_DTR_PROTO;
+ switch (op->cmd.nbytes) {
+ case 1:
+ reg &= ~CQSPI_REG_CONFIG_DUAL_OPCODE;
+ break;
+ case 2:
reg |= CQSPI_REG_CONFIG_DUAL_OPCODE;
/* Set up command opcode extension. */
ret = cadence_qspi_setup_opcode_ext(priv, op, shift);
if (ret)
return ret;
- } else {
- reg &= ~CQSPI_REG_CONFIG_DTR_PROTO;
- reg &= ~CQSPI_REG_CONFIG_DUAL_OPCODE;
+ break;
+ default:
+ return log_msg_ret("QSPI: Invalid command length", -EINVAL);
}
+ if (enable)
+ reg |= CQSPI_REG_CONFIG_DTR_PROTO;
+ else
+ reg &= ~CQSPI_REG_CONFIG_DTR_PROTO;
+
writel(reg, priv->regbase + CQSPI_REG_CONFIG);
return 0;
@@ -465,10 +473,16 @@ int cadence_qspi_apb_command_read(struct cadence_spi_priv
*priv,
unsigned int dummy_clk;
u8 opcode;
- if (priv->dtr)
- opcode = op->cmd.opcode >> 8;
- else
+ switch (op->cmd.nbytes) {
+ case 1:
opcode = op->cmd.opcode;
+ break;
+ case 2:
+ opcode = op->cmd.opcode >> 8;
+ break;
+ default:
+ return log_msg_ret("QSPI: Invalid command length", -EINVAL);
+ }
if (opcode == CMD_4BYTE_OCTAL_READ && !priv->dtr)
opcode = CMD_4BYTE_FAST_READ;
@@ -557,10 +571,16 @@ int cadence_qspi_apb_command_write(struct
cadence_spi_priv *priv,
void *reg_base = priv->regbase;
u8 opcode;
- if (priv->dtr)
- opcode = op->cmd.opcode >> 8;
- else
+ switch (op->cmd.nbytes) {
+ case 1:
opcode = op->cmd.opcode;
+ break;
+ case 2:
+ opcode = op->cmd.opcode >> 8;
+ break;
+ default:
+ return log_msg_ret("QSPI: Invalid command length", -EINVAL);
+ }
reg |= opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB;
@@ -634,10 +654,16 @@ int cadence_qspi_apb_read_setup(struct cadence_spi_priv
*priv,
priv->regbase + CQSPI_REG_INDIRECTTRIGGER);
/* Configure the opcode */
- if (priv->dtr)
- opcode = op->cmd.opcode >> 8;
- else
+ switch (op->cmd.nbytes) {
+ case 1:
opcode = op->cmd.opcode;
+ break;
+ case 2:
+ opcode = op->cmd.opcode >> 8;
+ break;
+ default:
+ return log_msg_ret("QSPI: Invalid command length", -EINVAL);
+ }
rd_reg = opcode << CQSPI_REG_RD_INSTR_OPCODE_LSB;
rd_reg |= op->cmd.dtr ? CQSPI_REG_RD_INSTR_DDR_EN_MASK : 0;
@@ -804,10 +830,16 @@ int cadence_qspi_apb_write_setup(struct cadence_spi_priv
*priv,
priv->regbase + CQSPI_REG_INDIRECTTRIGGER);
/* Configure the opcode */
- if (priv->dtr)
- opcode = op->cmd.opcode >> 8;
- else
+ switch (op->cmd.nbytes) {
+ case 1:
opcode = op->cmd.opcode;
+ break;
+ case 2:
+ opcode = op->cmd.opcode >> 8;
+ break;
+ default:
+ return log_msg_ret("QSPI: Invalid command length", -EINVAL);
+ }
reg = opcode << CQSPI_REG_WR_INSTR_OPCODE_LSB;
reg |= priv->data_width << CQSPI_REG_WR_INSTR_TYPE_DATA_LSB;
--
2.43.2
[PATCH 05/11] spi: cadence-quadspi: disable automatic write enable
From: Ian Roberts The spi-nor subsystem issues the write enable command manually. So this automatic feature sends duplicate commands and also introduces the possibility of erroneous writes. Disable the automatic write enable feature by default. Co-developed-by: Nathan Barrett-Morrison Signed-off-by: Nathan Barrett-Morrison Signed-off-by: Greg Malysa Signed-off-by: Ian Roberts --- drivers/spi/cadence_qspi.h | 1 + drivers/spi/cadence_qspi_apb.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h index 72e92cc997..355919cb23 100644 --- a/drivers/spi/cadence_qspi.h +++ b/drivers/spi/cadence_qspi.h @@ -73,6 +73,7 @@ #define CQSPI_REG_WR_INSTR 0x08 #define CQSPI_REG_WR_INSTR_OPCODE_LSB 0 +#define CQSPI_REG_WR_INSTR_WELDIS_MASK BIT(8) #define CQSPI_REG_WR_INSTR_TYPE_ADDR_LSB 12 #define CQSPI_REG_WR_INSTR_TYPE_DATA_LSB 16 diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c index eb9f4ed63d..176cff5338 100644 --- a/drivers/spi/cadence_qspi_apb.c +++ b/drivers/spi/cadence_qspi_apb.c @@ -842,6 +842,7 @@ int cadence_qspi_apb_write_setup(struct cadence_spi_priv *priv, } reg = opcode << CQSPI_REG_WR_INSTR_OPCODE_LSB; + reg |= CQSPI_REG_WR_INSTR_WELDIS_MASK; reg |= priv->data_width << CQSPI_REG_WR_INSTR_TYPE_DATA_LSB; reg |= priv->addr_width << CQSPI_REG_WR_INSTR_TYPE_ADDR_LSB; writel(reg, priv->regbase + CQSPI_REG_WR_INSTR); -- 2.43.2
[PATCH 03/11] spi: cadence-quadspi: Enable DDR bit for DTR commands
From: Ian Roberts The Cadence octal SPI IP read instruction register requires a bit to be set to indicate if the read opcode is a compliant DDR read command. Co-developed-by: Nathan Barrett-Morrison Signed-off-by: Nathan Barrett-Morrison Signed-off-by: Greg Malysa Signed-off-by: Ian Roberts --- drivers/spi/cadence_qspi.h | 1 + drivers/spi/cadence_qspi_apb.c | 4 2 files changed, 5 insertions(+) diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h index 693474a287..72e92cc997 100644 --- a/drivers/spi/cadence_qspi.h +++ b/drivers/spi/cadence_qspi.h @@ -61,6 +61,7 @@ #define CQSPI_REG_RD_INSTR 0x04 #define CQSPI_REG_RD_INSTR_OPCODE_LSB 0 #define CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB 8 +#define CQSPI_REG_RD_INSTR_DDR_EN_MASK BIT(10) #define CQSPI_REG_RD_INSTR_TYPE_ADDR_LSB12 #define CQSPI_REG_RD_INSTR_TYPE_DATA_LSB16 #define CQSPI_REG_RD_INSTR_MODE_EN_LSB 20 diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c index fb90532217..34cacf1880 100644 --- a/drivers/spi/cadence_qspi_apb.c +++ b/drivers/spi/cadence_qspi_apb.c @@ -446,6 +446,7 @@ int cadence_qspi_apb_command_read_setup(struct cadence_spi_priv *priv, return ret; reg = cadence_qspi_calc_rdreg(priv); + reg |= op->cmd.dtr ? CQSPI_REG_RD_INSTR_DDR_EN_MASK : 0; writel(reg, priv->regbase + CQSPI_REG_RD_INSTR); return 0; @@ -537,6 +538,7 @@ int cadence_qspi_apb_command_write_setup(struct cadence_spi_priv *priv, return ret; reg = cadence_qspi_calc_rdreg(priv); + reg |= op->cmd.dtr ? CQSPI_REG_RD_INSTR_DDR_EN_MASK : 0; writel(reg, priv->regbase + CQSPI_REG_RD_INSTR); return 0; @@ -638,6 +640,7 @@ int cadence_qspi_apb_read_setup(struct cadence_spi_priv *priv, opcode = op->cmd.opcode; rd_reg = opcode << CQSPI_REG_RD_INSTR_OPCODE_LSB; + rd_reg |= op->cmd.dtr ? CQSPI_REG_RD_INSTR_DDR_EN_MASK : 0; rd_reg |= cadence_qspi_calc_rdreg(priv); writel(op->addr.val, priv->regbase + CQSPI_REG_INDIRECTRDSTARTADDR); @@ -812,6 +815,7 @@ int cadence_qspi_apb_write_setup(struct cadence_spi_priv *priv, writel(reg, priv->regbase + CQSPI_REG_WR_INSTR); reg = cadence_qspi_calc_rdreg(priv); + reg |= op->cmd.dtr ? CQSPI_REG_RD_INSTR_DDR_EN_MASK : 0; writel(reg, priv->regbase + CQSPI_REG_RD_INSTR); writel(op->addr.val, priv->regbase + CQSPI_REG_INDIRECTWRSTARTADDR); -- 2.43.2
[PATCH 02/11] mtd: spi-nor: Octal DTR support for IS25*x
From: Ian Roberts
ISSI IS25*x series SPIflash chips are capable of Octal IO and DDR.
Add spi-nor support to enable and operate in these modes.
Co-developed-by: Nathan Barrett-Morrison
Signed-off-by: Nathan Barrett-Morrison
Signed-off-by: Greg Malysa
Signed-off-by: Ian Roberts
---
drivers/mtd/spi/spi-nor-core.c | 78 ++
drivers/mtd/spi/spi-nor-ids.c | 6 ++-
include/linux/mtd/spi-nor.h| 6 +++
3 files changed, 89 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index f164c3cf73..ce86e53860 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3968,6 +3968,76 @@ static struct spi_nor_fixups macronix_octal_fixups = {
};
#endif /* CONFIG_SPI_FLASH_MACRONIX */
+#ifdef CONFIG_SPI_FLASH_ISSI
+/**
+ * spi_nor_issi_octal_dtr_enable() - Enable octal DTR on ISSI flashes.
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_issi_octal_dtr_enable(struct spi_nor *nor)
+{
+ struct spi_mem_op op;
+ int ret;
+ u8 regval;
+
+ nor->read_dummy = ISSI_MAX_DC;
+
+ ret = write_enable(nor);
+ if (ret)
+ return ret;
+
+ regval = SPINOR_REG_ISSI_VCR_ODDR_EN;
+ op = (struct spi_mem_op)
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_ISSI_WR_VCR, 1),
+ SPI_MEM_OP_ADDR(3, SPINOR_REG_ISSI_VCR_IOMODE, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1, ®val, 1));
+
+ ret = spi_mem_exec_op(nor->spi, &op);
+ if (ret) {
+ dev_err(nor->dev, "Failed to enable octal DTR mode\n");
+ return ret;
+ }
+
+ nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
+
+ return 0;
+}
+
+static void issi_octal_default_init(struct spi_nor *nor)
+{
+ nor->octal_dtr_enable = spi_nor_issi_octal_dtr_enable;
+}
+
+static void issi_octal_post_sfdp_fixup(struct spi_nor *nor,
+ struct spi_nor_flash_parameter *params)
+{
+ /*
+* Adding SNOR_HWCAPS_PP_8_8_8_DTR in hwcaps.mask when
+* SPI_NOR_OCTAL_DTR_READ flag exists.
+*/
+ if (params->hwcaps.mask & SNOR_HWCAPS_READ_8_8_8_DTR)
+ params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
+ nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
+
+ spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR],
+ 0, 16, 0x0c, SNOR_PROTO_8_8_8_DTR);
+ spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP_8_8_8_DTR],
+ 0x12, SNOR_PROTO_8_8_8_DTR);
+
+ params->rdsr_dummy = 8;
+
+ nor->flags |= SNOR_F_IO_MODE_EN_VOLATILE;
+ nor->flags |= SNOR_F_SOFT_RESET;
+}
+
+static struct spi_nor_fixups issi_octal_dtr_fixups = {
+ .default_init = issi_octal_default_init,
+ .post_sfdp = issi_octal_post_sfdp_fixup,
+};
+#endif /* CONFIG_SPI_FLASH_ISSI */
+
/** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
* @nor: pointer to a 'struct spi_nor'
*
@@ -4161,6 +4231,14 @@ void spi_nor_set_fixups(struct spi_nor *nor)
nor->fixups = &mt35xu512aba_fixups;
#endif
+#if CONFIG_IS_ENABLED(SPI_FLASH_ISSI)
+ if (JEDEC_MFR(nor->info) == SNOR_MFR_ISSI) {
+ if ((nor->info->id[1] == 0x5a || nor->info->id[1] == 0x5b) &&
+ (nor->info->id[2] == 0x19 || nor->info->id[2] == 0x18))
+ nor->fixups = &issi_octal_dtr_fixups;
+ }
+#endif
+
#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
nor->fixups = ¯onix_octal_fixups;
#endif /* SPI_FLASH_MACRONIX */
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 4e83b8c94c..e3e37cd79b 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -238,8 +238,12 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("is25wp01g", 0x9d701b, 0, 64 * 1024, 2048,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { INFO("is25lx256", 0x9d5a19, 0, 128 * 1024, 256,
+ SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ
+ | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
{ INFO("is25wx256", 0x9d5b19, 0, 128 * 1024, 256,
- SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
SPI_NOR_4B_OPCODES) },
+ SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ
+ | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
{ INFO("is25lx512", 0x9d5a1a, 0, 64 * 1024, 1024,
SECT_4K | USE_FSR | SPI_NOR_4B_OPCODES |
SPI_NOR_HAS_TB) },
#endif
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 2eddb52392..bd364e74a7 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-n
Re: [PATCH v2] board: rockchip: Add the Turing RK1 SoM
On Thu, Apr 11, 2024 at 1:29 AM Florian Klink wrote:
>
> On 23-12-14 18:46:47, Joshua Riek wrote:
> >The Turing RK1 is a Rockchip RK3588 based SoM from Turing Machines.
> >
> >Specifications:
> >
> >Rockchip RK3588 SoC
> >4x ARM Cortex-A76, 4x ARM Cortex-A55
> >8/16/32GB memory LPDDR4x
> >Mali G610MC4 GPU
> >32GB eMMC HS400
> >2x USB 2.0, 2x USB 3.0
> >2x MIPI CSI 4x lanes
> >1x MIPI-DSI DPHY 2x lanes
> >PCIe 2.0 x1, PCIe 3.0 x4
> >1x HDMI 2.1 output, 1x DP 1.4 output
> >Gigabit Ethernet
> >Size: 69.6mm x 45mm (260-pin SO-DIMM connector)
> >
> >Kernel commit:
> >2806a69f3fef ("arm64: dts: rockchip: Add Turing RK1 SoM support")
>
> […]
>
> >diff --git a/configs/turing-rk1-rk3588_defconfig
> >b/configs/turing-rk1-rk3588_defconfig
> >new file mode 100644
> >index 00..289f2da775
> >--- /dev/null
> >+++ b/configs/turing-rk1-rk3588_defconfig
> >@@ -0,0 +1,133 @@
> >+CONFIG_ARM=y
> >+CONFIG_SKIP_LOWLEVEL_INIT=y
> >+CONFIG_SYS_HAS_NONCACHED_MEMORY=y
> >+CONFIG_COUNTER_FREQUENCY=2400
> >+CONFIG_ARCH_ROCKCHIP=y
> >+CONFIG_TEXT_BASE=0x00a0
> >+CONFIG_SPL_LIBCOMMON_SUPPORT=y
> >+CONFIG_SPL_LIBGENERIC_SUPPORT=y
> >+CONFIG_NR_DRAM_BANKS=2
> >+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
> >+CONFIG_SF_DEFAULT_SPEED=2400
> >+CONFIG_SF_DEFAULT_MODE=0x2000
> >+CONFIG_DEFAULT_DEVICE_TREE="rk3588-turing-rk1"
> >+CONFIG_ROCKCHIP_RK3588=y
> >+CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
> >+CONFIG_ROCKCHIP_SPI_IMAGE=y
>
Hi Florian,
Thanks for getting in touch!
> Does the RK1 have an SPI chip attached, and is is possible to flash
> u-boot into SPI and boot from it?
The answer you want is "no." Though the RK1 does have an unpopulated
pad for SPI flash, actually installing one would be a pretty involved
user modification, and those users almost certainly can/will build the
SPI boot image themselves.
> This has sparked some confusion on whether "u-boot-rockchip-spi.bin"
> should be provided in a downstream build or not.
Ah yeah the CONFIG_ROCKCHIP_SPI_IMAGE=y might not be a sensible
default given that 99.9% of users don't need it. Is that config entry
the main thing creating the confusion? I think it should be removed
here in U-Boot if so.
Note that the RK1 is a little different from most RK3588 boards in
that UART9 at 115200 baud is the generally-accepted debug UART (due
both to the popularity of pairing it with the Turing Pi 2
clusterboard, and for pin-compatibility with most NVIDIA Jetson SoMs),
and setting this very early in boot requires using Rockchip's
"ddrbin_tool" to change the configuration embedded in the ddrbin/TPL
image. If you're already supporting other targets that require ddrbin
configuration changes, please add these for RK1:
uart id=9
uart iomux=0
uart baudrate=115200
...but if this would require going significantly out of your way,
don't worry about it. IIUC this is only required to get TPL+SPL output
routed correctly: the U-Boot monitor + kernel will still
(re)initialize UART9 appropriately.
Cheers,
Sam
>
> […]
>
> Thanks,
> Florian
Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL
On Wed, Apr 03, 2024 at 06:18:01PM +0530, Chintan Vankar wrote: > > > On 22/01/24 10:11, Siddharth Vadapalli wrote: > > > > > > On 20/01/24 22:11, Tom Rini wrote: > > > On Mon, Jan 15, 2024 at 01:42:51PM +0530, Siddharth Vadapalli wrote: > > > > Hello Tom, > > > > > > > > On 12/01/24 18:56, Tom Rini wrote: > > > > ... > > > > > > > The list of conditionals in common/spl/spl.c::board_init_r() should be > > > > > updated and probably use SPL_NET as the option to check for. > > > > > > > > Thank you for reviewing the patch and pointing this out. I wasn't aware > > > > of it. I > > > > assume that you are referring to the following change: > > > > > > > > if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || > > > > CONFIG_IS_ENABLED(HANDOFF) || > > > > - IS_ENABLED(CONFIG_SPL_ATF)) > > > > + IS_ENABLED(CONFIG_SPL_ATF) || IS_ENABLED(CONFIG_SPL_NET)) > > > > dram_init_banksize(); > > > > > > > > I shall replace the current patch with the above change in the v2 > > > > series. Since > > > > this is in the common section, is there a generic reason I could > > > > provide in the > > > > commit message rather than the existing commit message which seems to > > > > be board > > > > specific? Also, I hope that the above change will not cause regressions > > > > for > > > > other non-TI devices. Please let me know. > > > > > > Yes, that's the area, and just note that networking also requires the > > > DDR to be initialized. > > > > > > > Thank you for confirming and providing your suggestion for the contents of > > the > > commit message. > > > Following Tom's Suggestion of adding CONFIG_SPL_NET in common/spl/spl.c > "dram_init_banksize()", the issue of fetching a file at SPL stage seemed > to be fixed. However the commit "ba20b2443c29", which sets gd->ram_top > for the very first time in "spl_enable_cache()" results in > "arch_lmb_reserve()" function reserving memory region from Stack pointer > at "0x81FFB820" to gd->ram_top pointing to "0x1". Previously > when gd->ram_top was zero "arch_lmb_reserve()" was noop. Now using TFTP > to fetch U-Boot image at SPL stage results in "tftp_init_load_addr()" > function call that invokes "arch_lmb_reserve()" function, which reserves > entire memory starting from Stack Pointer to gd->ram_top leaving no > space to load U-Boot image via TFTP since TFTP loads files at pre > configured memory address at "0x8200". > > As a workaround for this issue, one solution we can propose is to > disable the checks "lmb_get_free_size()" at SPL and U-Boot stage. For > that we can define a new config option for LMB reserve checks as > "SPL_LMB". This config will be enable by default for the backword > compatibility and disable for our use case at SPL and U-Boot stage. The problem here is that we need LMB for booting an OS, which is something we'll want in SPL in non-cortex-R cases too, which means this platform, so that's a no-go. I think you need to dig harder and see if you can correct the logic somewhere so that we don't over reserve? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/2] sunxi, usb: UDC/DM gadget model support
On Thu, Apr 11, 2024 at 1:40 AM John Watts wrote: > > On Thu, Apr 11, 2024 at 12:52:14AM -0600, Sam Edwards wrote: > > Hi John, > > > > This patch was developed against (and used very heavily on) the Turing > > Pi 2, which has an Allwinner T113-s3 SoC. Likely it should work for > > any T113/D1 board. I haven't been encountering any USB errors but also > > my use case hasn't gone much beyond the `udc` command. What > > device/errors do you have over there? > > > > Cheers, > > Sam > > Hi Sam, > > I made a list of things that do work: > > - DFU (slowly, probably due to no DMA) to RAM > - CDC serial console > > Running a command like this: > > ubi part ubi; ubifsmount ubi:root; ums 0 ubi 0; Hi John, Ahh I see the problem. In U-Boot, `ubi` isn't actually a block device: it's implemented as a stub in the block layer, and the filesystem layer redirects `ubi` accesses to the currently-mounted ubifs instead. But the `ums` command works on the block layer, so it's not being intercepted, and instead hitting that stub and likely crashing. In the spirit of the Linux ubiblock driver, I have another patchset[1] I've been working on[2] to expose static ubivols as true read-only block devices. Note that this only works for static volumes: the access semantics of dynamic volumes are too flash-like to support block device access, so accessing them with `ums` likely will never work like users expect. Still, there could be some interaction issue between `ums`<->USB that I haven't identified. Could you try with mmc (if available) or a ramdisk (otherwise) just to confirm that `ums` is fine? Regards, Sam [1] https://lore.kernel.org/u-boot/20230812000606.72319-1-cfswo...@gmail.com/T/ [2] Not very diligently; if you're interested in helping test it, I'd love to get back to it. > > Gives this output in dmesg: > > [3633079.772330] usb-storage 1-1.1:1.0: USB Mass Storage device detected > [3633079.772506] scsi host9: usb-storage 1-1.1:1.0 > [3633080.794607] scsi 9:0:0:0: Direct-Access LinuxUMS disk 0 > PQ: 0 ANSI: 2 > [3633080.794941] sd 9:0:0:0: Attached scsi generic sg6 type 0 > [3633080.795214] sd 9:0:0:0: [sdg] 3942645758 512-byte logical blocks: (2.02 > TB/1.83 TiB) > [3633080.795220] sd 9:0:0:0: [sdg] 3925868545-byte physical blocks > [3633080.795341] sd 9:0:0:0: [sdg] Write Protect is off > [3633080.795345] sd 9:0:0:0: [sdg] Mode Sense: 0f 00 00 00 > [3633080.795462] sd 9:0:0:0: [sdg] Write cache: enabled, read cache: enabled, > doesn't support DPO or FUA > [3633080.907359] usb 1-1.1: reset high-speed USB device number 44 using > xhci_hcd > [3633081.021905] usb 1-1.1: device descriptor read/64, error -71 > [3633081.238566] usb 1-1.1: device descriptor read/64, error -71 > [3633081.448573] usb 1-1.1: reset high-speed USB device number 44 using > xhci_hcd > [3633081.558566] usb 1-1.1: device descriptor read/64, error -71 > [3633081.775236] usb 1-1.1: device descriptor read/64, error -71 > [3633081.988559] usb 1-1.1: reset high-speed USB device number 44 using > xhci_hcd > [3633086.788615] usb 1-1.1: Device not responding to setup address. > [3633091.799190] usb 1-1.1: Device not responding to setup address. > [3633092.008482] usb 1-1.1: device not accepting address 44, error -71 > [3633092.747719] usb 1-1.1: USB disconnect, device number 44 > [3633092.748488] device offline error, dev sdg, sector 0 op 0x0:(READ) flags > 0x0 phys_seg 2 prio class 2 > [3633092.748502] buffer_io_error: 10 callbacks suppressed > [3633092.748504] Buffer I/O error on dev sdg, logical block 0, async page read > [3633092.748511] Buffer I/O error on dev sdg, logical block 1, async page read > [3633092.748520] device offline error, dev sdg, sector 4 op 0x0:(READ) flags > 0x0 phys_seg 2 prio class 2 > [3633092.748525] Buffer I/O error on dev sdg, logical block 2, async page read > [3633092.748529] Buffer I/O error on dev sdg, logical block 3, async page read > [3633092.748582] device offline error, dev sdg, sector 0 op 0x0:(READ) flags > 0x0 phys_seg 4 prio class 2 > [3633092.748594] Buffer I/O error on dev sdg, logical block 0, async page read > [3633092.748600] Buffer I/O error on dev sdg, logical block 1, async page read > [3633092.748605] Buffer I/O error on dev sdg, logical block 2, async page read > [3633092.748609] Buffer I/O error on dev sdg, logical block 3, async page read > [3633092.748621] ldm_validate_partition_table(): Disk read failed. > [3633092.748638] device offline error, dev sdg, sector 0 op 0x0:(READ) flags > 0x0 phys_seg 2 prio class 2 > [3633092.748644] Buffer I/O error on dev sdg, logical block 0, async page read > [3633092.748649] Buffer I/O error on dev sdg, logical block 1, async page read > [3633092.748665] device offline error, dev sdg, sector 4 op 0x0:(READ) flags > 0x0 phys_seg 2 prio class 2 > [3633092.748686] device offline error, dev sdg, sector 0 op 0x0:(READ) flags > 0x0 phys_seg 2 prio class 2 > [3633092.748704] device offline error, dev sdg, sector 4 op 0x0:(READ) flags > 0x0 phys_
Re: [PATCH] boot: Pass baud rate to stdout-path
On Thu, Apr 11, 2024 at 05:11:46PM +0200, Mark Kettenis wrote: > You probably should fix this by making sure the device tree you're > using has the appropriate stdout-path node. Because I think the > functionality you're trying to use here is deprecated: Hi Mark, Interesting, I'll go with that approach instead. > ... > > A particular case that I'm dealing with is the default speed of > 150 that the various Rockchip SoCs use. This doesn't work with > many of the USB-to-serial interfaces on the market and is also rather > susceptible to line noise. So for OpenBSD packages I've decide to use > 115200 instead. But that means I have to patch all the device trees > in addition to changing the CONFIG_BAUDRATE setting. If U-Boot would > tweak the stdout-path property based on CONFIG_BAUDRATE that would > make things easier. That's an interesting use case! Would you mind testing this patch if possible? > Cheers, > > Mark John.
Re: [PATCH 0/2] sunxi: Support UART1 and UART2 on the T113
On Thu, Apr 11, 2024 at 01:37:38PM +0100, Andre Przywara wrote: > Hi John, > > > The T113 supports UART1 and UART2 on PG and PD pins respectively. > > Add support for these in U-Boot so we can use them. > > So those bits are just for the *debug* UARTs. Traditionally this is UART0, > with some particular pinmux, sometimes UART2 on older SoCs. Hi Andre, No board uses this by default, so I'll just carry this out of tree then. Thanks for looking at the patch! > So is there a board that uses those pins for a debug console? I want to > avoid making this code even messier than it already is, without good > reasons. Also please note that I tried to clean this up here: > https://patchwork.ozlabs.org/project/uboot/patch/20240103001239.17482-20-andre.przyw...@arm.com/ I'll give this a test and review for you when I can. John.
Re: [PATCH v2 12/16] arm: dts: k3-am625-sk-u-boot: Add sysreset-controller node
Mattijs Korpershoek writes:
> Hi Jonathan,
>
> Thank you for the patch.
>
> On lun., avril 08, 2024 at 17:31, Jonathan Humphreys
> wrote:
>
>> Signed-off-by: Jonathan Humphreys
>
> Please consider adding a commit message body.
Got it. thanks.
BTW, the next version of this series will drop this patch as Andrew has
submitted another patch removing the need for this one. See
https://lore.kernel.org/r/20240402160908.508974-1-...@ti.com.
>
> On the TI vendor tree, there is a similar patch with a commit message:
> https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2023.04&id=c5296d943c2c84dd6dcb3b91305d006ac46f3157
>
> Before patch:
> => reset
> resetting ...
> System reset not supported on this platform
> ### ERROR ### Please RESET the board ###
>
> With patch applied:
> => reset
> resetting ...
>
> Tested-by: Mattijs Korpershoek # on am62x sk evm
>
> Andrew also suggested to me that if we are interested by A53 reset only,
> we can PSCI reset instead for all k3 architecture:
>
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -784,6 +784,9 @@ config ARCH_K3
> bool "Texas Instruments' K3 Architecture"
> select SPL
> select SUPPORT_SPL
> + select PSCI_RESET if ARM64
> + select SYSRESET if ARM64
> + select SYSRESET_PSCI if ARM64
> select FIT
> select REGEX
> select FIT_SIGNATURE if ARM64
>
> Has the above been considered?
I am not aware. I would think that you want full reset, unless you are
thinking about specifying a reset level?
Jon
>
>
>> ---
>> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>> index fa778b0ff4c..35bfeae75a0 100644
>> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>> @@ -46,3 +46,12 @@
>> &cpsw_port2 {
>> status = "disabled";
>> };
>> +
>> +&dmsc {
>> +bootph-pre-ram;
>> +
>> +k3_sysreset: sysreset-controller {
>> +compatible = "ti,sci-sysreset";
>> +bootph-pre-ram;
>> +};
>> +};
>> --
>> 2.34.1
Re: [PATCH v3 0/3] Introduce mtdblock device
Hello! Ping. On Thu, Apr 04, 2024 at 01:58:10PM +0300, Alexey Romanov wrote: > Hello! > > This series adds support for the mtdblock device, which > allows to read/write data block by block. For example, > it can now be used for BCB or Android AB command: > > $ bcb load mtd 0 part_name > > Tested only on SPI NAND, so bind is made only for > SPI NAND drivers. > > --- > > Changes V1 -> V2 [1]: > > - Drop patch [2]. > - Add warning if bind NAND mtdblock device. > - Move documentation of mtdblock implementation > from commit message to the source code. > - Remove __maybe_unused from mtd partition functions > description. > - Use blk_enabled() instead of #ifdefs. > > Changes V2 -> V3 [2]: > > - Rebased over [3]. > - Rename mtd_bread/bwrite -> mtd_blk_read/write. > - Fix GPL-2.0 license short name definiton in headers. > - Add empty line after MTD_ENTRY_NUMBERS define. > > Links: > > - [1] > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > - [2] > https://lore.kernel.org/all/20240227100441.1811047-5-avroma...@salutedevices.com/ > - [3] > https://lore.kernel.org/u-boot/20240403114047.84030-1-heinrich.schucha...@canonical.com/T/#u > > Alexey Romanov (3): > disk: support MTD partitions > drivers: introduce mtdblock abstraction > spinand: bind mtdblock > > disk/part.c | 3 +- > drivers/block/blk-uclass.c | 1 + > drivers/mtd/Kconfig | 1 + > drivers/mtd/Makefile| 1 + > drivers/mtd/mtdblock.c | 227 > drivers/mtd/mtdpart.c | 69 +++ > drivers/mtd/nand/spi/core.c | 20 > include/linux/mtd/mtd.h | 12 ++ > include/part.h | 3 + > 9 files changed, 336 insertions(+), 1 deletion(-) > create mode 100644 drivers/mtd/mtdblock.c > > -- > 2.34.1 > -- Thank you, Alexey
Re: [PATCH v4 1/6] boot: fdt: Change type of env_get_bootm_low() to phys_addr_t
On Tue, 26 Mar 2024 23:13:11 +0100, Marek Vasut wrote: > Change type of ulong env_get_bootm_low() to phys_addr_t env_get_bootm_low(). > The PPC/LS systems already treat env_get_bootm_low() result as phys_addr_t, > while the function itself still returns ulong. This is potentially dangerous > on 64bit systems, where ulong might not be large enough to hold the content > of "bootm_low" environment variable. Fix it by using phys_addr_t, similar to > what env_get_bootm_size() does, which returns phys_size_t . > > [...] Applied to u-boot/master, thanks! -- Tom
[PATCH] input: button_kbd: gracefully handle buttons that fail probe
If a button device fails to probe, it will still be added to the uclass
device list, and therefore will still be iterated over in
button_read_keys() resulting in a UAF on the buttons private data.
Resolve this by unbinding button devices that aren't active after
probing, and print a warning so it's clear that the button is broken.
Fixes: e8779962898e ("dm: input: add button_kbd driver")
Signed-off-by: Caleb Connolly
---
drivers/input/button_kbd.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/input/button_kbd.c b/drivers/input/button_kbd.c
index 74fadfca8bb8..c73d3b18be9c 100644
--- a/drivers/input/button_kbd.c
+++ b/drivers/input/button_kbd.c
@@ -33,9 +33,10 @@ struct button_kbd_priv {
static int button_kbd_start(struct udevice *dev)
{
struct button_kbd_priv *priv = dev_get_priv(dev);
int i = 0;
- struct udevice *button_gpio_devp;
+ struct udevice *button_gpio_devp, *next_devp;
+ struct uclass *uc;
uclass_foreach_dev_probe(UCLASS_BUTTON, button_gpio_devp) {
struct button_uc_plat *uc_plat =
dev_get_uclass_plat(button_gpio_devp);
/* Ignore the top-level button node */
@@ -45,8 +46,23 @@ static int button_kbd_start(struct udevice *dev)
uc_plat->label, i, button_gpio_devp->name);
i++;
}
+ if (uclass_get(UCLASS_BUTTON, &uc))
+ return -ENOENT;
+
+ /*
+* Unbind any buttons that failed to probe so we don't iterate over
+* them when polling.
+*/
+ uclass_foreach_dev_safe(button_gpio_devp, next_devp, uc) {
+ if (!(dev_get_flags(button_gpio_devp) & DM_FLAG_ACTIVATED)) {
+ log_warning("Button %s failed to probe\n",
+ button_gpio_devp->name);
+ device_unbind(button_gpio_devp);
+ }
+ }
+
priv->button_size = i;
priv->old_state = calloc(i, sizeof(int));
return 0;
--
2.44.0
[PATCH] Fix references to trace doc
The README.trace has been moved and converted to rst in commit dce26c7d56ed
("doc: move README.trace to HTML documentation"); fix all the remaining
references to this file.
Signed-off-by: Vincent Stehlé
Cc: Tom Rini
Cc: Simon Glass
Cc: Heinrich Schuchardt
---
cmd/Kconfig | 4 ++--
doc/develop/tests_sandbox.rst | 2 +-
lib/Kconfig | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 38305197602..f9f271616d3 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2832,8 +2832,8 @@ config CMD_TRACE
Enables a command to control using of function tracing within
U-Boot. This allows recording of call traces including timing
information. The command can write data to memory for exporting
- for analysis (e.g. using bootchart). See doc/README.trace for full
- details.
+ for analysis (e.g. using bootchart). See doc/develop/trace.rst
+ for full details.
config CMD_AVB
bool "avb - Android Verified Boot 2.0 operations"
diff --git a/doc/develop/tests_sandbox.rst b/doc/develop/tests_sandbox.rst
index bfd3bdb9270..c2824834d07 100644
--- a/doc/develop/tests_sandbox.rst
+++ b/doc/develop/tests_sandbox.rst
@@ -29,7 +29,7 @@ Some of the available tests are:
- test/image/test-imagetools.sh - multi-file images
- test/py/tests/test-fit.py - FIT images
- tracing: test/trace/test-trace.sh tests the tracing system (see
- README.trace)
+ doc/develop/trace.rst)
- verified boot: test/py/tests/test_vboot.py
If you change or enhance any U-Boot subsystem, you should write or expand a
diff --git a/lib/Kconfig b/lib/Kconfig
index 37ac14f7bab..efb77978a65 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -348,7 +348,7 @@ config TRACE
Enables function tracing within U-Boot. This allows recording of call
traces including timing information. The command can write data to
memory for exporting for analysis (e.g. using bootchart).
- See doc/README.trace for full details.
+ See doc/develop/trace.rst for full details.
config TRACE_BUFFER_SIZE
hex "Size of trace buffer in U-Boot"
--
2.43.0
Re: [PATCH v3 0/3] Introduce mtdblock device
Hi I will review tomorrow, I need have a time window to test even on my board Mihcael On Thu, Apr 11, 2024 at 6:09 PM Alexey Romanov wrote: > > Hello! Ping. > > On Thu, Apr 04, 2024 at 01:58:10PM +0300, Alexey Romanov wrote: > > Hello! > > > > This series adds support for the mtdblock device, which > > allows to read/write data block by block. For example, > > it can now be used for BCB or Android AB command: > > > > $ bcb load mtd 0 part_name > > > > Tested only on SPI NAND, so bind is made only for > > SPI NAND drivers. > > > > --- > > > > Changes V1 -> V2 [1]: > > > > - Drop patch [2]. > > - Add warning if bind NAND mtdblock device. > > - Move documentation of mtdblock implementation > > from commit message to the source code. > > - Remove __maybe_unused from mtd partition functions > > description. > > - Use blk_enabled() instead of #ifdefs. > > > > Changes V2 -> V3 [2]: > > > > - Rebased over [3]. > > - Rename mtd_bread/bwrite -> mtd_blk_read/write. > > - Fix GPL-2.0 license short name definiton in headers. > > - Add empty line after MTD_ENTRY_NUMBERS define. > > > > Links: > > > > - [1] > > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > > - [2] > > https://lore.kernel.org/all/20240227100441.1811047-5-avroma...@salutedevices.com/ > > - [3] > > https://lore.kernel.org/u-boot/20240403114047.84030-1-heinrich.schucha...@canonical.com/T/#u > > > > Alexey Romanov (3): > > disk: support MTD partitions > > drivers: introduce mtdblock abstraction > > spinand: bind mtdblock > > > > disk/part.c | 3 +- > > drivers/block/blk-uclass.c | 1 + > > drivers/mtd/Kconfig | 1 + > > drivers/mtd/Makefile| 1 + > > drivers/mtd/mtdblock.c | 227 > > drivers/mtd/mtdpart.c | 69 +++ > > drivers/mtd/nand/spi/core.c | 20 > > include/linux/mtd/mtd.h | 12 ++ > > include/part.h | 3 + > > 9 files changed, 336 insertions(+), 1 deletion(-) > > create mode 100644 drivers/mtd/mtdblock.c > > > > -- > > 2.34.1 > > > > -- > Thank you, > Alexey -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
[PATCH] usb: dwc3: support USB 3.1 controllers
The revision is different for these, add the additional check as in
xhci-dwc3 core_init code.
Signed-off-by: Caleb Connolly
---
drivers/usb/dwc3/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 96e850b7170f..db045f5822d4 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -594,9 +594,10 @@ static int dwc3_core_init(struct dwc3 *dwc)
int ret;
reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
/* This should read as U3 followed by revision number */
- if ((reg & DWC3_GSNPSID_MASK) != 0x5533) {
+ if ((reg & DWC3_GSNPSID_MASK) != 0x5533 &&
+ (reg & DWC3_GSNPSID_MASK) != 0x3331) {
dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
ret = -ENODEV;
goto err0;
}
--
2.44.0
Re: [PATCH v2 00/19] x86: expo: Add support for editing coreboot CMOS RAM settings
On Thu, Jan 04, 2024 at 08:11:33AM -0700, Simon Glass wrote: > U-Boot provides support for editing settings with an 'expo', as well as > reading and writing settings to CMOS RAM. > > This series integrates expo functionality with coreboot, using the > sysinfo table to get a list of settings, creating an expo with them and > allowing them to be edited. > > A new CI test provides coverage for some coreboot-related commands. For > this to work, a number of minor tweaks are made to existing tests, so > that they pass on coreboot (x86) or at least are skipped when they > cannot pass. Likely most of these fixes will apply to other boards too. > > It includes several other fixes and improvements: > - new -m flag for 'bootflow scan' so it can display a menu automatically > - Fix for video-scrolling crash with Truetype > - menu items can now have individual integer values > - menu items are lined up according to the width of all menu labels This needs to be rebased on top of master where I suspect the biggest problem is that we need to reconfigure coreboot that we build now? All of the new tests fail: https://source.denx.de/u-boot/u-boot/-/jobs/814728 and we're just building a standard defconfig for coreboot now. -- Tom signature.asc Description: PGP signature
Re: [PATCH] boot: Pass baud rate to stdout-path
> From: John Watts
> Date: Thu, 11 Apr 2024 15:03:20 +1000
>
> Linux might use the wrong baud rate such as 9600 by default, make sure
> to specify it when passing the serial port over.
>
> Signed-off-by: John Watts
> ---
> On my board at least (a sunxi T113) the serial console will initialize
> as 9600 baud instead of the set baud. Pass the baud with the serial
> device to Linux to solve this issue.
You probably should fix this by making sure the device tree you're
using has the appropriate stdout-path node. Because I think the
functionality you're trying to use here is deprecated:
* The linux,stdout-path property has been superseded by the
stdout-path property.
* The description of the OF_STDOUT_VIA_ALIAS option suggests that it
is seprecated as well:
This option currently references CONFIG_CONS_INDEX, which is
incorrect when used with device tree as this option does not
exist / should not be used.
It just happens that sunxi is one of the few remaining "modenr"
platforms that still uses CONFIG_CONS_INDEX.
That said, the diff is interesting. To me it doesn't really make
sense that you can change the serial port and its parameters in
U-Boot, but that this choice doesn't always make it into the device
tree that is passed to the OS.
A particular case that I'm dealing with is the default speed of
150 that the various Rockchip SoCs use. This doesn't work with
many of the USB-to-serial interfaces on the market and is also rather
susceptible to line noise. So for OpenBSD packages I've decide to use
115200 instead. But that means I have to patch all the device trees
in addition to changing the CONFIG_BAUDRATE setting. If U-Boot would
tweak the stdout-path property based on CONFIG_BAUDRATE that would
make things easier.
Cheers,
Mark
> ---
> boot/fdt_support.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/boot/fdt_support.c b/boot/fdt_support.c
> index 090d82ee80..83e62f47b5 100644
> --- a/boot/fdt_support.c
> +++ b/boot/fdt_support.c
> @@ -153,9 +153,9 @@ static int fdt_fixup_stdout(void *fdt, int chosenoff)
> }
>
> /* fdt_setprop may break "path" so we copy it to tmp buffer */
> - memcpy(tmp, path, len);
> + len = sprintf(tmp, "%.*s:%d", len, (char *)path, CONFIG_BAUDRATE);
>
> - err = fdt_setprop(fdt, chosenoff, "linux,stdout-path", tmp, len);
> + err = fdt_setprop(fdt, chosenoff, "linux,stdout-path", tmp, len + 1);
> if (err < 0)
> printf("WARNING: could not set linux,stdout-path %s.\n",
> fdt_strerror(err));
>
> ---
> base-commit: 777c28460947371ada40868dc994dfe8537d7115
> change-id: 20240411-stdout-4f91b566a0f2
>
> Best regards,
> --
> John Watts
>
>
Re: [PATCH v6 0/7] Resolve issues with booting distros on x86
On Thu, 04 Jan 2024 08:10:35 -0700, Simon Glass wrote: > This little series reprises the EFI-video fix, fixes a USB problem and > enables a boot script for coreboot. > > It also moves to truetype fonts for coreboot and qemu-x86, since the > menus look much better and there are no strong size constraints. > > With these changes it is possible to boot a Linux distro automatically > with U-Boot on x86, including when U-Boot is the second-stage > bootloader. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 1/7] mmc: msm_sdhci: correct vendor_spec_cap0 register for v5
On Tue, 9 Apr 2024 at 23:33, Caleb Connolly wrote:
>
> The V4 and V5 controllers have quite varied register layouts. Inherit
> the register offsets and naming from the Linux driver. More version
> specific offsets can be inherited from Linux as needed.
>
> Fixes: 364c22a ("mmc: msm_sdhci: Add SDCC version 5.0.0 support")
> Signed-off-by: Caleb Connolly
> ---
> drivers/mmc/msm_sdhci.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
This patch broke booting on the HMIBSC board, have you tested it on
db410c? It's very likely that this has caused regression there too.
Error observed:
sdhci_send_command: Timeout for status update: 0001
-Sumit
> diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
> index 059cb3da77c5..f23d425144ef 100644
> --- a/drivers/mmc/msm_sdhci.c
> +++ b/drivers/mmc/msm_sdhci.c
> @@ -32,11 +32,8 @@
> #define SDCC_MCI_STATUS2 0x6C
> #define SDCC_MCI_STATUS2_MCI_ACT 0x1
> #define SDCC_MCI_HC_MODE 0x78
>
> -/* Non standard (?) SDHCI register */
> -#define SDHCI_VENDOR_SPEC_CAPABILITIES0 0x11c
> -
> struct msm_sdhc_plat {
> struct mmc_config cfg;
> struct mmc mmc;
> };
> @@ -48,8 +45,10 @@ struct msm_sdhc {
> };
>
> struct msm_sdhc_variant_info {
> bool mci_removed;
> +
> + u32 core_vendor_spec_capabilities0;
> };
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -180,9 +179,9 @@ static int msm_sdc_probe(struct udevice *dev)
> */
> if (core_major >= 1 && core_minor != 0x11 && core_minor != 0x12) {
> caps = readl(host->ioaddr + SDHCI_CAPABILITIES);
> caps |= SDHCI_CAN_VDD_300 | SDHCI_CAN_DO_8BIT;
> - writel(caps, host->ioaddr + SDHCI_VENDOR_SPEC_CAPABILITIES0);
> + writel(caps, host->ioaddr +
> var_info->core_vendor_spec_capabilities0);
> }
>
> ret = mmc_of_parse(dev, &plat->cfg);
> if (ret)
> @@ -243,12 +242,16 @@ static int msm_sdc_bind(struct udevice *dev)
> }
>
> static const struct msm_sdhc_variant_info msm_sdhc_mci_var = {
> .mci_removed = false,
> +
> + .core_vendor_spec_capabilities0 = 0x21c,
> };
>
> static const struct msm_sdhc_variant_info msm_sdhc_v5_var = {
> .mci_removed = true,
> +
> + .core_vendor_spec_capabilities0 = 0x11c,
> };
>
> static const struct udevice_id msm_mmc_ids[] = {
> { .compatible = "qcom,sdhci-msm-v4", .data = (ulong)&msm_sdhc_mci_var
> },
>
> --
> 2.44.0
>
Re: [PATCH 1/1] fs: fat: convert change month correctly
On Tue, 9 Apr 2024 at 20:05, Heinrich Schuchardt
wrote:
>
> The month is stored in 5 - 8. We need to shift it by 5 bits.
>
> Cf. Microsoft FAT Specification, 2005-08-30
>
> Fixes: 13c11c665320 ("fs: fat: add file attributes to struct fs_dirent")
> Signed-off-by: Heinrich Schuchardt
> ---
> fs/fat/fat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index 14e53cf2d5a..2dd9d4e72dc 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -1254,7 +1254,7 @@ out:
> static void __maybe_unused fat2rtc(u16 date, u16 time, struct rtc_time *tm)
> {
> tm->tm_mday = date & 0x1f;
> - tm->tm_mon = (date & 0x1e0) >> 4;
> + tm->tm_mon = (date & 0x1e0) >> 5;
> tm->tm_year = (date >> 9) + 1980;
>
> tm->tm_sec = (time & 0x1f) << 1;
> --
> 2.43.0
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH] efi_loader: using EFI_UNSUPPORTED for private authenticated variables
On Wed, 10 Apr 2024 at 14:29, Heinrich Schuchardt wrote: > > On 10.04.24 14:19, Weizhao Ouyang wrote: > > Improve error message for UEFI SCT tests. > > > > Signed-off-by: Weizhao Ouyang > > --- > > lib/efi_loader/efi_variable.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c > > index 2951dc78c7..e6c1219a11 100644 > > --- a/lib/efi_loader/efi_variable.c > > +++ b/lib/efi_loader/efi_variable.c > > @@ -163,6 +163,7 @@ static efi_status_t efi_variable_authenticate(const u16 > > *variable, > > break; > > default: > > /* TODO: support private authenticated variables */ > > + ret = EFI_UNSUPPORTED; > > This looks more adequate than EFI_SECURITY_VIOLATION. Thanks. > > Reviewed-by: Heinrich Schuchardt > > > goto err; > > } > > > Reviewed-by: Ilias Apalodimas
Re: [PATCH 1/1] clk: sifive: append missing \n to messages
On 4/11/24 04:37, Heinrich Schuchardt wrote:
On 11.04.24 05:13, Sean Anderson wrote:
On 2/16/24 11:35, Heinrich Schuchardt wrote:
If multiple messages are written, line-feeds improve the readability.
Fixes: c40b6df87fc0 ("clk: Add SiFive FU540 PRCI clock driver")
Signed-off-by: Heinrich Schuchardt
---
drivers/clk/analogbits/wrpll-cln28hpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/analogbits/wrpll-cln28hpc.c
b/drivers/clk/analogbits/wrpll-cln28hpc.c
index a3cb109d357..537c696b727 100644
--- a/drivers/clk/analogbits/wrpll-cln28hpc.c
+++ b/drivers/clk/analogbits/wrpll-cln28hpc.c
@@ -81,7 +81,7 @@ static int __wrpll_calc_filter_range(unsigned long
post_divr_freq)
{
if (post_divr_freq < MIN_POST_DIVR_FREQ ||
post_divr_freq > MAX_POST_DIVR_FREQ) {
- WARN(1, "%s: post-divider reference freq out of range: %lu",
+ WARN(1, "%s: post-divider reference freq out of range: %lu\n",
__func__, post_divr_freq);
return -ERANGE;
}
@@ -229,7 +229,7 @@ int wrpll_configure_for_rate(struct wrpll_cfg *c, u32
target_rate,
int range;
if (c->flags == 0) {
- WARN(1, "%s called with uninitialized PLL config", __func__);
+ WARN(1, "%s called with uninitialized PLL config\n", __func__);
return -EINVAL;
}
@@ -335,7 +335,7 @@ unsigned long wrpll_calc_output_rate(const struct wrpll_cfg
*c,
u64 n;
if (c->flags & WRPLL_FLAGS_EXT_FEEDBACK_MASK) {
- WARN(1, "external feedback mode not yet supported");
+ WARN(1, "external feedback mode not yet supported\n");
return ULONG_MAX;
}
Reviewed-by: Sean Anderson
But maybe these should be dev_dbg?
The messages look like indicating misconfiguration. So the user should see
these.
Yeah, but we already return an error. So the user will notice.
The kernel code also uses WARN() (and also lacks the line-feeds).
In the kernel there are no size restrictions, so it is fine to include messages.
--Sean
Re: [PATCH v1 1/2] sunxi: SPL SPI: Add SPI boot support for the Allwinner R528/T113 SoCs
On Thu, 11 Apr 2024 14:31:02 +1000
John Watts wrote:
Hi,
> Hi there,
>
> I've been using my own independent implementation of this patch but
> today I gave this one a test in my tree and found out it works.
>
> The code looks fine in comparison, so here's a Tested-by and a
> Reviewed-by.
>
> John.
>
> Tested-by: John Watts
> Reviewed-by: John Watts
Thanks for that. I considered this patch already for the last cycle, but
dropped it last minute, since I had some doubts and couldn't test it. I
will have a look again.
Cheers,
Andre
> On Sat, Nov 11, 2023 at 04:33:07PM +0300, Maksim Kiselev wrote:
> > R528/T113 SoCs uses the same SPI IP as the H6, also have the same clocks
> > and reset bits layout, but the CCU base is different. Another difference
> > is that the new SoCs do not have a clock divider inside. Instead of this
> > we should configure sample mode depending on input clock rate.
> >
> > The pin assignment is also different: the H6 uses PC0, the R528/T113 PC4
> > instead. This makes for a change in spi0_pinmux_setup() routine.
> >
> > This patch extends the H6/H616 #ifdef guards to also cover the R528/T113,
> > using the shared CONFIG_SUNXI_GEN_NCAT2 and CONFIG_MACH_SUN8I_R528
> > symbols. Also use CONFIG_SUNXI_GEN_NCAT2 symbol for the Kconfig
> > dependency.
> >
> > Signed-off-by: Maksim Kiselev
> > Tested-by: Sam Edwards
> > ---
> > arch/arm/mach-sunxi/Kconfig | 2 +-
> > arch/arm/mach-sunxi/spl_spi_sunxi.c | 78 +
> > 2 files changed, 58 insertions(+), 22 deletions(-)
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index a10e4c06b6..732f60821a 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -1044,7 +1044,7 @@ config SPL_STACK_R_ADDR
> >
> > config SPL_SPI_SUNXI
> > bool "Support for SPI Flash on Allwinner SoCs in SPL"
> > - depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I || MACH_SUNXI_H3_H5
> > || MACH_SUN50I || MACH_SUN8I_R40 || SUN50I_GEN_H6 || MACH_SUNIV
> > + depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I || MACH_SUNXI_H3_H5
> > || MACH_SUN50I || MACH_SUN8I_R40 || SUN50I_GEN_H6 || MACH_SUNIV ||
> > SUNXI_GEN_NCAT2
> > help
> > Enable support for SPI Flash. This option allows SPL to read from
> > sunxi SPI Flash. It uses the same method as the boot ROM, so does
> > diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c
> > b/arch/arm/mach-sunxi/spl_spi_sunxi.c
> > index c2410dd7bb..ba3b1579f0 100644
> > --- a/arch/arm/mach-sunxi/spl_spi_sunxi.c
> > +++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c
> > @@ -73,18 +73,27 @@
> > #define SUN6I_CTL_ENABLEBIT(0)
> > #define SUN6I_CTL_MASTERBIT(1)
> > #define SUN6I_CTL_SRST BIT(31)
> > +#define SUN6I_TCR_SDM BIT(13)
> > #define SUN6I_TCR_XCH BIT(31)
> >
> >
> > /*/
> >
> > -#define CCM_AHB_GATING0 (0x01C2 + 0x60)
> > -#define CCM_H6_SPI_BGR_REG (0x03001000 + 0x96c)
> > -#ifdef CONFIG_SUN50I_GEN_H6
> > -#define CCM_SPI0_CLK(0x03001000 + 0x940)
> > +#if IS_ENABLED(CONFIG_SUN50I_GEN_H6)
> > +#define CCM_BASE0x03001000
> > +#elif IS_ENABLED(CONFIG_SUNXI_GEN_NCAT2)
> > +#define CCM_BASE0x02001000
> > #else
> > -#define CCM_SPI0_CLK(0x01C2 + 0xA0)
> > +#define CCM_BASE0x01C2
> > #endif
> > -#define SUN6I_BUS_SOFT_RST_REG0 (0x01C2 + 0x2C0)
> > +
> > +#define CCM_AHB_GATING0 (CCM_BASE + 0x60)
> > +#define CCM_H6_SPI_BGR_REG (CCM_BASE + 0x96c)
> > +#if IS_ENABLED(CONFIG_SUN50I_GEN_H6) || IS_ENABLED(CONFIG_SUNXI_GEN_NCAT2)
> > +#define CCM_SPI0_CLK(CCM_BASE + 0x940)
> > +#else
> > +#define CCM_SPI0_CLK(CCM_BASE + 0xA0)
> > +#endif
> > +#define SUN6I_BUS_SOFT_RST_REG0 (CCM_BASE + 0x2C0)
> >
> > #define AHB_RESET_SPI0_SHIFT20
> > #define AHB_GATE_OFFSET_SPI020
> > @@ -102,17 +111,22 @@
> > */
> > static void spi0_pinmux_setup(unsigned int pin_function)
> > {
> > - /* All chips use PC0 and PC2. */
> > - sunxi_gpio_set_cfgpin(SUNXI_GPC(0), pin_function);
> > + /* All chips use PC2. And all chips use PC0, except R528/T113 */
> > + if (!IS_ENABLED(CONFIG_MACH_SUN8I_R528))
> > + sunxi_gpio_set_cfgpin(SUNXI_GPC(0), pin_function);
> > +
> > sunxi_gpio_set_cfgpin(SUNXI_GPC(2), pin_function);
> >
> > - /* All chips except H6 and H616 use PC1. */
> > - if (!IS_ENABLED(CONFIG_SUN50I_GEN_H6))
> > + /* All chips except H6/H616/R528/T113 use PC1. */
> > + if (!IS_ENABLED(CONFIG_SUN50I_GEN_H6) &&
> > + !IS_ENABLED(CONFIG_MACH_SUN8I_R528))
> > sunxi_gpio_set_cfgpin(SUNXI_GPC(1), pin_function);
> >
> > - if (IS_ENABLED(CONFIG_MACH_SUN50I_H6))
> > + if (IS_ENABLED(CONFIG_MACH_SUN50I_H6) ||
> > + IS_ENABLED(CON
Re: [PATCH] MAINTAINERS: add Qualcomm mailing list
On Tue, 09 Apr 2024 17:02:51 +0200, Caleb Connolly wrote: > Add the newly created u-boot-qcom mailing list to keep track of Qualcomm > patches. > > Additionally, link to the U-Boot Snapdragon custodian tree. > > Applied, thanks! [1/1] MAINTAINERS: add Qualcomm mailing list commit: b46a2aec4cd5937ef6cd77601ac02ac0fcfdb4c4 Best regards, -- Caleb Connolly
Re: [PATCH v2] mach-snapdragon: Allow other board vendors apart from Qcom
On Thu, 11 Apr 2024 18:07:26 +0530, Sumit Garg wrote: > Qcom SoCs derived boards can come from various OEMs/ODMs and not just > Qcom itself. So allow CONFIG_SYS_VENDOR to be set correctly > corressponding to the actual board vendor. > > Applied, thanks! [1/1] mach-snapdragon: Allow other board vendors apart from Qcom commit: 68f98096c09734257e5218897500a7279c6c4ca2 Best regards, -- Caleb Connolly
Re: [PATCH 0/7] qcom: mmc fixes and sdm845 support
On Tue, 09 Apr 2024 20:02:59 +0200, Caleb Connolly wrote: > This series does some long overdue cleanup to the msm_sdhci driver, > fixes v5 support, and adds the necessary clock configuration to get the > sdcard up and running on the RB3. > Applied, thanks! [1/7] mmc: msm_sdhci: correct vendor_spec_cap0 register for v5 commit: a737d8962cae2a37634bf0fe9f2b6907f7a047a7 [2/7] mmc: msm_sdhci: use modern DT handling commit: 5fc028897fb16abd0823b545b6f7b8a1df54d4dd [3/7] mmc: msm_sdhci: print core version commit: 0dc3cd3e5e501a575d0579b78b238bdd1b2a8274 [4/7] mmc: msm_sdhci: use a more sensible default clock rate commit: 6d327bca5ac7112f168fef8f2284e67211637e6c [5/7] clk/qcom: sdm845: enable SDCC2 core clock commit: da74cd018493b5a1f6bb8785bf6cc7754e42dfd8 [6/7] pinctrl: qcom: sdm845: add special pin names commit: 691e3cfc645504397a5f0da7afd2db96e4445f26 [7/7] dts: sdm845-db845c-u-boot: adjust MMC clocks commit: 17cfde60a2fcaf3365fdef7755a825aeddc6179a Best regards, -- Caleb Connolly
Re: [PATCH 0/4] qcom: clock drivers for qcm2290/sm6115/sm8250
On Mon, 08 Apr 2024 15:06:48 +0200, Caleb Connolly wrote: > Introduce clock drivers for three new SoCs and enable them. This allows > for configuring UART and USB on all three as well as controlling > relevant resets and power domains. > > Applied, thanks! [1/4] clk/qcom: add driver for qcm2290 GCC commit: 7a8efc12ddf7ad2345725821377aa90e1972f366 [2/4] clk/qcom: add driver for sm6115 GCC commit: 5f38a7b36468c3a78570822676ccb8d0057f33b1 [3/4] clk/qcom: add driver for sm8250 GCC commit: 45271bce0478276158ebbe8e0113b9a887f88ae9 [4/4] qcom_defconfig: enable clocks for qcm2290/sm6115/sm8250 commit: 642ad0402c0654841c9096e2fadc753e5bb86348 Best regards, -- Caleb Connolly
Re: [PATCH v2 0/3] qcom: support SPMI buttons on SM8550 and SM8650
On Wed, 10 Apr 2024 17:59:42 +0200, Neil Armstrong wrote: > First add PMIC gpio variant on pm8550-gpio, then rework the > qcom-pmic button driver to support data structs for each PMIC > variant and finally add the data for the pmk8350 button configs. > > Applied, thanks! [1/3] gpio: qcom_pmic_gpio: add support for pm8550-gpio commit: 21e19a823aba68fe585ab48ff89c1414554ac929 [2/3] button: qcom-pmic: move node name checks to btn_data struct commit: 28b264674fdd0b50a396a22115e097dae47945fa [3/3] button: qcom-pmic: add support for pmk8350 button configs commit: 43923bfb5040c245645aa91bc000b92117c587dd Best regards, -- Caleb Connolly
Re: [PATCH 0/3] qcom: add pinctrl driver for SM8550 and SM8650
On Fri, 05 Apr 2024 10:15:09 +0200, Neil Armstrong wrote: > Add pinctrl driver for the TLMM block found in the SM8550 & SM8650 SoCs. > > This driver only handles the gpio and qup debug uart pinmux, and makes sure > the pinconf applies on SDC2 pins. > > Finally enable both drivers in the Qualcomm defconfig > > [...] Applied, thanks! [1/3] pinctrl: qcom: Add SM8550 pinctrl driver commit: 225c991b41a2255054dfcafb7667979c6a88bffd [2/3] pinctrl: qcom: Add SM8650 pinctrl driver commit: b0725abe0ae5c41c03dfc9af921120fe501f07f5 [3/3] qcom_defconfig: enable SM8550 & SM8650 pinctrl driver commit: c32ab322d04eed52d5ad30b19d45fe041c19a250 Best regards, -- Caleb Connolly
Re: [PATCH v2 0/2] phy: qcom: add support for the Qualcomm Synopsys eUSB2 PHY
On Wed, 10 Apr 2024 18:01:11 +0200, Neil Armstrong wrote: > Add support for the new Qualcomm Synopsys eUSB2 PHY found in the > SM8550 and SM8650 SoCs. > > Finally enable the driver in the Qualcomm defconfig. > > Applied, thanks! [1/2] phy: qcom: add Synopsys eUSB2 PHY driver commit: 01d9217273df37c5150bab45018b0ee54cb1f30e [2/2] qcom_defconfig: enable the Qualcomm Synopsys eUSB2 PHY driver commit: 1e6adb446297fdaea5561c001e58cc9f2cb7a743 Best regards, -- Caleb Connolly
Re: [PATCH 0/4] smpi: msm: fix version 5 and add version 7 support
On 05/04/2024 10:21, Neil Armstrong wrote: First, fix version 5 support by using the right ch_offset in then msm_spmi_write() reg accesses. Then: - properly format command by importing helpers from Linux driver and use a switch/case to handle all versions in msm_spmi_write/read() command. - handle peripheral ownership by poking into the cnfg registers and mark periperal as read-only when the owner id doesn't match - finally add version 7 defines SPMI Arbiter Version 7 is present on SM8450, SM8550 and SM8650 SoC. Signed-off-by: Neil Armstrong Acked-by: Caleb Connolly Mateusz: do you prefer to take these? I'm just as happy to take then through the qcom tree. Kind regards, --- Neil Armstrong (4): spmi: msm: fix version 5 support spmi: msm: properly format command spmi: msm: handle peripheral ownership spmi: msm: support controller version 7 drivers/spmi/spmi-msm.c | 148 +--- 1 file changed, 116 insertions(+), 32 deletions(-) --- base-commit: f0e6aba1218bca578605697eed8aa94582bf57bb change-id: 20240404-topic-sm8x50-spmi-fixes-aec9b392813b Best regards, -- // Caleb (they/them)
Re: [PATCH 0/2] sunxi: Support UART1 and UART2 on the T113
On Thu, 11 Apr 2024 15:14:14 +1000 John Watts wrote: Hi John, > The T113 supports UART1 and UART2 on PG and PD pins respectively. > Add support for these in U-Boot so we can use them. So those bits are just for the *debug* UARTs. Traditionally this is UART0, with some particular pinmux, sometimes UART2 on older SoCs. So is there a board that uses those pins for a debug console? I want to avoid making this code even messier than it already is, without good reasons. Also please note that I tried to clean this up here: https://patchwork.ozlabs.org/project/uboot/patch/20240103001239.17482-20-andre.przyw...@arm.com/ > Note: I'm not entirely sure if the PD pins should be default, they > overlap with the LCD pins. I am however using this on a real board. Is this a custom board? Could you consider using UART0 for debug then? This one doesn't support RTS/CTS, so you do not waste the more capable UARTs for debug. Cheers, Andre > Signed-off-by: John Watts > --- > John Watts (2): > sunxi: Support UART1 on the T113 > sunxi: Support UART2 on the T113 > > arch/arm/mach-sunxi/board.c | 9 +++-- > include/sunxi_gpio.h| 1 + > 2 files changed, 8 insertions(+), 2 deletions(-) > --- > base-commit: 777c28460947371ada40868dc994dfe8537d7115 > change-id: 20240411-t113serial-a6e9ca8d8848 > > Best regards,
[PATCH v2] mach-snapdragon: Allow other board vendors apart from Qcom
Qcom SoCs derived boards can come from various OEMs/ODMs and not just Qcom itself. So allow CONFIG_SYS_VENDOR to be set correctly corressponding to the actual board vendor. Suggested-by: Stephan Gerhold Reviewed-by: Caleb Connolly Signed-off-by: Sumit Garg --- Changes in v2: - Retained default vendor being "qualcomm". - Collected review tag. arch/arm/mach-snapdragon/Kconfig | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig index 96e44e2c549..536960b83c3 100644 --- a/arch/arm/mach-snapdragon/Kconfig +++ b/arch/arm/mach-snapdragon/Kconfig @@ -4,7 +4,12 @@ config SYS_SOC default "snapdragon" config SYS_VENDOR + string "Snapdragon board vendor" default "qualcomm" + help + Allows to specify vendor for the Snapdragon SoCs based boards. + Based on this option board// + will be used as the custom board directory. config SYS_MALLOC_F_LEN default 0x2000 @@ -19,12 +24,11 @@ config LNX_KRNL_IMG_TEXT_OFFSET_BASE default 0x8000 config SYS_BOARD - string "Qualcomm custom board" + string "Snapdragon SoCs based board" help - The Dragonboard 410c and 820c have additional board init - code that isn't shared with other Qualcomm boards. - Based on this option board/qualcomm/ will - be used. + Allows to specify the Snapdragon SoCs based board name. + Based on this option board// + will be used as the custom board directory. config SYS_CONFIG_NAME string "Board configuration name" -- 2.34.1
Re: [PATCH] mach-snapdragon: Allow other board vendors apart from Qcom
Hi Sumit, On 11/04/2024 13:51, Sumit Garg wrote: Qcom SoCs derived boards can come from various OEMs/ODMs and not just Qcom itself. So allow CONFIG_SYS_VENDOR to be set correctly corressponding to the actual board vendor. Suggested-by: Stephan Gerhold Signed-off-by: Sumit Garg --- arch/arm/mach-snapdragon/Kconfig | 15 +-- configs/dragonboard410c_defconfig | 1 + configs/dragonboard820c_defconfig | 1 + 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig index 96e44e2c549..4615a140d0d 100644 --- a/arch/arm/mach-snapdragon/Kconfig +++ b/arch/arm/mach-snapdragon/Kconfig @@ -4,7 +4,11 @@ config SYS_SOC default "snapdragon" config SYS_VENDOR - default "qualcomm" Can you keep the default rather than adding it to the defconfig? With that Reviewed-by: Caleb Connolly + string "Snapdragon board vendor" + help + Allows to specify vendor for the Snapdragon SoCs based boards. + Based on this option board// + will be used as the custom board directory. config SYS_MALLOC_F_LEN default 0x2000 @@ -19,12 +23,11 @@ config LNX_KRNL_IMG_TEXT_OFFSET_BASE default 0x8000 config SYS_BOARD - string "Qualcomm custom board" + string "Snapdragon SoCs based board" help - The Dragonboard 410c and 820c have additional board init - code that isn't shared with other Qualcomm boards. - Based on this option board/qualcomm/ will - be used. + Allows to specify the Snapdragon SoCs based board name. + Based on this option board// + will be used as the custom board directory. config SYS_CONFIG_NAME string "Board configuration name" diff --git a/configs/dragonboard410c_defconfig b/configs/dragonboard410c_defconfig index 260a8349d3b..3b6f50307a3 100644 --- a/configs/dragonboard410c_defconfig +++ b/configs/dragonboard410c_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_SYS_VENDOR="qualcomm" CONFIG_SYS_BOARD="dragonboard410c" CONFIG_COUNTER_FREQUENCY=1900 CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y diff --git a/configs/dragonboard820c_defconfig b/configs/dragonboard820c_defconfig index ebc80eb2a46..a795497ef5d 100644 --- a/configs/dragonboard820c_defconfig +++ b/configs/dragonboard820c_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_SYS_VENDOR="qualcomm" CONFIG_SYS_BOARD="dragonboard820c" CONFIG_COUNTER_FREQUENCY=1900 CONFIG_ARCH_SNAPDRAGON=y -- // Caleb (they/them)
Re: [PATCH v2 0/4] qcom: pinctrl drivers for qcm2290/sm6115/sm8250
On Wed, 10 Apr 2024 at 23:23, Caleb Connolly wrote: > > Introduce pinctrl drivers for three new SoCs and enable them. > > Signed-off-by: Caleb Connolly > --- > Changes in v2: > - Fix a few formatting issues > - Link to v1: > https://lore.kernel.org/r/20240408-b4-qcom-rbx-soc-v1-0-900db37b8...@linaro.org > > --- > Caleb Connolly (4): > pinctrl: qcom: add qcm2290 pinctrl driver > pinctrl: qcom: add sm6115 pinctrl driver > pinctrl: qcom: add sm8250 pinctrl driver > qcom_defconfig: enable pinctrl for new qcm2290/sm6115/sm8250 > Acked-by: Sumit Garg -Sumit > configs/qcom_defconfig | 3 + > drivers/pinctrl/qcom/Kconfig | 21 > drivers/pinctrl/qcom/Makefile | 3 + > drivers/pinctrl/qcom/pinctrl-qcm2290.c | 70 > drivers/pinctrl/qcom/pinctrl-sm6115.c | 200 > + > drivers/pinctrl/qcom/pinctrl-sm8250.c | 99 > 6 files changed, 396 insertions(+) > --- > change-id: 20240408-b4-qcom-rbx-soc-44ee99c8b799 > base-commit: 4ba549b0a4e67c563785ab144edf47e108b34822 > > // Caleb (they/them) >
Re: [PATCH v2 0/2] phy: qcom: add support for the Qualcomm Synopsys eUSB2 PHY
On Wed, 10 Apr 2024 at 21:31, Neil Armstrong wrote: > > Add support for the new Qualcomm Synopsys eUSB2 PHY found in the > SM8550 and SM8650 SoCs. > > Finally enable the driver in the Qualcomm defconfig. > > Signed-off-by: Neil Armstrong > --- > Changes in v2: > - fixed driver build failure due to missin } > - Link to v1: > https://lore.kernel.org/r/20240405-topic-sm8x50-usb-phy-v1-0-8a8604bf8...@linaro.org > > --- > Neil Armstrong (2): > phy: qcom: add Synopsys eUSB2 PHY driver > qcom_defconfig: enable the Qualcomm Synopsys eUSB2 PHY driver > Acked-by: Sumit Garg -Sumit > configs/qcom_defconfig | 1 + > drivers/phy/qcom/Kconfig | 8 + > drivers/phy/qcom/Makefile | 1 + > drivers/phy/qcom/phy-qcom-snps-eusb2.c | 366 > + > 4 files changed, 376 insertions(+) > --- > base-commit: f0e6aba1218bca578605697eed8aa94582bf57bb > change-id: 20240404-topic-sm8x50-usb-phy-d09a98f72d1b > > Best regards, > -- > Neil Armstrong >
[PATCH] mach-snapdragon: Allow other board vendors apart from Qcom
Qcom SoCs derived boards can come from various OEMs/ODMs and not just Qcom itself. So allow CONFIG_SYS_VENDOR to be set correctly corressponding to the actual board vendor. Suggested-by: Stephan Gerhold Signed-off-by: Sumit Garg --- arch/arm/mach-snapdragon/Kconfig | 15 +-- configs/dragonboard410c_defconfig | 1 + configs/dragonboard820c_defconfig | 1 + 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig index 96e44e2c549..4615a140d0d 100644 --- a/arch/arm/mach-snapdragon/Kconfig +++ b/arch/arm/mach-snapdragon/Kconfig @@ -4,7 +4,11 @@ config SYS_SOC default "snapdragon" config SYS_VENDOR - default "qualcomm" + string "Snapdragon board vendor" + help + Allows to specify vendor for the Snapdragon SoCs based boards. + Based on this option board// + will be used as the custom board directory. config SYS_MALLOC_F_LEN default 0x2000 @@ -19,12 +23,11 @@ config LNX_KRNL_IMG_TEXT_OFFSET_BASE default 0x8000 config SYS_BOARD - string "Qualcomm custom board" + string "Snapdragon SoCs based board" help - The Dragonboard 410c and 820c have additional board init - code that isn't shared with other Qualcomm boards. - Based on this option board/qualcomm/ will - be used. + Allows to specify the Snapdragon SoCs based board name. + Based on this option board// + will be used as the custom board directory. config SYS_CONFIG_NAME string "Board configuration name" diff --git a/configs/dragonboard410c_defconfig b/configs/dragonboard410c_defconfig index 260a8349d3b..3b6f50307a3 100644 --- a/configs/dragonboard410c_defconfig +++ b/configs/dragonboard410c_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_SYS_VENDOR="qualcomm" CONFIG_SYS_BOARD="dragonboard410c" CONFIG_COUNTER_FREQUENCY=1900 CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y diff --git a/configs/dragonboard820c_defconfig b/configs/dragonboard820c_defconfig index ebc80eb2a46..a795497ef5d 100644 --- a/configs/dragonboard820c_defconfig +++ b/configs/dragonboard820c_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_SYS_VENDOR="qualcomm" CONFIG_SYS_BOARD="dragonboard820c" CONFIG_COUNTER_FREQUENCY=1900 CONFIG_ARCH_SNAPDRAGON=y -- 2.34.1
Re: [PATCH v4] cmd: bootm: add ELF file support
On 11.04.24 10:57, Maxim Moskalets wrote:
From: Maxim Moskalets
Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.
Signed-off-by: Maxim Moskalets
---
boot/bootm_os.c | 23 +++
boot/image-fit.c | 3 ++-
boot/image.c | 3 +++
include/image.h | 1 +
4 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index ccde72d22c..f6b46cf57f 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -395,6 +395,26 @@ static int do_bootm_qnxelf(int flag, struct bootm_info
*bmi)
}
#endif
+#if defined(CONFIG_CMD_ELF)
+static int do_bootm_elf(int flag, struct bootm_info *bmi)
+{
+ struct bootm_headers *images = bmi->images;
+ char *local_args[2] = {NULL};
+ char str[19] = ""; /* "0x" + 16 digits + "\0" */
+
+ if (flag != BOOTM_STATE_OS_GO)
+ return 0;
+
+ snprintf(str, ARRAY_SIZE(str), "0x%lx", images->ep); /* write
entry-point into string */
+ local_args[0] = bmi->argv[0];
+ local_args[1] = str;/* and provide it via the arguments */
+
+ do_bootelf(NULL, 0, 2, local_args);
Booting should be possible without having a command line interface.
See commit 7c4647b8fb44 (Merge patch series "Complete decoupling of
bootm logic from commands")
The functionality to boot an ELF binary should be carved out into
library function. The interface should not use argv[], argc.
Best regards
Heinrich
+
+ return 1;
+}
+#endif
+
#ifdef CONFIG_INTEGRITY
static int do_bootm_integrity(int flag, struct bootm_info *bmi)
{
@@ -536,6 +556,9 @@ static boot_os_fn *boot_os[] = {
#ifdef CONFIG_BOOTM_EFI
[IH_OS_EFI] = do_bootm_efi,
#endif
+#if defined(CONFIG_CMD_ELF)
+ [IH_OS_ELF] = do_bootm_elf,
+#endif
};
/* Allow for arch specific config before we boot */
diff --git a/boot/image-fit.c b/boot/image-fit.c
index 89e377563c..0419bef6d2 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -2180,7 +2180,8 @@ int fit_image_load(struct bootm_headers *images, ulong
addr,
fit_image_check_os(fit, noffset, IH_OS_TEE) ||
fit_image_check_os(fit, noffset, IH_OS_OPENRTOS) ||
fit_image_check_os(fit, noffset, IH_OS_EFI) ||
- fit_image_check_os(fit, noffset, IH_OS_VXWORKS);
+ fit_image_check_os(fit, noffset, IH_OS_VXWORKS) ||
+ fit_image_check_os(fit, noffset, IH_OS_ELF);
/*
* If either of the checks fail, we should report an error, but
diff --git a/boot/image.c b/boot/image.c
index 073931cd7a..5b88d6808c 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -134,6 +134,9 @@ static const table_entry_t uimage_os[] = {
#endif
{ IH_OS_OPENSBI, "opensbi","RISC-V OpenSBI", },
{ IH_OS_EFI, "efi","EFI Firmware" },
+#ifdef CONFIG_CMD_ELF
+ { IH_OS_ELF, "elf","ELF Image" },
+#endif
{ -1, "", "", },
};
diff --git a/include/image.h b/include/image.h
index 21de70f0c9..9a40bca22c 100644
--- a/include/image.h
+++ b/include/image.h
@@ -100,6 +100,7 @@ enum {
IH_OS_TEE, /* Trusted Execution Environment */
IH_OS_OPENSBI, /* RISC-V OpenSBI */
IH_OS_EFI, /* EFI Firmware (e.g. GRUB2) */
+ IH_OS_ELF, /* ELF Image (e.g. seL4) */
IH_OS_COUNT,
};
[PATCH] riscv: andesv5: Set default cache line size to 64-bytes
The instruction and data cache line sizes of Andes core are 64-byte. Select SYS_CACHE_SHIFT_6 for RISCV_NDS so the SYS_CACHELINE_SIZE is enabled with a default value. Signed-off-by: Yu Chien Peter Lin --- arch/riscv/cpu/andesv5/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/cpu/andesv5/Kconfig b/arch/riscv/cpu/andesv5/Kconfig index f311291aed..e3efb0de8f 100644 --- a/arch/riscv/cpu/andesv5/Kconfig +++ b/arch/riscv/cpu/andesv5/Kconfig @@ -1,6 +1,7 @@ config RISCV_NDS bool select ARCH_EARLY_INIT_R + select SYS_CACHE_SHIFT_6 imply CPU imply CPU_RISCV imply RISCV_TIMER if (RISCV_SMODE || SPL_RISCV_SMODE) -- 2.34.1
[PATCH v4] cmd: bootm: add ELF file support
From: Maxim Moskalets
Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.
Signed-off-by: Maxim Moskalets
---
boot/bootm_os.c | 23 +++
boot/image-fit.c | 3 ++-
boot/image.c | 3 +++
include/image.h | 1 +
4 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index ccde72d22c..f6b46cf57f 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -395,6 +395,26 @@ static int do_bootm_qnxelf(int flag, struct bootm_info
*bmi)
}
#endif
+#if defined(CONFIG_CMD_ELF)
+static int do_bootm_elf(int flag, struct bootm_info *bmi)
+{
+ struct bootm_headers *images = bmi->images;
+ char *local_args[2] = {NULL};
+ char str[19] = ""; /* "0x" + 16 digits + "\0" */
+
+ if (flag != BOOTM_STATE_OS_GO)
+ return 0;
+
+ snprintf(str, ARRAY_SIZE(str), "0x%lx", images->ep); /* write
entry-point into string */
+ local_args[0] = bmi->argv[0];
+ local_args[1] = str;/* and provide it via the arguments */
+
+ do_bootelf(NULL, 0, 2, local_args);
+
+ return 1;
+}
+#endif
+
#ifdef CONFIG_INTEGRITY
static int do_bootm_integrity(int flag, struct bootm_info *bmi)
{
@@ -536,6 +556,9 @@ static boot_os_fn *boot_os[] = {
#ifdef CONFIG_BOOTM_EFI
[IH_OS_EFI] = do_bootm_efi,
#endif
+#if defined(CONFIG_CMD_ELF)
+ [IH_OS_ELF] = do_bootm_elf,
+#endif
};
/* Allow for arch specific config before we boot */
diff --git a/boot/image-fit.c b/boot/image-fit.c
index 89e377563c..0419bef6d2 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -2180,7 +2180,8 @@ int fit_image_load(struct bootm_headers *images, ulong
addr,
fit_image_check_os(fit, noffset, IH_OS_TEE) ||
fit_image_check_os(fit, noffset, IH_OS_OPENRTOS) ||
fit_image_check_os(fit, noffset, IH_OS_EFI) ||
- fit_image_check_os(fit, noffset, IH_OS_VXWORKS);
+ fit_image_check_os(fit, noffset, IH_OS_VXWORKS) ||
+ fit_image_check_os(fit, noffset, IH_OS_ELF);
/*
* If either of the checks fail, we should report an error, but
diff --git a/boot/image.c b/boot/image.c
index 073931cd7a..5b88d6808c 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -134,6 +134,9 @@ static const table_entry_t uimage_os[] = {
#endif
{ IH_OS_OPENSBI, "opensbi", "RISC-V OpenSBI", },
{ IH_OS_EFI, "efi", "EFI Firmware" },
+#ifdef CONFIG_CMD_ELF
+ { IH_OS_ELF, "elf", "ELF Image" },
+#endif
{ -1, "", "", },
};
diff --git a/include/image.h b/include/image.h
index 21de70f0c9..9a40bca22c 100644
--- a/include/image.h
+++ b/include/image.h
@@ -100,6 +100,7 @@ enum {
IH_OS_TEE, /* Trusted Execution Environment */
IH_OS_OPENSBI, /* RISC-V OpenSBI */
IH_OS_EFI, /* EFI Firmware (e.g. GRUB2) */
+ IH_OS_ELF, /* ELF Image (e.g. seL4) */
IH_OS_COUNT,
};
--
2.39.2
Re: [PATCH v3] cmd: bootm: add ELF file support
Hi Maxim,
On 4/11/24 10:32, Maxim Moskalets wrote:
From: Maxim Moskalets
Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.
Signed-off-by: Maxim Moskalets
---
boot/bootm_os.c | 24
boot/image-fit.c | 3 ++-
boot/image.c | 3 +++
include/image.h | 1 +
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index ccde72d22c..1c92b8149c 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -395,6 +395,27 @@ static int do_bootm_qnxelf(int flag, struct bootm_info
*bmi)
}
#endif
+#if defined(CONFIG_CMD_ELF)
+static int do_bootm_elf(int flag, struct bootm_info *bmi)
+{
+ struct bootm_headers *images = bmi->images;
+ char *local_args[2] = {NULL};
+ char str[19] = ""; /* "0x" + 16 digits + "\0" */
+
+ if (flag != BOOTM_STATE_OS_GO)
+ return 0;
+
+ snprintf(str, sizeof str, "0x%lx", images->ep); /* write entry-point
into string */
While sizeof str does return the same as the number of elements in the
array, it's only because it's a char array and thus its elements are all
1B, any other type would have returned something incorrect.
I recommend using ARRAY_SIZE(str) instead, which is the way to know the
number of elements in the array (dividing the size of the array by the
size of an element in the array).
Cheers,
Quentin
Re: [PATCH 1/1] clk: sifive: append missing \n to messages
On 11.04.24 05:13, Sean Anderson wrote:
On 2/16/24 11:35, Heinrich Schuchardt wrote:
If multiple messages are written, line-feeds improve the readability.
Fixes: c40b6df87fc0 ("clk: Add SiFive FU540 PRCI clock driver")
Signed-off-by: Heinrich Schuchardt
---
drivers/clk/analogbits/wrpll-cln28hpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/analogbits/wrpll-cln28hpc.c
b/drivers/clk/analogbits/wrpll-cln28hpc.c
index a3cb109d357..537c696b727 100644
--- a/drivers/clk/analogbits/wrpll-cln28hpc.c
+++ b/drivers/clk/analogbits/wrpll-cln28hpc.c
@@ -81,7 +81,7 @@ static int __wrpll_calc_filter_range(unsigned long
post_divr_freq)
{
if (post_divr_freq < MIN_POST_DIVR_FREQ ||
post_divr_freq > MAX_POST_DIVR_FREQ) {
- WARN(1, "%s: post-divider reference freq out of range: %lu",
+ WARN(1, "%s: post-divider reference freq out of range: %lu\n",
__func__, post_divr_freq);
return -ERANGE;
}
@@ -229,7 +229,7 @@ int wrpll_configure_for_rate(struct wrpll_cfg *c,
u32 target_rate,
int range;
if (c->flags == 0) {
- WARN(1, "%s called with uninitialized PLL config", __func__);
+ WARN(1, "%s called with uninitialized PLL config\n", __func__);
return -EINVAL;
}
@@ -335,7 +335,7 @@ unsigned long wrpll_calc_output_rate(const struct
wrpll_cfg *c,
u64 n;
if (c->flags & WRPLL_FLAGS_EXT_FEEDBACK_MASK) {
- WARN(1, "external feedback mode not yet supported");
+ WARN(1, "external feedback mode not yet supported\n");
return ULONG_MAX;
}
Reviewed-by: Sean Anderson
But maybe these should be dev_dbg?
The messages look like indicating misconfiguration. So the user should
see these.
The kernel code also uses WARN() (and also lacks the line-feeds).
CCing Paul as the Linux maintainer and author.
Best regards
Heinrich
Re: [PATCH 1/1] efi_loader: sanitize efi_tcg2_final_events_table definition
On Thu, 11 Apr 2024 at 00:50, Heinrich Schuchardt
wrote:
>
> The length of the variable name typically is not 1.
> Neither the length of the variable name nor the size of the appended
> data is known in the include.
>
> * Define the size of element variable_name as variable.
> * Remove the unusable element variable_data.
>
> Addresses-Coverity-ID: 467400 Out-of-bounds read
> Signed-off-by: Heinrich Schuchardt
> ---
> include/efi_tcg2.h | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
> index b21c5cb3dd6..a75b5a35b6e 100644
> --- a/include/efi_tcg2.h
> +++ b/include/efi_tcg2.h
> @@ -150,16 +150,14 @@ struct efi_tcg2_final_events_table {
> * the variable.
> * @variable_data_length: The size of the variable data.
> * @unicode_name: The CHAR16 unicode name of the variable
> - * without NULL-terminator.
> - * @variable_data: The data parameter of the efi variable
> - * in the GetVariable() API.
> + * without NULL-terminator followed by data.
> */
> struct efi_tcg2_uefi_variable_data {
> efi_guid_t variable_name;
> u64 unicode_name_length;
> u64 variable_data_length;
> - u16 unicode_name[1];
> - u8 variable_data[1];
> + u16 unicode_name[];
> + // u8 variable_data[];
> };
>
> /**
> --
> 2.43.0
>
Reviewed-by: Ilias Apalodimas
[PATCH v3] cmd: bootm: add ELF file support
From: Maxim Moskalets
Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.
Signed-off-by: Maxim Moskalets
---
boot/bootm_os.c | 24
boot/image-fit.c | 3 ++-
boot/image.c | 3 +++
include/image.h | 1 +
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index ccde72d22c..1c92b8149c 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -395,6 +395,27 @@ static int do_bootm_qnxelf(int flag, struct bootm_info
*bmi)
}
#endif
+#if defined(CONFIG_CMD_ELF)
+static int do_bootm_elf(int flag, struct bootm_info *bmi)
+{
+ struct bootm_headers *images = bmi->images;
+ char *local_args[2] = {NULL};
+ char str[19] = ""; /* "0x" + 16 digits + "\0" */
+
+ if (flag != BOOTM_STATE_OS_GO)
+ return 0;
+
+ snprintf(str, sizeof str, "0x%lx", images->ep); /* write entry-point
into string */
+ local_args[0] = bmi->argv[0];
+ local_args[1] = str;/* and provide it via the arguments */
+
+ do_bootelf(NULL, 0, 2, local_args);
+
+ return 1;
+}
+#endif
+
#ifdef CONFIG_INTEGRITY
static int do_bootm_integrity(int flag, struct bootm_info *bmi)
{
@@ -536,6 +557,9 @@ static boot_os_fn *boot_os[] = {
#ifdef CONFIG_BOOTM_EFI
[IH_OS_EFI] = do_bootm_efi,
#endif
+#if defined(CONFIG_CMD_ELF)
+ [IH_OS_ELF] = do_bootm_elf,
+#endif
};
/* Allow for arch specific config before we boot */
diff --git a/boot/image-fit.c b/boot/image-fit.c
index 89e377563c..0419bef6d2 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -2180,7 +2180,8 @@ int fit_image_load(struct bootm_headers *images, ulong
addr,
fit_image_check_os(fit, noffset, IH_OS_TEE) ||
fit_image_check_os(fit, noffset, IH_OS_OPENRTOS) ||
fit_image_check_os(fit, noffset, IH_OS_EFI) ||
- fit_image_check_os(fit, noffset, IH_OS_VXWORKS);
+ fit_image_check_os(fit, noffset, IH_OS_VXWORKS) ||
+ fit_image_check_os(fit, noffset, IH_OS_ELF);
/*
* If either of the checks fail, we should report an error, but
diff --git a/boot/image.c b/boot/image.c
index 073931cd7a..5b88d6808c 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -134,6 +134,9 @@ static const table_entry_t uimage_os[] = {
#endif
{ IH_OS_OPENSBI, "opensbi", "RISC-V OpenSBI", },
{ IH_OS_EFI, "efi", "EFI Firmware" },
+#ifdef CONFIG_CMD_ELF
+ { IH_OS_ELF, "elf", "ELF Image" },
+#endif
{ -1, "", "", },
};
diff --git a/include/image.h b/include/image.h
index 21de70f0c9..9a40bca22c 100644
--- a/include/image.h
+++ b/include/image.h
@@ -100,6 +100,7 @@ enum {
IH_OS_TEE, /* Trusted Execution Environment */
IH_OS_OPENSBI, /* RISC-V OpenSBI */
IH_OS_EFI, /* EFI Firmware (e.g. GRUB2) */
+ IH_OS_ELF, /* ELF Image (e.g. seL4) */
IH_OS_COUNT,
};
--
2.39.2
[PATCH v2] cmd: bootm: add ELF file support
From: Maxim Moskalets
Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.
Signed-off-by: Maxim Moskalets
---
boot/bootm_os.c | 24
boot/image-fit.c | 3 ++-
boot/image.c | 3 +++
include/image.h | 1 +
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index ccde72d22c..1c92b8149c 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -395,6 +395,27 @@ static int do_bootm_qnxelf(int flag, struct bootm_info
*bmi)
}
#endif
+#if defined(CONFIG_CMD_ELF)
+static int do_bootm_elf(int flag, struct bootm_info *bmi)
+{
+ struct bootm_headers *images = bmi->images;
+ char *local_args[2] = {NULL};
+ char str[19] = ""; /* "0x" + 16 digits + "\0" */
+
+ if (flag != BOOTM_STATE_OS_GO)
+ return 0;
+
+ snprintf(str, sizeof str, "0x%lx", images->ep); /* write entry-point
into string */
+ str[18] = '\0';
+ local_args[0] = bmi->argv[0];
+ local_args[1] = str;/* and provide it via the arguments */
+
+ do_bootelf(NULL, 0, 2, local_args);
+
+ return 1;
+}
+#endif
+
#ifdef CONFIG_INTEGRITY
static int do_bootm_integrity(int flag, struct bootm_info *bmi)
{
@@ -536,6 +557,9 @@ static boot_os_fn *boot_os[] = {
#ifdef CONFIG_BOOTM_EFI
[IH_OS_EFI] = do_bootm_efi,
#endif
+#if defined(CONFIG_CMD_ELF)
+ [IH_OS_ELF] = do_bootm_elf,
+#endif
};
/* Allow for arch specific config before we boot */
diff --git a/boot/image-fit.c b/boot/image-fit.c
index 89e377563c..0419bef6d2 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -2180,7 +2180,8 @@ int fit_image_load(struct bootm_headers *images, ulong
addr,
fit_image_check_os(fit, noffset, IH_OS_TEE) ||
fit_image_check_os(fit, noffset, IH_OS_OPENRTOS) ||
fit_image_check_os(fit, noffset, IH_OS_EFI) ||
- fit_image_check_os(fit, noffset, IH_OS_VXWORKS);
+ fit_image_check_os(fit, noffset, IH_OS_VXWORKS) ||
+ fit_image_check_os(fit, noffset, IH_OS_ELF);
/*
* If either of the checks fail, we should report an error, but
diff --git a/boot/image.c b/boot/image.c
index 073931cd7a..5b88d6808c 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -134,6 +134,9 @@ static const table_entry_t uimage_os[] = {
#endif
{ IH_OS_OPENSBI, "opensbi", "RISC-V OpenSBI", },
{ IH_OS_EFI, "efi", "EFI Firmware" },
+#ifdef CONFIG_CMD_ELF
+ { IH_OS_ELF, "elf", "ELF Image" },
+#endif
{ -1, "", "", },
};
diff --git a/include/image.h b/include/image.h
index 21de70f0c9..9a40bca22c 100644
--- a/include/image.h
+++ b/include/image.h
@@ -100,6 +100,7 @@ enum {
IH_OS_TEE, /* Trusted Execution Environment */
IH_OS_OPENSBI, /* RISC-V OpenSBI */
IH_OS_EFI, /* EFI Firmware (e.g. GRUB2) */
+ IH_OS_ELF, /* ELF Image (e.g. seL4) */
IH_OS_COUNT,
};
--
2.39.2
Re: [PATCH] cmd: bootm: add ELF file support
Hi Maxim,
On 4/10/24 23:21, Maxim Moskalets wrote:
From: Maxim Moskalets
Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.
Signed-off-by: Maxim Moskalets
---
boot/bootm_os.c | 24
boot/image-fit.c | 3 ++-
boot/image.c | 3 +++
include/image.h | 1 +
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index ccde72d22c..1c92b8149c 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -395,6 +395,27 @@ static int do_bootm_qnxelf(int flag, struct bootm_info
*bmi)
}
#endif
+#if defined(CONFIG_CMD_ELF)
+static int do_bootm_elf(int flag, struct bootm_info *bmi)
+{
+ struct bootm_headers *images = bmi->images;
+ char *local_args[2] = {NULL};
+ char str[19] = ""; /* "0x" + 16 digits + "\0" */
+
+ if (flag != BOOTM_STATE_OS_GO)
+ return 0;
+
+ sprintf(str, "0x%lx", images->ep); /* write entry-point into string */
+ str[18] = '\0';
This does seem like snprintf would be useful here?
"""
snprintf(str, 19, "0x%lx", images-ep);
"""
safest and also merges the two instructions in one.
Also, have another question, do we want to 0-left-pad the value so that
it's always a 16 hex-digit number?
e.g. 0x%016lx
Cheers,
Quentin
Re: [PATCH v2 12/16] arm: dts: k3-am625-sk-u-boot: Add sysreset-controller node
Hi Jonathan,
Thank you for the patch.
On lun., avril 08, 2024 at 17:31, Jonathan Humphreys wrote:
> Signed-off-by: Jonathan Humphreys
Please consider adding a commit message body.
On the TI vendor tree, there is a similar patch with a commit message:
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2023.04&id=c5296d943c2c84dd6dcb3b91305d006ac46f3157
Before patch:
=> reset
resetting ...
System reset not supported on this platform
### ERROR ### Please RESET the board ###
With patch applied:
=> reset
resetting ...
Tested-by: Mattijs Korpershoek # on am62x sk evm
Andrew also suggested to me that if we are interested by A53 reset only,
we can PSCI reset instead for all k3 architecture:
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -784,6 +784,9 @@ config ARCH_K3
bool "Texas Instruments' K3 Architecture"
select SPL
select SUPPORT_SPL
+ select PSCI_RESET if ARM64
+ select SYSRESET if ARM64
+ select SYSRESET_PSCI if ARM64
select FIT
select REGEX
select FIT_SIGNATURE if ARM64
Has the above been considered?
> ---
> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> index fa778b0ff4c..35bfeae75a0 100644
> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> @@ -46,3 +46,12 @@
> &cpsw_port2 {
> status = "disabled";
> };
> +
> +&dmsc {
> + bootph-pre-ram;
> +
> + k3_sysreset: sysreset-controller {
> + compatible = "ti,sci-sysreset";
> + bootph-pre-ram;
> + };
> +};
> --
> 2.34.1
Re: [PATCH v2] board: rockchip: Add the Turing RK1 SoM
On 23-12-14 18:46:47, Joshua Riek wrote:
The Turing RK1 is a Rockchip RK3588 based SoM from Turing Machines.
Specifications:
Rockchip RK3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16/32GB memory LPDDR4x
Mali G610MC4 GPU
32GB eMMC HS400
2x USB 2.0, 2x USB 3.0
2x MIPI CSI 4x lanes
1x MIPI-DSI DPHY 2x lanes
PCIe 2.0 x1, PCIe 3.0 x4
1x HDMI 2.1 output, 1x DP 1.4 output
Gigabit Ethernet
Size: 69.6mm x 45mm (260-pin SO-DIMM connector)
Kernel commit:
2806a69f3fef ("arm64: dts: rockchip: Add Turing RK1 SoM support")
[…]
diff --git a/configs/turing-rk1-rk3588_defconfig
b/configs/turing-rk1-rk3588_defconfig
new file mode 100644
index 00..289f2da775
--- /dev/null
+++ b/configs/turing-rk1-rk3588_defconfig
@@ -0,0 +1,133 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_SYS_HAS_NONCACHED_MEMORY=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_TEXT_BASE=0x00a0
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
+CONFIG_SF_DEFAULT_SPEED=2400
+CONFIG_SF_DEFAULT_MODE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="rk3588-turing-rk1"
+CONFIG_ROCKCHIP_RK3588=y
+CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
Does the RK1 have an SPI chip attached, and is is possible to flash
u-boot into SPI and boot from it?
This has sparked some confusion on whether "u-boot-rockchip-spi.bin"
should be provided in a downstream build or not.
[…]
Thanks,
Florian
Re: [PATCH v2 0/4] qcom: pinctrl drivers for qcm2290/sm6115/sm8250
On 10/04/2024 19:52, Caleb Connolly wrote: Introduce pinctrl drivers for three new SoCs and enable them. Signed-off-by: Caleb Connolly --- Changes in v2: - Fix a few formatting issues - Link to v1: https://lore.kernel.org/r/20240408-b4-qcom-rbx-soc-v1-0-900db37b8...@linaro.org --- Caleb Connolly (4): pinctrl: qcom: add qcm2290 pinctrl driver pinctrl: qcom: add sm6115 pinctrl driver pinctrl: qcom: add sm8250 pinctrl driver qcom_defconfig: enable pinctrl for new qcm2290/sm6115/sm8250 configs/qcom_defconfig | 3 + drivers/pinctrl/qcom/Kconfig | 21 drivers/pinctrl/qcom/Makefile | 3 + drivers/pinctrl/qcom/pinctrl-qcm2290.c | 70 drivers/pinctrl/qcom/pinctrl-sm6115.c | 200 + drivers/pinctrl/qcom/pinctrl-sm8250.c | 99 6 files changed, 396 insertions(+) --- change-id: 20240408-b4-qcom-rbx-soc-44ee99c8b799 base-commit: 4ba549b0a4e67c563785ab144edf47e108b34822 // Caleb (they/them) Reviewed-by: Neil Armstrong
