Add Zicsr and Zifencei extensions when GCC >= 11 #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This driver uses simple_strtol(), so it needs SPL_STRTO. Before commit 88ca8e2 ("disk: Add an option for partitions in SPL"), SPL_STRTO was always selected indirectly. Now it is not, so select it here. Series-to: sunxi Signed-off-by: Samuel Holland <samuel@sholland.org>
Copy the devicetree source for the A10 SoC and all existing boards verbatim from the Linux v5.18-rc1 tag. The previous version of this change was only partially applied. Series-to: sunxi Series-cc: trini Series-version: 2 Series-changes: 2 - Rebased. The commit that was sent in Andre's PR only contained changes from one file -- the one with the character set change. Fixes: 4746694 ("ARM: dts: sun4i: Sync from Linux v5.18-rc1") Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
TOC1 is an container format used by Allwinner's boot0 that can hold multiple images. It supports encryption and signatures, but that functionality is not implemented, only the basic "non-secure" subset. A config file is used to provide the list of data files to include. Its path is passed as the argument to "-d". It contains sections of the following form: [name] file = /path/to/file addr = 0x12345678 Specific well-known names, such as "dtb", "opensbi", and "u-boot", are used by the bootloader to distinguish the items inside the image. Cover-letter: tools: mkimage: Add Allwinner TOC1 support The SPL port for the Allwinner D1 RISC-V SoC will probably take a while longer than porting U-Boot proper, as none of the relevant drivers are set up for DM in SPL. In the meantime, we are using[1][2] a fork[3] of Allwinner's boot0 loader, which they also call "spl" in their BSP. boot0 uses this TOC1 image format. The vendor tools for generating TOC1 images require a binary config file generated by their FEX compiler. Instead of trying to support that, I made up a simple human-readable config file format. I didn't see any existing platform-agnostic parser for multi-image containers in mkimage. I am sending this as RFC because it is only of temporary/limited use. It only works with one specific fork of boot0 which was modified to "behave" (the the original vendor version monkey-patches a custom header inside the U-Boot image during boot). So it will be obsolete once U-Boot SPL is ported. And it is Yet Another Image Format. On the other hand, it does work, and it is currently being used. [1]: https://linux-sunxi.org/Allwinner_Nezha#U-Boot [2]: https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner [3]: https://github.com/smaeul/sun20i_d1_spl END Series-prefix: RFC Series-to: sunxi Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
ARCH_SUNXI selects BINMAN, so the condition "!BINMAN && ARCH_SUNXI" is impossible to satisfy. Signed-off-by: Samuel Holland <samuel@sholland.org>
Currently, if the "offset" property is given for an entry, the section's running offset is completely ignored. This causes entries to overlap if the provided offset is less than the size of the entries earlier in the section. Avoid the overlap by only using the provided offset when it is greater than the running offset. The motivation for this change is the rule used by SPL to find U-Boot on sunxi boards: U-Boot starts 32 KiB after the start of SPL, unless SPL is larger than 32 KiB, in which case U-Boot immediately follows SPL. Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that Crust (SCP firmware) has support for H3, we need a FIT image to load it. H3 also needs to load a SoC-specific eGon blob to support CPU 0 hotplug. Let's first enable FIT support before adding extra firmware. Update the binman description to work on either 32-bit or 64-bit SoCs: - Make BL31 optional, since it is not used on 32-bit SoCs (though BL32 may be used in the future). - Explicitly set the minimum offset of the FIT to 32 KiB, since SPL on some boards is still only 24 KiB large even with FIT support enabled. CONFIG_SPL_PAD_TO cannot be used because it is not defined for H616. FIT unlocks more features (signatures, multiple DTBs, etc.), so enable it by default. A10 (sun4i) only has 24 KiB of SRAM A1, so it needs SPL_FIT_IMAGE_TINY. For simplicity, enable that option everywhere. Cover-letter: sunxi: SPL FIT support for 32-bit sunxi SoCs This series makes the necessary changes so 32-bit sunxi SoCs can load additional device trees or firmware from SPL along with U-Boot proper. There was no existing binman entry property that put the FIT at the right offset. The minimum offset is 32k, but this matches neither the SPL size (which is no more than 24k on some SoCs) nor the FIT alignment (which is 512 bytes in practice due to SPL size constraints). So instead of adding a new property, I fixed what is arguably a bug in the offset property -- though this strategy will not work if someone is intentionally creating overlapping entries. END Series-to: sunxi Series-to: sjg Signed-off-by: Samuel Holland <samuel@sholland.org>
Do not try to send an SGI from CPU 0 to itself. Since FIQs are masked when entering monitor mode, this will hang. Plus, CPU 0 cannot fully power itself off anyway. Instead, have it turn FIQs back on and continue servicing SGIs from other cores. Signed-off-by: Samuel Holland <samuel@sholland.org>
Due to a bug in the H3 SoC, where the CPU 0 hotplug flag cannot be written, resuming CPU 0 requires using the "Super Standby" code path in the BROM instead of the hotplug path. This path requires jumping to an eGON image in SRAM. Add support to the build system to generate this eGON image and include it in the FIT, and add code to direct the BROM to its location in SRAM. Since the Super Standby code path in the BROM initializes the CPU and AHB1 clocks to 24 MHz, those registers need to be restored after control passes back to U-Boot. Furthermore, because the BROM lowers the AHB1 clock divider to /1 before switching to the lower-frequency parent, PLL_PERIPH0 must be bypassed to prevent AHB1 from temporarily running at 600 MHz. Otherwise, this locks up the SoC. Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that issues with the BROM have been sorted out, we can implement PSCI system suspend on H3 by delegating to SCP firmware. Let's start by including the firmware in the FIT image and starting the coprocessor if valid firmware is loaded. Signed-off-by: Samuel Holland <samuel@sholland.org>
Add the new option, function IDs, and prototypes for PSCI v1.1 implementations. In the process, fix some issues with the existing definitions: - Fix the incorrectly-named ARM_PSCI_0_2_FN64_SYSTEM_RESET2. - Replace the deprecated "affinity_level" naming with "power_level". Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
This adds a new PSCI implementation which communicates with SCP firmware running on the AR100 using the SCPI protocol. This allows it to support the full set of PSCI v1.1 features, including CPU idle states, system suspend, and multiple reset methods. Signed-off-by: Samuel Holland <samuel@sholland.org>
The reset array size is currently used for bounds checking in the reset driver. The same bounds check should really be done in the clock driver. Currently, the array size is provided to the reset driver separately from the CCU descriptor, which is a bit strange. Let's do this the usual way, with the array sizes next to the arrays themselves. Acked-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org>
Because the gate arrays are not given explicit sizes, the arrays are only as large as the highest-numbered gate described in the driver. However, only a subset of the CCU clocks are needed by U-Boot. So there are valid clock specifiers with indexes greater than the size of the arrays. Referencing any of these clocks causes out-of-bounds access. Fix this by checking the identifier against the size of the array. Series-changes: 2 - Rebased on top of the dummy flag addition Fixes: 0d47bc7 ("clk: Add Allwinner A64 CLK driver") Acked-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org>
This allows all of the clock drivers to use a common bind function. Acked-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that all of the variants use the same bind/probe functions and ops, there is no need to have a separate driver for each variant. Since most SoCs contain two variants (the main CCU and PRCM CCU), this saves a bit of firmware size and RAM. Acked-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org>
All of the driver private data should really be platform data since it is determined statically (selected by the compatible string or extracted from the devicetree). Move everything to platform data, so it can be provided when binding the driver. This is useful for SPL, or for instantiating the driver as part of an MFD. Acked-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org>
The reason here is the same as the reason for changing the clock driver: platform data can be provided when binding the driver. Acked-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org>
The clock and reset drivers use the exact same platform data. Simplify them by sharing the object. This is safe because the parent device (the clock device) always gets its driver model callbacks run first. Series-to: sunxi Series-cc: Lukasz Majewski <lukma@denx.de> Series-cc: Sean Anderson <seanga2@gmail.com> Series-version: 2 Cover-letter: clk: sunxi: Out-of-bounds access fix and driver cleanup This series fixes an issue with out-of-bounds access to the gate array (patches 1-2), uses the rearranged array size information to remove a bunch of duplicate code (patches 3-4), and then simplifies how the reset driver is bound (patches 5-7). The original motivation for these changes was adding a driver for the legacy A31/A23/A33 PRCM binding (which I will send separately), and trying to use OF_PLATDATA in SPL (which did not work out). But I think at least some of the cleanup is worth applying on its own. Patch 4 is generally the same change I made between v1 and v2 of the pinctrl series, using some #ifdefs to share a U_BOOT_DRIVER. It's not quite as clean as the pinctrl case, because here the SoC-specific parts are in different files, so all of the CCU descriptors have to be global. END Acked-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org>
Compatible strings for some new RTC hardware variants were added to the binding. Add them to the driver in preparation for supporting those new SoCs. Signed-off-by: Samuel Holland <samuel@sholland.org>
Since the D1 CCU binding is defined, we can add support for its gates/resets, following the pattern of the existing drivers. Series-to: sunxi Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
This board is configured with CONFIG_USB1_VBUS_PIN="PH24", but no regulator exists in its device tree. Add the regulator, so USB will continue to work when the PHY driver switches to using the regulator uclass instead of a GPIO. Update the device tree here because it does not exist in Linux. Signed-off-by: Samuel Holland <samuel@sholland.org>
This driver reports the presence/absence of voltage on the PMIC's USB VBUS pin. This information is used by the USB PHY driver. The correspond 8000 ing Linux driver uses the power supply class, which does not exist in U-Boot. UCLASS_REGULATOR seems to be the closest match. Signed-off-by: Samuel Holland <samuel@sholland.org>
Update boards to use the USB power supply driver, as referenced in the device tree, instead of a virtual GPIO. This removes the need for some DM-incompatible special cases in the GPIO driver. The following six boards used AXP0-VBUS-DETECT in their config, but are missing the "usb0_vbus_power-supply" property in their device tree: - Ainol_AW1_defconfig / sun7i-a20-ainol-aw1 - Cubieboard4_defconfig / sun9i-a80-cubieboard4 - Merrii_A80_Optimus_defconfig / sun9i-a80-optimus - Nintendo_NES_Classic_Edition_defconfig / sun8i-r16-nintendo-nes-classic-edition - Yones_Toptech_BD1078_defconfig / sun7i-a20-yones-toptech-bd1078 - Yones_Toptech_BS1078_V2_defconfig / sun6i-a31s-yones-toptech-bs1078-v2 None of those six boards have the MUSB controller (USB OTG) enabled in their device trees, so this change should not break anything for them. Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that this functionality is modeled using the device tree and regulator uclass, the named GPIO is not referenced anywhere. Remove it. Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
As Icenowy pointed out, newer manuals (starting with H6) actually document the register block at offset 0x800 as "HCI controller and PHY interface", also describe the bits in our "PMU_UNK1" register. Let's put proper names to those "unknown" variables and symbols. While we are at it, generalise the existing code by allowing a bitmap of bits to clear and set, to cover newer SoCs: The A100 and H616 use a different bit for the SIDDQ control. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: TekkamanV <tekkamanv@163.com> [Samuel: Only kept the non-Fedora-specific subset of changes] Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: TekkamanV <tekkamanv@163.com> [Samuel: Kept default prompt, trimmed things to stay under 1 MiB] Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Jisheng Zhang <jszhang@kernel.org> [Samuel: licheepi -> lichee; drop DRAM size; other changes] Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
This shows the changes needed to sunxi-common.h, so it makes upstreaming a little bit easier. Signed-off-by: Samuel Holland <samuel@sholland.org>
If this value is not increased, the error occurs during loading uncompressed kernel from fitImage: "Error: inflate() returned -5 Image too large: increase CONFIG_SYS_BOOTM_LEN" Signed-off-by: Cezary Sobczak <cezary.sobczak@3mdeb.com> Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
In GCC version >= 11, since the the version of RISC-V ISA used is 20191213, csrr*/csrw* are not in I extension anymore. This lead to failed compilation when using csrr*/csrw* instructions, for example: > Error: unrecognized opcode `csrw stvec,t0' This enable Zicsr and Zifencei extension when GCC version is >= 11.
|
Thanks ! Works fine to build u-boot on Debian Testing using the default Risc-V cross compiler (gcc 12.2.0). |
|
I have rebased my branch, which pulls in 1dde977, the upstream fix for this problem. |
MartinHerren
pushed a commit
to MartinHerren/u-boot
that referenced
this pull request
Apr 15, 2025
Ilias Apalodimas <ilias.apalodimas@linaro.org> says: Hi all, This is a respin of [1] adding https support to wget. In short patch#1 enables the crypto algorithms we need in mbedTLS patches#2, smaeul#3 enable anf fix the lwIP part we need patch#4 is adding https:// parsing support in our wget patch#5 is making https:// the default for QEMU lwip defconfig so people can easily test and finaly patch#6 updates our documentation [1] https://lore.kernel.org/u-boot/20241024112449.1362319-1-ilias.apalodimas@linaro.org/ Link: https://lore.kernel.org/r/20241110083017.367565-1-ilias.apalodimas@linaro.org
MartinHerren
pushed a commit
to MartinHerren/u-boot
that referenced
this pull request
Apr 15, 2025
Add detailed SMBIOS information as following: 1. Missing fields in Type smaeul#3 and smaeul#4 2. Type smaeul#7 Add support to dynamic length of contained object handles and elements. As SMBIOS is a fundamental feature which is enabled for all boards, in order to avoid increasing rom size, all detailed SMBIOS information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE. Board maintainers can determine whether to select this feature. Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
MartinHerren
pushed a commit
to MartinHerren/u-boot
that referenced
this pull request
Apr 15, 2025
Raymond Mao <raymond.mao@linaro.org> says: Motivations for changes: Current SMBIOS library and command-line tool is not fully matching with the requirements: 1. Missing support for other mandatory types (smaeul#7, u-boot#9, u-boot#16, u-boot#17, u-boot#19). 2. Only a few platforms support SMBIOS node from the device tree. 3. Values of some fields are hardcoded in the library other than fetching from the device hardware. 4. Embedded data with dynamic length is not supported (E.g. Contained Object Handles in Type smaeul#2 and Contained Elements in Type smaeul#3) Changes: 1. Refactor the SMBIOS library and command-line tool to better align with the SMBIOS spec. 2. Create an arch-specific driver for all aarch64-based platforms to fetch SMBIOS private data from the device hardware (processor and cache). 3. Create a sysinfo driver to poppulate platform SMBIOS private data. 4. Add generic SMBIOS DTS file for arm64 platforms for those common strings and values which cannot be retrieved from the system registers. Vendors can create their own SMBIOS node using this as an example. For those boards without SMBIOS nodes, this DTS file can be included to have a generic SMBIOS information of the system. 5. Add support for Type smaeul#7 (Cache Information) and link its handles to Type smaeul#4. 6. To minimize size-growth for those platforms which have not sufficient ROM spaces or the platforms which don't need detailed SMBIOS information, new added fields are only being built when kconfig GENERATE_SMBIOS_TABLE_VERBOSE is selected. Once this patch is acceptted, subsequent patch sets will add other missing types (u-boot#9, u-boot#16, u-boot#17, u-boot#19). Tests: To test this with QEMU arm64, please follow the guide on dt_qemu.rst to get a merged DT to run with. ``` qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \ | dtc - -o merged.dtb qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \ -dtb merged.dtb ``` Link: https://lore.kernel.org/r/20241206225438.13866-1-raymond.mao@linaro.org
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In GCC version >= 11, since the the version of RISC-V ISA used is 20191213,
csrr*/csrw* are not in I extension anymore. This lead to failed
compilation when using csrr*/csrw* instructions, for example:
This enable Zicsr and Zifencei extension when GCC version is >= 11.