June 2023 - U-Boot

Pull request: u-boot-rockchip-20230629
by Kever Yang 30 Jun '23

30 Jun '23

Hi Tom, Please pull the fixex for rockchip platform: - rockchip inno phy fix; - pinctrl driver in SPL arort in specific case; - fix IO port voltage for rock5b-rk3588 board; CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/16732 Thanks, - Kever The following changes since commit 580eb31199be8a822e62f20965854a242f895d03: Merge branch 'riscv-fixes' of https://source.denx.de/u-boot/custodians/u-boot-riscv (2023-06-27 09:39:58 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-rockchip.git tags/u-boot-rockchip-20230629 for you to fetch changes up to d77d5301d7dc333db0425ee82499fe362abd259d: board: rockchip: rock5b-rk3588: fix description (2023-06-29 18:43:42 +0800) ---------------------------------------------------------------- Eugen Hristev (2): phy: rockchip: inno-usb2: fix phy reg=0 case board: rockchip: rock5b-rk3588: fix description Jonas Karlman (1): pinctrl: rockchip: Fix Data Abort exception in SPL Ondrej Jirman (1): pinephone-pro: Fix I/O port voltage (GPIO3D4A is 1.8V) arch/arm/mach-rockchip/rk3588/Kconfig | 10 ++++---- .../pinephone-pro-rk3399/pinephone-pro-rk3399.c | 6 +++-- drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 2 +- drivers/pinctrl/rockchip/pinctrl-rockchip-core.c | 28 +++++----------------- 4 files changed, 16 insertions(+), 30 deletions(-)

2 1

[PATCH v2 0/4] Introduce the sysinfo command
by Detlev Casanova 29 Jun '23

29 Jun '23

The command can be used to show various information that can be used to identify the running system. Currently supported subcommands are: * model: A string representing the model * id: The id of the board * revision: The revision of this board. I'm also not sure if a test should be added and where to start to test this kind of command. Changes since v1: - Removed shell function to select linux device tree. This will be distributions job. - Break revision in rev_major and rev_minor in the sysinfo driver. Detlev Casanova (4): sysinfo: Add IDs for board id and revision cmd: Add a sysinfo command sysinfo: rcar3: Use int instead of char for revision sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION_* cmd/Kconfig | 6 ++ cmd/Makefile | 1 + cmd/sysinfo.c | 134 ++++++++++++++++++++++++++++++++++++++ drivers/sysinfo/rcar3.c | 141 ++++++++++++++++++++++++++++------------ include/sysinfo.h | 5 ++ 5 files changed, 245 insertions(+), 42 deletions(-) create mode 100644 cmd/sysinfo.c -- 2.39.3

2 6

Does CONFIG_I2C_EEPROM depend on CONFIG_MISC_INIT_R?
by sunying＠nj.iscas.ac.cn 29 Jun '23

29 Jun '23

Hi, We noticed that in the code implementation board/atmel/sama7g5ek/sama7g5ek.c, "#if (IS_ENABLED(CONFIG_I2C_EEPROM))" is located in the condition "#if (IS_ENABLED(CONFIG_MISC_INIT_R))". Consider that the CONFIG_I2C_EEPROM option requires access to EEPROM memory after normal initial operations are complete. Do you think it is necessary to add a dependency on MISC_INIT_R in the I2C_EEPROM option definition of drivers/misc/Kconfig file? Best regards, Yanjie Ren Ying Sun

2 1

Re: [PATCH] bootstd: USB devtype detection for script boot
by Simon Glass 29 Jun '23

29 Jun '23

Hi John, On Thu, 29 Jun 2023 at 01:03, John Clark <inindev(a)gmail.com> wrote: > > > I only just thought of this, but I think it is better to check > blk->uclass_id == UCLASS_USB instead, since it avoids a string comparison. > > I am not finding anything as direct as your pseudo code above suggests. > The closest I can find is a compare like this: > > UCLASS_MASS_STORAGE == device_get_uclass_id(dev_get_parent(bflow->blk)) > > Which has the overhead of calling two new functions that otherwise would > not be called and could match other mass storage devices other than USB > (am I right to assume this?). > > Can you shed additional insight into "blk->uclass_id"? Oh sorry, I mean the blk_desc structure attached to the block device. struct blk_desc *desc = dev_get_uclass_plat(blk); Then desc->uclass_id is what you want. It is the uclass of the media device (typically the parent of the block device). > > blk is a udevice without a uclass_id member: > > ./dm/device.h > > struct udevice { > const struct driver *driver; > const char *name; > void *plat_; > void *parent_plat_; > void *uclass_plat_; > ulong driver_data; > struct udevice *parent; > void *priv_; > struct uclass *uclass; > void *uclass_priv_; > void *parent_priv_; > struct list_head uclass_node; > struct list_head child_head; > struct list_head sibling_node; > #if !CONFIG_IS_ENABLED(OF_PLATDATA_RT) > u32 flags_; > #endif > int seq_; > #if CONFIG_IS_ENABLED(OF_REAL) > ofnode node_; > #endif > #if CONFIG_IS_ENABLED(DEVRES) > struct list_head devres_head; > #endif > #if CONFIG_IS_ENABLED(DM_DMA) > ulong dma_offset; > #endif > #if CONFIG_IS_ENABLED(IOMMU) > struct udevice *iommu; > #endif > }; You can use device_get_uclass_id(blk) to get the uclass ID of the block device, but of course it will just be UCLASS_BLK. > > > I am not a prolific open source contributor, so I am not sure if a > side-bar conversation like this is one we should be having with the > whole list? Something this trivial seems like it would just be noise to > include hundreds of people on. > > I appreciate your advice here, and thanks for your time. You can just copy the list on all emails. I've done it here. Regards, Simon > > > John Clark > > > On 6/28/23 3:42 AM, Simon Glass wrote: > > Hi John, > > > > On Tue, 27 Jun 2023 at 15:39, John Clark <inindev(a)gmail.com> wrote: > >> Change the device type from "usb_mass_storage" to "usb" when > >> booting a script. > >> > >> Before this change: > >> => printenv devtype > >> devtype=usb_mass_storage > >> > >> After this change: > >> => printenv devtype > >> devtype=usb > >> > >> Signed-off-by: John Clark <inindev(a)gmail.com> > >> --- > >> > >> boot/bootmeth_script.c | 8 ++++++-- > >> 1 file changed, 6 insertions(+), 2 deletions(-) > >> > >> diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c > >> index 225eb18ee6..9fdadb3005 100644 > >> --- a/boot/bootmeth_script.c > >> +++ b/boot/bootmeth_script.c > >> @@ -187,10 +187,14 @@ static int script_set_bootflow(struct udevice *dev, struct bootflow *bflow, > >> static int script_boot(struct udevice *dev, struct bootflow *bflow) > >> { > >> struct blk_desc *desc = dev_get_uclass_plat(bflow->blk); > >> + const char *devtype = blk_get_devtype(bflow->blk); > >> ulong addr; > >> int ret; > >> > >> - ret = env_set("devtype", blk_get_devtype(bflow->blk)); > >> + if (!strcmp("usb_mass_storage", devtype)) > > I only just thought of this, but I think it is better to check > > blk->uclass_id == UCLASS_USB instead, since it avoids a string > > comparison. > > > >> + ret = env_set("devtype", "usb"); > >> + else > >> + ret = env_set("devtype", devtype); > >> if (!ret) > >> ret = env_set_hex("devnum", desc->devnum); > >> if (!ret) > >> @@ -198,7 +202,7 @@ static int script_boot(struct udevice *dev, struct bootflow *bflow) > >> if (!ret) > >> ret = env_set("prefix", bflow->subdir); > >> if (!ret && IS_ENABLED(CONFIG_ARCH_SUNXI) && > >> - !strcmp("mmc", blk_get_devtype(bflow->blk))) > >> + !strcmp("mmc", devtype)) > >> ret = env_set_hex("mmc_bootdev", desc->devnum); > >> if (ret) > >> return log_msg_ret("env", ret); > >> -- > >> 2.39.2 > >> > > Regards, > > Simon

1 0

[PATCH v3] arm: dts: am335x-evm-u-boot: Remove usb0 mode configuration
by Julien Panis 29 Jun '23

29 Jun '23

This USB port configuration is moved to 'am335x-evm.dts'. Signed-off-by: Julien Panis <jpanis(a)baylibre.com> --- Initially, this series was submitted to fix usb0 dr_mode for am335x-icev2 and am335x-evmsk. It must be set to 'peripheral' in order to avoid 'no USB device found' error, in usb_ether_init() function. It was finally decided to move usb0 mode configuration in kernel device trees. That's why a series was submitted for linux: https://lore.kernel.org/all/20230629-usb0-as-peripheral-v1-0-167f78a11746@b… As a consequence, usb0 dr_mode configuration must now be removed from 'am335x-evm-u-boot.dtsi', since this fragment needs to go in linux too. --- Changes in v3: - Remove usb0 dr_mode configuration from 'am335x-evm-u-boot.dtsi'. - Link to v2: https://lore.kernel.org/r/20230621-fix_usb_ether_init-v2-0-ff121f0e8d7a@bay… Changes in v2: - Drop the modification made in arch/arm/mach-omap2/am33xx/board.c - Configure usb0 dr_mode as peripheral in 'am335x-icev2-u-boot.dtsi' and 'am335x-evmsk-u-boot.dtsi' device trees. - Link to v1: https://lore.kernel.org/r/20230621-fix_usb_ether_init-v1-1-2156923994a9@bay… --- arch/arm/dts/am335x-evm-u-boot.dtsi | 4 ---- 1 file changed, 4 deletions(-) diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi b/arch/arm/dts/am335x-evm-u-boot.dtsi index 82a483ae3e28..42eeca8c0499 100644 --- a/arch/arm/dts/am335x-evm-u-boot.dtsi +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi @@ -23,10 +23,6 @@ status = "disabled"; }; -&usb0 { - dr_mode = "peripheral"; -}; - &i2c0 { bootph-all; }; --- base-commit: 19b77d3d23966a0d6dbb3c86187765f11100fb6f change-id: 20230621-fix_usb_ether_init-4bf4f1135113 Best regards, -- Julien Panis <jpanis(a)baylibre.com>

1 0

[PATCH v1] mtd: nand: raw: rockchip_nfc: copy hwecc PA data to oob_poi buffer
by Johan Jonker 29 Jun '23

29 Jun '23

Rockchip boot blocks are written per 4 x 512 byte sectors per page. Each page must have a page address (PA) pointer in OOB to the next page. Pages are written in a pattern depending on the NAND chip ID. This logic used to build a page pattern table is not fully disclosed and is not easy to fit in the MTD framework. The formula in rk_nfc_write_page_hwecc() function is not correct. Make hwecc and raw behavior identical. Generate boot block page address and pattern for hwecc in user space and copy PA data to/from the already reserved last 4 bytes before EEC in the chip->oob_poi data layout. Signed-off-by: Johan Jonker <jbx6244(a)gmail.com> --- drivers/mtd/nand/raw/rockchip_nfc.c | 34 ++++++++++++++++++----------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/drivers/mtd/nand/raw/rockchip_nfc.c b/drivers/mtd/nand/raw/rockchip_nfc.c index 5fcf6a6b..274489ec 100644 --- a/drivers/mtd/nand/raw/rockchip_nfc.c +++ b/drivers/mtd/nand/raw/rockchip_nfc.c @@ -525,7 +525,7 @@ static int rk_nfc_write_page_hwecc(struct mtd_info *mtd, int pages_per_blk = mtd->erasesize / mtd->writesize; int ret = 0, i, boot_rom_mode = 0; dma_addr_t dma_data, dma_oob; - u32 reg; + u32 tmp; u8 *oob; nand_prog_page_begin_op(chip, page, 0, NULL, 0); @@ -552,6 +552,13 @@ static int rk_nfc_write_page_hwecc(struct mtd_info *mtd, * * 0xFF 0xFF 0xFF 0xFF | BBM OOB1 OOB2 OOB3 | ... * + * The code here just swaps the first 4 bytes with the last + * 4 bytes without losing any data. + * + * The chip->oob_poi data layout: + * + * BBM OOB1 OOB2 OOB3 |......| PA0 PA1 PA2 PA3 + * * Configure the ECC algorithm supported by the boot ROM. */ if (page < (pages_per_blk * rknand->boot_blks)) { @@ -561,21 +568,17 @@ static int rk_nfc_write_page_hwecc(struct mtd_info *mtd, } for (i = 0; i < ecc->steps; i++) { - if (!i) { - reg = 0xFFFFFFFF; - } else { + if (!i) + oob = chip->oob_poi + (ecc->steps - 1) * NFC_SYS_DATA_SIZE; + else oob = chip->oob_poi + (i - 1) * NFC_SYS_DATA_SIZE; - reg = oob[0] | oob[1] << 8 | oob[2] << 16 | - oob[3] << 24; - } - if (!i && boot_rom_mode) - reg = (page & (pages_per_blk - 1)) * 4; + tmp = oob[0] | oob[1] << 8 | oob[2] << 16 | oob[3] << 24; if (nfc->cfg->type == NFC_V9) - nfc->oob_buf[i] = reg; + nfc->oob_buf[i] = tmp; else - nfc->oob_buf[i * (oob_step / 4)] = reg; + nfc->oob_buf[i * (oob_step / 4)] = tmp; } dma_data = dma_map_single((void *)nfc->page_buf, @@ -720,12 +723,17 @@ static int rk_nfc_read_page_hwecc(struct mtd_info *mtd, goto timeout_err; } - for (i = 1; i < ecc->steps; i++) { - oob = chip->oob_poi + (i - 1) * NFC_SYS_DATA_SIZE; + for (i = 0; i < ecc->steps; i++) { + if (!i) + oob = chip->oob_poi + (ecc->steps - 1) * NFC_SYS_DATA_SIZE; + else + oob = chip->oob_poi + (i - 1) * NFC_SYS_DATA_SIZE; + if (nfc->cfg->type == NFC_V9) tmp = nfc->oob_buf[i]; else tmp = nfc->oob_buf[i * (oob_step / 4)]; + *oob++ = (u8)tmp; *oob++ = (u8)(tmp >> 8); *oob++ = (u8)(tmp >> 16); -- 2.30.2

2 1

[PATCH] board: rockchip: rock5b-rk3588: fix description
by Eugen Hristev 29 Jun '23

29 Jun '23

Update description with correct specifications Fixes: 3bf8e4080763 ("board: rockchip: add Radxa ROCK5B Rk3588 board") Signed-off-by: Eugen Hristev <eugen.hristev(a)collabora.com> --- arch/arm/mach-rockchip/rk3588/Kconfig | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig b/arch/arm/mach-rockchip/rk3588/Kconfig index 3596b82f1f1c..b7d5f13bebbf 100644 --- a/arch/arm/mach-rockchip/rk3588/Kconfig +++ b/arch/arm/mach-rockchip/rk3588/Kconfig @@ -34,15 +34,15 @@ config TARGET_ROCK5B_RK3588 4x ARM Cortex-A76, 4x ARM Cortex-A55 4/8/16GB memory LPDDR4x Mali G610MC4 GPU - MIPI CSI 2 multiple lanes connector + 2x MIPI CSI 2 multiple lanes connector eMMC module connector uSD slot (up to 128GB) - 2x USB 2.0, 2x USB 3.0 - 2x HDMI output, 1x HDMI input - Ethernet port + 2x USB 2.0 Type-A, 2x USB 3.0 Type-A, 1x USB 3.0 Type-C + 2x HDMI 2.1 output, 1x micro HDMI input + 2.5 Gbps Ethernet port 40-pin IO header including UART, SPI, I2C and 5V DC power in USB PD over USB Type-C - Size: 85mm x 54mm + Size: 100mm x 72mm (Pico-ITX form factor) config ROCKCHIP_BOOT_MODE_REG default 0xfd588080 -- 2.34.1

2 1

[PATCH] pinctrl: rockchip: Fix Data Abort exception in SPL
by Jonas Karlman 29 Jun '23

29 Jun '23

Using CONFIG_ARMV8_SPL_EXCEPTION_VECTORS=y and CONFIG_OF_LIVE=y triggers a Data Abort exception from unaligned memory access when the pinctrl driver iterate node properties, e.g. for UART2 on RK3568. setting mux of GPIO0-24 to 1 setting mux of GPIO0-24 to 1 "Synchronous Abort" handler, esr 0x96000021 elr: 000000000000e554 lr : 000000000000e54c x 0: 0000000000000a5c x 1: 0000000000000a5c x 2: 0000000000000007 x 3: 0000000000000065 x 4: 0000000000000007 x 5: 0000000000022d4e x 6: 0000000000000a7c x 7: 00000000000227a4 x 8: 0000000000021cf0 x 9: 0000000000000a7c x10: 0000000000021cf0 x11: 0000000000021cf0 x12: 00000000003fda1c x13: 0000000000000007 x14: 00000000003fd9ec x15: 000000000001c0ff x16: 0000000007000000 x17: 00000000fdccd028 x18: 00000000003fde20 x19: 0000000000000018 x20: 0000000000020670 x21: 0000000000000000 x22: 00000000003fdb00 x23: 00000000003fef90 x24: 0000000000020688 x25: 0000000000000000 x26: 0000000000000001 x27: 00000000003ffc50 x28: 0000000000000000 x29: 00000000003fda60 Code: b94083e1 97ffd508 93407c01 37f81260 (f9401038) Resetting CPU ... Fix this by replacing the loop to access node properties with use of ofnode_for_each_prop instead of the current ifdef. Also continue to next prop instead of aborting at first sign of an unknown property. This fixes the Data Abort exception and also pinconf of e.g. pull and drive in SPL, e.g. for UART2 on RK3568. setting mux of GPIO0-24 to 1 setting mux of GPIO0-24 to 1 setting pull of GPIO0-24 to 5 setting mux of GPIO0-25 to 1 setting mux of GPIO0-25 to 1 setting pull of GPIO0-25 to 5 Fixes: e7ae4cf27a6d ("pinctrl: rockchip: Add common rockchip pinctrl driver") Signed-off-by: Jonas Karlman <jonas(a)kwiboo.se> --- .../pinctrl/rockchip/pinctrl-rockchip-core.c | 28 ++++--------------- 1 file changed, 6 insertions(+), 22 deletions(-) diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c index d9d61fdb726a..8ef089994f46 100644 --- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c +++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c @@ -12,7 +12,6 @@ #include <fdtdec.h> #include <linux/bitops.h> #include <linux/libfdt.h> -#include <asm/global_data.h> #include "pinctrl-rockchip.h" @@ -433,13 +432,7 @@ static int rockchip_pinctrl_set_state(struct udevice *dev, int prop_len, param; const u32 *data; ofnode node; -#ifdef CONFIG_OF_LIVE - const struct device_node *np; - struct property *pp; -#else - int property_offset, pcfg_node; - const void *blob = gd->fdt_blob; -#endif + struct ofprop prop; data = dev_read_prop(config, "rockchip,pins", &count); if (count < 0) { debug("%s: bad array size %d\n", __func__, count); @@ -473,24 +466,15 @@ static int rockchip_pinctrl_set_state(struct udevice *dev, node = ofnode_get_by_phandle(conf); if (!ofnode_valid(node)) return -ENODEV; -#ifdef CONFIG_OF_LIVE - np = ofnode_to_np(node); - for (pp = np->properties; pp; pp = pp->next) { - prop_name = pp->name; - prop_len = pp->length; - value = pp->value; -#else - pcfg_node = ofnode_to_offset(node); - fdt_for_each_property_offset(property_offset, blob, pcfg_node) { - value = fdt_getprop_by_offset(blob, property_offset, - &prop_name, &prop_len); + ofnode_for_each_prop(prop, node) { + value = ofprop_get_property(&prop, &prop_name, &prop_len); if (!value) - return -ENOENT; -#endif + continue; + param = rockchip_pinconf_prop_name_to_param(prop_name, &default_val); if (param < 0) - break; + continue; if (prop_len >= sizeof(fdt32_t)) arg = fdt32_to_cpu(*(fdt32_t *)value); -- 2.40.1

2 1

[PATCH] phy: rockchip: inno-usb2: fix phy reg=0 case
by Eugen Hristev 29 Jun '23

29 Jun '23

The support for #address-cells=2 has a loophole: if the reg is actually 0, but the #address-cells is actually 1, like in such case below: syscon { #address-cells = <1>; phy { reg = <0 0x10>; }; }; then the second u32 of the 'reg' is the size, not the address. The code should check for the parent's #address-cells value, and not assume that if the first u32 is 0, then the #address-cells is 2, and the reg property is something like reg = <0 0xff00 0x10>; Fixed this by looking for the #address-cells value and retrieving the reg address only if this is ==2. To avoid breaking anything I also kept the check `if reg==0` as some DT's may have a wrong #address-cells as parent and even if this commit is correct, it might break the existing wrong device-trees. Fixes: d538efb9adcf ("phy: rockchip: inno-usb2: Add support #address_cells = 2") Signed-off-by: Eugen Hristev <eugen.hristev(a)collabora.com> --- drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c index 22e2797eea28..e5e02b6765b1 100644 --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c @@ -186,7 +186,7 @@ static int rockchip_usb2phy_probe(struct udevice *dev) } /* support address_cells=2 */ - if (reg == 0) { + if (dev_read_addr_cells(dev) == 2 && reg == 0) { if (ofnode_read_u32_index(dev_ofnode(dev), "reg", 1, &reg)) { dev_err(dev, "%s must have reg[1]\n", ofnode_get_name(dev_ofnode(dev))); -- 2.34.1

2 1

Suggestion: Does the CONFIG_RTC_DS1307 and CONFIG_DM_RTC options conflict?
by sunying＠nj.iscas.ac.cn 29 Jun '23

29 Jun '23

hi, we recently noticed that RTC_DS1307 is dependent on DM_RTC in drivers/rtc/Kconfig, but the code implementation of drivers/rtc/ds1307.c: conflicts between the two. "#ifdef CONFIG_RTC_DS1307" is in the condition "#ifndef CONFIG_DM_RTC" . These two options are used to enable different RTC drivers. If both options are enabled, there is a situation where two RTC drivers exist at the same time, which can lead to conflicts and errors. Therefore, only one of these two options should be enabled, not both. Do you think it is necessary to fix the dependency in drivers/rtc/Kconfig? Best regards, Yanjie Ren Ying Sun

1 0