[GIT PULL] please pull fsl-qoirq-2023-10-10
Hi Tom, Please pull fsl-qoirq-2023-10-10 --- Drop legacy PPA secure FW support support for MC reserved memory reset the FLSHxCR1 registers for nxp_fspi --- CI: https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/pipelines/18067 I merged the patch 1 [1] and patch 2 [1] into one patch [1]https://lore.kernel.org/all/20230822150334.15703-1-laurentiu.tu...@nxp.com/ Thanks, Peng. The following changes since commit d9bb6d779b69c2548891e568e5e2a23e1b7eedaa: Merge tag 'u-boot-rockchip-20231007' of https://source.denx.de/u-boot/custodians/u-boot-rockchip (2023-10-08 09:58:55 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git tags/fsl-qoirq-2023-10-10 for you to fetch changes up to 131e44c5448fb0ba9f8b6084cb848a84d729b2c5: spi: nxp_fspi: reset the FLSHxCR1 registers (2023-10-10 10:13:51 +0800) Han Xu (1): spi: nxp_fspi: reset the FLSHxCR1 registers Laurentiu Tudor (6): configs: layerscape: delete defconfigs using legacy PPA secure FW fsl-layerscape: drop obsolete PPA secure firmware support armv8: fsl-layerscape: make some functions static drivers: net: fsl-mc: add support for MC reserved memory board: freescale: ls2080a: declare MC reserved regions board: freescale: ls1088a: declare MC reserved regions arch/arm/cpu/armv8/fsl-layerscape/Kconfig| 60 --- arch/arm/cpu/armv8/fsl-layerscape/Makefile | 1 - arch/arm/cpu/armv8/fsl-layerscape/icid.c | 12 ++-- arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 284 - arch/arm/cpu/armv8/fsl-layerscape/spl.c | 34 --- arch/arm/include/asm/arch-fsl-layerscape/ppa.h | 12 arch/arm/include/asm/fsl_secure_boot.h | 9 --- board/freescale/ls1012afrdm/Kconfig | 11 board/freescale/ls1012afrdm/ls1012afrdm.c| 6 -- board/freescale/ls1012aqds/Kconfig | 8 --- board/freescale/ls1012aqds/ls1012aqds.c | 6 -- board/freescale/ls1012ardb/Kconfig | 12 board/freescale/ls1012ardb/ls1012ardb.c | 6 -- board/freescale/ls1028a/Kconfig | 12 board/freescale/ls1028a/ls1028a.c| 7 --- board/freescale/ls1043aqds/Kconfig | 16 - board/freescale/ls1043aqds/ls1043aqds.c | 5 -- board/freescale/ls1043ardb/Kconfig | 14 - board/freescale/ls1043ardb/ls1043ardb.c | 5 -- board/freescale/ls1046aqds/Kconfig | 16 - board/freescale/ls1046aqds/ls1046aqds.c | 5 -- board/freescale/ls1046ardb/Kconfig | 14 - board/freescale/ls1046ardb/ls1046ardb.c | 5 -- board/freescale/ls1088a/Kconfig | 28 - board/freescale/ls1088a/ls1088a.c| 6 +- board/freescale/ls2080aqds/Kconfig | 16 - board/freescale/ls2080aqds/ls2080aqds.c | 6 +- board/freescale/ls2080ardb/Kconfig | 16 - board/freescale/ls2080ardb/ls2080ardb.c | 6 +- board/freescale/lx2160a/lx2160a.c| 1 + board/traverse/ten64/ten64.c | 1 - configs/ls1012a2g5rdb_qspi_defconfig | 69 -- configs/ls1012afrdm_qspi_defconfig | 67 - configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 72 --- configs/ls1012afrwy_qspi_defconfig | 72 --- configs/ls1012aqds_qspi_defconfig| 95 -- configs/ls1012ardb_qspi_SECURE_BOOT_defconfig| 77 configs/ls1012ardb_qspi_defconfig| 77 configs/ls1043aqds_defconfig | 107 -- configs/ls1043aqds_lpuart_defconfig | 109 -- configs/ls1043aqds_nand_defconfig| 138 --- configs/ls1043aqds_nor_ddr3_defconfig| 108 -- configs/ls1043aqds_qspi_defconfig| 98 --- configs/ls1043aqds_sdcard_ifc_defconfig | 135 -- configs/ls1043aqds_sdcard_qspi_defconfig | 124 --- configs/ls1043ardb_SECURE_BOOT_defconfig | 99 --- configs/ls1043ardb_defconfig
[PATCH 1/1] i2c: designware_i2c: adjust timing calculation
In SPL probing of the designware_i2c device on the StarFive VisionFive 2
board fails with
dw_i2c: mode 0, ic_clk 100, speed 10,
period 10 rise 1 fall 1 tlow 5 thigh 4 spk 0
dw_i2c: bad counts. hcnt = -4 lcnt = 4
device_probe: i2c@1205 failed to probe -22
When changing the offset for the high phase from 7 to 1 the device is
probed correctly.
Without this fix the memory size of the StarFive VisionFive 2 board cannot
be read from EEPROM.
Fixes: e71b6f6622d6 ("i2c: designware_i2c: Rewrite timing calculation")
Signed-off-by: Heinrich Schuchardt
---
drivers/i2c/designware_i2c.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index e54de42abc..55e582091c 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -155,10 +155,10 @@ static int dw_i2c_calc_timing(struct dw_i2c *priv, enum
i2c_speed_mode mode,
/*
* Back-solve for hcnt and lcnt according to the following equations:
-* SCL_High_time = [(HCNT + IC_*_SPKLEN + 7) * ic_clk] + SCL_Fall_time
+* SCL_High_time = [(HCNT + IC_*_SPKLEN + 1) * ic_clk] + SCL_Fall_time
* SCL_Low_time = [(LCNT + 1) * ic_clk] - SCL_Fall_time + SCL_Rise_time
*/
- hcnt = min_thigh_cnt - fall_cnt - 7 - spk_cnt;
+ hcnt = min_thigh_cnt - fall_cnt - 1 - spk_cnt;
lcnt = min_tlow_cnt - rise_cnt + fall_cnt - 1;
if (hcnt < 0 || lcnt < 0) {
@@ -170,13 +170,13 @@ static int dw_i2c_calc_timing(struct dw_i2c *priv, enum
i2c_speed_mode mode,
* Now add things back up to ensure the period is hit. If it is off,
* split the difference and bias to lcnt for remainder
*/
- tot = hcnt + lcnt + 7 + spk_cnt + rise_cnt + 1;
+ tot = hcnt + lcnt + 1 + spk_cnt + rise_cnt + 1;
if (tot < period_cnt) {
diff = (period_cnt - tot) / 2;
hcnt += diff;
lcnt += diff;
- tot = hcnt + lcnt + 7 + spk_cnt + rise_cnt + 1;
+ tot = hcnt + lcnt + 1 + spk_cnt + rise_cnt + 1;
lcnt += period_cnt - tot;
}
--
2.40.1
Re: [PATCH v5 10/11] ram: starfive: Read memory size information from EEPROM
On 11.10.23 04:54, Heinrich Schuchardt wrote:
On 15.06.23 11:36, Yanhong Wang wrote:
StarFive VisionFive 2 has two versions, 1.2A and 1.3B, each version of
DDR capacity includes 2G/4G/8G, a DT can not support multiple
capacities, so the capacity size information is recorded to EEPROM, when
DDR initialization required capacity size information is read from
EEPROM.
If there is no information in EEPROM, it is initialized with the default
size defined in DT.
Signed-off-by: Yanhong Wang
Reviewed-by: Leo Yu-Chi Liang
---
arch/riscv/cpu/jh7110/spl.c | 32 -
drivers/ram/starfive/starfive_ddr.c | 2 --
2 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c
index 104f0fe949..72adcefa0e 100644
--- a/arch/riscv/cpu/jh7110/spl.c
+++ b/arch/riscv/cpu/jh7110/spl.c
@@ -3,19 +3,49 @@
* Copyright (C) 2022 StarFive Technology Co., Ltd.
* Author: Yanhong Wang
*/
-
+#include
+#include
#include
#include
#include
+#include
#include
+#include
#define CSR_U74_FEATURE_DISABLE 0x7c1
#define L2_LIM_MEM_END 0x81FUL
+DECLARE_GLOBAL_DATA_PTR;
+
+static bool check_ddr_size(phys_size_t size)
+{
+ switch (size) {
+ case SZ_2:
+ case SZ_4:
+ case SZ_8:
+ case SZ_16:
+ return true;
+ default:
+ return false;
+ }
+}
+
int spl_soc_init(void)
{
int ret;
struct udevice *dev;
+ phys_size_t size;
+
+ ret = fdtdec_setup_mem_size_base();
+ if (ret)
+ return ret;
+
+ /* Read the definition of the DDR size from eeprom, and if not,
+ * use the definition in DT
+ */
+ size = (get_ddr_size_from_eeprom() >> 16) & 0xFF;
On origin/master for a 4 GiB board with a serial number
VF7110B1-2253-D004E000-4000 this always fails. This results in
memory reported as 8 GiB and Linux crashing.
i2c_get_chip_for_busnum() returns -EINVAL in read_eeprom()
[board/starfive/visionfive2/visionfive2-i2c-eeprom.c:335].
Is the driver model really expected to be fully initialized before
setting up memory?
Best regards
Heinrich
The root cause seems to be in dw_i2c_calc_timing(). Probing of the
i2c_designware device fails with:
dw_i2c: mode 0, ic_clk 100, speed 10, period 10 rise 1 fall 1
tlow 5 thigh 4 spk 0
dw_i2c: bad counts. hcnt = -4 lcnt = 4
device_probe: i2c@1205 failed to probe -22
When I change the hcnt timing calculation, by replacing the offset of 7
to 1, the device is probed correctly and I get the correct memory size
for my board.
Best regards
Heinrich
+ if (check_ddr_size(size))
+ gd->ram_size = size << 30;
/* DDR init */
ret = uclass_get_device(UCLASS_RAM, 0, );
diff --git a/drivers/ram/starfive/starfive_ddr.c
b/drivers/ram/starfive/starfive_ddr.c
index 553f2ce6f4..a0a3d6b33d 100644
--- a/drivers/ram/starfive/starfive_ddr.c
+++ b/drivers/ram/starfive/starfive_ddr.c
@@ -72,8 +72,6 @@ static int starfive_ddr_probe(struct udevice *dev)
u64 rate;
int ret;
- /* Read memory base and size from DT */
- fdtdec_setup_mem_size_base();
priv->info.base = gd->ram_base;
priv->info.size = gd->ram_size;
Re: [PATCH] arm: mach-apple: Move M1/M2 specifics into a separate folder
S5L8950X is definitely belongs to the mach-apple folder, since it's the
first truly apple-made SoC: it uses AIC, DART, Apple GPIO, etc etc. I
might be wrong but I haven't seen any references of RTKit on S5L8950X.
I have already have gotten u-boot working with AIC timer and partial
dwc2 support (plug-in detection works, not sure yet why it doesn't
expose a USB interface to my PC) on the iPhone 5. It's confirmed to also
work on the 5c, and with a few changes addresses-wise it also works on
A5. Here's a rough link to my changes (which are still to-be-improved)
on my github u-boot repo:
https://github.com/ivoszbg/u-boot/commit/e20958e142cb881488602b7e864c00073dfe32db
In my opinion, M1 support shouldn't have been placed in the mach-apple
folder like that in the first place. It's disrupting the work for a ton
of Apple SoCs, as if M1 is the only apple SoC in existence.
On 10/11/23 00:17, Mark Kettenis wrote:
>> Date: Tue, 29 Aug 2023 22:13:53 +0300
>> From: Ivaylo Ivanov
>>
>> I'm currently working on S5L8950X. I also have some T7000 and T8010
>> devices that I'll work on in the future.
>>
>> There's a project called freemyipod that has a fork of U-Boot working on
>> iPod Nano's (specifically the S5L8730 in the iPod Nano 5). I've read
>> that they're planning on upstreaming it in the near future.
>
> ok, well, most of the code you're moving isn't really M1/M2 specific.
> Apple uses RTKit all over the place. And some of the SoCs you mention
> are really close to M1/M2. And the older ones have a lot of Samsung
> heritage so I'm not sure they belong under mach-apple ...
>
> Also, unless you actually have code to support other Apple SoCs, this
> just causes disruption for upstreaming more of the M1/M2 code. So I
> think this is best left alone until you actually show your code and we
> can see how to integrate it.
>
>>
>> On 8/29/23 20:43, Mark Kettenis wrote:
From: ivo.iva...@null.net
Date: Tue, 29 Aug 2023 20:25:19 +0300
From: Ivaylo Ivanov
Currently, mach-apple assumes we're working with M1/M2. Make room for
adding support for other Apple SoCs by moving everything from the M1/M2
SoC family in "mach-apple/" into "mach-apple/m1/".
>>>
>>> Which other Apple SoCs?
>>>
Signed-off-by: Ivaylo Ivanov
---
arch/arm/Kconfig | 29 --
arch/arm/mach-apple/Kconfig | 42
arch/arm/mach-apple/Makefile | 5 +--
arch/arm/mach-apple/m1/Makefile | 6 +++
arch/arm/mach-apple/{ => m1}/board.c | 0
arch/arm/mach-apple/{ => m1}/lowlevel_init.S | 0
arch/arm/mach-apple/{ => m1}/rtkit.c | 0
arch/arm/mach-apple/{ => m1}/sart.c | 0
configs/apple_m1_defconfig | 1 +
9 files changed, 50 insertions(+), 33 deletions(-)
create mode 100644 arch/arm/mach-apple/m1/Makefile
rename arch/arm/mach-apple/{ => m1}/board.c (100%)
rename arch/arm/mach-apple/{ => m1}/lowlevel_init.S (100%)
rename arch/arm/mach-apple/{ => m1}/rtkit.c (100%)
rename arch/arm/mach-apple/{ => m1}/sart.c (100%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97c25b4f14..5339da370c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -980,38 +980,9 @@ config ARCH_NPCM
config ARCH_APPLE
bool "Apple SoCs"
- select ARM64
- select CLK
- select CMD_PCI
- select CMD_USB
select DM
- select DM_GPIO
- select DM_KEYBOARD
- select DM_MAILBOX
select DM_RESET
select DM_SERIAL
- select DM_SPI
- select DM_USB
- select VIDEO
- select IOMMU
- select LINUX_KERNEL_IMAGE_HEADER
- select OF_BOARD_SETUP
- select OF_CONTROL
- select PCI
- select PINCTRL
- select POSITION_INDEPENDENT
- select POWER_DOMAIN
- select REGMAP
- select SPI
- select SYSCON
- select SYSRESET
- select SYSRESET_WATCHDOG
- select SYSRESET_WATCHDOG_AUTO
- select USB
- imply CMD_DM
- imply CMD_GPT
- imply DISTRO_DEFAULTS
- imply OF_HAS_PRIOR_STAGE
config ARCH_OWL
bool "Actions Semi OWL SoCs"
diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig
index 294690ec0e..a38779b387 100644
--- a/arch/arm/mach-apple/Kconfig
+++ b/arch/arm/mach-apple/Kconfig
@@ -3,6 +3,46 @@ if ARCH_APPLE
config TEXT_BASE
default 0x
+choice
+ prompt "Apple Silicon architecture type select"
+ optional
+
+config ARCH_APPLE_M1
+ bool "Apple M1/M2 SoC family"
+ select ARM64
+ select CLK
+ select CMD_PCI
+ select CMD_USB
+ select DM_GPIO
+ select DM_KEYBOARD
+ select DM_MAILBOX
+ select DM_SPI
+ select DM_USB
+ select VIDEO
+ select IOMMU
RE: [PATCH] timer: starfive: Add Starfive timer support
Hi Simon, If there are no more issue, I will send out version 2 patch. > -Original Message- > From: Simon Glass > Sent: Tuesday, October 10, 2023 9:45 PM > To: KuanLim.Lee > Cc: u-boot@lists.denx.de; WeiLiang Lim > Subject: Re: [PATCH] timer: starfive: Add Starfive timer support > > Hi, > > On Wed, 4 Oct 2023 at 03:49, KuanLim.Lee > wrote: > > > > Hi Simon, > > > > > -Original Message- > > > From: Simon Glass > > > Sent: Wednesday, October 4, 2023 10:11 AM > > > To: KuanLim.Lee > > > Cc: u-boot@lists.denx.de; WeiLiang Lim > > > > > > Subject: Re: [PATCH] timer: starfive: Add Starfive timer support > > > > > > On Tue, 19 Sept 2023 at 06:08, Kuan Lim Lee > > > > > > wrote: > > > > > > > > Add timer driver in Starfive SoC. It is an timer that outside of > > > > CPU core and inside Starfive SoC. > > > > > > > > Signed-off-by: Kuan Lim Lee > > > > Reviewed-by: Wei Liang Lim > > > > --- > > > > drivers/timer/Kconfig | 7 +++ > > > > drivers/timer/Makefile | 1 + > > > > drivers/timer/starfive-timer.c | 94 > > > > ++ > > > > 3 files changed, 102 insertions(+) create mode 100644 > > > > drivers/timer/starfive-timer.c > > > > > > Reviewed-by: Simon Glass > > > > > > nits below > > What are the nits? > > How do the nits to be solved? > > they are the things I mentioned below > > > > > > > > > > > > diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig index > > > > 915b2af160..a98be9dfae 100644 > > > > --- a/drivers/timer/Kconfig > > > > +++ b/drivers/timer/Kconfig > > > > @@ -326,4 +326,11 @@ config XILINX_TIMER > > > > Select this to enable support for the timer found on > > > > any Xilinx boards (axi timer). > > > > > > > > +config STARFIVE_TIMER > > > > + bool "Starfive timer support" > > > > + depends on TIMER > > > > + help > > > > + Select this to enable support for the timer found on > > > > + Starfive SoC. > > > > > > What resolution is the timer? How is it clocked? Is there only one > > > channel? > > Timer will be driven by clock pulses from clocks. The clocks are defined in > device tree. > > Four channels timer, each timer has own clock source. > > Clock source frequency is gotten by clk_get_by_index () and clk_get_rate(). > > The timer counter register is a 32bits size register. > > OK so could you put these details in the help? Timer0 bias = 0x00, Timer1 bias = 0x40, Timer2 bias = 0x80, Timer3 bias = 0xc0 Register: TIMER Interrupts Status (offset = 0x00) Bit0 - timer_int_ch0 - default: 0x00 Bit1 - timer_int_ch1 - default: 0x00 Bit2 - timer_int_ch2 - default: 0x00 Bit3 - timer_int_ch3 - default: 0x00 TIMER Control Register (offset = 0x04+bias) Bit[0] - default: 0x0 0: continuous run, 1: single run Single run mode will stop after the TIMER Value Register is counted to zero and reloaded. Continuous run mode will keep on running after the TIMER Value Register is counted to zero and reloaded. TIMER Load Register (offset = 0x08+bias) Bit[31:0] - default: 0x The value is always reloaded into TIMER Value Register TIMER Enable Register (offset = 0x10+bias) Bit[0] - default: 0x0 0: disable, 1: enable TIMER Reload Register (offset = 0x14+bias) Bit[0] - default: 0x0 Write this register to reload preset value to counter. (Write 0 and 1 are both ok) Read this register always get '0'. TIMER Value Register (offset = 0x18+bias) Bit[31:0] - default: 0x Indicates value of the 32-bit counter. Read-Only Register. TIMER Interrupt Status/Clear Register (offset = 0x20+bias) Bit[1] - default: 0x0. "timer_int_clr_busy". Read-Only bit. '1' means that it is clearing interrupt. Bit 0 can NOT be written. '0' means Bit 0 can be written to clear interrupt. Bit[0] - default: 0x0. "timer_int_clear_status". Read-Write bit. Read value represent channel interrupt status. Write 1 to this bit clear interrupt. Write 0 has no effects. TIMER Interrupt Mask Register (offset = 0x24+bias) Bit[0] - default: 0x1 Interrupt Mask Register. 0: Unmask, 1: Mask It must be unmasked to before using the timer channel. Current device tree will put the clock source details. So that, driver can get the clock source frequency of the channel by clk_get_by_index () and clk_get_rate(). clock-names = "ch0", "ch1", "ch2", "ch3", "apb"; I don’t use interrupt here and only choose one of the timer channels to use. Please tell me if these details are not sufficient. > > > > > > > > + > > > > endmenu > > > > diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile index > > > > 1ca74805fd..1ef814970b 100644 > > > > --- a/drivers/timer/Makefile > > > > +++ b/drivers/timer/Makefile > > > > @@ -34,3 +34,4 @@ obj-$(CONFIG_MTK_TIMER) += mtk_timer.o > > > > obj-$(CONFIG_MCHP_PIT64B_TIMER)+= mchp-pit64b-timer.o > > > > obj-$(CONFIG_IMX_GPT_TIMER)+= imx-gpt-timer.o > > > > obj-$(CONFIG_XILINX_TIMER) += xilinx-timer.o > > > >
[PATCH] spi: cadence_ospi_versal: Add support for 64-bit address
When 64-bit address is passed only lower 32-bit address is getting updated. Program the upper 32-bit address in the DMA destination memory address MSBs register. Signed-off-by: Venkatesh Yadav Abbarapu --- drivers/spi/cadence_ospi_versal.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/spi/cadence_ospi_versal.c b/drivers/spi/cadence_ospi_versal.c index a7685a2f51..e02a3b3de3 100644 --- a/drivers/spi/cadence_ospi_versal.c +++ b/drivers/spi/cadence_ospi_versal.c @@ -44,8 +44,10 @@ int cadence_qspi_apb_dma_read(struct cadence_spi_priv *priv, priv->regbase + CQSPI_REG_INDIR_TRIG_ADDR_RANGE); writel(CQSPI_DFLT_DMA_PERIPH_CFG, priv->regbase + CQSPI_REG_DMA_PERIPH_CFG); - writel((unsigned long)rxbuf, priv->regbase + + writel(lower_32_bits((unsigned long)rxbuf), priv->regbase + CQSPI_DMA_DST_ADDR_REG); + writel(upper_32_bits((unsigned long)rxbuf), priv->regbase + + CQSPI_DMA_DST_ADDR_MSB_REG); writel(priv->trigger_address, priv->regbase + CQSPI_DMA_SRC_RD_ADDR_REG); writel(bytes_to_dma, priv->regbase + -- 2.17.1
[PATCH v2] drivers: firmware: Handle error case in the zynqmp_pm_feature
Unhandled error coming from xilinx_pm_request() but return value is not read back that's why getting sparse warning as below: warning: variable 'ret' set but not used [-Wunused-but-set-variable]. In case of error return the "ret" value. Signed-off-by: Venkatesh Yadav Abbarapu --- Changes in v2: - Fixed the commit description. - Removed the newline. --- drivers/firmware/firmware-zynqmp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/firmware/firmware-zynqmp.c b/drivers/firmware/firmware-zynqmp.c index 43fb7fa778..8ea15c7ed3 100644 --- a/drivers/firmware/firmware-zynqmp.c +++ b/drivers/firmware/firmware-zynqmp.c @@ -203,6 +203,8 @@ int zynqmp_pm_feature(const u32 api_id) /* Check feature check API version */ ret = xilinx_pm_request(PM_FEATURE_CHECK, api_id, 0, 0, 0, ret_payload); + if (ret) + return ret; /* Return feature check version */ return ret_payload[1] & FIRMWARE_VERSION_MASK; -- 2.17.1
Re: [PATCH v5 10/11] ram: starfive: Read memory size information from EEPROM
On 15.06.23 11:36, Yanhong Wang wrote:
StarFive VisionFive 2 has two versions, 1.2A and 1.3B, each version of
DDR capacity includes 2G/4G/8G, a DT can not support multiple
capacities, so the capacity size information is recorded to EEPROM, when
DDR initialization required capacity size information is read from
EEPROM.
If there is no information in EEPROM, it is initialized with the default
size defined in DT.
Signed-off-by: Yanhong Wang
Reviewed-by: Leo Yu-Chi Liang
---
arch/riscv/cpu/jh7110/spl.c | 32 -
drivers/ram/starfive/starfive_ddr.c | 2 --
2 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c
index 104f0fe949..72adcefa0e 100644
--- a/arch/riscv/cpu/jh7110/spl.c
+++ b/arch/riscv/cpu/jh7110/spl.c
@@ -3,19 +3,49 @@
* Copyright (C) 2022 StarFive Technology Co., Ltd.
* Author: Yanhong Wang
*/
-
+#include
+#include
#include
#include
#include
+#include
#include
+#include
#define CSR_U74_FEATURE_DISABLE 0x7c1
#define L2_LIM_MEM_END0x81FUL
+DECLARE_GLOBAL_DATA_PTR;
+
+static bool check_ddr_size(phys_size_t size)
+{
+ switch (size) {
+ case SZ_2:
+ case SZ_4:
+ case SZ_8:
+ case SZ_16:
+ return true;
+ default:
+ return false;
+ }
+}
+
int spl_soc_init(void)
{
int ret;
struct udevice *dev;
+ phys_size_t size;
+
+ ret = fdtdec_setup_mem_size_base();
+ if (ret)
+ return ret;
+
+ /* Read the definition of the DDR size from eeprom, and if not,
+* use the definition in DT
+*/
+ size = (get_ddr_size_from_eeprom() >> 16) & 0xFF;
On origin/master for a 4 GiB board with a serial number
VF7110B1-2253-D004E000-4000 this always fails. This results in
memory reported as 8 GiB and Linux crashing.
i2c_get_chip_for_busnum() returns -EINVAL in read_eeprom()
[board/starfive/visionfive2/visionfive2-i2c-eeprom.c:335].
Is the driver model really expected to be fully initialized before
setting up memory?
Best regards
Heinrich
+ if (check_ddr_size(size))
+ gd->ram_size = size << 30;
/* DDR init */
ret = uclass_get_device(UCLASS_RAM, 0, );
diff --git a/drivers/ram/starfive/starfive_ddr.c
b/drivers/ram/starfive/starfive_ddr.c
index 553f2ce6f4..a0a3d6b33d 100644
--- a/drivers/ram/starfive/starfive_ddr.c
+++ b/drivers/ram/starfive/starfive_ddr.c
@@ -72,8 +72,6 @@ static int starfive_ddr_probe(struct udevice *dev)
u64 rate;
int ret;
- /* Read memory base and size from DT */
- fdtdec_setup_mem_size_base();
priv->info.base = gd->ram_base;
priv->info.size = gd->ram_size;
Re: [PATCH v5 00/16] firmware: scmi: add SCMI base protocol support
On Wed, Oct 11, 2023 at 10:36:11AM +0900, AKASHI Takahiro wrote:
> Hi Tom,
>
> On Tue, Oct 10, 2023 at 10:19:09AM -0400, Tom Rini wrote:
> > On Tue, Sep 26, 2023 at 03:57:34PM +0900, AKASHI Takahiro wrote:
> >
> > > This patch series allows users to access SCMI base protocol provided by
> > > SCMI server (platform). It will also be utilized in separate patches
> > > in the future to add sanity/validity checks for other protocols.
> > > See SCMI specification document v3.2 beta[1] for more details about SCMI
> > > base protocol.
> > >
> > > What is currently not implemented is
> > > - SCMI_BASE_NOTIFY_ERRORS command and notification callback mechanism
> > >
> > > This feature won't be very useful in the current U-Boot environment.
> > >
> > > [1] https://developer.arm.com/documentation/den0056/e/?lang=en
> > >
> > >
> > > Test
> > >
> > > The patch series was tested on the following platforms:
> > > * sandbox
> > > * qemu-arm64 with OPTEE as SCMI server
> >
> > I have two problems. The first is that for sandbox, this series is not
> > bisectable as a commits fail to build due to needing a definition in the
> > test before it's added:
> > /home/uboot/work/u-boot/u-boot/test/dm/scmi.c: In function
> > 'dm_test_scmi_clocks':
> > /home/uboot/work/u-boot/u-boot/test/dm/scmi.c:117:21: warning: implicit
> > declaration of function 'scmi_get_protocol'
> > [-Wimplicit-function-declaration]
> > 117 | clock_dev = scmi_get_protocol(agent_dev,
> > SCMI_PROTOCOL_ID_CLOCK);
> > | ^
>
> [snip]
>
> Ah, I didn't notice this dependency.
> I will fix it by re-ordering the commits.
>
> > Second, the series causes this failure:
> > == FAILURES
> > ===
> > ___ test_ut[ut_dm_dm_test_scmi_cmd]
> > ___
> > test/py/u_boot_spawn.py:195: in expect
> > c = os.read(self.fd, 1024).decode(errors='replace')
> > E OSError: [Errno 5] Input/output error
> >
> > During handling of the above exception, another exception occurred:
> > test/py/tests/test_ut.py:497: in test_ut
> > output = u_boot_console.run_command('ut ' + ut_subtest)
> > test/py/u_boot_console_base.py:266: in run_command
> > m = self.p.expect([self.prompt_compiled] + self.bad_patterns)
> > test/py/u_boot_spawn.py:204: in expect
> > raise ValueError('U-Boot exited with %s' % info)
> > E ValueError: U-Boot exited with signal 11 (SIGSEGV)
> > Captured stdout call
> > -
> > => ut dm dm_test_scmi_cmd
> > Test: dm_test_scmi_cmd: scmi.c
> > SCMI device: scmi
> > protocol version: 0x2
> > # of agents: 2
> > 0: platform
> > > 1: OSPM
> > # of protocols: 3
> > Clock management
> > Reset domain management
> > Voltage domain management
> > vendor: U-Boot
> > sub vendor: Sandbox
> > impl version: 0x1
> > Denying access to device:0 failed (-13)
> > Denying access to protocol:0x14 on device:0 failed (-13)
> > Reset failed (-13)
> > Test: dm_test_scmi_cmd: scmi.c (flat tree)
> > SCMI device: ?n
> > === short test summary info
> > ===
> > FAILED test/py/tests/test_ut.py::test_ut[ut_dm_dm_test_scmi_cmd] -
> > ValueError: U-Boot exited...
>
> This seems to happen in the case of "flat tree", but
> I cannot reproduce it in my local environment with
> $ pytest test/py/tests/test_ut.py -bd sandbox -k scmi_cmd ...
How about if you run all of the tests? That's how I usually do it, and
CI as well.
> > Which I believe CI will also produce, once the issue with htmldocs is
> > fixed. I can't bisect it exactly as the failure shows up once the new
> > test is added.
>
> Anyhow, "scmi" command is more or less a debug tool for my development.
> All the functionality provided by this patch set is tested at "function"
> level with "ut dm scmi_base" and the command is *not* needed.
> To avoid increasing the maintenance cost, I will drop the command
> (patch #14-#16) in the next version.
OK. Please make sure CI runs and passes as well, thanks.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 00/15] blk: sandbox: Support binding a device with a given logical block size
On Tue, Sep 26, 2023 at 04:43:30PM +0800, Bin Meng wrote: > At present on Sandbox when binding to a host backing file, the host > block device is created with a hard-coded 512 bytes block size. > > Such assumption works for most cases, but for situation that with a raw > image file dump from a pre-formatted GPT partitioned disk image from a > 4KiB block size device, when binding this file to a host device and mapping > this device to a blkmap, "blkmap" command like "blkmap part" won't work > correctly, due to block size mismatch during parsing the partition table. > > This series updates Sandbox block driver, as well as the blkmap driver, > to get rid of the hard-coded 512 bytes block size assumption. > > This series is available at u-boot-x86/blk for testing. > > Test log (512 block size): > > => host bind 0 test.img > => host info > dev blocks blksz label path > 0 262144512 0 test.img > => blkmap create 0 > Created "0" > => blkmap map 0 0 4 linear host 0 0 > Block 0x0+0x4 mapped to block 0x0 of "host 0" > => blkmap info > Device 0: Vendor: U-Boot Rev: 1.0 Prod: blkmap > Type: Hard Disk > Capacity: 128.0 MB = 0.1 GB (262144 x 512) > => blkmap part > > Partition Map for BLKMAP device 0 -- Partition Type: EFI > > PartStart LBA End LBA Name > Attributes > Type GUID > Partition GUID > 1 0x0022 0x00bd "u-boot-spl" > attrs: 0x > type: 5b193300-fc78-40cd-8002-e86c45580b47 > (5b193300-fc78-40cd-8002-e86c45580b47) > guid: 0bb6bb6e-4aac-4c27-be03-016b01e7b941 > 2 0x0822 0x0c84 "u-boot" > attrs: 0x > type: 2e54b353-1271-4842-806f-e436d6af6985 > (2e54b353-1271-4842-806f-e436d6af6985) > guid: 91d50814-8e31-4cc0-97dc-779e1dc59056 > 3 0x0c85 0xcc84 "rootfs" > attrs: 0x0004 > type: 0fc63daf-8483-4772-8e79-3d69d8477de4 > (linux) > guid: 42799722-6e55-46e6-afa9-529e7af3f03b > > Test log (4096 block size): > > => host bind 0 test.img 4096 > => host info > dev blocks blksz label path > 032768 4096 0 test.img > => blkmap create 0 > Created "0" > => blkmap map 0 0 8000 linear host 0 0 > Block 0x0+0x8000 mapped to block 0x0 of "host 0" > => blkmap info > Device 0: Vendor: U-Boot Rev: 1.0 Prod: blkmap > Type: Hard Disk > Capacity: 128.0 MB = 0.1 GB (32768 x 4096) > => blkmap part > > Partition Map for BLKMAP device 0 -- Partition Type: EFI > > PartStart LBA End LBA Name > Attributes > Type GUID > Partition GUID > 1 0x0100 0x1fff "primary" > attrs: 0x > type: 0fc63daf-8483-4772-8e79-3d69d8477de4 > (linux) > guid: eba904d7-72c1-4dbd-bb4e-36be49cba5e3 > 2 0x2000 0x7ffa "primary" > attrs: 0x > type: 0fc63daf-8483-4772-8e79-3d69d8477de4 > (linux) > guid: c48c360e-db47-46da-ab87-26416fad3cd3 With minor changes to apply again, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 00/16] firmware: scmi: add SCMI base protocol support
Hi Tom,
On Tue, Oct 10, 2023 at 10:19:09AM -0400, Tom Rini wrote:
> On Tue, Sep 26, 2023 at 03:57:34PM +0900, AKASHI Takahiro wrote:
>
> > This patch series allows users to access SCMI base protocol provided by
> > SCMI server (platform). It will also be utilized in separate patches
> > in the future to add sanity/validity checks for other protocols.
> > See SCMI specification document v3.2 beta[1] for more details about SCMI
> > base protocol.
> >
> > What is currently not implemented is
> > - SCMI_BASE_NOTIFY_ERRORS command and notification callback mechanism
> >
> > This feature won't be very useful in the current U-Boot environment.
> >
> > [1] https://developer.arm.com/documentation/den0056/e/?lang=en
> >
> >
> > Test
> >
> > The patch series was tested on the following platforms:
> > * sandbox
> > * qemu-arm64 with OPTEE as SCMI server
>
> I have two problems. The first is that for sandbox, this series is not
> bisectable as a commits fail to build due to needing a definition in the
> test before it's added:
> /home/uboot/work/u-boot/u-boot/test/dm/scmi.c: In function
> 'dm_test_scmi_clocks':
> /home/uboot/work/u-boot/u-boot/test/dm/scmi.c:117:21: warning: implicit
> declaration of function 'scmi_get_protocol' [-Wimplicit-function-declaration]
> 117 | clock_dev = scmi_get_protocol(agent_dev,
> SCMI_PROTOCOL_ID_CLOCK);
> | ^
[snip]
Ah, I didn't notice this dependency.
I will fix it by re-ordering the commits.
> Second, the series causes this failure:
> == FAILURES
> ===
> ___ test_ut[ut_dm_dm_test_scmi_cmd]
> ___
> test/py/u_boot_spawn.py:195: in expect
> c = os.read(self.fd, 1024).decode(errors='replace')
> E OSError: [Errno 5] Input/output error
>
> During handling of the above exception, another exception occurred:
> test/py/tests/test_ut.py:497: in test_ut
> output = u_boot_console.run_command('ut ' + ut_subtest)
> test/py/u_boot_console_base.py:266: in run_command
> m = self.p.expect([self.prompt_compiled] + self.bad_patterns)
> test/py/u_boot_spawn.py:204: in expect
> raise ValueError('U-Boot exited with %s' % info)
> E ValueError: U-Boot exited with signal 11 (SIGSEGV)
> Captured stdout call
> -
> => ut dm dm_test_scmi_cmd
> Test: dm_test_scmi_cmd: scmi.c
> SCMI device: scmi
> protocol version: 0x2
> # of agents: 2
> 0: platform
> > 1: OSPM
> # of protocols: 3
> Clock management
> Reset domain management
> Voltage domain management
> vendor: U-Boot
> sub vendor: Sandbox
> impl version: 0x1
> Denying access to device:0 failed (-13)
> Denying access to protocol:0x14 on device:0 failed (-13)
> Reset failed (-13)
> Test: dm_test_scmi_cmd: scmi.c (flat tree)
> SCMI device: ?n
> === short test summary info
> ===
> FAILED test/py/tests/test_ut.py::test_ut[ut_dm_dm_test_scmi_cmd] -
> ValueError: U-Boot exited...
This seems to happen in the case of "flat tree", but
I cannot reproduce it in my local environment with
$ pytest test/py/tests/test_ut.py -bd sandbox -k scmi_cmd ...
> Which I believe CI will also produce, once the issue with htmldocs is
> fixed. I can't bisect it exactly as the failure shows up once the new
> test is added.
Anyhow, "scmi" command is more or less a debug tool for my development.
All the functionality provided by this patch set is tested at "function"
level with "ut dm scmi_base" and the command is *not* needed.
To avoid increasing the maintenance cost, I will drop the command
(patch #14-#16) in the next version.
Thanks,
-Takahiro Akashi
>
> --
> Tom
signature.asc
Description: PGP signature
Re: [PATCH v5 15/16] doc: cmd: add documentation for scmi
Hi Tom, On Tue, Oct 10, 2023 at 10:19:06AM -0400, Tom Rini wrote: > On Tue, Sep 26, 2023 at 03:57:49PM +0900, AKASHI Takahiro wrote: > > > This is a help text for scmi command. > > > > Signed-off-by: AKASHI Takahiro > > Reviewed-by: Simon Glass > > Reviewed-by: Etienne Carriere > > --- > > v4 > > * s/tranport/transport/ > > v2 > > * add more descriptions about SCMI > > --- > > doc/usage/cmd/scmi.rst | 126 + > > 1 file changed, 126 insertions(+) > > create mode 100644 doc/usage/cmd/scmi.rst > > This needs to be included in doc/usage/index.rst in alphabetical order, > so that "make htmldocs" passes. Normally I'd fix this up, but given the > other problem I'm reporting this along. Okay, thanks. I can fix, but see my comment at patch 00/16. -Takahiro Akashi > > -- > Tom signature.asc Description: PGP signature
Re: [PATCH v1 2/7] clk: rockchip: rk3568: add i2s3 clk
Hi Elaine,
Please add commit message, and remove the change id.
same for other patches.
Thanks,
- Kever
On 2023/10/10 16:51, Elaine Zhang wrote:
Change-Id: If20fe16260d2b584d4216d1dbabffcb25478fb1d
Signed-off-by: Elaine Zhang
---
.../include/asm/arch-rockchip/cru_rk3568.h| 36 +++
drivers/clk/rockchip/clk_rk3568.c | 218 ++
2 files changed, 254 insertions(+)
diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
b/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
index 9c7ddd751f72..0306ce57e369 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
@@ -211,6 +211,31 @@ enum {
ACLK_PERIMID_SEL_100M,
ACLK_PERIMID_SEL_24M,
+ /* CRU_CLK_SEL21_CON */
+ I2S3_MCLKOUT_TX_SEL_SHIFT = 15,
+ I2S3_MCLKOUT_TX_SEL_MASK= 1 << I2S3_MCLKOUT_TX_SEL_SHIFT,
+ I2S3_MCLKOUT_TX_SEL_MCLK= 0,
+ I2S3_MCLKOUT_TX_SEL_12M,
+ CLK_I2S3_SEL_SHIFT = 10,
+ CLK_I2S3_SEL_MASK = 0x3 << CLK_I2S3_SEL_SHIFT,
+ CLK_I2S3_SEL_SRC= 0,
+ CLK_I2S3_SEL_FRAC,
+ CLK_I2S3_SEL_CLKIN,
+ CLK_I2S3_SEL_XIN12M,
+ CLK_I2S3_SRC_SEL_SHIFT = 8,
+ CLK_I2S3_SRC_SEL_MASK = 0x3 << CLK_I2S3_SRC_SEL_SHIFT,
+ CLK_I2S3_SRC_SEL_GPLL = 0,
+ CLK_I2S3_SRC_SEL_CPLL,
+ CLK_I2S3_SRC_SEL_NPLL,
+ CLK_I2S3_SRC_DIV_SHIFT = 0,
+ CLK_I2S3_SRC_DIV_MASK = 0x7f << CLK_I2S3_SRC_DIV_SHIFT,
+
+ /* CRU_CLK_SEL22_CON */
+ CLK_I2S3_FRAC_NUMERATOR_SHIFT = 16,
+ CLK_I2S3_FRAC_NUMERATOR_MASK= 0x << 16,
+ CLK_I2S3_FRAC_DENOMINATOR_SHIFT = 0,
+ CLK_I2S3_FRAC_DENOMINATOR_MASK = 0x,
+
/* CRU_CLK_SEL27_CON */
CLK_CRYPTO_PKA_SEL_SHIFT= 6,
CLK_CRYPTO_PKA_SEL_MASK = 3 << CLK_CRYPTO_PKA_SEL_SHIFT,
@@ -502,5 +527,16 @@ enum {
/* CRU_CLK_SEL82_CON */
CPLL_100M_DIV_SHIFT = 0,
CPLL_100M_DIV_MASK = 0x1f << CPLL_100M_DIV_SHIFT,
+
+ /* GRF_SOC_CON2 */
+ I2S3_MCLKOUT_SEL_SHIFT = 15,
+ I2S3_MCLKOUT_SEL_MASK = 0x1 << I2S3_MCLKOUT_SEL_SHIFT,
+ I2S3_MCLKOUT_SEL_RX = 0,
+ I2S3_MCLKOUT_SEL_TX,
+ I2S3_MCLK_IOE_SEL_SHIFT = 3,
+ I2S3_MCLK_IOE_SEL_MASK = 0x1 << I2S3_MCLK_IOE_SEL_SHIFT,
+ I2S3_MCLK_IOE_SEL_CLKIN = 0,
+ I2S3_MCLK_IOE_SEL_CLKOUT,
+
};
#endif
diff --git a/drivers/clk/rockchip/clk_rk3568.c
b/drivers/clk/rockchip/clk_rk3568.c
index 599b7b130eb9..469014439be4 100644
--- a/drivers/clk/rockchip/clk_rk3568.c
+++ b/drivers/clk/rockchip/clk_rk3568.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2326,6 +2327,170 @@ static ulong rk3568_uart_set_rate(struct
rk3568_clk_priv *priv,
return rk3568_uart_get_rate(priv, clk_id);
}
+#ifndef CONFIG_SPL_BUILD
+static ulong rk3568_i2s3_get_rate(struct rk3568_clk_priv *priv, ulong clk_id)
+{
+ struct rk3568_cru *cru = priv->cru;
+ struct rk3568_grf *grf = priv->grf;
+ u32 con, div, src, p_rate;
+ u32 reg, fracdiv, p_src;
+ unsigned long m, n;
+
+ switch (clk_id) {
+ case I2S3_MCLKOUT_TX:
+ con = readl(>clksel_con[21]);
+ src = (con & I2S3_MCLKOUT_TX_SEL_MASK) >>
+ I2S3_MCLKOUT_TX_SEL_SHIFT;
+ if (src == I2S3_MCLKOUT_TX_SEL_12M)
+ p_rate = 1200;
+ else
+ p_rate = rk3568_i2s3_get_rate(priv, MCLK_I2S3_2CH_TX);
+ return p_rate;
+ case I2S3_MCLKOUT_RX:
+ con = readl(>clksel_con[83]);
+ src = (con & I2S3_MCLKOUT_TX_SEL_MASK) >>
+ I2S3_MCLKOUT_TX_SEL_SHIFT;
+ if (src == I2S3_MCLKOUT_TX_SEL_12M)
+ p_rate = 1200;
+ else
+ p_rate = rk3568_i2s3_get_rate(priv, MCLK_I2S3_2CH_RX);
+ return p_rate;
+ case I2S3_MCLKOUT:
+ con = readl(>soc_con2);
+ src = (con & I2S3_MCLKOUT_SEL_MASK)
+ >> I2S3_MCLKOUT_SEL_SHIFT;
+ if (src == I2S3_MCLKOUT_SEL_RX)
+ p_rate = rk3568_i2s3_get_rate(priv, I2S3_MCLKOUT_RX);
+ else
+ p_rate = rk3568_i2s3_get_rate(priv, I2S3_MCLKOUT_TX);
+ return p_rate;
+ case MCLK_I2S3_2CH_RX:
+ reg = 83;
+ break;
+ case MCLK_I2S3_2CH_TX:
+ reg = 21;
+ break;
+ default:
+ return -ENOENT;
+ }
+
+ con = readl(>clksel_con[reg]);
+ src = (con & CLK_I2S3_SEL_MASK) >> CLK_I2S3_SEL_SHIFT;
+ div = (con & CLK_I2S3_SRC_DIV_MASK) >> CLK_I2S3_SRC_DIV_SHIFT;
+ p_src
Re: [PATCH 07/25] tegra: Change #ifdef for nop
On 10/10/23 10:42, Simon Glass wrote:
Hi Sean,
On Mon, 9 Oct 2023 at 17:40, Sean Anderson wrote:
On 10/9/23 11:32, Simon Glass wrote:
Hi Sean,
On Sat, 7 Oct 2023 at 17:21, Sean Anderson wrote:
On 10/7/23 19:10, Simon Glass wrote:
Hi Tom.
On Sun, 24 Sept 2023 at 18:43, Tom Rini wrote:
On Sun, Sep 24, 2023 at 02:39:25PM -0600, Simon Glass wrote:
This code is normally compiled for Tegra, but sandbox can also compile
it. We should not use UNIT_TEST as a synonym for SANDBOX, since it is
possible to disable UNIT_TEST for sandbox.
Correct the condition.
Signed-off-by: Simon Glass
---
include/k210/pll.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/k210/pll.h b/include/k210/pll.h
index fd16a89cb203..6dd60b2eb4fc 100644
--- a/include/k210/pll.h
+++ b/include/k210/pll.h
@@ -13,7 +13,7 @@ struct k210_pll_config {
u8 od;
};
-#ifdef CONFIG_UNIT_TEST
+#ifdef CONFIG_SANDBOX
TEST_STATIC int k210_pll_calc_config(u32 rate, u32 rate_in,
struct k210_pll_config *best);
#ifndef nop
Tegra? Do you mean sifive? That's where CLK_K210 stuff is... but it
Oh yes, I got confused.
also seems wrong, you can run unit test on real hardware, and this is a
test that could (should?) be run on that platform.
Only if it enables UNIT_TEST. You cannot run unit tests without that.
The current tests are designed for sandbox.
FWIW I have run this test on actual hardware. My intent here was to allow
unit tests to access functions which would otherwise be declared static.
Er, with or without UNIT_TEST enabled? How can it even build if this
declaration is only for sandbox?
With UNIT_TEST of course. Although since this is a forward-declaration, the
UNIT_TEST ifdef isn't really even necessary. If it's on actual hardware, nop
should already be defined. So maybe this should be something like
#if CONFIG_SANDBOX
#define nop()
#endif
It is the CONFIG_SANDBOX that I am trying to remove. Can it be
CONFIG_UNIT_TEST instead?
Well, you can just remove the `ifdef UNIT_TEST` then.
--Sean
[PATCH 2/4] rockchip: rk3588-rock-5b: Enable support for PCIe SATA cards
Enable support for PCIe SATA cards and the on-board SATA controller. This also revert use of CONFIG_PCI_INIT_R in order to speed up boot from eMMC or SD-cards. Standard boot will initialize pci after faster boot media have been enumerated. Signed-off-by: Jonas Karlman --- Cc: Christopher Obbard --- configs/rock5b-rk3588_defconfig | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig index 447913faccc4..ec22e70033a0 100644 --- a/configs/rock5b-rk3588_defconfig +++ b/configs/rock5b-rk3588_defconfig @@ -26,6 +26,7 @@ CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0xc00800 CONFIG_PCI=y CONFIG_DEBUG_UART=y +CONFIG_AHCI=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_SPL_FIT_SIGNATURE=y @@ -35,7 +36,6 @@ CONFIG_OF_BOARD_SETUP=y CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-rock-5b.dtb" # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y -CONFIG_PCI_INIT_R=y CONFIG_SPL_MAX_SIZE=0x4 CONFIG_SPL_PAD_TO=0x7f8000 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y @@ -63,6 +63,8 @@ CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigne CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_REGMAP=y CONFIG_SPL_SYSCON=y +CONFIG_AHCI_PCI=y +CONFIG_DWC_AHCI=y CONFIG_SPL_CLK=y # CONFIG_USB_FUNCTION_FASTBOOT is not set CONFIG_ROCKCHIP_GPIO=y @@ -89,6 +91,8 @@ CONFIG_SPL_PINCTRL=y CONFIG_REGULATOR_PWM=y CONFIG_PWM_ROCKCHIP=y CONFIG_SPL_RAM=y +CONFIG_SCSI=y +CONFIG_DM_SCSI=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_SYS_NS16550_MEM32=y -- 2.42.0
[PATCH 4/4] usb: dwc3-generic: Use combined glue and ctrl node for RK3588
Like Rockchip RK3328 and RK3568, the RK3588 also have single node to
represent the glue and ctrl for USB 3.0.
Use rk_ops as driver data to select correct ctrl node for RK3588 DWC3.
Signed-off-by: Jonas Karlman
---
drivers/usb/dwc3/dwc3-generic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 744fde806948..6fb2de8a5ace 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -610,6 +610,7 @@ static const struct udevice_id dwc3_glue_ids[] = {
{ .compatible = "rockchip,rk3328-dwc3", .data = (ulong)_ops },
{ .compatible = "rockchip,rk3399-dwc3" },
{ .compatible = "rockchip,rk3568-dwc3", .data = (ulong)_ops },
+ { .compatible = "rockchip,rk3588-dwc3", .data = (ulong)_ops },
{ .compatible = "qcom,dwc3" },
{ .compatible = "fsl,imx8mp-dwc3", .data = (ulong)_ops },
{ .compatible = "fsl,imx8mq-dwc3" },
--
2.42.0
[PATCH 0/4] rockchip: rk3588: Sync pcie and usb3 nodes from linux
This series sync rk3588 device tree nodes from latest mainline linux maintainer tree and also update usb3 nodes with latest submitted patches. Patch 1 sync latest device tree from latest linux maintainer tree to move pcie and spi flash nodes away from -u-boot.dtsi files. Patch 2 fully enable pcie and ahci/sata support on rk3588-rock-5b. Patch 3 sync usb3 nodes with latest pending patches in order to drop use of rockchip,rk3399-dwc3 compatible. Patch 4 adds support for rockchip,rk3588-dwc3 compatible to the dwc3-generic driver. Jonas Karlman (4): rockchip: rk3588: Sync device tree from linux maintainer tree rockchip: rk3588-rock-5b: Enable support for PCIe SATA cards rockchip: rk3588-rock-5b: Sync USB3 nodes from mainline linux patches usb: dwc3-generic: Use combined glue and ctrl node for RK3588 arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi | 11 +- arch/arm/dts/rk3588-evb1-v10.dts | 98 +++ arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 204 +-- arch/arm/dts/rk3588-rock-5b.dts | 140 arch/arm/dts/rk3588-u-boot.dtsi | 40 ++--- arch/arm/dts/rk3588s-pinctrl.dtsi| 44 + arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 4 - arch/arm/dts/rk3588s-u-boot.dtsi | 78 + arch/arm/dts/rk3588s.dtsi| 11 ++ configs/rock5b-rk3588_defconfig | 7 +- drivers/usb/dwc3/dwc3-generic.c | 1 + 11 files changed, 397 insertions(+), 241 deletions(-) -- 2.42.0
[PATCH 3/4] rockchip: rk3588-rock-5b: Sync USB3 nodes from mainline linux patches
The device tree for rk3588 and rock-5b contain usb3 nodes that have
deviated too much from current state of submitted mainline linux usb3
patches, see [1].
Sync usb3 related nodes from latest patches and collaboras rk3588 tree
so that dwc3-generic driver can be updated to include support for the
rockchip,rk3588-dwc3 compatible.
[1]
https://lore.kernel.org/lkml/20231009172129.43568-1-sebastian.reic...@collabora.com/
Signed-off-by: Jonas Karlman
---
Cc: Sebastian Reichel
---
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 148 +++-
arch/arm/dts/rk3588-u-boot.dtsi | 39 +++
arch/arm/dts/rk3588s-u-boot.dtsi| 68 ++-
configs/rock5b-rk3588_defconfig | 1 -
4 files changed, 99 insertions(+), 157 deletions(-)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 3f390ef26a3f..b595ddef7028 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -19,38 +19,10 @@
regulator-min-microvolt = <1200>;
regulator-max-microvolt = <1200>;
};
+};
- vcc5v0_usbdcin: vcc5v0-usbdcin {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_usbdcin";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- vin-supply = <_dcin>;
- };
-
- vcc5v0_usb: vcc5v0-usb {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_usb";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- vin-supply = <_usbdcin>;
- };
-
- vbus5v0_typec: vbus5v0-typec {
- compatible = "regulator-fixed";
- regulator-name = "vbus5v0_typec";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- enable-active-high;
- gpio = < RK_PB6 GPIO_ACTIVE_HIGH>;
- vin-supply = <_usb>;
- pinctrl-names = "default";
- pinctrl-0 = <_pwren>;
- };
+_psu {
+ status = "okay";
};
_pins {
@@ -58,13 +30,9 @@
};
{
- usb-typec {
+ usb {
usbc0_int: usbc0-int {
- rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO _pull_up>;
- };
-
- typec5v_pwren: typec5v-pwren {
- rockchip,pins = <2 RK_PB6 RK_FUNC_GPIO _pull_none>;
+ rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO _pull_none>;
};
};
};
@@ -97,7 +65,6 @@
};
_otg {
- rockchip,typec-vbus-det;
status = "okay";
};
@@ -109,25 +76,17 @@
status = "okay";
};
-_grf {
+_phy1 {
status = "okay";
};
-_grf {
+_phy1_u3 {
status = "okay";
};
-_host0_ehci {
- companion = <_host0_ohci>;
-};
-
-_host1_ehci {
- companion = <_host1_ohci>;
-};
-
_phy0 {
orientation-switch;
- svid = <0xff01>;
+ mode-switch;
sbu1-dc-gpios = < RK_PA6 GPIO_ACTIVE_HIGH>;
sbu2-dc-gpios = < RK_PA7 GPIO_ACTIVE_HIGH>;
status = "okay";
@@ -135,14 +94,15 @@
port {
#address-cells = <1>;
#size-cells = <0>;
- usbdp_phy0_orientation_switch: endpoint@0 {
+
+ usbdp_phy0_typec_ss: endpoint@0 {
reg = <0>;
- remote-endpoint = <_orien_sw>;
+ remote-endpoint = <_ss>;
};
- usbdp_phy0_dp_altmode_mux: endpoint@1 {
+ usbdp_phy0_typec_sbu: endpoint@1 {
reg = <1>;
- remote-endpoint = <_altmode_mux>;
+ remote-endpoint = <_sbu>;
};
};
};
@@ -151,84 +111,53 @@
status = "okay";
};
-_phy1 {
- rockchip,dp-lane-mux = <2 3>;
+_host0_xhci {
+ usb-role-switch;
status = "okay";
-};
-_phy1_u3 {
- status = "okay";
-};
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
-_0 {
- status = "okay";
+ usb_host0_xhci_drd_sw: endpoint {
+ remote-endpoint = <_hs>;
+ };
+ };
};
-_1 {
+_host1_xhci {
status = "okay";
};
-_dwc3_0 {
- usb-role-switch;
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
- dwc3_0_role_switch: endpoint@0 {
- reg = <0>;
- remote-endpoint = <_role_sw>;
- };
- };
+_host2_xhci {
+ status = "okay";
};
{
+ pinctrl-names = "default";
pinctrl-0 = <_xfer>;
status =
[PATCH 1/4] rockchip: rk3588: Sync device tree from linux maintainer tree
Sync rk3588 device tree from linux maintainer tree (v6.7-armsoc/dts64).
Adds PCIe nodes to rk3588-evb1-v10 and rk3588-rock-5b boards. Also
remove includes from u-boot.dtsi-files that is no longer needed.
Linux commits:
42145b7a8235 ("arm64: dts: rockchip: add PCIe network controller to rock-5b")
199cbd5f195a ("arm64: dts: rockchip: add PCIe for M.2 M-key to rock-5b")
da447ec38780 ("arm64: dts: rockchip: add PCIe for M.2 E-Key to rock-5b")
86a2024d95e2 ("arm64: dts: rockchip: add PCIe2 network controller to
rk3588-evb1")
46bb398ea1d8 ("arm64: dts: rockchip: add PCIe3 bus to rk3588-evb1")
1c9a53ff7ece ("arm64: dts: rockchip: Add sdio node to rock-5b")
3eaf2abd11aa ("arm64: dts: rockchip: Add sfc node to rk3588s")
bf012368bb0a ("arm64: dts: rockchip: Add I2S2 M0 pin definitions to rk3588s")
3d77a3e51b0f ("arm64: dts: rockchip: Add UART9 M0 pin definitions to rk3588s")
Signed-off-by: Jonas Karlman
---
arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi | 11 +-
arch/arm/dts/rk3588-evb1-v10.dts | 98
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 60 --
arch/arm/dts/rk3588-rock-5b.dts | 140 +++
arch/arm/dts/rk3588-u-boot.dtsi | 1 -
arch/arm/dts/rk3588s-pinctrl.dtsi| 44 +++
arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 4 -
arch/arm/dts/rk3588s-u-boot.dtsi | 10 --
arch/arm/dts/rk3588s.dtsi| 11 ++
9 files changed, 294 insertions(+), 85 deletions(-)
diff --git a/arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi
b/arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi
index bd2e25948633..e8566785e965 100644
--- a/arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi
@@ -6,16 +6,7 @@
#include "rk3588-u-boot.dtsi"
/ {
- aliases {
- mmc0 =
- mmc1 =
- };
-
chosen {
- u-boot,spl-boot-order =
+ u-boot,spl-boot-order = "same-as-spl",
};
};
-
- {
- bootph-all;
-};
diff --git a/arch/arm/dts/rk3588-evb1-v10.dts b/arch/arm/dts/rk3588-evb1-v10.dts
index 229a9111f5eb..c3fe58e39e99 100644
--- a/arch/arm/dts/rk3588-evb1-v10.dts
+++ b/arch/arm/dts/rk3588-evb1-v10.dts
@@ -29,6 +29,46 @@
pwms = < 0 25000 0>;
};
+ pcie20_avdd0v85: pcie20-avdd0v85-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie20_avdd0v85";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <85>;
+ regulator-max-microvolt = <85>;
+ vin-supply = <_0v85_s0>;
+ };
+
+ pcie20_avdd1v8: pcie20-avdd1v8-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie20_avdd1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ vin-supply = <_1v8_s0>;
+ };
+
+ pcie30_avdd0v75: pcie30-avdd0v75-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie30_avdd0v75";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <75>;
+ regulator-max-microvolt = <75>;
+ vin-supply = <_0v75_s0>;
+ };
+
+ pcie30_avdd1v8: pcie30-avdd1v8-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie30_avdd1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ vin-supply = <_1v8_s0>;
+ };
+
vcc12v_dcin: vcc12v-dcin-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc12v_dcin";
@@ -38,6 +78,19 @@
regulator-max-microvolt = <1200>;
};
+ vcc3v3_pcie30: vcc3v3-pcie30-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_pcie30";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ enable-active-high;
+ gpios = < RK_PC3 GPIO_ACTIVE_HIGH>;
+ startup-delay-us = <5000>;
+ vin-supply = <_dcin>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pcie30_en>;
+ };
+
vcc5v0_host: vcc5v0-host-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc5v0_host";
@@ -87,6 +140,10 @@
status = "okay";
};
+_psu {
+ status = "okay";
+};
+
_b0 {
cpu-supply = <_cpu_big0_s0>;
};
@@ -163,7 +220,32 @@
};
};
+ {
+ reset-gpios = < RK_PA2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_1_rst>, <_isolate>;
+
Re: [PATCH] arm: mach-apple: Move M1/M2 specifics into a separate folder
> Date: Tue, 29 Aug 2023 22:13:53 +0300
> From: Ivaylo Ivanov
>
> I'm currently working on S5L8950X. I also have some T7000 and T8010
> devices that I'll work on in the future.
>
> There's a project called freemyipod that has a fork of U-Boot working on
> iPod Nano's (specifically the S5L8730 in the iPod Nano 5). I've read
> that they're planning on upstreaming it in the near future.
ok, well, most of the code you're moving isn't really M1/M2 specific.
Apple uses RTKit all over the place. And some of the SoCs you mention
are really close to M1/M2. And the older ones have a lot of Samsung
heritage so I'm not sure they belong under mach-apple ...
Also, unless you actually have code to support other Apple SoCs, this
just causes disruption for upstreaming more of the M1/M2 code. So I
think this is best left alone until you actually show your code and we
can see how to integrate it.
>
> On 8/29/23 20:43, Mark Kettenis wrote:
> >> From: ivo.iva...@null.net
> >> Date: Tue, 29 Aug 2023 20:25:19 +0300
> >>
> >> From: Ivaylo Ivanov
> >>
> >> Currently, mach-apple assumes we're working with M1/M2. Make room for
> >> adding support for other Apple SoCs by moving everything from the M1/M2
> >> SoC family in "mach-apple/" into "mach-apple/m1/".
> >
> > Which other Apple SoCs?
> >
> >> Signed-off-by: Ivaylo Ivanov
> >> ---
> >> arch/arm/Kconfig | 29 --
> >> arch/arm/mach-apple/Kconfig | 42
> >> arch/arm/mach-apple/Makefile | 5 +--
> >> arch/arm/mach-apple/m1/Makefile | 6 +++
> >> arch/arm/mach-apple/{ => m1}/board.c | 0
> >> arch/arm/mach-apple/{ => m1}/lowlevel_init.S | 0
> >> arch/arm/mach-apple/{ => m1}/rtkit.c | 0
> >> arch/arm/mach-apple/{ => m1}/sart.c | 0
> >> configs/apple_m1_defconfig | 1 +
> >> 9 files changed, 50 insertions(+), 33 deletions(-)
> >> create mode 100644 arch/arm/mach-apple/m1/Makefile
> >> rename arch/arm/mach-apple/{ => m1}/board.c (100%)
> >> rename arch/arm/mach-apple/{ => m1}/lowlevel_init.S (100%)
> >> rename arch/arm/mach-apple/{ => m1}/rtkit.c (100%)
> >> rename arch/arm/mach-apple/{ => m1}/sart.c (100%)
> >>
> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> index 97c25b4f14..5339da370c 100644
> >> --- a/arch/arm/Kconfig
> >> +++ b/arch/arm/Kconfig
> >> @@ -980,38 +980,9 @@ config ARCH_NPCM
> >>
> >> config ARCH_APPLE
> >>bool "Apple SoCs"
> >> - select ARM64
> >> - select CLK
> >> - select CMD_PCI
> >> - select CMD_USB
> >>select DM
> >> - select DM_GPIO
> >> - select DM_KEYBOARD
> >> - select DM_MAILBOX
> >>select DM_RESET
> >>select DM_SERIAL
> >> - select DM_SPI
> >> - select DM_USB
> >> - select VIDEO
> >> - select IOMMU
> >> - select LINUX_KERNEL_IMAGE_HEADER
> >> - select OF_BOARD_SETUP
> >> - select OF_CONTROL
> >> - select PCI
> >> - select PINCTRL
> >> - select POSITION_INDEPENDENT
> >> - select POWER_DOMAIN
> >> - select REGMAP
> >> - select SPI
> >> - select SYSCON
> >> - select SYSRESET
> >> - select SYSRESET_WATCHDOG
> >> - select SYSRESET_WATCHDOG_AUTO
> >> - select USB
> >> - imply CMD_DM
> >> - imply CMD_GPT
> >> - imply DISTRO_DEFAULTS
> >> - imply OF_HAS_PRIOR_STAGE
> >>
> >> config ARCH_OWL
> >>bool "Actions Semi OWL SoCs"
> >> diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig
> >> index 294690ec0e..a38779b387 100644
> >> --- a/arch/arm/mach-apple/Kconfig
> >> +++ b/arch/arm/mach-apple/Kconfig
> >> @@ -3,6 +3,46 @@ if ARCH_APPLE
> >> config TEXT_BASE
> >>default 0x
> >>
> >> +choice
> >> + prompt "Apple Silicon architecture type select"
> >> + optional
> >> +
> >> +config ARCH_APPLE_M1
> >> + bool "Apple M1/M2 SoC family"
> >> + select ARM64
> >> + select CLK
> >> + select CMD_PCI
> >> + select CMD_USB
> >> + select DM_GPIO
> >> + select DM_KEYBOARD
> >> + select DM_MAILBOX
> >> + select DM_SPI
> >> + select DM_USB
> >> + select VIDEO
> >> + select IOMMU
> >> + select LINUX_KERNEL_IMAGE_HEADER
> >> + select OF_BOARD_SETUP
> >> + select OF_CONTROL
> >> + select PCI
> >> + select PINCTRL
> >> + select POSITION_INDEPENDENT
> >> + select POWER_DOMAIN
> >> + select REGMAP
> >> + select SPI
> >> + select SYSCON
> >> + select SYSRESET
> >> + select SYSRESET_WATCHDOG
> >> + select SYSRESET_WATCHDOG_AUTO
> >> + select USB
> >> + imply CMD_DM
> >> + imply CMD_GPT
> >> + imply DISTRO_DEFAULTS
> >> + imply OF_HAS_PRIOR_STAGE
> >> +
> >> +endchoice
> >> +
> >> +if ARCH_APPLE_M1
> >> +
> >> config SYS_CONFIG_NAME
> >>default "apple"
> >>
> >> @@ -19,3 +59,5 @@ config LNX_KRNL_IMG_TEXT_OFFSET_BASE
> >>default TEXT_BASE
> >>
> >> endif
> >> +
> >> +endif
> >> diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
> >> index 50b465b947..d147ccdde2 100644
> >> --- a/arch/arm/mach-apple/Makefile
> >> +++ b/arch/arm/mach-apple/Makefile
> >> @@ -1,6 +1,3 @@
Re: [PATCH 10/15] cmd: blk_common: Use macros for the return values
On Tue, Oct 10, 2023 at 08:58:04AM -0600, Simon Glass wrote:
> Hi Bin,
>
> On Tue, 10 Oct 2023 at 03:06, Bin Meng wrote:
> >
> > Hi Simon,
> >
> > On Mon, Oct 2, 2023 at 9:42 AM Simon Glass wrote:
> > >
> > > Hi Bin,
> > >
> > > On Tue, 26 Sept 2023 at 02:54, Bin Meng wrote:
> > > >
> > > > Avoid using magic number 0/1 for the command result.
> > > >
> > > > Signed-off-by: Bin Meng
> > > > ---
> > > >
> > > > cmd/blk_common.c | 14 +++---
> > > > 1 file changed, 7 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/cmd/blk_common.c b/cmd/blk_common.c
> > > > index 9f9d4327a9..ad9b16dc09 100644
> > > > --- a/cmd/blk_common.c
> > > > +++ b/cmd/blk_common.c
> > > > @@ -25,18 +25,18 @@ int blk_common_cmd(int argc, char *const argv[],
> enum uclass_id uclass_id,
> > > > case 2:
> > > > if (strncmp(argv[1], "inf", 3) == 0) {
> > > > blk_list_devices(uclass_id);
> > > > - return 0;
> > > > + return CMD_RET_SUCCESS;
> > >
> > > I really don't like this...0 is success.
> > >
> > > > } else if (strncmp(argv[1], "dev", 3) == 0) {
> > > > if (blk_print_device_num(uclass_id,
> *cur_devnump)) {
> > > > printf("\nno %s devices available\n",
> if_name);
> > > > return CMD_RET_FAILURE;
> > > > }
> > > > - return 0;
> > > > + return CMD_RET_SUCCESS;
> > > > } else if (strncmp(argv[1], "part", 4) == 0) {
> > > > if (blk_list_part(uclass_id))
> > > > printf("\nno %s partition table
> available\n",
> > > >if_name);
> > > > - return 0;
> > > > + return CMD_RET_SUCCESS;
> > > > }
> > > > return CMD_RET_USAGE;
> > > > case 3:
> > > > @@ -49,7 +49,7 @@ int blk_common_cmd(int argc, char *const argv[],
> enum uclass_id uclass_id,
> > > > } else {
> > > > return CMD_RET_FAILURE;
> > > > }
> > > > - return 0;
> > > > + return CMD_RET_SUCCESS;
> > > > } else if (strncmp(argv[1], "part", 4) == 0) {
> > > > int dev = (int)dectoul(argv[2], NULL);
> > > >
> > > > @@ -58,7 +58,7 @@ int blk_common_cmd(int argc, char *const argv[],
> enum uclass_id uclass_id,
> > > >if_name, dev);
> > > > return CMD_RET_FAILURE;
> > > > }
> > > > - return 0;
> > > > + return CMD_RET_SUCCESS;
> > > > }
> > > > return CMD_RET_USAGE;
> > > >
> > > > @@ -80,7 +80,7 @@ int blk_common_cmd(int argc, char *const argv[],
> enum uclass_id uclass_id,
> > > >
> > > > printf("%ld blocks read: %s\n", n,
> > > >n == cnt ? "OK" : "ERROR");
> > > > - return n == cnt ? 0 : 1;
> > > > + return n == cnt ? CMD_RET_SUCCESS :
> CMD_RET_FAILURE;
> > >
> > > CMD_RET_FAILURE is OK, but I would prefer not to use CMD_RET_SUCCESS.
> > > It is 0 and always will be.
> > >
> > > It encourages people to do things like:
> > >
> > > if (ret == CMD_RET_SUCCESS)
> > >
> > > instead of
> > >
> > > if (!ret)
> >
> > I see your concern. However we don't change the return value type to
> > enum, so people can still use
> >
> > if (!ret)
> >
> > I would still defend that we should use CMD_RET_SUCCESS.
> >
> > This is like EXIT_XXX defined in stdlib.h:
> >
> > #define EXIT_FAILURE 1/* Failing exit status. */
> > #define EXIT_SUCCESS 0/* Successful exit status. */
> >
> > One should use predefined macros whenever possible.
>
> I agree except for success, where I don't, sorry. It should always be 0 in
> U-Boot.
>
> People then have to look up the value and also we get things like
>
> if (ret != CMD_RET_SUCCESS)
>
> It is a slippery and I would rather not start down it.
To be clear, we have a large amount of code today that uses
CMD_RET_SUCCESS in the way this patch converts to. We do have a few
cases even of the kind of code you worry about seeing, but I think in
context clearer (it's in security or OTP fuse contexts) and the compiler
will do the right thing regardless.
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
[PATCH] rockchip: dts: rk3328: Sync rock64 device tree file from Linux
Sync the rk3328-rock64 dts from v6.6-rc5.
See Linux kernel commit for details:
03633c4ef1fb ("arm64: dts: rockchip: fix USB regulator on ROCK64")
Signed-off-by: Matwey V. Kornilov
---
arch/arm/dts/rk3328-rock64.dts | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm/dts/rk3328-rock64.dts b/arch/arm/dts/rk3328-rock64.dts
index f69a38f42d..0a27fa5271 100644
--- a/arch/arm/dts/rk3328-rock64.dts
+++ b/arch/arm/dts/rk3328-rock64.dts
@@ -37,7 +37,8 @@
vin-supply = <_io>;
};
- vcc_host_5v: vcc-host-5v-regulator {
+ /* Common enable line for all of the rails mentioned in the labels */
+ vcc_host_5v: vcc_host1_5v: vcc_otg_5v: vcc-host-5v-regulator {
compatible = "regulator-fixed";
gpio = < RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
@@ -48,17 +49,6 @@
vin-supply = <_sys>;
};
- vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
- compatible = "regulator-fixed";
- gpio = < RK_PA2 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <_host_drv>;
- regulator-name = "vcc_host1_5v";
- regulator-always-on;
- regulator-boot-on;
- vin-supply = <_sys>;
- };
-
vcc_sys: vcc-sys {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
--
2.35.3
[PATCH] firmware: scmi: Fix clearing variable
The sess variable in open_channel was not entirely
cleared to zero at the start of this function.
This commit ensures that the entire struct is cleared.
Signed-off-by: Francois Berder
---
drivers/firmware/scmi/optee_agent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/scmi/optee_agent.c
b/drivers/firmware/scmi/optee_agent.c
index db927fb214..1247d0b03e 100644
--- a/drivers/firmware/scmi/optee_agent.c
+++ b/drivers/firmware/scmi/optee_agent.c
@@ -149,7 +149,7 @@ static int open_channel(struct udevice *dev, struct
scmi_optee_channel *chan,
struct tee_param param[1] = { };
int ret;
- memset(sess, 0, sizeof(sess));
+ memset(sess, 0, sizeof(*sess));
sess->tee = tee_find_device(NULL, NULL, NULL, NULL);
if (!sess->tee)
--
2.34.1
Re: [PATCH 00/25] Tidy up use of CONFIG_CMDLINE
Hi Tom, On Sun, 24 Sept 2023 at 18:37, Tom Rini wrote: > > On Sun, Sep 24, 2023 at 02:39:18PM -0600, Simon Glass wrote: > > > It should be possible to disable CONFIG_CMDLINE and have all commands > > and related functionality dropped from U-Boot. This is useful when > > trying to reduce the size of U-Boot. > > > > Recent changes have stopped this from working. > > > > This series repairs the feature for sandbox and adds a test to stop it > > breaking again. > > > > Note that quite a lot of functionality is lost of CONFIG_CMDLINE is > > disabled, e.g. networking and most booting options. Further work is > > needed to make the option more generally useful. > > I worry there's a lot of "make it compile, deal with it later" in here > rather than unwinding so that $X works with CMDLINE disabled or we truly > must have CMDLINE. Perhaps it would be better to start with to take one > of the platforms that enables say networking in SPL, where we > functionally don't have a cmdline, and make that build with CMDLINE off. > Having *PL build and link and work with CMDLINE disabled would possibly > save some space too, which is always a good thing there. So long as it gets us closer to the goal, I think the work is valuable. Also it prevents additional regressions from creeping in, at least for sandbox. I am under no illusions about how big an effort this is, but we have to start somewhere. To me the easiest first step would be to decouple bootm functionality from the bootm command. Likely that would be <40 patches. Regards, Simon
Re: [PATCH v3 2/3] dt-bindings: mtd: binman-partition: Add binman compatibles
On Mon, Oct 09, 2023 at 04:02:40PM -0600, Simon Glass wrote:
> Hi Rob,
>
> On Mon, 9 Oct 2023 at 15:18, Rob Herring wrote:
> >
> >
> > On Mon, 09 Oct 2023 14:10:00 -0600, Simon Glass wrote:
> > > Add two compatible for binman entries, as a starting point for the
> > > schema.
> > >
> > > Note that, after discussion on v2, we decided to keep the existing
> > > meaning of label so as not to require changes to existing userspace
> > > software when moving to use binman nodes to specify the firmware
> > > layout.
> > >
> > > Signed-off-by: Simon Glass
> > > ---
> > >
> > > Changes in v3:
> > > - Drop fixed-partitions from the example
> > > - Use compatible instead of label
> > >
> > > Changes in v2:
> > > - Use plain partition@xxx for the node name
> > >
> > > .../mtd/partitions/binman-partition.yaml | 48 +++
> > > 1 file changed, 48 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml
> > >
> >
> > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> > on your patch (DT_CHECKER_FLAGS is new in v5.13):
> >
> > yamllint warnings/errors:
> >
> > dtschema/dtc warnings/errors:
> > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mtd/partitions/binman-partition.yaml:
> > properties:compatible:items: {'enum': ['u-boot', 'atf-bl31']} is not of
> > type 'array'
> > from schema $id:
> > http://devicetree.org/meta-schemas/string-array.yaml#
> >
> > doc reference errors (make refcheckdocs):
> >
> > See
> > https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231009201005.1964794-2-...@chromium.org
> >
> > The base for the series is generally the latest rc1. A different dependency
> > should be noted in *this* patch.
> >
> > If you already ran 'make dt_binding_check' and didn't see the above
> > error(s), then make sure 'yamllint' is installed and dt-schema is up to
> > date:
> >
> > pip3 install dtschema --upgrade
> >
> > Please check and re-submit after running the above command yourself. Note
> > that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> > your schema. However, it must be unset to test all examples with your
> > schema.
> >
>
> Oh dear, I didn't notice that output but I see it now. Could the check
> return a non-zero exit code if something goes wrong?
No, because things go wrong too often and then it breaks for everyone.
It's better now, but only because of the above reports and 3
maintainers.
Also, it is not fatal. The schemas are checked against the DT
meta-schema, but are used for validation if they pass just draft2019-09
meta-schema. That allows new DT meta-schema checks to not start
excluding previously used schema.
Rob
Re: [PATCH v3] cli: Consume invalid escape sequences early
Simon, On Tue, Oct 10, 2023 at 5:58 PM Simon Glass wrote: > > On Tue, 10 Oct 2023 at 02:16, Yurii Monakov wrote: > > > > Unexpected 'Esc' key presses are accumulated internally, even if it is > > already clear that the current escape sequence is invalid. This results > > in weird behaviour. For example, the next character after 'Esc' key > > simply disappears from input and 'Unknown command' is printed > > after 'Enter'. > > > > This commit fixes some issues with extra 'Esc' keys entered by user: > > > > 1. Sequence right after autoboot stop gives: > > => > > nknown command 'ry 'help' > > => > > 2. Sequence gives: > > => ri > > Unknown command 'ri' - try 'help' > > => > > 3. Extra 'Esc' key presses break backspace functionality. > > > > Signed-off-by: Yurii Monakov > > --- > > Changes for v2: > > - add tests and reword commit message > > Changes for v3: > > - fix indentation > > > > common/cli_getch.c | 2 ++ > > test/common/cread.c | 12 > > 2 files changed, 14 insertions(+) > > Reviewed-by: Simon Glass > > Unfortunately this shows a design flaw, one which is hard to fix in general. > But this does improve it. > > The flaw is that we assume that character sequences have a time gap between > them, which allows figuring out when a sequence has finished. > > But when starting up there may be buffered output with no gaps. I don't think > there is a general fix for this problem. One option is to have a special mode > at the start, where escape sequences are ignored. But the user may press an > arrow key on startup. > > So I don't have anything much to suggest here. Let's see how this fix goes. > Perhaps it is enough. > > Regards, > Simon > One option is to have a special mode at the start, where escape sequences are > ignored I think that there is no reason to emit parts of invalid escape sequences, as current code does. There is a very little chance (at least for a human being) to input such sequences by intent. > But the user may press an arrow key on startup. As a fix, autoboot code can check for 'Esc' and keep it as a part of input string. Best Regards, Yurii
Re: [PATCH 3/5] binman: capsule: Use dumped capsule header contents for verification
Hi Sughosh, On Tue, 10 Oct 2023 at 09:01, Sughosh Ganu wrote: > > hi Simon, > > On Tue, 10 Oct 2023 at 20:27, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Mon, 9 Oct 2023 at 13:41, Sughosh Ganu wrote: > > > > > > hi Simon, > > > > > > On Mon, 9 Oct 2023 at 23:27, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Mon, 9 Oct 2023 at 01:46, Sughosh Ganu > > > > wrote: > > > > > > > > > > hi Simon, > > > > > > > > > > On Sun, 8 Oct 2023 at 04:41, Simon Glass wrote: > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > On Wed, 4 Oct 2023 at 05:27, Sughosh Ganu > > > > > > wrote: > > > > > > > > > > > > > > The various fields of a generated capsule are currently verified > > > > > > > through hard-coded offsets. Use the dump-capsule feature for > > > > > > > dumping > > > > > > > the capsule header contents and use those for capsule > > > > > > > verification. > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > --- > > > > > > > tools/binman/ftest.py | 95 > > > > > > > --- > > > > > > > 1 file changed, 54 insertions(+), 41 deletions(-) > > > > > > > > > > > > This looks good apart from a few nits below. However, the tests > > > > > > fail for me. > > > > > > > > > > Can you please specify which tests fail, and the way to reproduce the > > > > > failures? I ran the tests before sending the patches, and they ran > > > > > fine, including the coverage which is 100%. Ci too did not complain. > > > > > > > > Sure, for example: > > > > > > > > $ binman test testCapsuleGen > > > > Running binman tests > > > > /usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering > > > > (buffering=1) isn't supported in binary mode, the default buffer size > > > > will be used > > > > return io.open(fd, mode, buffering, encoding, *args, **kwargs) > > > > /usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering > > > > (buffering=1) isn't supported in binary mode, the default buffer size > > > > will be used > > > > return io.open(fd, mode, buffering, encoding, *args, **kwargs) > > > > F > > > > == > > > > FAIL: binman.ftest.TestFunctional.testCapsuleGen > > > > (subunit.RemotedTestCase) > > > > binman.ftest.TestFunctional.testCapsuleGen > > > > -- > > > > testtools.testresult.real._StringException: Traceback (most recent call > > > > last): > > > > AssertionError: '6DCBD5ED-E82D-4C44-BDA1-7194199AD92A' != [] > > > > > > > > > > > > -- > > > > Ran 1 test in 0.147s > > > > > > > > FAILED (failures=1) > > > > > > That is interesting. When I run the tests, they run just fine. I had > > > tested them before sending the patches. For e.g. > > > > > > ./tools/binman/binman test testCapsuleGen > > > Running binman tests > > > . > > > -- > > > Ran 1 test in 0.375s > > > > > > OK > > > > Yes, I'm not sure what that is. Perhaps you have a required tool in your > > path? But in that case I would expect to get some sort of error. > > I don't have any special tool in my path. Just that I build tools > before invoking the tests, since the mkeficapsule tool needs to have > been present. Moreover, the tests are also passing in the CI run. So > it seems to be something specific in your setup I guess. > Yes, I suppose so...I'll try the new version and try to figure it out. Regards, Simon
Re: [RFC PATCH] clk: scmi: Provide channel information to every clock
On 10/5/23 13:49, Michal Simek wrote: When assigned-clocks/assigned-clock-rates is defined U-Boot DM core finds out leaf which is registered via clk_register(). But new clock doesn't have information about channel which is stored in private data. That's why copy parents private data (channel only now) to all childs. It will fix the issue when there is reference to clk child and operations with it. Signed-off-by: Michal Simek --- I am not really sure that this is the right way how to solve this problem. I had another patch which is pretty much written in a way if current device doesn't have private data it looks at parents private data. Anyway I am sending it as RFC to start to have discussion about it. --- drivers/clk/clk_scmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/clk_scmi.c b/drivers/clk/clk_scmi.c index d172fed24c9d..98a779fdc81b 100644 --- a/drivers/clk/clk_scmi.c +++ b/drivers/clk/clk_scmi.c @@ -12,6 +12,7 @@ #include #include #include +#include /** * struct scmi_clk_priv - Private data for SCMI clocks @@ -186,6 +187,7 @@ static int scmi_clk_probe(struct udevice *dev) return ret; } + dev_set_priv(clk->dev, dev_get_priv(dev)); clk_dm(i, clk); } } Please ignore this patch. Takahiro's series is fixing this problem https://lore.kernel.org/all/20230926065750.734440-1-takahiro.aka...@linaro.org/ Thanks, Michal
Re: [PATCH 3/5] binman: capsule: Use dumped capsule header contents for verification
hi Simon, On Tue, 10 Oct 2023 at 20:27, Simon Glass wrote: > > Hi Sughosh, > > On Mon, 9 Oct 2023 at 13:41, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Mon, 9 Oct 2023 at 23:27, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Mon, 9 Oct 2023 at 01:46, Sughosh Ganu wrote: > > > > > > > > hi Simon, > > > > > > > > On Sun, 8 Oct 2023 at 04:41, Simon Glass wrote: > > > > > > > > > > Hi Sughosh, > > > > > > > > > > On Wed, 4 Oct 2023 at 05:27, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > The various fields of a generated capsule are currently verified > > > > > > through hard-coded offsets. Use the dump-capsule feature for dumping > > > > > > the capsule header contents and use those for capsule verification. > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > --- > > > > > > tools/binman/ftest.py | 95 > > > > > > --- > > > > > > 1 file changed, 54 insertions(+), 41 deletions(-) > > > > > > > > > > This looks good apart from a few nits below. However, the tests fail > > > > > for me. > > > > > > > > Can you please specify which tests fail, and the way to reproduce the > > > > failures? I ran the tests before sending the patches, and they ran > > > > fine, including the coverage which is 100%. Ci too did not complain. > > > > > > Sure, for example: > > > > > > $ binman test testCapsuleGen > > > Running binman tests > > > /usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering > > > (buffering=1) isn't supported in binary mode, the default buffer size > > > will be used > > > return io.open(fd, mode, buffering, encoding, *args, **kwargs) > > > /usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering > > > (buffering=1) isn't supported in binary mode, the default buffer size > > > will be used > > > return io.open(fd, mode, buffering, encoding, *args, **kwargs) > > > F > > > == > > > FAIL: binman.ftest.TestFunctional.testCapsuleGen (subunit.RemotedTestCase) > > > binman.ftest.TestFunctional.testCapsuleGen > > > -- > > > testtools.testresult.real._StringException: Traceback (most recent call > > > last): > > > AssertionError: '6DCBD5ED-E82D-4C44-BDA1-7194199AD92A' != [] > > > > > > > > > -- > > > Ran 1 test in 0.147s > > > > > > FAILED (failures=1) > > > > That is interesting. When I run the tests, they run just fine. I had > > tested them before sending the patches. For e.g. > > > > ./tools/binman/binman test testCapsuleGen > > Running binman tests > > . > > -- > > Ran 1 test in 0.375s > > > > OK > > Yes, I'm not sure what that is. Perhaps you have a required tool in your > path? But in that case I would expect to get some sort of error. I don't have any special tool in my path. Just that I build tools before invoking the tests, since the mkeficapsule tool needs to have been present. Moreover, the tests are also passing in the CI run. So it seems to be something specific in your setup I guess. -sughosh
Re: [PATCH 10/15] cmd: blk_common: Use macros for the return values
Hi Bin,
On Tue, 10 Oct 2023 at 03:06, Bin Meng wrote:
>
> Hi Simon,
>
> On Mon, Oct 2, 2023 at 9:42 AM Simon Glass wrote:
> >
> > Hi Bin,
> >
> > On Tue, 26 Sept 2023 at 02:54, Bin Meng wrote:
> > >
> > > Avoid using magic number 0/1 for the command result.
> > >
> > > Signed-off-by: Bin Meng
> > > ---
> > >
> > > cmd/blk_common.c | 14 +++---
> > > 1 file changed, 7 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/cmd/blk_common.c b/cmd/blk_common.c
> > > index 9f9d4327a9..ad9b16dc09 100644
> > > --- a/cmd/blk_common.c
> > > +++ b/cmd/blk_common.c
> > > @@ -25,18 +25,18 @@ int blk_common_cmd(int argc, char *const argv[],
enum uclass_id uclass_id,
> > > case 2:
> > > if (strncmp(argv[1], "inf", 3) == 0) {
> > > blk_list_devices(uclass_id);
> > > - return 0;
> > > + return CMD_RET_SUCCESS;
> >
> > I really don't like this...0 is success.
> >
> > > } else if (strncmp(argv[1], "dev", 3) == 0) {
> > > if (blk_print_device_num(uclass_id,
*cur_devnump)) {
> > > printf("\nno %s devices available\n",
if_name);
> > > return CMD_RET_FAILURE;
> > > }
> > > - return 0;
> > > + return CMD_RET_SUCCESS;
> > > } else if (strncmp(argv[1], "part", 4) == 0) {
> > > if (blk_list_part(uclass_id))
> > > printf("\nno %s partition table
available\n",
> > >if_name);
> > > - return 0;
> > > + return CMD_RET_SUCCESS;
> > > }
> > > return CMD_RET_USAGE;
> > > case 3:
> > > @@ -49,7 +49,7 @@ int blk_common_cmd(int argc, char *const argv[],
enum uclass_id uclass_id,
> > > } else {
> > > return CMD_RET_FAILURE;
> > > }
> > > - return 0;
> > > + return CMD_RET_SUCCESS;
> > > } else if (strncmp(argv[1], "part", 4) == 0) {
> > > int dev = (int)dectoul(argv[2], NULL);
> > >
> > > @@ -58,7 +58,7 @@ int blk_common_cmd(int argc, char *const argv[],
enum uclass_id uclass_id,
> > >if_name, dev);
> > > return CMD_RET_FAILURE;
> > > }
> > > - return 0;
> > > + return CMD_RET_SUCCESS;
> > > }
> > > return CMD_RET_USAGE;
> > >
> > > @@ -80,7 +80,7 @@ int blk_common_cmd(int argc, char *const argv[],
enum uclass_id uclass_id,
> > >
> > > printf("%ld blocks read: %s\n", n,
> > >n == cnt ? "OK" : "ERROR");
> > > - return n == cnt ? 0 : 1;
> > > + return n == cnt ? CMD_RET_SUCCESS :
CMD_RET_FAILURE;
> >
> > CMD_RET_FAILURE is OK, but I would prefer not to use CMD_RET_SUCCESS.
> > It is 0 and always will be.
> >
> > It encourages people to do things like:
> >
> > if (ret == CMD_RET_SUCCESS)
> >
> > instead of
> >
> > if (!ret)
>
> I see your concern. However we don't change the return value type to
> enum, so people can still use
>
> if (!ret)
>
> I would still defend that we should use CMD_RET_SUCCESS.
>
> This is like EXIT_XXX defined in stdlib.h:
>
> #define EXIT_FAILURE 1/* Failing exit status. */
> #define EXIT_SUCCESS 0/* Successful exit status. */
>
> One should use predefined macros whenever possible.
I agree except for success, where I don't, sorry. It should always be 0 in
U-Boot.
People then have to look up the value and also we get things like
if (ret != CMD_RET_SUCCESS)
It is a slippery and I would rather not start down it.
>
> >
> > It would eventually creep into everything, including our clean error
handling.
> >
> > > } else if (strcmp(argv[1], "write") == 0) {
> > > phys_addr_t paddr = hextoul(argv[2], NULL);
> > > lbaint_t blk = hextoul(argv[3], NULL);
> > > @@ -98,7 +98,7 @@ int blk_common_cmd(int argc, char *const argv[],
enum uclass_id uclass_id,
> > >
> > > printf("%ld blocks written: %s\n", n,
> > >n == cnt ? "OK" : "ERROR");
> > > - return n == cnt ? 0 : 1;
> > > + return n == cnt ? CMD_RET_SUCCESS :
CMD_RET_FAILURE;
> > > } else {
> > > return CMD_RET_USAGE;
> > > }
> > > --
Regards,
Re: [PATCH v3] cli: Consume invalid escape sequences early
On Tue, 10 Oct 2023 at 02:16, Yurii Monakov wrote: > > Unexpected 'Esc' key presses are accumulated internally, even if it is > already clear that the current escape sequence is invalid. This results > in weird behaviour. For example, the next character after 'Esc' key > simply disappears from input and 'Unknown command' is printed > after 'Enter'. > > This commit fixes some issues with extra 'Esc' keys entered by user: > > 1. Sequence right after autoboot stop gives: > => > nknown command 'ry 'help' > => > 2. Sequence gives: > => ri > Unknown command 'ri' - try 'help' > => > 3. Extra 'Esc' key presses break backspace functionality. > > Signed-off-by: Yurii Monakov > --- > Changes for v2: > - add tests and reword commit message > Changes for v3: > - fix indentation > > common/cli_getch.c | 2 ++ > test/common/cread.c | 12 > 2 files changed, 14 insertions(+) Reviewed-by: Simon Glass Unfortunately this shows a design flaw, one which is hard to fix in general. But this does improve it. The flaw is that we assume that character sequences have a time gap between them, which allows figuring out when a sequence has finished. But when starting up there may be buffered output with no gaps. I don't think there is a general fix for this problem. One option is to have a special mode at the start, where escape sequences are ignored. But the user may press an arrow key on startup. So I don't have anything much to suggest here. Let's see how this fix goes. Perhaps it is enough. Regards, Simon
Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot
Hi Peter, On Sun, 8 Oct 2023 at 14:20, Simon Glass wrote: > > Hi Peter, > > On Sun, 8 Oct 2023 at 12:02, Peter Robinson wrote: > > > > Hi Simon, > > > > > > So with more testing of 2023.10 in Fedora we found a regression where > > > > the display dies when the vc4 module loads in the kernel. With further > > > > debug it was found that it was due to the new U-Boot and with > > > > bisecting it myself I have found this series is the cause of the > > > > regression. > > > > > > > > The testing I have done is with recent RPi firmware, U-Boot 2023.10 > > > > and kernel 6.5.x, but also seen with 6.4.x, with a minimal text only > > > > image. I can also reproduce it by using the F-38 GA image, no updates > > > > and purely just changing the U-Boot component. I've done my testing on > > > > the RPi4. > > > > > > > > Let me know if you need more information, I believe you have a RPi you > > > > can test with. > > > > > > Thanks for the report. Which rpi should I test with? I take it that > > > vc4 is a kernel module? Do you have the error message? > > > > Well I've been testing on the RPi4 (as I mentioned above), there's no > > direct error message that's directly linked but the screen goes blank > > and turns off, even on a text only install, and yes, on the rpi4 the > > vc4 kernel module deals with driving the HDMI and other output > > interfaces (whereas the v3d is the driver for the render unit), and on > > rpi3 and older vc4 also runs the 3D render module too. > > OK I have an rpi4, but I don't get that far: > > >>> > U-Boot 2023.10-00111-g7d1e5aacdb4 (Oct 08 2023 - 14:14:10 -0600) > > DRAM: 948 MiB (effective 3.9 GiB) > RPI 4 Model B (0xc03111) > Core: 205 devices, 16 uclasses, devicetree: board > MMC: mmcnr@7e30: 1, mmc@7e34: 0 > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... > In:serial,usbkbd > Out: serial,vidconsole > Err: serial,vidconsole > Net: eth0: ethernet@7d58 > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > starting USB... > Bus xhci_pci: Register 5000420 NbrPorts 5 > Starting the controller > USB XHCI 1.00 > scanning bus xhci_pci for devices... 3 USB Device(s) found >scanning usb for storage devices... 1 Storage Device(s) found > Hit any key to stop autoboot: 0 > U-Boot> bootfl scan > Card did not respond to voltage select! : -110 > ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_2' with efi > Card did not respond to voltage select! : -110 > Failed to load EFI variables > ERROR: invalid device tree > Boot failed (err=-22) > <<< > > Do you know what that might be? I ask because it seems that you are > actually able to boot. > > I'll keep looking. This was apparently a corrupted uSD card as I tried again and it booted. Regards, Simon
Re: U-Boot 2023.10 does not boot from uSD on RPi4
Hi, On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet wrote: > > > > > -Original Message- > > From: Peter Robinson > > Sent: Tuesday, October 10, 2023 12:22 PM > > To: Guillaume Gardet > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass > > ; u-boot@lists.denx.de > > Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4 > > > > On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet > > wrote: > > > > > > Hi, > > > > > > U-Boot 2023.10 does not boot from uSD on RPi4. > > > This has been found on openSUSE Tumbleweed. The only diff we need is: > > > -CONFIG_OF_EMBED=y > > > +CONFIG_OF_BOARD=y > > > To use firmware provided Device Tree. But that should not affect the mmc > > behavior too much, I think. > > > > I've been booting Fedora fine on a RPi4 BUT there's issues with the display > > turning off [1] when the accelerated display modules load > > (vc4) as a result of this patch set. Can you confirm if that's the same problem > > you're seeing? > > No, that's not my problem. My issue is grub was not loaded by u-boot from uSD. > It seems more like Simon's problem: https://lists.denx.de/pipermail/u-boot/2023-October/533162.html > > @Simon, can you check if the patch below fixes your boot problem on RPi4, please? This has been reported at least twice before. There is a fix [2] which is in my queue to apply. Regarding the display problem, I got my rpi4 running again and Fedora installed, but I won't get back to it until the end of the week as I'm at osfc. Regards, Simon > > Thanks, > Guillaume > [2] https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/ > > > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > > > > > 'git bisect' points to: > > > ** > > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > > > Author: Simon Glass > > > Date: Thu Jul 27 15:54:28 2023 -0600 > > > > > > arm: rpi: Switch to standard boot > > > > > > Drop use of the distro scripts and use standard boot instead. > > > > > > We don't need to specify the mmc devices individually, since they are > > > used in order from 0 to 2, and standard boot uses that order anyway. > > > > > > Signed-off-by: Simon Glass > > > ** > > > > > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 nor RPi > > Zero 2 W): > > > ** > > > diff --git a/board/raspberrypi/rpi/rpi.env > > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644 > > > --- a/board/raspberrypi/rpi/rpi.env > > > +++ b/board/raspberrypi/rpi/rpi.env > > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > > > fdt_addr_r=0x0260 > > > ramdisk_addr_r=0x0270 > > > > > > -boot_targets=mmc usb pxe dhcp > > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > > > ** > > > > > > So, the comment from Simon " We don't need to specify the mmc devices > > individually, since they are used in order from 0 to 2, and standard boot uses that > > order anyway" seems wrong for the RPi4 case. > > > > > > Cheers, > > > Guillaume > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > > confidential and may also be privileged. If you are not the intended recipient, > > please notify the sender immediately and do not disclose the contents to any > > other person, use it for any purpose, or store or copy the information in any > > medium. Thank you. > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [PATCH v3 5/9] board_f: Fix corruption of relocaddr
Hi Devarsh,
On Fri, 22 Sept 2023 at 15:49, Devarsh Thakkar wrote:
>
> Hi Simon,
>
> On 22/09/23 23:57, Simon Glass wrote:
> > Hi Devarsh,
> >
> > On Tue, 12 Sept 2023 at 08:35, Devarsh Thakkar wrote:
> >>
> >> Hi Simon,
> >>
> >> On 11/09/23 04:44, Simon Glass wrote:
> >>> Hi Devarsh,
> >>>
> >>> On Thu, 17 Aug 2023 at 09:10, Tom Rini wrote:
>
> On Wed, Aug 16, 2023 at 09:16:05PM +0530, Devarsh Thakkar wrote:
> > Hi Simon,
> >
> > On 15/08/23 20:14, Simon Glass wrote:
> >> Hi Devarsh,
> >>
> >> On Tue, 15 Aug 2023 at 03:23, Devarsh Thakkar
wrote:
> >>>
> >>> Hi Simon, Tom,
> >>>
> >>> On 15/08/23 04:13, Simon Glass wrote:
> Hi Devarsh, Nikhil, Tom,
>
> On Wed, 9 Aug 2023 at 09:29, Bin Meng wrote:
> >
> > On Thu, Aug 3, 2023 at 7:03 PM Bin Meng
wrote:
> >>
> >> On Thu, Aug 3, 2023 at 6:37 PM Bin Meng
wrote:
> >>>
> >>> On Tue, Aug 1, 2023 at 12:00 AM Simon Glass
wrote:
>
> When the video framebuffer comes from the bloblist, we
should not change
> relocaddr to this address, since it interfers with the
normal memory
> >>>
> >>> typo: interferes
> >>>
> allocation.
>
> This fixes a boot loop in qemu-x86_64
>
> Signed-off-by: Simon Glass
> Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info
from SPL to u-boot")
> Suggested-by: Nikhil M Jain
> ---
>
> Changes in v3:
> - Reword the Kconfig help as suggested
>
> Changes in v2:
> - Add a Kconfig as the suggested conditional did not work
>
> common/board_f.c | 3 ++-
> drivers/video/Kconfig | 9 +
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/common/board_f.c b/common/board_f.c
> index 7d2c380e91e..5173d0a0c2d 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -419,7 +419,8 @@ static int reserve_video(void)
> if (!ho)
> return log_msg_ret("blf", -ENOENT);
> video_reserve_from_bloblist(ho);
> - gd->relocaddr = ho->fb;
> + if (IS_ENABLED(CONFIG_VIDEO_RESERVE_SPL))
> + gd->relocaddr = ho->fb;
> } else if (CONFIG_IS_ENABLED(VIDEO)) {
> ulong addr;
> int ret;
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index b41dc60cec5..f2e56204d52 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -1106,6 +1106,15 @@ config SPL_VIDEO_REMOVE
> if this option is enabled video driver will be
removed at the end of
> SPL stage, beforeloading the next stage.
>
> +config VIDEO_RESERVE_SPL
> + bool
> + help
> + This adjusts reserve_video() to redirect memory
reservation when it
> + sees a video handoff blob
(BLOBLISTT_U_BOOT_VIDEO). This avoids the
> + memory used for framebuffer from being allocated
by U-Boot proper,
> + thus preventing any further memory reservations
done by U-Boot proper
> + from overwriting the framebuffer.
> +
> if SPL_SPLASH_SCREEN
>
> config SPL_SPLASH_SCREEN_ALIGN
> >>>
> >>> Reviewed-by: Bin Meng
> >>
> >> applied to u-boot-x86, thanks!
> >
> > Dropped this one from the x86 queue per the discussion.
>
> I just wanted to come back to this discussion.
>
> Do we have an agreed way forward? Who is waiting for who?
>
> >>>
> >>> I was waiting on feedback on
> >>>
https://lore.kernel.org/all/3b1e8005-f161-8058-13e7-3de2316aa...@ti.com/
> >>> but per my opinion, I would prefer to go with "Approach 2" with a
> >>> Kconfig as it looks simpler to me. It would look something like
below :
> >>>
> >>> if (gd->relocaddr > (unsigned long)ho->fb) {
> >>>ulong fb_reloc_gap = gd->relocaddr - gd->ho->fb;
> >>>
> >>>/* Relocate after framebuffer area if nearing too close to
it */
> >>>if (fb_reloc_gap < CONFIG_BLOBLIST_FB_RELOC_MIN_GAP)
> >>> gd->relocaddr = ho->fb;
> >>> }
> >>>
> >>> Regarding CONFIG_BLOBLIST_FB_RELOC_MIN_GAP
> >>> -> This describes minimum gap to keep between
Re: [PATCH] malloc: Enable assertions if UNIT_TEST is enabled
On Sat, 7 Oct 2023 at 20:02, Sean Anderson wrote: > > dlmalloc has some sanity checks it performs on free() which can help detect > memory corruption. However, they are only enabled if DEBUG is defined before > including common.h. Define DEBUG earlier if UNIT_TEST is enabled so that > assertions are enabled in sandbox. > > Signed-off-by: Sean Anderson > --- > > common/dlmalloc.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH] net: Add option for tracing packets
On Sat, 7 Oct 2023 at 20:01, Sean Anderson wrote: > > Add an option to trace all packets send/received. This can be helpful when > debugging protocol issues, as the packets can then be imported into > wireshark [1] and analyzed further. > > [1] https://www.wireshark.org/docs/wsug_html_chunked/ChIOImportSection.html > > Signed-off-by: Sean Anderson > --- > > include/net.h | 4 > net/net.c | 3 +++ > 2 files changed, 7 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH 3/5] binman: capsule: Use dumped capsule header contents for verification
Hi Sughosh, On Mon, 9 Oct 2023 at 13:41, Sughosh Ganu wrote: > > hi Simon, > > On Mon, 9 Oct 2023 at 23:27, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Mon, 9 Oct 2023 at 01:46, Sughosh Ganu wrote: > > > > > > hi Simon, > > > > > > On Sun, 8 Oct 2023 at 04:41, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Wed, 4 Oct 2023 at 05:27, Sughosh Ganu wrote: > > > > > > > > > > The various fields of a generated capsule are currently verified > > > > > through hard-coded offsets. Use the dump-capsule feature for dumping > > > > > the capsule header contents and use those for capsule verification. > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > --- > > > > > tools/binman/ftest.py | 95 --- > > > > > 1 file changed, 54 insertions(+), 41 deletions(-) > > > > > > > > This looks good apart from a few nits below. However, the tests fail for me. > > > > > > Can you please specify which tests fail, and the way to reproduce the > > > failures? I ran the tests before sending the patches, and they ran > > > fine, including the coverage which is 100%. Ci too did not complain. > > > > Sure, for example: > > > > $ binman test testCapsuleGen > > Running binman tests > > /usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used > > return io.open(fd, mode, buffering, encoding, *args, **kwargs) > > /usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used > > return io.open(fd, mode, buffering, encoding, *args, **kwargs) > > F > > == > > FAIL: binman.ftest.TestFunctional.testCapsuleGen (subunit.RemotedTestCase) > > binman.ftest.TestFunctional.testCapsuleGen > > -- > > testtools.testresult.real._StringException: Traceback (most recent call last): > > AssertionError: '6DCBD5ED-E82D-4C44-BDA1-7194199AD92A' != [] > > > > > > -- > > Ran 1 test in 0.147s > > > > FAILED (failures=1) > > That is interesting. When I run the tests, they run just fine. I had > tested them before sending the patches. For e.g. > > ./tools/binman/binman test testCapsuleGen > Running binman tests > . > -- > Ran 1 test in 0.375s > > OK Yes, I'm not sure what that is. Perhaps you have a required tool in your path? But in that case I would expect to get some sort of error. [..] Regards, Simon
Re: [PATCH 07/25] tegra: Change #ifdef for nop
Hi Sean,
On Mon, 9 Oct 2023 at 17:40, Sean Anderson wrote:
>
> On 10/9/23 11:32, Simon Glass wrote:
> > Hi Sean,
> >
> > On Sat, 7 Oct 2023 at 17:21, Sean Anderson wrote:
> >>
> >> On 10/7/23 19:10, Simon Glass wrote:
> >>> Hi Tom.
> >>>
> >>> On Sun, 24 Sept 2023 at 18:43, Tom Rini wrote:
>
> On Sun, Sep 24, 2023 at 02:39:25PM -0600, Simon Glass wrote:
>
> > This code is normally compiled for Tegra, but sandbox can also compile
> > it. We should not use UNIT_TEST as a synonym for SANDBOX, since it is
> > possible to disable UNIT_TEST for sandbox.
> >
> > Correct the condition.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> >include/k210/pll.h | 2 +-
> >1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/k210/pll.h b/include/k210/pll.h
> > index fd16a89cb203..6dd60b2eb4fc 100644
> > --- a/include/k210/pll.h
> > +++ b/include/k210/pll.h
> > @@ -13,7 +13,7 @@ struct k210_pll_config {
> > u8 od;
> >};
> >
> > -#ifdef CONFIG_UNIT_TEST
> > +#ifdef CONFIG_SANDBOX
> >TEST_STATIC int k210_pll_calc_config(u32 rate, u32 rate_in,
> > struct k210_pll_config *best);
> >#ifndef nop
>
> Tegra? Do you mean sifive? That's where CLK_K210 stuff is... but it
> >>>
> >>> Oh yes, I got confused.
> >>>
> also seems wrong, you can run unit test on real hardware, and this is a
> test that could (should?) be run on that platform.
> >>>
> >>> Only if it enables UNIT_TEST. You cannot run unit tests without that.
> >>> The current tests are designed for sandbox.
> >>
> >> FWIW I have run this test on actual hardware. My intent here was to allow
> >> unit tests to access functions which would otherwise be declared static.
> >
> > Er, with or without UNIT_TEST enabled? How can it even build if this
> > declaration is only for sandbox?
>
> With UNIT_TEST of course. Although since this is a forward-declaration, the
> UNIT_TEST ifdef isn't really even necessary. If it's on actual hardware, nop
> should already be defined. So maybe this should be something like
>
> #if CONFIG_SANDBOX
> #define nop()
> #endif
It is the CONFIG_SANDBOX that I am trying to remove. Can it be
CONFIG_UNIT_TEST instead?
Regards,
Simon
Re: [PATCH v4 4/4] board: Add support for Conclusive KSTR-SAMA5D27
Hello Artur,
On 10/9/23 17:41, Artur Rojek wrote:
Introduce support for Conclusive KSTR-SAMA5D27 Single Board Computer.
Co-developed-by: Jakub Klama
Signed-off-by: Jakub Klama
Co-developed-by: Marcin Jabrzyk
Signed-off-by: Marcin Jabrzyk
Signed-off-by: Artur Rojek
---
v4: - utilize EVT_SETTINGS_R in order to read MAC and serial number from
EEPROM
v3: - use CONFIG_ID_EEPROM to read serial number
- as side-effect of using CONFIG_ID_EEPROM, KSTR-SAMA5D27 now also
correctly uses EEPROM embedded MAC addresses (overlooked in v1-v2)
- use CONFIG_DISPLAY_BOARDINFO_LATE for printing the board model and
serial number, and provide the required checkboard() call
- drop CONFIG_BOARD_LATE_INIT, as not needed anymore
- defconfig cleanup
v2: - remove redundant license text from at91-kstr-sama5d27.dts
- when defining properties in .dts, reference nodes by labels
- drop nodes for usb0 and pmic, as these aren't used by drivers
- switch i2c to flexcom driver and make the necessary dts changes
- sort includes in at91-kstr-sama5d27.dts alphabetically
arch/arm/dts/Makefile | 3 +
arch/arm/dts/at91-kstr-sama5d27.dts | 131 ++
arch/arm/mach-at91/Kconfig| 12 +
board/conclusive/kstr-sama5d27/Kconfig| 15 ++
board/conclusive/kstr-sama5d27/MAINTAINERS| 8 +
board/conclusive/kstr-sama5d27/Makefile | 5 +
.../conclusive/kstr-sama5d27/kstr-sama5d27.c | 239 ++
configs/kstr_sama5d27_defconfig | 73 ++
include/configs/kstr-sama5d27.h | 15 ++
9 files changed, 501 insertions(+)
create mode 100644 arch/arm/dts/at91-kstr-sama5d27.dts
create mode 100644 board/conclusive/kstr-sama5d27/Kconfig
create mode 100644 board/conclusive/kstr-sama5d27/MAINTAINERS
create mode 100644 board/conclusive/kstr-sama5d27/Makefile
create mode 100644 board/conclusive/kstr-sama5d27/kstr-sama5d27.c
create mode 100644 configs/kstr_sama5d27_defconfig
create mode 100644 include/configs/kstr-sama5d27.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bde2176ec7f6..c0f3525ed4d3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1198,6 +1198,9 @@ dtb-$(CONFIG_TARGET_SAMA5D27_SOM1_EK) += \
dtb-$(CONFIG_TARGET_SAMA5D27_WLSOM1_EK) += \
at91-sama5d27_wlsom1_ek.dtb
+dtb-$(CONFIG_TARGET_KSTR_SAMA5D27) += \
+ at91-kstr-sama5d27.dtb
+
dtb-$(CONFIG_TARGET_SAMA5D2_ICP) += \
at91-sama5d2_icp.dtb
diff --git a/arch/arm/dts/at91-kstr-sama5d27.dts b/arch/arm/dts/at91-kstr-sama5d27.dts
new file mode 100644
index ..fe9ec7e5bbc3
--- /dev/null
+++ b/arch/arm/dts/at91-kstr-sama5d27.dts
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * at91-kstr-sama5d27.dts - Device Tree file for Conclusive KSTR-SAMA5D27 board
+ *
+ * Copyright (C) 2019-2023 Conclusive Engineering Sp. z o. o.
+ *
+ */
+/dts-v1/;
+
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+#include
+#include
+#include
+
+/ {
+ model = "Conclusive KSTR-SAMA5D27";
+ compatible = "conclusive,kstr-sama5d27", "atmel,sama5d2", "atmel,sama5";
+
+ chosen {
+ bootph-all;
+ stdout-path =
+ };
+};
+
+_xtal {
+ clock-frequency = <1200>;
+};
+
+ {
+ bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_sdmmc0_cmd_dat_default
_sdmmc0_ck_cd_default>;
+ status = "okay";
+ bootph-all;
Can you create a separate file named at91-kstr-sama5d27-u-boot.dtsi (
which is automatically included by the Makefile) which would contain the
bootph properties
(Have a look at arch/arm/dts/at91-sama5d29_curiosity-u-boot.dtsi for
example )
In theory we would like the board dts file to be identical with Linux (
as much as possible if not identical ), and have specific U-boot props
in such a separate file.
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart1_default>;
+ status = "okay";
+ bootph-all;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_macb0_rmii _macb0_phy_irq>;
+ phy-mode = "rmii";
+ status = "okay";
+
+ ethernet-phy@0 {
+ reg = <0x0>;
+ reset-gpios = < 44 GPIO_ACTIVE_LOW>;
+ };
+};
+
+ {
+ atmel,flexcom-mode = ;
+ status = "okay";
+};
+
+ {
+ clock-frequency = <10>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_flx4_i2c>;
+ status = "okay";
Which bus number (in Uboot) is this i2c6 being assigned to ?
Would it be better , and/or more predictable to add an alias to the
desired bus number in DT ?
e.g. aliases { i2c2 = }
Thanks,
Eugen
+
+ eeprom: eeprom@50 {
+ compatible = "microchip,24c32", "atmel,24c32";
+ reg = <0x50>;
+ read-only;
+ pagesize = <32>;
+ status = "okay";
+ };
Re: [PATCH v5 00/16] firmware: scmi: add SCMI base protocol support
On Tue, Sep 26, 2023 at 03:57:34PM +0900, AKASHI Takahiro wrote:
> This patch series allows users to access SCMI base protocol provided by
> SCMI server (platform). It will also be utilized in separate patches
> in the future to add sanity/validity checks for other protocols.
> See SCMI specification document v3.2 beta[1] for more details about SCMI
> base protocol.
>
> What is currently not implemented is
> - SCMI_BASE_NOTIFY_ERRORS command and notification callback mechanism
>
> This feature won't be very useful in the current U-Boot environment.
>
> [1] https://developer.arm.com/documentation/den0056/e/?lang=en
>
>
> Test
>
> The patch series was tested on the following platforms:
> * sandbox
> * qemu-arm64 with OPTEE as SCMI server
I have two problems. The first is that for sandbox, this series is not
bisectable as a commits fail to build due to needing a definition in the
test before it's added:
/home/uboot/work/u-boot/u-boot/test/dm/scmi.c: In function
'dm_test_scmi_clocks':
/home/uboot/work/u-boot/u-boot/test/dm/scmi.c:117:21: warning: implicit
declaration of function 'scmi_get_protocol' [-Wimplicit-function-declaration]
117 | clock_dev = scmi_get_protocol(agent_dev,
SCMI_PROTOCOL_ID_CLOCK);
| ^
/home/uboot/work/u-boot/u-boot/test/dm/scmi.c:117:50: error:
'SCMI_PROTOCOL_ID_CLOCK' undeclared (first use in this function)
117 | clock_dev = scmi_get_protocol(agent_dev,
SCMI_PROTOCOL_ID_CLOCK);
| ^~
/home/uboot/work/u-boot/u-boot/test/dm/scmi.c:117:50: note: each undeclared
identifier is reported only once for each function it appears in
/home/uboot/work/u-boot/u-boot/test/dm/scmi.c: In function
'dm_test_scmi_resets':
/home/uboot/work/u-boot/u-boot/test/dm/scmi.c:182:50: error:
'SCMI_PROTOCOL_ID_RESET_DOMAIN' undeclared (first use in this function)
182 | reset_dev = scmi_get_protocol(agent_dev,
SCMI_PROTOCOL_ID_RESET_DOMAIN);
|
^
make[4]: *** [/home/uboot/work/u-boot/u-boot/scripts/Makefile.build:256:
test/dm/scmi.o] Error 1
Second, the series causes this failure:
== FAILURES
===
___ test_ut[ut_dm_dm_test_scmi_cmd]
___
test/py/u_boot_spawn.py:195: in expect
c = os.read(self.fd, 1024).decode(errors='replace')
E OSError: [Errno 5] Input/output error
During handling of the above exception, another exception occurred:
test/py/tests/test_ut.py:497: in test_ut
output = u_boot_console.run_command('ut ' + ut_subtest)
test/py/u_boot_console_base.py:266: in run_command
m = self.p.expect([self.prompt_compiled] + self.bad_patterns)
test/py/u_boot_spawn.py:204: in expect
raise ValueError('U-Boot exited with %s' % info)
E ValueError: U-Boot exited with signal 11 (SIGSEGV)
Captured stdout call
-
=> ut dm dm_test_scmi_cmd
Test: dm_test_scmi_cmd: scmi.c
SCMI device: scmi
protocol version: 0x2
# of agents: 2
0: platform
> 1: OSPM
# of protocols: 3
Clock management
Reset domain management
Voltage domain management
vendor: U-Boot
sub vendor: Sandbox
impl version: 0x1
Denying access to device:0 failed (-13)
Denying access to protocol:0x14 on device:0 failed (-13)
Reset failed (-13)
Test: dm_test_scmi_cmd: scmi.c (flat tree)
SCMI device: ?n
=== short test summary info
===
FAILED test/py/tests/test_ut.py::test_ut[ut_dm_dm_test_scmi_cmd] - ValueError:
U-Boot exited...
Which I believe CI will also produce, once the issue with htmldocs is
fixed. I can't bisect it exactly as the failure shows up once the new
test is added.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v5 15/16] doc: cmd: add documentation for scmi
On Tue, Sep 26, 2023 at 03:57:49PM +0900, AKASHI Takahiro wrote: > This is a help text for scmi command. > > Signed-off-by: AKASHI Takahiro > Reviewed-by: Simon Glass > Reviewed-by: Etienne Carriere > --- > v4 > * s/tranport/transport/ > v2 > * add more descriptions about SCMI > --- > doc/usage/cmd/scmi.rst | 126 + > 1 file changed, 126 insertions(+) > create mode 100644 doc/usage/cmd/scmi.rst This needs to be included in doc/usage/index.rst in alphabetical order, so that "make htmldocs" passes. Normally I'd fix this up, but given the other problem I'm reporting this along. -- Tom signature.asc Description: PGP signature
[PATCH] smegw01: Remove misuse of CONFIG_ENV_IS_NOWHERE
From: Eduard Strehlau
When using a list of writeable variables, the initial values come
from the built-in default environment since commit 5ab81058364b ("env:
Complete generic support for writable list").
Remove unnecessary misuse of CONFIG_ENV_IS_NOWHERE as default environment.
Based on the fix done by commit b16fd7f75f6d ("imx6q: acc: Remove misuse
of env is nowhere driver").
Signed-off-by: Eduard Strehlau
Signed-off-by: Fabio Estevam
---
board/storopack/smegw01/smegw01.c | 15 ---
configs/smegw01_defconfig | 1 -
2 files changed, 16 deletions(-)
diff --git a/board/storopack/smegw01/smegw01.c
b/board/storopack/smegw01/smegw01.c
index 7b2c50a61e..345191b31c 100644
--- a/board/storopack/smegw01/smegw01.c
+++ b/board/storopack/smegw01/smegw01.c
@@ -111,18 +111,3 @@ uint mmc_get_env_part(struct mmc *mmc)
return part;
}
-enum env_location env_get_location(enum env_operation op, int prio)
-{
- if (op == ENVOP_SAVE || op == ENVOP_ERASE)
- return ENVL_MMC;
-
- switch (prio) {
- case 0:
- return ENVL_NOWHERE;
-
- case 1:
- return ENVL_MMC;
- }
-
- return ENVL_UNKNOWN;
-}
diff --git a/configs/smegw01_defconfig b/configs/smegw01_defconfig
index 5cfd3d2715..13665ecfd3 100644
--- a/configs/smegw01_defconfig
+++ b/configs/smegw01_defconfig
@@ -48,7 +48,6 @@ CONFIG_CMD_SQUASHFS=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_OF_CONTROL=y
CONFIG_ENV_OVERWRITE=y
-CONFIG_ENV_IS_NOWHERE=y
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_SYS_MMC_ENV_DEV=1
--
2.41.0
Re: [PATCH v4] dt-bindings: mtd: fixed-partitions: Add compression property
On Wed, 27 Sep 2023 12:05:43 -0600, Simon Glass wrote: > Sometimes the contents of a partition are compressed. Add a property to > express this and define the algorithm used. > > Signed-off-by: Simon Glass > --- > > Changes in v4: > - Add an example > > Changes in v3: > - Just add a compression property for now > > Changes in v2: > - Use "binman" for compatible instead of "u-boot,binman" > - Significantly rework the patch > - Use make dt_binding_check DT_SCHEMA_FILES=Documentation/../partitions > > .../mtd/partitions/fixed-partitions.yaml | 19 +++ > 1 file changed, 19 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH] timer: starfive: Add Starfive timer support
Hi,
On Wed, 4 Oct 2023 at 03:49, KuanLim.Lee wrote:
>
> Hi Simon,
>
> > -Original Message-
> > From: Simon Glass
> > Sent: Wednesday, October 4, 2023 10:11 AM
> > To: KuanLim.Lee
> > Cc: u-boot@lists.denx.de; WeiLiang Lim
> > Subject: Re: [PATCH] timer: starfive: Add Starfive timer support
> >
> > On Tue, 19 Sept 2023 at 06:08, Kuan Lim Lee
> > wrote:
> > >
> > > Add timer driver in Starfive SoC. It is an timer that outside of CPU
> > > core and inside Starfive SoC.
> > >
> > > Signed-off-by: Kuan Lim Lee
> > > Reviewed-by: Wei Liang Lim
> > > ---
> > > drivers/timer/Kconfig | 7 +++
> > > drivers/timer/Makefile | 1 +
> > > drivers/timer/starfive-timer.c | 94
> > > ++
> > > 3 files changed, 102 insertions(+)
> > > create mode 100644 drivers/timer/starfive-timer.c
> >
> > Reviewed-by: Simon Glass
> >
> > nits below
> What are the nits?
> How do the nits to be solved?
they are the things I mentioned below
> >
> > >
> > > diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig index
> > > 915b2af160..a98be9dfae 100644
> > > --- a/drivers/timer/Kconfig
> > > +++ b/drivers/timer/Kconfig
> > > @@ -326,4 +326,11 @@ config XILINX_TIMER
> > > Select this to enable support for the timer found on
> > > any Xilinx boards (axi timer).
> > >
> > > +config STARFIVE_TIMER
> > > + bool "Starfive timer support"
> > > + depends on TIMER
> > > + help
> > > + Select this to enable support for the timer found on
> > > + Starfive SoC.
> >
> > What resolution is the timer? How is it clocked? Is there only one channel?
> Timer will be driven by clock pulses from clocks. The clocks are defined in
> device tree.
> Four channels timer, each timer has own clock source.
> Clock source frequency is gotten by clk_get_by_index () and clk_get_rate().
> The timer counter register is a 32bits size register.
OK so could you put these details in the help?
> >
> > > +
> > > endmenu
> > > diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile index
> > > 1ca74805fd..1ef814970b 100644
> > > --- a/drivers/timer/Makefile
> > > +++ b/drivers/timer/Makefile
> > > @@ -34,3 +34,4 @@ obj-$(CONFIG_MTK_TIMER) += mtk_timer.o
> > > obj-$(CONFIG_MCHP_PIT64B_TIMER)+= mchp-pit64b-timer.o
> > > obj-$(CONFIG_IMX_GPT_TIMER)+= imx-gpt-timer.o
> > > obj-$(CONFIG_XILINX_TIMER) += xilinx-timer.o
> > > +obj-$(CONFIG_STARFIVE_TIMER) += starfive-timer.o
> > > diff --git a/drivers/timer/starfive-timer.c
> > > b/drivers/timer/starfive-timer.c new file mode 100644 index
> > > 00..816402fdbf
> > > --- /dev/null
> > > +++ b/drivers/timer/starfive-timer.c
> > > @@ -0,0 +1,94 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright 2022 StarFive, Inc. All rights reserved.
> > > + * Author: Lee Kuan Lim
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#defineSTF_TIMER_INT_STATUS0x00
> > > +#define STF_TIMER_CTL 0x04
> > > +#define STF_TIMER_LOAD 0x08
> > > +#define STF_TIMER_ENABLE 0x10
> > > +#define STF_TIMER_RELOAD 0x14
> > > +#define STF_TIMER_VALUE0x18
> > > +#define STF_TIMER_INT_CLR 0x20
> > > +#define STF_TIMER_INT_MASK 0x24
> > > +
> > > +struct starfive_timer_priv {
> > > + void __iomem *base;
> > > + u32 timer_size;
> > > +};
> > > +
> > > +static u64 notrace starfive_get_count(struct udevice *dev) {
> > > + struct starfive_timer_priv *priv = dev_get_priv(dev);
> > > +
> > > + /* Read decrement timer value and convert to increment value */
> > > + return priv->timer_size - readl(priv->base + STF_TIMER_VALUE);
> > > +}
> >
> > As an enhancement, you could provide a timer_early_get_count() function and
> > an easly setup, so you can use bootstage.
> >
> Is this a must? If so, I must define some fixed address to get the timer
> count,
> enable timer, clock source frequency because I can't get base address and
> frequency from the device tree in early stage.
No it isn't. It is useful for bootstage though. I suspect you can read
DT early, though.
> > > +
> > > +static const struct timer_ops starfive_ops = {
> > > + .get_count = starfive_get_count, };
> > > +
> > > +static int starfive_probe(struct udevice *dev) {
> > > + struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> > > + struct starfive_timer_priv *priv = dev_get_priv(dev);
> > > + int timer_channel;
> > > + struct clk clk;
> > > + int ret;
> > > +
> > > + priv->base = dev_read_addr_ptr(dev);
> > > + if (IS_ERR(priv->base))
> >
> > if (!priv->base)
> > return -EINVAL
> >
> Noted.
> > > + return PTR_ERR(priv->base);
> > > +
> > > + timer_channel = dev_read_u32_default(dev, "channel", 0);
> > > + priv->base =
Re: [PATCH] cmd: mmc: Add mmc reg read command for reading card registers
On 10/10/23 08:51, Heinrich Schuchardt wrote: Am 10. Oktober 2023 01:14:58 MESZ schrieb Marek Vasut : Add extension to the 'mmc' command to read out the card registers. Currently, only the eMMC OCR/CID/CSD/EXTCSD/RCA/DSR register are supported. A register value can either be displayed or read into an environment variable. Hello Marek, could you, please, update doc/usage/cmd/mmc.rst. Should be fixed in V2, thanks.
Re: [PATCH v2] net: phy: xilinx_phy: Get rid of using property xlnx,phy-type
On 10/10/23 05:04, Venkatesh Yadav Abbarapu wrote:
As the xlnx,phy-type device tree property is deprecated and phy-mode
is being used, so removing the code references of xlnx,phy-type.
Signed-off-by: Venkatesh Yadav Abbarapu
---
Changes in v2:
- Removed phytype variable.
---
drivers/net/phy/xilinx_phy.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/net/phy/xilinx_phy.c b/drivers/net/phy/xilinx_phy.c
index 1df639d6f4..c07c780193 100644
--- a/drivers/net/phy/xilinx_phy.c
+++ b/drivers/net/phy/xilinx_phy.c
@@ -99,7 +99,6 @@ static int xilinxphy_startup(struct phy_device *phydev)
static int xilinxphy_of_init(struct phy_device *phydev)
{
- u32 phytype;
ofnode node;
debug("%s\n", __func__);
@@ -107,10 +106,6 @@ static int xilinxphy_of_init(struct phy_device *phydev)
if (!ofnode_valid(node))
return -EINVAL;
- phytype = ofnode_read_u32_default(node, "xlnx,phy-type", -1);
- if (phytype == XAE_PHY_TYPE_1000BASE_X)
- phydev->flags |= XAE_PHY_TYPE_1000BASE_X;
-
return 0;
}
Applied.
M
Re: [PATCH] ARM: dts: stm32mp: Repair damage from alignment with v6.3
On 10/10/23 01:15, Marek Vasut wrote:
> The patch fixed by this commit renders ST STM32MP15xx EV1 board and
> all DHSOM SoM based boards unbootable from SPI NOR. Fix the damage
> by updating -u-boot.dtsi to match the stm32mp15-pinctrl.dtsi update.
>
> Fixes: 08002ffd083d ("ARM: dts: stm32mp: alignment with v6.3")
> Signed-off-by: Marek Vasut
> ---
> NOTE: It is truly incomprehensible how 08002ffd083d was ever tested
> at ST, I can only speculate it never was tested at all, grumb.
Hi Marek,
Sorry for that, you are right, SPI NOR boot in SPL is no more tested on our
side :-(
Today we are only tested boot from sdcard with tf-a/optee.
Thanks for you fix.
Patrice
> ---
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi | 16
> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 12 +++-
> arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 8 ++--
> 3 files changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
> b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
> index 1f7fdbce530..eb283cacd27 100644
> --- a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
> @@ -135,20 +135,28 @@
>
> _bk1_pins_a {
> bootph-pre-ram;
> - pins1 {
> + pins {
> bootph-pre-ram;
> };
> - pins2 {
> +};
> +
> +_cs1_pins_a {
> + bootph-pre-ram;
> + pins {
> bootph-pre-ram;
> };
> };
>
> _bk2_pins_a {
> bootph-pre-ram;
> - pins1 {
> + pins {
> bootph-pre-ram;
> };
> - pins2 {
> +};
> +
> +_cs2_pins_a {
> + bootph-pre-ram;
> + pins {
> bootph-pre-ram;
> };
> };
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> index f12941b05f6..2f70b0690d2 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> @@ -134,20 +134,14 @@
>
> _bk1_pins_a {
> bootph-pre-ram;
> - pins1 {
> - bootph-pre-ram;
> - };
> - pins2 {
> + pins {
> bootph-pre-ram;
> };
> };
>
> -_bk2_pins_a {
> +_cs1_pins_a {
> bootph-pre-ram;
> - pins1 {
> - bootph-pre-ram;
> - };
> - pins2 {
> + pins {
> bootph-pre-ram;
> };
> };
> diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> index eb905ad2820..552b35db3c7 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> @@ -98,10 +98,14 @@
>
> _bk1_pins_a {
> bootph-pre-ram;
> - pins1 {
> + pins {
> bootph-pre-ram;
> };
> - pins2 {
> +};
> +
> +_cs1_pins_a {
> + bootph-pre-ram;
> + pins {
> bootph-pre-ram;
> };
> };
Reviewed-by: Patrice Chotard
Patrice
Re: [PATCH] board/km/cent2: Fix buffer overflow when fixing MAC address
On Fri, Sep 29, 2023 at 04:11:00PM +0200, Francois Berder wrote: > String "/soc/fman/ethernet@e8000" is 25 bytes long > and not 24 due to extra byte for null character at > the end. > > Signed-off-by: Francois Berder Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] stdio: fix stdio_deregister_dev()
On Fri, Sep 29, 2023 at 02:47:17AM +0200, Heinrich Schuchardt wrote:
> When copying the name of a stdio device we must ensure that it is NUL
> terminated before passing it to strcmp() to avoid a buffer overrun.
>
> Truncating the name field leads to failure to deregister a stdio device.
> When copying we must ensure that the name field sizes match.
>
> Addresses-Coverity-ID: 350462 String not null terminated
> Fixes: 5294e97832a6 ("stdio: extend "name" to 32 symbols")
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/2] dm: serial: fix serial_post_probe()
On Fri, Sep 29, 2023 at 02:47:16AM +0200, Heinrich Schuchardt wrote:
> The size of the name of a udevice is not limited.
>
> When setting the fixed sized name field of a stdio device we must ensure
> that the target string is NUL terminated to avoid buffer overflows.
>
> Fixes: 57d92753d4ca ("dm: Add a uclass for serial devices")
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] ARM: vexpress_ca9x4: Add missing flash width config option
On Wed, Sep 20, 2023 at 09:41:20AM +0200, Patryk Biel wrote: > Allow for a proper configuration of CFI flash banks avaialble on the > vexpress_ca9x4 > board. Without this option, the CFI flash incorrectly detects that the board > has two > banks of 32MB flash devices, while in reality, the board provides > two flash banks, each with 64MB size. As a result, it becomes impossible to > e.g. to > save u-boot env in flash. According to device tree for this board and > its implementation in QEMU, the CFI width should be set to 32 bits. > > After applying this fix, CFI flash will correctly detect both flash > banks each with a size of 64MB. As as result the functionality of e.g. saving > u-boot > env will work correctly. > > Tested on QEMU 6.2.0. > > Cc: Kristian Amlie > Signed-off-by: Patryk Biel > Reviewed-by: Kristian Amlie Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] bootstd: use ARCH_DMA_MINALIGN in memalign() when allocating memory
On Tue, Sep 19, 2023 at 02:27:21PM -0700, Tony Dinh wrote: > Use ARCH_DMA_MINALIGN in memalign() when allocating memory to read the script > from the media. > > Ref: > https://lore.kernel.org/u-boot/cajalify05f3cr4x4g2mvkppxnbefzrhq+5cngyn8ejpg8en...@mail.gmail.com/T/#m26daadc2463fe653b814a94e6309e5e6bb6be1d1 > > Note: this patch depends on the previous patch > https://patchwork.ozlabs.org/project/uboot/patch/20230917230649.30357-1-mibo...@gmail.com/ > > Signed-off-by: Tony Dinh > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/2] test: lmb: Add test for coalescing and overlap range
On Tue, Sep 26, 2023 at 04:54:43PM +0530, Udit Kumar wrote: > Add test case for an address range which is coalescing with one of > range and overlapping with next range > > Cc: Simon Glass > Signed-off-by: Udit Kumar > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] lmb: remove overlapping region with next range
On Tue, Sep 26, 2023 at 04:54:42PM +0530, Udit Kumar wrote: > In case of new memory range to be added is coalesced > with any already added non last lmb region. > > And there is possibility that, then region in which new memory > range added is not adjacent to next region. But have some > sections are overlapping. > > So along with adjacency check with next lmb region, > check for overlap should be done. > > In case overlap is found, adjust and merge these two lmb > region into one. > > Reported-by: Suman Anna > Signed-off-by: Udit Kumar Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] exynos: Cleanup exynos_init
On Thu, Sep 21, 2023 at 07:32:48PM -0400, Tom Rini wrote: > - None of the callers perform error checking and based on the non-empty > versions of this function, there's no checking to be done, so make > this a void. > - Add a default weak version of the function. > - Remove the empty versions of exynos_init now that we have a weak > version. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] board: Remove essentially empty board files and Makefiles
On Thu, Sep 21, 2023 at 07:32:47PM -0400, Tom Rini wrote: > As part of reviewing a new platform, Daniel Schwierzeck noted that we > can have an empty Makefile in the board directory and don't need an > empty board.c file as well. Further with further cleanup in the > Makefile we can now omit the Makefile entirely. Remove a number of now > unnecessary board.c and Makefiles. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] Makefile: Allow for board directories to not have a Makefile
On Thu, Sep 21, 2023 at 07:32:46PM -0400, Tom Rini wrote: > It is entirely possible at this point to have platforms in U-Boot that > do not have board-specific C code (just Kconfig or environment) and so > make it optional to have to descend in to and then build in the board > directory. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] Makefile: Force regeneration of env.txt
On Fri, Sep 15, 2023 at 09:43:23AM -0500, Andrew Davis wrote: > If the source .env file changes to one that is also older than the > generated env.txt file then the .env file is not regenerated. This > means when switching board configs we do not regenerate the env. > > This can be tested with: > > $ make j721e_evm_a72_defconfig > $ make # this may fail to complete but that is okay for this test > $ make am64x_evm_a53_defconfig > $ make > $ vim include/generated/env.txt > > Note this is still the J721e env not the AM64 config as expected. > > As ENV_FILE is set based on configuration, regenerate anytime > autoconf.h changes. > > Signed-off-by: Andrew Davis > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] tools: iot2050-sign-fw.sh: Make localization of tools dir more robust
On Wed, Sep 27, 2023 at 05:41:09PM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > When building in-tree, there is no source link. > > Signed-off-by: Jan Kiszka Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: mach-k3: common: fix compile warnings with PHYS_64BIT on 32bit
On Wed, Sep 27, 2023 at 03:43:14PM +0200, Matthias Schiffer wrote: > Use uintptr_t instead of phys_addr_t where appropriate, so passing the > addresses to writel() doesn't result in compile warnings when PHYS_64BIT > is set for 32bit builds (which is actually a useful configuration, as > the K3 SoC family boots from an R5 SPL, which may pass bank information > based on gd->bd->bi_dram to fdt_fixup_memory_banks() etc., so PHYS_64BIT > is needed for fixing up the upper bank). > > Signed-off-by: Matthias Schiffer Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] mailbox: k3-sec-proxy: fix error handling for missing scfg in FDT
On Tue, Sep 26, 2023 at 02:42:54PM +0200, Matthias Schiffer wrote:
> The wrong field was checked.
>
> Fixes: f9aa41023bd9 ("mailbox: Introduce K3 Secure Proxy Driver")
> Signed-off-by: Matthias Schiffer
> Reviewed-by: Nishanth Menon
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2] test/py: sleep: Add a test for the time command
On Wed, Sep 27, 2023 at 10:33:55AM +0530, Love Kumar wrote: > Execute "time ", and validate that it gives the approximately > the correct amount of command execution time. > > Signed-off-by: Love Kumar Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] test: Fix SPL tests not being run
On Fri, Sep 29, 2023 at 12:06:54PM -0400, Sean Anderson wrote:
> SPL doesn't have OF_LIVE enabled, so we can only run tests with a flat
> tree. Don't skip them even if they don't use the devicetree.
>
> Fixes: 6ec5178c0ef ("test: Skip flat-tree tests if devicetree is not used")
> Signed-off-by: Sean Anderson
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] spl: Jump to image at end of board_init_r
On Wed, Sep 27, 2023 at 09:44:13PM +, Jonas Karlman wrote: > spl_board_prepare_for_boot() is not called before jumping/invoking atf, > optee, opensbi or linux images. > > Jump to image at the end of board_init_r() to fix this. > > Signed-off-by: Jonas Karlman > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] spl: add __noreturn attribute to spl_invoke_atf function
On Fri, Sep 08, 2023 at 05:08:56PM +0900, Chanho Park wrote: > spl_invoke_atf function will not be returned to SPL. Thus, we need to > set __noreturn function attribute to the function. > > Signed-off-by: Chanho Park Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] test/py: net: Add a test for 'pxe get' command
On 10/6/23 22:27, Ramon Fried wrote:
On Tue, Oct 3, 2023 at 4:12 PM Love Kumar wrote:
Execute the 'pxe get' command to download a pxe configuration file from
the TFTP server and validate its interpretation.
Signed-off-by: Love Kumar
---
test/py/tests/test_net.py | 66 +++
1 file changed, 66 insertions(+)
diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index cd4b4dc53cbc..b2241ae6a482 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -6,6 +6,7 @@
import pytest
import u_boot_utils
+import uuid
"""
Note: This test relies on boardenv_* containing configuration values to define
@@ -61,6 +62,16 @@ env__net_nfs_readable_file = {
'crc32': 'c2244b26',
}
+# Details regarding a file that may be read from a TFTP server. This variable
+# may be omitted or set to None if PXE testing is not possible or desired.
+env__net_pxe_readable_file = {
+'fn': 'default',
+'addr': 0x200,
+'size': 74,
+'timeout': 5,
+'pattern': 'Linux',
+}
+
# True if a router advertisement service is connected to the network, and
should
# be tested. If router advertisement testing is not possible or desired, this
variable may be omitted or set to False.
@@ -260,3 +271,58 @@ def test_net_nfs(u_boot_console):
output = u_boot_console.run_command('crc32 %x $filesize' % addr)
assert expected_crc in output
+
+@pytest.mark.buildconfigspec("cmd_net")
+@pytest.mark.buildconfigspec("cmd_pxe")
+def test_net_pxe_get(u_boot_console):
+"""Test the pxe get command.
+
+A pxe configuration file is downloaded from the TFTP server and interpreted
+to boot the images mentioned in pxe configuration file.
+
+The details of the file to download are provided by the boardenv_* file;
+see the comment at the beginning of this file.
+"""
+
+if not net_set_up:
+pytest.skip("Network not initialized")
+
+test_net_setup_static(u_boot_console)
+
+f = u_boot_console.config.env.get("env__net_pxe_readable_file", None)
+if not f:
+pytest.skip("No PXE readable file to read")
+
+addr = f.get("addr", None)
+timeout = f.get("timeout", u_boot_console.p.timeout)
+
+pxeuuid = uuid.uuid1()
+u_boot_console.run_command(f"setenv pxeuuid {pxeuuid}")
+expected_text_uuid = f"Retrieving file: pxelinux.cfg/{pxeuuid}"
+
+ethaddr = u_boot_console.run_command("echo $ethaddr")
+ethaddr = ethaddr.replace(':', '-')
+expected_text_ethaddr = f"Retrieving file: pxelinux.cfg/01-{ethaddr}"
+
+ip = u_boot_console.run_command("echo $ipaddr")
+ip = ip.split('.')
+ipaddr_file = "".join(['%02x' % int(x) for x in ip]).upper()
+expected_text_ipaddr = f"Retrieving file: pxelinux.cfg/{ipaddr_file}"
+expected_text_default = f"Retrieving file: pxelinux.cfg/default"
+
+with u_boot_console.temporary_timeout(timeout):
+output = u_boot_console.run_command("pxe get")
+
+assert "TIMEOUT" not in output
+assert expected_text_uuid in output
+assert expected_text_ethaddr in output
+assert expected_text_ipaddr in output
+
+i = 1
+for i in range(0, len(ipaddr_file) - 1):
+expected_text_ip = f"Retrieving file: pxelinux.cfg/{ipaddr_file[:-i]}"
+assert expected_text_ip in output
+i += 1
+
+assert expected_text_default in output
+assert "Config file 'default.boot' found" in output
--
2.25.1
Reviewed-by: Ramon Fried
I can't see any issue in CI loop when this is applied.
Ramon: Do you want to take it via your tree?
Or should I take it?
Thanks,
Michal
[PATCH v2] cmd: mmc: Add mmc reg read command for reading card registers
Add extension to the 'mmc' command to read out the card registers.
Currently, only the eMMC OCR/CID/CSD/EXTCSD/RCA/DSR register are
supported. A register value can either be displayed or read into
an environment variable.
Signed-off-by: Marek Vasut
---
Cc: Abdellatif El Khlifi
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
Cc: Jaehoon Chung
Cc: Ramon Fried
Cc: Roger Knecht
Cc: Sean Edmond
Cc: Simon Glass
Cc: Tobias Waldekranz
---
V2: - Update documentation
---
cmd/Kconfig | 8
cmd/mmc.c | 96 +++
doc/usage/cmd/mmc.rst | 26
3 files changed, 130 insertions(+)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 6470b138d2f..dcd99757a1e 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1307,6 +1307,14 @@ config CMD_BKOPS_ENABLE
on a eMMC device. The feature is optionally available on eMMC devices
conforming to standard >= 4.41.
+config CMD_MMC_REG
+ bool "Enable support for reading card registers in the mmc command"
+ depends on CMD_MMC
+ default n
+ help
+ Enable the commands for reading card registers. This is useful
+ mostly for debugging or extracting details from the card.
+
config CMD_MMC_RPMB
bool "Enable support for RPMB in the mmc command"
depends on SUPPORT_EMMC_RPMB
diff --git a/cmd/mmc.c b/cmd/mmc.c
index c6bd81cebbc..c29f44b7a18 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -1110,6 +1110,93 @@ static int do_mmc_boot_wp(struct cmd_tbl *cmdtp, int
flag,
return CMD_RET_SUCCESS;
}
+#if CONFIG_IS_ENABLED(CMD_MMC_REG)
+static int do_mmc_reg(struct cmd_tbl *cmdtp, int flag,
+ int argc, char *const argv[])
+{
+ ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+ struct mmc *mmc;
+ int i, ret;
+ u32 off;
+
+ if (argc < 3 || argc > 5)
+ return CMD_RET_USAGE;
+
+ mmc = find_mmc_device(curr_device);
+ if (!mmc) {
+ printf("no mmc device at slot %x\n", curr_device);
+ return CMD_RET_FAILURE;
+ }
+
+ if (IS_SD(mmc)) {
+ printf("SD registers are not supported\n");
+ return CMD_RET_FAILURE;
+ }
+
+ off = simple_strtoul(argv[3], NULL, 10);
+ if (!strcmp(argv[2], "cid")) {
+ if (off > 3)
+ return CMD_RET_USAGE;
+ printf("CID[%i]: 0x%08x\n", off, mmc->cid[off]);
+ if (argv[4])
+ env_set_hex(argv[4], mmc->cid[off]);
+ return CMD_RET_SUCCESS;
+ }
+ if (!strcmp(argv[2], "csd")) {
+ if (off > 3)
+ return CMD_RET_USAGE;
+ printf("CSD[%i]: 0x%08x\n", off, mmc->csd[off]);
+ if (argv[4])
+ env_set_hex(argv[4], mmc->csd[off]);
+ return CMD_RET_SUCCESS;
+ }
+ if (!strcmp(argv[2], "dsr")) {
+ printf("DSR: 0x%08x\n", mmc->dsr);
+ if (argv[4])
+ env_set_hex(argv[4], mmc->dsr);
+ return CMD_RET_SUCCESS;
+ }
+ if (!strcmp(argv[2], "ocr")) {
+ printf("OCR: 0x%08x\n", mmc->ocr);
+ if (argv[4])
+ env_set_hex(argv[4], mmc->ocr);
+ return CMD_RET_SUCCESS;
+ }
+ if (!strcmp(argv[2], "rca")) {
+ printf("RCA: 0x%08x\n", mmc->rca);
+ if (argv[4])
+ env_set_hex(argv[4], mmc->rca);
+ return CMD_RET_SUCCESS;
+ }
+ if (!strcmp(argv[2], "extcsd") &&
+ mmc->version >= MMC_VERSION_4_41) {
+ ret = mmc_send_ext_csd(mmc, ext_csd);
+ if (ret)
+ return ret;
+ if (!strcmp(argv[3], "all")) {
+ /* Dump the entire register */
+ printf("EXT_CSD:");
+ for (i = 0; i < MMC_MAX_BLOCK_LEN; i++) {
+ if (!(i % 10))
+ printf("\n%03i: ", i);
+ printf(" %02x", ext_csd[i]);
+ }
+ printf("\n");
+ return CMD_RET_SUCCESS;
+ }
+ off = simple_strtoul(argv[3], NULL, 10);
+ if (off > 512)
+ return CMD_RET_USAGE;
+ printf("EXT_CSD[%i]: 0x%02x\n", off, ext_csd[off]);
+ if (argv[4])
+ env_set_hex(argv[4], ext_csd[off]);
+ return CMD_RET_SUCCESS;
+ }
+
+ return CMD_RET_FAILURE;
+}
+#endif
+
static struct cmd_tbl cmd_mmc[] = {
U_BOOT_CMD_MKENT(info, 1, 0, do_mmcinfo, "", ""),
U_BOOT_CMD_MKENT(read, 4, 1, do_mmc_read, "", ""),
@@ -1142,6 +1229,9 @@ static struct cmd_tbl cmd_mmc[] = {
U_BOOT_CMD_MKENT(bkops-enable, 2, 0, do_mmc_bkops_enable,
Re: [PATCH v5 10/11] ram: starfive: Read memory size information from EEPROM
On Jun 15 2023, Yanhong Wang wrote: > StarFive VisionFive 2 has two versions, 1.2A and 1.3B, each version of > DDR capacity includes 2G/4G/8G, a DT can not support multiple > capacities, so the capacity size information is recorded to EEPROM, when > DDR initialization required capacity size information is read from > EEPROM. Does that acutally work? I see that read_eeprom fails in SPL. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Port gen_compile_commands.py from Linux to U-Boot
>Hello U-Boot community, >I'm submitting a patch series that ports the gen_compile_commands.py >script from the Linux kernel's sources to U-Boot. This script, originally >located in scripts/clang-tools/gen_compile_commands.py, enables the >generation of compile_commands.json file for improved code navigation >and analysis. The series consists of the initial script import, the >necessary modifications for U-Boot compatibility, and finally some >documentation. Tested-by: Joao Paulo Goncalves
[PATCH v2 1/1] drivers: rng: add support for Meson S4
For some Amlogic SOC's, mechanism to obtain random number
has been changed. For example, S4 now uses status bit waiting algo.
Signed-off-by: Alexey Romanov
---
drivers/rng/meson-rng.c | 72 -
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/rng/meson-rng.c b/drivers/rng/meson-rng.c
index e0a1e8c7e0..ba60325b94 100644
--- a/drivers/rng/meson-rng.c
+++ b/drivers/rng/meson-rng.c
@@ -10,10 +10,23 @@
#include
#include
#include
+#include
+
+#define RNG_DATA 0x00
+#define RNG_S4_DATA0x08
+#define RNG_S4_CFG 0x00
+
+#define RUN_BITBIT(0)
+#define SEED_READY_STS_BIT BIT(31)
+
+struct meson_rng_priv {
+ u32 (*read)(fdt_addr_t base);
+};
struct meson_rng_plat {
fdt_addr_t base;
struct clk clk;
+ struct meson_rng_priv *priv;
};
/**
@@ -27,10 +40,11 @@ struct meson_rng_plat {
static int meson_rng_read(struct udevice *dev, void *data, size_t len)
{
struct meson_rng_plat *pdata = dev_get_plat(dev);
+ struct meson_rng_priv *priv = pdata->priv;
char *buffer = (char *)data;
while (len) {
- u32 rand = readl(pdata->base);
+ u32 rand = priv->read(pdata->base);
size_t step;
if (len >= 4)
@@ -44,6 +58,47 @@ static int meson_rng_read(struct udevice *dev, void *data,
size_t len)
return 0;
}
+static int meson_rng_wait_status(void __iomem *cfg_addr, int bit)
+{
+ u32 status = 0;
+ int ret;
+
+ ret = readl_relaxed_poll_timeout(cfg_addr,
+status, !(status & bit),
+1);
+ if (ret)
+ return -EBUSY;
+
+ return 0;
+}
+
+static u32 meson_common_rng_read(fdt_addr_t base)
+{
+ return readl(base);
+}
+
+static u32 meson_s4_rng_read(fdt_addr_t base)
+{
+ void __iomem *cfg_addr = (void *)base + RNG_S4_CFG;
+ int err;
+
+ writel_relaxed(readl_relaxed(cfg_addr) | SEED_READY_STS_BIT, cfg_addr);
+
+ err = meson_rng_wait_status(cfg_addr, SEED_READY_STS_BIT);
+ if (err) {
+ pr_err("Seed isn't ready, try again\n");
+ return err;
+ }
+
+ err = meson_rng_wait_status(cfg_addr, RUN_BIT);
+ if (err) {
+ pr_err("Can't get random number, try again\n");
+ return err;
+ }
+
+ return readl_relaxed(base + RNG_S4_DATA);
+}
+
/**
* meson_rng_probe() - probe rng device
*
@@ -59,6 +114,8 @@ static int meson_rng_probe(struct udevice *dev)
if (err)
return err;
+ pdata->priv = dev_get_driver_data(dev);
+
return 0;
}
@@ -102,9 +159,22 @@ static const struct dm_rng_ops meson_rng_ops = {
.read = meson_rng_read,
};
+static const struct meson_rng_priv meson_rng_priv = {
+ .read = meson_common_rng_read,
+};
+
+static const struct meson_rng_priv meson_rng_priv_s4 = {
+ .read = meson_s4_rng_read,
+};
+
static const struct udevice_id meson_rng_match[] = {
{
.compatible = "amlogic,meson-rng",
+ .data = (ulong)_rng_priv,
+ },
+ {
+ .compatible = "amlogic,meson-s4-rng",
+ .data = (ulong)_rng_priv_s4,
},
{},
};
--
2.25.1
[PATCH v2 0/1] hwrng: meson - add support for S4
Hello! This patch adds support for Meson S4 series hardware number generator using new algo. V2: - Sync with Linux version. Alexey Romanov (1): drivers: rng: add support for Meson S4 drivers/rng/meson-rng.c | 72 - 1 file changed, 71 insertions(+), 1 deletion(-) -- 2.25.1
[PATCH v2 0/2] Meson A1: add HW RNG and AO Secure nodes
Hello! This patchest adds HW RNG and AO Secure definition in device tree for Amlogic A1-series. V2: - Rebased over latest amlogic U-Boot branch. Alexey Romanov (2): meson-a1: dts: add hw rng node meson-a1: dts: add ao secure node arch/arm/dts/meson-a1.dtsi | 11 +++ 1 file changed, 11 insertions(+) -- 2.25.1
[PATCH v2 2/2] meson-a1: dts: add ao secure node
ao-secure node can be used to get information about the board,
so, for example, using show_board_info() we can get following
information for board with Meson A1 SoC:
SoC: Amlogic Meson A1 (A113L) Revision 2c:a (1:a)
Signed-off-by: Alexey Romanov
---
arch/arm/dts/meson-a1.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/dts/meson-a1.dtsi b/arch/arm/dts/meson-a1.dtsi
index e6e72d4004..e3a42c5b24 100644
--- a/arch/arm/dts/meson-a1.dtsi
+++ b/arch/arm/dts/meson-a1.dtsi
@@ -129,6 +129,12 @@
compatible = "amlogic,meson-rng";
reg = <0x0 0x5118 0x0 0x4>;
};
+
+ sec_AO: ao-secure@5a20 {
+ compatible = "amlogic,meson-gx-ao-secure",
"syscon";
+ reg = <0x0 0x5a20 0x0 0x140>;
+ amlogic,has-chip-id;
+ };
};
gic: interrupt-controller@ff901000 {
--
2.25.1
[PATCH v2 1/2] meson-a1: dts: add hw rng node
Add support for hardware random number generator
of Amlogic Meson SoCs.
Signed-off-by: Alexey Romanov
---
arch/arm/dts/meson-a1.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/dts/meson-a1.dtsi b/arch/arm/dts/meson-a1.dtsi
index 6509329b85..e6e72d4004 100644
--- a/arch/arm/dts/meson-a1.dtsi
+++ b/arch/arm/dts/meson-a1.dtsi
@@ -124,6 +124,11 @@
clock-names = "xtal", "pclk", "baud";
status = "disabled";
};
+
+ hwrng: rng@5118 {
+ compatible = "amlogic,meson-rng";
+ reg = <0x0 0x5118 0x0 0x4>;
+ };
};
gic: interrupt-controller@ff901000 {
--
2.25.1
Re: [PATCH v1 1/7] rockchip: dts: rk3568: Resync from kernel-4.19
> From: Elaine Zhang > Date: Tue, 10 Oct 2023 16:51:49 +0800 > > Resync from kernel-4.19: > (a6cf6aca12c0 drivers: rkflash: Ajudst the dll strategy) Linux 4.19 is ancient; why are you not synching from 6.5 or a 6.6 release candidate? > Change-Id: I7b7134946b76dbd8963cfaafdc5b56750622855e > Signed-off-by: Elaine Zhang > --- > include/dt-bindings/clock/rk3568-cru.h | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/include/dt-bindings/clock/rk3568-cru.h > b/include/dt-bindings/clock/rk3568-cru.h > index c1942422a438..251445cf7632 100644 > --- a/include/dt-bindings/clock/rk3568-cru.h > +++ b/include/dt-bindings/clock/rk3568-cru.h > @@ -478,6 +478,13 @@ > #define CPLL_50M 415 > #define CPLL_25M 416 > #define CPLL_100M417 > +#define SCLK_DDRCLK 418 > +#define I2S1_MCLKOUT 419 > +#define I2S3_MCLKOUT 420 > +#define I2S1_MCLK_RX_IOE 421 > +#define I2S1_MCLK_TX_IOE 422 > +#define I2S2_MCLK_IOE423 > +#define I2S3_MCLK_IOE424 > > #define PCLK_CORE_PVTM 450 > > -- > 2.17.1 > >
Re: [PATCH v1 1/7] rockchip: dts: rk3568: Resync from kernel-4.19
Hi Elaine, On 2023-10-10 10:51, Elaine Zhang wrote: > Resync from kernel-4.19: > (a6cf6aca12c0 drivers: rkflash: Ajudst the dll strategy) bindings should be synced from mainline linux, not vendor kernel. > > Change-Id: I7b7134946b76dbd8963cfaafdc5b56750622855e > Signed-off-by: Elaine Zhang > --- > include/dt-bindings/clock/rk3568-cru.h | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/include/dt-bindings/clock/rk3568-cru.h > b/include/dt-bindings/clock/rk3568-cru.h > index c1942422a438..251445cf7632 100644 > --- a/include/dt-bindings/clock/rk3568-cru.h > +++ b/include/dt-bindings/clock/rk3568-cru.h > @@ -478,6 +478,13 @@ > #define CPLL_50M 415 > #define CPLL_25M 416 > #define CPLL_100M417 > +#define SCLK_DDRCLK 418 This is the only missing clock that is defined in mainline linux. > +#define I2S1_MCLKOUT 419 > +#define I2S3_MCLKOUT 420 > +#define I2S1_MCLK_RX_IOE 421 > +#define I2S1_MCLK_TX_IOE 422 > +#define I2S2_MCLK_IOE423 > +#define I2S3_MCLK_IOE424 These are missing in mainline linux, please upstream to linux. Regards, Jonas > > #define PCLK_CORE_PVTM 450 >
[PATCH v1] arm: dts: k3-am625-verdin: fix boot
From: Marcel Ziswiler
A53 U-Boot proper got broken because nodes marked as 'bootph-pre-ram'
are no longer available in U-Boot proper before relocation.
Fix this by marking all nodes in u-boot.dtsi as 'bootph-all'.
Fixes: 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc
after relocation")
Signed-off-by: Marcel Ziswiler
---
.../dts/k3-am625-verdin-wifi-dev-u-boot.dtsi | 72 +--
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/arm/dts/k3-am625-verdin-wifi-dev-u-boot.dtsi
b/arch/arm/dts/k3-am625-verdin-wifi-dev-u-boot.dtsi
index 5d564603eb2..afa24d07a4c 100644
--- a/arch/arm/dts/k3-am625-verdin-wifi-dev-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-verdin-wifi-dev-u-boot.dtsi
@@ -17,49 +17,49 @@
};
memory@8000 {
- bootph-pre-ram;
+ bootph-all;
};
};
_main {
- bootph-pre-ram;
+ bootph-all;
timer@240 {
clock-frequency = <2500>;
- bootph-pre-ram;
+ bootph-all;
};
};
_mcu {
- bootph-pre-ram;
+ bootph-all;
};
_wakeup {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_phy0 {
- bootph-pre-ram;
+ bootph-all;
};
_phy1 {
- bootph-pre-ram;
+ bootph-all;
};
_port1 {
- bootph-pre-ram;
+ bootph-all;
};
_port2 {
- bootph-pre-ram;
+ bootph-all;
};
/* MDIO, shared by Verdin ETH_1 (On-module PHY) and Verdin ETH_2_RGMII */
@@ -67,40 +67,40 @@
/delete-property/ assigned-clocks;
/delete-property/ assigned-clock-parents;
/delete-property/ assigned-clock-rates;
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
k3_sysreset: sysreset-controller {
compatible = "ti,sci-sysreset";
- bootph-pre-ram;
+ bootph-all;
};
};
{
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_clks {
- bootph-pre-ram;
+ bootph-all;
};
_pds {
- bootph-pre-ram;
+ bootph-all;
};
_reset {
- bootph-pre-ram;
+ bootph-all;
};
_gpio0 {
- bootph-pre-ram;
+ bootph-all;
};
/* On-module I2C - PMIC_I2C */
@@ -130,53 +130,53 @@
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
/* Verdin UART_3, used as the Linux console */
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
/* Verdin UART_1 */
_uart1 {
- bootph-pre-ram;
+ bootph-all;
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
_ctrl_sleep_moci {
- bootph-pre-ram;
+ bootph-all;
};
_i2c0 {
- bootph-pre-ram;
+ bootph-all;
};
_i2c1 {
- bootph-pre-ram;
+ bootph-all;
};
_sdhci0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart1 {
- bootph-pre-ram;
+ bootph-all;
};
_wkup_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
{
@@ -184,18 +184,18 @@
};
_proxy_main {
- bootph-pre-ram;
+ bootph-all;
};
_ctrl_sleep_moci {
- bootph-pre-ram;
+ bootph-all;
};
_conf {
- bootph-pre-ram;
+ bootph-all;
};
/* Verdin UART_2 */
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
--
2.36.1
Re: ZFS support in custom u-boot build...
Hello Stacey, Am Thu, Oct 05, 2023 at 11:22:14AM +0100 schrieb Stacey Pellegrino: > To all those of concern, > > I am in need of help regarding building u-boot with ZFS support for the > Orange Pi 5 Plus. > > I have tried working out the following... > > https://github.com/u-boot/u-boot/blob/22ad69b7987eb4b10221330661db4427e40174fb/doc/README.zfs > > The URL link above specifies using the board specific config file, which > for the Orange Pi 5 Plus is (so I believe) > orangepi-build/userpatches/config-default.conf. > I therefore edited this file in question with CONFIG_CMD_ZFS="yes" and > uncommenting the line install_zfs="yes". In that regard this README.zfs is somewhat outdated. You should set CMD_ZFS through Kconfig instead. Which means: pick the matching defconfig from configs/ subfolder, then run menuconfig and enable CMD_ZFS, and build that. Not sure if that Orange Pi 5 Plus is already supported by U-Boot mainline already. From a quick glance at the defconfig filenames I would not know which to pick. > However, it still does not allow me to boot with root ZFS on the NVMe SSD > with the official Orange Pi Debian v12 (Bookwork) ARM image. ZFS does not > seem to be referenced in the custom u-boot source code build output as > well. I followed the build instructions located at the following URL link... > > http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_5_Plus#Compile_u-boot Oh you should have told before. This uses a custom build script not part of U-Boot, probably to call U-Boot build. Please contact that project on how to change U-Boot config instead. Or look at their build.sh and figure out how it configures and builds U-Boot. > ...but am I required to apply a patch to the u-boot source for ZFS support? > If so, then that could be my problem. If a patch is required, then how > would I go about applying this accordingly? Although they seem to use an outdated and patched version v2017.09 of u-boot: probably not. Please try with enabling CMD_ZFS in your U-Boot config first. It's in the menuconfig, also in v2017.09 already. Greets Alex > > Thank you in advance for help in this matter. Kindest regards, -Stacey > Pellegrino
Re: [PATCH] arm: rpi: explicitly enumerate mmc boot targets
On Sun, Oct 8, 2023 at 11:32 PM Ben Wolsieffer wrote:
>
> Hi Peter,
>
> On Sun, Oct 08, 2023 at 07:21:57PM +0100, Peter Robinson wrote:
> > On Sat, Oct 7, 2023 at 4:55 PM Ben Wolsieffer
> > wrote:
> > >
> > > Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
> > > fail to boot. c771e5b explains this approach as follows:
> > >
> > > > We don't need to specify the mmc devices individually, since they are
> > > > used in order from 0 to 2, and standard boot uses that order anyway.
> > >
> > > In practice, U-Boot first attempts to boot from the unconnected mmc1
> > > interface, and, when this fails, moves on to attempt the USB and network
> > > boot targets rather than trying mmc0.
> >
> > Really? It shouldn't be enumerating it if it's not defined in device
> > tree, I've not seen this in my testing.
>
> It does seem odd, but U-Boot definitely sees two MMC interfaces:
>
> U-Boot> mmc list
> mmcnr@7e30: 1
> mmc@7e34: 0 (SD)
The WiFi interface is connected by SDHCI/SDIO which AFAICT is the
first interface.
> >
> > > This patch explicitly enumerates the mmc interfaces, causing each to be
> > > attempted in turn. This matches what is done on other boards, and allows
> > > the system to boot successfully.
> > >
> > > Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
> > > Signed-off-by: Ben Wolsieffer
> > > ---
> > > board/raspberrypi/rpi/rpi.env | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
> > > index 30228285ed..02210b97b5 100644
> > > --- a/board/raspberrypi/rpi/rpi.env
> > > +++ b/board/raspberrypi/rpi/rpi.env
> > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250
> > > fdt_addr_r=0x0260
> > > ramdisk_addr_r=0x0270
> > >
> > > -boot_targets=mmc usb pxe dhcp
> > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp
> >
> > Why are you adding mmc1 and mmc2 if they're not connected?
>
> I was trying to match the old distro boot behavior, which had three MMC
> interfaces listed.
RE: U-Boot 2023.10 does not boot from uSD on RPi4
> -Original Message- > From: Peter Robinson > Sent: Tuesday, October 10, 2023 12:22 PM > To: Guillaume Gardet > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass > ; u-boot@lists.denx.de > Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4 > > On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet > wrote: > > > > Hi, > > > > U-Boot 2023.10 does not boot from uSD on RPi4. > > This has been found on openSUSE Tumbleweed. The only diff we need is: > > -CONFIG_OF_EMBED=y > > +CONFIG_OF_BOARD=y > > To use firmware provided Device Tree. But that should not affect the mmc > behavior too much, I think. > > I've been booting Fedora fine on a RPi4 BUT there's issues with the display > turning off [1] when the accelerated display modules load > (vc4) as a result of this patch set. Can you confirm if that's the same > problem > you're seeing? No, that's not my problem. My issue is grub was not loaded by u-boot from uSD. It seems more like Simon's problem: https://lists.denx.de/pipermail/u-boot/2023-October/533162.html @Simon, can you check if the patch below fixes your boot problem on RPi4, please? Thanks, Guillaume > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > > > 'git bisect' points to: > > ** > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > > Author: Simon Glass > > Date: Thu Jul 27 15:54:28 2023 -0600 > > > > arm: rpi: Switch to standard boot > > > > Drop use of the distro scripts and use standard boot instead. > > > > We don't need to specify the mmc devices individually, since they are > > used in order from 0 to 2, and standard boot uses that order anyway. > > > > Signed-off-by: Simon Glass > > ** > > > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 nor > > RPi > Zero 2 W): > > ** > > diff --git a/board/raspberrypi/rpi/rpi.env > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644 > > --- a/board/raspberrypi/rpi/rpi.env > > +++ b/board/raspberrypi/rpi/rpi.env > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > > fdt_addr_r=0x0260 > > ramdisk_addr_r=0x0270 > > > > -boot_targets=mmc usb pxe dhcp > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > > ** > > > > So, the comment from Simon " We don't need to specify the mmc devices > individually, since they are used in order from 0 to 2, and standard boot > uses that > order anyway" seems wrong for the RPi4 case. > > > > Cheers, > > Guillaume > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: U-Boot 2023.10 does not boot from uSD on RPi4
On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet wrote: > > Hi, > > U-Boot 2023.10 does not boot from uSD on RPi4. > This has been found on openSUSE Tumbleweed. The only diff we need is: > -CONFIG_OF_EMBED=y > +CONFIG_OF_BOARD=y > To use firmware provided Device Tree. But that should not affect the mmc > behavior too much, I think. I've been booting Fedora fine on a RPi4 BUT there's issues with the display turning off [1] when the accelerated display modules load (vc4) as a result of this patch set. Can you confirm if that's the same problem you're seeing? [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > 'git bisect' points to: > ** > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > Author: Simon Glass > Date: Thu Jul 27 15:54:28 2023 -0600 > > arm: rpi: Switch to standard boot > > Drop use of the distro scripts and use standard boot instead. > > We don't need to specify the mmc devices individually, since they are > used in order from 0 to 2, and standard boot uses that order anyway. > > Signed-off-by: Simon Glass > ** > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 nor > RPi Zero 2 W): > ** > diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env > index 30228285ed..02210b97b5 100644 > --- a/board/raspberrypi/rpi/rpi.env > +++ b/board/raspberrypi/rpi/rpi.env > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > fdt_addr_r=0x0260 > ramdisk_addr_r=0x0270 > > -boot_targets=mmc usb pxe dhcp > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > ** > > So, the comment from Simon " We don't need to specify the mmc devices > individually, since they are used in order from 0 to 2, and standard boot > uses that order anyway" seems wrong for the RPi4 case. > > Cheers, > Guillaume > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you.
U-Boot 2023.10 does not boot from uSD on RPi4
Hi, U-Boot 2023.10 does not boot from uSD on RPi4. This has been found on openSUSE Tumbleweed. The only diff we need is: -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y To use firmware provided Device Tree. But that should not affect the mmc behavior too much, I think. 'git bisect' points to: ** commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 Author: Simon Glass Date: Thu Jul 27 15:54:28 2023 -0600 arm: rpi: Switch to standard boot Drop use of the distro scripts and use standard boot instead. We don't need to specify the mmc devices individually, since they are used in order from 0 to 2, and standard boot uses that order anyway. Signed-off-by: Simon Glass ** The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 nor RPi Zero 2 W): ** diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644 --- a/board/raspberrypi/rpi/rpi.env +++ b/board/raspberrypi/rpi/rpi.env @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 fdt_addr_r=0x0260 ramdisk_addr_r=0x0270 -boot_targets=mmc usb pxe dhcp +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp ** So, the comment from Simon " We don't need to specify the mmc devices individually, since they are used in order from 0 to 2, and standard boot uses that order anyway" seems wrong for the RPi4 case. Cheers, Guillaume IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
[PATCH v2 6/6] binman: capsule: Add support for generating EFI empty capsules
Add support in binman for generating EFI empty capsules. These
capsules are used in the FWU A/B update feature. Also add test cases
in binman for the corresponding code coverage.
Signed-off-by: Sughosh Ganu
---
Changes since V1:
* Instead of using two separate boolean values, use a 'capsule-type'
property for indicating generation of an accept/revert capsule.
* Make corresponding changes in the sanity checks, documentation and
tests based on the above change.
* Use lower case characters for GUIDs.
* Call get_binman_test_guid() from the efi_capsule entry module.
* Add the documentation entry for the empty capsules in entries.rst.
* Remove the #[address,size]-cells properties from the test dts' for
empty capsules.
tools/binman/entries.rst | 44 ++
tools/binman/etype/efi_empty_capsule.py | 86 +++
tools/binman/ftest.py | 57
tools/binman/test/319_capsule_accept.dts | 13 +++
tools/binman/test/320_capsule_revert.dts | 11 +++
.../test/321_capsule_accept_missing_guid.dts | 11 +++
.../test/322_empty_capsule_type_missing.dts | 12 +++
.../323_capsule_accept_revert_missing.dts | 13 +++
8 files changed, 247 insertions(+)
create mode 100644 tools/binman/etype/efi_empty_capsule.py
create mode 100644 tools/binman/test/319_capsule_accept.dts
create mode 100644 tools/binman/test/320_capsule_revert.dts
create mode 100644 tools/binman/test/321_capsule_accept_missing_guid.dts
create mode 100644 tools/binman/test/322_empty_capsule_type_missing.dts
create mode 100644 tools/binman/test/323_capsule_accept_revert_missing.dts
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index 801bd94674..e7b4e9380e 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -532,6 +532,50 @@ payload using the blob-ext subnode.
+.. _etype_efi_empty_capsule:
+
+Entry: efi-empty-capsule: Entry for generating EFI Empty Capsule files
+--
+
+The parameters needed for generation of the empty capsules can
+be provided as properties in the entry.
+
+Properties / Entry arguments:
+- image-guid: Image GUID which will be used for identifying the
+ updatable image on the board. Mandatory for accept capsule.
+- capsule-type - String to indicate type of capsule to generate. Valid
+ values are 'accept' and 'revert'.
+
+For more details on the description of the capsule format, and the capsule
+update functionality, refer Section 8.5 and Chapter 23 in the `UEFI
+specification`_. For more information on the empty capsule, refer the
+sections 2.3.2 and 2.3.3 in the `Dependable Boot specification`_.
+
+A typical accept empty capsule entry node would then look something
+like this::
+
+empty-capsule {
+type = "efi-empty-capsule";
+/* GUID of the image being accepted */
+image-type-id = SANDBOX_UBOOT_IMAGE_GUID;
+capsule-type = "accept";
+};
+
+A typical revert empty capsule entry node would then look something
+like this::
+
+empty-capsule {
+type = "efi-empty-capsule";
+capsule-type = "revert";
+};
+
+The empty capsules do not have any input payload image.
+
+.. _`UEFI specification`:
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_10_Aug29.pdf
+.. _`Dependable Boot specification`:
https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf
+
+
+
.. _etype_encrypted:
Entry: encrypted: Externally built encrypted binary blob
diff --git a/tools/binman/etype/efi_empty_capsule.py
b/tools/binman/etype/efi_empty_capsule.py
new file mode 100644
index 00..064bf9a77f
--- /dev/null
+++ b/tools/binman/etype/efi_empty_capsule.py
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2023 Linaro Limited
+#
+# Entry-type module for producing an empty EFI capsule
+#
+
+import os
+
+from binman.entry import Entry
+from binman.etype.efi_capsule import get_binman_test_guid
+from binman.etype.section import Entry_section
+from dtoc import fdt_util
+from u_boot_pylib import tools
+
+class Entry_efi_empty_capsule(Entry_section):
+"""Generate EFI empty capsules
+
+The parameters needed for generation of the empty capsules can
+be provided as properties in the entry.
+
+Properties / Entry arguments:
+- image-guid: Image GUID which will be used for identifying the
+ updatable image on the board. Mandatory for accept capsule.
+- capsule-type - String to indicate type of capsule to generate. Valid
+ values are 'accept' and 'revert'.
+
+For more details on the description of the capsule format, and the capsule
+update functionality, refer Section 8.5 and Chapter 23 in the `UEFI
+specification`_. For more information on the empty capsule, refer the
+sections 2.3.2 and 2.3.3 in the `Dependable Boot specification`_.
+
+A
[PATCH v2 5/6] btool: mkeficapsule: Add support for EFI empty capsule generation
Add a method to the mkeficapsule bintool to generate empty
capsules. These are capsules needed for the FWU A/B update feature.
Signed-off-by: Sughosh Ganu
---
Changes since V1:
* Use a single boolean value to indicate the generation of either of
accept/revert capsule.
* Move the parameters added to the list on the same line in a couple
of places.
tools/binman/btool/mkeficapsule.py | 26 ++
1 file changed, 26 insertions(+)
diff --git a/tools/binman/btool/mkeficapsule.py
b/tools/binman/btool/mkeficapsule.py
index 61179747ff..ef1da638df 100644
--- a/tools/binman/btool/mkeficapsule.py
+++ b/tools/binman/btool/mkeficapsule.py
@@ -80,6 +80,32 @@ class Bintoolmkeficapsule(bintool.Bintool):
return self.run_cmd(*args)
+def generate_empty_capsule(self, image_guid, output_fname,
+ accept=True):
+"""Generate empty capsules for FWU A/B updates
+
+Args:
+image_guid (str): GUID used for identifying the image
+in case of an accept capsule
+output_fname (str): Path to the output capsule file
+accept (bool): Generate an accept capsule,
+else a revert capsule
+
+Returns:
+str: Tool output
+"""
+if accept:
+args = [
+f'--guid={image_guid}',
+'--fw-accept'
+]
+else:
+args = [ '--fw-revert' ]
+
+args += [ output_fname ]
+
+return self.run_cmd(*args)
+
def fetch(self, method):
"""Fetch handler for mkeficapsule
--
2.34.1
[PATCH v2 4/6] binman: capsule: Use dumped capsule header contents for verification
The various fields of a generated capsule are currently verified
through hard-coded offsets. Use the dump-capsule feature for dumping
the capsule header contents and use those for capsule verification.
Signed-off-by: Sughosh Ganu
---
Changes since V1:
* Move the get_binman_test_guid() function outside the
Entry_efi_capsule class so that it can be called from outside the
module.
* Use lowercase characters in the GUID values
* Add comments for the _GetCapsuleHeaders() function.
* Use a simple dict in _GetCapsuleHeaders() for storing the capsule
header values dumped by the mkeficapsule tool.
tools/binman/etype/efi_capsule.py | 24 +--
tools/binman/ftest.py | 105 ++
2 files changed, 82 insertions(+), 47 deletions(-)
diff --git a/tools/binman/etype/efi_capsule.py
b/tools/binman/etype/efi_capsule.py
index 006eb630ad..e320371782 100644
--- a/tools/binman/etype/efi_capsule.py
+++ b/tools/binman/etype/efi_capsule.py
@@ -11,6 +11,24 @@ from binman.etype.section import Entry_section
from dtoc import fdt_util
from u_boot_pylib import tools
+def get_binman_test_guid(type_str):
+"""Get the test image GUID for binman
+
+Based on the string passed to the function, return
+the corresponding GUID.
+
+Args:
+type_str: Key value of the type of GUID to look for
+
+Returns:
+The actual GUID value (str)
+"""
+TYPE_TO_GUID = {
+'binman-test' : '09d7cf52-0720-4710-91d1-08469b7fe9c8'
+}
+
+return TYPE_TO_GUID[type_str]
+
class Entry_efi_capsule(Entry_section):
"""Generate EFI capsules
@@ -104,12 +122,6 @@ class Entry_efi_capsule(Entry_section):
self.auth = 1
def BuildSectionData(self, required):
-def get_binman_test_guid(type_str):
-TYPE_TO_GUID = {
-'binman-test' : '09d7cf52-0720-4710-91d1-08469b7fe9c8'
-}
-return TYPE_TO_GUID[type_str]
-
private_key = ''
public_key_cert = ''
if self.auth:
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 8e419645a6..2ea18d2d08 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -121,9 +121,11 @@ COMP_BINTOOLS = ['bzip2', 'gzip', 'lz4', 'lzma_alone',
'lzop', 'xz', 'zstd']
TEE_ADDR = 0x5678
# Firmware Management Protocol(FMP) GUID
-FW_MGMT_GUID = 'edd5cb6d2de8444cbda17194199ad92a'
+FW_MGMT_GUID = '6dcbd5ed-e82d-4c44-bda1-7194199ad92a'
# Image GUID specified in the DTS
-CAPSULE_IMAGE_GUID = '52cfd7092007104791d108469b7fe9c8'
+CAPSULE_IMAGE_GUID = '09d7cf52-0720-4710-91d1-08469b7fe9c8'
+# Windows cert GUID
+WIN_CERT_TYPE_EFI_GUID = '4aafd29d-68df-49ee-8aa9-347d375665a7'
class TestFunctional(unittest.TestCase):
"""Functional tests for binman
@@ -7223,52 +7225,73 @@ fdt fdtmapExtract the
devicetree blob from the fdtmap
self.assertRegex(err,
"Image 'image'.*missing bintools.*: bootgen")
+def _GetCapsuleHeaders(self, data):
+"""Get the capsule header contents
+
+Args:
+data: Capsule file contents
+
+Returns:
+Dict:
+key: Capsule Header name (str)
+value: Header field value (str)
+"""
+capsule_file = os.path.join(self._indir, 'test.capsule')
+tools.write_file(capsule_file, data)
+
+out = tools.run('mkeficapsule', '--dump-capsule', capsule_file)
+lines = out.splitlines()
+
+re_line = re.compile(r'^([^:\-\t]*)(?:\t*\s*:\s*(.*))?$')
+vals = {}
+for line in lines:
+mat = re_line.match(line)
+if mat:
+vals[mat.group(1)] = mat.group(2)
+
+return vals
+
def _CheckCapsule(self, data, signed_capsule=False, version_check=False,
capoemflags=False):
-fmp_signature = "4d535331" # 'M', 'S', 'S', '1'
-fmp_size = "10"
-fmp_fw_version = "02"
-oemflag = "0080"
+fmp_signature = "3153534D" # 'M', 'S', 'S', '1'
+fmp_size = "0010"
+fmp_fw_version = "0002"
+capsule_image_index = "0001"
+oemflag = "00018000"
+auth_hdr_revision = "0200"
+auth_hdr_cert_type = "0EF1"
+
+payload_data_len = len(EFI_CAPSULE_DATA)
-payload_data = EFI_CAPSULE_DATA
+hdr = self._GetCapsuleHeaders(data)
-# TODO - Currently, these offsets for capsule fields are hardcoded.
-# There are plans to add support to the mkeficapsule tool to dump
-# the capsule contents which can then be used for capsule
-# verification.
+self.assertEqual(FW_MGMT_GUID.upper(),
hdr['EFI_CAPSULE_HDR.CAPSULE_GUID'])
-# Firmware Management Protocol(FMP) GUID - offset(0 - 32)
-self.assertEqual(FW_MGMT_GUID, data.hex()[:32])
-# Image GUID - offset(96 - 128)
-self.assertEqual(CAPSULE_IMAGE_GUID, data.hex()[96:128])
+
[PATCH v2 3/6] binman: capsule: Remove superfluous [address, size]-cells properties
The #address-cells and #size-cells are not needed for running the
capsule generation binman tests. Remove the superfluous properties.
Signed-off-by: Sughosh Ganu
---
Changes since V1:
* New patch based on review comment from Simon.
tools/binman/test/311_capsule.dts | 3 ---
tools/binman/test/312_capsule_signed.dts| 3 ---
tools/binman/test/313_capsule_version.dts | 3 ---
tools/binman/test/314_capsule_signed_ver.dts| 3 ---
tools/binman/test/315_capsule_oemflags.dts | 3 ---
tools/binman/test/316_capsule_missing_key.dts | 3 ---
tools/binman/test/317_capsule_missing_index.dts | 3 ---
tools/binman/test/318_capsule_missing_guid.dts | 3 ---
8 files changed, 24 deletions(-)
diff --git a/tools/binman/test/311_capsule.dts
b/tools/binman/test/311_capsule.dts
index 8eb4250b14..0a62ef81dd 100644
--- a/tools/binman/test/311_capsule.dts
+++ b/tools/binman/test/311_capsule.dts
@@ -3,9 +3,6 @@
/dts-v1/;
/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
binman {
efi-capsule {
image-index = <0x1>;
diff --git a/tools/binman/test/312_capsule_signed.dts
b/tools/binman/test/312_capsule_signed.dts
index d1c76e269c..4ab838efed 100644
--- a/tools/binman/test/312_capsule_signed.dts
+++ b/tools/binman/test/312_capsule_signed.dts
@@ -3,9 +3,6 @@
/dts-v1/;
/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
binman {
efi-capsule {
image-index = <0x1>;
diff --git a/tools/binman/test/313_capsule_version.dts
b/tools/binman/test/313_capsule_version.dts
index bafef3609e..19e7e83348 100644
--- a/tools/binman/test/313_capsule_version.dts
+++ b/tools/binman/test/313_capsule_version.dts
@@ -3,9 +3,6 @@
/dts-v1/;
/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
binman {
efi-capsule {
image-index = <0x1>;
diff --git a/tools/binman/test/314_capsule_signed_ver.dts
b/tools/binman/test/314_capsule_signed_ver.dts
index 85c784bba4..649b8ccb2d 100644
--- a/tools/binman/test/314_capsule_signed_ver.dts
+++ b/tools/binman/test/314_capsule_signed_ver.dts
@@ -3,9 +3,6 @@
/dts-v1/;
/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
binman {
efi-capsule {
image-index = <0x1>;
diff --git a/tools/binman/test/315_capsule_oemflags.dts
b/tools/binman/test/315_capsule_oemflags.dts
index f736e8758f..45853f69c3 100644
--- a/tools/binman/test/315_capsule_oemflags.dts
+++ b/tools/binman/test/315_capsule_oemflags.dts
@@ -3,9 +3,6 @@
/dts-v1/;
/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
binman {
efi-capsule {
image-index = <0x1>;
diff --git a/tools/binman/test/316_capsule_missing_key.dts
b/tools/binman/test/316_capsule_missing_key.dts
index 2080b50e3d..a14a74ee77 100644
--- a/tools/binman/test/316_capsule_missing_key.dts
+++ b/tools/binman/test/316_capsule_missing_key.dts
@@ -3,9 +3,6 @@
/dts-v1/;
/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
binman {
efi-capsule {
image-index = <0x1>;
diff --git a/tools/binman/test/317_capsule_missing_index.dts
b/tools/binman/test/317_capsule_missing_index.dts
index aadb61f647..99a54d55c3 100644
--- a/tools/binman/test/317_capsule_missing_index.dts
+++ b/tools/binman/test/317_capsule_missing_index.dts
@@ -3,9 +3,6 @@
/dts-v1/;
/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
binman {
efi-capsule {
/* Image GUID for testing capsule update */
diff --git a/tools/binman/test/318_capsule_missing_guid.dts
b/tools/binman/test/318_capsule_missing_guid.dts
index d76afba853..85d3317ecb 100644
--- a/tools/binman/test/318_capsule_missing_guid.dts
+++ b/tools/binman/test/318_capsule_missing_guid.dts
@@ -3,9 +3,6 @@
/dts-v1/;
/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
binman {
efi-capsule {
image-index = <0x1>;
--
2.34.1
[PATCH v2 2/6] doc: capsule: Add documentation for the capsule dump feature
Add documentation to explain the printing of the capsule headers through the mkeficapsule tool. Signed-off-by: Sughosh Ganu Reviewed-by: Simon Glass --- Changes since V1: None doc/develop/uefi/uefi.rst | 17 + 1 file changed, 17 insertions(+) diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index 68f9b332d1..f16580e169 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -385,6 +385,23 @@ capsules. Refer :ref:`etype_efi_capsule` for documentation about the efi-capsule binman entry type, which describes all the properties that can be specified. +Dumping capsule headers +*** + +The mkeficapsule tool also provides a command-line option to dump the +contents of the capsule header. This is a useful functionality when +trying to understand the structure of a capsule and is also used in +capsule verification. This feature is used in testing the capsule +contents in binman's test framework. + +To check the contents of the capsule headers, the mkeficapsule command +can be used. + +.. code-block:: console + +$ mkeficapsule --dump-capsule \ + + Performing the update * -- 2.34.1
[PATCH v2 1/6] tools: mkeficapsule: Add support to print capsule headers
Add support to dump the contents of capsule headers. This is useful as
a debug feature for checking the contents of the capsule headers, and
can also be used in capsule verification.
Signed-off-by: Sughosh Ganu
Reviewed-by: Simon Glass
---
Changes since V1:
* Get rid of the superfluous hdr_size variable in the
dump_fmp_payload_header() function
tools/eficapsule.h | 2 +
tools/mkeficapsule.c | 227 ++-
2 files changed, 228 insertions(+), 1 deletion(-)
diff --git a/tools/eficapsule.h b/tools/eficapsule.h
index 2099a2e9b8..6efd07d2eb 100644
--- a/tools/eficapsule.h
+++ b/tools/eficapsule.h
@@ -22,6 +22,8 @@
#define __aligned(x) __attribute__((__aligned__(x)))
#endif
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+
typedef struct {
uint8_t b[16];
} efi_guid_t __aligned(8);
diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index 52be1f122e..b8fc6069b5 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -29,7 +29,7 @@ static const char *tool_name = "mkeficapsule";
efi_guid_t efi_guid_fm_capsule = EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
-static const char *opts_short = "g:i:I:v:p:c:m:o:dhAR";
+static const char *opts_short = "g:i:I:v:p:c:m:o:dhARD";
enum {
CAPSULE_NORMAL_BLOB = 0,
@@ -49,6 +49,7 @@ static struct option options[] = {
{"fw-accept", no_argument, NULL, 'A'},
{"fw-revert", no_argument, NULL, 'R'},
{"capoemflag", required_argument, NULL, 'o'},
+ {"dump-capsule", no_argument, NULL, 'D'},
{"help", no_argument, NULL, 'h'},
{NULL, 0, NULL, 0},
};
@@ -69,6 +70,7 @@ static void print_usage(void)
"\t-A, --fw-accept firmware accept capsule, requires GUID, no
image blob\n"
"\t-R, --fw-revert firmware revert capsule, takes no GUID, no
image blob\n"
"\t-o, --capoemflag Capsule OEM Flag, an integer between 0x
and 0x\n"
+ "\t-D, --dump-capsule dump the contents of the capsule
headers\n"
"\t-h, --help print a help message\n",
tool_name);
}
@@ -647,6 +649,215 @@ err:
return ret;
}
+static void print_guid(void *ptr)
+{
+ int i;
+ efi_guid_t *guid = ptr;
+ const uint8_t seq[] = {
+ 3, 2, 1, 0, '-', 5, 4, '-', 7, 6,
+ '-', 8, 9, '-', 10, 11, 12, 13, 14, 15 };
+
+ for (i = 0; i < ARRAY_SIZE(seq); i++) {
+ if (seq[i] == '-')
+ putchar(seq[i]);
+ else
+ printf("%02X", guid->b[seq[i]]);
+ }
+
+ printf("\n");
+}
+
+static uint32_t dump_fmp_payload_header(
+ struct fmp_payload_header *fmp_payload_hdr)
+{
+ if (fmp_payload_hdr->signature == FMP_PAYLOAD_HDR_SIGNATURE) {
+ printf("\n");
+ printf("FMP_PAYLOAD_HDR.SIGNATURE\t\t\t: %08X\n",
+ FMP_PAYLOAD_HDR_SIGNATURE);
+ printf("FMP_PAYLOAD_HDR.HEADER_SIZE\t\t\t: %08X\n",
+ fmp_payload_hdr->header_size);
+ printf("FMP_PAYLOAD_HDR.FW_VERSION\t\t\t: %08X\n",
+ fmp_payload_hdr->fw_version);
+ printf("FMP_PAYLOAD_HDR.LOWEST_SUPPORTED_VERSION\t: %08X\n",
+ fmp_payload_hdr->lowest_supported_version);
+ return fmp_payload_hdr->header_size;
+ }
+
+ return 0;
+}
+
+static void dump_capsule_auth_header(
+ struct efi_firmware_image_authentication *capsule_auth_hdr)
+{
+ printf("EFI_FIRMWARE_IMAGE_AUTH.MONOTONIC_COUNT\t\t: %08lX\n",
+ capsule_auth_hdr->monotonic_count);
+ printf("EFI_FIRMWARE_IMAGE_AUTH.AUTH_INFO.HDR.dwLENGTH\t: %08X\n",
+ capsule_auth_hdr->auth_info.hdr.dwLength);
+ printf("EFI_FIRMWARE_IMAGE_AUTH.AUTH_INFO.HDR.wREVISION\t: %08X\n",
+ capsule_auth_hdr->auth_info.hdr.wRevision);
+ printf("EFI_FIRMWARE_IMAGE_AUTH.AUTH_INFO.HDR.wCERTTYPE\t: %08X\n",
+ capsule_auth_hdr->auth_info.hdr.wCertificateType);
+ printf("EFI_FIRMWARE_IMAGE_AUTH.AUTH_INFO.CERT_TYPE\t: ");
+ print_guid(_auth_hdr->auth_info.cert_type);
+}
+
+static void dump_fmp_capsule_image_header(
+ struct efi_firmware_management_capsule_image_header *image_hdr)
+{
+ void *capsule_auth_hdr;
+ void *fmp_payload_hdr;
+ uint64_t signature_size = 0;
+ uint32_t payload_size = 0;
+ uint32_t fmp_payload_hdr_size = 0;
+ struct efi_firmware_image_authentication *auth_hdr;
+
+ printf("\n");
+ printf("FMP_CAPSULE_IMAGE_HDR.VERSION\t\t\t: %08X\n",
+ image_hdr->version);
+ printf("FMP_CAPSULE_IMAGE_HDR.UPDATE_IMAGE_TYPE_ID\t: ");
+ print_guid(_hdr->update_image_type_id);
+ printf("FMP_CAPSULE_IMAGE_HDR.UPDATE_IMAGE_INDEX\t: %08X\n",
+
[PATCH v2 0/6] Support for dumping capsule headers and empty capsules
These set of patches are intended for two tasks. The first set of patches are adding support for dumping capsule header information, which is then being used in the binman test framework for testing the capsule generation. This replaces the current hardcoding of offsets used for verifying the capsule contents in the binman tests. Patch 1 introduces this functionality in the mkeficapsule tool. Patch 4 is using this functionality in the binman tests for capsules. The other set of patches, 5 and 6 are for adding support for generation of empty capsules in binman. The empty capsules are used for the FWU A/B update functionality. Changes since V1: * Get rid of the superfluous hdr_size variable in the dump_fmp_payload_header() function * Move the get_binman_test_guid() function outside the Entry_efi_capsule class so that it can be called from outside the module. * Use lowercase characters in the GUID values * Add comments for the _GetCapsuleHeaders() function. * Use a simple dict in _GetCapsuleHeaders() for storing the capsule header values dumped by the mkeficapsule tool. * Use a single boolean value to indicate the generation of either of accept/revert capsule. * Move the parameters added to the list on the same line in a couple of places. * Instead of using two separate boolean values, use a 'capsule-type' property for indicating generation of an accept/revert capsule. * Make corresponding changes in the sanity checks, documentation and tests based on the above change. * Use lower case characters for GUIDs. * Call get_binman_test_guid() from the efi_capsule entry module. * Add the documentation entry for the empty capsules in entries.rst. * Remove the #[address,size]-cells properties from the test dts' for empty capsules. Sughosh Ganu (6): tools: mkeficapsule: Add support to print capsule headers doc: capsule: Add documentation for the capsule dump feature binman: capsule: Remove superfluous [address,size]-cells properties binman: capsule: Use dumped capsule header contents for verification btool: mkeficapsule: Add support for EFI empty capsule generation binman: capsule: Add support for generating EFI empty capsules doc/develop/uefi/uefi.rst | 17 ++ tools/binman/btool/mkeficapsule.py| 26 ++ tools/binman/entries.rst | 44 tools/binman/etype/efi_capsule.py | 24 +- tools/binman/etype/efi_empty_capsule.py | 86 +++ tools/binman/ftest.py | 160 +--- tools/binman/test/311_capsule.dts | 3 - tools/binman/test/312_capsule_signed.dts | 3 - tools/binman/test/313_capsule_version.dts | 3 - tools/binman/test/314_capsule_signed_ver.dts | 3 - tools/binman/test/315_capsule_oemflags.dts| 3 - tools/binman/test/316_capsule_missing_key.dts | 3 - .../binman/test/317_capsule_missing_index.dts | 3 - .../binman/test/318_capsule_missing_guid.dts | 3 - tools/binman/test/319_capsule_accept.dts | 13 + tools/binman/test/320_capsule_revert.dts | 11 + .../test/321_capsule_accept_missing_guid.dts | 11 + .../test/322_empty_capsule_type_missing.dts | 12 + .../323_capsule_accept_revert_missing.dts | 13 + tools/eficapsule.h| 2 + tools/mkeficapsule.c | 227 +- 21 files changed, 599 insertions(+), 71 deletions(-) create mode 100644 tools/binman/etype/efi_empty_capsule.py create mode 100644 tools/binman/test/319_capsule_accept.dts create mode 100644 tools/binman/test/320_capsule_revert.dts create mode 100644 tools/binman/test/321_capsule_accept_missing_guid.dts create mode 100644 tools/binman/test/322_empty_capsule_type_missing.dts create mode 100644 tools/binman/test/323_capsule_accept_revert_missing.dts -- 2.34.1
Re: [PATCH 10/15] cmd: blk_common: Use macros for the return values
Hi Simon,
On Mon, Oct 2, 2023 at 9:42 AM Simon Glass wrote:
>
> Hi Bin,
>
> On Tue, 26 Sept 2023 at 02:54, Bin Meng wrote:
> >
> > Avoid using magic number 0/1 for the command result.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > cmd/blk_common.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/cmd/blk_common.c b/cmd/blk_common.c
> > index 9f9d4327a9..ad9b16dc09 100644
> > --- a/cmd/blk_common.c
> > +++ b/cmd/blk_common.c
> > @@ -25,18 +25,18 @@ int blk_common_cmd(int argc, char *const argv[], enum
> > uclass_id uclass_id,
> > case 2:
> > if (strncmp(argv[1], "inf", 3) == 0) {
> > blk_list_devices(uclass_id);
> > - return 0;
> > + return CMD_RET_SUCCESS;
>
> I really don't like this...0 is success.
>
> > } else if (strncmp(argv[1], "dev", 3) == 0) {
> > if (blk_print_device_num(uclass_id, *cur_devnump)) {
> > printf("\nno %s devices available\n",
> > if_name);
> > return CMD_RET_FAILURE;
> > }
> > - return 0;
> > + return CMD_RET_SUCCESS;
> > } else if (strncmp(argv[1], "part", 4) == 0) {
> > if (blk_list_part(uclass_id))
> > printf("\nno %s partition table
> > available\n",
> >if_name);
> > - return 0;
> > + return CMD_RET_SUCCESS;
> > }
> > return CMD_RET_USAGE;
> > case 3:
> > @@ -49,7 +49,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
> > uclass_id uclass_id,
> > } else {
> > return CMD_RET_FAILURE;
> > }
> > - return 0;
> > + return CMD_RET_SUCCESS;
> > } else if (strncmp(argv[1], "part", 4) == 0) {
> > int dev = (int)dectoul(argv[2], NULL);
> >
> > @@ -58,7 +58,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
> > uclass_id uclass_id,
> >if_name, dev);
> > return CMD_RET_FAILURE;
> > }
> > - return 0;
> > + return CMD_RET_SUCCESS;
> > }
> > return CMD_RET_USAGE;
> >
> > @@ -80,7 +80,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
> > uclass_id uclass_id,
> >
> > printf("%ld blocks read: %s\n", n,
> >n == cnt ? "OK" : "ERROR");
> > - return n == cnt ? 0 : 1;
> > + return n == cnt ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
>
> CMD_RET_FAILURE is OK, but I would prefer not to use CMD_RET_SUCCESS.
> It is 0 and always will be.
>
> It encourages people to do things like:
>
> if (ret == CMD_RET_SUCCESS)
>
> instead of
>
> if (!ret)
I see your concern. However we don't change the return value type to
enum, so people can still use
if (!ret)
I would still defend that we should use CMD_RET_SUCCESS.
This is like EXIT_XXX defined in stdlib.h:
#define EXIT_FAILURE 1/* Failing exit status. */
#define EXIT_SUCCESS 0/* Successful exit status. */
One should use predefined macros whenever possible.
>
> It would eventually creep into everything, including our clean error handling.
>
> > } else if (strcmp(argv[1], "write") == 0) {
> > phys_addr_t paddr = hextoul(argv[2], NULL);
> > lbaint_t blk = hextoul(argv[3], NULL);
> > @@ -98,7 +98,7 @@ int blk_common_cmd(int argc, char *const argv[], enum
> > uclass_id uclass_id,
> >
> > printf("%ld blocks written: %s\n", n,
> >n == cnt ? "OK" : "ERROR");
> > - return n == cnt ? 0 : 1;
> > + return n == cnt ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
> > } else {
> > return CMD_RET_USAGE;
> > }
> > --
Regards,
Bin
[PATCH v3 3/3] usb: udc: Try to clarify an error message
At some point when trying to use USB gadgets, two situations may arise
and lead to a failure. Either the UDC (USB Device Controller) is not
available at all (not described or not probed) or the UDC is already in
use. For instance, as the USB Ethernet gadget remains bound to the UDC,
the use of any other USB gadget (fastboot, dfu, etc) *after* will always
fail with the "couldn't find an available UDC" error.
Let's give a more helpful message by making a difference between the two
cases. Let's also hint people who would get this error and grep it into
the sources a better explanation of what's wrong with their workflow.
Signed-off-by: Miquel Raynal
Reviewed-by: Mattijs Korpershoek
---
While doing this I really wanted to add "much more" error comments but I
faced another reality: often the messages are there but use
pr_err/log_err which is actually silenced by default with LOGLEVEL=3, so
I consider this unnecessary, as decreasing the loglevel will make these
messages appear. I would have expected errors to be displayed, but I
understand it makes the binaries even bigger.
---
drivers/usb/gadget/udc/udc-core.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 7f73926cb3e..8405b03462e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -323,6 +323,7 @@ err1:
int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
{
struct usb_udc *udc = NULL;
+ unsigned intudc_count = 0;
int ret;
if (!driver || !driver->bind || !driver->setup)
@@ -330,12 +331,22 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
*driver)
mutex_lock(_lock);
list_for_each_entry(udc, _list, list) {
+ udc_count++;
+
/* For now we take the first one */
if (!udc->driver)
goto found;
}
- printf("couldn't find an available UDC\n");
+ if (!udc_count)
+ printf("No UDC available in the system\n");
+ else
+ /* When this happens, users should 'unbind '
+* using the output of 'dm tree' and looking at the line right
+* after the USB peripheral/device controller.
+*/
+ printf("All UDCs in use (%d available), use the unbind
command\n",
+ udc_count);
mutex_unlock(_lock);
return -ENODEV;
found:
--
2.34.1
[PATCH v3 2/3] cmd: bind: Try to improve the (un)bind help
While it may sound totally obvious for the regular U-Boot developer to get the parameters of the bind/unbind commands from the output of 'dm tree', it did not felt straightforward to me until I was explicitly told to look there. And even when I knew the command, I did not make a direct link between the arguments of this command and the columns returned by 'dm tree'. Several of us lost a lot of time because of that, I would like to kindly help other users by slightly improving this textual line. Unfortunately, because of how this string is used (like within the 'help' command) I cannot detail much more, but at least the pointer is there. While we add this message, we can also imply CMD_DM when we enable CMD_BIND so the debug message does not lead to an unknown command. This way the 'dm' command will likely be there unless explicitly disabled. Signed-off-by: Miquel Raynal Reviewed-by: Simon Glass Reviewed-by: Mattijs Korpershoek --- cmd/Kconfig | 1 + cmd/bind.c | 4 2 files changed, 5 insertions(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index 6cc3bf6c2d0..668411fd87c 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -996,6 +996,7 @@ config CMD_BCB config CMD_BIND bool "bind/unbind - Bind or unbind a device to/from a driver" depends on DM + imply CMD_DM help Bind or unbind a device to/from a driver from the command line. This is useful in situations where a device may be handled by several diff --git a/cmd/bind.c b/cmd/bind.c index 4d1b7885e60..be0d4d2a711 100644 --- a/cmd/bind.c +++ b/cmd/bind.c @@ -246,6 +246,8 @@ U_BOOT_CMD( "Bind a device to a driver", " \n" "bind \n" + "Use 'dm tree' to list all devices registered in the driver model,\n" + "their path, class, index and current driver.\n" ); U_BOOT_CMD( @@ -254,4 +256,6 @@ U_BOOT_CMD( "\n" "unbind \n" "unbind \n" + "Use 'dm tree' to list all devices registered in the driver model,\n" + "their path, class, index and current driver.\n" ); -- 2.34.1
[PATCH v3 1/3] cmd: Change the dependencies between CMD_BIND and USB_GADGET
Today CMD_BIND defaults to 'y' when USB_ETHER is enabled. In practice, CMD_BIND should default to 'y' when any USB gadget is enabled not only USB_ETHER. Let's invert the logic of the dependency and use the weak 'imply' keyword to enforce this. Signed-off-by: Miquel Raynal --- cmd/Kconfig| 1 - drivers/usb/gadget/Kconfig | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 43ca10f69cc..6cc3bf6c2d0 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -996,7 +996,6 @@ config CMD_BCB config CMD_BIND bool "bind/unbind - Bind or unbind a device to/from a driver" depends on DM - default y if USB_ETHER help Bind or unbind a device to/from a driver from the command line. This is useful in situations where a device may be handled by several diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 1cfe6022842..44f47a07207 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -17,6 +17,7 @@ menuconfig USB_GADGET bool "USB Gadget Support" depends on DM select DM_USB + imply CMD_BIND help USB is a master/slave protocol, organized with one master host (such as a PC) controlling up to 127 peripheral devices. -- 2.34.1
[PATCH v3 0/3] Improve the experience with USB gadgets
Try to ease the use of USB gadgets for people not fully aware of all the terms and constraints. With more helpful error messages a little bit of guidance anyone should be able to adapt to the bind/unbind game that is now necessary with USB gadgets. The idea is to eventually get proper USB composite gadget support, but that is a longer term goal. Changes in v3: * First patch is new. * Collected the tags received. * Imply CMD_DM from CMD_BIND. Miquel Raynal (3): cmd: Change the dependencies between CMD_BIND and USB_GADGET cmd: bind: Try to improve the (un)bind help usb: udc: Try to clarify an error message cmd/Kconfig | 2 +- cmd/bind.c| 4 drivers/usb/gadget/Kconfig| 1 + drivers/usb/gadget/udc/udc-core.c | 13 - 4 files changed, 18 insertions(+), 2 deletions(-) -- 2.34.1
[PATCH v1 2/7] clk: rockchip: rk3568: add i2s3 clk
Change-Id: If20fe16260d2b584d4216d1dbabffcb25478fb1d
Signed-off-by: Elaine Zhang
---
.../include/asm/arch-rockchip/cru_rk3568.h| 36 +++
drivers/clk/rockchip/clk_rk3568.c | 218 ++
2 files changed, 254 insertions(+)
diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
b/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
index 9c7ddd751f72..0306ce57e369 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3568.h
@@ -211,6 +211,31 @@ enum {
ACLK_PERIMID_SEL_100M,
ACLK_PERIMID_SEL_24M,
+ /* CRU_CLK_SEL21_CON */
+ I2S3_MCLKOUT_TX_SEL_SHIFT = 15,
+ I2S3_MCLKOUT_TX_SEL_MASK= 1 << I2S3_MCLKOUT_TX_SEL_SHIFT,
+ I2S3_MCLKOUT_TX_SEL_MCLK= 0,
+ I2S3_MCLKOUT_TX_SEL_12M,
+ CLK_I2S3_SEL_SHIFT = 10,
+ CLK_I2S3_SEL_MASK = 0x3 << CLK_I2S3_SEL_SHIFT,
+ CLK_I2S3_SEL_SRC= 0,
+ CLK_I2S3_SEL_FRAC,
+ CLK_I2S3_SEL_CLKIN,
+ CLK_I2S3_SEL_XIN12M,
+ CLK_I2S3_SRC_SEL_SHIFT = 8,
+ CLK_I2S3_SRC_SEL_MASK = 0x3 << CLK_I2S3_SRC_SEL_SHIFT,
+ CLK_I2S3_SRC_SEL_GPLL = 0,
+ CLK_I2S3_SRC_SEL_CPLL,
+ CLK_I2S3_SRC_SEL_NPLL,
+ CLK_I2S3_SRC_DIV_SHIFT = 0,
+ CLK_I2S3_SRC_DIV_MASK = 0x7f << CLK_I2S3_SRC_DIV_SHIFT,
+
+ /* CRU_CLK_SEL22_CON */
+ CLK_I2S3_FRAC_NUMERATOR_SHIFT = 16,
+ CLK_I2S3_FRAC_NUMERATOR_MASK= 0x << 16,
+ CLK_I2S3_FRAC_DENOMINATOR_SHIFT = 0,
+ CLK_I2S3_FRAC_DENOMINATOR_MASK = 0x,
+
/* CRU_CLK_SEL27_CON */
CLK_CRYPTO_PKA_SEL_SHIFT= 6,
CLK_CRYPTO_PKA_SEL_MASK = 3 << CLK_CRYPTO_PKA_SEL_SHIFT,
@@ -502,5 +527,16 @@ enum {
/* CRU_CLK_SEL82_CON */
CPLL_100M_DIV_SHIFT = 0,
CPLL_100M_DIV_MASK = 0x1f << CPLL_100M_DIV_SHIFT,
+
+ /* GRF_SOC_CON2 */
+ I2S3_MCLKOUT_SEL_SHIFT = 15,
+ I2S3_MCLKOUT_SEL_MASK = 0x1 << I2S3_MCLKOUT_SEL_SHIFT,
+ I2S3_MCLKOUT_SEL_RX = 0,
+ I2S3_MCLKOUT_SEL_TX,
+ I2S3_MCLK_IOE_SEL_SHIFT = 3,
+ I2S3_MCLK_IOE_SEL_MASK = 0x1 << I2S3_MCLK_IOE_SEL_SHIFT,
+ I2S3_MCLK_IOE_SEL_CLKIN = 0,
+ I2S3_MCLK_IOE_SEL_CLKOUT,
+
};
#endif
diff --git a/drivers/clk/rockchip/clk_rk3568.c
b/drivers/clk/rockchip/clk_rk3568.c
index 599b7b130eb9..469014439be4 100644
--- a/drivers/clk/rockchip/clk_rk3568.c
+++ b/drivers/clk/rockchip/clk_rk3568.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2326,6 +2327,170 @@ static ulong rk3568_uart_set_rate(struct
rk3568_clk_priv *priv,
return rk3568_uart_get_rate(priv, clk_id);
}
+#ifndef CONFIG_SPL_BUILD
+static ulong rk3568_i2s3_get_rate(struct rk3568_clk_priv *priv, ulong clk_id)
+{
+ struct rk3568_cru *cru = priv->cru;
+ struct rk3568_grf *grf = priv->grf;
+ u32 con, div, src, p_rate;
+ u32 reg, fracdiv, p_src;
+ unsigned long m, n;
+
+ switch (clk_id) {
+ case I2S3_MCLKOUT_TX:
+ con = readl(>clksel_con[21]);
+ src = (con & I2S3_MCLKOUT_TX_SEL_MASK) >>
+ I2S3_MCLKOUT_TX_SEL_SHIFT;
+ if (src == I2S3_MCLKOUT_TX_SEL_12M)
+ p_rate = 1200;
+ else
+ p_rate = rk3568_i2s3_get_rate(priv, MCLK_I2S3_2CH_TX);
+ return p_rate;
+ case I2S3_MCLKOUT_RX:
+ con = readl(>clksel_con[83]);
+ src = (con & I2S3_MCLKOUT_TX_SEL_MASK) >>
+ I2S3_MCLKOUT_TX_SEL_SHIFT;
+ if (src == I2S3_MCLKOUT_TX_SEL_12M)
+ p_rate = 1200;
+ else
+ p_rate = rk3568_i2s3_get_rate(priv, MCLK_I2S3_2CH_RX);
+ return p_rate;
+ case I2S3_MCLKOUT:
+ con = readl(>soc_con2);
+ src = (con & I2S3_MCLKOUT_SEL_MASK)
+ >> I2S3_MCLKOUT_SEL_SHIFT;
+ if (src == I2S3_MCLKOUT_SEL_RX)
+ p_rate = rk3568_i2s3_get_rate(priv, I2S3_MCLKOUT_RX);
+ else
+ p_rate = rk3568_i2s3_get_rate(priv, I2S3_MCLKOUT_TX);
+ return p_rate;
+ case MCLK_I2S3_2CH_RX:
+ reg = 83;
+ break;
+ case MCLK_I2S3_2CH_TX:
+ reg = 21;
+ break;
+ default:
+ return -ENOENT;
+ }
+
+ con = readl(>clksel_con[reg]);
+ src = (con & CLK_I2S3_SEL_MASK) >> CLK_I2S3_SEL_SHIFT;
+ div = (con & CLK_I2S3_SRC_DIV_MASK) >> CLK_I2S3_SRC_DIV_SHIFT;
+ p_src = (con & CLK_I2S3_SRC_SEL_MASK) >> CLK_I2S3_SRC_SEL_SHIFT;
+ if (p_src == CLK_I2S3_SRC_SEL_GPLL)
+ p_rate = priv->gpll_hz;
+ else if (p_src ==
[PATCH v1 4/7] clk: rk3588: Add 742.5M parameter for PLL
From: Guochun Huang
Change-Id: I5a842a3103df9a566789e7635fb484e4bb0bf427
Signed-off-by: Guochun Huang
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk_rk3588.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/rockchip/clk_rk3588.c
b/drivers/clk/rockchip/clk_rk3588.c
index 119b1337bdf2..c86176264147 100644
--- a/drivers/clk/rockchip/clk_rk3588.c
+++ b/drivers/clk/rockchip/clk_rk3588.c
@@ -36,6 +36,7 @@ static struct rockchip_pll_rate_table rk3588_pll_rates[] = {
RK3588_PLL_RATE(81600, 2, 272, 2, 0),
RK3588_PLL_RATE(786432000, 2, 262, 2, 9437),
RK3588_PLL_RATE(78600, 1, 131, 2, 0),
+ RK3588_PLL_RATE(74250, 4, 495, 2, 0),
RK3588_PLL_RATE(722534400, 8, 963, 2, 24850),
RK3588_PLL_RATE(6, 2, 200, 2, 0),
RK3588_PLL_RATE(59400, 2, 198, 2, 0),
--
2.17.1
[PATCH v1 3/7] clk: rockchip: rk3568: support dclk_vop select more parent clks
Change-Id: Ib823620ff7940f8d62e78010817ca9b5f06995dd
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk_rk3568.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk_rk3568.c
b/drivers/clk/rockchip/clk_rk3568.c
index 469014439be4..7b9035acdb0f 100644
--- a/drivers/clk/rockchip/clk_rk3568.c
+++ b/drivers/clk/rockchip/clk_rk3568.c
@@ -1839,7 +1839,7 @@ static ulong rk3568_dclk_vop_set_clk(struct
rk3568_clk_priv *priv,
rockchip_pll_set_rate(_pll_clks[VPLL],
priv->cru, VPLL, div * rate);
} else {
- for (i = 0; i <= DCLK_VOP_SEL_CPLL; i++) {
+ for (i = sel; i <= DCLK_VOP_SEL_CPLL; i++) {
switch (i) {
case DCLK_VOP_SEL_GPLL:
pll_rate = priv->gpll_hz;
@@ -2964,9 +2964,15 @@ static int rk3568_dclk_vop_set_parent(struct clk *clk,
struct clk *parent)
if (parent->id == PLL_VPLL) {
rk_clrsetreg(>clksel_con[con_id], DCLK0_VOP_SEL_MASK,
DCLK_VOP_SEL_VPLL << DCLK0_VOP_SEL_SHIFT);
- } else {
+ } else if (parent->id == PLL_HPLL) {
rk_clrsetreg(>clksel_con[con_id], DCLK0_VOP_SEL_MASK,
DCLK_VOP_SEL_HPLL << DCLK0_VOP_SEL_SHIFT);
+ } else if (parent->id == PLL_CPLL) {
+ rk_clrsetreg(>clksel_con[con_id], DCLK0_VOP_SEL_MASK,
+DCLK_VOP_SEL_CPLL << DCLK0_VOP_SEL_SHIFT);
+ } else {
+ rk_clrsetreg(>clksel_con[con_id], DCLK0_VOP_SEL_MASK,
+DCLK_VOP_SEL_GPLL << DCLK0_VOP_SEL_SHIFT);
}
return 0;
--
2.17.1
[PATCH v1 5/7] clk: rockchip: rk3588: support aclk_top_root set 750M
Change-Id: I78f00d37a645f37e28587d1c31f3179d5fa891e7
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk_rk3588.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk_rk3588.c
b/drivers/clk/rockchip/clk_rk3588.c
index c86176264147..7ba037ad72ba 100644
--- a/drivers/clk/rockchip/clk_rk3588.c
+++ b/drivers/clk/rockchip/clk_rk3588.c
@@ -306,12 +306,18 @@ static ulong rk3588_top_set_clk(struct rk3588_clk_priv
*priv,
switch (clk_id) {
case ACLK_TOP_ROOT:
- src_clk_div = DIV_ROUND_UP(priv->gpll_hz, rate);
+ if (!(priv->cpll_hz % rate)) {
+ src_clk = ACLK_TOP_ROOT_SRC_SEL_CPLL;
+ src_clk_div = DIV_ROUND_UP(priv->cpll_hz, rate);
+ } else {
+ src_clk = ACLK_TOP_ROOT_SRC_SEL_GPLL;
+ src_clk_div = DIV_ROUND_UP(priv->gpll_hz, rate);
+ }
assert(src_clk_div - 1 <= 31);
rk_clrsetreg(>clksel_con[8],
ACLK_TOP_ROOT_DIV_MASK |
ACLK_TOP_ROOT_SRC_SEL_MASK,
-(ACLK_TOP_ROOT_SRC_SEL_GPLL <<
+(src_clk <<
ACLK_TOP_ROOT_SRC_SEL_SHIFT) |
(src_clk_div - 1) << ACLK_TOP_ROOT_DIV_SHIFT);
break;
--
2.17.1
[PATCH v1 0/7] clk : rockchip: update rk3568 and rk3588 clk driver
Elaine Zhang (5): rockchip: dts: rk3568: Resync from kernel-4.19 clk: rockchip: rk3568: add i2s3 clk clk: rockchip: rk3568: support dclk_vop select more parent clks clk: rockchip: rk3588: support aclk_top_root set 750M clk: rockchip: rk3588: fix up the frac pll calculation Guochun Huang (1): clk: rk3588: Add 742.5M parameter for PLL Wyon Bi (1): clk: rockchip: rk3588: Avoid re-setting the pll rate of dclk_vop's parent .../include/asm/arch-rockchip/cru_rk3568.h| 36 +++ drivers/clk/rockchip/clk_pll.c| 102 ++-- drivers/clk/rockchip/clk_rk3568.c | 228 +- drivers/clk/rockchip/clk_rk3588.c | 35 ++- include/dt-bindings/clock/rk3568-cru.h| 7 + 5 files changed, 373 insertions(+), 35 deletions(-) -- 2.17.1
[PATCH v1 1/7] rockchip: dts: rk3568: Resync from kernel-4.19
Resync from kernel-4.19: (a6cf6aca12c0 drivers: rkflash: Ajudst the dll strategy) Change-Id: I7b7134946b76dbd8963cfaafdc5b56750622855e Signed-off-by: Elaine Zhang --- include/dt-bindings/clock/rk3568-cru.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/dt-bindings/clock/rk3568-cru.h b/include/dt-bindings/clock/rk3568-cru.h index c1942422a438..251445cf7632 100644 --- a/include/dt-bindings/clock/rk3568-cru.h +++ b/include/dt-bindings/clock/rk3568-cru.h @@ -478,6 +478,13 @@ #define CPLL_50M 415 #define CPLL_25M 416 #define CPLL_100M 417 +#define SCLK_DDRCLK418 +#define I2S1_MCLKOUT 419 +#define I2S3_MCLKOUT 420 +#define I2S1_MCLK_RX_IOE 421 +#define I2S1_MCLK_TX_IOE 422 +#define I2S2_MCLK_IOE 423 +#define I2S3_MCLK_IOE 424 #define PCLK_CORE_PVTM 450 -- 2.17.1
