[PATCH] driver: rng: Do not check ARM_SMCCC_TRNG_VERSION
As described in the document SMC Calling Convention (ARM DEN 0028 1.5 F),
section 7 "Arm Architecture Calls", the SMC call SMCCC_ARCH_FEATURES is
not expected to support the function ID ARM_SMCCC_TRNG_VERSION. Trusted
Firmware-A follows up the specification in its implementation.
This commit removes the invocation to avoid the failure - which is a
wrong calling in U-boot. The later code invokes ARM_SMCCC_TRNG_VERSION
for retrieving the TRNG version, except it can read back the version
number, it also can be used to detect whether the TRNG is supported or
not.
Signed-off-by: Leo Yan
---
drivers/rng/smccc_trng.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rng/smccc_trng.c b/drivers/rng/smccc_trng.c
index f59b80666b..1da1affd8e 100644
--- a/drivers/rng/smccc_trng.c
+++ b/drivers/rng/smccc_trng.c
@@ -135,10 +135,6 @@ static bool smccc_trng_is_supported(void
(*invoke_fn)(unsigned long a0, unsigned
{
struct arm_smccc_res res;
- (*invoke_fn)(ARM_SMCCC_ARCH_FEATURES, ARM_SMCCC_TRNG_VERSION, 0, 0, 0,
0, 0, 0, &res);
- if (res.a0 == ARM_SMCCC_RET_NOT_SUPPORTED)
- return false;
-
(*invoke_fn)(ARM_SMCCC_TRNG_VERSION, 0, 0, 0, 0, 0, 0, 0, &res);
if (res.a0 & BIT(31))
return false;
--
2.34.1
Re: [PATCH v1 0/2] arm64: Fix building failure for Xen target
On Thu, May 04, 2023 at 03:54:57PM +0800, Leo Yan wrote: > This patch series is for building Xen target with Clang. > > The first patch is to fix building failure for Xen target, the second > patch is to add info for a linkage known issue when use Clang as > compiler. Gentle ping ... I saw my patches were rejected by EPAM, so I am afraid EPAM engineers cannot see these two patches, I will try to reach them offline. At meantine, it would be great if anyone could review on this list. Thanks! > Leo Yan (2): > arm64: Remove duplicated symbols > doc: Add info for building Xen target with Clang > > .../include/asm/boot0-linux-kernel-header.h | 2 -- > doc/build/clang.rst | 36 +++ > 2 files changed, 36 insertions(+), 2 deletions(-) > > -- > 2.39.2 >
[PATCH v1 2/2] doc: Add info for building Xen target with Clang
When build Xen target with Clang, the linker reports failure. This patch adds the related info in the documentation as a known issue and gives details for how to dismiss the building failure with Clang. Signed-off-by: Leo Yan --- doc/build/clang.rst | 36 1 file changed, 36 insertions(+) diff --git a/doc/build/clang.rst b/doc/build/clang.rst index 1d35616eb5..cc265506c2 100644 --- a/doc/build/clang.rst +++ b/doc/build/clang.rst @@ -74,3 +74,39 @@ simplified with a simple wrapper script - saved as #!/bin/sh exec clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd "$@" + + +Known Issues + + +When build U-boot for `xenguest_arm64_defconfig` target, it reports linkage +error: + +.. code-block:: bash + +aarch64-linux-gnu-ld.bfd: drivers/xen/hypervisor.o: in function `do_hypervisor_callback': +/home/leoy/Dev2/u-boot/drivers/xen/hypervisor.c:188: undefined reference to `__aarch64_swp8_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/hypervisor.o: in function `synch_test_and_set_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:40: undefined reference to `__aarch64_ldset1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/hypervisor.o: in function `synch_test_and_clear_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:28: undefined reference to `__aarch64_ldclr1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/hypervisor.o: in function `synch_test_and_set_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:40: undefined reference to `__aarch64_ldset1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/hypervisor.o: in function `synch_test_and_clear_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:28: undefined reference to `__aarch64_ldclr1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/events.o: in function `synch_test_and_clear_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:28: undefined reference to `__aarch64_ldclr1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/events.o: in function `synch_test_and_set_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:40: undefined reference to `__aarch64_ldset1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/gnttab.o: in function `gnttab_end_access': +/home/leoy/Dev2/u-boot/drivers/xen/gnttab.c:109: undefined reference to `__aarch64_cas2_acq_rel' +Segmentation fault + +To fix the failure, we need to append option `-mno-outline-atomics` in Clang +command to not generate local calls to out-of-line atomic operations: + +.. code-block:: bash + +make HOSTCC=clang xenguest_arm64_defconfig +make HOSTCC=clang CROSS_COMPILE=aarch64-linux-gnu- \ + CC="clang -target aarch64-linux-gnueabi -mno-outline-atomics" -j8 -- 2.39.2
[PATCH v1 1/2] arm64: Remove duplicated symbols
When build U-boot with clang with using commands: $ make HOSTCC=clang xenguest_arm64_defconfig $ make HOSTCC=clang CROSS_COMPILE=aarch64-linux-gnu- \ CC="clang -target aarch64-linux-gnueabi" -j8 The compiler reports error: /tmp/start-acdf31.s:330:1: error: symbol '_start' is already defined _start: ^ Because the symbol '_start' has been defined twice, one is defined in arch/arm/cpu/armv8/start.S, another is defined in the header boot0-linux-kernel-header.h. To fix building failure, this patch removes the symbol '_start' from boot0-linux-kernel-header.h. Signed-off-by: Leo Yan --- arch/arm/include/asm/boot0-linux-kernel-header.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/include/asm/boot0-linux-kernel-header.h b/arch/arm/include/asm/boot0-linux-kernel-header.h index c6cd76f32a..c930fea5fd 100644 --- a/arch/arm/include/asm/boot0-linux-kernel-header.h +++ b/arch/arm/include/asm/boot0-linux-kernel-header.h @@ -31,8 +31,6 @@ .long \sym\()_hi32 .endm -.globl _start -_start: /* * DO NOT MODIFY. Image header expected by Linux boot-loaders. */ -- 2.39.2
[PATCH v1 0/2] arm64: Fix building failure for Xen target
This patch series is for building Xen target with Clang. The first patch is to fix building failure for Xen target, the second patch is to add info for a linkage known issue when use Clang as compiler. Leo Yan (2): arm64: Remove duplicated symbols doc: Add info for building Xen target with Clang .../include/asm/boot0-linux-kernel-header.h | 2 -- doc/build/clang.rst | 36 +++ 2 files changed, 36 insertions(+), 2 deletions(-) -- 2.39.2
[PATCH] pci: Sort resources before assignment
A PCI device can request resource for multiple memory regions, e.g. a
PCI device tries to allocate prefetchable memory for two regions, one
region size is 0x1000_ and another is 0x1__. And the PCIe
controller provides prefetchable memory window size is 0x1_8000_,
thus in theory the PCIe controller can meet the memory requirement for
the PCI device:
0x1_8000_ > 0x1_1000_ (0x1000_ + 0x1__)
When allocate the memory region, pciauto_region_allocate() applies the
alignment for the start address, we can see the memory regions are
allocated as:
=> pci bar 1.0.0
ID BaseSizeWidth Type
--
0 0x8800 0x0400 32 MEM
1 0x8c00 0x0010 32 MEM
2 0x0010 0x1000 64 MEM Prefetchable
3 0x0011 0x0001 64 MEM Prefetchable
The problem is for the last memory region, we can see its start address
is 0x11__ and the size is 0x1__, therefore, these two
memory regions occupy memory size is:
0x11__ + 0x1__ - 0x10__ = 0x2__
The allocated memory region (0x2__) is out of the range, because
the maximum space provided by PCI controller is only 0x1_8000_.
To fix this issue, this patch sorts resources with descending, this can
give the priority for big chunk memory region, the big memory region is
allocated ahead before a small region, so that its start address does
not necessarily introduce big hole caused by the alignment, which is
finished by function pdev_sort_resources().
And we use another function pdev_assign_resources() to set BARs based on
the sorted list.
As result, we can see the updated memory regions are altered as below;
the end address is: 0x11__ + 0x1000_, which falls into the
permitted memory window.
=> pci bar 1.0.0
ID BaseSizeWidth Type
--
0 0x8800 0x0400 32 MEM
1 0x8c00 0x0010 32 MEM
2 0x0011 0x1000 64 MEM Prefetchable
3 0x0010 0x0001 64 MEM Prefetchable
Reported-by: Matsumoto Misako
Signed-off-by: Leo Yan
---
drivers/pci/pci_auto.c | 104 +++--
1 file changed, 79 insertions(+), 25 deletions(-)
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index c7968926a1..69c801fc62 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
#include "pci_internal.h"
/* the user can define CONFIG_SYS_PCI_CACHE_LINE_SIZE to avoid problems */
@@ -21,6 +23,69 @@
#define CONFIG_SYS_PCI_CACHE_LINE_SIZE 8
#endif
+struct pci_dev_resource {
+ struct list_head list;
+ int bar;
+ pci_size_t bar_size;
+ int found_mem64;
+ struct pci_region *bar_res;
+};
+
+/* Sort resources by bar size */
+static void pdev_sort_resources(struct pci_dev_resource *new,
+ struct list_head *head)
+{
+ struct pci_dev_resource *dev_res;
+ struct list_head *n;
+
+ /* Fallback is smallest one or list is empty */
+ n = head;
+ list_for_each_entry(dev_res, head, list) {
+ if (new->bar_size > dev_res->bar_size) {
+ n = &dev_res->list;
+ break;
+ }
+ }
+
+ /* Insert it just before n */
+ list_add_tail(&new->list, n);
+}
+
+static void pdev_assign_resources(struct udevice *dev, struct list_head *head)
+{
+ struct pci_dev_resource *dev_res;
+ int bar;
+ pci_addr_t bar_value;
+ int ret = 0;
+
+ list_for_each_entry(dev_res, head, list) {
+ ret = pciauto_region_allocate(dev_res->bar_res,
dev_res->bar_size,
+ &bar_value, dev_res->found_mem64);
+ if (ret)
+ printf("PCI: Failed autoconfig bar %x\n", dev_res->bar);
+
+ bar = dev_res->bar;
+ if (!ret) {
+ /* Write it out and update our limit */
+ dm_pci_write_config32(dev, bar, (u32)bar_value);
+
+ if (dev_res->found_mem64) {
+ bar += 4;
+ if (IS_ENABLED(CONFIG_SYS_PCI_64BIT))
+ dm_pci_write_config32(dev, bar,
+ (u32)(bar_value
>> 32));
+ else
+ /*
+* If we are a 64-bit decoder
Re: [U-Boot] [PATCH] ARMv8: fix bug for flush data cache by set/way
hi David, On 04/01/2014 11:25 AM, feng...@phytium.com.cn wrote: hi Leo, Please reference ARMv8-TRM, the associativity field does not have to be a power of 2. I made the same mistake with you previously and scott identify this. *发件人:* Leo Yan <mailto:l...@marvell.com> *发送时间:* 2014年3月31日, 星期一 9:11 *收件人:* u-boot <mailto:u-boot@lists.denx.de>, David Feng <mailto:feng...@phytium.com.cn>, Scott Wood <mailto:scottw...@freescale.com> *抄送:* Leo Yan <mailto:l...@marvell.com> When flush the d$ with set/way instruction, it need calculate the way's offset = log2(Associativity); but in current uboot's code, it use below formula to calculate the offset: log2(Associativity * 2 - 1), so finally it cannot flush data cache properly. Signed-off-by: Leo Yan --- arch/arm/cpu/armv8/cache.S |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S index 546a83e..256d2e2 100644 --- a/arch/arm/cpu/armv8/cache.S +++ b/arch/arm/cpu/armv8/cache.S @@ -30,9 +30,7 @@ ENTRY(__asm_flush_dcache_level) add x2, x2, #4 /* x2 <- log2(cache line size) */ mov x3, #0x3ff and x3, x3, x6, lsr #3 /* x3 <- max number of #ways */ - add w4, w3, w3 - sub w4, w4, 1 /* round up log2(#ways + 1) */ - clz w5, w4 /* bit position of #ways */ + clz w5, w3 /* bit position of #ways */ mov x4, #0x7fff and x4, x4, x6, lsr #13 /* x4 <- max number of #sets */ /* x1 <- cache level << 1 */ -- 1.7.9.5 Apologize for top post in previous email, resend the email again. I have checked the ARMv8's Architecture Reference Manual DDI0487A_a_armv8_arm.pdf chapter "C4.4.1 DC CISW, Data or unified Cache line Clean and Invalidate by Set/Way", u can see the description as below: SetWay, bits [31:4] Contains two fields: • Way, bits[31:32-A], the number of the way to operate on. • Set, bits[B-1:L], the number of the set to operate on. Bits[L-1:4] are RES0. A = Log2(ASSOCIATIVITY), L = Log2(LINELEN), B = (L + S), S = Log2(NSETS). ASSOCIATIVITY, LINELEN (line length, in bytes), and NSETS (number of sets) have their usual meanings and are the values for the cache level being operated on. The values of A and S are rounded up to the next integer. Also we have tested on ARMv8's soc, we found this issue will introduce the cache cannot flush properly into DDR so that kernel cannot boot up successfully. BTW, i compared with Linux kernel's code for flushing operations and just commit this patch to align with it. Thx, Leo Yan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv8: fix bug for flush data cache by set/way
hi David, I have checked the ARMv8's Architecture Reference Manual DDI0487A_a_armv8_arm.pdf chapter "C4.4.1 DC CISW, Data or unified Cache line Clean and Invalidate by Set/Way", u can see the description as below: SetWay, bits [31:4] Contains two fields: • Way, bits[31:32-A], the number of the way to operate on. • Set, bits[B-1:L], the number of the set to operate on. Bits[L-1:4] are RES0. A = Log2(ASSOCIATIVITY), L = Log2(LINELEN), B = (L + S), S = Log2(NSETS). ASSOCIATIVITY, LINELEN (line length, in bytes), and NSETS (number of sets) have their usual meanings and are the values for the cache level being operated on. The values of A and S are rounded up to the next integer. Also we have tested on ARMv8's soc, we found this issue will introduce the cache cannot flush properly into DDR so that kernel cannot boot up successfully. BTW, i compared with Linux kernel's code for flushing operations and just commit this patch to align with it. Thx, Leo Yan On 04/01/2014 11:25 AM, feng...@phytium.com.cn wrote: hi Leo, Please reference ARMv8-TRM, the associativity field does not have to be a power of 2. I made the same mistake with you previously and scott identify this. *发件人:* Leo Yan <mailto:l...@marvell.com> *发送时间:* 2014年3月31日, 星期一 9:11 *收件人:* u-boot <mailto:u-boot@lists.denx.de>, David Feng <mailto:feng...@phytium.com.cn>, Scott Wood <mailto:scottw...@freescale.com> *抄送:* Leo Yan <mailto:l...@marvell.com> When flush the d$ with set/way instruction, it need calculate the way's offset = log2(Associativity); but in current uboot's code, it use below formula to calculate the offset: log2(Associativity * 2 - 1), so finally it cannot flush data cache properly. Signed-off-by: Leo Yan --- arch/arm/cpu/armv8/cache.S |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S index 546a83e..256d2e2 100644 --- a/arch/arm/cpu/armv8/cache.S +++ b/arch/arm/cpu/armv8/cache.S @@ -30,9 +30,7 @@ ENTRY(__asm_flush_dcache_level) add x2, x2, #4 /* x2 <- log2(cache line size) */ mov x3, #0x3ff and x3, x3, x6, lsr #3 /* x3 <- max number of #ways */ - add w4, w3, w3 - sub w4, w4, 1 /* round up log2(#ways + 1) */ - clz w5, w4 /* bit position of #ways */ + clz w5, w3 /* bit position of #ways */ mov x4, #0x7fff and x4, x4, x6, lsr #13 /* x4 <- max number of #sets */ /* x1 <- cache level << 1 */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMv8: fix bug for flush data cache by set/way
When flush the d$ with set/way instruction, it need calculate the way's offset = log2(Associativity); but in current uboot's code, it use below formula to calculate the offset: log2(Associativity * 2 - 1), so finally it cannot flush data cache properly. Signed-off-by: Leo Yan --- arch/arm/cpu/armv8/cache.S |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S index 546a83e..256d2e2 100644 --- a/arch/arm/cpu/armv8/cache.S +++ b/arch/arm/cpu/armv8/cache.S @@ -30,9 +30,7 @@ ENTRY(__asm_flush_dcache_level) add x2, x2, #4 /* x2 <- log2(cache line size) */ mov x3, #0x3ff and x3, x3, x6, lsr #3 /* x3 <- max number of #ways */ - add w4, w3, w3 - sub w4, w4, 1 /* round up log2(#ways + 1) */ - clz w5, w4 /* bit position of #ways */ + clz w5, w3 /* bit position of #ways */ mov x4, #0x7fff and x4, x4, x6, lsr #13 /* x4 <- max number of #sets */ /* x1 <- cache level << 1 */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
