July 2023 - U-Boot

How u-boot can chain "grub" and booting a mainline kernel on my ARM Chromebook
by Mario Marietto 01 Jul '23

01 Jul '23

Hello. I would like to enable KVM virtualization on my old ARM Chromebook laptop,based on the Exynos5250 arm 32 bit cpu aka snow,model xe303c12. The first thing I did has been to dd the image below directly on the sd card : https://github.com/hexdump0815/imagebuilder/releases/download/220619-01/chr… and it worked like a charm,but kvm was disabled. So,I have started to look for a good documentation to understand how to enable kvm and I found this : http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromebook/ I've followed all the instructions and it worked,but only with Ubuntu 13.04 and 14.04. More upgraded ubuntu versions give a lot of problems and they don't work. So,I've thought about a fresh idea. What about to install the virtual open systems "non-verified u-boot" on the first partition like explained in the tutorial,and,instead of starting another u-boot after the original,can I chain grub with the kernel installed for example by the ubuntu jammy iso image created by "hexdump0815" ? To be honest I'm not sure if hexdump0815 used grub,but I will explain this later. Anyway,I've got the idea by reading here : https://unix.stackexchange.com/questions/599141/how-to-install-grub-bootloa… So,now,I'm going to explain what's the content of the partitions on my Frankenstein sd card. 1) /dev/sdh1 = unknown = 16 MB. I've created this partition by doing : $ sudo dd if=nv_uboot-snow.kpart of=/dev/sdh1 Where I've got the file nv_uboot-snow.kpart ? From here : http://www.virtualopensystems.com/downloads/guides/kvm_on_chromebook/nv_u-b… 2) /dev/sdh2 = unknown = 16 MB. This partition has been created by executing the following script : $ sudo ./scripts/sdcard.sh /dev/sdh 3) /dev/sdh3 = ext2 BOOT. Inside the partition /dev/sdh3 I have copied the following files and folders (taken from the hexdump0815 "chromebook_snow-armv7l-jammy.img.gz" file : a) dtb-5.18.1-stb-cbe+ = directory b) extlinux = directory c) extra = directory d) config.5.18.1-stb-cbe+ : file e) initrd.img-5.18.1-stb-cbe+ : file f) System.map-5.18.1-stb-cbe+ : file g) vmlinux.kpart-5.18.1-stb-cbe+ : file h) zImage-5.18.1-stb.cbe+ : file Inside the directory "dtb-5.18.1-stb-cbe+" there are the following files : a) exynos5250-snow.dtb b) exynos5250-snow-rev5.dtb c) exynos5250-spring.dtb Inside the directory "extlinux",there is the following file : a) extlinux.conf : that has the following content : TIMEOUT 30 DEFAULT linux-snow-rev4 MENU TITLE snow chromebook boot options # rev4 snow chromebook LABEL linux-snow-rev4 MENU LABEL linux rev4 snow LINUX ../zImage-5.18.1-stb-cbe+ INITRD ../initrd.img-5.18.1-stb-cbe+ FDT ../dtb-5.18.1-stb-cbe+/exynos5250-snow.dtb APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0 ipv6.disable=1 fsck.repair=yes noresume # rev5 snow chromebook LABEL linux-snow-rev5 MENU LABEL linux rev5 snow LINUX ../zImage-5.18.1-stb-cbe+ INITRD ../initrd.img-5.18.1-stb-cbe+ FDT ../dtb-5.18.1-stb-cbe+/exynos5250-snow-rev5.dtb APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0 ipv6.disable=1 fsck.repair=yes noresume # spring chromebook - untested LABEL linux-spring MENU LABEL linux spring LINUX ../zImage-5.18.1-stb-cbe+ INITRD ../initrd.img-5.18.1-stb-cbe+ # rev4 snow chromebook FDT ../dtb-5.18.1-stb-cbe+/exynos5250-spring.dtb APPEND console=tty1 root=LABEL=rootpart ro rootwait net.ifnames=0 ipv6.disable=1 fsck.repair=yes noresume Inside the extra directory there are the following files : a) kernel-chromebook_snow-legacy.tar.gz b) uboot.kpart.cbe-snow c) uboot.kpart.cbe-snow-alternative d) uboot.kpart.cbe-spring 4) /dev/sdh4 : inside here I have copied all the files of the jammy userland prepared by hexdump0818. That's all. What I want to do is if and how can I chainload the "non-verified u-boot" that is installed on the partition /dev/sdh1 with grub or whatever mechanism it is able to boot the hexdump0815 jammy iso image. As I repeat,the "non-verified u-boot" is produced by the script called "build.sh",that's stored inside the u-boot/scripts directory. And if what I want to do is impossible,can you explain to me how I can enable kvm on my chromebook arm,using the most recent kernel possible ? I already know that the support for kvm on arm 32 has been dropped on kernel 5.7,but for me to use a lower kernel than 5.7 is ok. I've been working on this project for a lot of months. I would like to see some progress. Thanks. -- Mario.

2 6

[PATCH v2 1/2] ARM: armv7: Add C wrapper for allow_unaligned()
by Marek Vasut 01 Jul '23

01 Jul '23

Rename current assembler implementation of allow_unaligned() to v7_arch_cp15_allow_unaligned() and add it into armv7.h header, then add C wrapper of allow_unaligned(). This fixes misbehavior when linking U-Boot on ARMv7a i.MX6Q, where the CPU specific allow_unaligned() implementation was ignored and instead the __weak allow_unaligned() implementation from lib/efi_loader/efi_setup.c was used, which led to "data abort" just before booting Linux via tftp, in efi_dp_from_file() -> path_to_uefi() -> utf16_put() . The problem is triggerd by c7c0ca37673 ("efi_loader: fix efi_dp_from_file()") . Adding the wrapper fixes the problem. Fixes: 78f90aaeecc ("arm: armv7: allow unaligned memory access") Signed-off-by: Marek Vasut <marex(a)denx.de> --- V2: Update Fixes tag and commit message --- Cc: Fabio Estevam <festevam(a)denx.de> Cc: Heinrich Schuchardt <xypron.glpk(a)gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Cc: Simon Glass <sjg(a)chromium.org> Cc: Tom Rini <trini(a)konsulko.com> --- arch/arm/cpu/armv7/cpu.c | 5 +++++ arch/arm/cpu/armv7/sctlr.S | 6 +++--- arch/arm/include/asm/armv7.h | 1 + 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c index 68807d20997..6259ffa5108 100644 --- a/arch/arm/cpu/armv7/cpu.c +++ b/arch/arm/cpu/armv7/cpu.c @@ -83,3 +83,8 @@ int cleanup_before_linux(void) { return cleanup_before_linux_select(CBL_ALL); } + +void allow_unaligned(void) +{ + v7_arch_cp15_allow_unaligned(); +} diff --git a/arch/arm/cpu/armv7/sctlr.S b/arch/arm/cpu/armv7/sctlr.S index bd56e41afe1..d44b21498f6 100644 --- a/arch/arm/cpu/armv7/sctlr.S +++ b/arch/arm/cpu/armv7/sctlr.S @@ -8,15 +8,15 @@ #include <linux/linkage.h> /* - * void allow_unaligned(void) - allow unaligned access + * void v7_arch_cp15_allow_unaligned(void) - allow unaligned access * * This routine clears the aligned flag in the system control register. * After calling this routine unaligned access does no longer lead to a * data abort but is handled by the CPU. */ -ENTRY(allow_unaligned) +ENTRY(v7_arch_cp15_allow_unaligned) mrc p15, 0, r0, c1, c0, 0 @ load system control register bic r0, r0, #2 @ clear aligned flag mcr p15, 0, r0, c1, c0, 0 @ write system control register bx lr @ return -ENDPROC(allow_unaligned) +ENDPROC(v7_arch_cp15_allow_unaligned) diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h index 2fb824b69e2..c002998ac0b 100644 --- a/arch/arm/include/asm/armv7.h +++ b/arch/arm/include/asm/armv7.h @@ -156,6 +156,7 @@ void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 cpu_midr, u32 cpu_rev); void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb, u32 cpu_variant, u32 cpu_rev); +void v7_arch_cp15_allow_unaligned(void); #endif /* ! __ASSEMBLY__ */ #endif -- 2.40.1

1 1

[PATCH 1/2] ARM: armv7: Add C wrapper for allow_unaligned()
by Marek Vasut 01 Jul '23

01 Jul '23

Rename current assembler implementation of allow_unaligned() to v7_arch_cp15_allow_unaligned() and add it into armv7.h header, then add C wrapper of allow_unaligned(). This fixes misbehavior when linking U-Boot on ARMv7a i.MX6Q, where the CPU specific allow_unaligned() implementation was ignored and instead the __weak allow_unaligned() implementation from lib/efi_loader/efi_setup.c was used, which led to "data abort" just before booting Linux via tftp, in efi_dp_from_file() -> path_to_uefi() -> utf16_put() . Adding the wrapper fixes the problem. Fixes: c7c0ca37673 ("efi_loader: fix efi_dp_from_file()") Signed-off-by: Marek Vasut <marex(a)denx.de> --- Cc: Fabio Estevam <festevam(a)denx.de> Cc: Heinrich Schuchardt <xypron.glpk(a)gmx.de> Cc: Simon Glass <sjg(a)chromium.org> Cc: Tom Rini <trini(a)konsulko.com> --- arch/arm/cpu/armv7/cpu.c | 5 +++++ arch/arm/cpu/armv7/sctlr.S | 6 +++--- arch/arm/include/asm/armv7.h | 1 + 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c index 68807d20997..6259ffa5108 100644 --- a/arch/arm/cpu/armv7/cpu.c +++ b/arch/arm/cpu/armv7/cpu.c @@ -83,3 +83,8 @@ int cleanup_before_linux(void) { return cleanup_before_linux_select(CBL_ALL); } + +void allow_unaligned(void) +{ + v7_arch_cp15_allow_unaligned(); +} diff --git a/arch/arm/cpu/armv7/sctlr.S b/arch/arm/cpu/armv7/sctlr.S index bd56e41afe1..d44b21498f6 100644 --- a/arch/arm/cpu/armv7/sctlr.S +++ b/arch/arm/cpu/armv7/sctlr.S @@ -8,15 +8,15 @@ #include <linux/linkage.h> /* - * void allow_unaligned(void) - allow unaligned access + * void v7_arch_cp15_allow_unaligned(void) - allow unaligned access * * This routine clears the aligned flag in the system control register. * After calling this routine unaligned access does no longer lead to a * data abort but is handled by the CPU. */ -ENTRY(allow_unaligned) +ENTRY(v7_arch_cp15_allow_unaligned) mrc p15, 0, r0, c1, c0, 0 @ load system control register bic r0, r0, #2 @ clear aligned flag mcr p15, 0, r0, c1, c0, 0 @ write system control register bx lr @ return -ENDPROC(allow_unaligned) +ENDPROC(v7_arch_cp15_allow_unaligned) diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h index 2fb824b69e2..c002998ac0b 100644 --- a/arch/arm/include/asm/armv7.h +++ b/arch/arm/include/asm/armv7.h @@ -156,6 +156,7 @@ void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 cpu_midr, u32 cpu_rev); void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb, u32 cpu_variant, u32 cpu_rev); +void v7_arch_cp15_allow_unaligned(void); #endif /* ! __ASSEMBLY__ */ #endif -- 2.40.1

2 3

[PATCH v4] dt-bindings: riscv: deprecate riscv,isa
by Conor Dooley 01 Jul '23

01 Jul '23

From: Conor Dooley <conor.dooley(a)microchip.com> intro ===== When the RISC-V dt-bindings were accepted upstream in Linux, the base ISA etc had yet to be ratified. By the ratification of the base ISA, incompatible changes had snuck into the specifications - for example the Zicsr and Zifencei extensions were spun out of the base ISA. Fast forward to today, and the reason for this patch. Currently the riscv,isa dt property permits only a specific subset of the ISA string - in particular it excludes version numbering. With the current constraints, it is not possible to discern whether "rv64i" means that the hart supports the fence.i instruction, for example. Future systems may choose to implement their own instruction fencing, perhaps using a vendor extension, or they may not implement the optional counter extensions. Software needs a way to determine this. versioning schemes ================== "Use the extension versions that are described in the ISA manual" you may say, and it's not like this has not been considered. Firstly, software that parses the riscv,isa property at runtime will need to contain a lookup table of some sort that maps arbitrary versions to versions it understands. There is not a consistent application of version number applied to extensions, with a higgledy-piggledy collection of tags, "bare" and versioned documents awaiting the reader on the "recently ratified extensions" page: https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions As an aside, and this is reflected in the patch too, since many extensions have yet to appear in a release of the ISA specs, they are defined by commits in their respective "working draft" repositories. Secondly, there is an issue of backwards compatibility, whereby allowing numbers in the ISA string, some parsers may be broken. This would require an additional property to be created to even use the versions in this manner. ~boolean properties~ string array property ========================================== If a new property is needed, the whole approach may as well be looked at from the bottom up. A string with limited character choices etc is hardly the best approach for communicating extension information to software. Switching to using properties that are defined on a per extension basis, allows us to define explicit meanings for the DT representation of each extension - rather than the current situation where different operating systems or other bits of software may impart different meanings to characters in the string. Clearly the best source of meanings is the specifications themselves, this just provides us the ability to choose at what point in time the meaning is set. If an extension changes incompatibility in the future, a new property will be required. Off-list, some of the RVI folks have committed to shoring up the wording in either the ISA specifications, the riscv-isa-manual or so that in the future, modifications to and additions or removals of features will require a new extension. Codifying that assertion somewhere would make it quite unlikely that compatibility would be broken, but we have the tools required to deal with it, if & when it crops up. It is in our collective interest, as consumers of extension meanings, to define a scheme that enforces compatibility. The use of individual elements, rather than a single string, will also permit validation that the properties have a meaning, as well as potentially reject mutually exclusive combinations, or enforce dependencies between extensions. That would not have be possible with the current dt-schema infrastructure for arbitrary strings, as we would need to add a riscv,isa parser to dt-validate! That's not implemented in this patch, but rather left as future work (for the brave, or the foolish). parser simplicity ================= Many systems that parse DT at runtime already implement an function that can check for the presence of a string in an array of string, as it is similar to the process for parsing a list of compatible strings, so a bunch of new, custom, DT parsing should not be needed. Getting rid of "riscv,isa" parsing would be a nice simplification, but unfortunately for backwards compatibility with old dtbs, existing parsers may not be removable - which may greatly simplify dt parsing code. In Linux, for example, checking for whether a hart supports an extension becomes as simple as: of_property_match_string(node, "riscv,isa-extensions", "zicbom") vendor extensions ================= Compared to riscv,isa, this proposed scheme promotes vendor extensions, oft touted as the strength of RISC-V, to first-class citizens. At present, extensions are defined as meaning what the RISC-V ISA specifications say they do. There is no realistic way of using that interface to provide cross-platform definitions for what vendor extensions mean. Vendor extensions may also have even less consistency than RVI do in terms of versioning, or no care about backwards compatibility. The new property allows us to assign explicit meanings on a per vendor extension basis, backed up by a description of their meanings. fin === Create a new file to store the extension meanings and a new riscv,isa-base property to replace the aspect of riscv,isa that is not represented by the new property - the base ISA implemented by a hart. As a starting point, add properties for extensions currently used in Linux. Finally, mark riscv,isa as deprecated, as removing support for it in existing programs would be an ABI break. CC: Palmer Dabbelt <palmer(a)dabbelt.com> CC: Paul Walmsley <paul.walmsley(a)sifive.com> CC: Rob Herring <robh+dt(a)kernel.org> CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt(a)linaro.org> CC: Alistair Francis <alistair.francis(a)wdc.com> CC: Andrew Jones <ajones(a)ventanamicro.com> CC: Anup Patel <apatel(a)ventanamicro.com> CC: Atish Patra <atishp(a)atishpatra.org> CC: Jessica Clarke <jrtc27(a)jrtc27.com> CC: Rick Chen <rick(a)andestech.com> CC: Leo <ycliang(a)andestech.com> CC: Oleksii <oleksii.kurochko(a)gmail.com> CC: linux-riscv(a)lists.infradead.org CC: qemu-riscv(a)nongnu.org CC: u-boot(a)lists.denx.de CC: devicetree(a)vger.kernel.org CC: linux-kernel(a)vger.kernel.org Reviewed-by: Palmer Dabbelt <palmer(a)rivosinc.com> Acked-by: Palmer Dabbelt <palmer(a)rivosinc.com> Reviewed-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> --- Changes in v4: - Drop the ACPI section at Anup's request. - Pick up tags from Rob. - Reword some counter access clarification bits in I & Zicsr. Changes in v3: - Per Rob's suggestion, switch to an array of strings. Cuts down on the size, compared to booleans. It has a standard mechanism for parsing (you need to parse arrays of strings for compatibles). It still allows for having a limited set of explicitly defined properties - so the advantages over a free-form string still apply. - Pick up Palmer's Ack and Review (although I expect that he will be the one to apply this). --- .../devicetree/bindings/riscv/cpus.yaml | 43 ++- .../devicetree/bindings/riscv/extensions.yaml | 250 ++++++++++++++++++ 2 files changed, 270 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/riscv/extensions.yaml diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index 67bd239ead0b..74bc92591086 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -25,6 +25,7 @@ description: | allOf: - $ref: /schemas/cpu.yaml# + - $ref: extensions.yaml properties: compatible: @@ -82,25 +83,6 @@ properties: description: The blocksize in bytes for the Zicboz cache operations. - riscv,isa: - description: - Identifies the specific RISC-V instruction set architecture - supported by the hart. These are documented in the RISC-V - User-Level ISA document, available from - https://riscv.org/specifications/ - - Due to revisions of the ISA specification, some deviations - have arisen over time. - Notably, riscv,isa was defined prior to the creation of the - Zicntr, Zicsr, Zifencei and Zihpm extensions and thus "i" - implies "zicntr_zicsr_zifencei_zihpm". - - While the isa strings in ISA specification are case - insensitive, letters in the riscv,isa string must be all - lowercase. - $ref: /schemas/types.yaml#/definitions/string - pattern: ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$ - # RISC-V has multiple properties for cache op block sizes as the sizes # differ between individual CBO extensions cache-op-block-size: false @@ -139,8 +121,17 @@ properties: DMIPS/MHz, relative to highest capacity-dmips-mhz in the system. +oneOf: + - required: + - riscv,isa + - required: + - riscv,isa-base + +dependencies: + riscv,isa-base: [ "riscv,isa-extensions" ] + riscv,isa-extensions: [ "riscv,isa-base" ] + required: - - riscv,isa - interrupt-controller unevaluatedProperties: false @@ -160,7 +151,9 @@ examples: i-cache-sets = <128>; i-cache-size = <16384>; reg = <0>; - riscv,isa = "rv64imac"; + riscv,isa-base = "rv64i"; + riscv,isa-extensions = "i", "m", "a", "c"; + cpu_intc0: interrupt-controller { #interrupt-cells = <1>; compatible = "riscv,cpu-intc"; @@ -183,8 +176,10 @@ examples: i-tlb-size = <32>; mmu-type = "riscv,sv39"; reg = <1>; - riscv,isa = "rv64imafdc"; tlb-split; + riscv,isa-base = "rv64i"; + riscv,isa-extensions = "i", "m", "a", "f", "d", "c"; + cpu_intc1: interrupt-controller { #interrupt-cells = <1>; compatible = "riscv,cpu-intc"; @@ -202,8 +197,10 @@ examples: device_type = "cpu"; reg = <0>; compatible = "riscv"; - riscv,isa = "rv64imafdc"; mmu-type = "riscv,sv48"; + riscv,isa-base = "rv64i"; + riscv,isa-extensions = "i", "m", "a", "f", "d", "c"; + interrupt-controller { #interrupt-cells = <1>; interrupt-controller; diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml new file mode 100644 index 000000000000..cc1f546fdbdc --- /dev/null +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml @@ -0,0 +1,250 @@ +# SPDX-License-Identifier: (GPL-2.0 OR MIT) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/riscv/extensions.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RISC-V ISA extensions + +maintainers: + - Paul Walmsley <paul.walmsley(a)sifive.com> + - Palmer Dabbelt <palmer(a)sifive.com> + - Conor Dooley <conor(a)kernel.org> + +description: | + RISC-V has a large number of extensions, some of which are "standard" + extensions, meaning they are ratified by RISC-V International, and others + are "vendor" extensions. + This document defines properties that indicate whether a hart supports a + given extension. + + Once a standard extension has been ratified, no changes in behaviour can be + made without the creation of a new extension. + The properties for standard extensions therefore map to their originally + ratified states, with the exception of the I, Zicntr & Zihpm extensions. + See the "i" property for more information. + +select: + properties: + compatible: + contains: + const: riscv + +properties: + riscv,isa: + description: + Identifies the specific RISC-V instruction set architecture + supported by the hart. These are documented in the RISC-V + User-Level ISA document, available from + https://riscv.org/specifications/ + + Due to revisions of the ISA specification, some deviations + have arisen over time. + Notably, riscv,isa was defined prior to the creation of the + Zicntr, Zicsr, Zifencei and Zihpm extensions and thus "i" + implies "zicntr_zicsr_zifencei_zihpm". + + While the isa strings in ISA specification are case + insensitive, letters in the riscv,isa string must be all + lowercase. + $ref: /schemas/types.yaml#/definitions/string + pattern: ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$ + deprecated: true + + riscv,isa-base: + description: + The base ISA implemented by this hart, as described by the 20191213 + version of the unprivileged ISA specification. + enum: + - rv32i + - rv64i + + riscv,isa-extensions: + $ref: /schemas/types.yaml#/definitions/string-array + minItems: 1 + description: Extensions supported by the hart. + items: + anyOf: + # single letter extensions, in canonical order + - const: i + description: | + The base integer instruction set, as ratified in the 20191213 + version of the unprivileged ISA specification. + + This does not include Chapter 10, "Counters", which was moved into + the Zicntr and Zihpm extensions after the ratification of the + 20191213 version of the unprivileged specification. + + - const: m + description: + The standard M extension for integer multiplication and division, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: a + description: + The standard A extension for atomic instructions, as ratified in the + 20191213 version of the unprivileged ISA specification. + + - const: f + description: + The standard F extension for single-precision floating point, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: d + description: + The standard D extension for double-precision floating-point, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: q + description: + The standard Q extension for quad-precision floating-point, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: c + description: + The standard C extension for compressed instructions, as ratified in + the 20191213 version of the unprivileged ISA specification. + + - const: v + description: + The standard V extension for vector operations, as ratified + in-and-around commit 7a6c8ae ("Fix text that describes vfmv.v.f + encoding") of the riscv-v-spec. + + - const: h + description: + The standard H extension for hypervisors as ratified in the 20191213 + version of the privileged ISA specification. + + # multi-letter extensions, sorted alphanumerically + - const: smaia + description: | + The standard Smaia supervisor-level extension for the advanced + interrupt architecture for machine-mode-visible csr and behavioural + changes to interrupts as frozen at commit ccbddab ("Merge pull + request #42 from riscv/jhauser-2023-RC4") of riscv-aia. + + - const: ssaia + description: | + The standard Ssaia supervisor-level extension for the advanced + interrupt architecture for supervisor-mode-visible csr and + behavioural changes to interrupts as frozen at commit ccbddab + ("Merge pull request #42 from riscv/jhauser-2023-RC4") of riscv-aia. + + - const: sscofpmf + description: | + The standard Sscofpmf supervisor-level extension for count overflow + and mode-based filtering as ratified at commit 01d1df0 ("Add ability + to manually trigger workflow. (#2)") of riscv-count-overflow. + + - const: sstc + description: | + The standard Sstc supervisor-level extension for time compare as + ratified at commit 3f9ed34 ("Add ability to manually trigger + workflow. (#2)") of riscv-time-compare. + + - const: svinval + description: + The standard Svinval supervisor-level extension for fine-grained + address-translation cache invalidation as ratified in the 20191213 + version of the privileged ISA specification. + + - const: svnapot + description: + The standard Svnapot supervisor-level extensions for napot + translation contiguity as ratified in the 20191213 version of the + privileged ISA specification. + + - const: svpbmt + description: + The standard Svpbmt supervisor-level extensions for page-based + memory types as ratified in the 20191213 version of the privileged + ISA specification. + + - const: zba + description: | + The standard Zba bit-manipulation extension for address generation + acceleration instructions as ratified at commit 6d33919 ("Merge pull + request #158 from hirooih/clmul-fix-loop-end-condition") of + riscv-bitmanip. + + - const: zbb + description: | + The standard Zbb bit-manipulation extension for basic bit-manipulation + as ratified at commit 6d33919 ("Merge pull request #158 from + hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip. + + - const: zbc + description: | + The standard Zbc bit-manipulation extension for carry-less + multiplication as ratified at commit 6d33919 ("Merge pull request + #158 from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip. + + - const: zbs + description: | + The standard Zbs bit-manipulation extension for single-bit + instructions as ratified at commit 6d33919 ("Merge pull request #158 + from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip. + + - const: zicbom + description: + The standard Zicbom extension for base cache management operations as + ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. + + - const: zicbop + description: + The standard Zicbop extension for cache-block prefetch instructions + as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of + riscv-CMOs. + + - const: zicboz + description: + The standard Zicboz extension for cache-block zeroing as ratified + in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs. + + - const: zicntr + description: + The standard Zicntr extension for base counters and timers, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: zicsr + description: | + The standard Zicsr extension for control and status register + instructions, as ratified in the 20191213 version of the + unprivileged ISA specification. + + This does not include Chapter 10, "Counters", which documents + special case read-only CSRs, that were moved into the Zicntr and + Zihpm extensions after the ratification of the 20191213 version of + the unprivileged specification. + + - const: zifencei + description: + The standard Zifencei extension for instruction-fetch fence, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: zihintpause + description: + The standard Zihintpause extension for pause hints, as ratified in + commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual. + + - const: zihpm + description: + The standard Zihpm extension for hardware performance counters, as + ratified in the 20191213 version of the unprivileged ISA + specification. + + - const: ztso + description: + The standard Ztso extension for total store ordering, as ratified + in commit 2e5236 ("Ztso is now ratified.") of the + riscv-isa-manual. + +additionalProperties: true +... -- 2.39.2

3 3

Re: distro_boot vs. env-based bootmenu
by Simon Glass 01 Jul '23

01 Jul '23

Hi Frank, On Fri, 21 Apr 2023 at 10:03, Frank Wunderlich <frank-w(a)public-files.de> wrote: > > Maybe you have an idea because your patch removes distro-boot > > https://patchwork.ozlabs.org/project/uboot/patch/20230409084454.v9.8.I4cf77… > > For missing linebreak for autoboot this seems to be a calculation issue > > https://source.denx.de/u-boot/u-boot/-/blob/master/common/menu.c#L439 Are you able to fix it with a patch? Or if not, do you have a patch for the 'move to env-based bootmenu' so I can try it? Regards, Simon > > > > -------- Ursprüngliche Nachricht -------- > Von: Frank Wunderlich <frank-w(a)public-files.de> > Gesendet: 12. April 2023 11:22:23 MESZ > An: u-boot(a)lists.denx.de > Betreff: distro_boot vs. env-based bootmenu > > Hi, > > i try to move from distro-boot (extlinux-config files) to an env-based bootmenu (builtin-environment) for > my bananapi r2pro. > > basicly it works, but i see more bootmenu-entries than i have defined in my environment > > *** U-Boot Boot Menu *** > > 1. Boot from SD/EMMC. > mmc 1:2 > mmc 1:3 > mmc 1:4 > U-Boot consoleHit any key to stop autoboot: 2 > > i have only defined one botmenu-entry (first one in uEnv_r2pro.txt) > > bootmenu_0=1. Boot from SD/EMMC.=run newboot > bootmenu_default=0 > > i guess the 3 mmc 1:x entries are part from distro-boot. i see a series from simon where he drops > distroboot for rockchip-boards. > > https://patchwork.ozlabs.org/project/uboot/patch/20230409084454.v9.8.I4cf77… > > can anyone explain me where i can disable the mmc 1:x entries? i wanted to leave distro_boot as > fallback but it seems this is not possible. > > maybe i have to disable these? > > BOOTMETH_DISTRO [=y] > DISTRO_DEFAULTS [=y] > > can i keep distro-boot (seems to works with env too, but overridden by my builtin env) somehow and drop the mmc-entries from my bootmenu? > > any idea why i have no linebreak after u-Boot console? > > i use u-boot 2023.04 my source for this conversion/tests is there: > https://github.com/frank-w/u-boot/tree/2023-04-bpi-r2pro > using modified configs/evb-rk3568_defconfig > > regards Frank > regards Frank

3 7

distro_boot vs. env-based bootmenu
by Frank Wunderlich 01 Jul '23

01 Jul '23

Hi, i try to move from distro-boot (extlinux-config files) to an env-based bootmenu (builtin-environment) for my bananapi r2pro. basicly it works, but i see more bootmenu-entries than i have defined in my environment *** U-Boot Boot Menu *** 1. Boot from SD/EMMC. mmc 1:2 mmc 1:3 mmc 1:4 U-Boot consoleHit any key to stop autoboot: 2 i have only defined one botmenu-entry (first one in uEnv_r2pro.txt) bootmenu_0=1. Boot from SD/EMMC.=run newboot bootmenu_default=0 i guess the 3 mmc 1:x entries are part from distro-boot. i see a series from simon where he drops distroboot for rockchip-boards. https://patchwork.ozlabs.org/project/uboot/patch/20230409084454.v9.8.I4cf77… can anyone explain me where i can disable the mmc 1:x entries? i wanted to leave distro_boot as fallback but it seems this is not possible. maybe i have to disable these? BOOTMETH_DISTRO [=y] DISTRO_DEFAULTS [=y] can i keep distro-boot (seems to works with env too, but overridden by my builtin env) somehow and drop the mmc-entries from my bootmenu? any idea why i have no linebreak after u-Boot console? i use u-boot 2023.04 my source for this conversion/tests is there: https://github.com/frank-w/u-boot/tree/2023-04-bpi-r2pro using modified configs/evb-rk3568_defconfig regards Frank

2 2