June 2023 - U-Boot

RE: Running u-boot and linux on qemu arm64 virt machine, linux shell does not respond.. ==> solved!
by Chan Kim 05 Jun '23

05 Jun '23

Hi, all, I found what the problem was and fixed it. In u-boot(v2022.07), I modified arch/arm/Kconfig and made CONFIG_GICV3 selected by CONFIG_ARCH_QEMU. And then in qemu_arm64_defconfig, added CONFIG_BOOTCOMMAND="booti 0x40400000 0x44000000 0x40000000" (this automatic boot, with my qemu command) I also had to add in include/configs/qemu-arm.h, #define GICD_BASE 0x8000000 #define GICR_BASE 0x80a0000 I think this is the only things I added to the u-boot code. (I removed GICR power-up code in my previous email, that wasn't necessary) Hope this helps someone later. Thank you! Chan Kim From: Chan Kim <ckim(a)etri.re.kr> Sent: Friday, June 2, 2023 6:28 PM To: U-Boot Mailing List <u-boot(a)lists.denx.de>; 'qemu-discuss(a)nongnu.org' <qemu-discuss(a)nongnu.org>; kernelnewbies(a)kernelnewbies.org Subject: Running u-boot and linux on qemu arm64 virt machine, linux shell does not respond.. Hello all, I'm trying to run u-boot and linux on qemu arm64 virt machine preferably without changing any source code. (u-boot v2022.07, linux 5.15.68, qemu 6.2.0, busybox 1.32.1) I have built u-boot using qemu_arm64_defconfig and I got u-boot(elf) and u-boot.bin. I built linux using defconfig but later I removed many CONFIG_* to reduce compile time and got Image(binary). Also, I built busybox and made ramdisk. Now this is the qemu command I used. (I referenced u-boot's include/configs/qemu-arm.h to determine the load addresses, set CONFIG_BOOTCOMMAND=" booti 0x40400000 0x44000000 0x40000000") ../temp/qemu-6.2.0/build/aarch64-softmmu/qemu-system-aarch64 -machine virt,gic-version=max,secure=on,virtualization=true -cpu max -m 4G -nographic -bios u-boot/u-boot.bin -device loader,file=../temp/linux-5.15.68/arch/arm64/boot/Image,addr=0x40400000 -device loader,file=initrd.img,addr=0x44000000 u-boot runs and automatically boots linunx and it boots OK to the shell prompt. But at the linux shell prompt, it doesn't respond to my keyboard input. It looks like the symptom I saw last year when system counter is not working(for real board only). (I added system counter device in our qemu virtual machine just to not cause panic during the system counter access with the same driver. The qemu machine for our board runs ok using u-boot-spl and linux after booting including shell program and simple driver test. I'm trying to use u-boot proper now). Also last year I had to power-on the GICR(for virtual machine and real board). So I tried adding the code to power up GICR but it is the same. (this part is missing in u-boot, but I saw it is in the arm-tf S/W). For your reference this is the change in u-boot's arch/arm/lib/gic_64.S. /* x9: ReDistributor Base Address of Current CPU */ 2: mov w10, #~0x2 ldr w11, [x9, GICR_WAKER] and w11, w11, w10 /* Clear ProcessorSleep */ str w11, [x9, GICR_WAKER] dsb st isb ==> /* x9: ReDistributor Base Address of Current CPU */ 2: // gicr power on, ckim mov w10, 2 str w10, [x9, GICR_PWRR] 5: ldr w10, [x9, GICR_PWRR] tbnz w10, #1, 5b /* Wait Children be Alive */ mov w10, #~0x2 ldr w11, [x9, GICR_WAKER] and w11, w11, w10 /* Clear ProcessorSleep */ str w11, [x9, GICR_WAKER] dsb st isb Can anyone suggest what I can try to solve this problem? (I mean, the problem of linux shell not responding in qemu virtual machine) I would appreciate it for any comment or help. Thank you. Chan Kim

1 0

[PATCH v5 0/2] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
by Xavier Drudis Ferran 04 Jun '23

04 Jun '23

arch/arm/dts/rk3399.dtsi has a node usb_host0_ehci: usb@fe380000 { compatible = "generic-ehci"; with clocks: clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>, <&u2phy0>; The first 2 refer to nodes with class UCLASS_CLK, but &u2phy0 has class UCLASS_PHY. u2phy0: usb2phy@e450 { compatible = "rockchip,rk3399-usb2phy"; Since clk_get_bulk() only looks for devices with UCLASS_CLK, it fails with -ENODEV and then ehci_usb_probe() aborts. The consequence is peripherals connected to a USB 2 port (e.g. in a Rock Pi 4 one of the two ports nearer the edge) not being detected. They're detected if CONFIG_USB_OHCI_GENERIC is selected in Kconfig, because ohci_usb_probe() does not abort when one clk_get_by_index() fails, but then they work in USB 1 mode,. rk3399.dtsi comes from linux and the u2phy0 was added[1] to the clock list in: commit b5d1c57299734f5b54035ef2e61706b83041f20c Author: William wu <wulf(a)rock-chips.com> Date: Wed Dec 21 18:41:05 2016 +0800 arm64: dts: rockchip: add u2phy clock for ehci and ohci of rk3399 We found that the suspend process was blocked when it run into ehci/ohci module due to clk-480m of usb2-phy was disabled. [...] Suspend concerns don't apply to U-Boot, and the problem with U-Boot failing to probe EHCI doesn't apply to linux, because in linux rockchip_usb2phy_clk480m_register makes u2phy0 a proper clock provider when called by rockchip_usb2phy_probe(). So I can think of a few alternative solutions: 1- Change ehci_usb_probe() to make it more similar to ohci_usb_probe(), and survive failure to get one clock. Looks a little harder, and I don't know whether it could break something if it ignored a clock that was important for something else than suspend. (tried in v2) 2- Change rk3399.dtsi effecttively reverting the linux commit b5d1c57299734f5b54035ef2e61706b83041f20c. This dealigns the .dtsi from linux and seems fragile at the next synchronisation. 3- Change the clock list in rk3399-u-boot.dtsi or somewhere else. This survives .dts* sync but may survive "too much" and miss some change from linux that we might want. (tried in v1) 4- Enable CONFIG_USB_OHCI_GENERIC and use the ports in USB 1 mode. This would need to be made for all boards using rk3399. In a simple test reading one file from USB storage it gave 769.5 KiB/s instead of 20.5 MiB/s with solution 2. 5- Trying to replicate linux and have usb2phy somehow provide a clk, or have a separate clock device for usb2phy in addition to the phy device. (tried in v3 and this v5, v4 did it wrong) This series is a third attempt to implement option 5 as Marek Vasut requested in December 5th. Options 1 and 3 didn't get through[2,3]. The first patch in the series (identical to v3) just registers usb2phy as a clock driver, without any specific operations, so that ehci-generic.c finds it and is happy. It worked in my tests on a Rock Pi 4 B+ (rk3399). Since Marek Vasut objected to an operationless driver[4], the second patch adds enable and disable operations adapted from linux prepare and unprepare operations (and round_rate(), which doesn't seem very useful anyway since it's a fixed clock). Since there're no users of this clock in u-boot, I can't see any difference in my tests with only the first patch or both, so I can't be sure it really works if it's ever needed, but it's hopefully more complete. Links: [1] https://lkml.kernel.org/lkml/1731551.Q6cHK6n5ZM@phil/T/ [2] https://patchwork.ozlabs.org/project/uboot/patch/20220701185959.GC1700@begu… [3] https://patchwork.ozlabs.org/project/uboot/patch/Y44+ayJfUlI08ptM@localhost… [4] https://patchwork.ozlabs.org/project/uboot/patch/Y5IWpjYLB4aXMy9o@localhost… Cc: Simon Glass <sjg(a)chromium.org> Cc: Philipp Tomsich <philipp.tomsich(a)vrull.eu> Cc: Kever Yang <kever.yang(a)rock-chips.com> Cc: Lukasz Majewski <lukma(a)denx.de> Cc: Sean Anderson <seanga2(a)gmail.com> Cc: Marek Vasut <marex(a)denx.de> Cc: Christoph Fritz <chf.fritz(a)googlemail.com> Signed-off-by: Xavier Drudis Ferran <xdrudis(a)tinet.cat> --- Changes: v5: fixes a bug that Christoph Fritz discovered, consisting in the wrong eror code returned when enabling or disabling the clock because property_enable() returns an error code in linux but the modified register value in U-Boot. This caused the clk disable to abort before freeing the clock and it apparently left things bad enough to cause a hang or a reset. v4: move v3 to one patch in the series and add a second patch to add operations to enable disable the usb2phy 480Mhz clock. Also, honour clock-output-names for what is worth. v3: implement option 5 (bind usb2phy as a clk driver too) instead of option 1 (ehci-generic.c tolerates missing clocks). v2: implement option 1 (ehci-generic.c tolerates missing clocks) instead of option 3 (change dts node to remove the missing clock).

3 10

[PATCH v3 0/5] SPL NVMe support
by Mayuresh Chitale 03 Jun '23

03 Jun '23

This patchset adds support to load images of the SPL's next booting stage from a NVMe device. Changes in v3: - Add generic API to fetch payload from Ext or FAT filesystems - Remove reduntant SPL_PCI_PNP config check Changes in v2: - Rebase on v2023.07-rc1 - Use uclass ID for blk APIs - Add support to load FIT images from ext filesystem Mayuresh Chitale (5): spl: Add Kconfig options for NVME spl: blk: Support loading images from fs nvme: pci: Enable for SPL spl: Support loading a FIT from ext FS common: spl: Add spl NVMe boot support arch/riscv/include/asm/spl.h | 1 + common/spl/Kconfig | 31 +++++++++++++++++++++ common/spl/Makefile | 2 ++ common/spl/spl_blk_fs.c | 54 ++++++++++++++++++++++++++++++++++++ common/spl/spl_ext.c | 33 ++++++++++++++++++++++ common/spl/spl_nvme.c | 34 +++++++++++++++++++++++ drivers/Makefile | 1 + drivers/block/Kconfig | 7 +++++ drivers/nvme/Makefile | 2 +- drivers/pci/Kconfig | 7 +++++ include/spl.h | 3 ++ 11 files changed, 174 insertions(+), 1 deletion(-) create mode 100644 common/spl/spl_blk_fs.c create mode 100644 common/spl/spl_nvme.c -- 2.34.1

4 16

[PATCH v3] cmd: sf/nand: Print and return failure when 0 length is passed
by Ashok Reddy Soma 03 Jun '23

03 Jun '23

For sf commands, when '0' length is passed for erase, update, write or read, there might be undesired results. Ideally '0' length means nothing to do. So print 'ERROR: Invalid size 0' and return cmd failure when length '0' is passed to sf commands. Same thing applies for nand commands also. Example: ZynqMP> sf erase 0 0 ERROR: Invalid size 0 ZynqMP> sf write 10000 0 0 ERROR: Invalid size 0 ZynqMP> sf read 10000 0 0 ERROR: Invalid size 0 ZynqMP> sf update 1000 10000 0 ERROR: Invalid size 0 ZynqMP> Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma(a)amd.com> --- Changes in v3: - Change printf to debug as it is too verbose Changes in v2: - Changed print from 'size is 0' to Invalid size 0 without quites. - Modified description to be imperative - Fixed typo in description from "samething" to "same thing" cmd/legacy-mtd-utils.c | 5 +++++ cmd/sf.c | 5 +++++ 2 files changed, 10 insertions(+) diff --git a/cmd/legacy-mtd-utils.c b/cmd/legacy-mtd-utils.c index ac7139f84d..5903a90fe5 100644 --- a/cmd/legacy-mtd-utils.c +++ b/cmd/legacy-mtd-utils.c @@ -88,6 +88,11 @@ int mtd_arg_off_size(int argc, char *const argv[], int *idx, loff_t *off, return -1; } + if (*size == 0) { + debug("ERROR: Invalid size 0\n"); + return -1; + } + print: printf("device %d ", *idx); if (*size == chipsize) diff --git a/cmd/sf.c b/cmd/sf.c index 11b9c25896..55bef2f769 100644 --- a/cmd/sf.c +++ b/cmd/sf.c @@ -353,6 +353,11 @@ static int do_spi_flash_erase(int argc, char *const argv[]) if (ret != 1) return CMD_RET_USAGE; + if (size == 0) { + debug("ERROR: Invalid size 0\n"); + return CMD_RET_FAILURE; + } + /* Consistency checking */ if (offset + size > flash->size) { printf("ERROR: attempting %s past flash size (%#x)\n", -- 2.17.1

5 6

Re: The latest U-boot reports an error when running on StarFive visionfive2 1.3B board
by yanhong wang 03 Jun '23

03 Jun '23

On 2023/5/31 2:11, Simon Glass wrote: > Hi Yanhong, > > Please can you send this to the mailing list and cc me? > > Regards, > Simon > > On Tue, 16 May 2023 at 20:48, yanhong wang > <yanhong.wang(a)starfivetech.com> wrote: >> >> Hi Simon Glass, >> >> Running the latest U-boot on the StarFive VisionFive 2 1.3B board prompts the following error message: >> >> U-Boot 2023.07-rc2-00133-g6e1852ca2c (May 17 2023 - 09:08:48 +0800) >> >> CPU: rv64imafdc_zba_zbb >> Model: StarFive VisionFive 2 v1.3B >> DRAM: 8 GiB >> initcall sequence 00000000fffe08b0 failed at call 000000004021611e (err=-19) >> ### ERROR ### Please RESET the board ### >> >> Roll back the most recent submission, and finally confirm that one of the submission affected [commit ID: 55171aedda88d12666e2a1bbc661dea1bec65337]. >> The author of this submission is you, so I sent this email to learn more about the specific situation. >> >> Do you have any suggestions to solution this issue? >> >> >> Best Regards. >> >> yanhong.wang(a)starfivetech.com

3 2

[RFC PATCH 0/4] Allwinner R528/T113s PSCI
by Sam Edwards 02 Jun '23

02 Jun '23

Hi Andre (and list), Per our previous discussion, these are my patches to add PSCI support to your WIP R528/T113s series. I am sending it as RFC because I have CC'd the list and don't want these changes to be treated as patches against upstream. The first patch in this series provides a few more register definitions for cpu_sunxi_ncat2.h. The next two are refactoring, independent of any specific arch/SoC. The final patch adds PSCI support. It might or might not be appropriate to split out the refactoring patches for separate review and inclusion; otherwise, the intent of this patchset is to be incorporated into the existing R528 series. Cheers, Sam Sam Edwards (4): SQUASH ME sunxi: psci: clean away preprocessor macros sunxi: psci: refactor register access to separate functions sunxi: psci: implement PSCI on R528 arch/arm/cpu/armv7/sunxi/psci.c | 185 ++++++++++++------ .../include/asm/arch-sunxi/cpu_sunxi_ncat2.h | 7 +- arch/arm/mach-sunxi/Kconfig | 2 + include/configs/sunxi-common.h | 8 + 4 files changed, 138 insertions(+), 64 deletions(-) -- 2.39.2

2 5

[PATCH 1/1] fs: fix smh_fs_read_at()
by Heinrich Schuchardt 02 Jun '23

02 Jun '23

The return value of smh_flen() is written to size and not to ret. But ret is checked. We can avoid calling smh_flen() by setting maxsize to LONG_MAX if it is not set yet. Check input parameters. Fixes: f676b45151c3 ("fs: Add semihosting filesystem") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- fs/semihostingfs.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/fs/semihostingfs.c b/fs/semihostingfs.c index 96eb3349a2..8a7d4da884 100644 --- a/fs/semihostingfs.c +++ b/fs/semihostingfs.c @@ -25,6 +25,9 @@ static int smh_fs_read_at(const char *filename, loff_t pos, void *buffer, { long fd, size, ret; + if (pos > LONG_MAX || maxsize > LONG_MAX) + return -EINVAL; + fd = smh_open(filename, MODE_READ | MODE_BINARY); if (fd < 0) return fd; @@ -33,15 +36,8 @@ static int smh_fs_read_at(const char *filename, loff_t pos, void *buffer, smh_close(fd); return ret; } - if (!maxsize) { - size = smh_flen(fd); - if (ret < 0) { - smh_close(fd); - return size; - } - - maxsize = size; - } + if (!maxsize) + maxsize = LONG_MAX; size = smh_read(fd, buffer, maxsize); smh_close(fd); -- 2.39.2

2 7

[PATCH v1 0/6] Provide support for mv88e6020 Marvell switch
by Lukasz Majewski 02 Jun '23

02 Jun '23

This patch set provides support for mv88e6020 switch. It is a dual chip device, with direct access to port register on SMI bus. However, PHYs are accessed indirectly. I've rebased this series (unmodified) on v2023.07-rcX (SHA1: cb4437e530ec1ff3deae85754010344afab8bcc5) and added reviewed by tags. Lukasz Majewski (6): net: mv88e61xx: Add support for checking addressing mode net: mv88e61xx: Configure PHY ports to also pass packets between them net: mv88e61xx: Clear temporary structs before using them in get_phy_id() net: mv88e61xx: Directly access the switch chip net: mv88e61xx: Set proper offset when R0_LED/ADDR4 is set on bootstrap net: mv88e61xx: Reset switch PHYs when bootstrapped to !NO_CPU drivers/net/phy/mv88e61xx.c | 158 ++++++++++++++++++++++++++++++++---- 1 file changed, 142 insertions(+), 16 deletions(-) -- 2.30.2

3 15

[PATCH v5 1/5] firmware: zynqmp: Remove extraordinary return value
by Stefan Herbrechtsmeier 02 Jun '23

02 Jun '23

From: Stefan Herbrechtsmeier <stefan.herbrechtsmeier(a)weidmueller.com> Return a common -EACCES error value instead of a positive private error value XST_PM_NO_ACCESS (2002) in zynqmp_pmufw_load_config_object function if the config object is not loadable to simplify the error checking. Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier(a)weidmueller.com> --- (no changes since v3) Changes in v3: - Rebase Changes in v2: - Use macro for node id drivers/firmware/firmware-zynqmp.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/firmware/firmware-zynqmp.c b/drivers/firmware/firmware-zynqmp.c index dc8e3ad2b9..2b1ad5d2c3 100644 --- a/drivers/firmware/firmware-zynqmp.c +++ b/drivers/firmware/firmware-zynqmp.c @@ -82,7 +82,7 @@ int zynqmp_pmufw_node(u32 id) ret = zynqmp_pmufw_load_config_object(xpm_configobject, sizeof(xpm_configobject)); - if (ret == XST_PM_NO_ACCESS && id == NODE_OCM_BANK_0) + if (ret == -EACCES && id == NODE_OCM_BANK_0) skip_config = true; return 0; @@ -235,8 +235,7 @@ int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id) * * @cfg_obj: Pointer to the configuration object * @size: Size of @cfg_obj in bytes - * Return: 0 on success otherwise negative errno. If the config object - * is not loadable returns positive errno XST_PM_NO_ACCESS(2002) + * Return: 0 on success otherwise negative errno. */ int zynqmp_pmufw_load_config_object(const void *cfg_obj, size_t size) { @@ -251,10 +250,8 @@ int zynqmp_pmufw_load_config_object(const void *cfg_obj, size_t size) err = xilinx_pm_request(PM_SET_CONFIGURATION, (u32)(u64)cfg_obj, 0, 0, 0, ret_payload); if (err == XST_PM_NO_ACCESS) { - if (((u32 *)cfg_obj)[NODE_ID_LOCATION] == NODE_OCM_BANK_0) { + if (((u32 *)cfg_obj)[NODE_ID_LOCATION] == NODE_OCM_BANK_0) printf("PMUFW: No permission to change config object\n"); - return err; - } return -EACCES; } -- 2.30.2

2 5

Running u-boot and linux on qemu arm64 virt machine, linux shell does not respond..
by Chan Kim 02 Jun '23

02 Jun '23

Hello all, I'm trying to run u-boot and linux on qemu arm64 virt machine preferably without changing any source code. (u-boot v2022.07, linux 5.15.68, qemu 6.2.0, busybox 1.32.1) I have built u-boot using qemu_arm64_defconfig and I got u-boot(elf) and u-boot.bin. I built linux using defconfig but later I removed many CONFIG_* to reduce compile time and got Image(binary). Also, I built busybox and made ramdisk. Now this is the qemu command I used. (I referenced u-boot's include/configs/qemu-arm.h to determine the load addresses, set CONFIG_BOOTCOMMAND=" booti 0x40400000 0x44000000 0x40000000") ../temp/qemu-6.2.0/build/aarch64-softmmu/qemu-system-aarch64 -machine virt,gic-version=max,secure=on,virtualization=true -cpu max -m 4G -nographic -bios u-boot/u-boot.bin -device loader,file=../temp/linux-5.15.68/arch/arm64/boot/Image,addr=0x40400000 -device loader,file=initrd.img,addr=0x44000000 u-boot runs and automatically boots linunx and it boots OK to the shell prompt. But at the linux shell prompt, it doesn't respond to my keyboard input. It looks like the symptom I saw last year when system counter is not working(for real board only). (I added system counter device in our qemu virtual machine just to not cause panic during the system counter access with the same driver. The qemu machine for our board runs ok using u-boot-spl and linux after booting including shell program and simple driver test. I'm trying to use u-boot proper now). Also last year I had to power-on the GICR(for virtual machine and real board). So I tried adding the code to power up GICR but it is the same. (this part is missing in u-boot, but I saw it is in the arm-tf S/W). For your reference this is the change in u-boot's arch/arm/lib/gic_64.S. /* x9: ReDistributor Base Address of Current CPU */ 2: mov w10, #~0x2 ldr w11, [x9, GICR_WAKER] and w11, w11, w10 /* Clear ProcessorSleep */ str w11, [x9, GICR_WAKER] dsb st isb ==> /* x9: ReDistributor Base Address of Current CPU */ 2: // gicr power on, ckim mov w10, 2 str w10, [x9, GICR_PWRR] 5: ldr w10, [x9, GICR_PWRR] tbnz w10, #1, 5b /* Wait Children be Alive */ mov w10, #~0x2 ldr w11, [x9, GICR_WAKER] and w11, w11, w10 /* Clear ProcessorSleep */ str w11, [x9, GICR_WAKER] dsb st isb Can anyone suggest what I can try to solve this problem? (I mean, the problem of linux shell not responding in qemu virtual machine) I would appreciate it for any comment or help. Thank you. Chan Kim

1 0