Re: [PATCH V4 2/2] riscv: board: Support OpenPiton SoC
Hi Sean, On 5/13/2021 3:49 PM, Bin Meng wrote: Hi Tianrui, On Thu, May 13, 2021 at 2:50 PM Tianrui Wei wrote: Hi Bin, On 5/13/2021 2:32 PM, Bin Meng wrote: Hi Tianrui, On Thu, May 13, 2021 at 1:07 PM Tianrui Wei wrote: Hi Sean, On 5/13/2021 1:14 AM, Sean Anderson wrote: [snip] On 5/8/2021 11:14 PM, Sean Anderson wrote: On 5/8/21 12:57 AM, Tianrui Wei wrote: On 5/7/2021 9:03 PM, Sean Anderson wrote: On 5/6/21 11:48 PM, Tianrui Wei wrote: On 5/7/2021 11:41 AM, Sean Anderson wrote: On 5/6/21 11:28 PM, Tianrui Wei wrote: On 5/7/2021 11:15 AM, Sean Anderson wrote: On 5/6/21 11:06 PM, Tianrui Wei wrote: On 5/7/2021 10:32 AM, Sean Anderson wrote: Please use a log without debug uart. So this is the part where it was a little confusing. Disabling debug uart acutally doesn't work for some reason, so we had to keep it open. Will submit another patch if we got it working with debug uart turned off. This is a bit of a strange request, but can you try adding some nops() (around 10-30) to some function (e.g. board_init). I've been having alignment problems in k210, so it could be something similar. I was wondering if you have any idea what may cause the alignment problems, we're also hitting it constantly and adding nops seems to have no impact so far. I have no idea :) If adding nop()s doesn't solve it, it may not be an alignment problem. You can also try switching from -Os to -O2, which should move things around a bit. My attempts to dig into this have been stymied by the poor debugging tools for the k210. The upstream openocd port only supports debugging hart 0. While Canaan's fork supports debugging both harts, you must pick the one to debug when launching the debugger. And both debuggers are very buggy themselves. The other problem on the k210 at least is that the typical failure mode (trying to read from unaddressable/unmapped addresses) hangs the bus. This also has the tendancy of hanging the jtag debug port. I did try to switch from -Os to -O2, and it didn't help either. I've also encountered the same debugger situation unfortunately, so I have not much luck finding the faulty instruction either. Maybe we should bring this issue up with the others along the compilation error? Sorry I lost the track. What problems are you seeing? There are two issues we're talking about. The first issue is a compilation issue, where CONFIG_SYS_TEXT_BASE cannot be set to a high address, otherwise the linker will error. The error messages are as follows Why do you need to set it to a high address? Out bootrom was at this address, and we were hoping to use SPL as ZSBL directly. common/built-in.o: in function `malloc_trim': /u-boot/common/dlmalloc.c:2236:(.text.malloc_trim+0x7e): relocation truncated to fit: R_RISCV_PCREL_HI20 against `.LANCHOR0' common/built-in.o: in function `free': /u-boot/common/dlmalloc.c:1603:(.text.free+0x62): relocation truncated to fit: R_RISCV_PCREL_HI20 against `.LANCHOR3' common/built-in.o: in function `malloc_extend_top': /u-boot/common/dlmalloc.c:1124:(.text.malloc+0x284): relocation truncated to fit: R_RISCV_PCREL_HI20 against `.LANCHOR3' scripts/Makefile.spl:463: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1 Makefile:1904: recipe for target 'spl/u-boot-spl' failed make: *** [spl/u-boot-spl] Error 2 make: *** Waiting for unfinished jobs With the qemu_riscv64_spl_defconfig on u-boot HEAD and toolchain of xpack-riscv-none-embed-gcc-10.1.0-1.1, only changing CONFIG_SPL_TEXT_BASE to 0xfff. The second problem we're seeing is that u-boot can only successfully boot linux with a set of certain configuration options. In our case, we had to explicitly enable many irrelevant features and turn on uart debug for linux to boot, otherwise uboot will be stuck. Sean suspected there may be some alignment issues. Does U-Boot boot, or were you talking about using U-Boot to boot Linux kernel and saw some random crash of U-Boot or Linux? U-Boot boots alright, but it will stuck when loading the kernel image without specific configurations. Regards, Bin
Re: [PATCH v4 12/14] dfu_mtd: Ignore non-implemented lock device failure
Hi Sughosh,
2021年5月19日(水) 15:07 Sughosh Ganu :
>
>
>
> On Wed, 19 May 2021 at 11:16, Masami Hiramatsu
> wrote:
>>
>> Ignore the non-implemented lock device failure on writing mtd
>> via DFU. Without this fix, DFU write shows an error on such device
>> even if it succeeded, because dfu->write_medium returns -EOPNOTSUPP.
>>
>> Signed-off-by: Masami Hiramatsu
>> Cc: Lukasz Majewski
>> ---
>> drivers/dfu/dfu_mtd.c |2 ++
>> 1 file changed, 2 insertions(+)
>
>
> A patch has already been submitted for this[1].
Ah, thanks for pointing! If that is merged, I can drop this patch.
Thank you,
>
> Patrick, can you please apply this in your tree and send it as part of the
> next PR. Thanks.
>
> -sughosh
>
> [1] - https://lists.denx.de/pipermail/u-boot/2021-March/443896.html
>
>
>>
>> diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
>> index ca67585a7e..e58302c32d 100644
>> --- a/drivers/dfu/dfu_mtd.c
>> +++ b/drivers/dfu/dfu_mtd.c
>> @@ -152,6 +152,8 @@ static int mtd_block_op(enum dfu_op op, struct
>> dfu_entity *dfu,
>> ret = mtd_lock(mtd, lock_ofs, lock_len);
>> if (ret && ret != -EOPNOTSUPP)
>> printf("MTD device lock failed\n");
>> + if (ret == -EOPNOTSUPP)
>> + ret = 0;
>> }
>> return ret;
>> }
>>
--
Masami Hiramatsu
Re: [PATCH] fs: btrfs: Add missing cache aligned allocation
On Tue, 18 May 2021 00:39:39 +0200 Marek Vasut wrote: > The superblock buffer must be cache aligned, since it might be used > in DMA context, allocate it using ALLOC_CACHE_ALIGN_BUFFER() just > like it was done in btrfs_read_superblock() and read_tree_node(). > > This fixes this output on boot and non-working btrfs on iMX53: > CACHE: Misaligned operation at range [ced299d0, ced2a9d0] > > Signed-off-by: Marek Vasut > Cc: Marek Behún > Cc: Qu Wenruo > --- Reviewed-by: Marek Behún
Re: [PATCH v4 12/14] dfu_mtd: Ignore non-implemented lock device failure
On Wed, 19 May 2021 at 11:16, Masami Hiramatsu
wrote:
> Ignore the non-implemented lock device failure on writing mtd
> via DFU. Without this fix, DFU write shows an error on such device
> even if it succeeded, because dfu->write_medium returns -EOPNOTSUPP.
>
> Signed-off-by: Masami Hiramatsu
> Cc: Lukasz Majewski
> ---
> drivers/dfu/dfu_mtd.c |2 ++
> 1 file changed, 2 insertions(+)
>
A patch has already been submitted for this[1].
Patrick, can you please apply this in your tree and send it as part of the
next PR. Thanks.
-sughosh
[1] - https://lists.denx.de/pipermail/u-boot/2021-March/443896.html
> diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
> index ca67585a7e..e58302c32d 100644
> --- a/drivers/dfu/dfu_mtd.c
> +++ b/drivers/dfu/dfu_mtd.c
> @@ -152,6 +152,8 @@ static int mtd_block_op(enum dfu_op op, struct
> dfu_entity *dfu,
> ret = mtd_lock(mtd, lock_ofs, lock_len);
> if (ret && ret != -EOPNOTSUPP)
> printf("MTD device lock failed\n");
> + if (ret == -EOPNOTSUPP)
> + ret = 0;
> }
> return ret;
> }
>
>
[PATCH v4 14/14] configs: synquacer: Enable EFI capsule update support
Enable EFI capsule update support. With the EFI capsule update, you can update U-Boot, TF-A and OP-TEE. TF-A and OP-TEE are usually combined as a FIP binary, but if the binary is bigger than 480KB, you have to modify FIP header, split the OP-TEE and stores the OP-TEE binary in the different place. This configuration supports both cases. Signed-off-by: Masami Hiramatsu --- Changes in v4: - Add some config options for EBBR. Changes in v3: - Fix a typo in dfu_alt_info. --- configs/synquacer_developerbox_defconfig | 17 + include/configs/synquacer.h |6 ++ 2 files changed, 23 insertions(+) diff --git a/configs/synquacer_developerbox_defconfig b/configs/synquacer_developerbox_defconfig index 2875fcd794..487755f444 100644 --- a/configs/synquacer_developerbox_defconfig +++ b/configs/synquacer_developerbox_defconfig @@ -112,3 +112,20 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y CONFIG_USB_STORAGE=y +CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y +CONFIG_EFI_CAPSULE_ON_DISK=y +CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y +CONFIG_EFI_CAPSULE_FIRMWARE=y +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y +CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y +CONFIG_EFI_CAPSULE_FMP_HEADER=y +CONFIG_FLASH_CFI_MTD=y +CONFIG_CMD_DFU=y +CONFIG_DFU_TFTP=y +CONFIG_DFU_MTD=y +CONFIG_DFU_RAM=y +CONFIG_DFU_SF=y +CONFIG_DFU_SF_PART=y +CONFIG_FIT=y +CONFIG_OF_LIBFDT=y +CONFIG_CMD_ERASEENV=y diff --git a/include/configs/synquacer.h b/include/configs/synquacer.h index 0dab4de1f1..8fe10d7485 100644 --- a/include/configs/synquacer.h +++ b/include/configs/synquacer.h @@ -61,6 +61,11 @@ /* Since U-Boot 64bit PCIe support is limited, disable 64bit MMIO support */ /* #define CONFIG_SYS_PCI_64BIT1 */ +#define DEFAULT_DFU_ALT_INFO "dfu_alt_info=" \ + "mtd nor1=u-boot.bin raw 20 10;"\ + "fip.bin raw 18 78000;" \ + "optee.bin raw 50 10\0" + /* Distro boot settings */ #ifndef CONFIG_SPL_BUILD #ifdef CONFIG_CMD_USB @@ -104,6 +109,7 @@ "ramdisk_addr_r=0xa000\0" \ "scriptaddr=0x8800\0" \ "pxefile_addr_r=0x8810\0" \ + DEFAULT_DFU_ALT_INFO\ BOOTENV #endif /* __CONFIG_H */
[PATCH v4 13/14] doc: qemu: arm64: Fix the documentation of capsule update
Since the EDK2 GenerateCapsule script is out of date and it doesn't generate the supported version capsule file, the document should refer the mkeficapsule in tools. Signed-off-by: Masami Hiramatsu --- doc/board/emulation/qemu_capsule_update.rst | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/doc/board/emulation/qemu_capsule_update.rst b/doc/board/emulation/qemu_capsule_update.rst index 33ce4bcd32..0a2286d039 100644 --- a/doc/board/emulation/qemu_capsule_update.rst +++ b/doc/board/emulation/qemu_capsule_update.rst @@ -39,16 +39,9 @@ In addition, the following config needs to be disabled(QEMU ARM specific):: CONFIG_TFABOOT -The capsule file can be generated by using the GenerateCapsule.py -script in EDKII:: - -$ ./BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o \ - --fw-version --lsv --guid \ -e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose --update-image-index \ - --verbose +The capsule file can be generated by using the tools/mkeficapsule:: -The above is a wrapper script(GenerateCapsule) which eventually calls -the actual GenerateCapsule.py script. +$ mkeficapsule --raw --index 1 As per the UEFI specification, the capsule file needs to be placed on the EFI System Partition, under the \EFI\UpdateCapsule directory. The
[PATCH v4 12/14] dfu_mtd: Ignore non-implemented lock device failure
Ignore the non-implemented lock device failure on writing mtd
via DFU. Without this fix, DFU write shows an error on such device
even if it succeeded, because dfu->write_medium returns -EOPNOTSUPP.
Signed-off-by: Masami Hiramatsu
Cc: Lukasz Majewski
---
drivers/dfu/dfu_mtd.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
index ca67585a7e..e58302c32d 100644
--- a/drivers/dfu/dfu_mtd.c
+++ b/drivers/dfu/dfu_mtd.c
@@ -152,6 +152,8 @@ static int mtd_block_op(enum dfu_op op, struct dfu_entity
*dfu,
ret = mtd_lock(mtd, lock_ofs, lock_len);
if (ret && ret != -EOPNOTSUPP)
printf("MTD device lock failed\n");
+ if (ret == -EOPNOTSUPP)
+ ret = 0;
}
return ret;
}
[PATCH v4 11/14] board: synquacer: Add DeveloperBox 96boards EE support
Add the DeveloperBox 96boards EE support. This board is also known as Socionext SynQuacer E-Series. It contians one "SC2A11" SoC, which has 24-cores of arm Cortex-A53, and 4 DDR3 slots, 3 PCIe slots (1 4x port and 2 1x ports which are expanded via PCIe bridge chip), 2 USB 3.0 ports and 2 USB 2.0 ports, 2 SATA ports and 1 GbE, 64MB NOR flash and 8GB eMMC on standard MicroATX Form Factor. For more information, see this page; https://www.96boards.org/product/developerbox/ Signed-off-by: Masami Hiramatsu --- Changes in v4: - Add I2C and RTC configuration. - Enable RTC and Date command. - Remove I2C0 node before booting linux to hide it same as EDK2 does. - Add some configurations to make it EBBR compliant. Changes in v3: - Enable CONFIG_MMC_SDHCI_F_SDH30. - Enable CONFIG_CMD_GENERIC (fstype command) for distro boot. - Remove unneeded CONFIG_ONLY_GENERIC_GPIO. Changes in v2: - Do not include arch/gpio.h and remove arch-sc2a11/gpio.h. - Remove non-UEFI boot commands. - Use Distro boot. - Remove NOR-connected SPI node by path instead of alias. - Rename configs/SynQuacer_defconfig to configs/synquacer_developerbox_defconfig. - Rename include/configs/SynQuacer.h to include/configs/synquacer.h. - Move README under doc/board/socionext/ and make it .rst text. --- arch/arm/Kconfig| 14 +++ board/socionext/developerbox/Kconfig| 36 +++ board/socionext/developerbox/MAINTAINERS| 14 +++ board/socionext/developerbox/Makefile |9 ++ board/socionext/developerbox/developerbox.c | 146 +++ configs/synquacer_developerbox_defconfig| 114 + doc/board/index.rst |1 doc/board/socionext/developerbox.rst| 87 doc/board/socionext/index.rst |9 ++ include/configs/synquacer.h | 109 10 files changed, 539 insertions(+) create mode 100644 board/socionext/developerbox/Kconfig create mode 100644 board/socionext/developerbox/MAINTAINERS create mode 100644 board/socionext/developerbox/Makefile create mode 100644 board/socionext/developerbox/developerbox.c create mode 100644 configs/synquacer_developerbox_defconfig create mode 100644 doc/board/socionext/developerbox.rst create mode 100644 doc/board/socionext/index.rst create mode 100644 include/configs/synquacer.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 023824df77..7ff24535cd 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1760,6 +1760,19 @@ config ARCH_UNIPHIER Support for UniPhier SoC family developed by Socionext Inc. (formerly, System LSI Business Division of Panasonic Corporation) +config ARCH_SYNQUACER + bool "Socionext SynQuacer SoCs" + select ARM64 + select DM + select GIC_V3 + select PSCI_RESET + select SYSRESET + select SYSRESET_PSCI + select OF_CONTROL + help + Support for SynQuacer SoC family developed by Socionext Inc. + This SoC is used on 96boards EE DeveloperBox. + config ARCH_STM32 bool "Support STMicroelectronics STM32 MCU with cortex M" select CPU_V7M @@ -2102,6 +2115,7 @@ source "board/hisilicon/poplar/Kconfig" source "board/isee/igep003x/Kconfig" source "board/kontron/sl28/Kconfig" source "board/myir/mys_6ulx/Kconfig" +source "board/socionext/developerbox/Kconfig" source "board/spear/spear300/Kconfig" source "board/spear/spear310/Kconfig" source "board/spear/spear320/Kconfig" diff --git a/board/socionext/developerbox/Kconfig b/board/socionext/developerbox/Kconfig new file mode 100644 index 00..706b8dc0f1 --- /dev/null +++ b/board/socionext/developerbox/Kconfig @@ -0,0 +1,36 @@ +if ARCH_SYNQUACER + +choice + prompt "SC2A11 Cortex-A53 MPCore 24cores" + optional + +config TARGET_DEVELOPERBOX + bool "Socionext DeveloperBox" + select PCI + select DM_PCI + select PCIE_ECAM_SYNQUACER + select SYS_DISABLE_DCACHE_OPS + select OF_BOARD_SETUP + help +Choose this option if you build the U-Boot for the DeveloperBox +96boards Enterprise Edition. +This board will booted from SCP firmware and it enables SMMU, thus +the dcache is updated automatically when DMA operation is executed. +endchoice + +config SYS_SOC + default "sc2a11" + +if TARGET_DEVELOPERBOX + +config SYS_BOARD + default "developerbox" + +config SYS_VENDOR + default "socionext" + +config SYS_CONFIG_NAME + default "synquacer" + +endif +endif diff --git a/board/socionext/developerbox/MAINTAINERS b/board/socionext/developerbox/MAINTAINERS new file mode 100644 index 00..aa672b6e05 --- /dev/null +++ b/board/socionext/developerbox/MAINTAINERS @@ -0,0 +1,14 @@ +DEVELOPER BOX +M: Masami Hiramatsu +M: Jassi Brar +S: Maintained +F: arch/arm/dts/synquacer-* +F: board/socionext/developer
[PATCH v4 10/14] ARM: dts: synquacer: Add device trees for DeveloperBox
Add device trees for 96boards EE DeveloperBox and basement SynQuacer
SoC dtsi. These files are imported from EDK2
commit 83d38b0b4c0f240d4488c600bbe87cea391f3922
as-is (except for the changes #include path and some macros).
And add U-Boot specific changes in synquacer-sc2a11-developerbox-u-boot.dtsi
Signed-off-by: Masami Hiramatsu
---
Changes in v4:
- Add i2c0 and RTC node.
Changes in v3:
- Use generic nor flash instead of specific mx25u51245g.
(chip parameters will be searched by the register value)
Changes in v2:
- Add reference commit id of original EDK2 to the comment
- Just copy the EDK2 dts files as-is (change #include path)
- Split out the u-boot specific changes in -u-boot.dtsi.
- Removed unneeded spi-nor flash partition information.
---
arch/arm/dts/Makefile |2
arch/arm/dts/synquacer-sc2a11-caches.dtsi | 73 ++
.../dts/synquacer-sc2a11-developerbox-u-boot.dtsi | 75 +++
arch/arm/dts/synquacer-sc2a11-developerbox.dts | 56 ++
arch/arm/dts/synquacer-sc2a11.dtsi | 595
5 files changed, 801 insertions(+)
create mode 100644 arch/arm/dts/synquacer-sc2a11-caches.dtsi
create mode 100644 arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
create mode 100644 arch/arm/dts/synquacer-sc2a11-developerbox.dts
create mode 100644 arch/arm/dts/synquacer-sc2a11.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9c601a5c98..2195729d7c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1099,6 +1099,8 @@ dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) +=
ca-presidio-engboard.dtb
dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.dtb
+dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
+
targets += $(dtb-y)
# Add any required device tree compiler flags here
diff --git a/arch/arm/dts/synquacer-sc2a11-caches.dtsi
b/arch/arm/dts/synquacer-sc2a11-caches.dtsi
new file mode 100644
index 00..177ddf8c2b
--- /dev/null
+++ b/arch/arm/dts/synquacer-sc2a11-caches.dtsi
@@ -0,0 +1,73 @@
+/** @file
+ * Copyright (c) 2018, Linaro Limited. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-2-Clause-Patent
+ */
+
+#define __L1(cpuref, l2ref) \
+cpuref {\
+i-cache-size = <0x8000>;\
+i-cache-line-size = <64>; \
+i-cache-sets = <256>; \
+d-cache-size = <0x8000>;\
+d-cache-line-size = <64>; \
+d-cache-sets = <128>; \
+l2-cache = ; \
+};
+
+#define __L2(idx) \
+L2_##idx: l2-cache##idx { \
+cache-size = <0x4>; \
+cache-line-size = <64>; \
+cache-sets = <256>; \
+cache-unified; \
+next-level-cache = <&L3>; \
+};
+
+/ {
+__L2(0)
+__L2(1)
+__L2(2)
+__L2(3)
+__L2(4)
+__L2(5)
+__L2(6)
+__L2(7)
+__L2(8)
+__L2(9)
+__L2(10)
+__L2(11)
+
+L3: l3-cache {
+cache-level = <3>;
+cache-size = <0x40>;
+cache-line-size = <64>;
+cache-sets = <4096>;
+cache-unified;
+};
+};
+
+__L1(&CPU0, &L2_0)
+__L1(&CPU1, &L2_0)
+__L1(&CPU2, &L2_1)
+__L1(&CPU3, &L2_1)
+__L1(&CPU4, &L2_2)
+__L1(&CPU5, &L2_2)
+__L1(&CPU6, &L2_3)
+__L1(&CPU7, &L2_3)
+__L1(&CPU8, &L2_4)
+__L1(&CPU9, &L2_4)
+__L1(&CPU10, &L2_5)
+__L1(&CPU11, &L2_5)
+__L1(&CPU12, &L2_6)
+__L1(&CPU13, &L2_6)
+__L1(&CPU14, &L2_7)
+__L1(&CPU15, &L2_7)
+__L1(&CPU16, &L2_8)
+__L1(&CPU17, &L2_8)
+__L1(&CPU18, &L2_9)
+__L1(&CPU19, &L2_9)
+__L1(&CPU20, &L2_10)
+__L1(&CPU21, &L2_10)
+__L1(&CPU22, &L2_11)
+__L1(&CPU23, &L2_11)
diff --git a/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
b/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
new file mode 100644
index 00..2f13a42235
--- /dev/null
+++ b/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: BSD-2-Clause-Patent
+//
+// Copyright (c) 2021, Linaro Limited. All rights reserved.
+//
+
+/ {
+ aliases {
+ spi_nor = &spi_nor;
+ i2c0 = &i2c0;
+ };
+
+ spi_nor: spi@5480 {
+ compatible = "socionext,synquacer-spi";
+ reg = <0x00 0x5480 0x00 0x1000>;
+ interrupts = <0x00 0x9c 0x04 0x00 0x9d 0x04 0x00 0x9e 0x04>;
+ clocks = <&clk_alw_1_8>;
+ clock-names = "iHCLK";
+ socionext,use-rtm;
+ socionext,set-aces;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+ active_clk_edges;
+ chipselect_num = <1>;
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
[PATCH v4 09/14] i2c: synquacer: SNI Synquacer I2C controller
From: Jassi Brar Add driver for class of I2C controllers found on Socionext Synquacer platform. Signed-off-by: Jassi Brar --- drivers/i2c/Kconfig |7 + drivers/i2c/Makefile|1 drivers/i2c/synquacer_i2c.c | 338 +++ 3 files changed, 346 insertions(+) create mode 100644 drivers/i2c/synquacer_i2c.c diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 57a4efb88e..ce0d796d09 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -455,6 +455,13 @@ config SYS_I2C_STM32F7 _ Optional clock stretching _ Software reset +config SYS_I2C_SYNQUACER + bool "Socionext SynQuacer I2C controller" + depends on ARCH_SYNQUACER && DM_I2C + help + Support for Socionext Synquacer I2C controller. This I2C controller + will be used for RTC and LS-connector on DeveloperBox. + config SYS_I2C_TEGRA bool "NVIDIA Tegra internal I2C controller" depends on ARCH_TEGRA diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index 8c9f1fcd8b..06a1150f03 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -43,6 +43,7 @@ obj-$(CONFIG_SYS_I2C_SANDBOX) += sandbox_i2c.o i2c-emul-uclass.o obj-$(CONFIG_SYS_I2C_SH) += sh_i2c.o obj-$(CONFIG_SYS_I2C_SOFT) += soft_i2c.o obj-$(CONFIG_SYS_I2C_STM32F7) += stm32f7_i2c.o +obj-$(CONFIG_SYS_I2C_SYNQUACER) += synquacer_i2c.o obj-$(CONFIG_SYS_I2C_TEGRA) += tegra_i2c.o obj-$(CONFIG_SYS_I2C_UNIPHIER) += i2c-uniphier.o obj-$(CONFIG_SYS_I2C_UNIPHIER_F) += i2c-uniphier-f.o diff --git a/drivers/i2c/synquacer_i2c.c b/drivers/i2c/synquacer_i2c.c new file mode 100644 index 00..6672d9435e --- /dev/null +++ b/drivers/i2c/synquacer_i2c.c @@ -0,0 +1,338 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define REG_BSR0x0 +#define REG_BCR0x4 +#define REG_CCR0x8 +#define REG_ADR0xc +#define REG_DAR0x10 +#define REG_CSR0x14 +#define REG_FSR0x18 +#define REG_BC2R 0x1c + +/* I2C register bit definitions */ +#define BSR_FBTBIT(0) // First Byte Transfer +#define BSR_GCABIT(1) // General Call Address +#define BSR_AASBIT(2) // Address as Slave +#define BSR_TRXBIT(3) // Transfer/Receive +#define BSR_LRBBIT(4) // Last Received Bit +#define BSR_AL BIT(5) // Arbitration Lost +#define BSR_RSCBIT(6) // Repeated Start Cond. +#define BSR_BB BIT(7) // Bus Busy + +#define BCR_INTBIT(0) // Interrupt +#define BCR_INTE BIT(1) // Interrupt Enable +#define BCR_GCAA BIT(2) // Gen. Call Access Ack. +#define BCR_ACKBIT(3) // Acknowledge +#define BCR_MSSBIT(4) // Master Slave Select +#define BCR_SCCBIT(5) // Start Condition Cont. +#define BCR_BEIE BIT(6) // Bus Error Int Enable +#define BCR_BERBIT(7) // Bus Error + +#define CCR_CS_MASK(0x1f) // CCR Clock Period Sel. +#define CCR_EN BIT(5) // Enable +#define CCR_FM BIT(6) // Speed Mode Select + +#define CSR_CS_MASK(0x3f) // CSR Clock Period Sel. + +#define BC2R_SCLL BIT(0) // SCL Low Drive +#define BC2R_SDAL BIT(1) // SDA Low Drive +#define BC2R_SCLS BIT(4) // SCL Status +#define BC2R_SDAS BIT(5) // SDA Status + +/* PCLK frequency */ +#define BUS_CLK_FR(rate) (((rate) / 2000) + 1) + +#define I2C_CLK_DEF6250 + +/* STANDARD MODE frequency */ +#define CLK_MASTER_STD(rate) \ + DIV_ROUND_UP(DIV_ROUND_UP((rate), I2C_SPEED_STANDARD_RATE) - 2, 2) +/* FAST MODE frequency */ +#define CLK_MASTER_FAST(rate) \ + DIV_ROUND_UP((DIV_ROUND_UP((rate), I2C_SPEED_FAST_RATE) - 2) * 2, 3) + +/* (clkrate <= 1800) */ +/* calculate the value of CS bits in CCR register on standard mode */ +#define CCR_CS_STD_MAX_18M(rate) \ + ((CLK_MASTER_STD(rate) - 65) \ + & CCR_CS_MASK) + +/* calculate the value of CS bits in CSR register on standard mode */ +#define CSR_CS_STD_MAX_18M(rate) 0x00 + +/* calculate the value of CS bits in CCR register on fast mode */ +#define CCR_CS_FAST_MAX_18M(rate) \ + ((CLK_MASTER_FAST(rate) - 1) \ + & CCR_CS_MASK) + +/* calculate the value of CS bits in CSR register on fast mode */ +#define CSR_CS_FAST_MAX_18M(rate) 0x00 + +/* (clkrate > 1800) */ +/* calculate the value of CS bits in CCR register on standard mode */ +#define CCR_CS_STD_MIN_18M(rate) \ + ((CLK_MASTER_STD(rate) -
[PATCH v4 08/14] net: synquacer: Add netsec driver
From: Jassi Brar Add SynQuacer's NETSEC GbE controller driver. Since this driver will load the firmware from SPI NOR flash, this depends on CONFIG_SYNQUACER_SPI=y. Signed-off-by: Jassi Brar --- drivers/net/Kconfig |8 drivers/net/Makefile |1 drivers/net/sni_netsec.c | 1134 ++ 3 files changed, 1143 insertions(+) create mode 100644 drivers/net/sni_netsec.c diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 382639044b..9fc28b149d 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -673,6 +673,14 @@ config SNI_AVE This driver implements support for the Socionext AVE Ethernet controller, as found on the Socionext UniPhier family. +config SNI_NETSEC + bool "Socionext NETSEC Ethernet support" + depends on DM_ETH && SYNQUACER_SPI + select PHYLIB + help + This driver implements support for the Socionext SynQuacer NETSEC + ethernet controller, as found on the Socionext SynQuacer family. + source "drivers/net/mscc_eswitch/Kconfig" config ETHER_ON_FEC1 diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 2ce89f7e3c..c23e828edc 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -90,6 +90,7 @@ obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o obj-$(CONFIG_FSL_PFE) += pfe_eth/ obj-y += qe/ obj-$(CONFIG_SNI_AVE) += sni_ave.o +obj-$(CONFIG_SNI_NETSEC) += sni_netsec.o obj-y += ti/ obj-$(CONFIG_MEDIATEK_ETH) += mtk_eth.o obj-y += mscc_eswitch/ diff --git a/drivers/net/sni_netsec.c b/drivers/net/sni_netsec.c new file mode 100644 index 00..a9ebf6af9c --- /dev/null +++ b/drivers/net/sni_netsec.c @@ -0,0 +1,1134 @@ +// SPDX-License-Identifier: GPL-2.0+ +/** + * netsec.c - Socionext Synquacer Netsec driver + * Copyright 2021 Linaro Ltd. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define NETSEC_REG_SOFT_RST0x104 +#define NETSEC_REG_COM_INIT0x120 + +#define NETSEC_REG_TOP_STATUS 0x200 +#define NETSEC_IRQ_RX BIT(1) +#define NETSEC_IRQ_TX BIT(0) + +#define NETSEC_REG_TOP_INTEN 0x204 +#define NETSEC_REG_INTEN_SET 0x234 +#define NETSEC_REG_INTEN_CLR 0x238 + +#define NETSEC_REG_NRM_TX_STATUS 0x400 +#define NETSEC_REG_NRM_TX_INTEN0x404 +#define NETSEC_REG_NRM_TX_INTEN_SET0x428 +#define NETSEC_REG_NRM_TX_INTEN_CLR0x42c +#define NRM_TX_ST_NTOWNR BIT(17) +#define NRM_TX_ST_TR_ERR BIT(16) +#define NRM_TX_ST_TXDONE BIT(15) +#define NRM_TX_ST_TMREXP BIT(14) + +#define NETSEC_REG_NRM_RX_STATUS 0x440 +#define NETSEC_REG_NRM_RX_INTEN0x444 +#define NETSEC_REG_NRM_RX_INTEN_SET0x468 +#define NETSEC_REG_NRM_RX_INTEN_CLR0x46c +#define NRM_RX_ST_RC_ERR BIT(16) +#define NRM_RX_ST_PKTCNT BIT(15) +#define NRM_RX_ST_TMREXP BIT(14) + +#define NETSEC_REG_PKT_CMD_BUF 0xd0 + +#define NETSEC_REG_CLK_EN 0x100 + +#define NETSEC_REG_PKT_CTRL0x140 + +#define NETSEC_REG_DMA_TMR_CTRL0x20c +#define NETSEC_REG_F_TAIKI_MC_VER 0x22c +#define NETSEC_REG_F_TAIKI_VER 0x230 +#define NETSEC_REG_DMA_HM_CTRL 0x214 +#define NETSEC_REG_DMA_MH_CTRL 0x220 +#define NETSEC_REG_ADDR_DIS_CORE 0x218 +#define NETSEC_REG_DMAC_HM_CMD_BUF 0x210 +#define NETSEC_REG_DMAC_MH_CMD_BUF 0x21c + +#define NETSEC_REG_NRM_TX_PKTCNT 0x410 + +#define NETSEC_REG_NRM_TX_DONE_PKTCNT 0x414 +#define NETSEC_REG_NRM_TX_DONE_TXINT_PKTCNT0x418 + +#define NETSEC_REG_NRM_TX_TMR 0x41c + +#define NETSEC_REG_NRM_RX_PKTCNT 0x454 +#define NETSEC_REG_NRM_RX_RXINT_PKTCNT 0x458 +#define NETSEC_REG_NRM_TX_TXINT_TMR0x420 +#define NETSEC_REG_NRM_RX_RXINT_TMR0x460 + +#define NETSEC_REG_NRM_RX_TMR 0x45c + +#define NETSEC_REG_NRM_TX_DESC_START_UP0x434 +#define NETSEC_REG_NRM_TX_DESC_START_LW0x408 +#define NETSEC_REG_NRM_RX_DESC_START_UP0x474 +#define NETSEC_REG_NRM_RX_DESC_START_LW0x448 + +#define NETSEC_REG_NRM_TX_CONFIG 0x430 +#define NETSEC_REG_NRM_RX_CONFIG 0x470 + +#define MAC_REG_STATUS 0x1024 +#define MAC_REG_DATA 0x11c0 +#define MAC_REG_CMD0x11c4 +#define MAC_REG_FLOW_TH0x11cc +#define MAC_REG_INTF_SEL 0x11d4 +#define M
[PATCH v4 06/14] mmc: synquacer: Add SynQuacer F_SDH30 SDHCI driver
From: Jassi Brar
Signed-off-by: Jassi Brar
Signed-off-by: Masami Hiramatsu
Reviewed-by: Jaehoon Chung
---
Changes in v4:
- Add Jaehoon's reviewed-by.
Changes in v3:
- Rename config name to MMC_SDHCI_F_SDH30.
- Remove unneeded wait in drivers/mmc/sdhci.c.
- Rename probe function to f_sdh30_sdhci_probe.
---
drivers/mmc/Kconfig | 10 ++
drivers/mmc/Makefile |1 +
drivers/mmc/f_sdh30.c | 81 +
3 files changed, 92 insertions(+)
create mode 100644 drivers/mmc/f_sdh30.c
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 8901456967..1c5aecfa5c 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -561,6 +561,16 @@ config MMC_SDHCI_IPROC
If unsure, say N.
+config MMC_SDHCI_F_SDH30
+ bool "SDHCI support for Fujitsu Semiconductor F_SDH30"
+ depends on BLK && DM_MMC
+ depends on MMC_SDHCI
+ help
+ This selects the Secure Digital Host Controller Interface (SDHCI)
+ Needed by some Fujitsu SoC for MMC / SD / SDIO support.
+ If you have a controller with this interface, say Y or M here.
+ If unsure, say N.
+
config MMC_SDHCI_KONA
bool "SDHCI support on Broadcom KONA platform"
depends on MMC_SDHCI
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 89d6af3db3..f5fd59093e 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -76,3 +76,4 @@ obj-$(CONFIG_MMC_UNIPHIER)+= tmio-common.o
uniphier-sd.o
obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o
obj-$(CONFIG_MMC_BCM2835) += bcm2835_sdhost.o
obj-$(CONFIG_MMC_MTK) += mtk-sd.o
+obj-$(CONFIG_MMC_SDHCI_F_SDH30)+= f_sdh30.o
diff --git a/drivers/mmc/f_sdh30.c b/drivers/mmc/f_sdh30.c
new file mode 100644
index 00..3a85d9e348
--- /dev/null
+++ b/drivers/mmc/f_sdh30.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Socionext F_SDH30 eMMC driver
+ * Copyright 2021 Linaro Ltd.
+ * Copyright 2021 Socionext, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct f_sdh30_plat {
+ struct mmc_config cfg;
+ struct mmc mmc;
+};
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int f_sdh30_sdhci_probe(struct udevice *dev)
+{
+ struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+ struct f_sdh30_plat *plat = dev_get_plat(dev);
+ struct sdhci_host *host = dev_get_priv(dev);
+ int ret;
+
+ ret = mmc_of_parse(dev, &plat->cfg);
+ if (ret)
+ return ret;
+
+ host->mmc = &plat->mmc;
+ host->mmc->dev = dev;
+ host->mmc->priv = host;
+
+ ret = sdhci_setup_cfg(&plat->cfg, host, 2, 40);
+ if (ret)
+ return ret;
+
+ upriv->mmc = host->mmc;
+
+ mmc_set_clock(host->mmc, host->mmc->cfg->f_min, MMC_CLK_ENABLE);
+
+ return sdhci_probe(dev);
+}
+
+static int f_sdh30_of_to_plat(struct udevice *dev)
+{
+ struct sdhci_host *host = dev_get_priv(dev);
+
+ host->name = strdup(dev->name);
+ host->ioaddr = dev_read_addr_ptr(dev);
+ host->bus_width = dev_read_u32_default(dev, "bus-width", 4);
+ host->index = dev_read_u32_default(dev, "index", 0);
+
+ return 0;
+}
+
+static int f_sdh30_bind(struct udevice *dev)
+{
+ struct f_sdh30_plat *plat = dev_get_plat(dev);
+
+ return sdhci_bind(dev, &plat->mmc, &plat->cfg);
+}
+
+static const struct udevice_id f_sdh30_mmc_ids[] = {
+ { .compatible = "fujitsu,mb86s70-sdhci-3.0" },
+ { }
+};
+
+U_BOOT_DRIVER(f_sdh30_drv) = {
+ .name = "f_sdh30_sdhci",
+ .id = UCLASS_MMC,
+ .of_match = f_sdh30_mmc_ids,
+ .of_to_plat = f_sdh30_of_to_plat,
+ .ops= &sdhci_ops,
+ .bind = f_sdh30_bind,
+ .probe = f_sdh30_sdhci_probe,
+ .priv_auto = sizeof(struct sdhci_host),
+ .plat_auto = sizeof(struct f_sdh30_plat),
+};
[PATCH v4 07/14] spi: synquacer: Add HSSPI SPI controller driver for SynQuacer
From: Jassi Brar
This is a driver for the HSSPI SPI controller on SynQuacer SoC.
The HSSPI has command sequence mode (memory mapped) and
direct mode (FIFO access). The driver will operate it under
the direct mode. And before booting OS, it switch back to the
command sequence mode since that is compatible with default
EDK2 behavior.
Signed-off-by: Jassi Brar
Signed-off-by: Masami Hiramatsu
---
drivers/spi/Kconfig |8 +
drivers/spi/Makefile|1
drivers/spi/spi-synquacer.c | 491 +++
3 files changed, 500 insertions(+)
create mode 100644 drivers/spi/spi-synquacer.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 1494c91763..62d9676550 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -481,4 +481,12 @@ config MXC_SPI
Enable the MXC SPI controller driver. This driver can be used
on various i.MX SoCs such as i.MX31/35/51/6/7.
+config SYNQUACER_SPI
+ bool "Socionext SynQuacer HS-SPI driver"
+ depends on ARCH_SYNQUACER
+ help
+ Enable the Socionext HS-SPI driver for SynQuacer. This driver can
+ be used to access the SPI interface and SPI NOR flash on platforms
+ embedding this HS-SPI IP core.
+
endif # menu "SPI Support"
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index cfe4fae1d4..98c95323d1 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o
obj-$(CONFIG_FSL_ESPI) += fsl_espi.o
obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o
+obj-$(CONFIG_SYNQUACER_SPI) += spi-synquacer.o
obj-$(CONFIG_ICH_SPI) += ich.o
obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
diff --git a/drivers/spi/spi-synquacer.c b/drivers/spi/spi-synquacer.c
new file mode 100644
index 00..ce558c4bc0
--- /dev/null
+++ b/drivers/spi/spi-synquacer.c
@@ -0,0 +1,491 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * spi-synquacer.c - Socionext Synquacer SPI driver
+ * Copyright 2021 Linaro Ltd.
+ * Copyright 2021 Socionext, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MCTRL 0x0
+#define MEN0
+#define CSEN 1
+#define IPCLK 3
+#define MES4
+#define SYNCON 5
+
+#define PCC0 0x4
+#define PCC(n) (PCC0 + (n) * 4)
+#define RTM3
+#define ACES 2
+#define SAFESYNC 16
+#define CPHA 0
+#define CPOL 1
+#define SSPOL 4
+#define SDIR 7
+#define SS2CD 5
+#define SENDIAN8
+#define CDRS_SHIFT 9
+#define CDRS_MASK 0x7f
+
+#define TXF0x14
+#define TXE0x18
+#define TXC0x1c
+#define RXF0x20
+#define RXE0x24
+#define RXC0x28
+#define TFLETE 4
+#define RFMTE 5
+
+#define FAULTF 0x2c
+#define FAULTC 0x30
+
+#define DMCFG 0x34
+#define SSDC 1
+#define MSTARTEN 2
+
+#define DMSTART0x38
+#define TRIGGER0
+#define DMSTOP 8
+#define CS_MASK3
+#define CS_SHIFT 16
+#define DATA_TXRX 0
+#define DATA_RX1
+#define DATA_TX2
+#define DATA_MASK 3
+#define DATA_SHIFT 26
+#define BUS_WIDTH 24
+
+#define DMBCC 0x3c
+#define DMSTATUS 0x40
+#define RX_DATA_MASK 0x1f
+#define RX_DATA_SHIFT 8
+#define TX_DATA_MASK 0x1f
+#define TX_DATA_SHIFT 16
+
+#define TXBITCNT 0x44
+
+#define FIFOCFG0x4c
+#define BPW_MASK 0x3
+#define BPW_SHIFT 8
+#define RX_FLUSH 11
+#define TX_FLUSH 12
+#define RX_TRSHLD_MASK 0xf
+#define RX_TRSHLD_SHIFT0
+#define TX_TRSHLD_MASK 0xf
+#define TX_TRSHLD_SHIFT4
+
+#define TXFIFO 0x50
+#define RXFIFO 0x90
+#define MID0xfc
+
+#define FIFO_DEPTH 16
+#define TX_TRSHLD 4
+#define RX_TRSHLD (FIFO_DEPTH - TX_TRSHLD)
+
+#define TXBIT 1
+#define RXBIT 2
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct synquacer_spi_plat {
+ void __iomem *base;
+ bool aces, rtm;
+};
+
+struct synquacer_spi_priv {
+ void __iomem *base;
+ bool aces, rtm;
+ int speed, cs, mode, rwflag;
+ void *rx_buf;
+ const void *tx_buf;
+ unsigned int tx_words, rx_words;
+};
+
+static void read_fifo(struct synquacer_spi_priv *priv)
+{
+ u32 len = readl(priv->base + DMSTATUS);
+ u8 *buf = priv->rx_buf;
+ int i;
+
+ len = (len >> RX_DATA_SHIFT) & RX_DATA_MASK;
+ len = min_t(unsigned int, len, priv->rx_words);
+
+ for (i = 0; i < len; i++)
+ *buf++ = readb(priv->base + RXFIFO);
+
+ priv->rx_buf = buf;
+ priv->rx_words -= len;
+}
+
+static void write_fifo(struct synquacer_spi_priv *pri
[PATCH v4 05/14] pci: synquacer: Add SynQuacer ECAM based PCIe driver
Add ECAM based SynQuacer PCIe RC driver. This driver configures the PCIe RC and filter out a ghost pcie config. Since the Linux kernel expects "socionext,synquacer-pcie-ecam" device is configured by firmware (EDK2), it doesn't re-configure in the kernel. So as same as EDK2, U-Boot needs to configure it before boot the kernel. Signed-off-by: Masami Hiramatsu --- drivers/pci/Kconfig | 12 + drivers/pci/Makefile |1 drivers/pci/pcie_ecam_synquacer.c | 600 + 3 files changed, 613 insertions(+) create mode 100644 drivers/pci/pcie_ecam_synquacer.c diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index d5b6018b3d..2e6393f25b 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -81,6 +81,18 @@ config PCIE_ECAM_GENERIC Say Y here if you want to enable support for generic ECAM-based PCIe host controllers, such as the one emulated by QEMU. +config PCIE_ECAM_SYNQUACER + bool "SynQuacer ECAM-based PCI host controller support" + default n + depends on DM_PCI + select PCI_INIT_R + select PCI_REGION_MULTI_ENTRY + help + Say Y here if you want to enable support for Socionext + SynQuacer SoC's ECAM-based PCIe host controllers. + Note that this must be configured when boot because Linux driver + expects the PCIe RC has been configured in the bootloader. + config PCI_PHYTIUM bool "Phytium PCIe support" depends on DM_PCI diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index 1f741786a0..035e3d3088 100644 --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -16,6 +16,7 @@ endif obj-$(CONFIG_PCI) += pci_auto_common.o pci_common.o obj-$(CONFIG_PCIE_ECAM_GENERIC) += pcie_ecam_generic.o +obj-$(CONFIG_PCIE_ECAM_SYNQUACER) += pcie_ecam_synquacer.o obj-$(CONFIG_FSL_PCI_INIT) += fsl_pci_init.o obj-$(CONFIG_PCI_INDIRECT_BRIDGE) += pci_indirect.o obj-$(CONFIG_PCI_GT64120) += pci_gt64120.o diff --git a/drivers/pci/pcie_ecam_synquacer.c b/drivers/pci/pcie_ecam_synquacer.c new file mode 100644 index 00..c6e7c59f8a --- /dev/null +++ b/drivers/pci/pcie_ecam_synquacer.c @@ -0,0 +1,600 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * SynQuacer PCIE host driver + * + * Based on drivers/pci/pcie_ecam_generic.c + * + * Copyright (C) 2016 Imagination Technologies + * Copyright (C) 2021 Linaro Ltd. + */ + +#include +#include +#include +#include + +#include +#include +#include + +/* iATU registers */ +#define IATU_VIEWPORT_OFF 0x900 +#define IATU_VIEWPORT_INBOUND BIT(31) +#define IATU_VIEWPORT_OUTBOUND 0 +#define IATU_VIEWPORT_REGION_INDEX(idx) ((idx) & 7) + +#define IATU_REGION_CTRL_1_OFF_OUTBOUND_0 0x904 +#define IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_MEM 0x0 +#define IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_IO 0x2 +#define IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_CFG0 0x4 +#define IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_CFG1 0x5 +#define IATU_REGION_CTRL_1_OFF_OUTBOUND_0_THBIT(12) + +#define IATU_REGION_CTRL_2_OFF_OUTBOUND_0 0x908 +#define IATU_REGION_CTRL_2_OFF_OUTBOUND_0_REGION_EN BIT(31) +#define IATU_REGION_CTRL_2_OFF_OUTBOUND_0_CFG_SHIFT_MODEBIT(28) +#define IATU_REGION_CTRL_2_OFF_OUTBOUND_0_MSG_CODE_32BIT0xF +#define IATU_REGION_CTRL_2_OFF_OUTBOUND_0_MSG_CODE_64BIT0xFF + +#define IATU_LWR_BASE_ADDR_OFF_OUTBOUND_0 0x90C +#define IATU_UPPER_BASE_ADDR_OFF_OUTBOUND_0 0x910 +#define IATU_LIMIT_ADDR_OFF_OUTBOUND_0 0x914 +#define IATU_LWR_TARGET_ADDR_OFF_OUTBOUND_0 0x918 +#define IATU_UPPER_TARGET_ADDR_OFF_OUTBOUND_0 0x91C + +/* Clock and resets */ +#define CORE_CONTROL 0x000 +#define APP_LTSSM_ENABLE BIT(4) +#define DEVICE_TYPE (BIT(3) | BIT(2) | BIT(1) | BIT(0)) + +#define AXI_CLK_STOP 0x004 +#define DBI_ACLK_STOP BIT(8) +#define SLV_ACLK_STOP BIT(4) +#define MSTR_ACLK_STOPBIT(0) +#define DBI_CSYSREQ_REG BIT(9) +#define SLV_CSYSREQ_REG BIT(5) +#define MSTR_CSYSREQ_REG BIT(1) + +#define RESET_CONTROL_1 0x00C +#define PERST_N_O_REG BIT(5) +#define PERST_N_I_REG BIT(4) +#define BUTTON_RST_N_REG BIT(1) +#define PWUP_RST_N_REGBIT(0) + +#define RESET_CONTROL_2 0x010 + +#define RESET_SELECT_10x014 +#define SQU_RST_SEL BIT(29) +#define PHY_RST_SEL BIT(28) +#define PWR_RST_SEL BIT(24) +#define STI_RST_SEL BIT(20) +#define N_STI_RST_SEL BIT(16) +#define CORE_RST_SEL BIT(12) +#
[PATCH v4 04/14] gpio: Introduce CONFIG_GPIO_EXTRA_HEADER to cleanup #ifdefs
Since some SoCs and boards do not hae extra asm/arch/gpio.h, introduce CONFIG_GPIO_EXTRA_HEADER instead of adding !define(CONFIG_ARCH_) in asm/gpio.h. Signed-off-by: Masami Hiramatsu --- Changes in v3: - Change the config name to positive and selected by the opposite CONFIG_ARCH_*. (Build checked by Github CI) --- arch/arm/Kconfig| 94 +++ arch/arm/include/asm/gpio.h |8 2 files changed, 95 insertions(+), 7 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 31d687ea01..023824df77 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -90,6 +90,9 @@ config HAS_VBAR config HAS_THUMB2 bool +config GPIO_EXTRA_HEADER + bool + # Used for compatibility with asm files copied from the kernel config ARM_ASM_UNIFIED bool @@ -518,25 +521,30 @@ choice config ARCH_AT91 bool "Atmel AT91" + select GPIO_EXTRA_HEADER select SPL_BOARD_INIT if SPL && !TARGET_SMARTWEB select SPL_SEPARATE_BSS if SPL config TARGET_EDB93XX bool "Support edb93xx" select CPU_ARM920T + select GPIO_EXTRA_HEADER select PL010_SERIAL config TARGET_ASPENITE bool "Support aspenite" select CPU_ARM926EJS + select GPIO_EXTRA_HEADER config TARGET_GPLUGD bool "Support gplugd" select CPU_ARM926EJS + select GPIO_EXTRA_HEADER config ARCH_DAVINCI bool "TI DaVinci" select CPU_ARM926EJS + select GPIO_EXTRA_HEADER select SPL_DM_SPI if SPL imply CMD_SAVES help @@ -547,6 +555,7 @@ config ARCH_KIRKWOOD select ARCH_MISC_INIT select BOARD_EARLY_INIT_F select CPU_ARM926EJS + select GPIO_EXTRA_HEADER config ARCH_MVEBU bool "Marvell MVEBU family (Armada XP/375/38x/3700/7K/8K)" @@ -555,6 +564,7 @@ config ARCH_MVEBU select DM_SERIAL select DM_SPI select DM_SPI_FLASH + select GPIO_EXTRA_HEADER select SPL_DM_SPI if SPL select SPL_DM_SPI_FLASH if SPL select OF_CONTROL @@ -565,11 +575,13 @@ config ARCH_MVEBU config ARCH_ORION5X bool "Marvell Orion" select CPU_ARM926EJS + select GPIO_EXTRA_HEADER config TARGET_SPEAR300 bool "Support spear300" select BOARD_EARLY_INIT_F select CPU_ARM926EJS + select GPIO_EXTRA_HEADER select PL011_SERIAL imply CMD_SAVES @@ -577,6 +589,7 @@ config TARGET_SPEAR310 bool "Support spear310" select BOARD_EARLY_INIT_F select CPU_ARM926EJS + select GPIO_EXTRA_HEADER select PL011_SERIAL imply CMD_SAVES @@ -584,6 +597,7 @@ config TARGET_SPEAR320 bool "Support spear320" select BOARD_EARLY_INIT_F select CPU_ARM926EJS + select GPIO_EXTRA_HEADER select PL011_SERIAL imply CMD_SAVES @@ -591,6 +605,7 @@ config TARGET_SPEAR600 bool "Support spear600" select BOARD_EARLY_INIT_F select CPU_ARM926EJS + select GPIO_EXTRA_HEADER select PL011_SERIAL imply CMD_SAVES @@ -601,6 +616,7 @@ config TARGET_STV0991 select DM_SERIAL select DM_SPI select DM_SPI_FLASH + select GPIO_EXTRA_HEADER select PL01X_SERIAL select SPI select SPI_FLASH @@ -610,18 +626,21 @@ config TARGET_X600 bool "Support x600" select BOARD_LATE_INIT select CPU_ARM926EJS + select GPIO_EXTRA_HEADER select PL011_SERIAL select SUPPORT_SPL config TARGET_FLEA3 bool "Support flea3" select CPU_ARM1136 + select GPIO_EXTRA_HEADER config ARCH_BCM283X bool "Broadcom BCM283X family" select DM select DM_GPIO select DM_SERIAL + select GPIO_EXTRA_HEADER select OF_CONTROL select PL01X_SERIAL select SERIAL_SEARCH_ALL @@ -650,6 +669,7 @@ config ARCH_BCMSTB bool "Broadcom BCM7XXX family" select CPU_V7A select DM + select GPIO_EXTRA_HEADER select OF_CONTROL select OF_PRIOR_STAGE imply CMD_DM @@ -660,6 +680,7 @@ config ARCH_BCMSTB config TARGET_BCMCYGNUS bool "Support bcmcygnus" select CPU_V7A + select GPIO_EXTRA_HEADER imply BCM_SF2_ETH imply BCM_SF2_ETH_GMAC imply CMD_HASH @@ -671,6 +692,7 @@ config TARGET_BCMCYGNUS config TARGET_BCMNS2 bool "Support Broadcom Northstar2" select ARM64 + select GPIO_EXTRA_HEADER help Support for Broadcom Northstar 2 SoCs. NS2 is a quad-core 64-bit ARMv8 Cortex-A57 processors targeting a broad range of networking @@ -695,6 +717,7 @@ config ARCH_EXYNOS select DM_SPI select DM_SPI_FLASH select SPI + select GPIO_EXTRA_HEADER imply SYS_THUMB_BUILD imply CMD_DM imply FAT_WRITE @@ -706,6 +729,7 @@ config ARCH_S5PC1XX
[PATCH v4 03/14] efi: Fix to use null handle to create new handle for efi_fmp_raw
When running the efidebug capsule disk-update command, the efi_fmp_raw
protocol installation is failed with 2 (EFI_INVALID_PARAMETER) as
below. This is because the code passes efi_root instaed of handle.
=> efidebug capsule disk-update
EFI: Call: efi_install_multiple_protocol_interfaces( &handle,
&efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
EFI: Entry efi_install_multiple_protocol_interfaces(fbaf5988)
EFI: Call: efi_install_protocol_interface( handle, protocol,
EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Entry efi_install_protocol_interface(fbaf5988,
86c77a67-0b97-4633-a187-49104d0685c7, 0, fbfa6ee8)
EFI: new handle fbb37520
EFI: Exit: efi_install_protocol_interface: 0
EFI: 0 returned by efi_install_protocol_interface( handle, protocol,
EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Exit: efi_install_multiple_protocol_interfaces: 0
EFI: 0 returned by efi_install_multiple_protocol_interfaces( &handle,
&efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
EFI: Call: efi_install_multiple_protocol_interfaces( &efi_root,
&efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
EFI: Entry efi_install_multiple_protocol_interfaces(fbfec648)
EFI: Call: efi_install_protocol_interface( handle, protocol,
EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Entry efi_install_protocol_interface(fbfec648,
86c77a67-0b97-4633-a187-49104d0685c7, 0, fbfa6f18)
EFI: handle fbaf8520
EFI: Exit: efi_install_protocol_interface: 2
EFI: 2 returned by efi_install_protocol_interface( handle, protocol,
EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Exit: efi_install_multiple_protocol_interfaces: 2
EFI: 2 returned by efi_install_multiple_protocol_interfaces( &efi_root,
&efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
Command failed, result=1
To fix this issue, pass the handle variable as same as the efi_fmp_fit
installation.
Signed-off-by: Masami Hiramatsu
---
lib/efi_loader/efi_capsule.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 6ee883d5b1..f038245c93 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -949,7 +949,7 @@ efi_status_t __weak arch_efi_load_capsule_drivers(void)
if (IS_ENABLED(CONFIG_EFI_CAPSULE_FIRMWARE_RAW)) {
handle = NULL;
ret = EFI_CALL(efi_install_multiple_protocol_interfaces(
- &efi_root,
+ &handle,
&efi_guid_firmware_management_protocol,
&efi_fmp_raw, NULL));
}
[PATCH v4 02/14] dm: pci: Skip setting VGA bridge bits if parent device is the host bus
Commit bbbcb5262839 ("dm: pci: Enable VGA address forwarding on bridges")
sets the VGA bridge bits by checking pplat->class, but if the parent
device is the pci host bus device, it can be skipped. Moreover, it
shouldn't access the pplat because the parent has different plat data.
Without this fix, "pci enum" command cause a synchronous abort.
pci_auto_config_devices: start
PCI Autoconfig: Bus Memory region: [7800-7fff],
Physical Memory [7800-7fffx]
PCI Autoconfig: Bus I/O region: [0-],
Physical Memory [77f0-77f0x]
pci_auto_config_devices: device pci_6:0.0
PCI Autoconfig: BAR 0, Mem, size=0x100, address=0x7800
bus_lower=0x7900
PCI Autoconfig: BAR 1, Mem, size=0x800, No room in resource, avail
start=7900 / size=800, need=800
PCI: Failed autoconfig bar 14
PCI Autoconfig: BAR 2, I/O, size=0x4, address=0x1000 bus_lower=0x1004
PCI Autoconfig: BAR 3, Mem, size=0x200, address=0x7a00
bus_lower=0x7c00
PCI Autoconfig: BAR 4, I/O, size=0x80, address=0x1080 bus_lower=0x1100
PCI Autoconfig: ROM, size=0x8, address=0x7c00 bus_lower=0x7c08
"Synchronous Abort" handler, esr 0x9606
elr: e002bd28 lr : e002bce8 (reloc)
elr: fff6fd28 lr : fff6fce8
x0 : 1041 x1 : 003e
x2 : ffb0f8c8 x3 : 0001
x4 : 0080 x5 :
x6 : fff718fc x7 : 000f
x8 : ffb0f238 x9 : 0008
x10: x11: 0010
x12: 0006 x13: 0001869f
x14: ffb0fcd0 x15: 0020
x16: fff71cc4 x17:
x18: ffb13d90 x19: ffb14320
x20: x21: ffb14090
x22: ffb0f8c8 x23: 0001
x24: ffb14c10 x25:
x26: x27:
x28: ffb14c70 x29: ffb0f830
Code: 52800843 52800061 52800e00 97ffcf65 (b9400280)
Resetting CPU ...
Signed-off-by: Masami Hiramatsu
Reviewed-by: Simon Glass
---
drivers/pci/pci-uclass.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 22a033e632..afe4f1974a 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -550,6 +550,9 @@ int pci_auto_config_devices(struct udevice *bus)
max_bus = ret;
sub_bus = max(sub_bus, max_bus);
+ if (dev_get_parent(dev) == bus)
+ continue;
+
pplat = dev_get_parent_plat(dev);
if (pplat->class == (PCI_CLASS_DISPLAY_VGA << 8))
set_vga_bridge_bits(dev);
[PATCH v4 01/14] ata: ahci-pci: Use scsi_ops to initialize ops
Without this fix, scsi-scan will cause a synchronous abort
when accessing ops->scan.
Signed-off-by: Masami Hiramatsu
Reviewed-by: Simon Glass
---
drivers/ata/ahci-pci.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/ata/ahci-pci.c b/drivers/ata/ahci-pci.c
index 11ec98b56f..b1d231e0f9 100644
--- a/drivers/ata/ahci-pci.c
+++ b/drivers/ata/ahci-pci.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
@@ -28,6 +29,7 @@ static const struct udevice_id ahci_pci_ids[] = {
U_BOOT_DRIVER(ahci_pci) = {
.name = "ahci_pci",
.id = UCLASS_AHCI,
+ .ops= &scsi_ops,
.of_match = ahci_pci_ids,
.bind = ahci_pci_bind,
.probe = ahci_pci_probe,
[PATCH v4 00/14] arm64: synquacer: Add SynQuacer/DeveloperBox support
Hi, Here is the 4th version of the series (including some fixes for build errors) to add SynQuacer/DeveloperBox 96board EE suport on U-Boot. This series includes not only DeveloperBox support but also some fixes for the issues which I faced while porting U-Boot on the DeveloperBox. First 3 patches are fixes, next 1 patch is a code cleanup for generic gpio for arm. The next 7 patches adding DeveloperBox devices and board support. The last 3 patches are related to the UEFI capsule update (including bugfixes). Previous version is here: https://lists.denx.de/pipermail/u-boot/2021-May/449305.html Changes in v4 - I dropped a PCI bugfix because it has been merged. And add I2C driver and enable RTC and EBBR support on the configuration. [06/14]: - Add Jaehoon's reviewed-by (Thanks!) [09/14]: - Add a new i2c driver. [10/14]: - Add i2c0 and RTC node. [11/14]: - Add I2C and RTC configuration. - Enable RTC and Date command. - Remove I2C0 node before booting linux to hide it same as EDK2 does. - Add some configurations to make it EBBR compliant. [14/14]: - Add some config options for EBBR. BTW, should I split fixes from this series? (since I didn't expect this took so long...) DeveloperBox DeveloperBox is a certified 96boards Enterprise Edition board. The board/SoC has: - * Socionext SC2A11 24-cores ARM Cortex-A53 on tbe Mini-ATX form factor motherboard * 4 DIMM slots (4GB DDR4-2400 UDIMM shipped by default) * 1 4xPCIe Gen2 slot and 2 1xPCIe Gen2 slots (1x slots are connected via PCIe bridge chip) * 4 USB-3.0 ports * 2 SATA ports * 1 GbE network port * 1 USB-UART serial port (micro USB) * 64MB SPI NOR Flash * 8GB eMMC Flash Storage * 96boards LS connector The DeveloperBox schematic can be found here: - https://www.96boards.org/documentation/enterprise/developerbox/hardware-docs/mzsc2am_v03_20180115_a.pdf And the other documents can be found here: - https://www.96boards.org/documentation/enterprise/developerbox/ Currently, the U-Boot port supports: - * USB * eMMC * SPI-NOR * SATA * GbE The DeveloperBox boots the TF-A and EDK2 as a main bootloader by default. The DeveloperBox U-Boot port will replace the EDK2 and boot from TF-A as BL33, but no need to combine with it. Thank you, --- Jassi Brar (4): mmc: synquacer: Add SynQuacer F_SDH30 SDHCI driver spi: synquacer: Add HSSPI SPI controller driver for SynQuacer net: synquacer: Add netsec driver i2c: synquacer: SNI Synquacer I2C controller Masami Hiramatsu (10): ata: ahci-pci: Use scsi_ops to initialize ops dm: pci: Skip setting VGA bridge bits if parent device is the host bus efi: Fix to use null handle to create new handle for efi_fmp_raw gpio: Introduce CONFIG_GPIO_EXTRA_HEADER to cleanup #ifdefs pci: synquacer: Add SynQuacer ECAM based PCIe driver ARM: dts: synquacer: Add device trees for DeveloperBox board: synquacer: Add DeveloperBox 96boards EE support dfu_mtd: Ignore non-implemented lock device failure doc: qemu: arm64: Fix the documentation of capsule update configs: synquacer: Enable EFI capsule update support arch/arm/Kconfig | 108 ++ arch/arm/dts/Makefile |2 arch/arm/dts/synquacer-sc2a11-caches.dtsi | 73 + .../dts/synquacer-sc2a11-developerbox-u-boot.dtsi | 75 + arch/arm/dts/synquacer-sc2a11-developerbox.dts | 56 + arch/arm/dts/synquacer-sc2a11.dtsi | 595 ++ arch/arm/include/asm/gpio.h|8 board/socionext/developerbox/Kconfig | 36 + board/socionext/developerbox/MAINTAINERS | 14 board/socionext/developerbox/Makefile |9 board/socionext/developerbox/developerbox.c| 146 +++ configs/synquacer_developerbox_defconfig | 131 ++ doc/board/emulation/qemu_capsule_update.rst| 11 doc/board/index.rst|1 doc/board/socionext/developerbox.rst | 87 ++ doc/board/socionext/index.rst |9 drivers/ata/ahci-pci.c |2 drivers/dfu/dfu_mtd.c |2 drivers/i2c/Kconfig|7 drivers/i2c/Makefile |1 drivers/i2c/synquacer_i2c.c| 338 ++ drivers/mmc/Kconfig| 10 drivers/mmc/Makefile |1 drivers/mmc/f_sdh30.c | 81 + drivers/net/Kconfig|8 drivers/net/Makefile |1 drivers/net/sni_netsec.c | 1134 drivers/pci/Kconfig| 12 drivers/pci/Makefile |1 drivers/pci/pc
Re: [PATCH] powerpc: fix regression in arch_initr_trap()
On Tue, 18 May 2021 01:50:56 -0400
"Stefan Roese" wrote:
> Hi Matt,
>
> On 17.05.21 19:32, Matt Merhar wrote:
> > The assembly output of the arch_initr_trap() function differed by a
> > single byte after common.h was removed from traps.c:
> >
> > fff49a18 :
> > fff49a18: 94 21 ff f0 stwur1,-16(r1)
> > fff49a1c: 7c 08 02 a6 mflrr0
> > fff49a20: 90 01 00 14 stw r0,20(r1)
> > -fff49a24: 80 62 00 44 lwz r3,68(r2)
> > +fff49a24: 80 62 00 38 lwz r3,56(r2)
> > fff49a28: 4b ff 76 19 bl fff41040
> > fff49a2c: 80 01 00 14 lwz r0,20(r1)
> > fff49a30: 38 60 00 00 li r3,0
> > fff49a34: 38 21 00 10 addir1,r1,16
> > fff49a38: 7c 08 03 a6 mtlrr0
> >
> > This was causing a consistent hard lockup during the MMC read /
> > loading of the QoriQ FMan firmware on a P2041RDB board.
> >
> > Re-adding the header causes identical assembly to be emitted and
> > allows the firmware loading and subsequent boot to succeed.
> >
> > Fixes: 401d1c4f5d ("common: Drop asm/global_data.h from common
> > header") Signed-off-by: Matt Merhar
>
> Did you try to investigate what exactly causes this difference in the
> assembly code, when the header is not included? Re-adding this header
> seems like "papering over" the real problem to me.
As Rasmus helpfully pointed out, the global_data struct has a different
layout depending on whether CONFIG_POST is defined.
In this case, CONFIG_POST is inconsistently defined depending on which
headers are included by the various bits that reference that struct.
For the P2041RDB, the define now comes in like:
common.h ->
config.h ->
configs/P2041RDB.h ->
#define CONFIG_POST CONFIG_SYS_POST_MEMORY
Would it help to clarify this in the commit message? Would it be better
to include config.h instead of common.h? I could resend the patch with
either or both changes. CONFIG_POST seems to only be defined in a
handful of headers in include/configs/.
>
> Thanks,
> Stefan
>
> > ---
> >
> > arch/powerpc/lib/traps.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/powerpc/lib/traps.c b/arch/powerpc/lib/traps.c
> > index c7bce82a44..ab8ca269a5 100644
> > --- a/arch/powerpc/lib/traps.c
> > +++ b/arch/powerpc/lib/traps.c
> > @@ -4,6 +4,7 @@
> >* Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> >*/
> >
> > +#include
> > #include
> > #include
> >
> >
>
>
> Viele Grüße,
> Stefan
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 1/1] sandbox: don't refer to symbol _init
On Wed, May 19, 2021 at 10:42 AM Heinrich Schuchardt wrote: > > GCC provides a symbol _init in crti.o on x86_64 and aarch64 but not on > RISC-V. The following lines leads to a build error for sandbox_defconfig on > RISC_V due to the missing symbol: typo: RISC-V > > common/board_f.c:269: > #elif defined(CONFIG_SANDBOX) || defined(CONFIG_EFI_APP) > gd->mon_len = (ulong)&_end - (ulong)_init; > > The sandbox code is not copied into the memory allocated using mmap(). > Hence we can safely use gd->mon_len = 0 to avoid the reference to _init. > > Signed-off-by: Heinrich Schuchardt > --- > common/board_f.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
[PATCH 1/1] sandbox: don't refer to symbol _init
GCC provides a symbol _init in crti.o on x86_64 and aarch64 but not on
RISC-V. The following lines leads to a build error for sandbox_defconfig on
RISC_V due to the missing symbol:
common/board_f.c:269:
#elif defined(CONFIG_SANDBOX) || defined(CONFIG_EFI_APP)
gd->mon_len = (ulong)&_end - (ulong)_init;
The sandbox code is not copied into the memory allocated using mmap().
Hence we can safely use gd->mon_len = 0 to avoid the reference to _init.
Signed-off-by: Heinrich Schuchardt
---
common/board_f.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index 203e965799..c1b8e63e56 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -265,7 +265,9 @@ static int setup_mon_len(void)
{
#if defined(__ARM__) || defined(__MICROBLAZE__)
gd->mon_len = (ulong)&__bss_end - (ulong)_start;
-#elif defined(CONFIG_SANDBOX) || defined(CONFIG_EFI_APP)
+#elif defined(CONFIG_SANDBOX)
+ gd->mon_len = 0;
+#elif defined(CONFIG_EFI_APP)
gd->mon_len = (ulong)&_end - (ulong)_init;
#elif defined(CONFIG_NIOS2) || defined(CONFIG_XTENSA)
gd->mon_len = CONFIG_SYS_MONITOR_LEN;
--
2.30.2
Re: [PATCH 1/1] sandbox: add symbol _init for RISC-V compilation
On 5/18/21 11:36 PM, Jim Wilson wrote: On Tue, May 18, 2021 at 2:32 PM Jim Wilson mailto:j...@sifive.com>> wrote: On Tue, May 18, 2021 at 1:58 PM Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote: I am compiling the sandbox_defconfig target of upstream U-Boot with GCC 11. Please, indicate what "legacy user code" you are referring to. I have no idea what that is. I'm not a uboot developer. By "user code" I mean that it isn't toolchain code, as the toolchain doesn't use init. Jim This seems to be the culprit: common/board_f.c:269: #elif defined(CONFIG_SANDBOX) || defined(CONFIG_EFI_APP) gd->mon_len = (ulong)&_end - (ulong)_init; gd->mon_len is used here: common/board_f.c:344 gd->ram_top = board_get_usable_ram_top(gd->mon_len); @Simon: We don't relocate the sandbox code into the mmap'ed memory. Why should we use a nonzero value of gd->mon_len on the sandbox? When compiling the sandbox on x86_64 u-boot.map has: .init 0x00031000 0x17 *(SORT_NONE(.init)) .init 0x00031000 0x12 /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crti.o 0x00031000_init .init 0x000310120x5 /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crtn.o This relates to https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/i386/crti.S This file defines symbols _init and _fini. For aarch64 we have: https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/aarch64/crti.S This file contains symbols _init and _fini, too. For RISC-V we have: https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/riscv/crti.S It contains only a comment /* crti.S is empty because .init_array/.fini_array are used exclusively. */ Symbols _init and _fini don't exist on RISC-V. As the usage of _init is deprecated in GCC we should not use it in any U-Boot configuration, neither for SANDBOX nor for EFI_APP. Best regards Heinrich
Re: [PATCH 1/1] sandbox: add symbol _init for RISC-V compilation
Hi Jim, On Wed, May 19, 2021 at 5:36 AM Jim Wilson wrote: > > On Tue, May 18, 2021 at 2:32 PM Jim Wilson wrote: >> >> On Tue, May 18, 2021 at 1:58 PM Heinrich Schuchardt >> wrote: >>> >>> I am compiling the sandbox_defconfig target of upstream U-Boot with GCC >>> 11. Please, indicate what "legacy user code" you are referring to. >> >> >> I have no idea what that is. I'm not a uboot developer. > > > By "user code" I mean that it isn't toolchain code, as the toolchain doesn't > use init. Heinrich was using a GCC natively (not cross-compile) on a RISC-V board to build a "user code" and unfortunately it did not build. Do you think this might be related to how GCC was configured for native RISC-V? Regards, Bin
[PATCH] arm: Remove nokia_rx51 board
This board has not been converted to CONFIG_DM_USB by the deadline. Remove it. Cc: Pali Rohár Signed-off-by: Tom Rini --- I assume you'll be trying to fix this so I've not removed all of the test related scripts. --- .azure-pipelines.yml | 13 - .gitlab-ci.yml| 7 - arch/arm/mach-omap2/omap3/Kconfig | 4 - board/nokia/rx51/Kconfig | 12 - board/nokia/rx51/MAINTAINERS | 8 - board/nokia/rx51/Makefile | 7 - board/nokia/rx51/lowlevel_init.S | 196 board/nokia/rx51/rx51.c | 724 -- board/nokia/rx51/tag_omap.h | 294 configs/nokia_rx51_defconfig | 69 --- doc/README.nokia_rx51 | 94 include/configs/nokia_rx51.h | 249 -- test/nokia_rx51_test.sh | 296 13 files changed, 1973 deletions(-) delete mode 100644 board/nokia/rx51/Kconfig delete mode 100644 board/nokia/rx51/MAINTAINERS delete mode 100644 board/nokia/rx51/Makefile delete mode 100644 board/nokia/rx51/lowlevel_init.S delete mode 100644 board/nokia/rx51/rx51.c delete mode 100644 board/nokia/rx51/tag_omap.h delete mode 100644 configs/nokia_rx51_defconfig delete mode 100644 doc/README.nokia_rx51 delete mode 100644 include/configs/nokia_rx51.h delete mode 100755 test/nokia_rx51_test.sh diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 438139660219..90d5e4dc7244 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -160,19 +160,6 @@ jobs: # seems to hang forever with pre-configured "container" environment docker run -v $PWD:$(work_dir) $(ci_runner_image) /bin/bash $(work_dir)/build.sh - - job: nokia_rx51_test -displayName: 'Run tests for Nokia RX-51 (aka N900)' -pool: - vmImage: $(ubuntu_vm) -container: - image: $(ci_runner_image) - options: $(container_option) -steps: - - script: | - ./tools/buildman/buildman --fetch-arch arm - export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH - test/nokia_rx51_test.sh - - job: test_py displayName: 'test.py' pool: diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 5bf6f151b4fc..95aacdd9d74d 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -163,13 +163,6 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites: ./tools/patman/patman test; make testconfig -Run tests for Nokia RX-51 (aka N900): - stage: testsuites - script: -- ./tools/buildman/buildman --fetch-arch arm; - export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH; - test/nokia_rx51_test.sh - # Test sandbox with test.py sandbox test.py: variables: diff --git a/arch/arm/mach-omap2/omap3/Kconfig b/arch/arm/mach-omap2/omap3/Kconfig index 81c898b66e34..3c67a334d81c 100644 --- a/arch/arm/mach-omap2/omap3/Kconfig +++ b/arch/arm/mach-omap2/omap3/Kconfig @@ -105,9 +105,6 @@ config TARGET_OMAP3_LOGIC select OMAP3_GPIO_6 imply CMD_DM -config TARGET_NOKIA_RX51 - bool "Nokia RX51" - config TARGET_TAO3530 bool "TAO3530" select OMAP3_GPIO_2 @@ -160,7 +157,6 @@ source "board/timll/devkit8000/Kconfig" source "board/ti/evm/Kconfig" source "board/isee/igep00x0/Kconfig" source "board/logicpd/omap3som/Kconfig" -source "board/nokia/rx51/Kconfig" source "board/lg/sniper/Kconfig" endif diff --git a/board/nokia/rx51/Kconfig b/board/nokia/rx51/Kconfig deleted file mode 100644 index ec6a571a2263.. --- a/board/nokia/rx51/Kconfig +++ /dev/null @@ -1,12 +0,0 @@ -if TARGET_NOKIA_RX51 - -config SYS_BOARD - default "rx51" - -config SYS_VENDOR - default "nokia" - -config SYS_CONFIG_NAME - default "nokia_rx51" - -endif diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS deleted file mode 100644 index 58b16bf9a95c.. --- a/board/nokia/rx51/MAINTAINERS +++ /dev/null @@ -1,8 +0,0 @@ -RX51 BOARD -M: Pali Rohár -S: Maintained -F: board/nokia/rx51/ -F: include/configs/nokia_rx51.h -F: configs/nokia_rx51_defconfig -F: doc/README.nokia_rx51 -F: test/nokia_rx51_test.sh diff --git a/board/nokia/rx51/Makefile b/board/nokia/rx51/Makefile deleted file mode 100644 index 842f9e6a650e.. --- a/board/nokia/rx51/Makefile +++ /dev/null @@ -1,7 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0+ -# -# (C) Copyright 2000, 2001, 2002 -# Wolfgang Denk, DENX Software Engineering, w...@denx.de. - -obj-y := rx51.o -obj-y += lowlevel_init.o diff --git a/board/nokia/rx51/lowlevel_init.S b/board/nokia/rx51/lowlevel_init.S deleted file mode 100644 index 1466d976fc4b.. --- a/board/nokia/rx51/lowlevel_init.S +++ /dev/null @@ -1,196 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0+ */ -/* - * (C) Copyright 2011-2012 - * Pali Rohár - */ - -#include - -relocaddr: /* address of this relocaddr section after coping */ - .word . /* add
Re: [PATCH] Makefile: allow to override python3
On Sat, May 01, 2021 at 10:12:21PM +0200, Andrey Zhizhikin wrote:
> Python3 taken from the PATH causes build issues when pylibfdt bindings are
> generated with Yocto SDK.
>
> Python3 provided as a part of SDK is not compatible with host Python3,
> therefore binding build breaks with following errors:
>
> scripts/dtc/pylibfdt/libfdt_wrap.c:154:11: fatal error: Python.h: No such
> file or directory
> 154 | # include
> | ^~
>
> Do not enforce the python3 from the PATH and make it conditionally-assigned
> so it can be overridden from outside of build system. Keep the default
> assignment to point to version that is taken from the PATH.
>
> Similar fix has been introduced in b48bfc74ee ("tools: allow to override
> python"), where conditional assignment is used for python executable to
> address similar build errors.
>
> Signed-off-by: Andrey Zhizhikin
> Cc: Simon Glass
> Fixes: e91610da7c ("kconfig: re-sync with Linux 4.17-rc4")
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] cli: slighly more clear error messages
On Tue, May 04, 2021 at 01:45:59AM -0700, peng.w...@smartm.com wrote: > This patch tries to distinguish two error messages. > > Signed-off-by: peng.w...@smartm.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] MAINTAINERS, git-mailrc: socfpga: Update email address for Ley Foon
On Wed, May 12, 2021 at 06:31:57PM +0800, Ley Foon Tan wrote: > My mail address doesn't work any longer, change to gmail. > > Signed-off-by: Ley Foon Tan Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Makefile: Handle building in a very old build directory
On Thu, May 06, 2021 at 07:32:23PM -0600, Simon Glass wrote: > Versions of U-Boot before 2014.01 created a symlink from include/asm to > the architecture-specific header directory. > > If an ARM board is build with that old version, then sandbox is built on > a more recent version (both with in-tree builds), the include/asm symlink > confuses the build system. It picks up the ARM headers when it should be > using the sandbox ones. > > Since 2014 U-Boot has only created a symlink inside the include/asm/ > directory and only for out-of-tree builds. So for in-tree builds it does > not expect to see an include/asm symlink. It is not removed by > 'make mrproper'. It does show up with 'git status' but is easy enough to > miss. > > Add include/asm to the files to remove with 'make mkproper'. For recent > U-Boot builds this has no effect, since include/asm is a directory, not a > file. If the include/asm symlink is there, it will be removed. > > Reported-by: Marek Szyprowski > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] psci: rename psci_features function
On Thu, May 06, 2021 at 05:34:27PM +0300, Igor Opaniuk wrote:
> From: Igor Opaniuk
>
> s/psci_features/request_psci_features/g for the case when both
> ARCH_SUPPORT_PSCI=y and ARM_PSCI_FW=y, that leads to these
> compilation issues:
>
> drivers/firmware/psci.c:69:12: error: conflicting types for 'psci_features'
>69 | static int psci_features(u32 psci_func_id)
> |^
> In file included from drivers/firmware/psci.c:23:
> ./arch/arm/include/asm/system.h:548:5: note: previous declaration of
> 'psci_features' was here
> 548 | s32 psci_features(u32 function_id, u32 psci_fid);
> | ^
>
> Tested-by: Alexandru Gagniuc
> Reported-by: Alexandru Gagniuc
> Fixes: b7135b034f ("psci: add features/reset2 support")
> Signed-off-by: Igor Opaniuk
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] sandbox: add symbol _init for RISC-V compilation
On Tue, May 18, 2021 at 2:32 PM Jim Wilson wrote: > On Tue, May 18, 2021 at 1:58 PM Heinrich Schuchardt > wrote: > >> I am compiling the sandbox_defconfig target of upstream U-Boot with GCC >> 11. Please, indicate what "legacy user code" you are referring to. >> > > I have no idea what that is. I'm not a uboot developer. > By "user code" I mean that it isn't toolchain code, as the toolchain doesn't use init. Jim
Re: [PATCH 1/1] sandbox: add symbol _init for RISC-V compilation
On Tue, May 18, 2021 at 1:58 PM Heinrich Schuchardt wrote: > I am compiling the sandbox_defconfig target of upstream U-Boot with GCC > 11. Please, indicate what "legacy user code" you are referring to. > I have no idea what that is. I'm not a uboot developer. Jim
Re: [PATCH 1/1] sandbox: add symbol _init for RISC-V compilation
On Thu, May 13, 2021 at 5:55 PM Bin Meng wrote: > On Fri, May 14, 2021 at 7:56 AM Simon Glass wrote: > > On Thu, 13 May 2021 at 08:46, Heinrich Schuchardt > wrote: > > > /usr/bin/ld: common/built-in.o: in function `bootdelay_process': > > > common/autoboot.c:335: undefined reference to `_init' > > > collect2: error: ld returned 1 exit status > > > make: *** [Makefile:1726: u-boot] Error 1 > In the ELF standard, .init sections were deprecated and replaced with .init_array sections in the early 1990s I think. It took some time for the toolchains to fully migrate from init to init_array, but by 2010 or so everyone was using init_array instead of init, with init support retained only for legacy code that hadn't been fixed to use init_array yet. Because RISC-V is a new target with no legacy code to support, we made the decision to drop support for the obsolete init section. Last I checked there are only two glibc targets that have no init section support, with the other one also being a new arch, like RISC-V. Same goes for the embedded target, so the RISC-V newlib port has no init section support also. It sounds like you have some legacy user code that hasn't been fixed yet to use init_array instead of init. Or maybe it is a program loader that supports both? In which case it should be extended to not use init on new targets that no longer support it. Init_array supports stack unwinding (aka C++ EH) and init doesn't, so init_array should always be preferred over init, unless you have a very old toolchain that lacks init_array support. Dropping init support from the RISC-V toolchain allows us to save some bytes of program code size, and save some cycles on program startup, which is good considering that this is a feature that we don't need anymore. Jim
Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
Hi Andrey,
On Sun, May 16, 2021 at 11:31 AM ZHIZHIKIN Andrey
wrote:
>
> Hello Ricardo,
>
> > -Original Message-
> > From: Ricardo Salveti
> > Sent: Friday, May 14, 2021 5:29 PM
> > To: Fabio Estevam
> > Cc: ZHIZHIKIN Andrey ; Peng Fan
> > (OSS) ; sba...@denx.de; u-boot@lists.denx.de; uboot-
> > i...@nxp.com; Ye Li ; vanessa.maeg...@foundries.io;
> > igor.opan...@foundries.io
> > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
> >
> >
> > Hi Fabio,
> >
> > On Fri, May 14, 2021 at 9:30 AM Fabio Estevam wrote:
> > >
> > > Hi Andrey,
> > >
> > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey
> > > wrote:
> > >
> > > > > Update PMIC to use PCA9540, the legacy board not supported by NXP
> > > >
> > > > This commit seems rather a "nuclear" to me, as de-facto it drops the
> > initialization of ROMH PMIC in
> > > > favor of PCA one, leaving all the previous board revisions not to be
> > > > properly
> > sourced.
> > > >
> > > > I know that there might be no intention to provide a support for earlier
> > revisions of i.MX8M Mini
> > > > EVKs from NXP, but providing no backward compatibility to those boards
> > which are still in use by
> > > > a lot of people for development purposes is highly undesirable either.
> > > >
> > > > TBH, I've tested this patch on the old EVK where ROMH PMIC is present,
> > > > and
> > apart from having some
> > > > error messages in SPL regarding the register writes - it does boots.
> > > > What
> > worries me the most though
> > > > is that DTS changes some voltage settings, which I'm not sure how the
> > > > SOC
> > would react on.
> > > >
> > > > To my opinion, this patch should either be complemented with the
> > mechanism to provide a
> > > > level of backward compatibility (where the PMIC can be dynamically
> > identified and instantiated),
> > > > or the separate implementation should be presented which would make the
> > old board type not to
> > > > be bootable at all if it is considered not to be supported any longer.
> > > > Or this
> > patch should be reverted
> > > > in an effort to come up with a solution which covers new revision
> > > > without
> > "damaging" the currently
> > > > integrated one.
> > > >
> > > > Fabio / Stefano,
> > > > Do you have any thoughts here on how this should be handled further,
> > considering the fact that the
> > > > backward compatibility of 2021.07 release is not kept for this board
> > > > type
> > across multiple revisions?
> > > >
> > > > I'd really like to get your opinion here as I do have those boards in
> > development and would need to
> > > > come up with the idea on what to do with them.
> > > >
> > > > Also, this should be taken care of in the Yocto, since there is only one
> > definition of the i.MX8MM EVK
> > > > machine which does not make any distinction regarding the revision.
> > >
> > > You bring a good point.
> > >
> > > What about adding a new defconfig to support the old imx8mm-evk with
> > > the Rohm PMIC?
> > >
> > > Then we could have imx8mm_evk_defconfig for the new version and
> > > imx8mm_evk_rohm_defconfig for the old one.
> > >
> > > What do you think?
> >
> > Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing i2c)
> > would work better?
>
> This might be solution given that there is an implementation in SPL which
> can be used to query I2C to determine the PMIC type and get it dynamically.
>
> I'm not aware if this functionality exist, I would need to search for the
> reference
> in the U-Boot tree for this.
>
> But still, as I previously replied to Fabio, it would still need to have 2
> separate
> entries in DTS for both PMICs, and SPL power_init_board(void) code should be
> extended to request the PMIC based on the type detected.
>
> I guess this can be done in 2 steps: first make the PMIC selection based on
> the
> config option in SPL, and then - replace it with dynamic query (if possible).
>
> >
> > Different configs would imply different builds and binaries, which is
> > a problem when trying to support a single build for both the old EVK
> > and EVKB (and the main difference is the PMIC, nothing really major).
>
> This is especially true for Yocto builds, but there would be a way to define
> separate U-Boot config based on the type, so having 2 separate config files
> would not be technically impossible to achieve.
>
> However, I totally agree with you - one build for both revisions would be the
> best solution here.
Just as a reference, Toradex has worked around this issue for their
imx8mmevk-based design by implementing the dynamic board rev selection in their
tree ("verdin-imx8mm: implement hardware version detection"). With this patch,
they use the same Uboot defconfig with two different dtbs being selected
at runtime in board.c.
We have implemented a similar logic in our tree and it worked for both EVK and
EVKB versions.
>
> >
> > I also share Andrey's concerns, as we do have several EVKs in hands,
> > and having one single build woul
[PATCH v2] arm: dts: k3-j721e: Fix up MAIN R5FSS cluster mode back to Split-mode
The default U-Boot environment variables and design are all set up for
both the MAIN R5FSS clusters to be in Split-mode. This is the setting
in v2021.01 U-Boot and the dt nodes are synched with the kernel binding
property names in commit 468ec2f3ef8f ("remoteproc: k3_r5: Sync to
upstreamed kernel DT property names") merged in v2021.04-rc2.
The modes for both the clusters got switched back to LockStep mode by
mistake in commit 70e167495ab2 ("arm: dts: k3-j721e: Sync Linux v5.11-rc6
dts into U-Boot") also in v2021.04-rc2. This throws the following warning
messages when early-booting the cores using default env variables,
k3_r5f_rproc r5f@5d0: Invalid op: Trying to start secondary core 7 in
lockstep mode
Load Remote Processor 3 with data@addr=0x8200 98484 bytes: Failed!
k3_r5f_rproc r5f@5f0: Invalid op: Trying to start secondary core 9 in
lockstep mode
Load Remote Processor 5 with data@addr=0x8200 98484 bytes: Failed!
Fix this by switching back both the clusters to the expected Split-mode.
Make this mode change in the u-boot specific dtsi file to avoid such
sync overrides in the future until the kernel dts is also switched to
Split-mode by default.
Fixes: 70e167495ab2 ("arm: dts: k3-j721e: Sync Linux v5.11-rc6 dts into U-Boot")
Reported-by: Minas Hambardzumyan
Signed-off-by: Suman Anna
---
v2:
- Move the cluster mode change from k3-j721e-main.dtsi to the u-boot
board dtsi file, k3-j721e-common-proc-board-u-boot.dtsi
- Update commit description citing the reason
v1:
http://patchwork.ozlabs.org/project/uboot/patch/20210514003603.13940-1-s-a...@ti.com/
arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 3384ed9f3a1e..fe095a6153ed 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -193,3 +193,11 @@
&mcu_fss0_ospi1_pins_default {
u-boot,dm-spl;
};
+
+&main_r5fss0 {
+ ti,cluster-mode = <0>;
+};
+
+&main_r5fss1 {
+ ti,cluster-mode = <0>;
+};
--
2.30.1
Re: [PATCH 1/1] sandbox: add symbol _init for RISC-V compilation
On 5/18/21 9:29 PM, Jim Wilson wrote: On Thu, May 13, 2021 at 5:55 PM Bin Meng mailto:bmeng...@gmail.com>> wrote: On Fri, May 14, 2021 at 7:56 AM Simon Glass mailto:s...@chromium.org>> wrote: > On Thu, 13 May 2021 at 08:46, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote: > > /usr/bin/ld: common/built-in.o: in function `bootdelay_process': > > common/autoboot.c:335: undefined reference to `_init' > > collect2: error: ld returned 1 exit status > > make: *** [Makefile:1726: u-boot] Error 1 In the ELF standard, .init sections were deprecated and replaced with .init_array sections in the early 1990s I think. It took some time for the toolchains to fully migrate from init to init_array, but by 2010 or so everyone was using init_array instead of init, with init support retained only for legacy code that hadn't been fixed to use init_array yet. Because RISC-V is a new target with no legacy code to support, we made the decision to drop support for the obsolete init section. Last I checked there are only two glibc targets that have no init section support, with the other one also being a new arch, like RISC-V. Same goes for the embedded target, so the RISC-V newlib port has no init section support also. It sounds like you have some legacy user code that hasn't been fixed yet to use init_array instead of init. Or maybe it is a program loader that supports both? In which case it should be extended to not use init on new targets that no longer support it. I am compiling the sandbox_defconfig target of upstream U-Boot with GCC 11. Please, indicate what "legacy user code" you are referring to. Best regards Heinrich Init_array supports stack unwinding (aka C++ EH) and init doesn't, so init_array should always be preferred over init, unless you have a very old toolchain that lacks init_array support. Dropping init support from the RISC-V toolchain allows us to save some bytes of program code size, and save some cycles on program startup, which is good considering that this is a feature that we don't need anymore. Jim
Re: [PATCH] efi_loader: capsule: remove unused guid
On 5/10/21 10:20 AM, AKASHI Takahiro wrote:
EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID is never used.
Just remove it.
Signed-off-by: AKASHI Takahiro
---
lib/efi_loader/efi_capsule.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 84ddaf50d13f..b0dffd3ac9ce 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -208,9 +208,6 @@ skip:
#if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
-const efi_guid_t efi_guid_capsule_root_cert_guid =
- EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
-
I see multiple usages in origin/master. What am I missing?
$ git grep -n -B1 EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID
include/efi_api.h-228-
include/efi_api.h:229:#define EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID \
--
lib/efi_loader/efi_capsule.c-22-static const efi_guid_t
efi_guid_firmware_management_capsule_id =
lib/efi_loader/efi_capsule.c:23:
EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
--
lib/efi_loader/efi_capsule.c-208-const efi_guid_t
efi_guid_capsule_root_cert_guid =
lib/efi_loader/efi_capsule.c:209:
EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
--
tools/mkeficapsule.c-43-
tools/mkeficapsule.c:44:efi_guid_t efi_guid_fm_capsule =
EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
Best regards
Heinrich
#if defined(CONFIG_EFI_PKEY_DTB_EMBED)
int efi_get_public_key_data(void **pkey, efi_uintn_t *pkey_len)
{
RE: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
Hello Vanessa, > -Original Message- > From: Vanessa Maegima > Sent: Tuesday, May 18, 2021 3:15 PM > To: ZHIZHIKIN Andrey > Cc: Ricardo Salveti ; Fabio Estevam > ; Peng Fan (OSS) ; > sba...@denx.de; u-boot@lists.denx.de; uboot-...@nxp.com; Ye Li > ; igor.opan...@foundries.io > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board > > > Hi Andrey, > > On Sun, May 16, 2021 at 11:31 AM ZHIZHIKIN Andrey geosystems.com> wrote: > > > > Hello Ricardo, > > > > > -Original Message- > > > From: Ricardo Salveti > > > Sent: Friday, May 14, 2021 5:29 PM > > > To: Fabio Estevam > > > Cc: ZHIZHIKIN Andrey ; Peng > > > Fan > > > (OSS) ; sba...@denx.de; u-boot@lists.denx.de; > > > uboot- i...@nxp.com; Ye Li ; > > > vanessa.maeg...@foundries.io; igor.opan...@foundries.io > > > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk > > > board > > > > > > > > > Hi Fabio, > > > > > > On Fri, May 14, 2021 at 9:30 AM Fabio Estevam > wrote: > > > > > > > > Hi Andrey, > > > > > > > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey > > > > wrote: > > > > > > > > > > Update PMIC to use PCA9540, the legacy board not supported by > > > > > > NXP > > > > > > > > > > This commit seems rather a "nuclear" to me, as de-facto it drops > > > > > the > > > initialization of ROMH PMIC in > > > > > favor of PCA one, leaving all the previous board revisions not > > > > > to be properly > > > sourced. > > > > > > > > > > I know that there might be no intention to provide a support for > > > > > earlier > > > revisions of i.MX8M Mini > > > > > EVKs from NXP, but providing no backward compatibility to those > > > > > boards > > > which are still in use by > > > > > a lot of people for development purposes is highly undesirable either. > > > > > > > > > > TBH, I've tested this patch on the old EVK where ROMH PMIC is > > > > > present, and > > > apart from having some > > > > > error messages in SPL regarding the register writes - it does > > > > > boots. What > > > worries me the most though > > > > > is that DTS changes some voltage settings, which I'm not sure > > > > > how the SOC > > > would react on. > > > > > > > > > > To my opinion, this patch should either be complemented with the > > > mechanism to provide a > > > > > level of backward compatibility (where the PMIC can be > > > > > dynamically > > > identified and instantiated), > > > > > or the separate implementation should be presented which would > > > > > make the > > > old board type not to > > > > > be bootable at all if it is considered not to be supported any > > > > > longer. Or this > > > patch should be reverted > > > > > in an effort to come up with a solution which covers new > > > > > revision without > > > "damaging" the currently > > > > > integrated one. > > > > > > > > > > Fabio / Stefano, > > > > > Do you have any thoughts here on how this should be handled > > > > > further, > > > considering the fact that the > > > > > backward compatibility of 2021.07 release is not kept for this > > > > > board type > > > across multiple revisions? > > > > > > > > > > I'd really like to get your opinion here as I do have those > > > > > boards in > > > development and would need to > > > > > come up with the idea on what to do with them. > > > > > > > > > > Also, this should be taken care of in the Yocto, since there is > > > > > only one > > > definition of the i.MX8MM EVK > > > > > machine which does not make any distinction regarding the revision. > > > > > > > > You bring a good point. > > > > > > > > What about adding a new defconfig to support the old imx8mm-evk > > > > with the Rohm PMIC? > > > > > > > > Then we could have imx8mm_evk_defconfig for the new version and > > > > imx8mm_evk_rohm_defconfig for the old one. > > > > > > > > What do you think? > > > > > > Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing > > > i2c) would work better? > > > > This might be solution given that there is an implementation in SPL > > which can be used to query I2C to determine the PMIC type and get it > dynamically. > > > > I'm not aware if this functionality exist, I would need to search for > > the reference in the U-Boot tree for this. > > > > But still, as I previously replied to Fabio, it would still need to > > have 2 separate entries in DTS for both PMICs, and SPL > > power_init_board(void) code should be extended to request the PMIC based > on the type detected. > > > > I guess this can be done in 2 steps: first make the PMIC selection > > based on the config option in SPL, and then - replace it with dynamic query > > (if > possible). > > > > > > > > Different configs would imply different builds and binaries, which > > > is a problem when trying to support a single build for both the old > > > EVK and EVKB (and the main difference is the PMIC, nothing really major). > > > > This is especially true for Yocto builds, but there would be a way to > > define separate U-Boot config based on the type, so having 2 separa
Re: Pull request for efi-2021-07-rc3
On Tue, May 18, 2021 at 05:09:04PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit feddbdb55f47b94f9f6695dc19a826953f893f7a: > > Merge https://source.denx.de/u-boot/custodians/u-boot-marvell > (2021-05-17 10:01:56 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2021-07-rc3 > > for you to fetch changes up to 87316da05f2fd49d3709275e64ef0c5980366ade: > > lib: introduce HASH_CALCULATE option (2021-05-18 12:36:13 +0200) > > Gitlab CI showed no issues: > > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/7574 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-riscv/master
On Tue, May 18, 2021 at 09:48:43AM +0800, Leo Liang wrote: > Hi Tom, > > CI result: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/7572 > > The following changes since commit e644dfbb1786a4a3308b068e1f61cd9e2dfac237: > > configs: Resync with savedefconfig (2021-05-15 08:10:13 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to 89419279f4fe6bfd68dd518059ef2007295f1cb4: > > riscv: Group assembly optimized implementation of memory routines into a > submenu (2021-05-17 16:47:33 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] pinctrl: single: Fix probe failure getting register area size
Hi,
> Il 17/05/2021 22:15 Tom Rini ha scritto:
>
>
> On Fri, May 07, 2021 at 02:40:34PM +0530, Vignesh Raghavendra wrote:
>
> > If reg property of pinctrl-single node requires address translation then
> > probe fails with following message:
> >
> > single-pinctrl pinctrl@4301c000: failed to get base register size
> >
> > This is because driver uses dev_read_addr_size() to get size which also
> > tries to fetch untranslated addr and fails.
> > Fix this by using dev_read_addr_size_index() which takes care of address
> > translation and also makes following dev_read_addr() call redundant.
> >
> > This fixes Ethernet failures on TI's AM654 based EVMs due to lack of
> > pinmux configuration.
> >
> > Fixes: 9fd8a430f3 ("pinctrl: single: get register area size by device API")
> > Signed-off-by: Vignesh Raghavendra
> > ---
> > drivers/pinctrl/pinctrl-single.c | 10 ++
> > 1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/pinctrl/pinctrl-single.c
> > b/drivers/pinctrl/pinctrl-single.c
> > index ebb7602dde..7af6c5f0b0 100644
> > --- a/drivers/pinctrl/pinctrl-single.c
> > +++ b/drivers/pinctrl/pinctrl-single.c
> > @@ -509,19 +509,13 @@ static int single_of_to_plat(struct udevice *dev)
> > return -EINVAL;
> > }
> >
> > - addr = dev_read_addr_size(dev, "reg", &size);
> > + addr = dev_read_addr_size_index(dev, 0, &size);
> > if (addr == FDT_ADDR_T_NONE) {
> > - dev_err(dev, "failed to get base register size\n");
> > + dev_err(dev, "failed to get base register address\n");
> > return -EINVAL;
> > }
> >
> > pdata->offset = size - pdata->width / BITS_PER_BYTE;
> > -
> > - addr = dev_read_addr(dev);
> > - if (addr == FDT_ADDR_T_NONE) {
> > - dev_dbg(dev, "no valid base register address\n");
> > - return -EINVAL;
> > - }
> > pdata->base = addr;
> >
> > ret = dev_read_u32(dev, "pinctrl-single,function-mask", &pdata->mask);
>
> Dario, since this has a fixes tag for a commit of yours, comments?
> Thanks!
>
I applied the patch and tested it on my beaglebone black.
It is OK. As well the tests I had developed in the sandbox configuration for
pinmux passed.
Thanks and regards,
Dario
> --
> Tom
Pull request for efi-2021-07-rc3
Dear Tom, The following changes since commit feddbdb55f47b94f9f6695dc19a826953f893f7a: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2021-05-17 10:01:56 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2021-07-rc3 for you to fetch changes up to 87316da05f2fd49d3709275e64ef0c5980366ade: lib: introduce HASH_CALCULATE option (2021-05-18 12:36:13 +0200) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/7574 Pull request for efi-2021-07-rc3 Documentation: * add a man-page for the size command * add man-page for extension command to index Bug fixes: * avoid build failure due to missing SHA512 hardware acceleration * correct error handling in TCG2 protocol * don't let user disable capsule authentication * correct reading directories via UEFI API Heinrich Schuchardt (4): doc: man-page for size command doc: extension.rst missing in doc/usage/index.rst efi_loader: build warning in efi_tcg2_hash_log_extend_event hash: Kconfig option for SHA512 hardware acceleration Ilias Apalodimas (4): efi_loader: Clean up tcg2 once in case of failure efi_loader: Uninstall the TCG2 protocol if logging s-crtm fails efi_loader: Don't stop EFI subsystem init if installing TCG2 fails efi_loader: Fix Kconfig for EFI_TCG2 protocol Masahisa Kojima (1): lib: introduce HASH_CALCULATE option Peng Fan (1): efi_loader: loosen buffer parameter check in efi_file_read_int Sughosh Ganu (1): efi_loader: capsule: Remove the check for capsule_authentication_enabled environment variable board/emulation/common/qemu_capsule.c | 6 - common/Kconfig.boot | 1 + common/hash.c | 8 +++--- doc/usage/index.rst | 2 ++ doc/usage/size.rst| 40 + lib/Kconfig | 24 ++ lib/Makefile | 2 +- lib/efi_loader/Kconfig| 8 ++ lib/efi_loader/efi_file.c | 2 +- lib/efi_loader/efi_firmware.c | 5 ++-- lib/efi_loader/efi_tcg2.c | 47 --- 11 files changed, 110 insertions(+), 35 deletions(-) create mode 100644 doc/usage/size.rst
Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
Hi Leo, I just posted the patch for pcie_dw_common.c compilation error. Please check and see if it works. Thanks. Hi Bin and Leo, And I'll check the 'binman' patch series soon. See if we can have both binman and fu740 patchset ready. Regards, Green On Tue, May 18, 2021 at 9:12 PM Green Wan wrote: > As I mentioned before, pcie_dw_common.c is not part of fu740 patch. The > error is actually nothing to do with fu740 patchset. Even I fix those > warning message. It will not be in same patch series. > > - Green > > Leo Liang 於 2021年5月18日 週二，下午8:00寫道： > >> On Tue, May 18, 2021 at 05:56:08PM +0800, Bin Meng wrote: >> > Hi Green, >> > >> > On Tue, May 18, 2021 at 5:43 PM Green Wan wrote: >> > > >> > > >> > > >> > > On Tue, May 18, 2021 at 3:45 PM Bin Meng wrote: >> > >> >> > >> Hi Green, >> > >> >> > >> On Tue, May 18, 2021 at 3:38 PM Leo Liang >> wrote: >> > >> > >> > >> > On Fri, May 14, 2021 at 11:45:30AM +0800, Green Wan wrote: >> > >> > > Hi Bin, >> > >> > > >> > >> > > Thanks, I'll include that revert. Just traced back the git log. >> My original >> > >> > > patch is based on fu740. I guess it was merged to fu540 since >> fu740 series >> > >> > > wasn't present yet. >> > >> > > >> > >> > > Hi Rick, >> > >> > > >> > >> > > Not sure whether you'll pick fu740 series soon or if any parts >> need more >> > >> > > revisement. Do you prefer that I append both this revert and >> "disable CSR" >> > >> > > patch to fu740&unmatched patch series? If so, I will create v9 >> patch and >> > >> > > include these 2 patches. >> > >> > > >> > >> > > Or if you prefer to keep them separate from fu740 series, we can >> wait for >> > >> > > fu740&unmatche patch merge and I'll create a separate patch for >> this revert >> > >> > > and CSR disable. >> > >> > > >> > >> > > What do you think? Many thanks. >> > >> > > >> > >> > > Regards, >> > >> > > - Green >> > >> > > >> > >> > >> > >> > Hi Green, >> > >> > >> > >> > Could you please append the "disable CSR" patch to fu740 unmatched >> patch >> > >> > and send a v9 patch ? Thanks! >> > >> > >> > >> >> > >> I think you will need some update per this patch as well: >> > >> >> http://patchwork.ozlabs.org/project/uboot/patch/20210511120412.25065-1-bmeng...@gmail.com/ >> > > >> > > >> > > Hi Bin >> > > I updated the change to [patch v9 1/8]. Thanks, >> > > >> > >> >> > >> >> > >> >> > >> Hi Leo, >> > >> >> > >> What's your plan for the binman patch series? >> > >> >> > >> If the binman patch series go first, Green needs to update Unmatched >> > >> to use binman as well. >> > > >> > > >> > > Hi Leo/Bin, >> > > >> > > Are we referring to >> https://lists.denx.de/pipermail/u-boot/2021-May/448885.html? >> > >> > This one: http://patchwork.ozlabs.org/project/uboot/list/?series=242992 >> > >> > > I'd prefer to have a separated patch work to track binman changes. >> Thanks, >> > >> > Actually that's why I asked Leo the plan. If your patch go before my >> > patch, then I will need to do an additional patch to convert >> > unmatched. >> > >> > But if mine go first before yours, you will have to respin another >> > version to do the convert in the first place. >> > >> > Leo, please let us know your plan. >> > >> >> Hi Bin/Green, >> >> I was thinking picking Bin's patch first, >> because Green's patch could not pass CI. >> (Due to some format warning being treated as error >> when compiling drivers/pci/pcie_dw_common.c) >> >> At the meantime, we should come up with some fixes to pass CI. >> Then Green could send his patch with binman, >> or a seperate patch to track binman utility. >> >> What do you guys think? >> >> Best regards, >> Leo >> >> >> > Regards, >> > Bin >> >
Re: [PATCH v3] Fix flashing of eMMC user area with Fastboot
On 5/14/21 5:26 PM, Oleh Kravchenko wrote:
> Hello guys,
> Could you please review and merge this patch?
>
> PR successfully passed CI:
> https://github.com/u-boot/u-boot/pull/75
>
> 15.05.21 00:15, Oleh Kravchenko пише:
>> 'gpt' and 'mmc0' fastboot partitions have been treated as the same device,
>> but it is wrong.
>>
>> Signed-off-by: Oleh Kravchenko
>> Cc: Pantelis Antoniou
>> Cc: Marek Vasut
>> ---
>> Changes for v2:
>> - code cleanup;
>> Changes for v3:
>> - QA passed at https://github.com/u-boot/u-boot/pull/75;
>>
>> drivers/fastboot/fb_mmc.c | 25 -
>> 1 file changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
>> index 2f3837e559..647d3f6c1b 100644
>> --- a/drivers/fastboot/fb_mmc.c
>> +++ b/drivers/fastboot/fb_mmc.c
>> @@ -532,12 +532,7 @@ void fastboot_mmc_flash_write(const char *cmd, void
*download_buffer,
>> #endif
>>
>> #if CONFIG_IS_ENABLED(EFI_PARTITION)
>> -#ifndef CONFIG_FASTBOOT_MMC_USER_SUPPORT
>>if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
>> -#else
>> - if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0 ||
>> - strcmp(cmd, CONFIG_FASTBOOT_MMC_USER_NAME) == 0) {
>> -#endif
>>dev_desc = fastboot_mmc_get_dev(response);
>>if (!dev_desc)
>>return;
>> @@ -599,9 +594,29 @@ void fastboot_mmc_flash_write(const char *cmd, void
*download_buffer,
>>}
>> #endif
>>
>> +#if CONFIG_IS_ENABLED(FASTBOOT_MMC_USER_SUPPORT)
>> + if (strcmp(cmd, CONFIG_FASTBOOT_MMC_USER_NAME) == 0) {
>> + dev_desc = fastboot_mmc_get_dev(response);
>> + if (!dev_desc)
>> + return;
>> +
>> + memset(&info, 0, sizeof(info));
>> + info.start = 0;
>> + info.size = dev_desc->lba;
>> + info.blksz = dev_desc->blksz;
>> + strlcpy((char *)&info.name, cmd, sizeof(info.name));
>> +
>> + goto write_image;
>> + }
>> +#endif
>> +
>>if (fastboot_mmc_get_part_info(cmd, &dev_desc, &info, response) < 0)
>>return;
>>
>> +#if CONFIG_IS_ENABLED(FASTBOOT_MMC_USER_SUPPORT)
>> +write_image:
>> +#endif
>> +
This is still ugly; perhaps we can combine this with the above if statement.
E.g.
if (!info.size
&& fastboot_mmc_get_part_info(cmd, &dev_desc, &info, response) < 0)
return;
--Sean
>>if (is_sparse_image(download_buffer)) {
>>struct fb_mmc_sparse sparse_priv;
>>struct sparse_storage sparse;
>>
>
Re: [PATCH v3] Fix flashing of eMMC user area with Fastboot
Hello Tom, 18.05.21 16:40, Tom Rini пише: > On Tue, May 18, 2021 at 04:24:49PM +0300, Oleh Kravchenko wrote: >> Hello Tom, >> >> 18.05.21 15:21, Tom Rini пише: >>> On Tue, May 18, 2021 at 01:41:06PM +0300, Oleh Kravchenko wrote: >>> Any updates on these? >>> Sorry, my reading of what you and Sean were saying left me with the >>> impression no code changes were needed in the end, is that not the case? >> >> Sean has proposed to flash and erase by mapping through 0.0:0 (user), >> 0.1:0 (boot0), 0.2:0 (boot1). >> This works. >> >> But as I understand, we also can flash and erase eMMC hardware >> partitions by configuration defined labels: >> - CONFIG_FASTBOOT_MMC_BOOT1_NAME >> - CONFIG_FASTBOOT_MMC_BOOT2_NAME >> - CONFIG_FASTBOOT_MMC_USER_NAME >> Currently, this feature is broken, and these patches fix that. > > Ah, OK. And are both > https://patchwork.ozlabs.org/project/uboot/patch/20210514210620.24715-1-o...@kaa.org.ua/ > and > https://patchwork.ozlabs.org/project/uboot/patch/20210514211505.26722-1-o...@kaa.org.ua/ > relevant still or is the latter v3 of the former? Thanks. > Yes, they are still relevant. -- Best regards, Oleh Kravchenko
[PATCH] drivers: pci: pcie_dw_common: fix Werror compilation error
Fix compilation error when Werror is turned on. The warning could
possible break some CI builds.
Signed-off-by: Green Wan
---
drivers/pci/pcie_dw_common.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/pcie_dw_common.c b/drivers/pci/pcie_dw_common.c
index 785fd3aad0..fde7c36558 100644
--- a/drivers/pci/pcie_dw_common.c
+++ b/drivers/pci/pcie_dw_common.c
@@ -213,7 +213,7 @@ int pcie_dw_read_config(const struct udevice *bus,
pci_dev_t bdf,
va_address = set_cfg_address(pcie, bdf, offset);
- value = readl(va_address);
+ value = readl((void __iomem *)va_address);
debug("(addr,val)=(0x%04x, 0x%08lx)\n", offset, value);
*valuep = pci_conv_32_to_size(value, offset, size);
@@ -257,9 +257,9 @@ int pcie_dw_write_config(struct udevice *bus, pci_dev_t bdf,
va_address = set_cfg_address(pcie, bdf, offset);
- old = readl(va_address);
+ old = readl((void __iomem *)va_address);
value = pci_conv_size_to_32(old, value, offset, size);
- writel(value, va_address);
+ writel(value, (void __iomem *)va_address);
return pcie_dw_prog_outbound_atu_unroll(pcie, PCIE_ATU_REGION_INDEX1,
PCIE_ATU_TYPE_IO,
pcie->io.phys_start,
@@ -337,28 +337,28 @@ void pcie_dw_setup_host(struct pcie_dw *pci)
pci->cfg_base, pci->cfg_base + pci->cfg_size,
pci->cfg_size);
- dev_dbg(pci->dev, "IO space: [0x%llx - 0x%llx, size 0x%lx]\n",
+ dev_dbg(pci->dev, "IO space: [0x%llx - 0x%llx, size 0x%llx]\n",
pci->io.phys_start, pci->io.phys_start + pci->io.size,
pci->io.size);
- dev_dbg(pci->dev, "IO bus: [0x%lx - 0x%lx, size 0x%lx]\n",
+ dev_dbg(pci->dev, "IO bus: [0x%llx - 0x%llx, size 0x%llx]\n",
pci->io.bus_start, pci->io.bus_start + pci->io.size,
pci->io.size);
- dev_dbg(pci->dev, "MEM space: [0x%llx - 0x%llx, size 0x%lx]\n",
+ dev_dbg(pci->dev, "MEM space: [0x%llx - 0x%llx, size 0x%llx]\n",
pci->mem.phys_start, pci->mem.phys_start + pci->mem.size,
pci->mem.size);
- dev_dbg(pci->dev, "MEM bus: [0x%lx - 0x%lx, size 0x%lx]\n",
+ dev_dbg(pci->dev, "MEM bus: [0x%llx - 0x%llx, size 0x%llx]\n",
pci->mem.bus_start, pci->mem.bus_start + pci->mem.size,
pci->mem.size);
if (pci->prefetch.size) {
- dev_dbg(pci->dev, "PREFETCH space: [0x%llx - 0x%llx, size
0x%lx]\n",
+ dev_dbg(pci->dev, "PREFETCH space: [0x%llx - 0x%llx, size
0x%llx]\n",
pci->prefetch.phys_start, pci->prefetch.phys_start +
pci->prefetch.size,
pci->prefetch.size);
- dev_dbg(pci->dev, "PREFETCH bus: [0x%lx - 0x%lx, size
0x%lx]\n",
+ dev_dbg(pci->dev, "PREFETCH bus: [0x%llx - 0x%llx, size
0x%llx]\n",
pci->prefetch.bus_start, pci->prefetch.bus_start +
pci->prefetch.size,
pci->prefetch.size);
}
--
2.31.0
Re: [Uboot-stm32] [PATCH 2/2] cmd: pinmux: support pin name in status command
Hi Simon, On 5/6/21 5:02 PM, Simon Glass wrote: Hi Patrick, On Thu, 6 May 2021 at 02:38, Patrick DELAUNAY wrote: ... Any reason to prefer C test to python... I just complete the existing pinmux tests. For performance ? I wrote this up here: https://u-boot.readthedocs.io/en/latest/develop/tests_writing.html other pinmux tests in already python should be migrate also ? They may as well be, to the extent that they only run on sandbox. Regards, SImon I discover this page, it is clear now. And I will chaneg the test to C. Patrick
[PATCH 2/2] test: add dm_test_read_resource
Add a test of dev_read_resource with translation or without translation
Signed-off-by: Patrick Delaunay
---
test/dm/test-fdt.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index 9b771fdf19..b1736fbe27 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1165,3 +1166,35 @@ static int dm_test_decode_display_timing(struct
unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_decode_display_timing, UT_TESTF_SCAN_PDATA |
UT_TESTF_SCAN_FDT);
+
+/* Test read_resourcee() */
+static int dm_test_read_resource(struct unit_test_state *uts)
+{
+ struct udevice *dev;
+ struct resource res;
+
+ /* test resource without translation */
+ ut_assertok(uclass_find_device_by_name(UCLASS_SIMPLE_BUS, "syscon@2",
&dev));
+ ut_assertok(dev_read_resource(dev, 0, &res));
+ ut_asserteq(0x40, res.start);
+ ut_asserteq(0x44, res.end);
+ ut_assertok(dev_read_resource(dev, 1, &res));
+ ut_asserteq(0x48, res.start);
+ ut_asserteq(0x4D, res.end);
+
+ /* test resource with translation */
+ ut_assertok(uclass_find_device_by_name(UCLASS_TEST_DUMMY, "dev@1,100",
&dev));
+ ut_assertok(dev_read_resource(dev, 0, &res));
+ ut_asserteq(0x9000, res.start);
+ ut_asserteq(0x9FFF, res.end);
+
+ /* test named resource */
+ ut_assertok(uclass_find_device_by_name(UCLASS_TEST_DUMMY, "dev@0,0",
&dev));
+ ut_assertok(dev_read_resource_byname(dev, "sandbox-dummy-0", &res));
+ ut_asserteq(0x8000, res.start);
+ ut_asserteq(0x8FFF, res.end);
+
+ return 0;
+}
+
+DM_TEST(dm_test_read_resource, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
--
2.17.1
[PATCH 1/2] net: luton: remove address translation after ofnode_read_resource
Removed call of ofnode_translate_address() after ofnode_read_resource
in luton_switch.c:luton_probe(); it is unnecessary since
the commit feb7ac457c20 ("dm: core: Add address translation in
fdt_get_resource").
Fixes: feb7ac457c20 ("dm: core: Add address translation in fdt_get_resource")
Reported-by: Horatiu Vultur
Signed-off-by: Patrick Delaunay
---
drivers/net/mscc_eswitch/luton_switch.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/mscc_eswitch/luton_switch.c
b/drivers/net/mscc_eswitch/luton_switch.c
index 54afa14c9d..73c950d118 100644
--- a/drivers/net/mscc_eswitch/luton_switch.c
+++ b/drivers/net/mscc_eswitch/luton_switch.c
@@ -588,7 +588,6 @@ static int luton_probe(struct udevice *dev)
struct luton_private *priv = dev_get_priv(dev);
int i, ret;
struct resource res;
- fdt32_t faddr;
phys_addr_t addr_base;
unsigned long addr_size;
ofnode eth_node, node, mdio_node;
@@ -658,9 +657,7 @@ static int luton_probe(struct udevice *dev)
if (ofnode_read_resource(mdio_node, 0, &res))
return -ENOMEM;
- faddr = cpu_to_fdt32(res.start);
-
- addr_base = ofnode_translate_address(mdio_node, &faddr);
+ addr_base = res.start;
addr_size = res.end - res.start;
/* If the bus is new then create a new bus */
--
2.17.1
[PATCH 0/2] dm: core: Add address translation in fdt_get_resource - fixes
Hi, This serie push again 2 modifications proposed in previous serie V3 [1] but missing in master branch as only patchset V1 [2] is merged. Simon, I don't add your Reviewed-by, even you sent it for [1]. The first patch solves a issue see by horatiu.vul...@microchip.com in V1 [2]. Regards, Patrick [1] [v3] dm: core: Add address translation in fdt_get_resource http://patchwork.ozlabs.org/project/uboot/list/?series=242010&state=* [2] dm: core: Add address translation in fdt_get_resource http://patchwork.ozlabs.org/project/uboot/list/?series=237557&state=* Patrick Delaunay (2): net: luton: remove address translation after ofnode_read_resource test: add dm_test_read_resource drivers/net/mscc_eswitch/luton_switch.c | 5 +--- test/dm/test-fdt.c | 33 + 2 files changed, 34 insertions(+), 4 deletions(-) -- 2.17.1
Re: [PATCH v3] Fix flashing of eMMC user area with Fastboot
On Tue, May 18, 2021 at 04:24:49PM +0300, Oleh Kravchenko wrote: > Hello Tom, > > 18.05.21 15:21, Tom Rini пише: > > On Tue, May 18, 2021 at 01:41:06PM +0300, Oleh Kravchenko wrote: > > > >> Any updates on these? > > Sorry, my reading of what you and Sean were saying left me with the > > impression no code changes were needed in the end, is that not the case? > > Sean has proposed to flash and erase by mapping through 0.0:0 (user), > 0.1:0 (boot0), 0.2:0 (boot1). > This works. > > But as I understand, we also can flash and erase eMMC hardware > partitions by configuration defined labels: > - CONFIG_FASTBOOT_MMC_BOOT1_NAME > - CONFIG_FASTBOOT_MMC_BOOT2_NAME > - CONFIG_FASTBOOT_MMC_USER_NAME > Currently, this feature is broken, and these patches fix that. Ah, OK. And are both https://patchwork.ozlabs.org/project/uboot/patch/20210514210620.24715-1-o...@kaa.org.ua/ and https://patchwork.ozlabs.org/project/uboot/patch/20210514211505.26722-1-o...@kaa.org.ua/ relevant still or is the latter v3 of the former? Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3] Fix flashing of eMMC user area with Fastboot
Hello Tom,
18.05.21 15:21, Tom Rini пише:
> On Tue, May 18, 2021 at 01:41:06PM +0300, Oleh Kravchenko wrote:
>
>> Any updates on these?
> Sorry, my reading of what you and Sean were saying left me with the
> impression no code changes were needed in the end, is that not the case?
Sean has proposed to flash and erase by mapping through 0.0:0 (user),
0.1:0 (boot0), 0.2:0 (boot1).
This works.
But as I understand, we also can flash and erase eMMC hardware
partitions by configuration defined labels:
- CONFIG_FASTBOOT_MMC_BOOT1_NAME
- CONFIG_FASTBOOT_MMC_BOOT2_NAME
- CONFIG_FASTBOOT_MMC_USER_NAME
Currently, this feature is broken, and these patches fix that.
>> 15.05.21 00:26, Oleh Kravchenko пише:
>>> Hello guys,
>>> Could you please review and merge this patch?
>>>
>>> PR successfully passed CI:
>>> https://github.com/u-boot/u-boot/pull/75
>>>
>>> 15.05.21 00:15, Oleh Kravchenko пише:
'gpt' and 'mmc0' fastboot partitions have been treated as the same device,
but it is wrong.
Signed-off-by: Oleh Kravchenko
Cc: Pantelis Antoniou
Cc: Marek Vasut
---
Changes for v2:
- code cleanup;
Changes for v3:
- QA passed at https://github.com/u-boot/u-boot/pull/75;
drivers/fastboot/fb_mmc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 2f3837e559..647d3f6c1b 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -532,12 +532,7 @@ void fastboot_mmc_flash_write(const char *cmd, void
*download_buffer,
#endif
#if CONFIG_IS_ENABLED(EFI_PARTITION)
-#ifndef CONFIG_FASTBOOT_MMC_USER_SUPPORT
if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
-#else
- if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0 ||
- strcmp(cmd, CONFIG_FASTBOOT_MMC_USER_NAME) == 0) {
-#endif
dev_desc = fastboot_mmc_get_dev(response);
if (!dev_desc)
return;
@@ -599,9 +594,29 @@ void fastboot_mmc_flash_write(const char *cmd, void
*download_buffer,
}
#endif
+#if CONFIG_IS_ENABLED(FASTBOOT_MMC_USER_SUPPORT)
+ if (strcmp(cmd, CONFIG_FASTBOOT_MMC_USER_NAME) == 0) {
+ dev_desc = fastboot_mmc_get_dev(response);
+ if (!dev_desc)
+ return;
+
+ memset(&info, 0, sizeof(info));
+ info.start = 0;
+ info.size = dev_desc->lba;
+ info.blksz = dev_desc->blksz;
+ strlcpy((char *)&info.name, cmd, sizeof(info.name));
+
+ goto write_image;
+ }
+#endif
+
if (fastboot_mmc_get_part_info(cmd, &dev_desc, &info, response) < 0)
return;
+#if CONFIG_IS_ENABLED(FASTBOOT_MMC_USER_SUPPORT)
+write_image:
+#endif
+
if (is_sparse_image(download_buffer)) {
struct fb_mmc_sparse sparse_priv;
struct sparse_storage sparse;
Re: [PATCH v3] dm: core: Add address translation in fdt_get_resource
Hi Simon,
On 5/4/21 6:58 PM, Simon Glass wrote:
On Tue, 4 May 2021 at 04:02, Patrick Delaunay
wrote:
Today of_address_to_resource() is called only in
ofnode_read_resource() for livetree support and
fdt_get_resource() is called when livetree is not supported.
The fdt_get_resource() doesn't do the address translation
so when it is required, but the address translation is done
by ofnode_read_resource() caller, for example in
drivers/firmware/scmi/smt.c::scmi_dt_get_smt_buffer() {
...
ret = ofnode_read_resource(args.node, 0, &resource);
if (ret)
return ret;
faddr = cpu_to_fdt32(resource.start);
paddr = ofnode_translate_address(args.node, &faddr);
...
The both behavior should be aligned and the address translation
must be called in fdt_get_resource() and removed for each caller.
Fixes: a44810123f9e ("dm: core: Add dev_read_resource() to read device
resources")
Signed-off-by: Patrick Delaunay
---
This patch allows to remove the workaround in smci/smt.c
introduced by [1].
But it impact with all user of
- ofnode_read_resource
- ofnode_read_resource_byname
- dev_read_resource
- dev_read_resource_byname
After my first check, the only impacts are in drivers/net/mscc_eswitch
=> I remove the unnecessary translate after code review,
this patch need to be verify on real hardware
I proposed to merge the workaround [1] as soon as possible to avoid issue
on stm32mp1 platform and this patch can be merged when it will be acked
by mscc_eswitch maintainers and other API users.
[1] "scmi: translate the resource only when livetree is not activated"
http://patchwork.ozlabs.org/project/uboot/list/?series=236526&state=*
Changes in v3:
- add test dm_test_read_resource
Changes in v2:
- remove translate in luton_switch.c:luton_probe()
drivers/firmware/scmi/smt.c | 12 +
drivers/net/mscc_eswitch/jr2_switch.c | 4 +--
drivers/net/mscc_eswitch/luton_switch.c | 5 +---
drivers/net/mscc_eswitch/ocelot_switch.c | 4 +--
drivers/net/mscc_eswitch/serval_switch.c | 4 +--
drivers/net/mscc_eswitch/servalt_switch.c | 4 +--
lib/fdtdec.c | 6 -
test/dm/test-fdt.c| 33 +++
8 files changed, 44 insertions(+), 28 deletions(-)
Reviewed-by: Simon Glass
Thanks for the review of this v3...
But today I see that V1 is already merged in master branch
http://patchwork.ozlabs.org/project/uboot/list/?series=237557&state=*
I will sent a separate serie with only the changes introcuduced by V2 and
V3 and rebased on master branch.
Regards
Patrick
Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
As I mentioned before, pcie_dw_common.c is not part of fu740 patch. The error is actually nothing to do with fu740 patchset. Even I fix those warning message. It will not be in same patch series. - Green Leo Liang 於 2021年5月18日 週二，下午8:00寫道： > On Tue, May 18, 2021 at 05:56:08PM +0800, Bin Meng wrote: > > Hi Green, > > > > On Tue, May 18, 2021 at 5:43 PM Green Wan wrote: > > > > > > > > > > > > On Tue, May 18, 2021 at 3:45 PM Bin Meng wrote: > > >> > > >> Hi Green, > > >> > > >> On Tue, May 18, 2021 at 3:38 PM Leo Liang > wrote: > > >> > > > >> > On Fri, May 14, 2021 at 11:45:30AM +0800, Green Wan wrote: > > >> > > Hi Bin, > > >> > > > > >> > > Thanks, I'll include that revert. Just traced back the git log. > My original > > >> > > patch is based on fu740. I guess it was merged to fu540 since > fu740 series > > >> > > wasn't present yet. > > >> > > > > >> > > Hi Rick, > > >> > > > > >> > > Not sure whether you'll pick fu740 series soon or if any parts > need more > > >> > > revisement. Do you prefer that I append both this revert and > "disable CSR" > > >> > > patch to fu740&unmatched patch series? If so, I will create v9 > patch and > > >> > > include these 2 patches. > > >> > > > > >> > > Or if you prefer to keep them separate from fu740 series, we can > wait for > > >> > > fu740&unmatche patch merge and I'll create a separate patch for > this revert > > >> > > and CSR disable. > > >> > > > > >> > > What do you think? Many thanks. > > >> > > > > >> > > Regards, > > >> > > - Green > > >> > > > > >> > > > >> > Hi Green, > > >> > > > >> > Could you please append the "disable CSR" patch to fu740 unmatched > patch > > >> > and send a v9 patch ? Thanks! > > >> > > > >> > > >> I think you will need some update per this patch as well: > > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210511120412.25065-1-bmeng...@gmail.com/ > > > > > > > > > Hi Bin > > > I updated the change to [patch v9 1/8]. Thanks, > > > > > >> > > >> > > >> > > >> Hi Leo, > > >> > > >> What's your plan for the binman patch series? > > >> > > >> If the binman patch series go first, Green needs to update Unmatched > > >> to use binman as well. > > > > > > > > > Hi Leo/Bin, > > > > > > Are we referring to > https://lists.denx.de/pipermail/u-boot/2021-May/448885.html? > > > > This one: http://patchwork.ozlabs.org/project/uboot/list/?series=242992 > > > > > I'd prefer to have a separated patch work to track binman changes. > Thanks, > > > > Actually that's why I asked Leo the plan. If your patch go before my > > patch, then I will need to do an additional patch to convert > > unmatched. > > > > But if mine go first before yours, you will have to respin another > > version to do the convert in the first place. > > > > Leo, please let us know your plan. > > > > Hi Bin/Green, > > I was thinking picking Bin's patch first, > because Green's patch could not pass CI. > (Due to some format warning being treated as error > when compiling drivers/pci/pcie_dw_common.c) > > At the meantime, we should come up with some fixes to pass CI. > Then Green could send his patch with binman, > or a seperate patch to track binman utility. > > What do you guys think? > > Best regards, > Leo > > > > Regards, > > Bin >
[PATCH 10/10] stm32mp: stm32prog: handle dfu error
Handle DFU stack error in STM32CubeProgrammer protocol.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index ab687c272d..f7c93a1298 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -1783,3 +1783,17 @@ void dfu_initiated_callback(struct dfu_entity *dfu)
log_debug("dfu offset = 0x%llx\n", dfu->offset);
}
}
+
+void dfu_error_callback(struct dfu_entity *dfu, const char *msg)
+{
+ struct stm32prog_data *data = stm32prog_data;
+
+ if (!stm32prog_data)
+ return;
+
+ if (!stm32prog_data->cur_part)
+ return;
+
+ if (dfu->alt == stm32prog_data->cur_part->alt_id)
+ stm32prog_err(msg);
+}
--
2.17.1
[PATCH 09/10] dfu: add error callback
Add error callback in dfu stack to manage some board specific
behavior on DFU targets.
Signed-off-by: Patrick Delaunay
---
drivers/dfu/dfu.c | 12
include/dfu.h | 11 +++
2 files changed, 23 insertions(+)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 213a20e7bc..ff1859d946 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -44,6 +44,14 @@ __weak void dfu_initiated_callback(struct dfu_entity *dfu)
{
}
+/*
+ * The purpose of the dfu_error_callback() function is to
+ * provide callback for dfu user
+ */
+__weak void dfu_error_callback(struct dfu_entity *dfu, const char *msg)
+{
+}
+
/*
* The purpose of the dfu_usb_get_reset() function is to
* provide information if after USB_DETACH request
@@ -342,6 +350,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
printf("%s: Wrong sequence number! [%d] [%d]\n",
__func__, dfu->i_blk_seq_num, blk_seq_num);
dfu_transaction_cleanup(dfu);
+ dfu_error_callback(dfu, "Wrong sequence number");
return -1;
}
@@ -366,6 +375,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
ret = dfu_write_buffer_drain(dfu);
if (ret) {
dfu_transaction_cleanup(dfu);
+ dfu_error_callback(dfu, "DFU write error");
return ret;
}
}
@@ -375,6 +385,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
pr_err("Buffer overflow! (0x%p + 0x%x > 0x%p)\n", dfu->i_buf,
size, dfu->i_buf_end);
dfu_transaction_cleanup(dfu);
+ dfu_error_callback(dfu, "Buffer overflow");
return -1;
}
@@ -386,6 +397,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
ret = dfu_write_buffer_drain(dfu);
if (ret) {
dfu_transaction_cleanup(dfu);
+ dfu_error_callback(dfu, "DFU write error");
return ret;
}
}
diff --git a/include/dfu.h b/include/dfu.h
index d18b701728..1963e9ffb9 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -383,6 +383,17 @@ void dfu_initiated_callback(struct dfu_entity *dfu);
*/
void dfu_flush_callback(struct dfu_entity *dfu);
+/**
+ * dfu_error_callback() - weak callback called at the DFU write error
+ *
+ * It is a callback function called by DFU stack after DFU write error.
+ * This function allows to manage some board specific behavior on DFU targets
+ *
+ * @dfu: pointer to the dfu_entity which cause the error
+ * @msg: the message of the error
+ */
+void dfu_error_callback(struct dfu_entity *dfu, const char *msg);
+
int dfu_transaction_initiate(struct dfu_entity *dfu, bool read);
void dfu_transaction_cleanup(struct dfu_entity *dfu);
--
2.17.1
[PATCH 06/10] stm32mp: stm32prog: correctly handle DM_PMIC
Correctly handle number of alternate when DM_PMIC is not activated. This patch remove the last UNKNOWN partition in this case. Signed-off-by: Patrick Delaunay --- arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c index ea69d5dd16..ab687c272d 100644 --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c @@ -1150,7 +1150,10 @@ static int dfu_init_entities(struct stm32prog_data *data) struct dfu_entity *dfu; int alt_nb; - alt_nb = 3; /* number of virtual = CMD, OTP, PMIC*/ + alt_nb = 2; /* number of virtual = CMD, OTP*/ + if (CONFIG_IS_ENABLED(DM_PMIC)) + alt_nb++; /* PMIC NVMEM*/ + if (data->part_nb == 0) alt_nb++; /* +1 for FlashLayout */ else -- 2.17.1
[PATCH 07/10] stm32mp: stm32prog: use get_cpu_dev for GetID command
Use get_cpu_dev() in uart getID command and remove the defines
DEVICE_ID_BYTE1 and 2 defines.
This patch prepare the support for new SOC family.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
index 2550ae6a2b..7de62668fe 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -19,8 +20,7 @@
/* - configuration part -*/
#define USART_BL_VERSION 0x40/* USART bootloader version V4.0*/
#define UBOOT_BL_VERSION 0x03/* bootloader version V0.3*/
-#define DEVICE_ID_BYTE10x05/* MSB byte of device ID*/
-#define DEVICE_ID_BYTE20x00/* LSB byte of device ID*/
+
#define USART_RAM_BUFFER_SIZE 256 /* Size of USART_RAM_Buf buffer*/
/* - Commands -*/
@@ -436,10 +436,12 @@ static void get_version_command(struct stm32prog_data
*data)
*/
static void get_id_command(struct stm32prog_data *data)
{
+ u32 cpu = get_cpu_dev();
+
/* Send Device IDCode */
stm32prog_serial_putc(0x1);
- stm32prog_serial_putc(DEVICE_ID_BYTE1);
- stm32prog_serial_putc(DEVICE_ID_BYTE2);
+ stm32prog_serial_putc((cpu >> 8) & 0xFF);
+ stm32prog_serial_putc(cpu & 0xFF);
stm32prog_serial_result(ACK_BYTE);
}
--
2.17.1
[PATCH 08/10] stm32mp: stm32prog: change one message level to debug
Move the message "Invalid or missing layout file."
to debug level as it is a normal behavior and not an error
and add the missing '\n'.
This patch avoids the strange trace :
Boot over usb0!
Invalid or missing layout file.DFU alt info setting: done
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index f3790f900f..feff73c79e 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -99,7 +99,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, int
argc,
ret = stm32prog_init(data, addr, size);
if (ret)
- printf("Invalid or missing layout file.");
+ log_debug("Invalid or missing layout file at 0x%lx.\n", addr);
/* prepare DFU for device read/write */
ret = stm32prog_dfu_init(data);
--
2.17.1
[PATCH 04/10] stm32mp: stm32prog: solve compilation with CONFIG_FIT_SIGNATURE
When CONFIG_FIT_SIGNATURE is activated, CONFIG_LEGACY_IMAGE_FORMAT
is deactivated and the define IMAGE_FORMAT_LEGACY don't exist with
include/image.h:
#if defined(CONFIG_LEGACY_IMAGE_FORMAT)
#define IMAGE_FORMAT_LEGACY 0x01/* legacy image_header based format */
#endif
This patch adds the needed check on compilation flag
CONFIG_LEGACY_IMAGE_FORMAT to avoid the compilation error
for command stm32prog:
cmd_stm32prog.c:81:8: error: ‘IMAGE_FORMAT_LEGACY’ undeclared
(first use in this function); did you mean ‘IMAGE_FORMAT_FIT’?
81 |if (IMAGE_FORMAT_LEGACY ==
|^~~
|IMAGE_FORMAT_FIT
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index e584bb52bd..f3790f900f 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -77,10 +77,12 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
if (header.type == HEADER_STM32IMAGE) {
size = header.image_length + BL_HEADER_SIZE;
+#if defined(CONFIG_LEGACY_IMAGE_FORMAT)
/* uImage detected in STM32IMAGE, execute the script */
if (IMAGE_FORMAT_LEGACY ==
genimg_get_format((void *)(addr + BL_HEADER_SIZE)))
return image_source_script(addr +
BL_HEADER_SIZE, "script@1");
+#endif
}
}
--
2.17.1
[PATCH 00/10] stm32mp: stm32prog: several features and fixes
This serie provides several evolution and patches for the command stm32prog used on STM32MP platform to communicate with the STMicroelectonics tools STM32CubeProgrammer. Patrick Delaunay (10): stm32mp: stm32prog: remove all the header check for UART download stm32mp: stm32prog: add timeout in stm32prog_serial_get_buffer stm32mp: stm32prog: add support of initrd in flashlayout stm32mp: stm32prog: solve compilation with CONFIG_FIT_SIGNATURE stm32mp: stm32prog: handle the next phase after USB re-enumeration stm32mp: stm32prog: correctly handle DM_PMIC stm32mp: stm32prog: use get_cpu_dev for GetID command stm32mp: stm32prog: change one message level to debug dfu: add error callback stm32mp: stm32prog: handle dfu error .../cmd_stm32prog/cmd_stm32prog.c | 26 ++- .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 43 +++-- .../mach-stm32mp/cmd_stm32prog/stm32prog.h| 7 +- .../cmd_stm32prog/stm32prog_serial.c | 173 -- .../cmd_stm32prog/stm32prog_usb.c | 7 +- drivers/dfu/dfu.c | 12 ++ include/dfu.h | 11 ++ 7 files changed, 108 insertions(+), 171 deletions(-) -- 2.17.1
[PATCH 03/10] stm32mp: stm32prog: add support of initrd in flashlayout
Add the support in command stm32prog of kernel load and start
with initrd file, identify by the partition Type "Binary" in
the flashlayout.tsv, for example:
- 0x01 fsbl Binary none 0x0 tfa.stm32
- 0x03 fip Binary none 0x0 fip.bin
P 0x10 kernel System ram0 0xC200 uImage.bin
P 0x11 dtb FileSystem ram0 0xC400 board.dtb
P 0x12 initrd Binary ram0 0xC440
The file can be a legacy image "uInitrd", generated
with mkimage, or a RAW initrd image "initrd.gz".
After a DFU detach the bootm command with be executed
with the associated address, for example:
$> bootm 0xC200 0xC440: 0xC400
When the "Binary" partition type is absent, the 'bootm'
command starts the kernel without ramdisk, for example:
$> bootm 0xC200 - 0xC400
With this paths, it is no more mandatory to generate FIT
including the kernel, DT and initrd:
- 0x01 fsbl Binary none 0x0 tfa.stm32
- 0x03 fip Binary none 0x0 fip.bin
P 0x10 fit System ram0 0xC200 fit.bin
Signed-off-by: Patrick Delaunay
---
.../cmd_stm32prog/cmd_stm32prog.c | 22 +--
.../mach-stm32mp/cmd_stm32prog/stm32prog.c| 10 ++---
.../mach-stm32mp/cmd_stm32prog/stm32prog.h| 2 ++
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index e36501a86b..e584bb52bd 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -45,7 +45,6 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, int
argc,
bool reset = false;
struct image_header_s header;
struct stm32prog_data *data;
- u32 uimage, dtb;
if (argc < 3 || argc > 5)
return CMD_RET_USAGE;
@@ -119,21 +118,23 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
goto cleanup;
}
- uimage = data->uimage;
- dtb = data->dtb;
-
stm32prog_clean(data);
free(stm32prog_data);
stm32prog_data = NULL;
puts("Download done\n");
- if (uimage) {
+ if (data->uimage) {
char boot_addr_start[20];
char dtb_addr[20];
+ char initrd_addr[40];
char *bootm_argv[5] = {
"bootm", boot_addr_start, "-", dtb_addr, NULL
};
+ u32 uimage = data->uimage;
+ u32 dtb = data->dtb;
+ u32 initrd = data->initrd;
+
if (!dtb)
bootm_argv[3] = env_get("fdtcontroladdr");
else
@@ -142,8 +143,15 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
"0x%x", uimage);
- printf("Booting kernel at %s - %s...\n\n\n",
- boot_addr_start, bootm_argv[3]);
+
+ if (initrd) {
+ snprintf(initrd_addr, sizeof(initrd_addr) - 1,
"0x%x:0x%x",
+initrd, data->initrd_size);
+ bootm_argv[2] = initrd_addr;
+ }
+
+ printf("Booting kernel at %s %s %s...\n\n\n",
+ boot_addr_start, bootm_argv[2], bootm_argv[3]);
/* Try bootm for legacy and FIT format image */
if (genimg_get_format((void *)uimage) != IMAGE_FORMAT_INVALID)
do_bootm(cmdtp, 0, 4, bootm_argv);
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index 84b880261a..ea69d5dd16 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -1473,7 +1473,7 @@ error:
return ret;
}
-static void stm32prog_end_phase(struct stm32prog_data *data)
+static void stm32prog_end_phase(struct stm32prog_data *data, u64 offset)
{
if (data->phase == PHASE_FLASHLAYOUT) {
if (parse_flash_layout(data, STM32_DDR_BASE, 0))
@@ -1489,6 +1489,10 @@ static void stm32prog_end_phase(struct stm32prog_data
*data)
data->uimage = data->cur_part->addr;
if (data->cur_part->part_type == PART_FILESYSTEM)
data->dtb = data->cur_part->addr;
+ if (data->cur_part->part_type == PART_BINARY) {
+ data->initrd = data->cur_part->addr;
+ data->initrd_size = offset;
+ }
}
if (CONFIG_IS_ENABLED(MMC) &&
@@ -1747,7 +1751,7 @@ void dfu_flush_callback(struct dfu_entity *dfu)
if (dfu->dev_type == DFU_DEV_RAM) {
if (dfu->alt == 0 &&
stm32prog_data->phase == PHASE_FLASHLAYOUT) {
- stm32prog_end_phase(stm32prog_data);
+ stm32prog_end_phase(stm32prog_data, dfu->of
[PATCH 05/10] stm32mp: stm32prog: handle the next phase after USB re-enumeration
Handle the second USB enumeration only when the flashlayout is received
and when phase is PHASE_FLASHLAYOUT. This patch removes the call of
stm32prog_next_phase as it is already done in stm32prog_dfu_init().
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
index bc44d9fc8f..d4a3f7ea16 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
@@ -207,13 +207,10 @@ bool stm32prog_usb_loop(struct stm32prog_data *data, int
dev)
if (stm32prog_data->phase == PHASE_FLASHLAYOUT) {
ret = run_usb_dnl_gadget(dev, "usb_dnl_dfu");
- if (ret || stm32prog_data->phase == PHASE_DO_RESET)
+ if (ret || stm32prog_data->phase != PHASE_FLASHLAYOUT)
return ret;
/* prepare the second enumeration with the FlashLayout */
- if (stm32prog_data->phase == PHASE_FLASHLAYOUT)
- stm32prog_dfu_init(data);
- /* found next selected partition */
- stm32prog_next_phase(data);
+ stm32prog_dfu_init(data);
}
ret = run_usb_dnl_gadget(dev, "usb_dnl_dfu");
--
2.17.1
[PATCH 02/10] stm32mp: stm32prog: add timeout in stm32prog_serial_get_buffer
Handle timeout in stm32prog_serial_get_buffer to sent NACK
to STM32CubeProgrammer when the buffer is not fully received.
This patch avoids to reach the STM32CubeProgrammer timeout and
the associated unrecoverable error.
Timeout error occurred while waiting for acknowledgment.
Error: Write Operation fails at packet number 4165 at address 0x1044FF
Signed-off-by: Patrick Delaunay
---
.../mach-stm32mp/cmd_stm32prog/stm32prog_serial.c| 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
index 7eca86c11b..2550ae6a2b 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
@@ -60,6 +60,9 @@ const u8 cmd_id[] = {
#define NB_CMD sizeof(cmd_id)
+/* with 115200 bauds, 20 ms allow to receive the 256 bytes buffer */
+#define TIMEOUT_SERIAL_BUFFER 30
+
/* DFU support for serial */
static struct dfu_entity *stm32prog_get_entity(struct stm32prog_data *data)
{
@@ -264,6 +267,7 @@ static bool stm32prog_serial_get_buffer(u8 *buffer, u32
*count)
{
struct dm_serial_ops *ops = serial_get_ops(down_serial_dev);
int err;
+ ulong start = get_timer(0);
do {
err = ops->getc(down_serial_dev);
@@ -273,6 +277,10 @@ static bool stm32prog_serial_get_buffer(u8 *buffer, u32
*count)
} else if (err == -EAGAIN) {
ctrlc();
WATCHDOG_RESET();
+ if (get_timer(start) > TIMEOUT_SERIAL_BUFFER) {
+ err = -ETIMEDOUT;
+ break;
+ }
} else {
break;
}
@@ -648,7 +656,7 @@ static void download_command(struct stm32prog_data *data)
printf("transmission error on packet %d, byte %d\n",
packet_number, codesize - counter);
/* waiting end of packet before flush & NACK */
- mdelay(30);
+ mdelay(TIMEOUT_SERIAL_BUFFER);
data->packet_number--;
result = NACK_BYTE;
goto end;
@@ -666,7 +674,7 @@ static void download_command(struct stm32prog_data *data)
/* wait to be sure that all data are received
* in the FIFO before flush
*/
- mdelay(30);
+ mdelay(TIMEOUT_SERIAL_BUFFER);
data->packet_number--;
result = NACK_BYTE;
goto end;
--
2.17.1
[PATCH 01/10] stm32mp: stm32prog: remove all the header check for UART download
This patch removes the header check for UART download;
the check of checksum is not mandatory with even parity and chuck
checksum for each 256 received bytes and it is only done for
STM32 image (FSBL = TF-A BL2), not for FIT image.
This patch solve issue of duplicated 0x100 byte written with FIP header.
Fixes: 4fb7b3e10891 ("stm32mp: stm32prog: add FIP header support")
Signed-off-by: Patrick Delaunay
---
.../mach-stm32mp/cmd_stm32prog/stm32prog.c| 14 +-
.../mach-stm32mp/cmd_stm32prog/stm32prog.h| 5 -
.../cmd_stm32prog/stm32prog_serial.c | 151 ++
3 files changed, 22 insertions(+), 148 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index 4c4d8a7a69..84b880261a 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -369,23 +369,24 @@ static int parse_flash_layout(struct stm32prog_data *data,
bool end_of_line, eof;
char *p, *start, *last, *col;
struct stm32prog_part_t *part;
+ struct image_header_s header;
int part_list_size;
int i;
data->part_nb = 0;
/* check if STM32image is detected */
- stm32prog_header_check((struct raw_header_s *)addr, &data->header);
- if (data->header.type == HEADER_STM32IMAGE) {
+ stm32prog_header_check((struct raw_header_s *)addr, &header);
+ if (header.type == HEADER_STM32IMAGE) {
u32 checksum;
addr = addr + BL_HEADER_SIZE;
- size = data->header.image_length;
+ size = header.image_length;
- checksum = stm32prog_header_checksum(addr, &data->header);
- if (checksum != data->header.image_checksum) {
+ checksum = stm32prog_header_checksum(addr, &header);
+ if (checksum != header.image_checksum) {
stm32prog_err("Layout: invalid checksum : 0x%x expected
0x%x",
- checksum, data->header.image_checksum);
+ checksum, header.image_checksum);
return -EIO;
}
}
@@ -1727,7 +1728,6 @@ void stm32prog_clean(struct stm32prog_data *data)
free(data->part_array);
free(data->otp_part);
free(data->buffer);
- free(data->header_data);
}
/* DFU callback: used after serial and direct DFU USB access */
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
index 581b10d0ac..ad404879a7 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
@@ -132,14 +132,9 @@ struct stm32prog_data {
u32 *otp_part;
u8 pmic_part[PMIC_SIZE];
- /* STM32 header information */
- struct raw_header_s *header_data;
- struct image_header_s header;
-
/* SERIAL information */
u32 cursor;
u32 packet_number;
- u32 checksum;
u8 *buffer; /* size = USART_RAM_BUFFER_SIZE*/
int dfu_seq;
u8 read_phase;
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
index 2b92e3b149..7eca86c11b 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
@@ -292,56 +292,6 @@ static void stm32prog_serial_putc(u8 w_byte)
}
/* Helper function /
-
-static u8 stm32prog_header(struct stm32prog_data *data)
-{
- u8 ret;
- u8 boot = 0;
- struct dfu_entity *dfu_entity;
- u64 size = 0;
-
- dfu_entity = stm32prog_get_entity(data);
- if (!dfu_entity)
- return -ENODEV;
-
- printf("\nSTM32 download write %s\n", dfu_entity->name);
-
- /* force cleanup to avoid issue with previous read */
- dfu_transaction_cleanup(dfu_entity);
-
- stm32prog_header_check(data->header_data, &data->header);
-
- /* no stm32 image header : max size is partition size */
- if (data->header.type != HEADER_STM32IMAGE) {
- dfu_entity->get_medium_size(dfu_entity, &size);
- data->header.image_length = size;
- }
-
- / Flash the header if necessary for boot partition */
- if (data->phase < PHASE_FIRST_USER)
- boot = 1;
-
- /* write header if boot partition */
- if (boot) {
- if (ret) {
- stm32prog_err("invalid header (error %d)", ret);
- } else {
- ret = stm32prog_write(data,
- (u8 *)data->header_data,
- BL_HEADER_SIZE);
- }
- } else {
-
[PATCH] configs: sama5d27_wlsom1_ek_mmc: add default bootargs
Add default bootarguments with booting from mmc0 for this configuration. This will allow a default Linux boot for this board. Suggested-by: Jarvis Chen Signed-off-by: Eugen Hristev --- configs/sama5d27_wlsom1_ek_mmc_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/sama5d27_wlsom1_ek_mmc_defconfig b/configs/sama5d27_wlsom1_ek_mmc_defconfig index a778df54bf..c60d4c6be5 100644 --- a/configs/sama5d27_wlsom1_ek_mmc_defconfig +++ b/configs/sama5d27_wlsom1_ek_mmc_defconfig @@ -26,6 +26,7 @@ CONFIG_SYS_EXTRA_OPTIONS="SAMA5D2" CONFIG_SD_BOOT=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rw rootwait" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_MISC_INIT_R=y -- 2.25.1
Re: [PATCH v3] Fix flashing of eMMC user area with Fastboot
On Tue, May 18, 2021 at 01:41:06PM +0300, Oleh Kravchenko wrote:
> Any updates on these?
Sorry, my reading of what you and Sean were saying left me with the
impression no code changes were needed in the end, is that not the case?
>
> 15.05.21 00:26, Oleh Kravchenko пише:
> > Hello guys,
> > Could you please review and merge this patch?
> >
> > PR successfully passed CI:
> > https://github.com/u-boot/u-boot/pull/75
> >
> > 15.05.21 00:15, Oleh Kravchenko пише:
> >> 'gpt' and 'mmc0' fastboot partitions have been treated as the same device,
> >> but it is wrong.
> >>
> >> Signed-off-by: Oleh Kravchenko
> >> Cc: Pantelis Antoniou
> >> Cc: Marek Vasut
> >> ---
> >> Changes for v2:
> >>- code cleanup;
> >> Changes for v3:
> >>- QA passed at https://github.com/u-boot/u-boot/pull/75;
> >>
> >> drivers/fastboot/fb_mmc.c | 25 -
> >> 1 file changed, 20 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
> >> index 2f3837e559..647d3f6c1b 100644
> >> --- a/drivers/fastboot/fb_mmc.c
> >> +++ b/drivers/fastboot/fb_mmc.c
> >> @@ -532,12 +532,7 @@ void fastboot_mmc_flash_write(const char *cmd, void
> >> *download_buffer,
> >> #endif
> >>
> >> #if CONFIG_IS_ENABLED(EFI_PARTITION)
> >> -#ifndef CONFIG_FASTBOOT_MMC_USER_SUPPORT
> >>if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
> >> -#else
> >> - if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0 ||
> >> - strcmp(cmd, CONFIG_FASTBOOT_MMC_USER_NAME) == 0) {
> >> -#endif
> >>dev_desc = fastboot_mmc_get_dev(response);
> >>if (!dev_desc)
> >>return;
> >> @@ -599,9 +594,29 @@ void fastboot_mmc_flash_write(const char *cmd, void
> >> *download_buffer,
> >>}
> >> #endif
> >>
> >> +#if CONFIG_IS_ENABLED(FASTBOOT_MMC_USER_SUPPORT)
> >> + if (strcmp(cmd, CONFIG_FASTBOOT_MMC_USER_NAME) == 0) {
> >> + dev_desc = fastboot_mmc_get_dev(response);
> >> + if (!dev_desc)
> >> + return;
> >> +
> >> + memset(&info, 0, sizeof(info));
> >> + info.start = 0;
> >> + info.size = dev_desc->lba;
> >> + info.blksz = dev_desc->blksz;
> >> + strlcpy((char *)&info.name, cmd, sizeof(info.name));
> >> +
> >> + goto write_image;
> >> + }
> >> +#endif
> >> +
> >>if (fastboot_mmc_get_part_info(cmd, &dev_desc, &info, response) < 0)
> >>return;
> >>
> >> +#if CONFIG_IS_ENABLED(FASTBOOT_MMC_USER_SUPPORT)
> >> +write_image:
> >> +#endif
> >> +
> >>if (is_sparse_image(download_buffer)) {
> >>struct fb_mmc_sparse sparse_priv;
> >>struct sparse_storage sparse;
> >>
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
On Tue, May 18, 2021 at 05:56:08PM +0800, Bin Meng wrote: > Hi Green, > > On Tue, May 18, 2021 at 5:43 PM Green Wan wrote: > > > > > > > > On Tue, May 18, 2021 at 3:45 PM Bin Meng wrote: > >> > >> Hi Green, > >> > >> On Tue, May 18, 2021 at 3:38 PM Leo Liang wrote: > >> > > >> > On Fri, May 14, 2021 at 11:45:30AM +0800, Green Wan wrote: > >> > > Hi Bin, > >> > > > >> > > Thanks, I'll include that revert. Just traced back the git log. My > >> > > original > >> > > patch is based on fu740. I guess it was merged to fu540 since fu740 > >> > > series > >> > > wasn't present yet. > >> > > > >> > > Hi Rick, > >> > > > >> > > Not sure whether you'll pick fu740 series soon or if any parts need > >> > > more > >> > > revisement. Do you prefer that I append both this revert and "disable > >> > > CSR" > >> > > patch to fu740&unmatched patch series? If so, I will create v9 patch > >> > > and > >> > > include these 2 patches. > >> > > > >> > > Or if you prefer to keep them separate from fu740 series, we can wait > >> > > for > >> > > fu740&unmatche patch merge and I'll create a separate patch for this > >> > > revert > >> > > and CSR disable. > >> > > > >> > > What do you think? Many thanks. > >> > > > >> > > Regards, > >> > > - Green > >> > > > >> > > >> > Hi Green, > >> > > >> > Could you please append the "disable CSR" patch to fu740 unmatched patch > >> > and send a v9 patch ? Thanks! > >> > > >> > >> I think you will need some update per this patch as well: > >> http://patchwork.ozlabs.org/project/uboot/patch/20210511120412.25065-1-bmeng...@gmail.com/ > > > > > > Hi Bin > > I updated the change to [patch v9 1/8]. Thanks, > > > >> > >> > >> > >> Hi Leo, > >> > >> What's your plan for the binman patch series? > >> > >> If the binman patch series go first, Green needs to update Unmatched > >> to use binman as well. > > > > > > Hi Leo/Bin, > > > > Are we referring to > > https://lists.denx.de/pipermail/u-boot/2021-May/448885.html? > > This one: http://patchwork.ozlabs.org/project/uboot/list/?series=242992 > > > I'd prefer to have a separated patch work to track binman changes. Thanks, > > Actually that's why I asked Leo the plan. If your patch go before my > patch, then I will need to do an additional patch to convert > unmatched. > > But if mine go first before yours, you will have to respin another > version to do the convert in the first place. > > Leo, please let us know your plan. > Hi Bin/Green, I was thinking picking Bin's patch first, because Green's patch could not pass CI. (Due to some format warning being treated as error when compiling drivers/pci/pcie_dw_common.c) At the meantime, we should come up with some fixes to pass CI. Then Green could send his patch with binman, or a seperate patch to track binman utility. What do you guys think? Best regards, Leo > Regards, > Bin
Re: [PATCH] nvme: fix for big endian systems
Hi all,
On Thu, May 06, 2021 at 08:24:30PM +0200, David Lamparter wrote:
> writel() and co. already include the endian swap; doing the swap twice
> is, er, unhelpful.
>
> Tested on a P4080DS, which boots perfectly fine off NVMe with this.
is there anything to be done on my end to get this merged? The
MAINTAINERS file has no entry for drivers/nvme/ so I'm not quite sure
who to ping on this...
Cheers,
David
> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> index c61dab20c5f0..d554ec54cbe0 100644
> --- a/drivers/nvme/nvme.c
> +++ b/drivers/nvme/nvme.c
> @@ -157,7 +157,7 @@ static u16 nvme_read_completion_status(struct nvme_queue
> *nvmeq, u16 index)
>
> invalidate_dcache_range(start, stop);
>
> - return le16_to_cpu(readw(&(nvmeq->cqes[index].status)));
> + return readw(&(nvmeq->cqes[index].status));
> }
>
> /**
> @@ -221,7 +221,7 @@ static int nvme_submit_sync_cmd(struct nvme_queue *nvmeq,
> }
>
> if (result)
> - *result = le32_to_cpu(readl(&(nvmeq->cqes[head].result)));
> + *result = readl(&(nvmeq->cqes[head].result));
>
> if (++head == nvmeq->q_depth) {
> head = 0;
> @@ -304,7 +304,7 @@ static int nvme_enable_ctrl(struct nvme_dev *dev)
> {
> dev->ctrl_config &= ~NVME_CC_SHN_MASK;
> dev->ctrl_config |= NVME_CC_ENABLE;
> - writel(cpu_to_le32(dev->ctrl_config), &dev->bar->cc);
> + writel(dev->ctrl_config, &dev->bar->cc);
>
> return nvme_wait_ready(dev, true);
> }
> @@ -313,7 +313,7 @@ static int nvme_disable_ctrl(struct nvme_dev *dev)
> {
> dev->ctrl_config &= ~NVME_CC_SHN_MASK;
> dev->ctrl_config &= ~NVME_CC_ENABLE;
> - writel(cpu_to_le32(dev->ctrl_config), &dev->bar->cc);
> + writel(dev->ctrl_config, &dev->bar->cc);
>
> return nvme_wait_ready(dev, false);
> }
Re: [PATCH] crypto: Add driver for Aspeed HACE
On 5/18/21 9:09 AM, Joel Stanley wrote:
> The HACE supports MD5, SHA1 and SHA2 family hash functions. This driver
> uses it in a polling mode to perform hash calculations over buffers
> placed in DRAM.
>
> It registers a driver to allow the hardware's clocking to be enabled
> using the clock framework.
>
> Co-developed-by: Klaus Heinrich Kiwi
> Signed-off-by: Klaus Heinrich Kiwi
> Signed-off-by: Joel Stanley
> ---
> configs/evb-ast2600_defconfig | 1 +
> drivers/crypto/Kconfig| 19 +++
> drivers/crypto/Makefile | 1 +
> drivers/crypto/aspeed_hace.c | 256 ++
> 4 files changed, 277 insertions(+)
> create mode 100644 drivers/crypto/aspeed_hace.c
>
> diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
> index 91518dbe3589..52ae8e423bfd 100644
> --- a/configs/evb-ast2600_defconfig
> +++ b/configs/evb-ast2600_defconfig
> @@ -45,6 +45,7 @@ CONFIG_REGMAP=y
> CONFIG_SPL_OF_TRANSLATE=y
> CONFIG_CLK=y
> CONFIG_SPL_CLK=y
> +CONFIG_ASPEED_HACE=y
> CONFIG_DM_I2C=y
> CONFIG_MISC=y
> CONFIG_SPL_MISC=y
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 1ea116be7503..e92037d88906 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -2,4 +2,23 @@ menu "Hardware crypto devices"
>
> source drivers/crypto/fsl/Kconfig
>
> +config ASPEED_HACE
> + bool "ASPEED Hash and Crypto Engine"
> + depends on ASPEED_AST2600
> + imply SHA_HW_ACCEL
> + imply SHA_PROG_HW_ACCEL
> + imply SHA512
> + imply SHA512_ALGO
> + imply CMD_HASH
> + help
> + Select this option to enable a driver for using the SHA engine in
> + the ASPEED BMC SoCs.
> +
> + Enabling this allows the use of SHA operations in hardware without
> requiring the
> + SHA software implementations, saving code size.
> +
> + Due to hardware limitations it cannot be used with a FIT placed in SPI
> + FLASH. Data can only be hashed if it is in SDRAM, making this relevant
> + for MMC and network boot only.
> +
> endmenu
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index efbd1d3fca05..ac93b1295954 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -4,5 +4,6 @@
> #http://www.samsung.com
>
> obj-$(CONFIG_EXYNOS_ACE_SHA) += ace_sha.o
> +obj-$(CONFIG_ASPEED_HACE)+= aspeed_hace.o
> obj-y += rsa_mod_exp/
> obj-y += fsl/
> diff --git a/drivers/crypto/aspeed_hace.c b/drivers/crypto/aspeed_hace.c
> new file mode 100644
> index ..941c1555fe5c
> --- /dev/null
> +++ b/drivers/crypto/aspeed_hace.c
> @@ -0,0 +1,256 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +//
> +// (C) Copyright ASPEED Technology Inc.
> +// Copyright 2021 IBM Corp.
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define ASPEED_HACE_STS 0x1C
> +#define HACE_RSA_ISRBIT(13)
> +#define HACE_CRYPTO_ISR BIT(12)
> +#define HACE_HASH_ISR BIT(9)
> +#define HACE_RSA_BUSY BIT(2)
> +#define HACE_CRYPTO_BUSYBIT(1)
> +#define HACE_HASH_BUSY BIT(0)
> +#define ASPEED_HACE_HASH_SRC 0x20
> +#define ASPEED_HACE_HASH_DIGEST_BUFF 0x24
> +#define ASPEED_HACE_HASH_KEY_BUFF0x28
> +#define ASPEED_HACE_HASH_DATA_LEN0x2C
> +#define HACE_SG_LASTBIT(31)
> +#define ASPEED_HACE_HASH_CMD 0x30
> +#define HACE_SHA_BE_EN BIT(3)
> +#define HACE_MD5_LE_EN BIT(2)
> +#define HACE_ALGO_MD5 0
> +#define HACE_ALGO_SHA1 BIT(5)
> +#define HACE_ALGO_SHA224BIT(6)
> +#define HACE_ALGO_SHA256(BIT(4) | BIT(6))
> +#define HACE_ALGO_SHA512(BIT(5) | BIT(6))
> +#define HACE_ALGO_SHA384(BIT(5) | BIT(6) | BIT(10))
> +#define HACE_SG_EN BIT(18)
> +
> +#define ASPEED_MAX_SG32
It would nice to have a struct aspeed_hace describing the register layout.
> +struct aspeed_sg {
> + u32 len;
> + u32 addr;
> +};
> +
> +struct aspeed_hash_ctx {
> + u32 method;
> + u32 digest_size;
> + u32 len;
> + u32 count;
> + struct aspeed_sg list[ASPEED_MAX_SG]; /* Must be 8 byte aligned */
> +};
Shouldn't we use __aligned(8); ?
> +struct aspeed_hace {
> + struct clk clk;
> +};
> +
> +static phys_addr_t base;
> +
> +static int aspeed_hace_wait_completion(u32 reg, u32 flag, int timeout_us)
> +{
> + u32 val;
> +
> + return readl_poll_timeout(reg, val, (val & flag) == flag, timeout_us);
> +}
> +
> +static int digest_object(const void *src, unsigned int length, void *digest,
> u32 method)
> +{
> + if (!((u32)src & BIT(31))) {
> + debug("HACE src out of bounds: can only copy fr
[PATCH] mkimage: allow -l to work on block devices on Linux
From: Yann Dirson
When "mkimage -l" was run on a block device it would fail with
erroneous message, because fstat reports a size of zero for those:
mkimage: Bad size: "/dev/sdb4" is not valid image
This patch identifies the "is a block device" case and reports it as
such, and if it knows how to determine the size of a block device on
the current OS, proceeds.
As shown in
http://www.mit.edu/afs.new/sipb/user/tytso/e2fsprogs/lib/blkid/getsize.c
this is no portable task, and I only handled the case of a modern
Linux kernel, which is what I can test.
Signed-off-by: Yann Dirson
---
tools/mkimage.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index cc7b242faf..302bfcf971 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -12,6 +12,9 @@
#include "imximage.h"
#include
#include
+#ifdef __linux__
+#include
+#endif
static void copy_file(int, const char *, int);
@@ -402,6 +405,7 @@ int main(int argc, char **argv)
}
if (params.lflag || params.fflag) {
+ uint64_t size;
/*
* list header information of existing image
*/
@@ -412,14 +416,34 @@ int main(int argc, char **argv)
exit (EXIT_FAILURE);
}
- if ((unsigned)sbuf.st_size < tparams->header_size) {
+ if ((sbuf.st_mode & S_IFMT) == S_IFBLK) {
+#ifdef __linux__
+#if defined(__linux__) && defined(_IOR) && !defined(BLKGETSIZE64)
+#define BLKGETSIZE64 _IOR(0x12,114,size_t) /* return device size in bytes
(u64 *arg) */
+#endif
+ if (ioctl(ifd, BLKGETSIZE64, &size) < 0) {
+ fprintf (stderr,
+ "%s: failed to get size of block device
\"%s\"\n",
+ params.cmdname, params.imagefile);
+ exit (EXIT_FAILURE);
+ }
+#else
fprintf (stderr,
- "%s: Bad size: \"%s\" is not valid image\n",
+ "%s: \"%s\" is block device, don't know how to
get its size\n",
params.cmdname, params.imagefile);
exit (EXIT_FAILURE);
+#endif
+ } else if ((unsigned)sbuf.st_size < tparams->header_size) {
+ fprintf (stderr,
+ "%s: Bad size: \"%s\" is not valid image: size
%ld < %u\n",
+ params.cmdname, params.imagefile,
+ sbuf.st_size, tparams->header_size);
+ exit (EXIT_FAILURE);
+ } else {
+ size = sbuf.st_size;
}
- ptr = mmap(0, sbuf.st_size, PROT_READ, MAP_SHARED, ifd, 0);
+ ptr = mmap(0, size, PROT_READ, MAP_SHARED, ifd, 0);
if (ptr == MAP_FAILED) {
fprintf (stderr, "%s: Can't read %s: %s\n",
params.cmdname, params.imagefile,
--
2.30.2
[PATCH] powerpc: fix regression in arch_initr_trap()
The assembly output of the arch_initr_trap() function differed by a
single byte after common.h was removed from traps.c:
fff49a18 :
fff49a18: 94 21 ff f0 stwur1,-16(r1)
fff49a1c: 7c 08 02 a6 mflrr0
fff49a20: 90 01 00 14 stw r0,20(r1)
-fff49a24: 80 62 00 44 lwz r3,68(r2)
+fff49a24: 80 62 00 38 lwz r3,56(r2)
fff49a28: 4b ff 76 19 bl fff41040
fff49a2c: 80 01 00 14 lwz r0,20(r1)
fff49a30: 38 60 00 00 li r3,0
fff49a34: 38 21 00 10 addir1,r1,16
fff49a38: 7c 08 03 a6 mtlrr0
This was causing a consistent hard lockup during the MMC read / loading
of the QoriQ FMan firmware on a P2041RDB board.
Re-adding the header causes identical assembly to be emitted and allows
the firmware loading and subsequent boot to succeed.
Fixes: 401d1c4f5d ("common: Drop asm/global_data.h from common header")
Signed-off-by: Matt Merhar
---
arch/powerpc/lib/traps.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/lib/traps.c b/arch/powerpc/lib/traps.c
index c7bce82a44..ab8ca269a5 100644
--- a/arch/powerpc/lib/traps.c
+++ b/arch/powerpc/lib/traps.c
@@ -4,6 +4,7 @@
* Wolfgang Denk, DENX Software Engineering, w...@denx.de.
*/
+#include
#include
#include
--
2.25.1
Re: [PATCH v3] Fix flashing of eMMC user area with Fastboot
Any updates on these?
15.05.21 00:26, Oleh Kravchenko пише:
> Hello guys,
> Could you please review and merge this patch?
>
> PR successfully passed CI:
> https://github.com/u-boot/u-boot/pull/75
>
> 15.05.21 00:15, Oleh Kravchenko пише:
>> 'gpt' and 'mmc0' fastboot partitions have been treated as the same device,
>> but it is wrong.
>>
>> Signed-off-by: Oleh Kravchenko
>> Cc: Pantelis Antoniou
>> Cc: Marek Vasut
>> ---
>> Changes for v2:
>>- code cleanup;
>> Changes for v3:
>>- QA passed at https://github.com/u-boot/u-boot/pull/75;
>>
>> drivers/fastboot/fb_mmc.c | 25 -
>> 1 file changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
>> index 2f3837e559..647d3f6c1b 100644
>> --- a/drivers/fastboot/fb_mmc.c
>> +++ b/drivers/fastboot/fb_mmc.c
>> @@ -532,12 +532,7 @@ void fastboot_mmc_flash_write(const char *cmd, void
>> *download_buffer,
>> #endif
>>
>> #if CONFIG_IS_ENABLED(EFI_PARTITION)
>> -#ifndef CONFIG_FASTBOOT_MMC_USER_SUPPORT
>> if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
>> -#else
>> -if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0 ||
>> -strcmp(cmd, CONFIG_FASTBOOT_MMC_USER_NAME) == 0) {
>> -#endif
>> dev_desc = fastboot_mmc_get_dev(response);
>> if (!dev_desc)
>> return;
>> @@ -599,9 +594,29 @@ void fastboot_mmc_flash_write(const char *cmd, void
>> *download_buffer,
>> }
>> #endif
>>
>> +#if CONFIG_IS_ENABLED(FASTBOOT_MMC_USER_SUPPORT)
>> +if (strcmp(cmd, CONFIG_FASTBOOT_MMC_USER_NAME) == 0) {
>> +dev_desc = fastboot_mmc_get_dev(response);
>> +if (!dev_desc)
>> +return;
>> +
>> +memset(&info, 0, sizeof(info));
>> +info.start = 0;
>> +info.size = dev_desc->lba;
>> +info.blksz = dev_desc->blksz;
>> +strlcpy((char *)&info.name, cmd, sizeof(info.name));
>> +
>> +goto write_image;
>> +}
>> +#endif
>> +
>> if (fastboot_mmc_get_part_info(cmd, &dev_desc, &info, response) < 0)
>> return;
>>
>> +#if CONFIG_IS_ENABLED(FASTBOOT_MMC_USER_SUPPORT)
>> +write_image:
>> +#endif
>> +
>> if (is_sparse_image(download_buffer)) {
>> struct fb_mmc_sparse sparse_priv;
>> struct sparse_storage sparse;
>>
Re: [PATCH] hash: Kconfig option for SHA512 hardware acceleration
On 5/18/21 5:36 AM, Joel Stanley wrote:
On Fri, 14 May 2021 at 09:12, Heinrich Schuchardt wrote:
Commit a479f103dc1c ("hash: Allow for SHA512 hardware implementations")
defined function definitions for hardware accelerated SHA384 and SHA512.
If CONFIG_SHA_HW_ACCEL=y, these functions are used.
We already have boards using CONFIG_SHA_HW_ACCEL=y but none implements the
new functions hw_sha384() and hw_sha512().
For implementing the EFI TCG2 protocol we need SHA384 and SHA512. The
missing hardware acceleration functions lead to build errors on boards like
peach-pi_defconfig.
Introduce a new Kconfig symbol CONFIG_SHA512_HW_ACCEL to control if the
functions hw_sha384() and hw_sha512() shall be used to implement the SHA384
and SHA512 algorithms.
Fixes: a479f103dc1c ("hash: Allow for SHA512 hardware implementations")
Signed-off-by: Heinrich Schuchardt
---
This patch replaces
hash: revert Allow for SHA512 hardware implementations
https://lists.denx.de/pipermail/u-boot/2021-May/449648.html
https://patchwork.ozlabs.org/project/uboot/patch/20210512170040.137058-1-xypron.g...@gmx.de/
This looks to be a good compromise. Thanks for fixing it.
Reviewed-by: Joel Stanley
The CONFIG maze that is the hash acceleration code could do with some
overarching cleanup at some point.
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -389,21 +389,32 @@ config SHA384
(digest).
config SHA_HW_ACCEL
- bool "Enable hashing using hardware"
+ bool "Enable hardware acceleration for SHA hash functions"
help
- This option enables hardware acceleration for SHA hashing.
- This affects the 'hash' command and also the hash_lookup_algo()
- function.
+ This option enables hardware acceleration for the SHA1 and SHA256
+ hashing algorithms. This affects the 'hash' command and also the
+ hash_lookup_algo() function.
+
+if SHA_HW_ACCEL
+
+config SHA512_HW_ACCEL
+ bool "Enable hardware acceleration for SHA512"
+ depends on SHA512_ALGO
This dependency is new, does it make sense? We don't have an
equivalent one for SHA_HW_ACCEL, but perhaps we should introduce one?
It does not make sense to show SHA512_HW_ACCEL is we cannot have SHA512
or SHA384.
+ help
+ This option enables hardware acceleration for the SHA384 andSHA512
Nit: there's a missing space after "and" here.
I will add it.
Perhaps you could add to the help text that this option should be
disabled if the platform requires SHA512 support but does not have
hardware acceleration.
The current text already says that it "enables hardware acceleration".
It would provide little value to add to all Kconfig options:
"Don't enable this option if you don't have a hardware for it.".
Best regards
Heinrich
+ hashing algorithms. This affects the 'hash' command and also the
+ hash_lookup_algo() function.
config SHA_PROG_HW_ACCEL
bool "Enable Progressive hashing support using hardware"
- depends on SHA_HW_ACCEL
help
This option enables hardware-acceleration for SHA progressive
hashing.
Data can be streamed in a block at a time and the hashing is
performed in hardware.
+endif
+
config MD5
bool "Support MD5 algorithm"
help
--
2.30.2
Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
Hi Green, On Tue, May 18, 2021 at 5:43 PM Green Wan wrote: > > > > On Tue, May 18, 2021 at 3:45 PM Bin Meng wrote: >> >> Hi Green, >> >> On Tue, May 18, 2021 at 3:38 PM Leo Liang wrote: >> > >> > On Fri, May 14, 2021 at 11:45:30AM +0800, Green Wan wrote: >> > > Hi Bin, >> > > >> > > Thanks, I'll include that revert. Just traced back the git log. My >> > > original >> > > patch is based on fu740. I guess it was merged to fu540 since fu740 >> > > series >> > > wasn't present yet. >> > > >> > > Hi Rick, >> > > >> > > Not sure whether you'll pick fu740 series soon or if any parts need more >> > > revisement. Do you prefer that I append both this revert and "disable >> > > CSR" >> > > patch to fu740&unmatched patch series? If so, I will create v9 patch and >> > > include these 2 patches. >> > > >> > > Or if you prefer to keep them separate from fu740 series, we can wait for >> > > fu740&unmatche patch merge and I'll create a separate patch for this >> > > revert >> > > and CSR disable. >> > > >> > > What do you think? Many thanks. >> > > >> > > Regards, >> > > - Green >> > > >> > >> > Hi Green, >> > >> > Could you please append the "disable CSR" patch to fu740 unmatched patch >> > and send a v9 patch ? Thanks! >> > >> >> I think you will need some update per this patch as well: >> http://patchwork.ozlabs.org/project/uboot/patch/20210511120412.25065-1-bmeng...@gmail.com/ > > > Hi Bin > I updated the change to [patch v9 1/8]. Thanks, > >> >> >> >> Hi Leo, >> >> What's your plan for the binman patch series? >> >> If the binman patch series go first, Green needs to update Unmatched >> to use binman as well. > > > Hi Leo/Bin, > > Are we referring to > https://lists.denx.de/pipermail/u-boot/2021-May/448885.html? This one: http://patchwork.ozlabs.org/project/uboot/list/?series=242992 > I'd prefer to have a separated patch work to track binman changes. Thanks, Actually that's why I asked Leo the plan. If your patch go before my patch, then I will need to do an additional patch to convert unmatched. But if mine go first before yours, you will have to respin another version to do the convert in the first place. Leo, please let us know your plan. Regards, Bin
Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
On Tue, May 18, 2021 at 3:45 PM Bin Meng wrote: > Hi Green, > > On Tue, May 18, 2021 at 3:38 PM Leo Liang wrote: > > > > On Fri, May 14, 2021 at 11:45:30AM +0800, Green Wan wrote: > > > Hi Bin, > > > > > > Thanks, I'll include that revert. Just traced back the git log. My > original > > > patch is based on fu740. I guess it was merged to fu540 since fu740 > series > > > wasn't present yet. > > > > > > Hi Rick, > > > > > > Not sure whether you'll pick fu740 series soon or if any parts need > more > > > revisement. Do you prefer that I append both this revert and "disable > CSR" > > > patch to fu740&unmatched patch series? If so, I will create v9 patch > and > > > include these 2 patches. > > > > > > Or if you prefer to keep them separate from fu740 series, we can wait > for > > > fu740&unmatche patch merge and I'll create a separate patch for this > revert > > > and CSR disable. > > > > > > What do you think? Many thanks. > > > > > > Regards, > > > - Green > > > > > > > Hi Green, > > > > Could you please append the "disable CSR" patch to fu740 unmatched patch > > and send a v9 patch ? Thanks! > > > > I think you will need some update per this patch as well: > > http://patchwork.ozlabs.org/project/uboot/patch/20210511120412.25065-1-bmeng...@gmail.com/ Hi Bin I updated the change to [patch v9 1/8]. Thanks, > > > Hi Leo, > > What's your plan for the binman patch series? > > If the binman patch series go first, Green needs to update Unmatched > to use binman as well. > Hi Leo/Bin, Are we referring to https://lists.denx.de/pipermail/u-boot/2021-May/448885.html? I'd prefer to have a separated patch work to track binman changes. Thanks, Regards, - Green > > Regards, > Bin >
Re: [PATCH] ARM: imx8m: verdin-imx8mm: Increase bootm size to 64 MiB
On Tue, May 18, 2021 at 11:45 AM Marek Vasut wrote: > > On 5/18/21 9:37 AM, Oleksandr Suvorov wrote: > > On Tue, May 18, 2021 at 1:40 AM Marek Vasut wrote: > >> > >> Uncompressed aarch64 kernel Image are rather large, increase the bootm > >> size limit to 64 MiB to cater for that. > >> > >> Signed-off-by: Marek Vasut > > > > Marek, thanks for your fix! > > > > There is a typo in the comment message: > > "kernel Image are rather large" probably should be either "kernel > > Images are rather large" or "kernel Image is rather large". > > The Image is the filename (aarch64 image) and it is plural, so I think > its neither of the options. Oh, I didn't notice the capital letter "I" :) Sorry about that. Reviewed w/o conditions :) -- Best regards Oleksandr Suvorov Toradex AG Ebenaustrasse 10 | 6048 Horw | Switzerland | T: +41 41 500 48 00
[PATCH v9 8/8] riscv: cpu: fu740: clear feature disable CSR
Clear feature disable CSR to turn on all features of hart. The detail
is specified at section, 'SiFive Feature Disable CSR', in user manual
https://sifive.cdn.prismic.io/sifive/aee0dd4c-d156-496e-a6c4-db0cf54bbe68_sifive_U74MC_rtl_full_20G1.03.00_manual.pdf
Signed-off-by: Green Wan
Reviewed-by: Sean Anderson
Reviewed-by: Bin Meng
Reviewed-by: Rick Chen
---
arch/riscv/cpu/fu740/spl.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/riscv/cpu/fu740/spl.c b/arch/riscv/cpu/fu740/spl.c
index ea0b2283a2..55e30346ff 100644
--- a/arch/riscv/cpu/fu740/spl.c
+++ b/arch/riscv/cpu/fu740/spl.c
@@ -6,6 +6,9 @@
#include
#include
+#include
+
+#define CSR_U74_FEATURE_DISABLE0x7c1
int spl_soc_init(void)
{
@@ -21,3 +24,15 @@ int spl_soc_init(void)
return 0;
}
+
+void harts_early_init(void)
+{
+ /*
+* Feature Disable CSR
+*
+* Clear feature disable CSR to '0' to turn on all features for
+* each core. This operation must be in M-mode.
+*/
+ if (CONFIG_IS_ENABLED(RISCV_MMODE))
+ csr_write(CSR_U74_FEATURE_DISABLE, 0);
+}
--
2.31.0
[PATCH v9 6/8] riscv: dts: add SiFive Unmatched board support
Add dts files for SiFive Unmatched board.
Signed-off-by: Green Wan
Reviewed-by: Rick Chen
---
arch/riscv/dts/Makefile |1 +
.../dts/fu740-hifive-unmatched-a00-ddr.dtsi | 1489 +
.../dts/hifive-unmatched-a00-u-boot.dtsi | 40 +
arch/riscv/dts/hifive-unmatched-a00.dts | 259 +++
4 files changed, 1789 insertions(+)
create mode 100644 arch/riscv/dts/fu740-hifive-unmatched-a00-ddr.dtsi
create mode 100644 arch/riscv/dts/hifive-unmatched-a00-u-boot.dtsi
create mode 100644 arch/riscv/dts/hifive-unmatched-a00.dts
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 8138d89d84..ed32f56c9e 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -2,6 +2,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
+dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
diff --git a/arch/riscv/dts/fu740-hifive-unmatched-a00-ddr.dtsi
b/arch/riscv/dts/fu740-hifive-unmatched-a00-ddr.dtsi
new file mode 100644
index 00..fc3dfd1959
--- /dev/null
+++ b/arch/riscv/dts/fu740-hifive-unmatched-a00-ddr.dtsi
@@ -0,0 +1,1489 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * (C) Copyright 2020-2021 SiFive, Inc
+ */
+
+&dmc {
+ sifive,ddr-params = <
+ 0x0a00 /* DENALI_CTL_00_DATA */
+ 0x /* DENALI_CTL_01_DATA */
+ 0x /* DENALI_CTL_02_DATA */
+ 0x /* DENALI_CTL_03_DATA */
+ 0x /* DENALI_CTL_04_DATA */
+ 0x /* DENALI_CTL_05_DATA */
+ 0x000a /* DENALI_CTL_06_DATA */
+ 0x0002d362 /* DENALI_CTL_07_DATA */
+ 0x00071073 /* DENALI_CTL_08_DATA */
+ 0x0a1c0255 /* DENALI_CTL_09_DATA */
+ 0x1c1c0400 /* DENALI_CTL_10_DATA */
+ 0x0404c90b /* DENALI_CTL_11_DATA */
+ 0x2b050405 /* DENALI_CTL_12_DATA */
+ 0x0d0c081e /* DENALI_CTL_13_DATA */
+ 0x08090914 /* DENALI_CTL_14_DATA */
+ 0x00fde718 /* DENALI_CTL_15_DATA */
+ 0x00180a05 /* DENALI_CTL_16_DATA */
+ 0x008b130d /* DENALI_CTL_17_DATA */
+ 0x01000118 /* DENALI_CTL_18_DATA */
+ 0x0d032001 /* DENALI_CTL_19_DATA */
+ 0x /* DENALI_CTL_20_DATA */
+ 0x0101 /* DENALI_CTL_21_DATA */
+ 0x /* DENALI_CTL_22_DATA */
+ 0x0a00 /* DENALI_CTL_23_DATA */
+ 0x /* DENALI_CTL_24_DATA */
+ 0x01450100 /* DENALI_CTL_25_DATA */
+ 0x1c36 /* DENALI_CTL_26_DATA */
+ 0x0005 /* DENALI_CTL_27_DATA */
+ 0x00170006 /* DENALI_CTL_28_DATA */
+ 0x014e0400 /* DENALI_CTL_29_DATA */
+ 0x0301 /* DENALI_CTL_30_DATA */
+ 0x000a0e00 /* DENALI_CTL_31_DATA */
+ 0x04030200 /* DENALI_CTL_32_DATA */
+ 0x031f /* DENALI_CTL_33_DATA */
+ 0x00070004 /* DENALI_CTL_34_DATA */
+ 0x /* DENALI_CTL_35_DATA */
+ 0x /* DENALI_CTL_36_DATA */
+ 0x /* DENALI_CTL_37_DATA */
+ 0x /* DENALI_CTL_38_DATA */
+ 0x /* DENALI_CTL_39_DATA */
+ 0x /* DENALI_CTL_40_DATA */
+ 0x /* DENALI_CTL_41_DATA */
+ 0x /* DENALI_CTL_42_DATA */
+ 0x /* DENALI_CTL_43_DATA */
+ 0x /* DENALI_CTL_44_DATA */
+ 0x /* DENALI_CTL_45_DATA */
+ 0x /* DENALI_CTL_46_DATA */
+ 0x /* DENALI_CTL_47_DATA */
+ 0x /* DENALI_CTL_48_DATA */
+ 0x /* DENALI_CTL_49_DATA */
+ 0x /* DENALI_CTL_50_DATA */
+ 0x /* DENALI_CTL_51_DATA */
+ 0x /* DENALI_CTL_52_DATA */
+ 0x /* DENALI_CTL_53_DATA */
+ 0x /* DENALI_CTL_54_DATA */
+ 0x /* DENALI_CTL_55_DATA */
+ 0x /* DENALI_CTL_56_DATA */
+ 0x /* DENALI_CTL_57_DATA */
+ 0x /* DENALI_CTL_58_DATA */
+ 0x /* DENALI_CTL_59_DATA */
+ 0x0424 /* DENALI_CTL_60_DATA */
+ 0x0201 /* DENALI_CTL_61_DA
[PATCH v9 7/8] board: sifive: add HiFive Unmatched board support
Add defconfig and board support for HiFive Unmatched. Signed-off-by: Green Wan Reviewed-by: Bin Meng Reviewed-by: Rick Chen --- arch/riscv/Kconfig | 4 + board/sifive/unleashed/Kconfig | 1 + board/sifive/unmatched/Kconfig | 50 +++ board/sifive/unmatched/MAINTAINERS | 9 + board/sifive/unmatched/Makefile| 9 + board/sifive/unmatched/spl.c | 85 + board/sifive/unmatched/unmatched.c | 24 ++ common/spl/Kconfig | 4 +- configs/sifive_unmatched_defconfig | 54 +++ doc/board/sifive/index.rst | 1 + doc/board/sifive/unmatched.rst | 536 + drivers/reset/Kconfig | 2 +- include/configs/sifive-unmatched.h | 85 + 13 files changed, 861 insertions(+), 3 deletions(-) create mode 100644 board/sifive/unmatched/Kconfig create mode 100644 board/sifive/unmatched/MAINTAINERS create mode 100644 board/sifive/unmatched/Makefile create mode 100644 board/sifive/unmatched/spl.c create mode 100644 board/sifive/unmatched/unmatched.c create mode 100644 configs/sifive_unmatched_defconfig create mode 100644 doc/board/sifive/unmatched.rst create mode 100644 include/configs/sifive-unmatched.h diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 81c524600e..1fc3add4d3 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -20,6 +20,9 @@ config TARGET_QEMU_VIRT config TARGET_SIFIVE_UNLEASHED bool "Support SiFive Unleashed Board" +config TARGET_SIFIVE_UNMATCHED + bool "Support SiFive Unmatched Board" + config TARGET_SIPEED_MAIX bool "Support Sipeed Maix Board" @@ -56,6 +59,7 @@ source "board/AndesTech/ax25-ae350/Kconfig" source "board/emulation/qemu-riscv/Kconfig" source "board/microchip/mpfs_icicle/Kconfig" source "board/sifive/unleashed/Kconfig" +source "board/sifive/unmatched/Kconfig" source "board/sipeed/maix/Kconfig" # platform-specific options below diff --git a/board/sifive/unleashed/Kconfig b/board/sifive/unleashed/Kconfig index dbffd59c98..833cbd370d 100644 --- a/board/sifive/unleashed/Kconfig +++ b/board/sifive/unleashed/Kconfig @@ -27,6 +27,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy def_bool y select SIFIVE_FU540 select ENV_IS_IN_SPI_FLASH + select RESET_SIFIVE imply CMD_DHCP imply CMD_EXT2 imply CMD_EXT4 diff --git a/board/sifive/unmatched/Kconfig b/board/sifive/unmatched/Kconfig new file mode 100644 index 00..9e2748ce1e --- /dev/null +++ b/board/sifive/unmatched/Kconfig @@ -0,0 +1,50 @@ +if TARGET_SIFIVE_UNMATCHED + +config SYS_BOARD + default "unmatched" + +config SYS_VENDOR + default "sifive" + +config SYS_CPU + default "fu740" + +config SYS_CONFIG_NAME + default "sifive-unmatched" + +config SYS_TEXT_BASE + default 0x8020 if SPL + default 0x8000 if !RISCV_SMODE + default 0x8020 if RISCV_SMODE + +config SPL_TEXT_BASE + default 0x0800 + +config SPL_OPENSBI_LOAD_ADDR + default 0x8000 + +config BOARD_SPECIFIC_OPTIONS # dummy + def_bool y + select SIFIVE_FU740 + select SUPPORT_SPL + select RESET_SIFIVE + imply CMD_DHCP + imply CMD_EXT2 + imply CMD_EXT4 + imply CMD_FAT + imply CMD_FS_GENERIC + imply CMD_GPT + imply PARTITION_TYPE_GUID + imply CMD_NET + imply CMD_PING + imply CMD_SF + imply DOS_PARTITION + imply EFI_PARTITION + imply IP_DYN + imply ISO_PARTITION + imply PHY_LIB + imply PHY_MSCC + imply SYSRESET + imply SYSRESET_GPIO + +endif diff --git a/board/sifive/unmatched/MAINTAINERS b/board/sifive/unmatched/MAINTAINERS new file mode 100644 index 00..94c9510bfa --- /dev/null +++ b/board/sifive/unmatched/MAINTAINERS @@ -0,0 +1,9 @@ +SiFive HiFive Unmatched FU740 BOARD +M: Paul Walmsley +M: Pragnesh Patel +M: Green Wan +S: Maintained +F: board/sifive/unmatched/ +F: doc/board/sifive/hifive-unmatched-fu740.rst +F: include/configs/sifive-unmatched.h +F: configs/sifive_unmatched_defconfig diff --git a/board/sifive/unmatched/Makefile b/board/sifive/unmatched/Makefile new file mode 100644 index 00..6308c80d64 --- /dev/null +++ b/board/sifive/unmatched/Makefile @@ -0,0 +1,9 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright (c) 2020-2021 SiFive, Inc + +obj-y += unmatched.o + +ifdef CONFIG_SPL_BUILD +obj-y += spl.o +endif diff --git a/board/sifive/unmatched/spl.c b/board/sifive/unmatched/spl.c new file mode 100644 index 00..5e1333b09a --- /dev/null +++ b/board/sifive/unmatched/spl.c @@ -0,0 +1,85 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) 2020-2021 SiFive, Inc + * + * Authors: + * Pragnesh Patel + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define GEM_PHY_RESET SIFIVE_GENERIC_GPIO_NR(0, 12) + +#define MODE_SELECT_REG0x
[PATCH v9 5/8] riscv: dts: add fu740 support
Add dts support for fu740. The HiFive Unmatched support is based on
fu740 cpu and drivers in following patch set.
Signed-off-by: Green Wan
[greentime.hu: set fu740 speed to 1.2GHz]
Signed-off-by: Greentime Hu
Reviewed-by: Bin Meng
Reviewed-by: Rick Chen
---
arch/riscv/dts/fu740-c000-u-boot.dtsi | 105 ++
arch/riscv/dts/fu740-c000.dtsi| 329 ++
include/dt-bindings/clock/sifive-fu740-prci.h | 25 ++
include/dt-bindings/reset/sifive-fu740-prci.h | 19 +
4 files changed, 478 insertions(+)
create mode 100644 arch/riscv/dts/fu740-c000-u-boot.dtsi
create mode 100644 arch/riscv/dts/fu740-c000.dtsi
create mode 100644 include/dt-bindings/clock/sifive-fu740-prci.h
create mode 100644 include/dt-bindings/reset/sifive-fu740-prci.h
diff --git a/arch/riscv/dts/fu740-c000-u-boot.dtsi
b/arch/riscv/dts/fu740-c000-u-boot.dtsi
new file mode 100644
index 00..a5d0688b06
--- /dev/null
+++ b/arch/riscv/dts/fu740-c000-u-boot.dtsi
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * (C) Copyright 2020-2021 SiFive, Inc
+ */
+
+#include
+
+/ {
+ cpus {
+ assigned-clocks = <&prci PRCI_CLK_COREPLL>;
+ assigned-clock-rates = <12>;
+ u-boot,dm-spl;
+ cpu0: cpu@0 {
+ clocks = <&prci PRCI_CLK_COREPLL>;
+ u-boot,dm-spl;
+ status = "okay";
+ cpu0_intc: interrupt-controller {
+ u-boot,dm-spl;
+ };
+ };
+ cpu1: cpu@1 {
+ clocks = <&prci PRCI_CLK_COREPLL>;
+ u-boot,dm-spl;
+ cpu1_intc: interrupt-controller {
+ u-boot,dm-spl;
+ };
+ };
+ cpu2: cpu@2 {
+ clocks = <&prci PRCI_CLK_COREPLL>;
+ u-boot,dm-spl;
+ cpu2_intc: interrupt-controller {
+u-boot,dm-spl;
+ };
+ };
+ cpu3: cpu@3 {
+ clocks = <&prci PRCI_CLK_COREPLL>;
+ u-boot,dm-spl;
+ cpu3_intc: interrupt-controller {
+ u-boot,dm-spl;
+ };
+ };
+ cpu4: cpu@4 {
+ clocks = <&prci PRCI_CLK_COREPLL>;
+ u-boot,dm-spl;
+ cpu4_intc: interrupt-controller {
+ u-boot,dm-spl;
+ };
+ };
+ };
+
+ soc {
+ u-boot,dm-spl;
+ clint: clint@200 {
+ compatible = "riscv,clint0";
+ interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7
+ &cpu1_intc 3 &cpu1_intc 7
+ &cpu2_intc 3 &cpu2_intc 7
+ &cpu3_intc 3 &cpu3_intc 7
+ &cpu4_intc 3 &cpu4_intc 7>;
+ reg = <0x0 0x200 0x0 0x1>;
+ u-boot,dm-spl;
+ };
+ prci: clock-controller@1000 {
+ #reset-cells = <1>;
+ resets = <&prci PRCI_RST_DDR_CTRL_N>,
+<&prci PRCI_RST_DDR_AXI_N>,
+<&prci PRCI_RST_DDR_AHB_N>,
+<&prci PRCI_RST_DDR_PHY_N>,
+<&prci PRCI_RST_GEMGXL_N>,
+<&prci PRCI_RST_CLTX_N>;
+ reset-names = "ddr_ctrl", "ddr_axi", "ddr_ahb",
+ "ddr_phy", "gemgxl_reset", "cltx_reset";
+ };
+ dmc: dmc@100b {
+ compatible = "sifive,fu740-c000-ddr";
+ reg = <0x0 0x100b 0x0 0x0800
+ 0x0 0x100b2000 0x0 0x2000
+ 0x0 0x100b8000 0x0 0x1000>;
+ clocks = <&prci PRCI_CLK_DDRPLL>;
+ clock-frequency = <93324>;
+ u-boot,dm-spl;
+ };
+ };
+};
+
+&prci {
+ u-boot,dm-spl;
+};
+
+&uart0 {
+ u-boot,dm-spl;
+};
+
+&spi0 {
+ u-boot,dm-spl;
+};
+
+ð0 {
+ assigned-clocks = <&prci PRCI_CLK_GEMGXLPLL>;
+ assigned-clock-rates = <125125000>;
+};
+
+&ccache {
+ status = "okay";
+};
diff --git a/arch/riscv/dts/fu740-c000.dtsi b/arch/riscv/dts/fu740-c000.dtsi
new file mode 100644
index 00..649efe400a
--- /dev/null
+++ b/arch/riscv/dts/fu740-c000.dtsi
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2020-2021 SiFive, Inc */
+
+/dts-v1/;
+
[PATCH v9 2/8] drivers: clk: add fu740 support
Add fu740 support. One abstract layer is added for supporting multiple chips such as fu540 and fu740. Signed-off-by: Green Wan --- arch/riscv/cpu/fu540/Kconfig | 2 +- drivers/clk/sifive/Kconfig | 8 +- drivers/clk/sifive/Makefile | 4 +- drivers/clk/sifive/fu540-prci.c | 769 +-- drivers/clk/sifive/fu540-prci.h | 22 + drivers/clk/sifive/fu740-prci.c | 158 +++ drivers/clk/sifive/fu740-prci.h | 22 + drivers/clk/sifive/sifive-prci.c | 733 + drivers/clk/sifive/sifive-prci.h | 323 + drivers/reset/Kconfig| 2 +- 10 files changed, 1288 insertions(+), 755 deletions(-) create mode 100644 drivers/clk/sifive/fu540-prci.h create mode 100644 drivers/clk/sifive/fu740-prci.c create mode 100644 drivers/clk/sifive/fu740-prci.h create mode 100644 drivers/clk/sifive/sifive-prci.c create mode 100644 drivers/clk/sifive/sifive-prci.h diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig index dcf099447b..05463b2625 100644 --- a/arch/riscv/cpu/fu540/Kconfig +++ b/arch/riscv/cpu/fu540/Kconfig @@ -18,7 +18,7 @@ config SIFIVE_FU540 imply SPL_LOAD_FIT imply SMP imply CLK_SIFIVE - imply CLK_SIFIVE_FU540_PRCI + imply CLK_SIFIVE_PRCI imply SIFIVE_SERIAL imply MACB imply MII diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig index c4d0a1f9b1..20fc004b59 100644 --- a/drivers/clk/sifive/Kconfig +++ b/drivers/clk/sifive/Kconfig @@ -6,11 +6,11 @@ config CLK_SIFIVE help SoC drivers for SiFive Linux-capable SoCs. -config CLK_SIFIVE_FU540_PRCI - bool "PRCI driver for SiFive FU540 SoCs" +config CLK_SIFIVE_PRCI + bool "PRCI driver for SiFive SoCs" depends on CLK_SIFIVE select CLK_ANALOGBITS_WRPLL_CLN28HPC help Supports the Power Reset Clock interface (PRCI) IP block found in - FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC, - enable this driver. + FU540/FU740 SoCs. If this kernel is meant to run on a SiFive FU540/ + FU740 SoCs, enable this driver. diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile index b224279afb..51348b1ddc 100644 --- a/drivers/clk/sifive/Makefile +++ b/drivers/clk/sifive/Makefile @@ -1,3 +1,5 @@ # SPDX-License-Identifier: GPL-2.0+ -obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o +obj-y += sifive-prci.o + +obj-$(CONFIG_CLK_SIFIVE_PRCI) += fu540-prci.o fu740-prci.o diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c index b3882d0b77..ceb2c6fab0 100644 --- a/drivers/clk/sifive/fu540-prci.c +++ b/drivers/clk/sifive/fu540-prci.c @@ -5,6 +5,8 @@ * Copyright (C) 2018 SiFive, Inc. * Wesley Terpstra * Paul Walmsley + * Zong Li + * Pragnesh Patel * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -15,632 +17,48 @@ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * - * The FU540 PRCI implements clock and reset control for the SiFive - * FU540-C000 chip. This driver assumes that it has sole control - * over all PRCI resources. - * - * This driver is based on the PRCI driver written by Wesley Terpstra. - * - * Refer, commit 999529edf517ed75b56659d456d221b2ee56bb60 of: - * https://github.com/riscv/riscv-linux - * * References: * - SiFive FU540-C000 manual v1p0, Chapter 7 "Clocking and Reset" */ -#include -#include -#include -#include -#include -#include -#include -#include #include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -/* - * EXPECTED_CLK_PARENT_COUNT: how many parent clocks this driver expects: - * hfclk and rtcclk - */ -#define EXPECTED_CLK_PARENT_COUNT 2 - -/* - * Register offsets and bitmasks - */ - -/* COREPLLCFG0 */ -#define PRCI_COREPLLCFG0_OFFSET0x4 -#define PRCI_COREPLLCFG0_DIVR_SHIFT0 -#define PRCI_COREPLLCFG0_DIVR_MASK (0x3f << PRCI_COREPLLCFG0_DIVR_SHIFT) -#define PRCI_COREPLLCFG0_DIVF_SHIFT6 -#define PRCI_COREPLLCFG0_DIVF_MASK (0x1ff << PRCI_COREPLLCFG0_DIVF_SHIFT) -#define PRCI_COREPLLCFG0_DIVQ_SHIFT15 -#define PRCI_COREPLLCFG0_DIVQ_MASK (0x7 << PRCI_COREPLLCFG0_DIVQ_SHIFT) -#define PRCI_COREPLLCFG0_RANGE_SHIFT 18 -#define PRCI_COREPLLCFG0_RANGE_MASK(0x7 << PRCI_COREPLLCFG0_RANGE_SHIFT) -#define PRCI_COREPLLCFG0_BYPASS_SHIFT 24 -#define PRCI_COREPLLCFG0_BYPASS_MASK (0x1 << PRCI_COREPLLCFG0_BYPASS_SHIFT) -#define PRCI_COREPLLCFG0_FSE_SHIFT 25 -#define PRCI_COREPLLCFG0_FSE_MASK (0x1 << PRCI_COREPLLCFG0_FSE_SHIFT) -#define PRCI_COREPLLCFG0_LOCK_SHIFT31 -#define PRCI_COREPLLCFG0_LOCK_MASK (0x1 << PRCI_COREPLLCFG0_LOCK_SHIFT) - -/* COREPLLCFG1 */ -#define PRCI_COREPLLCFG1_OFFSET0x8 -#define
[PATCH v9 4/8] drivers: pci: add pcie support for fu740
Add pcie driver for SiFive fu740, the driver depends on
fu740 gpio, clk and reset driver to do init. Force running at Gen1
for better capatible enumeration.
Several devices are tested:
a) M.2 NVMe SSD
b) USB-to-PCI adapter
c) Ethernet adapter (E1000 compatible)
Signed-off-by: Green Wan
Reviewed-by: Neil Armstrong
---
drivers/pci/Kconfig | 10 +
drivers/pci/Makefile | 1 +
drivers/pci/pcie_dw_sifive.c | 507 +++
3 files changed, 518 insertions(+)
create mode 100644 drivers/pci/pcie_dw_sifive.c
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index d5b6018b3d..b2b7b253f8 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -97,6 +97,16 @@ config PCIE_DW_MVEBU
Armada-8K SoCs. The PCIe controller on Armada-8K is based on
DesignWare hardware.
+config PCIE_DW_SIFIVE
+ bool "Enable SiFive FU740 PCIe"
+ depends on CLK_SIFIVE_PRCI
+ depends on RESET_SIFIVE
+ depends on SIFIVE_GPIO
+ select PCIE_DW_COMMON
+ help
+ Say Y here if you want to enable PCIe controller support on
+ FU740.
+
config PCIE_FSL
bool "FSL PowerPC PCIe support"
depends on DM_PCI
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 1f741786a0..c742bb2c94 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -54,3 +54,4 @@ obj-$(CONFIG_PCIE_DW_MESON) += pcie_dw_meson.o
obj-$(CONFIG_PCI_BRCMSTB) += pcie_brcmstb.o
obj-$(CONFIG_PCI_OCTEONTX) += pci_octeontx.o
obj-$(CONFIG_PCIE_OCTEON) += pcie_octeon.o
+obj-$(CONFIG_PCIE_DW_SIFIVE) += pcie_dw_sifive.o
diff --git a/drivers/pci/pcie_dw_sifive.c b/drivers/pci/pcie_dw_sifive.c
new file mode 100644
index 00..fac3f18237
--- /dev/null
+++ b/drivers/pci/pcie_dw_sifive.c
@@ -0,0 +1,507 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * SiFive FU740 DesignWare PCIe Controller
+ *
+ * Copyright (C) 2020-2021 SiFive, Inc.
+ *
+ * Based in early part on the i.MX6 PCIe host controller shim which is:
+ *
+ * Copyright (C) 2013 Kosagi
+ * http://www.kosagi.com
+ *
+ * Based on driver from author: Alan Mikhak
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pcie_dw_common.h"
+
+struct pcie_sifive {
+ /* Must be first member of the struct */
+ struct pcie_dw dw;
+
+ /* private control regs */
+ void __iomem *priv_base;
+
+ /* reset, power, clock resources */
+ int sys_int_pin;
+ struct gpio_desc pwren_gpio;
+ struct gpio_desc reset_gpio;
+ struct clk aux_ck;
+ struct reset_ctl reset;
+};
+
+enum pcie_sifive_devtype {
+ SV_PCIE_UNKNOWN_TYPE = 0,
+ SV_PCIE_ENDPOINT_TYPE = 1,
+ SV_PCIE_HOST_TYPE = 3
+};
+
+#define ASSERTION_DELAY100
+#define PCIE_PERST_ASSERT 0x0
+#define PCIE_PERST_DEASSERT0x1
+#define PCIE_PHY_RESET 0x1
+#define PCIE_PHY_RESET_DEASSERT0x0
+#define GPIO_LOW 0x0
+#define GPIO_HIGH 0x1
+#define PCIE_PHY_SEL 0x1
+
+#define sv_info(sv, fmt, arg...) printf(fmt, ## arg)
+#define sv_warn(sv, fmt, arg...) printf(fmt, ## arg)
+#define sv_debug(sv, fmt, arg...) debug(fmt, ## arg)
+#define sv_err(sv, fmt, arg...)printf(fmt, ## arg)
+
+/* Doorbell Interface */
+#define DBI_OFFSET 0x0
+#define DBI_SIZE 0x1000
+
+#define PL_OFFSET 0x700
+
+#define PHY_DEBUG_R0 (PL_OFFSET + 0x28)
+
+#define PHY_DEBUG_R1 (PL_OFFSET + 0x2c)
+#define PHY_DEBUG_R1_LINK_UP (0x1 << 4)
+#define PHY_DEBUG_R1_LINK_IN_TRAINING (0x1 << 29)
+
+#define PCIE_MISC_CONTROL_10x8bc
+#define DBI_RO_WR_EN BIT(0)
+
+/* pcie reset */
+#define PCIEX8MGMT_PERST_N 0x0
+
+/* LTSSM */
+#define PCIEX8MGMT_APP_LTSSM_ENABLE0x10
+#define LTSSM_ENABLE_BIT BIT(0)
+
+/* phy reset */
+#define PCIEX8MGMT_APP_HOLD_PHY_RST0x18
+
+/* device type */
+#define PCIEX8MGMT_DEVICE_TYPE 0x708
+#define DEVICE_TYPE_EP 0x0
+#define DEVICE_TYPE_RC 0x4
+
+/* phy control registers*/
+#define PCIEX8MGMT_PHY0_CR_PARA_ADDR 0x860
+#define PCIEX8MGMT_PHY0_CR_PARA_RD_EN 0x870
+#define PCIEX8MGMT_PHY0_CR_PARA_RD_DATA0x878
+#define PCIEX8MGMT_PHY0_CR_PARA_SEL0x880
+#define PCIEX8MGMT_PHY0_CR_PARA_WR_DATA0x888
+#define PCIEX8MGMT_PHY0_CR_PARA_WR_EN 0x890
+#define PCIEX8MGMT_PHY0_CR_PARA_ACK0x898
+#define PCIEX8MGMT_PHY1_CR_PARA_ADDR 0x8a0
+#define PCIEX8MGMT_PHY1_CR_PARA_RD_EN 0x8b0
+#define PCIEX8MGMT_PHY1_CR_PARA_RD_DATA0x8b8
+#define PCIEX8MGMT_PHY1_CR_PARA_SEL0x8c0
+#define PCIEX8MGMT_PHY1_CR_PARA_WR_DATA0x8c8
+#define PCIEX8MGMT_PHY1_CR_PARA_WR_EN 0x8d0
+#define PCIEX8MGMT_PHY1_CR_PARA_ACK0x8d8
+
+#define P
[PATCH v9 3/8] drivers: ram: sifive: rename fu540_ddr and add fu740 support
Rename fu540_ddr.c to sifive_ddr.c and add fu740 support
Signed-off-by: Green Wan
Reviewed-by: Bin Meng
---
drivers/ram/sifive/Kconfig| 8 +-
drivers/ram/sifive/Makefile | 2 +-
.../ram/sifive/{fu540_ddr.c => sifive_ddr.c} | 89 ++-
3 files changed, 50 insertions(+), 49 deletions(-)
rename drivers/ram/sifive/{fu540_ddr.c => sifive_ddr.c} (81%)
diff --git a/drivers/ram/sifive/Kconfig b/drivers/ram/sifive/Kconfig
index 08de692e02..0aaac02656 100644
--- a/drivers/ram/sifive/Kconfig
+++ b/drivers/ram/sifive/Kconfig
@@ -5,9 +5,9 @@ config RAM_SIFIVE
help
This enables support for ram drivers of SiFive SoCs.
-config SIFIVE_FU540_DDR
- bool "SiFive FU540 DDR driver"
+config SIFIVE_DDR
+ bool "SiFive DDR driver"
depends on RAM_SIFIVE
- default y if TARGET_SIFIVE_UNLEASHED
+ default y if TARGET_SIFIVE_UNLEASHED || TARGET_SIFIVE_UNMATCHED
help
- This enables DDR support for the platforms based on SiFive FU540 SoC.
+ This enables DDR support for the platforms based on SiFive SoC.
diff --git a/drivers/ram/sifive/Makefile b/drivers/ram/sifive/Makefile
index d66efec264..4ef89f85bb 100644
--- a/drivers/ram/sifive/Makefile
+++ b/drivers/ram/sifive/Makefile
@@ -3,4 +3,4 @@
# Copyright (c) 2020 SiFive, Inc
#
-obj-$(CONFIG_SIFIVE_FU540_DDR) += fu540_ddr.o
+obj-$(CONFIG_SIFIVE_DDR) += sifive_ddr.o
diff --git a/drivers/ram/sifive/fu540_ddr.c b/drivers/ram/sifive/sifive_ddr.c
similarity index 81%
rename from drivers/ram/sifive/fu540_ddr.c
rename to drivers/ram/sifive/sifive_ddr.c
index c0653bb897..ba18466033 100644
--- a/drivers/ram/sifive/fu540_ddr.c
+++ b/drivers/ram/sifive/sifive_ddr.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
/*
- * (C) Copyright 2020 SiFive, Inc.
+ * (C) Copyright 2020-2021 SiFive, Inc.
*
* Authors:
* Pragnesh Patel
@@ -65,16 +65,16 @@
DECLARE_GLOBAL_DATA_PTR;
-struct fu540_ddrctl {
+struct sifive_ddrctl {
volatile u32 denali_ctl[265];
};
-struct fu540_ddrphy {
+struct sifive_ddrphy {
volatile u32 denali_phy[1215];
};
/**
- * struct fu540_ddr_info
+ * struct sifive_ddr_info
*
* @dev : pointer for the device
* @info: UCLASS RAM information
@@ -83,23 +83,23 @@ struct fu540_ddrphy {
* @ctrl: DDR control base address
* @physical_filter_ctrl: DDR physical filter control base address
*/
-struct fu540_ddr_info {
+struct sifive_ddr_info {
struct udevice *dev;
struct ram_info info;
- struct fu540_ddrctl *ctl;
- struct fu540_ddrphy *phy;
+ struct sifive_ddrctl *ctl;
+ struct sifive_ddrphy *phy;
struct clk ddr_clk;
u32 *physical_filter_ctrl;
};
#if defined(CONFIG_SPL_BUILD)
-struct fu540_ddr_params {
- struct fu540_ddrctl pctl_regs;
- struct fu540_ddrphy phy_regs;
+struct sifive_ddr_params {
+ struct sifive_ddrctl pctl_regs;
+ struct sifive_ddrphy phy_regs;
};
struct sifive_dmc_plat {
- struct fu540_ddr_params ddr_params;
+ struct sifive_ddr_params ddr_params;
};
/*
@@ -118,7 +118,7 @@ static void sdram_copy_to_reg(volatile u32 *dest,
}
}
-static void fu540_ddr_setup_range_protection(volatile u32 *ctl, u64 end_addr)
+static void sifive_ddr_setup_range_protection(volatile u32 *ctl, u64 end_addr)
{
u32 end_addr_16kblocks = ((end_addr >> 14) & 0x7F) - 1;
@@ -135,8 +135,8 @@ static void fu540_ddr_setup_range_protection(volatile u32
*ctl, u64 end_addr)
0x1 << PORT_ADDR_PROTECTION_EN_OFFSET);
}
-static void fu540_ddr_start(volatile u32 *ctl, u32 *physical_filter_ctrl,
- u64 ddr_end)
+static void sifive_ddr_start(volatile u32 *ctl, u32 *physical_filter_ctrl,
+u64 ddr_end)
{
volatile u64 *filterreg = (volatile u64 *)physical_filter_ctrl;
@@ -149,7 +149,7 @@ static void fu540_ddr_start(volatile u32 *ctl, u32
*physical_filter_ctrl,
filterreg[0] = 0x0f00UL | (ddr_end >> 2);
}
-static void fu540_ddr_check_errata(u32 regbase, u32 updownreg)
+static void sifive_ddr_check_errata(u32 regbase, u32 updownreg)
{
u64 fails = 0;
u32 dq= 0;
@@ -202,7 +202,7 @@ static void fu540_ddr_check_errata(u32 regbase, u32
updownreg)
}
}
-static u64 fu540_ddr_phy_fixup(volatile u32 *ddrphyreg)
+static u64 sifive_ddr_phy_fixup(volatile u32 *ddrphyreg)
{
u32 slicebase = 0;
@@ -213,7 +213,7 @@ static u64 fu540_ddr_phy_fixup(volatile u32 *ddrphyreg)
for (u32 reg = 0; reg < 4; reg++) {
u32 updownreg = readl(regbase + reg + ddrphyreg);
- fu540_ddr_check_errata(regbase, updownreg);
+ sifive_ddr_check_errata(regbase, updownreg);
}
slicebase += 128;
}
[PATCH v9 1/8] riscv: cpu: fu740: Add support for cpu fu740
Add SiFive fu740 cpu to support RISC-V arch
Signed-off-by: Green Wan
Reviewed-by: Bin Meng
---
arch/riscv/Kconfig| 1 +
arch/riscv/cpu/fu740/Kconfig | 37 +++
arch/riscv/cpu/fu740/Makefile | 12 +
arch/riscv/cpu/fu740/cache.c | 55 +++
arch/riscv/cpu/fu740/cpu.c| 22 +
arch/riscv/cpu/fu740/dram.c | 38
arch/riscv/cpu/fu740/spl.c| 23 ++
arch/riscv/include/asm/arch-fu740/cache.h | 14 ++
arch/riscv/include/asm/arch-fu740/clk.h | 14 ++
arch/riscv/include/asm/arch-fu740/gpio.h | 38
arch/riscv/include/asm/arch-fu740/reset.h | 13 ++
arch/riscv/include/asm/arch-fu740/spl.h | 14 ++
12 files changed, 281 insertions(+)
create mode 100644 arch/riscv/cpu/fu740/Kconfig
create mode 100644 arch/riscv/cpu/fu740/Makefile
create mode 100644 arch/riscv/cpu/fu740/cache.c
create mode 100644 arch/riscv/cpu/fu740/cpu.c
create mode 100644 arch/riscv/cpu/fu740/dram.c
create mode 100644 arch/riscv/cpu/fu740/spl.c
create mode 100644 arch/riscv/include/asm/arch-fu740/cache.h
create mode 100644 arch/riscv/include/asm/arch-fu740/clk.h
create mode 100644 arch/riscv/include/asm/arch-fu740/gpio.h
create mode 100644 arch/riscv/include/asm/arch-fu740/reset.h
create mode 100644 arch/riscv/include/asm/arch-fu740/spl.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 82e10da11e..81c524600e 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -61,6 +61,7 @@ source "board/sipeed/maix/Kconfig"
# platform-specific options below
source "arch/riscv/cpu/ax25/Kconfig"
source "arch/riscv/cpu/fu540/Kconfig"
+source "arch/riscv/cpu/fu740/Kconfig"
source "arch/riscv/cpu/generic/Kconfig"
# architecture-specific options below
diff --git a/arch/riscv/cpu/fu740/Kconfig b/arch/riscv/cpu/fu740/Kconfig
new file mode 100644
index 00..3a5f6e47f5
--- /dev/null
+++ b/arch/riscv/cpu/fu740/Kconfig
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2020-2021 SiFive, Inc
+# Pragnesh Patel
+
+config SIFIVE_FU740
+ bool
+ select ARCH_EARLY_INIT_R
+ select RAM
+ select SPL_RAM if SPL
+ imply CPU
+ imply CPU_RISCV
+ imply RISCV_TIMER if (RISCV_SMODE || SPL_RISCV_SMODE)
+ imply SPL_SIFIVE_CLINT
+ imply CMD_CPU
+ imply SPL_CPU
+ imply SPL_OPENSBI
+ imply SPL_LOAD_FIT
+ imply SMP
+ imply CLK_SIFIVE
+ imply CLK_SIFIVE_PRCI
+ imply SIFIVE_SERIAL
+ imply MACB
+ imply MII
+ imply SPI
+ imply SPI_SIFIVE
+ imply MMC
+ imply MMC_SPI
+ imply MMC_BROKEN_CD
+ imply CMD_MMC
+ imply DM_GPIO
+ imply SIFIVE_GPIO
+ imply CMD_GPIO
+ imply MISC
+ imply SIFIVE_OTP
+ imply DM_PWM
+ imply PWM_SIFIVE
diff --git a/arch/riscv/cpu/fu740/Makefile b/arch/riscv/cpu/fu740/Makefile
new file mode 100644
index 00..5ef8ac18a7
--- /dev/null
+++ b/arch/riscv/cpu/fu740/Makefile
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2020-2021 SiFive, Inc
+# Pragnesh Patel
+
+ifeq ($(CONFIG_SPL_BUILD),y)
+obj-y += spl.o
+else
+obj-y += dram.o
+obj-y += cpu.o
+obj-y += cache.o
+endif
diff --git a/arch/riscv/cpu/fu740/cache.c b/arch/riscv/cpu/fu740/cache.c
new file mode 100644
index 00..680955c9e3
--- /dev/null
+++ b/arch/riscv/cpu/fu740/cache.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020-2021 SiFive, Inc
+ *
+ * Authors:
+ * Pragnesh Patel
+ */
+
+#include
+#include
+#include
+#include
+
+/* Register offsets */
+#define L2_CACHE_CONFIG0x000
+#define L2_CACHE_ENABLE0x008
+
+#define MASK_NUM_WAYS GENMASK(15, 8)
+#define NUM_WAYS_SHIFT 8
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int cache_enable_ways(void)
+{
+ const void *blob = gd->fdt_blob;
+ int node;
+ fdt_addr_t base;
+ u32 config;
+ u32 ways;
+
+ volatile u32 *enable;
+
+ node = fdt_node_offset_by_compatible(blob, -1,
+"sifive,fu740-c000-ccache");
+
+ if (node < 0)
+ return node;
+
+ base = fdtdec_get_addr_size_auto_parent(blob, 0, node, "reg", 0,
+ NULL, false);
+ if (base == FDT_ADDR_T_NONE)
+ return FDT_ADDR_T_NONE;
+
+ config = readl((volatile u32 *)base + L2_CACHE_CONFIG);
+ ways = (config & MASK_NUM_WAYS) >> NUM_WAYS_SHIFT;
+
+ enable = (volatile u32 *)(base + L2_CACHE_ENABLE);
+
+ /* memory barrier */
+ mb();
+ (*enable) = ways - 1;
+ /* memory barrier */
+ mb();
+ return 0;
+}
diff --git a/arch/riscv/cpu/fu740/cpu.c b/arch/riscv/cpu/fu740/cpu.c
new file mode 100644
index 00..f13c18942f
--- /dev/null
+++ b/arch/riscv/cpu/fu740/cpu.c
@@ -0,0 +1,22 @@
+// SPDX-Lice
[PATCH v9 0/8] Add FU740 chip and HiFive Unmatched board support
This patch set is to add SiFive fu740 chip and HiFive Unmatched board support. Patches are split into several parts: - [PATCH v9 1/8] support for fu740 cpu - [PATCH v9 2/8] support for fu740 clk driver - [PATCH v9 3/8] rename and support for fu740 ram driver - [PATCH v9 4/8] add pcie driver - [PATCH v9 5/8] dts for SiFive fu740 - [PATCH v9 6/8] dts for SiFive Unmatched board - [PATCH v9 7/8] add Unmatched board support - [PATCH v9 8/8] clear feature disable CSR Description - For fu740 cpu support, reuse most of fu540 cpu. - For prci driver, add one abstract layer to separate fu540 and fu740. Move orignal fu540 code to separate files. - For pcie driver, it depends on gpio, prci, clk and reset drivers to do init&reset works. Also based on pcie_dw_common.c - Align with Linux DT file. Tests and patch checks - Able to boot both unmatched and unleashed boards. - PCIe tests . M.2 NVMe SSD . e1000 compatibale ethernet adapter (ping&tftpboot) . pci-to-usb adapter(usb mass storage) - checkpatch is performed. To keep code derived from other boards the same, ignore some warnings/errors in [PATCH 7/8]. Changlogs - V9 . applied http://patchwork.ozlabs.org/project/uboot/patch/20210511120412.25065-1-bmeng...@gmail.com/ . append clear feature disable CSR patch to the last - V8 . Add #include back to sifive_clint.c in [PATCH v8 1/7] . Remove unused CLK_SIFIVE_FU540_PRCI from Kconfig [PATCH v8 2/8] and remove CONFIG_CLK_SIFIVE_PRCI=y from unleashed config in [PATCH v8 7/7] . Remove ECAM compatible string to align with Linux pcie driver and add Reviewed-by to [PATCH v8 4/7] . Drop last patch [PATCH v7 8/8] for drivers/net/macb.c and use the same compatible string, 'sifive,fu540-c000-gem', to align with Linux driver. - V7 . Rebase to latest master branch . Moved dts for fu740 patch [v6 1/7] to [v7 5/8] and seperate dts of Unmatched board from [v6 6/7] into [v7 6/8] . Applied PCIe refactoring patch to base on the common code in pcie_dw_common.c - V6 . Remove redundant DT string for 1.2GHz CPU clock and squash to [1/7] - V5 . Fix unleashed build error in patch [6/8] . Append one more set for 1.2GHz CPU speed . Add "#include " back to sifive_ddr.c . Add Reviewed-by to [4/8] and [7/8] - V4 . fixed incorrect file name in ./board/sifive/unmatched/Makefile . fixed link in doc/board/sifive/index.rst, passed 'make htmldocs' - V3 . Rebase to unleashed rename v2 patch . Rename doc/board/sifive/unmatched.rst board/sifive/unmatched/unmatched.c . Fix tail whitespace . Add 'git mv' info to ram driver and merge patch back to one . Add comment to macb driver for PLL hardware quirk . Add reviewed-by to patch [6/7] . Add 'gpio-poweroff' node for upcoming opensbi integration - V2 . Rebase to unleashed rename patch . remove unnessaary fu540 changes . split ram driver patch into 2 to keep 'git mv' info . use a shorter name for unmatched support . Remove redundant&incorrect temperature-sensor in DT . Remove unnecessary USB EHCI & OHCI from defconfig . Revised fu740 doc . Fixed year of copyright . Add reviewed-by received in v1 patch Green Wan (8): riscv: cpu: fu740: Add support for cpu fu740 drivers: clk: add fu740 support drivers: ram: sifive: rename fu540_ddr and add fu740 support drivers: pci: add pcie support for fu740 riscv: dts: add fu740 support riscv: dts: add SiFive Unmatched board support board: sifive: add HiFive Unmatched board support riscv: cpu: fu740: clear feature disable CSR arch/riscv/Kconfig|5 + arch/riscv/cpu/fu540/Kconfig |2 +- arch/riscv/cpu/fu740/Kconfig | 37 + arch/riscv/cpu/fu740/Makefile | 12 + arch/riscv/cpu/fu740/cache.c | 55 + arch/riscv/cpu/fu740/cpu.c| 22 + arch/riscv/cpu/fu740/dram.c | 38 + arch/riscv/cpu/fu740/spl.c| 38 + arch/riscv/dts/Makefile |1 + arch/riscv/dts/fu740-c000-u-boot.dtsi | 105 ++ arch/riscv/dts/fu740-c000.dtsi| 329 .../dts/fu740-hifive-unmatched-a00-ddr.dtsi | 1489 + .../dts/hifive-unmatched-a00-u-boot.dtsi | 40 + arch/riscv/dts/hifive-unmatched-a00.dts | 259 +++ arch/riscv/include/asm/arch-fu740/cache.h | 14 + arch/riscv/include/asm/arch-fu740/clk.h | 14 + arch/riscv/include/asm/arch-fu740/gpio.h | 38 + arch/riscv/include/asm/arch-fu740/reset.h | 13 + arch/riscv/include/asm/arch-fu740/spl.h | 14 + board/sifive/unleashed/Kconfig|1 + board/sifive/unmatched/Kconfig| 50 + board/sifive/unmatched/MAINTAINERS|9 + board/sifive/unmatched/Makefile
[RFC PATCH 2/2] global-data.h: add build-time sanity check of sizeof(struct global_data)
The layout and contents of struct global_data depends on a lot of
CONFIG_* preprocessor macros, not all of which are entirely converted
to Kconfig - not to mention weird games played here and there. This
can result in one translation unit using one definition of struct
global_data while the actual layout is another.
That can be very hard to debug. But we already have a mechanism that
can help catch such bugs at build time, namely the asm-offsets
machinery which is necessary anyway to provide assembly code with the
necessary constants. So make sure that every C translation unit that
include global_data.h actually sees the same size of struct
global_data as that which was seen by the asm-offsets.c TU.
It is likely that this patch will break the build of some boards. For
example, without the patch from Matt Merhar
(https://lists.denx.de/pipermail/u-boot/2021-May/450135.html) or some
other fix, this breaks P2041RDB_defconfig:
CC arch/powerpc/lib/traps.o
AS arch/powerpc/cpu/mpc85xx/start.o
In file included from include/asm-generic/global_data.h:26,
from ./arch/powerpc/include/asm/global_data.h:109,
from include/init.h:21,
from arch/powerpc/lib/traps.c:7:
include/linux/build_bug.h:99:41: error: static assertion failed: "sizeof(struct
global_data) == GD_SIZE"
99 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
| ^~
include/linux/build_bug.h:98:34: note: in expansion of macro ‘__static_assert’
98 | #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__,
#expr)
| ^~~
include/asm-generic/global_data.h:470:1: note: in expansion of macro
‘static_assert’
470 | static_assert(sizeof(struct global_data) == GD_SIZE);
| ^
make[1]: *** [scripts/Makefile.build:266: arch/powerpc/lib/traps.o] Error 1
make: *** [Makefile:1753: arch/powerpc/lib] Error 2
make: *** Waiting for unfinished jobs
Signed-off-by: Rasmus Villemoes
---
include/asm-generic/global_data.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 47921d27b1..1233ec0ed6 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
struct acpi_ctx;
struct driver_rt;
@@ -464,6 +466,9 @@ struct global_data {
char *smbios_version;
#endif
};
+#ifndef DO_DEPS_ONLY
+static_assert(sizeof(struct global_data) == GD_SIZE);
+#endif
/**
* gd_board_type() - retrieve board type
--
2.29.2
[RFC PATCH 1/2] build_bug.h: add wrapper for _Static_assert
[Linux commit 6bab69c65013bed5fce9f101a64a84d0385b3946] BUILD_BUG_ON() is a little annoying, since it cannot be used outside function scope. So one cannot put assertions about the sizeof() a struct next to the struct definition, but has to hide that in some more or less arbitrary function. Since gcc 4.6 (which is now also the required minimum), there is support for the C11 _Static_assert in all C modes, including gnu89. So add a simple wrapper for that. _Static_assert() requires a message argument, which is usually quite redundant (and I believe that bug got fixed at least in newer C++ standards), but we can easily work around that with a little macro magic, making it optional. For example, adding static_assert(sizeof(struct printf_spec) == 8); in vsprintf.c and modifying that struct to violate it, one gets ./include/linux/build_bug.h:78:41: error: static assertion failed: "sizeof(struct printf_spec) == 8" #define __static_assert(expr, msg, ...) _Static_assert(expr, "" msg "") godbolt.org suggests that _Static_assert() has been support by clang since at least 3.0.0. Signed-off-by: Rasmus Villemoes --- include/linux/build_bug.h | 19 +++ 1 file changed, 19 insertions(+) diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h index b7d22d6000..9c7088bafa 100644 --- a/include/linux/build_bug.h +++ b/include/linux/build_bug.h @@ -79,6 +79,25 @@ */ #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") +/** + * static_assert - check integer constant expression at build time + * + * static_assert() is a wrapper for the C11 _Static_assert, with a + * little macro magic to make the message optional (defaulting to the + * stringification of the tested expression). + * + * Contrary to BUILD_BUG_ON(), static_assert() can be used at global + * scope, but requires the expression to be an integer constant + * expression (i.e., it is not enough that __builtin_constant_p() is + * true for expr). + * + * Also note that BUILD_BUG_ON() fails the build if the condition is + * true, while static_assert() fails the build if the expression is + * false. + */ +#define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr) +#define __static_assert(expr, msg, ...) _Static_assert(expr, msg) + #endif /* __CHECKER__ */ #endif /* _LINUX_BUILD_BUG_H */ -- 2.29.2
[RFC PATCH 0/2] sizeof(gd_t) sanity checking
I haven't done a whole lot of testing of these, just enough to see that it normally works _and_ that it would catch the bug Matt reported. I don't have time or resources to find and fix the bugs this would reveal, hence just an RFC for people to consider. Rasmus Villemoes (2): build_bug.h: add wrapper for _Static_assert global-data.h: add build-time sanity check of sizeof(struct global_data) include/asm-generic/global_data.h | 5 + include/linux/build_bug.h | 19 +++ 2 files changed, 24 insertions(+) -- 2.29.2
Re: [PATCH] ARM: imx8m: verdin-imx8mm: Increase bootm size to 64 MiB
On 5/18/21 9:37 AM, Oleksandr Suvorov wrote: On Tue, May 18, 2021 at 1:40 AM Marek Vasut wrote: Uncompressed aarch64 kernel Image are rather large, increase the bootm size limit to 64 MiB to cater for that. Signed-off-by: Marek Vasut Marek, thanks for your fix! There is a typo in the comment message: "kernel Image are rather large" probably should be either "kernel Images are rather large" or "kernel Image is rather large". The Image is the filename (aarch64 image) and it is plural, so I think its neither of the options.
Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
Leo Liang 於 2021年5月18日 週二，下午3:38寫道： > On Fri, May 14, 2021 at 11:45:30AM +0800, Green Wan wrote: > > Hi Bin, > > > > Thanks, I'll include that revert. Just traced back the git log. My > original > > patch is based on fu740. I guess it was merged to fu540 since fu740 > series > > wasn't present yet. > > > > Hi Rick, > > > > Not sure whether you'll pick fu740 series soon or if any parts need more > > revisement. Do you prefer that I append both this revert and "disable > CSR" > > patch to fu740&unmatched patch series? If so, I will create v9 patch and > > include these 2 patches. > > > > Or if you prefer to keep them separate from fu740 series, we can wait for > > fu740&unmatche patch merge and I'll create a separate patch for this > revert > > and CSR disable. > > > > What do you think? Many thanks. > > > > Regards, > > - Green > > > > Hi Green, > > Could you please append the "disable CSR" patch to fu740 unmatched patch > and send a v9 patch ? Thanks! > > Best regards, > Leo > Sure, I think I can do it by today. > > On Wed, May 12, 2021 at 11:28 PM Bin Meng wrote: > > > > > Hi Green, > > > > > > On Wed, May 12, 2021 at 11:13 PM Green Wan > wrote: > > > > > > > > Yes, noted. This patch should be applied based on the fu740 port. > Thanks > > > for the reminder. > > > > > > > > > > Just to clarify, the reverted patch *content* should be in your fu740 > > > support series. > > > > > > @Rick, this revert patch itself should be applied in u-boot/master > > > now, as the mainline U-Boot does not boot on the Unleashed board. > > > > > > Regards, > > > Bin > > > >
Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
Hi Green, On Tue, May 18, 2021 at 3:38 PM Leo Liang wrote: > > On Fri, May 14, 2021 at 11:45:30AM +0800, Green Wan wrote: > > Hi Bin, > > > > Thanks, I'll include that revert. Just traced back the git log. My original > > patch is based on fu740. I guess it was merged to fu540 since fu740 series > > wasn't present yet. > > > > Hi Rick, > > > > Not sure whether you'll pick fu740 series soon or if any parts need more > > revisement. Do you prefer that I append both this revert and "disable CSR" > > patch to fu740&unmatched patch series? If so, I will create v9 patch and > > include these 2 patches. > > > > Or if you prefer to keep them separate from fu740 series, we can wait for > > fu740&unmatche patch merge and I'll create a separate patch for this revert > > and CSR disable. > > > > What do you think? Many thanks. > > > > Regards, > > - Green > > > > Hi Green, > > Could you please append the "disable CSR" patch to fu740 unmatched patch > and send a v9 patch ? Thanks! > I think you will need some update per this patch as well: http://patchwork.ozlabs.org/project/uboot/patch/20210511120412.25065-1-bmeng...@gmail.com/ Hi Leo, What's your plan for the binman patch series? If the binman patch series go first, Green needs to update Unmatched to use binman as well. Regards, Bin
Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
On Fri, May 14, 2021 at 11:45:30AM +0800, Green Wan wrote: > Hi Bin, > > Thanks, I'll include that revert. Just traced back the git log. My original > patch is based on fu740. I guess it was merged to fu540 since fu740 series > wasn't present yet. > > Hi Rick, > > Not sure whether you'll pick fu740 series soon or if any parts need more > revisement. Do you prefer that I append both this revert and "disable CSR" > patch to fu740&unmatched patch series? If so, I will create v9 patch and > include these 2 patches. > > Or if you prefer to keep them separate from fu740 series, we can wait for > fu740&unmatche patch merge and I'll create a separate patch for this revert > and CSR disable. > > What do you think? Many thanks. > > Regards, > - Green > Hi Green, Could you please append the "disable CSR" patch to fu740 unmatched patch and send a v9 patch ? Thanks! Best regards, Leo > On Wed, May 12, 2021 at 11:28 PM Bin Meng wrote: > > > Hi Green, > > > > On Wed, May 12, 2021 at 11:13 PM Green Wan wrote: > > > > > > Yes, noted. This patch should be applied based on the fu740 port. Thanks > > for the reminder. > > > > > > > Just to clarify, the reverted patch *content* should be in your fu740 > > support series. > > > > @Rick, this revert patch itself should be applied in u-boot/master > > now, as the mainline U-Boot does not boot on the Unleashed board. > > > > Regards, > > Bin > >
Re: [PATCH] ARM: imx8m: verdin-imx8mm: Increase bootm size to 64 MiB
On Tue, May 18, 2021 at 1:40 AM Marek Vasut wrote: > > Uncompressed aarch64 kernel Image are rather large, increase the bootm > size limit to 64 MiB to cater for that. > > Signed-off-by: Marek Vasut Marek, thanks for your fix! There is a typo in the comment message: "kernel Image are rather large" probably should be either "kernel Images are rather large" or "kernel Image is rather large". With that: Reviewed-by: Oleksandr Suvorov > Cc: Marcel Ziswiler > Cc: Max Krummenacher > Cc: Oleksandr Suvorov > --- > include/configs/verdin-imx8mm.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/configs/verdin-imx8mm.h b/include/configs/verdin-imx8mm.h > index e2a817891c2..7be5e5ddf11 100644 > --- a/include/configs/verdin-imx8mm.h > +++ b/include/configs/verdin-imx8mm.h > @@ -16,6 +16,8 @@ > #define CONFIG_SYS_UBOOT_BASE \ > (QSPI0_AMBA_BASE + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512) > > +#define CONFIG_SYS_BOOTM_LEN SZ_64M > + > #ifdef CONFIG_SPL_BUILD > #define CONFIG_SPL_STACK 0x92 > #define CONFIG_SPL_BSS_START_ADDR 0x91 > -- > 2.30.2 > -- Best regards Oleksandr Suvorov Toradex AG Ebenaustrasse 10 | 6048 Horw | Switzerland | T: +41 41 500 48 00
[PATCH] crypto: Add driver for Aspeed HACE
The HACE supports MD5, SHA1 and SHA2 family hash functions. This driver
uses it in a polling mode to perform hash calculations over buffers
placed in DRAM.
It registers a driver to allow the hardware's clocking to be enabled
using the clock framework.
Co-developed-by: Klaus Heinrich Kiwi
Signed-off-by: Klaus Heinrich Kiwi
Signed-off-by: Joel Stanley
---
configs/evb-ast2600_defconfig | 1 +
drivers/crypto/Kconfig| 19 +++
drivers/crypto/Makefile | 1 +
drivers/crypto/aspeed_hace.c | 256 ++
4 files changed, 277 insertions(+)
create mode 100644 drivers/crypto/aspeed_hace.c
diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index 91518dbe3589..52ae8e423bfd 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -45,6 +45,7 @@ CONFIG_REGMAP=y
CONFIG_SPL_OF_TRANSLATE=y
CONFIG_CLK=y
CONFIG_SPL_CLK=y
+CONFIG_ASPEED_HACE=y
CONFIG_DM_I2C=y
CONFIG_MISC=y
CONFIG_SPL_MISC=y
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 1ea116be7503..e92037d88906 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -2,4 +2,23 @@ menu "Hardware crypto devices"
source drivers/crypto/fsl/Kconfig
+config ASPEED_HACE
+ bool "ASPEED Hash and Crypto Engine"
+ depends on ASPEED_AST2600
+ imply SHA_HW_ACCEL
+ imply SHA_PROG_HW_ACCEL
+ imply SHA512
+ imply SHA512_ALGO
+ imply CMD_HASH
+ help
+Select this option to enable a driver for using the SHA engine in
+the ASPEED BMC SoCs.
+
+Enabling this allows the use of SHA operations in hardware without
requiring the
+SHA software implementations, saving code size.
+
+Due to hardware limitations it cannot be used with a FIT placed in SPI
+FLASH. Data can only be hashed if it is in SDRAM, making this relevant
+for MMC and network boot only.
+
endmenu
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index efbd1d3fca05..ac93b1295954 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -4,5 +4,6 @@
# http://www.samsung.com
obj-$(CONFIG_EXYNOS_ACE_SHA) += ace_sha.o
+obj-$(CONFIG_ASPEED_HACE) += aspeed_hace.o
obj-y += rsa_mod_exp/
obj-y += fsl/
diff --git a/drivers/crypto/aspeed_hace.c b/drivers/crypto/aspeed_hace.c
new file mode 100644
index ..941c1555fe5c
--- /dev/null
+++ b/drivers/crypto/aspeed_hace.c
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// (C) Copyright ASPEED Technology Inc.
+// Copyright 2021 IBM Corp.
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define ASPEED_HACE_STS0x1C
+#define HACE_RSA_ISR BIT(13)
+#define HACE_CRYPTO_ISR BIT(12)
+#define HACE_HASH_ISR BIT(9)
+#define HACE_RSA_BUSY BIT(2)
+#define HACE_CRYPTO_BUSY BIT(1)
+#define HACE_HASH_BUSYBIT(0)
+#define ASPEED_HACE_HASH_SRC 0x20
+#define ASPEED_HACE_HASH_DIGEST_BUFF 0x24
+#define ASPEED_HACE_HASH_KEY_BUFF 0x28
+#define ASPEED_HACE_HASH_DATA_LEN 0x2C
+#define HACE_SG_LAST BIT(31)
+#define ASPEED_HACE_HASH_CMD 0x30
+#define HACE_SHA_BE_ENBIT(3)
+#define HACE_MD5_LE_ENBIT(2)
+#define HACE_ALGO_MD5 0
+#define HACE_ALGO_SHA1BIT(5)
+#define HACE_ALGO_SHA224 BIT(6)
+#define HACE_ALGO_SHA256 (BIT(4) | BIT(6))
+#define HACE_ALGO_SHA512 (BIT(5) | BIT(6))
+#define HACE_ALGO_SHA384 (BIT(5) | BIT(6) | BIT(10))
+#define HACE_SG_ENBIT(18)
+
+#define ASPEED_MAX_SG 32
+
+struct aspeed_sg {
+ u32 len;
+ u32 addr;
+};
+
+struct aspeed_hash_ctx {
+ u32 method;
+ u32 digest_size;
+ u32 len;
+ u32 count;
+ struct aspeed_sg list[ASPEED_MAX_SG]; /* Must be 8 byte aligned */
+};
+
+struct aspeed_hace {
+ struct clk clk;
+};
+
+static phys_addr_t base;
+
+static int aspeed_hace_wait_completion(u32 reg, u32 flag, int timeout_us)
+{
+ u32 val;
+
+ return readl_poll_timeout(reg, val, (val & flag) == flag, timeout_us);
+}
+
+static int digest_object(const void *src, unsigned int length, void *digest,
u32 method)
+{
+ if (!((u32)src & BIT(31))) {
+ debug("HACE src out of bounds: can only copy from SDRAM\n");
+ return -EINVAL;
+ }
+
+ if ((u32)digest & 0x7) {
+ debug("HACE dest alignment incorrect: %p\n", digest);
+ return -EINVAL;
+ }
+
+ if (readl(base + ASPEED_HACE_STS) & HACE_HASH_BUSY) {
+ debug("HACE error: engine busy\n");
+ return -EBUSY;
+ }
+
+ /* Clear pending completion
Re: [PATCH] powerpc: fix regression in arch_initr_trap()
On 18/05/2021 07.50, Stefan Roese wrote:
> Hi Matt,
>
> On 17.05.21 19:32, Matt Merhar wrote:
>> The assembly output of the arch_initr_trap() function differed by a
>> single byte after common.h was removed from traps.c:
>>
>> fff49a18 :
>> fff49a18: 94 21 ff f0 stwu r1,-16(r1)
>> fff49a1c: 7c 08 02 a6 mflr r0
>> fff49a20: 90 01 00 14 stw r0,20(r1)
>> -fff49a24: 80 62 00 44 lwz r3,68(r2)
>> +fff49a24: 80 62 00 38 lwz r3,56(r2)
>> fff49a28: 4b ff 76 19 bl fff41040
>> fff49a2c: 80 01 00 14 lwz r0,20(r1)
>> fff49a30: 38 60 00 00 li r3,0
>> fff49a34: 38 21 00 10 addi r1,r1,16
>> fff49a38: 7c 08 03 a6 mtlr r0
>>
>> This was causing a consistent hard lockup during the MMC read / loading
>> of the QoriQ FMan firmware on a P2041RDB board.
>>
>> Re-adding the header causes identical assembly to be emitted and allows
>> the firmware loading and subsequent boot to succeed.
>>
>> Fixes: 401d1c4f5d ("common: Drop asm/global_data.h from common header")
>> Signed-off-by: Matt Merhar
>
> Did you try to investigate what exactly causes this difference in the
> assembly code, when the header is not included? Re-adding this header
> seems like "papering over" the real problem to me.
Running pahole on traps.o without and with that patch shows (I took
P2041RDB_defconfig)
struct global_data {
struct bd_info * bd; /* 0 4 */
long unsigned int flags;/* 4 4 */
unsigned int baudrate; /* 8 4 */
long unsigned int cpu_clk; /*12 4 */
long unsigned int bus_clk; /*16 4 */
long unsigned int pci_clk; /*20 4 */
long unsigned int mem_clk; /*24 4 */
long unsigned int have_console; /*28 4 */
long unsigned int env_addr; /*32 4 */
long unsigned int env_valid;/*36 4 */
long unsigned int env_has_init; /*40 4 */
intenv_load_prio;/*44 4 */
long unsigned int ram_base; /*48 4 */
/* XXX 4 bytes hole, try to pack */
phys_addr_tram_top; /*56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
long unsigned int relocaddr;/*64 4 */
vs
struct global_data {
struct bd_info * bd; /* 0 4 */
long unsigned int flags;/* 4 4 */
unsigned int baudrate; /* 8 4 */
long unsigned int cpu_clk; /*12 4 */
long unsigned int bus_clk; /*16 4 */
long unsigned int pci_clk; /*20 4 */
long unsigned int mem_clk; /*24 4 */
long unsigned int post_log_word;/*28 4 */
long unsigned int post_log_res; /*32 4 */
long unsigned int post_init_f_time; /*36 4 */
long unsigned int have_console; /*40 4 */
long unsigned int env_addr; /*44 4 */
long unsigned int env_valid;/*48 4 */
long unsigned int env_has_init; /*52 4 */
intenv_load_prio;/*56 4 */
long unsigned int ram_base; /*60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
phys_addr_tram_top; /*64 8 */
long unsigned int relocaddr;/*72 4 */
so it seems to be the
#if defined(CONFIG_POST)
in include/asm-generic/global_data.h which is broken or unreliable or
whatever the appropriate way to describe it is.
It would be nice if the linker could catch that kind of thing when
collecting debug info from various TUs.
Rasmus
