From fb54e5971a02b5c1bfa84252d54c51d7e21cf36f Mon Sep 17 00:00:00 2001 From: realybin Date: Wed, 1 Jan 2025 05:58:42 +0000 Subject: [PATCH] feat: add locale en --- .../current/baseline-reference.md | 100 + .../collection-of-typical-configurations.md | 2006 +++++++++++++++++ .../current/errata.md | 22 + .../current/intro.md | 14 + .../current/linux-upstream-support.md | 88 + .../current/loong-or-loongarch.md | 98 + .../current/old-and-new-worlds.md | 192 ++ .../current/world-compat-details/index.md | 667 ++++++ 8 files changed, 3187 insertions(+) create mode 100644 i18n/en/docusaurus-plugin-content-docs/current/baseline-reference.md create mode 100644 i18n/en/docusaurus-plugin-content-docs/current/collection-of-typical-configurations.md create mode 100644 i18n/en/docusaurus-plugin-content-docs/current/errata.md create mode 100644 i18n/en/docusaurus-plugin-content-docs/current/intro.md create mode 100644 i18n/en/docusaurus-plugin-content-docs/current/linux-upstream-support.md create mode 100644 i18n/en/docusaurus-plugin-content-docs/current/loong-or-loongarch.md create mode 100644 i18n/en/docusaurus-plugin-content-docs/current/old-and-new-worlds.md create mode 100644 i18n/en/docusaurus-plugin-content-docs/current/world-compat-details/index.md diff --git a/i18n/en/docusaurus-plugin-content-docs/current/baseline-reference.md b/i18n/en/docusaurus-plugin-content-docs/current/baseline-reference.md new file mode 100644 index 00000000..1f894e15 --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current/baseline-reference.md @@ -0,0 +1,100 @@ +--- +sidebar_position: 5 +--- + +# Baseline Reference of Infra Component Versions + +:::info Frequently Updated! +This is a living document, and its content will change as conditions evolve. Check back often! +::: + +As LoongArch gains wider upstream support in various open-source projects and sees regular releases, the sheer variety of fundamental software versions inevitably multiplies. To reduce the integration burden and avoid repeated pitfalls, here are our recommended baseline combinations. Some are time-tested for stability; others represent the cutting edge of feature development and will soon become the next wave of stable baselines. + +We currently name each baseline in a “year + quarter” format because it helps developers associate version numbers with the relevant context (and sometimes painful memories). + +This document was last updated on May 12, 2024. The recommended stable baseline is 2023Q1, and the testing baseline is 2024Q2. The current leading-edge baseline is expected to stabilize by late 2024 and be designated as 2024Q4 or 2025Q1. If you plan to adopt the 2024Q2 baseline, we strongly suggest also including the leading-edge baseline in your evaluation. + +## Bleeding Edge {#bleeding-edge} + +|Binutils|GCC|Linux|glibc|LLVM|Rust|Go | +|:------:|:-:|:---:|:---:|:--:|:--:|:-:| +|2.43 :wrench:|15.x :wrench:|6.12 LTS|2.4x :wrench:|19 :wrench:|1.8x.x|1.23.x :wrench:| + +:wrench: This symbol indicates that the related content is still under development. + +This baseline reflects real-time progress; some software versions are still unreleased, so their numbers may change. Many new features are under refinement, which may lead to unexpected compilation or linking errors and runtime behaviors. Developers and capable users are encouraged to test, practice, and report any issues in the [community discussion channel](https://github.com/loongson-community/discussions/issues). + +:::warning Proactive issue reporting is crucial! +Only when you raise problems will others see them and work on fixes. +Though the circle is still small, LoongArch’s application scope is already broader than any single individual can imagine. +Don’t expect a few developers to coincidentally face your issue and solve it without direct communication. +::: + +The main features of this period/baseline include: + +* :wrench: Continuing the implementation of LoongArch ELF psABI v20231219 (overall version v2.30). + - v20230519: :wrench: Further improvements to linker relaxation. + - v20231219: :wrench: Expected full TLS descriptor (TLSDESC) support. +* KVM virtualization is supported on Linux. +* :wrench: Extended support for new instructions and semantic changes in LoongArch v1.10. + - 16-byte atomic operations are planned: :wrench: [tracking issue](https://github.com/loongson-community/discussions/issues/16). +* Full TLSDESC support? +* BFD linker support for `DT_RELR`? +* TBD + +## 2024Q2 {#2024q2} + +|Binutils|GCC|Linux|glibc|LLVM|Rust|Go | +|:------:|:-:|:---:|:---:|:--:|:--:|:-:| +|2.42|14.x|6.6 LTS|2.39|18|1.76.x|1.22.x| + +This is the second baseline in the rapid development of the LoongArch's new world, showcasing significant iterations achieved through large-scale collaborative research and numerous minor improvements. + +The support for LoongArch v1.00 features is nearly complete in this baseline. Additionally, broader community participation, closer collaboration, and more timely iterations mean that more modern features are gradually being introduced starting from this baseline. + +Key features of this period/baseline include: + +* Partial implementation of LoongArch ELF psABI v20231219 (overall version v2.30). + - v20230519: Basic linker relaxation support: GNU toolchain has comprehensive support, while LLVM toolchain only implements compatibility requirements. Some issues may remain. + - v20231102: For `medium` code model procedure calls, implemented the correct approach using adjacent `pcaddu18i + jirl` with `R_LARCH_CALL36`. Legacy approach remains supported only for binary compatibility but is not recommended for new code. + - v20231219: Added TLS descriptor (TLSDESC) support, mainlined everywhere except glibc and musl. + - v20231219: Requires adjacent placement of four address-composing instructions in `extreme` code model. Legacy object code with non-adjacent instructions crossing 4KiB boundaries will link incorrectly without remedy. Package maintainers should closely monitor software using `extreme` code model (typically large projects or low-level components). +* First complete support for LoongArch v1.00 instruction set, enabling assembly, disassembly, and free use in programs. +* Support for LoongArch v1.10 new instructions in assembly and disassembly, with partial code generation support. For example, gcc added command-line options to control 32-bit division erratum and `frecipe` usage. +* Initial auto-vectorization capability in compilers. +* First-time Rust language support for Linux glibc and bare metal environments. +* For Linux: KVM virtualization support missed the Linux 6.6 LTS release in late 2023. + +## 2023Q1 {#2023q1} + +|Binutils|GCC|Linux|glibc|LLVM|Rust|Go | +|:------:|:-:|:---:|:---:|:--:|:--:|:-:| +|2.40|13.x|6.1 LTS|2.37|16|N/A|1.20.x| + +This is the first bootable baseline for LoongArch's new world. + +Key features of this period/baseline include: + +* Partial implementation of LoongArch ELF psABI v20230519 (overall version v2.10). + - Introduced and defaulted to simplified relocations that do not rely on stack operation semantics. + - For `medium` code model procedure calls, adopted a workaround using `jirl` with `R_LARCH_PCALA_LO12`. + - No support for linker relaxation and related relocations. +* Compliance with ACPI 6.5 and UEFI 2.10. + These specifications were officially released in August 2022, missing Linux 5.19's merge window in early July. + Combined with the time needed for code updates, this baseline marks their first implementation. +* First-time LLVM/Clang support. +* Still no support for SIMD, hardware virtualization, or binary translation extensions. + +## 2022Q3 {#2022q3} + +|Binutils|GCC|Linux|glibc|LLVM|Rust|Go | +|:------:|:-:|:---:|:---:|:--:|:--:|:-:| +|2.38|12.x|5.19|2.36|N/A|N/A|1.19.x| + +This is the first upstream baseline for LoongArch's new world. +At this point, while LoongArch support in toolchains and kernel was first upstreamed completely and could work together to build a complete sysroot, the timing mismatch with ACPI and UEFI specification updates meant systems built with this baseline couldn't boot. + +Key features of this period/baseline include: + +* Only supports relocations using stack operation semantics (`R_LARCH_SOP_*`). +* Only supports basic integer and floating-point instructions from LoongArch v1.00 Volume 1. SIMD, hardware virtualization, and binary translation extensions are completely unavailable. diff --git a/i18n/en/docusaurus-plugin-content-docs/current/collection-of-typical-configurations.md b/i18n/en/docusaurus-plugin-content-docs/current/collection-of-typical-configurations.md new file mode 100644 index 00000000..b75dade9 --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current/collection-of-typical-configurations.md @@ -0,0 +1,2006 @@ +--- +sidebar_position: 6 +--- + +# Typical LoongArch Configuration Data Collection + +:::info Frequently Updated! +This is a living document, and its content will change as conditions evolve. Check back often! +::: + +This page is open for editing! You’re welcome to submit your LoongArch hardware configurations via GitHub, following the format in the [template section](#template). + +## 3C6000 Single-Socket Server + +`uname -srvmpio`: `Linux 6.12.0-aosc-main #1 SMP PREEMPT_DYNAMIC Thu Nov 21 13:11:11 UTC 2024 loongarch64 unknown unknown GNU/Linux` + +
+`CPUCFG` + +```c +CPUCFG.0x0 = 0x0014d010 +CPUCFG.0x1 = 0x07f2f2fe +CPUCFG.0x2 = 0x7e7ccfc7 +CPUCFG.0x3 = 0x00cefcff +CPUCFG.0x4 = 0x05f5e100 +CPUCFG.0x5 = 0x00010001 +CPUCFG.0x6 = 0x00007f33 +CPUCFG.0x10 = 0x00002c3d +CPUCFG.0x11 = 0x06080003 +CPUCFG.0x12 = 0x06080003 +CPUCFG.0x13 = 0x0608000f +CPUCFG.0x14 = 0x060f000f +``` + +
+ +
+`/proc/cpuinfo` + +``` +system type : generic-loongson-machine + +processor : 0 +package : 0 +core : 0 +global_id : 0 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 1 +package : 0 +core : 1 +global_id : 1 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 2 +package : 0 +core : 2 +global_id : 2 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 3 +package : 0 +core : 3 +global_id : 3 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 4 +package : 0 +core : 4 +global_id : 4 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 5 +package : 0 +core : 5 +global_id : 5 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 6 +package : 0 +core : 6 +global_id : 6 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 7 +package : 0 +core : 7 +global_id : 7 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 8 +package : 0 +core : 8 +global_id : 8 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 9 +package : 0 +core : 9 +global_id : 9 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 10 +package : 0 +core : 10 +global_id : 10 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 11 +package : 0 +core : 11 +global_id : 11 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 12 +package : 0 +core : 12 +global_id : 12 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 13 +package : 0 +core : 13 +global_id : 13 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 14 +package : 0 +core : 14 +global_id : 14 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 15 +package : 0 +core : 15 +global_id : 15 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 16 +package : 0 +core : 16 +global_id : 16 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 17 +package : 0 +core : 17 +global_id : 17 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 18 +package : 0 +core : 18 +global_id : 18 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 19 +package : 0 +core : 19 +global_id : 19 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 20 +package : 0 +core : 20 +global_id : 20 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 21 +package : 0 +core : 21 +global_id : 21 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 22 +package : 0 +core : 22 +global_id : 22 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 23 +package : 0 +core : 23 +global_id : 23 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 24 +package : 0 +core : 24 +global_id : 24 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 25 +package : 0 +core : 25 +global_id : 25 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 26 +package : 0 +core : 26 +global_id : 26 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 27 +package : 0 +core : 27 +global_id : 27 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 28 +package : 0 +core : 28 +global_id : 28 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 29 +package : 0 +core : 29 +global_id : 29 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 30 +package : 0 +core : 30 +global_id : 30 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 31 +package : 0 +core : 31 +global_id : 31 +CPU Family : Loongson-64bit +Model Name : Loongson-3C6000 +CPU Revision : 0x10 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32r loongarch32s loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lspw lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 +``` + +
+ +
+`sudo dmidecode -t 0,1,2,4,7` + +``` +# dmidecode 3.6 +Getting SMBIOS data from sysfs. +SMBIOS 3.2.0 present. + +Handle 0x0000, DMI type 0, 26 bytes +BIOS Information + Vendor: Loongson + Version: Loongson-UDK2018-V4.0.05823-stable202408 + Release Date: 11/12/24 17:25:58 + ROM Size: 8 MB + Characteristics: + PCI is supported + BIOS is upgradeable + Boot from CD is supported + Selectable boot is supported + BIOS ROM is socketed + Serial services are supported (int 14h) + USB legacy is supported + UEFI is supported + +Handle 0x0001, DMI type 1, 27 bytes +System Information + Manufacturer: Loongson + Product Name: Loongson-3C6000-7A2000-2w-V0.1-EVB + Version: To Be Filled By O.E.M + Serial Number: To Be Filled By O.E.M + UUID: Not Present + Wake-up Type: Power Switch + SKU Number: To Be Filled By O.E.M + Family: To Be Filled By O.E.M + +Handle 0x0002, DMI type 2, 17 bytes +Base Board Information + Manufacturer: Loongson + Product Name: Loongson-3C6000-7A2000-2w-EVB-V1.21 + Version: To Be Filled By O.E.M + Serial Number: To Be Filled By O.E.M + Asset Tag: To Be Filled By O.E.M + Features: + Board is a hosting board + Board is replaceable + Location In Chassis: Not Specified + Chassis Handle: 0x0000 + Type: Motherboard + Contained Object Handles: 0 + +Handle 0x0004, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 1 + Operational Mode: Write Back + Location: Internal + Installed Size: 64 kB + Maximum Size: 64 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 4-way Set-associative + +Handle 0x0005, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 2 + Operational Mode: Write Back + Location: Internal + Installed Size: 256 kB + Maximum Size: 256 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 16-way Set-associative + +Handle 0x0006, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 3 + Operational Mode: Write Back + Location: Internal + Installed Size: 64 MB + Maximum Size: 64 MB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 16-way Set-associative + +Handle 0x0007, DMI type 4, 48 bytes +Processor Information + Socket Designation: CPU0 + Type: Central Processor + Family: Loongson 3C + Manufacturer: Loongson + ID: 33 43 36 30 30 30 00 00 + Signature: Processor Identity 0x30364333 + + Version: Loongson-3C6000 + Voltage: 1.2 V + External Clock: 25 MHz + Max Speed: 2200 MHz + Current Speed: 2200 MHz + Status: Populated, Enabled + Upgrade: Socket BGA2422 + L1 Cache Handle: 0x0004 + L2 Cache Handle: 0x0005 + L3 Cache Handle: 0x0006 + Serial Number: Not Specified + Asset Tag: Not Specified + Part Number: Not Specified + Core Count: 32 + Core Enabled: 32 + Thread Count: 32 + Characteristics: + 64-bit capable + Multi-Core + Hardware Thread +``` + +
+ +## ASUS XC-LS3A6M {#asus-xc-ls3a6m} + +From a software standpoint, this motherboard closely resembles the XA61200, with the primary difference being the inclusion of a Motorcomm YT6801 Ethernet controller. + +The firmware used to collect this data is a test version with the graphical display feature removed to support AMD GPUs based on the Navi architecture. The kernel also includes some extra drivers and in-development features. + +`uname -srvmpio`: `Linux 6.9.0-rc7-00036-g379ee315680a #1 SMP PREEMPT_DYNAMIC Wed Oct 11 05:48:28 PM CST 2023 loongarch64 unknown unknown GNU/Linux` + +
+`CPUCFG` + +```c +CPUCFG.0x0 = 0x0014d000 +CPUCFG.0x1 = 0x07f2f2fe +CPUCFG.0x2 = 0x7e7cccc7 +CPUCFG.0x3 = 0x00cefcff +CPUCFG.0x4 = 0x05f5e100 +CPUCFG.0x5 = 0x00010001 +CPUCFG.0x6 = 0x00007f33 +CPUCFG.0x10 = 0x00002c3d +CPUCFG.0x11 = 0x06080003 +CPUCFG.0x12 = 0x06080003 +CPUCFG.0x13 = 0x0608000f +CPUCFG.0x14 = 0x060e000f +``` + +
+ +
+`/proc/cpuinfo` + +``` +system type : generic-loongson-machine + +processor : 0 +package : 0 +core : 0 +global_id : 0 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 1 +package : 0 +core : 0 +global_id : 1 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 2 +package : 0 +core : 1 +global_id : 2 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 3 +package : 0 +core : 1 +global_id : 3 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 4 +package : 0 +core : 2 +global_id : 4 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 5 +package : 0 +core : 2 +global_id : 5 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 6 +package : 0 +core : 3 +global_id : 6 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 7 +package : 0 +core : 3 +global_id : 7 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +``` + +
+ +
+`sudo dmidecode -t 0,1,2,4,7` + +``` +# dmidecode 3.6 +Getting SMBIOS data from sysfs. +SMBIOS 3.2.0 present. + +Handle 0x0000, DMI type 0, 26 bytes +BIOS Information + Vendor: Loongson + Version: 9001 + Release Date: 03/25/24 13:57:18 + ROM Size: 4 MB + Characteristics: + PCI is supported + BIOS is upgradeable + Boot from CD is supported + Selectable boot is supported + BIOS ROM is socketed + Serial services are supported (int 14h) + USB legacy is supported + UEFI is supported + +Handle 0x0001, DMI type 1, 27 bytes +System Information + Manufacturer: Loongson + Product Name: XC-LS3A6M + Version: To Be Filled By O.E.M + Serial Number: To Be Filled By O.E.M + UUID: 2dd58a14-107c-6162-0130-107c6162012f + Wake-up Type: Power Switch + SKU Number: To Be Filled By O.E.M + Family: To Be Filled By O.E.M + +Handle 0x0002, DMI type 2, 17 bytes +Base Board Information + Manufacturer: Loongson + Product Name: XC-LS3A6M + Version: To Be Filled By O.E.M + Serial Number: 240132082200051 + Asset Tag: To Be Filled By O.E.M + Features: + Board is a hosting board + Board is replaceable + Location In Chassis: Not Specified + Chassis Handle: 0x0000 + Type: Motherboard + Contained Object Handles: 0 + +Handle 0x0004, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 1 + Operational Mode: Write Back + Location: Internal + Installed Size: 64 kB + Maximum Size: 64 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 4-way Set-associative + +Handle 0x0005, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 2 + Operational Mode: Write Back + Location: Internal + Installed Size: 256 kB + Maximum Size: 256 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 16-way Set-associative + +Handle 0x0006, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 3 + Operational Mode: Write Back + Location: Internal + Installed Size: 16 MB + Maximum Size: 16 MB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 16-way Set-associative + +Handle 0x0007, DMI type 4, 50 bytes +Processor Information + Socket Designation: CPU0 + Type: Central Processor + Family: Loongson 3A + Manufacturer: Loongson + ID: 33 41 36 30 30 30 2D 48 + Signature: Processor Identity 0x30364133 + + Version: Loongson-3A6000-HV + Voltage: 1.2 V + External Clock: 25 MHz + Max Speed: 2500 MHz + Current Speed: 2500 MHz + Status: Populated, Enabled + Upgrade: Socket BGA2422 + L1 Cache Handle: 0x0004 + L2 Cache Handle: 0x0005 + L3 Cache Handle: 0x0006 + Serial Number: Not Specified + Asset Tag: Not Specified + Part Number: Not Specified + Core Count: 8 + Core Enabled: 8 + Thread Count: 8 + Characteristics: + 64-bit capable + Multi-Core + Hardware Thread + +``` + +
+ +## 3A6000 Evaluation Board (XA612A0) {#3a6000-evb-xa612a0} + +This model is compatible with XA61200 firmware, differing only in minor details like the network port. Flashing another model’s firmware can still power up the board, but certain onboard devices, such as the network port, may remain unrecognized or unusable because the LS7A bridging chip is not configured for this model. + +`uname -srvmpio`: `Linux 6.6.0-rc3-next-20230928-gbcdaf018db45 #3 SMP PREEMPT Sun Jun 25 12:04:01 AM CST 2023 loongarch64 unknown unknown GNU/Linux` + +
+`CPUCFG` + +``` +CPUCFG.0x0 = 0x0014d000 +CPUCFG.0x1 = 0x07f2f2fe +CPUCFG.0x2 = 0x7e7cccc7 +CPUCFG.0x3 = 0x00cefcff +CPUCFG.0x4 = 0x05f5e100 +CPUCFG.0x5 = 0x00010001 +CPUCFG.0x6 = 0x00007f33 +CPUCFG.0x10 = 0x00002c3d +CPUCFG.0x11 = 0x06080003 +CPUCFG.0x12 = 0x06080003 +CPUCFG.0x13 = 0x0608000f +CPUCFG.0x14 = 0x060e000f +``` + +
+ +
+`/proc/cpuinfo` + +``` +system type : generic-loongson-machine + +processor : 0 +package : 0 +core : 0 +global_id : 0 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 1 +package : 0 +core : 0 +global_id : 1 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 2 +package : 0 +core : 1 +global_id : 2 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 3 +package : 0 +core : 1 +global_id : 3 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 4 +package : 0 +core : 2 +global_id : 4 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 5 +package : 0 +core : 2 +global_id : 5 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 6 +package : 0 +core : 3 +global_id : 6 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +processor : 7 +package : 0 +core : 3 +global_id : 7 +CPU Family : Loongson-64bit +Model Name : Loongson-3A6000-HV +CPU Revision : 0x00 +FPU Revision : 0x00 +CPU MHz : 2500.00 +BogoMIPS : 5000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 4 + +``` + +
+ +
+`sudo dmidecode -t 0,1,2,4,7` + +``` +# dmidecode 3.5 +Getting SMBIOS data from sysfs. +SMBIOS 3.2.0 present. + +Handle 0x0000, DMI type 0, 26 bytes +BIOS Information + Vendor: Loongson + Version: Loongson-UDK2018-V4.0.05634-stable202308 + Release Date: 11/29/23 18:07:37 + ROM Size: 4 MB + Characteristics: + PCI is supported + BIOS is upgradeable + Boot from CD is supported + Selectable boot is supported + BIOS ROM is socketed + Serial services are supported (int 14h) + USB legacy is supported + UEFI is supported + +Handle 0x0001, DMI type 1, 27 bytes +System Information + Manufacturer: Loongson + Product Name: Loongson-3A6000-HV-7A2000-1w-V0.1-EVB + Version: To Be Filled By O.E.M + Serial Number: To Be Filled By O.E.M + UUID: Not Present + Wake-up Type: Power Switch + SKU Number: To Be Filled By O.E.M + Family: To Be Filled By O.E.M + +Handle 0x0002, DMI type 2, 17 bytes +Base Board Information + Manufacturer: Loongson + Product Name: Loongson-3A6000-HV-7A2000-1w-EVB-V1.21 + Version: To Be Filled By O.E.M + Serial Number: To Be Filled By O.E.M + Asset Tag: To Be Filled By O.E.M + Features: + Board is a hosting board + Board is replaceable + Location In Chassis: Not Specified + Chassis Handle: 0x0000 + Type: Motherboard + Contained Object Handles: 0 + +Handle 0x0004, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 1 + Operational Mode: Write Back + Location: Internal + Installed Size: 64 kB + Maximum Size: 64 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 4-way Set-associative + +Handle 0x0005, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 2 + Operational Mode: Write Back + Location: Internal + Installed Size: 256 kB + Maximum Size: 256 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 16-way Set-associative + +Handle 0x0006, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 3 + Operational Mode: Write Back + Location: Internal + Installed Size: 16 MB + Maximum Size: 16 MB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 16-way Set-associative + +Handle 0x0007, DMI type 4, 48 bytes +Processor Information + Socket Designation: CPU0 + Type: Central Processor + Family: + Manufacturer: Loongson + ID: 33 41 36 30 30 30 2D 48 + Version: Loongson-3A6000-HV + Voltage: 1.2 V + External Clock: 25 MHz + Max Speed: 2500 MHz + Current Speed: 2500 MHz + Status: Populated, Enabled + Upgrade: + L1 Cache Handle: 0x0004 + L2 Cache Handle: 0x0005 + L3 Cache Handle: 0x0006 + Serial Number: Not Specified + Asset Tag: Not Specified + Part Number: Not Specified + Core Count: 8 + Core Enabled: 8 + Thread Count: 8 + Characteristics: + 64-bit capable + Multi-Core + Hardware Thread + +``` + +
+ +## 3C5000 Single-Socket Server + +`uname -srvmpio`: `Linux 6.5.3-aosc-main #1 SMP PREEMPT Fri Sep 22 00:30:38 UTC 2023 loongarch64 unknown unknown GNU/Linux` + +
+`CPUCFG` + +``` +CPUCFG.0x0 = 0x0014c011 +CPUCFG.0x1 = 0x03f2f2fe +CPUCFG.0x2 = 0x007ccfc7 +CPUCFG.0x3 = 0x0000fcff +CPUCFG.0x4 = 0x05f5e100 +CPUCFG.0x5 = 0x00010001 +CPUCFG.0x6 = 0x00007f33 +CPUCFG.0x10 = 0x00002c3d +CPUCFG.0x11 = 0x06080003 +CPUCFG.0x12 = 0x06080003 +CPUCFG.0x13 = 0x0608000f +CPUCFG.0x14 = 0x060e000f +CPUCFG.0x30 = 0x0000000e +``` + +
+ +
+`/proc/cpuinfo` + +``` +system type : generic-loongson-machine + +processor : 0 +package : 0 +core : 0 +global_id : 0 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 1 +package : 0 +core : 1 +global_id : 1 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 2 +package : 0 +core : 2 +global_id : 2 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 3 +package : 0 +core : 3 +global_id : 3 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 4 +package : 0 +core : 4 +global_id : 4 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 5 +package : 0 +core : 5 +global_id : 5 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 6 +package : 0 +core : 6 +global_id : 6 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 7 +package : 0 +core : 7 +global_id : 7 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 8 +package : 0 +core : 8 +global_id : 8 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 9 +package : 0 +core : 9 +global_id : 9 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 10 +package : 0 +core : 10 +global_id : 10 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 11 +package : 0 +core : 11 +global_id : 11 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 12 +package : 0 +core : 12 +global_id : 12 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 13 +package : 0 +core : 13 +global_id : 13 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 14 +package : 0 +core : 14 +global_id : 14 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 15 +package : 0 +core : 15 +global_id : 15 +CPU Family : Loongson-64bit +Model Name : Loongson-3C5000 +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2200.00 +BogoMIPS : 4400.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +``` + +
+ +
+`sudo dmidecode -t 0,1,2,4,7` + +``` +# dmidecode 3.2 +Getting SMBIOS data from sysfs. +SMBIOS 3.2.0 present. + +Handle 0x0000, DMI type 0, 26 bytes +BIOS Information + Vendor: Loongson + Version: Loongson-UDK2018-V4.0.05420-stable202302 + Release Date: 05/27/23 17:52:43 + ROM Size: 4096 kB + Characteristics: + PCI is supported + BIOS is upgradeable + Boot from CD is supported + Selectable boot is supported + BIOS ROM is socketed + Serial services are supported (int 14h) + USB legacy is supported + UEFI is supported + BIOS Revision: 4.0 + +Handle 0x0001, DMI type 1, 27 bytes +System Information + Manufacturer: To be filled by O.E.M.To be fill + Product Name: To be filled by O.E.M.To be fill + Version: To be filled by O.E.M.To be fill + Serial Number: To be filled by O.E.M.To be fill + UUID: Not Present + Wake-up Type: Power Switch + SKU Number: Not Specified + Family: Not Specified + +Handle 0x0002, DMI type 2, 17 bytes +Base Board Information + Manufacturer: To be filled by O.E.M.To be fill + Product Name: To be filled by O.E.M.To be fill + Version: To be filled by O.E.M.To be fill + Serial Number: To be filled by O.E.M.To be fill + Asset Tag: To be filled by O.E.M.To be fill + Features: + Board is a hosting board + Board is replaceable + Location In Chassis: Not Specified + Chassis Handle: 0x0000 + Type: Motherboard + Contained Object Handles: 0 + +Handle 0x0004, DMI type 4, 48 bytes +Processor Information + Socket Designation: CPU0 + Type: Central Processor + Family: + Manufacturer: Loongson + ID: 33 43 35 30 30 30 00 00 + Version: Loongson-3C5000 + Voltage: 1.2 V + External Clock: 25 MHz + Max Speed: 2000 MHz + Current Speed: 2200 MHz + Status: Populated, Enabled + Upgrade: + L1 Cache Handle: Not Provided + L2 Cache Handle: Not Provided + L3 Cache Handle: Not Provided + Serial Number: Not Specified + Asset Tag: Not Specified + Part Number: Not Specified + Core Count: 16 + Core Enabled: 16 + Thread Count: 16 + Characteristics: + 64-bit capable + Multi-Core + Hardware Thread + +Handle 0x0005, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 1 + Operational Mode: Write Back + Location: Internal + Installed Size: 64 kB + Maximum Size: 64 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 4-way Set-associative + +Handle 0x0006, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 2 + Operational Mode: Write Back + Location: Internal + Installed Size: 256 kB + Maximum Size: 256 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 16-way Set-associative + +Handle 0x0007, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 3 + Operational Mode: Write Back + Location: Internal + Installed Size: 32768 kB + Maximum Size: 32768 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 16-way Set-associative + +``` + +
+ +## 3A5000M Laptop + +`uname -srvmpio`: `Linux 6.7.0-aosc-main #1 SMP PREEMPT_DYNAMIC Fri Dec 8 03:17:48 UTC 2023 loongarch64 unknown unknown GNU/Linux` + +
+`CPUCFG` + +``` +CPUCFG.0x0 = 0x0014c011 +CPUCFG.0x1 = 0x03f2f2fe +CPUCFG.0x2 = 0x007ccfc7 +CPUCFG.0x3 = 0x0000fcff +CPUCFG.0x4 = 0x05f5e100 +CPUCFG.0x5 = 0x00010001 +CPUCFG.0x6 = 0x00007f33 +CPUCFG.0x10 = 0x00002c3d +CPUCFG.0x11 = 0x06080003 +CPUCFG.0x12 = 0x06080003 +CPUCFG.0x13 = 0x0608000f +CPUCFG.0x14 = 0x060e000f +CPUCFG.0x30 = 0x0000000e +``` + +
+ +
+`/proc/cpuinfo` + +``` +system type : generic-loongson-machine + +processor : 0 +package : 0 +core : 0 +global_id : 0 +CPU Family : Loongson-64bit +Model Name : Loongson-3A5000M +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2000.00 +BogoMIPS : 4000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 1 +package : 0 +core : 1 +global_id : 1 +CPU Family : Loongson-64bit +Model Name : Loongson-3A5000M +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2000.00 +BogoMIPS : 4000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 2 +package : 0 +core : 2 +global_id : 2 +CPU Family : Loongson-64bit +Model Name : Loongson-3A5000M +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2000.00 +BogoMIPS : 4000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 + +processor : 3 +package : 0 +core : 3 +global_id : 3 +CPU Family : Loongson-64bit +Model Name : Loongson-3A5000M +CPU Revision : 0x11 +FPU Revision : 0x00 +CPU MHz : 2000.00 +BogoMIPS : 4000.00 +TLB Entries : 2112 +Address Sizes : 48 bits physical, 48 bits virtual +ISA : loongarch32 loongarch64 +Features : cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips +Hardware Watchpoint : yes, iwatch count: 8, dwatch count: 8 +``` + +
+ +
+`sudo dmidecode -t 0,1,2,4,7` + +``` +# dmidecode 3.2 +Getting SMBIOS data from sysfs. +SMBIOS 3.2.0 present. + +Handle 0x0000, DMI type 0, 26 bytes +BIOS Information + Vendor: Loongson + Version: Loongson-UDK2018-V4.0.05132-beta10 + Release Date: 07/26/2023 + ROM Size: 4096 kB + Characteristics: + PCI is supported + BIOS is upgradeable + Boot from CD is supported + Selectable boot is supported + BIOS ROM is socketed + Serial services are supported (int 14h) + USB legacy is supported + UEFI is supported + BIOS Revision: 4.0 + +Handle 0x0001, DMI type 1, 27 bytes +System Information + Manufacturer: Loongson + Product Name: Loongson-3A5000M-7A1000-Laptop-Eascs-L71 + Version: Not Specified + Serial Number: Not Specified + UUID: Not Present + Wake-up Type: Power Switch + SKU Number: Not Specified + Family: Not Specified + +Handle 0x0002, DMI type 2, 17 bytes +Base Board Information + Manufacturer: Loongson + Product Name: Loongson-LS3A5000-7A1000-Laptop-Eascs-L71 + Version: Not Specified + Serial Number: Not Specified + Asset Tag: Not Specified + Features: + Board is a hosting board + Board is replaceable + Location In Chassis: Not Specified + Chassis Handle: 0x0000 + Type: Motherboard + Contained Object Handles: 0 + +Handle 0x0004, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 1 + Operational Mode: Write Back + Location: Internal + Installed Size: 64 kB + Maximum Size: 64 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 4-way Set-associative + +Handle 0x0005, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 2 + Operational Mode: Write Back + Location: Internal + Installed Size: 256 kB + Maximum Size: 256 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 16-way Set-associative + +Handle 0x0006, DMI type 7, 27 bytes +Cache Information + Socket Designation: Not Specified + Configuration: Enabled, Not Socketed, Level 3 + Operational Mode: Write Back + Location: Internal + Installed Size: 16384 kB + Maximum Size: 16384 kB + Supported SRAM Types: + Burst + Pipeline Burst + Synchronous + Installed SRAM Type: Burst Pipeline Burst Synchronous + Speed: Unknown + Error Correction Type: Single-bit ECC + System Type: Data + Associativity: 16-way Set-associative + +Handle 0x0007, DMI type 4, 48 bytes +Processor Information + Socket Designation: CPU1 + Type: Central Processor + Family: + Manufacturer: Loongson + ID: 33 41 35 30 30 30 4D 00 + Version: Loongson-3A5000M + Voltage: 1.2 V + External Clock: 25 MHz + Max Speed: 2000 MHz + Current Speed: 2000 MHz + Status: Populated, Enabled + Upgrade: + L1 Cache Handle: 0x0004 + L2 Cache Handle: 0x0005 + L3 Cache Handle: 0x0006 + Serial Number: Not Specified + Asset Tag: Not Specified + Part Number: Not Specified + Core Count: 4 + Core Enabled: 4 + Thread Count: 4 + Characteristics: + 64-bit capable + Multi-Core + Hardware Thread +``` + +
+ +## For Contributors: Template for Adding New Hardware and Software Platforms {#template} + +`uname -srvmpio`: `TODO` + +
+`CPUCFG` + +```c +// Compile and run the following C program, then paste the output here. +// Replace this code with the output and remove “c” from the fenced code block’s language label. +#include +#include + +int main(void) +{ + int i; + for (i = 0; i < 128; i++) { + unsigned int data = __cpucfg(i); + if (!data) + continue; + printf("CPUCFG.0x%-2x = 0x%08x\n", i, data); + } + return 0; +} +``` + +
+ +
+`/proc/cpuinfo` + +``` +TODO +``` + +
+ +
+`sudo dmidecode -t 0,1,2,4,7` + +``` +TODO +``` + +
+ diff --git a/i18n/en/docusaurus-plugin-content-docs/current/errata.md b/i18n/en/docusaurus-plugin-content-docs/current/errata.md new file mode 100644 index 00000000..273c1a24 --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current/errata.md @@ -0,0 +1,22 @@ +--- +sidebar_position: 8 +--- + +# Loongson Hardware Errata Summary + +This page is unofficially maintained and continuously updated to collect known hardware flaws (errata) on Loongson platforms, complementing the relevant official materials. + +:::info Frequently Updated! +This is a living document, and its content will change as conditions evolve. Check back often! +::: + +## Possible LS7A Bridge Hardware Flaw Causing AMDGPU Driver Crashes + +If you see similar logs in the kernel messages or experience desktop freezes: +``` +[ 9037.053812] radeon 0000:07:00.0: ring 0 stalled for more than 5657104msec +[ 9037.060557] radeon 0000:07:00.0: GPU lockup (current fence id 0x00000000000001b4 last fence id 0x00000000000001ca on ring 0) +``` +Try adding `amdgpu.dpm=0` to the kernel command line to disable AMDGPU dynamic frequency scaling as a workaround. This is confirmed to be caused by a hardware flaw in the LS7A bridge chip. + +Affected platforms: 3A5000, 3A6000, 3C5000 (both 7A1000 and 7A2000 bridge-based boards). diff --git a/i18n/en/docusaurus-plugin-content-docs/current/intro.md b/i18n/en/docusaurus-plugin-content-docs/current/intro.md new file mode 100644 index 00000000..449c34e1 --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current/intro.md @@ -0,0 +1,14 @@ +--- +sidebar_position: 1 +--- + +# Reading Materials Homepage + +In addition to tracking the progress of upstream projects, the "Are We Loong Yet?" project also collects and maintains, and writes some other reading materials around the Loong architecture. This website is entirely maintained by community volunteers and sympathizers of the Loongson route, and the source code is hosted on GitHub. You are always welcome to visit. + +* [How to Address the Loong Architecture?](loong-or-loongarch.md) +* [The Old World and the New World](old-and-new-worlds.md) +* [Baseline Reference of Infra Component Versions](baseline-reference.md) +* [Typical LoongArch Configuration Data Collection for Typical LoongArch Hardware/Software Combinations](collection-of-typical-configurations.md) +* [LoongArch Hardware Errata Collection](errata.md) +* [Linux Upstream Hardware Support Status](linux-upstream-support.md) diff --git a/i18n/en/docusaurus-plugin-content-docs/current/linux-upstream-support.md b/i18n/en/docusaurus-plugin-content-docs/current/linux-upstream-support.md new file mode 100644 index 00000000..4f614c32 --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current/linux-upstream-support.md @@ -0,0 +1,88 @@ +--- +sidebar_position: 7 +--- + +# Linux Upstream Hardware Support Status + +This page tracks the support status of Loongson platform-related hardware in the upstream Linux kernel. In the following tables, the conventions are: + +- Version: Supported from this Linux version +- OK: Uses standard interfaces, no additional support needed +- WIP: Patches exist but not yet merged upstream +- TODO: Functionality exists but no patches available +- N/A: Hardware does not support this feature +- ?: Lack of data (no information submitted yet, contributions welcome!) + +## CPU Support Status + +| Feature | 3A5000 | 3A6000 | 3C6000 | +| ---------------------- | ---------------- | ---------------- | ---------------- | +| SMT | N/A | [6.5][smt] | [6.5][smt] | +| [AVEC][avec-docs] | N/A | N/A | [6.12][avec] | +| LCL (CPU PCIe) | N/A | N/A | OK | +| LSX | [6.5][lsx] | [6.5][lsx] | [6.5][lsx] | +| LASX | OK (same as LSX) | OK (same as LSX) | OK (same as LSX) | +| LBT | [6.6][lbt] | [6.6][lbt] | [6.6][lbt] | +| LVZ (KVM) | [6.7][kvm] | [6.7][kvm] | [6.7][kvm] | +| HWMon | [WIP][hwmon] | [WIP][hwmon] | [WIP][hwmon] | +| CPUFreq[^cpufreq-abis] | [6.11][cpufreq] | [6.11][cpufreq] | [6.11][cpufreq] | + +| Feature | 2K1000LA | 2K1500 | 2K2000 | 2K0300 | 2K0500 | 2K3000/3B6000M[^wip] | +| ---------------------- | ---------- | ------ | ---------- | ------ | ------ | -------------------- | +| SMT | N/A | N/A | N/A | N/A | N/A | ? | +| [AVEC][avec-docs] | N/A | N/A | N/A | N/A | N/A | ? | +| LCL (CPU PCIe) | N/A | N/A | N/A | N/A | N/A | ? | +| LSX | [6.5][lsx] | ? | [6.5][lsx] | ? | ? | [6.5][lsx] | +| LASX | N/A | N/A | N/A | N/A | N/A | OK (same as LSX) | +| LBT | N/A | N/A | N/A | N/A | N/A | ? | +| LVZ (KVM) | N/A | N/A | N/A | N/A | N/A | ? | +| HWMon | ? | ? | ? | ? | ? | ? | +| CPUFreq[^cpufreq-abis] | ? | ? | ? | ? | ? | ? | + +[smt]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f6f0c9a74a48448583c3cb0f3f067bc3fe0f13c6 +[avec]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae16f05c928a1336d5d9d19fd805d7bf29c3f0c8 +[avec-docs]: https://www.kernel.org/doc/html/latest/translations/zh\_CN/arch/loongarch/irq-chip-model.html#id2 +[kvm]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c1fc48aad14dbe7654f5986afb906332b528d54b +[lsx]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=616500232e632dba8b03981eeccadacf2fbf1c30 +[lbt]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd3c5798484aa9a08302a844d7a75a2ee3b53d05 +[hwmon]: https://github.com/loongarchlinux/linux/commit/fbc7e8f1e72f9efee68cfe7b70cc397adc325818 +[cpufreq]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccf51454145bffd98e31cdbe54a4262473c609e2 + +[^wip]: This model has not been officially released or even fully developed, so all related content is based on reasonable speculation from currently available public information. "Are We Loong Yet?" is not responsible for the accuracy of this information. +[^cpufreq-abis]: The cpufreq operations on the Loongson platform largely rely on the management core (usually a small LA132 core) to assist in execution. The system program on the main core communicates with the RTOS on the management core to indirectly achieve control, so the management core firmware communication protocol is an ABI boundary that needs to consider compatibility. Similar to the [Old and New World issues](./old-and-new-worlds.md) in the Loongson Linux ecosystem, the CPUFreq driver also has two versions, and the mainstream off-the-shelf hardware generally carries a management core firmware communication protocol that is incompatible with the Linux upstream driver implementation. Some domestic Linux distributions' Linux forks integrate the old protocol, such as [deepin](https://github.com/deepin-community/kernel/pull/143), openEuler [甲](https://gitee.com/openeuler/kernel/issues/I6BWFP) [乙](https://gitee.com/openeuler/kernel/commit/6b4ebaa38760203e2e53878b8fa59bf2be84e760), and [openAnolis](https://gitee.com/anolis/cloud-kernel/blob/devel-6.6/drivers/cpufreq/loongson3-acpi-cpufreq.c) (with a submission history similar to openEuler), for reference. + +## Bridge Chip Support Status + +| Feature | 7A1000 | 7A2000 | +| -------------------------- | ----------------------- | ------------------- | +| RTC (UEFI)[^rtc-drivers] | OK | OK | +| RTC (Native)[^rtc-drivers] | [6.5][rtc-loongson] | [6.5][rtc-loongson] | +| GPIO | [6.4][gpio] | [6.4][gpio] | +| I2C | [6.3][i2c] | [6.3][i2c] | +| Ethernet | [5.14][dwmac-2k-7a1000] | [WIP][dwmac-7a2000] | +| OHCI USB1.1 | OK | OK | +| EHCI USB2.0 | OK | OK | +| XHCI USB3.0 | N/A | OK | +| GPU | TODO | TODO | +| DC | [6.6][dc] | [6.6][dc] | +| HDA | [6.5][hda] | [6.5][hda] | +| AC97 | TODO | N/A | +| I2S | N/A | [6.5][i2s] | +| SATA | OK | OK | +| PCIE | OK | OK | +| SPI | [6.6][spi] | [6.6][spi] | +| LPC | TODO | TODO | +| IOMMU | N/A | [WIP][iommu] | + +[rtc-loongson]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b733a9ebc3d8011ca66ec6ff17f55a440358794 +[gpio]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7944d3b7fe86067509751473aa917fdfd662d92c +[i2c]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=015e61f0bffd46600496e50d3b2298f51f6b11a8 +[dwmac-2k-7a1000]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30bba69d7db40e732d6c0aa6d4890c60d717e314 +[dwmac-7a2000]: https://github.com/loongarchlinux/linux/commit/2a948c4b7bc5cc2689e2d0edfe83b4980b81b9ad +[dc]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f39db26c54281da6a785259498ca74b5e470476f +[hda]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28bd137a3c8e105587ba8c55b68ef43b519b270f +[i2s]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d84881e06836dc1655777a592b4279be76ad7324 +[spi]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6c7a864007b66e60a3f64858a9555efed408b048 +[iommu]: https://github.com/loongarchlinux/linux/commit/1d26eae35f9a6f9d318112c33a177b3612179b26 + +[^rtc-drivers]: In Loongson systems following the UEFI specification, the RTC can be operated through UEFI standard interfaces or by directly reading and writing related registers, but there is only one hardware resource. The native RTC driver is more for non-EFI Loongson systems, such as embedded devices booting with DT. diff --git a/i18n/en/docusaurus-plugin-content-docs/current/loong-or-loongarch.md b/i18n/en/docusaurus-plugin-content-docs/current/loong-or-loongarch.md new file mode 100644 index 00000000..8a8df8d6 --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current/loong-or-loongarch.md @@ -0,0 +1,98 @@ +--- +sidebar_position: 2 +--- + +# How to Refer to 龙架构? + +## A Guiding Principle + +In natural language: + +* In Chinese: Prefer "龙架构", optional "龙芯架构" +* In English: LoongArch (short for "Loong(son) Architecture") + +When mentioning bitness: + +* In Chinese: "32/64 位龙架构" +* In English: "32/64-bit LoongArch" or "LoongArch32/64" + +For identifiers in software not directly visible to end users: + +* If a short name is necessary or preferable: `loong` +* If the project calls `x86_64` as `amd64` and/or `aarch64` as `arm64`: `loong` +* If aligning with GNU target tuple / Debian multiarch tuple is prioritized: `loongarch` +* Otherwise: try `loongarch` to see if it looks and sounds good. If not, then `loong` + +You can add `32` `64` etc. as needed if bitness distinction is required in specific usage. + +## About Usage in Natural Language + +Initially, there was no name "龙架构". LoongArch was first associated with the Chinese name on April 30, 2021, when the "LoongArch Reference Manual" was first released: until then, LoongArch was paralleled with the term "龙芯架构", but the occasions of using "龙芯架构" were still rare. However, since Loongson's WeChat public account first used the term "龙架构" on April 13, 2022, people have generally referred to LoongArch as "龙架构" in Chinese contexts up to now (early 2023). + +Loongson has registered the trademarks "LoongArch", "龙芯架构", and "龙架构" in China, so please pay attention when using them. + +## About `loong` and `loongarch` (Short and Long Name Dispute) + +Since the registered trademarks are `LoongArch` and `LoongArch64`, in the earliest batch of adaptation contributions Loongson made to community projects, the architecture was named `loongarch`, `LOONGARCH`, or this name with the suffix `64`. However, the full name `loongarch64` seems a bit long compared to common other architectures like `x86_64`, `aarch64`, `riscv64`, and in cases like `ARCH=loongarch`, it appears even more redundant (which is different from the sense of redundancy in the Chinese language: "架构是龙架构" six characters, in the view of many people interviewed by the author of this entry, does not seem particularly redundant). Therefore, some communities chose to adopt the shorter names `loong` or `loong64` after discussion. This is similar to how many communities call `aarch64` as `arm64`. + +:::info Why not call it `la64`? + +Because there was once an architecture called `ia64`, although it has declined, it still exists in many people's memories. People generally avoid using names that differ only by one `i/l/1`, `O/0` when using Latin letters to avoid confusion, even though contemporary programming fonts have fully considered this to make these characters look distinguishable. (Not all times have programming fonts available.) Therefore, for occasions where the "architecture name" might be used in lowercase, `LA64/la64` is not suitable. + +"First come, first served" does not involve discrimination here. Because if LoongArch came first and Itanium architecture came later, people would reject the name `ia64` for the same reason, and people in that world line would probably call Itanium architecture `intel64` or `itanium`. + +::: + +:::info Why not call it `larch`? + +Besides LoongArch, Loongson actually registered the Chinese trademark LArch earlier. (Suspected to imitate `AArch`?) In the porting of the "three major pieces" of the GNU toolchain, the related team also used the term `LARCH` extensively to refer to LoongArch. But this usage has never been seen in other occasions or even in the work of other teams of Loongson[^1]. + +Given that since 2022, the terms `loongarch` and `loong` have been adopted by most projects, there is no chance to revive the name `larch` without increasing the user's memory burden. + +::: + +[^1]: The earliest LoongArch Go port actually used `GOARCH=larch64`, but it was replaced with `GOARCH=loongarch64` before it was first open-sourced. Later, it was changed to `GOARCH=loong64` based on upstream suggestions and community opinions. + +Unfortunately, some parts of these public discussions were misunderstood by some onlookers as "the 'community' picking on Loongson". These people do not consider `loongarch` to be lengthy[^2], and objectively, the long name has already been used in places like GNU target triples (the initial `config.guess` `config.sub` 龙架构 adaptation was submitted by Loongson's employees, using the long name), so they believe that allowing the use of `loong` actually increases the memory burden. Loongson has never stated in officially maintained documentation that `loong` is an optional name, which to some extent exacerbated the community's misunderstanding. + +[^2]: Even if, for example, the existing architecture identifiers in the project do not exceed 6 letters, in this mode of thinking, `loongarch` is considered the only feasible name. Why should others adapt to Loongson's practice? + +Although in practice, using or not using trademarks in software source code and developer communication does not affect the marketing promotion of the architecture, considering these subjective and objective factors, the author of this article still tried to balance "maintaining the integrity of Loongson's registered trademarks" and respecting the existing practices of various projects in the guiding principles at the beginning. + +## Names of LoongArch in Some Community Projects + +Linux distributions generally use a shorter architecture identifier, so they mostly call LoongArch `loong` or with a bitness suffix. + +|Distribution|Architecture Identifier| +|------------|------------------------| +|AOSC OS|`loongarch64`| +|Debian|| +|Gentoo|`loong`| +|Loong Arch Linux|`loong64`| +|RPM-based|`loongarch64`| +|Slackware|`loong64`| + +:::info Why does AOSC OS, a New World distribution, also use the term `loongarch64`? +According to the maintainer's own explanation, there are two main reasons: + +* The maintainer intentionally followed the official naming of Loogson; +* When AOSC OS started LoongArch work, there were already two architecture names `loongson2f` and `loongson3`, fearing that `loong64` would confuse users. +::: + +:::info Why do RPM-based distributions also use the term `loongarch64`? +[RPM's LoongArch support][rpm-loongarch64] was submitted upstream in early 2022. At that time, Loongson's employees were unaware of the community's discussion on this topic, and community contributors were also unaware of Loongson's activities; and RPM also calls AArch64 as `aarch64`, so the term `loongarch64` is self-consistent within the RPM scope, and RPM upstream quickly merged it. Therefore, to this day, RPM-based distributions retain this name, which now seems like an Old World term. +::: + +[rpm-loongarch64]: https://github.com/rpm-software-management/rpm/commit/7a014dae736f9c7a7c75f63deaa4dbbb9ae0249c + +The above information also applies to related derivative projects of each distribution if the corresponding projects have also followed up with LoongArch adaptation. + +The name of LoongArch in other software sometimes requires some memory. + +|Project|Name| +|-------|----| +|C#|[`LoongArch64`](https://learn.microsoft.com/zh-cn/dotnet/api/system.runtime.interopservices.architecture?view=net-8.0)| +|Go|`GOARCH=loong64`| +|Rust|`loongarch64-unknown-linux-gnu`| + +This table does not and cannot exhaust all software projects. If you have any additions, you can find the "Edit this page" link at the bottom of the page (pointing to the source file of this page in the upstream repository). diff --git a/i18n/en/docusaurus-plugin-content-docs/current/old-and-new-worlds.md b/i18n/en/docusaurus-plugin-content-docs/current/old-and-new-worlds.md new file mode 100644 index 00000000..de4bd533 --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current/old-and-new-worlds.md @@ -0,0 +1,192 @@ +--- +sidebar_position: 3 +--- + +# Old World and New World + +:::warning Under Construction! +This page is still under construction, and the content may be expanded or modified over time. Feel free to check back often! +::: + +:::info Do I need to care about this? +In short, if you don't compile and install software yourself, you probably don't need to worry about it. +Of course, casually browsing through this article might help you understand these terms in the future, or you can guide others who encounter issues. + +* If you are currently using Loongnix, Kylin, or UOS on a LoongArch computer, there will definitely be a full system upgrade in a few months or a year or two. + * If you don't upgrade, then external changes won't affect you. + * If you do upgrade, you shouldn't notice any difference in usage, which essentially means "migrating to the new world." +* If you are currently using Arch, Gentoo, etc., on a LoongArch computer, you are already a resident of the new world, and this doesn't concern you. + +The only situations where you might encounter issues are: + +* You are using Loongnix, Kylin, or UOS but have compiled some software yourself. + After the future full system upgrade, your self-compiled software may no longer work and will need to be recompiled or installed from the system package manager. +* You are a developer adapting or developing software for LoongArch. + If you have come to this page, you are likely already encountering issues, so read on! +::: + +As of early 2024, there are two incompatible software ecosystems for LoongArch, commonly referred to as the "old world" and the "new world." Loongson's materials also mention "ABI1.0" and "ABI2.0" (currently, all references do not include a space between "ABI" and the number). + +**The old world** refers to the initial LoongArch software ecosystem adapted internally by Loongson Technology and released alongside the public unveiling of LoongArch. +**The new world** refers to the completely open-source LoongArch software ecosystem developed collaboratively by Loongson Technology and community colleagues, following typical open-source community collaboration models. + +The emergence of the two worlds is a consequence of Loongson Technology's commercial strategy of secretly developing and suddenly launching the entire LoongArch ecosystem. This approach led to some unavoidable incompatible changes, resulting in challenges for both customers and the company itself. According to current trends and some public information, the old world will gradually phase out. Starting with the Loongson 3A6000 generation, the accompanying firmware of related products has been compatible with both the old and new worlds. However, as of early February 2024, it may take longer for distributions (such as Loongnix and other commercial distributions) to complete the migration, and thus they have not yet caught up with the official release of the 3A6000. + +When discussing Loongson topics, the terms "old world" and "new world" are used solely to distinguish between the two incompatible LoongArch ecosystems. Loongson's MIPS models are neither part of the old world nor the new world. They are generally referred to as "the MIPS-era Loongson." + +The terms "旧世界" and "新世界" are translated into English as "the old world" and "the new world," respectively. When used as adjectives, they are generally hyphenated as "old-world" and "new-world." If used frequently in a passage, the abbreviations "OW" and "NW" may also be used. + +## Which World Am I In? + +If any of the following conditions apply, you are using the **old world**: + +* The system is one of Kylin, Loongnix, or UOS. +* The kernel version starts with 4.19. +* You use WPS but have not installed `libLoL` or other old-world compatibility solutions. + +If none of these conditions apply, you are using the **new world**. + +This method of determination is based on known information as of February 2024. It may become inaccurate if not updated in time. + +## Which World Does This Software Belong To? + +You can use the `file` tool to easily check which world a binary program belongs to. Suppose you want to check the file `someprogram`, execute `file someprogram`. If the output line contains these words: + +``` +interpreter /lib64/ld.so.1, for GNU/Linux 4.15.0 +``` + +it indicates that this is an old-world program. + +Conversely, if the output line contains these words: + +``` +interpreter /lib64/ld-linux-loongarch-lp64d.so.1, for GNU/Linux 5.19.0 +``` + +it indicates that this is a new-world program. + +The above judgments apply to dynamically linked programs with glibc as the system libc. If the program is statically linked, there will be no interpreter information; if the program is written in Go or uses musl as the C library, there will be no `for GNU/Linux` marker in the file. In such cases, try running it—programs from the "other world" are unlikely to start normally. + +Of course, if your output looks like one of the following lines: + +``` +someprogram: Python script, Unicode text, UTF-8 text executable +someprogram: Bourne-Again shell script, ASCII text executable, with escape sequences +``` + +this indicates that the program you are checking is a script. Generally, script language programs do not care about the old or new world, but they may still rely on some binary components to work correctly. Therefore, the most reliable method is to try running it! + +## Why Call It "The Old World" and "The New World"? + +In other fields within the Chinese-speaking community, there are terms like "old-world/new-world monkeys" and "old-world/new-world wines," where "world" means "continent." The new world of LoongArch emerged later than the old world, and there are differences in how they operate, though they do interact. + +In technology, the terms "the old world" and "the new world" have appeared before. For example, the retro-computing community distinguishes "old-world" Macintosh models containing a ROM chip for the Macintosh Toolbox firmware from "new-world" Macintosh models that do not include this chip. Thus, old-world/new-world Macs entered the lexicon. + +On the other hand, users of Linux source-based distributions (such as Gentoo) often use expressions like “rebuild world.” Here, “world” refers to all packages in the system, analogous to userland. For Gentoo users, it also happens to represent the “@world” set. Meanwhile, the distinction between the old-world (OW) and the new-world (NW) LoongArch largely stems from small differences in the kernel-level system call interface, which cause incompatibilities among user-space programs. + +## Where Do the Two Worlds Differ? + +**Open-source availability.** The new world is fully open source. Parts of the old-world core remain closed for IP reasons, though some were later released. For example, old-world binutils and gcc sources came out months after initial release, Linux sources appeared in 2023, but the GSGPU shader compiler is still closed. Those that were released typically lack detailed Git histories, making upstream work difficult. + +**Available distributions.** Old-world distributions are only produced by a few commercial companies because the full source code is not publicly available. All community distributions belong to the new world. + +Known old-world (ports) distributions (alphabetical): +* 麒麟 (Kylin) +* Loongnix +* UOS + +Known new-world (ports) distributions (alphabetical): +* [ALT Linux](https://www.altlinux.org/Ports/loongarch64) +* [AOSC OS](https://aosc.io/zh-cn) +* [CLFS Manual & Builds](https://github.com/sunhaiyong1978/CLFS-for-LoongArch) +* [Debian](https://wiki.debian.org/Ports/loong64) +* [Fedora LoongArch Remix](https://github.com/fedora-remix-loongarch/releases-info) +* [Gentoo](https://wiki.gentoo.org/wiki/Project:LoongArch) +* [Loong Arch Linux](https://github.com/loongarchlinux) +* [Slackware](https://github.com/shipujin/slackware-loongarch64) +* [Yongbao](https://github.com/sunhaiyong1978/Yongbao) + +:::warning + +Some new-world distributions are built by Loongson staff. Compared to purely community-driven releases, they may include: + +* Code that has not yet been officially merged upstream (for example, kernel-level binary translation support). +* Content with unclear licensing (for example, LATX has no license agreement, defaults to all rights reserved, cannot be integrated, distributed, etc. by subjects other than Loongson) +* Non-open-source components (for example, packages like libffi, LibreOffice, and Chromium appeared early in CLFS and Loong Arch Linux, even before the earliest open-source patches made it upstream. Some are still not fully upstreamed. In the most extreme scenario, around early 2021, the LoongArch toolchain, kernel source, and QEMU changes were not yet open-sourced, hardware was barely available, and CLFS had already been released.) + +However, as time passes and more content moves upstream or matures, this situation will become less and less common until it disappears. + +::: + +**Software Versions Differ**. The base system of the old world generally follows the major Debian or RHEL version that was originally used for its porting. Because commercial companies may not prioritize (or have the capability) to track newer releases, old-world base system versions rarely receive major updates. Depending on your user scenarios and development or deployment habits, this can sometimes be beneficial and sometimes frustrating. + +Below is a comparison of some commonly used software and development tools in the two worlds: + +|Software|Old-world Version|New-world Version| +|----|----------|----------| +|Linux|4.19|≥ 5.19, commonly ≥ 6.1| +|binutils|2.31|≥ 2.38, commonly ≥ 2.40| +|gcc|8.3|≥ 12.1, commonly ≥ 13.1| +|glibc|2.28|≥ 2.36| +|LLVM|8|≥ 16| +|Node.js|14.16.1|≥ 18| +|Go|1.15、1.18、1.19|≥ 1.19| +|Rust|1.41、1.58|≥ 1.71| + +## How to Achieve Compatibility Between the Two Worlds? + +Because the differences between the old world and the new world (OW/NW) are not trivial, achieving perfect compatibility is quite difficult. One single solution cannot fulfill all of the following goals at once; trade-offs are inevitable: + +* Keep disk usage as small as possible. +* Minimize performance overhead. +* Minimize intrusive changes to the host system. +* Especially in extreme cases, maintain correctness: do not break operations that would succeed in the original world, nor force operations to succeed that should fail. + +Currently, the AOSC community’s [`libLoL`](https://liblol.aosc.io) is the most mature solution, already integrated by many new-world distributions. Loongson has also mentioned plans for a compatibility solution but has provided no public updates as of January 2024. + +## Common Pitfalls + +### Running a program returns “No such file or directory.” What’s going on? + +If you run a program and are told it doesn’t exist, for example: + +```sh-session +$ ./foo +zsh: no such file or directory: ./foo + +$ ./foo +zsh: 没有那个文件或目录: ./foo +``` + +If this file truly exists, you are most likely trying to run a program from the alien world world. The missing file is not the program itself but the so-called "ELF interpreter", as mentioned above when determining whether a program belongs to the old world or the new world. Please use a version of the program suited to your system, or ask the software provider for an adapted version. + +### I cross-compiled a Go program for LoongArch and got a segmentation fault. What happened? + +It might be caused by using the wrong Go toolchain, which inadvertently built a binary for a different ABI than intended. + +* For an old-world distribution, Loongson’s Go toolchain and the goproxy source (the "Loongson sources"; see below) must be used. +* For a new-world distribution, an upstream Go toolchain must be used; never use the "Loongson sources". + +In detail, when a Go program runs in the other world, a crucial initialization step makes an `rt_sigprocmask` system call. This call fails because the `NSIG` constant in the Go toolchain differs from what the kernel expects, causing Go to deliberately access an illegal address and crash right away. From the program’s perspective, a supposedly guaranteed system call has failed, indicating that kernel services are no longer reliable. + +### Loongson provides many mirrors (“Loongson sources”). Can I use them? + +Loongson indeed offers many “Loongson sources.” Old-world developers must use them (the system may already have the associated configuration changes), but new-world developers must not. + +As a rare exception for SEO and the spirit of helping each other (all developers are family), here are the relevant old-world documents. + +|Type|Typical Address|Notes| +|:--:|--------|----| +|Go|`http://goproxy.loongnix.cn:3000`|[Documentation](https://docs.loongnix.cn/golang/goproxy.html)| +|PyPI|`https://pypi.loongnix.cn/loongson/pypi`|[Documentation](https://docs.loongnix.cn/python/python.html)| +|npm|`https://registry.loongnix.cn:4873`|[Documentation](http://docs.loongnix.cn/nodejs/doc/list/03.%E9%BE%99%E8%8A%AFnpm%E7%9A%84%E5%AE%89%E8%A3%85%E5%92%8C%E4%BB%93%E5%BA%93%E9%85%8D%E7%BD%AE%E4%BD%BF%E7%94%A8.html)| +|NuGet|`https://nuget.loongnix.cn`|[Documentation](https://docs.loongnix.cn/dotnet/support/list/01.%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98-FAQ.html)| +|Rust
(crates.io)|`https://crates.loongnix.cn`|[Documentation](https://docs.loongnix.cn/rust/)| +|Harbor
(Container Images)|`https://cr.loongnix.cn`|[Documentation][loongson-cloud-community]| + +[loongson-cloud-community]: https://loongson-cloud-community.github.io/Loongson-Cloud-Community + +Since the old world ABI and API are not upstream and will not be upstream, packages that need to care about system-level ABI and API details cannot work properly in the old world with their official versions—those downloaded from upstream or regular mirrors. They either have not been adapted for LoongArch or have been adapted for the new world. Therefore, to facilitate software adaptation for the old world, Loongson has set up these sources: packages and their respective versions that would be affected have been modified for the old world in these sources. + +This is why new world developers should not use them for convenience: some packages downloaded from these sources are actually harmful to the new world, and integrity checks will fail—Loongson's behavior of providing modified code is indistinguishable from a "man-in-the-middle attack." Conversely, this is also why old world developers must enable them and disable the corresponding integrity checks. diff --git a/i18n/en/docusaurus-plugin-content-docs/current/world-compat-details/index.md b/i18n/en/docusaurus-plugin-content-docs/current/world-compat-details/index.md new file mode 100644 index 00000000..2f3c44dd --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current/world-compat-details/index.md @@ -0,0 +1,667 @@ +--- +sidebar_position: 4 +--- + +# The Old World and the New World (Low-Level Details) + +This documentation is primarily intended for developers working on LoongArch kernel development, distribution integration and other low-level tasks, providing technical details about the OW/NW compatibility issues and known compatibility solutions. + +Known compatibility approaches include: + +* [`libLoL`](https://liblol.aosc.io) + +## Introduction + +While programs from the old world (OW) and the new world (NW) are almost incompatible, this does not imply fundamental differences between them. On the contrary, they share many common characteristics that make compatibility technically feasible. In fact, any feature not explicitly listed as a difference between the worlds can be considered a commonality. To better understand both the differences and similarities between the old and new worlds, this document will highlight some of their key shared characteristics. + +This document examines the differences and commonalities between OW and NW from both kernel and user mode perspectives, primarily focusing on their externally visible characteristics rather than internal implementation details. Build system differences are not covered, as developers typically use a complete toolchain from the same world. Non-technical differences such as business strategies and community collaboration are also outside the scope of this document. + +Given that the Loongson ecosystem currently relies on the Linux kernel and glibc C runtime, and all "old-world" systems use this combination, for simplicity, when we refer to "kernel" or "user mode"/"libc", we mean Linux or glibc respectively. + +## Kernel + +The kernel's external interfaces can be divided into two aspects: the boot protocol, which can be viewed as an upstream interface, and system calls, which can be considered as downstream interfaces. + +### Boot Protocol + +At first glance, the kernel image files provided by OW distributions are in ELF format and require an OW-ported GRUB2 bootloader to boot. In contrast, NW kernel images are PE-format EFI applications (EFI Stub) that can be booted directly by UEFI firmware or through a NW-ported GRUB2 bootloader. + +Looking at the specific details of parameter passing from firmware to kernel, the Linux kernels of both worlds expect different data structures from their previous boot stage. See the following diagram for illustration. + +:::info Legend +* Rectangular nodes represent EFI applications (PE format images) +* Rounded nodes represent ELF format images +* Directed edges show control flow transitions, with labels indicating passed data structures +::: + +```mermaid +flowchart BT + subgraph linux [Linux] + OWLinuxELF(["Old-World Linux (ELF)"]) + NWLinuxStub["New-World Linux (EFI stub)"] + end + subgraph bootloader [Bootloader] + OWGrub2[Old-World GRUB2] + OWGrub2N[Old-World GRUB2] + NWGrub2[New-World GRUB2] + end + subgraph firmware [Firmware] + OWUEFI[[Old-World UEFI]] + NWUEFI[[New-World UEFI]] + end + + OWUEFI -->|"UEFI System Table (with BPI)"| OWGrub2 -->|BPI| OWLinuxELF + NWUEFI -->|"UEFI System Table"| OWGrub2N -->|UEFI System Table| OWLinuxELF + NWUEFI -->|"UEFI System Table"| NWGrub2 -->|UEFI System Table| NWLinuxStub + NWUEFI -->|"UEFI System Table"| NWLinuxStub +``` + +The old-world UEFI firmware comes in two versions, distinguished by their BPI structure signatures: `BPI01000` and `BPI01001`. While the UEFI firmware implementations like EDK2 share most behaviors between OW and NW, there are several notable differences: + +* Different MMU states when booting the OS + * Old World: The Direct Mapping Configuration Window (DMW) is already enabled when booting the OS, mapping virtual addresses like `0x9xxx_xxxx_xxxx_xxxx` to their corresponding physical memory space `0x0xxx_xxxx_xxxx_xxxx`. The PC register points to such virtual addresses. + + This "coincidentally" matches one of the fixed 1:1 mapping windows that Loongson Linux was required to use in the MIPS era due to architectural constraints. + Fast forward to the LoongArch era, this "coincidentally" remains the "coherent cached" DMW configuration shared between old-world kernels and new-world kernels that haven't fully switched to TLB. + + "Coherent Cached" (CC) is a term defined in Section 2.1.7 "Storage Access Types" of the LoongArch Reference Manual Volume 1. + + Ironically, although the firmware has already configured the same DMW before the kernel gains control, the old-world kernel entry point still repeats the configuration... + This obviously means one of these configurations is redundant! + + * New World: The DMW is not enabled when booting the OS, and the PC register points to physical addresses. + + The firmware should not, and indeed does not, make assumptions about the OS's memory management choices, let alone semi-forcing the OS to adopt a specific DMW configuration. + +* Different states of non-boot CPU cores when booting the OS + + In both OW and NW, when control is transferred to the OS, non-boot CPU cores are in an idle state - blocked executing the `idle 0` instruction while waiting for interrupts. When the system needs to wake up a specific CPU core, it writes the target jump address to that core's IPI (Inter-processor interrupt) mailbox register and triggers an IPI for that core. This wakes up the core, exits the `idle 0` instruction, and continues execution. The subsequent code reads the mailbox register and jumps to the stored address. + + In NW, since DMW is not enabled on any cores during system boot, physical addresses must be written to the mailbox registers. However, in OW, since DMW is already enabled on all cores at boot, virtual addresses starting with 0x9 must be written to the mailbox registers. + + For OW firmware version `BPI01001`, it appears the firmware was additionally adapted to handle physical addresses passed through the mailbox, so cores can boot successfully whether given virtual or physical addresses. + +* Pointers in UEFI tables + * Old World: Virtual addresses in the form of `0x9xxx_xxxx_xxxx_xxxx` are used for all pointers except ACPI table addresses. + * New World: All pointers are physical addresses. + +* Memory layout information passing + * Old World: The memory available for OS use is passed through the BPI data structure, while memory regions used or reserved by UEFI firmware are passed through the UEFI system table. The OS must combine both sources to obtain complete memory availability information. + * New World: Complete memory availability information is passed solely through the UEFI system table. + +* ACPI Data Structures: + * Old World: Some tables in firmware version `BPI01000` followed early Loongson standards that pre-dated ACPI 6.5. + + - MADT table used `ACPI_MADT_TYPE_LOCAL_APIC` to describe CPU core interrupt controller info, and `ACPI_MADT_TYPE_IO_APIC` for CPU socket interrupt controller info. + - In DSDT table, PCI root controller's IO resource descriptor lacked LIO controller MMIO offset information. Additionally, its IO port range didn't cover `0x0` to `0x4000`, expecting OS to unconditionally set address mapping for this range. Consequently, devices under LIO controller using IO ports in this range didn't declare dependencies on PCI root controller. + - Missing MCFG table for describing PCI root controller information. + + These structures were incompatible with ACPI 6.5. For example, when NW kernel encounters OW `BPI01000` firmware's MADT, it interprets the system as having 0 CPUs, leading to boot failure. + + OW firmware version `BPI01001` used the same ACPI tables as NW, conforming to ACPI 6.5 or later. + + * New World: Compliant with ACPI 6.5 or later versions. + +The old-world and new-world firmware also differ in how they pass essential boot information to the operating system. The new-world firmware directly passes the UEFI system table to the OS. The old-world firmware, following its MIPS-based Loongson predecessors, additionally passes a Loongson-specific "BPI" structure (`struct bootparamsinterface`, known as `struct boot_params` in Loongnix Linux source code, essentially the same thing): During boot, OW GRUB first checks for the presence of a BPI data structure in the UEFI system table. If found, indicating OW firmware, it passes the BPI structure to the OW kernel; if not found, indicating NW firmware, it passes the UEFI system table to the OW kernel instead. + +再具体一些，控制权从固件交出之后，早期引导流程的差异见以下示意图。 + +:::info 图例 +实线的边表示过程调用。有文字注解的虚线边表示数据流动，无文字注解的虚线边则表示有所简化的过程调用。 +::: + +```mermaid +flowchart TB + subgraph owgrub [Old-World GRUB] + OWGrub[Old-World GRUB] + OWGrubCheckBPI{{ Does UEFI System Table contain BPI? }} + OWGrub -->|Load ELF kernel into memory
ExitBootService
SetupDMW| OWGrubCheckBPI + end + subgraph nwgrub [New-World GRUB] + NWGrub[New-World GRUB] + end + subgraph ow [Old-World Linux] + OWKernelEntry[kernel_entry] + OWStartKernel[start_kernel] + OWFwInitEnv[fw_init_env] + + OWKernelEntry -.->|*fw_arg0 = a0
*fw_arg1 = a1
*fw_arg2 = a2| OWFwInitEnv + OWKernelEntry --> OWStartKernel -.-> OWFwInitEnv + + OWCheckArg0{{fw_arg0 > 1}} + OWCheckArg2{{fw_arg2 == 0}} + OWBPI([BPI Flow]) + OWUEFI([NW UEFI Flow]) + OWFDT([OW FDT Flow]) + + OWFwInitEnv --> OWCheckArg0 + OWCheckArg0 -->|Yes| OWBPI + OWCheckArg0 -->|No| OWCheckArg2 + OWCheckArg2 -->|Yes| OWFDT + OWCheckArg2 -->|No| OWUEFI + end + subgraph nw [New-World Linux] + NWKernelEntry[kernel_entry] + NWEfiEntry[efi_entry] + NWStartKernel[start_kernel] + NWInitEnviron[init_environ] + NWUEFI([Subsequent Flow]) + + NWKernelEntry -.->|*fw_arg0 = a0
*fw_arg1 = a1
*fw_arg2 = a2| NWInitEnviron + NWKernelEntry --> NWStartKernel -.-> NWInitEnviron -.-> NWUEFI + NWEfiEntry -->|ExitBootService
SetupDMW
a0 = 1
a1 = cmdline_ptr
a2 = efi_system_table| NWKernelEntry + end + + subgraph protocol [Firmware] + BPI[[OW Boot]] + UEFI[[NW Boot]] + end + + OWGrubCheckBPI -->|Yes
Merge system table memory info into BPI
a0 = argc
a1 = argv
a2 = &boot_params| OWKernelEntry + OWGrubCheckBPI -->|No
a0 = 1
a1 = cmdline_ptr
a2 = efi_system_table| OWKernelEntry + BPI --> |BPI data provided in UEFI System Table| OWGrub + UEFI -->|No BPI data in UEFI System Table| OWGrub + UEFI --> NWGrub -->|Direct call| NWEfiEntry +``` + +The diagram doesn't include detailed depiction of the new-world FDT flow as its actual logic is quite complex. You may refer to the source code for details. +However, in brief: the new world passes the FDT root pointer through a record in the UEFI system table with type `DEVICE_TREE_GUID` (`b1b621d5-f19c-41a5-830b-d9152c69aae0`) and value being the physical address of this pointer. +Therefore, whether booting with ACPI or FDT, new-world Linux follows the UEFI convention for parameter passing - achieving a remarkable unification! +In contrast, the old world lacks this unified nature. + +Under different firmware boot protocols, old-world Linux interprets the three firmware parameters differently: + +|Firmware Parameter|Old-World Boot Protocol Interpretation|New-World Boot Protocol Interpretation| +|-----|--------|--------| +|`fw_arg0`|`int argc`
Number of kernel command line arguments|`int efi_boot`
EFI boot flag, 0 means EFI runtime services unavailable, non-zero means available| +|`fw_arg1`|`const char *argv[]`
Virtual address of kernel command line argument list, used like C `main` function in user mode|`const char *argv`
Physical address of kernel command line as a single string| +|`fw_arg2`|`struct boot_params *efi_bp`
Virtual address of BPI table|`u64 efi_system_table`
Physical address of UEFI system table| + +Loongson's compatibility support for the new-world boot protocol in their old-world Linux fork was completed shortly before the 3A6000's release. This has been pushed to downstream commercial distributions like UOS and Kylin. + +As shown in the diagram, the code paths in the kernel are now essentially identical to the new world's: based on a flexible interpretation of the `fw_arg0` parameter - assuming that all "normal" kernel boots have more than one kernel command line parameter - the two boot protocols can be unambiguously distinguished in practice. + +In addition, Loongson also developed old-world boot protocol compatibility support for new-world Linux in 2023, and pushed it to community distributions with commercial backgrounds that needed to support machines without new-world firmware, such as openAnolis - see openAnolis's [related commit](https://gitee.com/anolis/cloud-kernel/commit/97a912cb723611c9ab706592621249354c9615a4). +(Note: This functionality has not yet been verified by third-party community members.) +This combination of boot protocols has not been reflected in the above description. + +### System Calls + +The ABI framework for system calls is consistent between OW and NW kernels. This includes: +- The method of making system calls (via the `syscall 0` instruction) +- System call numbers +- Register allocation for parameters and return values + +Most system call numbers are identical between the worlds, and the definitions of structures accepted by most system calls are also the same. This section covers the differences that cause NW incompatibility with OW system calls. + +#### Deprecated System Calls in the New World + +As LoongArch is the most recently introduced architecture in the Linux kernel, a decision was made to no longer provide certain older system calls that exist in OW. These system calls include: + +System Call Name | Number +------------|----- +`newfstatat` | 79 +`fstat` | 80 +`getrlimit` | 163 +`setrlimit` | 164 + +These compatibility issues can be resolved by directly implementing the deprecated system calls in the new-world kernel. + +#### Signal Number + +The `NSIG` macro (indicating the maximum allowed number of signals) is defined as 64 in the new world, while it's defined as 128 in the old world. This difference directly affects the size of `sigset_t` structures, which in turn impacts the size of `sigaction` structures. + +Additionally, several signal-related system calls require a `sigsetsize` parameter (indicating the length of the `sigset_t` structure) and expect this value to match the kernel's definition. Consequently, the following NW system calls cannot properly handle OW user mode calls: + +System Call Name | Number +------------|----- +`rt_sigsuspend` | 133 +`rt_sigaction` | 134 +`rt_sigprocmask` | 135 +`rt_sigpending` | 136 +`rt_sigtimedwait` | 137 +`pselect6` | 72 +`ppoll` | 73 +`signalfd4` | 74 +`epoll_pwait` | 22 +`epoll_pwait2` | 441 + +Among these system calls, `rt_sigprocmask`, `rt_sigpending`, and `rt_sigaction` involve writing to user mode `sigset_t` structures, while the others only read from them. + +To implement compatibility for these system calls, a straightforward approach would be to first override their definitions to accept 16 as the `sigsetsize` parameter. Additionally, since NW supports fewer signals than OW, system calls that read from user mode `sigset_t` structures can simply truncate the data to handle only the first 64 signals. For system calls that write to user mode `sigset_t` structures, if the user-provided `sigsetsize` parameter is 16, we clear the bits corresponding to the latter 64 signals in the sigset. Finally, for system calls that directly handle signal numbers, such as `sigaction` and `kill`, we can simply reject signal numbers greater than 64 from user mode. + +This approach means that when OW programs make system calls according to the OW ABI, their actual behavior will differ slightly from the original OW system calls. For example, if using `rt_sigprocmask` to first set a signal mask and then read it back, if the set value has any bits set for the latter 64 signals, the read value will differ from what was set. Furthermore, attempts to install signal handlers for the latter 64 signals or send these signals to processes will return errors. However, since OW programs rarely rely on these additional 64 custom signals, this simplified approach can successfully handle the vast majority of OW programs. + +#### User Mode Process Context + +When a process receives a signal, the kernel saves the process context to the user mode stack and passes it as the third parameter to the signal handler (regardless of whether the user requested context information when registering the signal handler). The kernel also sets the return address of the signal handler to a function that will call the `rt_sigreturn` system call (see the [`setup_rt_frame` function](https://elixir.bootlin.com/linux/v6.6/source/arch/loongarch/kernel/signal.c#L959)). + +When the signal handler returns, the program calls the `rt_sigreturn` system call. At this point, the kernel restores the previously saved context from the user mode stack to the process context (see the [`sys_rt_sigreturn` function](https://elixir.bootlin.com/linux/v6.6/source/arch/loongarch/kernel/signal.c#L926)). + +This mechanism allows user mode programs to modify the context within their signal handlers. When the signal handler returns, execution will continue from the location and context specified by these modifications, rather than returning to where the signal occurred. + +The OW and NW `ucontext` structures are significantly different, with member offsets that vary considerably. This makes it impossible to achieve compatibility through specially arranged data structures in-place. + +The memory layout of the `ucontext` structure in the old-world kernel is as follows: + +Offset | Member | Length | Notes +-------|------|-----|----- +0 | `uc_flags` | 8 +8 | `uc_link` | 8 +16 | `uc_stack` | 24 +40 | (padding) | 24 +64 | `uc_mcontext.sc_pc` | 8 +72 | `uc_mcontext.sc_regs[32]` | 32 × 8 | 32 general purpose registers +328 | `uc_mcontext.sc_flags` | 4 +332 | `uc_mcontext.sc_fcsr` | 4 +336 | `uc_mcontext.sc_none` | 4 +340 | (padding) | 4 +344 | `uc_mcontext.sc_fcc` | 8 +352 | `uc_mcontext.sc_scr[4]` | 4 × 8 | 4 LBT registers +384 | `uc_mcontext.sc_fpregs[32]` | 32 × 32 | 32 FP registers, 32-byte aligned +1408 | `uc_mcontext.sc_reserved[4]` | 4 | 16-byte aligned, first 4 bytes store LBT's `eflags` +1412 | `uc_mcontext.sc_reserved[4092]` | 4092 +5504 | `uc_sigmask` | 16 +5520 | `__unused` | 112 +5632 +The old world's `ucontext` structure is fixed-length at 5632 bytes and stores the process context at interruption. This includes fields for LBT extension registers and floating-point extension registers, regardless of whether the process uses these instructions. When floating-point instructions are used, depending on the instruction set (FPU, LSX, LASX), the floating-point registers are stored aligned to the lower bits in `uc_mcontext.sc_fpregs`. However, this structure cannot indicate whether the process uses floating-point extensions and/or LBT extensions, nor which floating-point instruction set is in use. When restoring context, the kernel decides which floating-point extension registers to restore based on the process's current state. + +The new world's `ucontext` structure data is more complex, divided into basic data and extension data. The basic data is stored in the `ucontext` structure with the following memory layout: + +Offset | Member | Length | Notes +-------|------|-----|----- +0 | `uc_flags` | 8 +8 | `uc_link` | 8 +16 | `uc_stack` | 24 +40 | `uc_sigmask` | 8 +48 | `unused` | 120 +168 | (padding) | 8 +176 | `uc_mcontext.sc_pc` | 8 +184 | `uc_mcontext.sc_regs[32]` | 32 × 8 | 32 general purpose registers +440 | `uc_mcontext.sc_flags` | 4 +444 | (padding) | 4 +448 | `uc_mcontext.sc_extcontext` | | 16-byte aligned + +The `uc_mcontext.sc_extcontext` field has a length of 0, being a [flexible array member](https://en.wikipedia.org/wiki/Flexible_array_member). Following the `ucontext` structure is a series of TLV (Type-Length-Value) extension data blocks that store context for extension instructions. The common header for extension data has the following memory layout: + +Offset | Member | Length | Notes +Offset | Member | Length | Notes +-------|------|-----|----- +0 | `magic` | 4 | Identifies the extension data type +4 | `size` | 4 +8 | `padding` | 8 +16 | | | 16-byte aligned + +Starting from an extension data header address, adding the length indicated by `size` gives the address of the next extension data block. The last extension data block has both `magic` and `size` fields set to 0, indicating the end of extension data. + +Currently, there are 4 defined extension data types, corresponding to context data for FPU, LSX, LASX, and LBT extension instruction sets. The NW kernel generates extension data blocks based on the process's current state. Among these, FPU, LSX, and LASX context data blocks are mutually exclusive - at most one can be present. + +For ordering, LBT extension context data (if present) is placed first, followed by either FPU, LSX, or LASX extension context data (if present), and finally the termination marker. + +The memory layout for each extension type is as follows: + +FPU extension instruction set, `magic` = `0x46505501` + +Offset | Member | Length | Notes +-------|------|-----|----- +0 | `regs[32]` | 32 × 8 | 32 FP registers +256 | `fcc` | 8 +264 | `fcsr` | 4 +268 | (padding) | 4 +272 + +LSX 扩展指令集，`magic` = `0x53580001` + +Offset | Member | Length | Notes +-------|------|-----|----- +0 | `regs[2*32]` | 32 × 16 | 32 FP registers +512 | `fcc` | 8 +520 | `fcsr` | 4 +524 | (padding) | 4 +528 + +LASX extension instruction set, `magic` = `0x41535801` + +Offset | Member | Length | Notes +-------|------|-----|----- +0 | `regs[4*32]` | 32 × 32 | 32 FP registers +1024 | `fcc` | 8 +1032 | `fcsr` | 4 +1036 | (padding) | 4 +1040 + +LBT 扩展指令集，`magic` = `0x42540001` + +Offset | Member | Length | Notes +-------|------|-----|----- +0 | `regs[4]` | 4 × 8 | 4 个 LBT 寄存器 +32 | `eflags` | 4 +36 | `ftop` | 4 +40 + +Comparing the `ucontext` data between OW and NW, we find that the layout of `uc_flags`, `uc_link`, and `uc_stack` fields is consistent, and both worlds pad `uc_sigmask` to 1024 bits (128 bytes). However, the order of `uc_mcontext` and `uc_sigmask` fields is reversed between OW and NW, and their `uc_mcontext` structures differ significantly. + +The NW implementation uses variable-length TLV (Type-Length-Value) extension data to store context for extended instruction sets, leaving room for future extensions. In contrast, the OW uses fixed-length structures, with 4096 reserved bytes for future extension contexts. Additionally, in the OW implementation, the LBT extension's `ftop` register isn't stored, and the `eflags` register occupies the first 4 bytes of the aforementioned reserved space. + +Kernel-level compatibility for `ucontext` data between OW and NW is infeasible because the kernel cannot determine which format the userspace program expects. Even if the kernel were modified to identify and mark processes based on their executable format, it still couldn't handle cases where a program dynamically links both OW and NW libraries, as it wouldn't know which format each signal handler expects. Therefore, compatibility must be implemented in user mode. + +Based on incomplete testing, Chromium and Electron-based applications' sandbox mechanism [verifies](https://chromium.googlesource.com/chromium/src/+/refs/tags/98.0.4758.141/sandbox/linux/seccomp-bpf/trap.cc#192) that the interrupt address recorded in the `ucontext` structure received by the `SIGSYS` signal handler matches the address in the `siginfo` structure, and actively uses the `ucontext` data. Consequently, old-world Electron-based applications require sandbox disabled to run properly when using only kernel-level compatibility with a complete old-world user mode directory tree. + +## User Mode + +As observed up to now (February 2024), the glibc version packaged in old-world systems is 2.28, while upstream glibc support for LoongArch started with version 2.36. At the time of writing, the latest glibc version is 2.39, though most new-world systems currently package glibc 2.37 or 2.38. Given glibc's excellent backward compatibility - programs running on older glibc versions generally work on newer versions without issues - this document focuses on comparing glibc 2.38 with the old-world ported glibc 2.28. Future new-world glibc versions will be compatible with version 2.38, so the conclusions in this document should remain applicable for newer glibc versions in new-world systems. + +### ELF File Format + +The ELF file format is identical between the old world and the new world, including the architecture field `e_machine` in the ELF header, which is set to 258 in both worlds. Most other structures are also consistent. The only difference lies in `bit[7:6]` of the `e_flags` field. OW binaries have these bits set to `0`, while NW binaries have them set to `1`[^b1]. When examining an ELF file's header information using `readelf --headers`, the presence of `OBJ-v1` in the `Flags:` section under `ELF Header:` indicates the file was compiled for the new world; conversely, `OBJ-v0` indicates compilation for the old world. + +This flag provides the most direct and reliable[^b2] method to determine whether an ELF file was compiled for OW or NW. However, as of mid-February 2024, neither world's runtime components (including the kernel's ELF loader and glibc's dynamic linker) reject loading ELF files based on this flag, nor do they behave differently because of it. + +[^b1]: In fact, this flag's true purpose is to indicate to the linker which version of relocation instruction semantics the object file (`.o`) contains. + These version-specific relocation instructions are not used in dynamic linking and thus don't appear in final linking products (`.so` and executables). + Therefore, while the flag's original meaning is irrelevant for shared libraries and executables, + it conveniently serves to distinguish between OW and NW programs and dynamic libraries. + +[^b2]: This flag was introduced in binutils 2.40 [via this commit](https://github.com/bminor/binutils-gdb/commit/c4a7e6b56218e1d5a858682186b542e2eae01a4a). + Consequently, NW programs and dynamic libraries generated by earlier binutils versions might lack the `OBJ-v1` flag. + Since binutils 2.40 was released in early 2023, when the NW LoongArch ecosystem hadn't yet developed a viable toolchain environment, + the number of such programs and libraries should be minimal. + +### Program Interpreter + +The Program Interpreter is a field in dynamically linked ELF executables that specifies the path to the required dynamic linker. When loading a dynamically linked ELF executable, the kernel loads the dynamic linker according to this field. The OW and NW have different program interpreter paths: + +* NW path: `/lib64/ld-linux-loongarch-lp64d.so.1` +* OW path: `/lib64/ld.so.1` + +This path is hardcoded into all dynamically linked executables. The difference in paths directly prevents old-world programs from running in the new world and vice versa. When attempting to execute a program from the other world, the error `No such file or directory` occurs because the corresponding program interpreter cannot be found. + +### Calling Convention + +The calling conventions between the old world and new world are identical in terms of parameter passing and return value handling. Generally, both worlds prioritize using registers for parameter passing, with additional parameters passed on the stack, and return values passed through registers. Furthermore, both worlds use the same register numbers for parameter and return value passing. + +Additionally, both worlds share identical sets of caller-saved and callee-saved registers. + +### User Mode Compatibility Overview + +The distinct ELF header markers and different program interpreter paths between the old world (OW) and new world (NW) make it possible to run OW programs in NW systems without requiring `chroot`. + +There are two technical approaches to achieve this: isolation-based and hybrid. In the isolation-based approach, OW executables call the OW `ld.so`, which modifies its search path to avoid NW dynamic library paths and only loads OW dynamic libraries. Meanwhile, NW executables use the original NW `ld.so` and naturally won't load OW libraries since they're stored in separate paths. This approach maintains a clear separation between OW and NW environments. + +For compatibility, the isolation-based approach must include a complete set of dynamic libraries required by OW programs. Framework-type libraries that search for plugin libraries in specific paths need recompilation to adjust their search locations. Other simple dynamic libraries can be ported directly from the OW. This may lead to significant storage overhead. Additionally, if a user's NW system has plugins installed but the OW compatibility layer doesn't provide OW versions of these plugins, certain functionality may be missing. The isolation approach has clear boundaries and doesn't require extensive glibc modifications. In fact, it only needs to implement context parameter (`ucontext`) translation in signal handlers, leaving other compatibility issues to the kernel. Furthermore, its correctness is easier to verify because the clear OW/NW separation ensures the OW glibc can correctly interpret data structures as OW versions without misinterpretation risks. + +The hybrid approach, conversely, leverages the identical calling conventions between OW and NW by providing a modified glibc. This glibc provides multiple symbol versions, allowing both OW programs and NW dynamic libraries to link with it simultaneously. This approach mixes OW and NW environments and doesn't require a complete set of OW dynamic libraries, instead utilizing NW libraries directly. This saves storage space and avoids completeness concerns regarding included libraries. However, the hybrid approach requires complex glibc modifications. Additionally, it may face challenges in correctly identifying whether data structures are NW or OW versions, potentially leading to misinterpretation issues. + +### glibc 符号版本 + +众所周知，glibc 具有相当良好的兼容性。这是通过符号版本（Symbol Versioning）来实现的。 +具体而言 glibc 中所有的符号都相应地被分配了一个符号引入时的版本号。如果一个符号的 ABI 发生了变化， +那么则会引入同名符号的新版本，而旧版本的符号则会被保留（实现可能会被替换为兼容的实现）。这个版本号是一个字符串， +在动态链接的过程中，只有版本号相同的符号才会被链接。这样，即使 glibc 的 ABI 发生了变化， +由于和旧版本 glibc 编译链接产生的可执行程序中的符号版本号是旧版本的，所以这个可执行程序在新版本 glibc 上运行时， +也会使用旧版本的符号，从而保证了兼容性。glibc 的符号名称和关联的版本定义，位于其各目录的 `Versions` 文件中。 +例如 [`io/Versions`](https://elixir.bootlin.com/glibc/glibc-2.38/source/io/Versions)。在下文中， +我们称在 `Versions` 文件中定义的符号版本号为“源码版本号”。从这个定义可知，一个符号的源码版本号是与架构无关的。 +与源码版本号相区别，在编译生成的二进制 glibc 库文件中定义的符号版本号，我们称之为“二进制版本号”。 +这个版本号会在编译链接其它可执行程序时被写入到可执行程序的符号表中，同时也是动态链接器在加载可执行程序时用来检查符号版本的版本号。 +在类似 i386 这样的架构上，一个符号的源码版本号和二进制版本号是一致的。但是，这并非对所有架构都成立。 + +我们可以注意到，很多符号都是在最早的 2.0 版本中就定义了的，但是并非所有架构都是从 2.0 版本开始支持的。 +例如 riscv64 即是在 2.27 版本中才开始支持的。那么对于 riscv64 架构， +是不可能存在与 2.26 或更早版本的 glibc 编译链接的程序的。这意味着，如果有符号在 2.0 至 2.26 版本之间改变了 ABI， +那么这个符号的旧版本就没有存在的必要了。glibc 对该问题的处理方式是，定义了每一个架构的“纪元版本号”， +即该架构引入时所在的 glibc 版本号。对于所有的符号，如果其源码版本号小于该架构的纪元版本号， +那么在该架构上编译出来的 glibc 中，二进制版本号将会被设置为纪元版本号；如果有多个小于纪元版本号的源码版本号， +则仅编译最新的那一个，并将其二进制版本号设置为纪元版本号。 + +例如：`setrlimit` 有两个源码版本，分别是 `GLIBC_2.0` 和 `GLIBC_2.2`，而 riscv64 的纪元版本号是 2.27， +那么在 riscv64 上编译出来的 glibc 中，`setrlimit` 的二进制版本号将会被设置为 `GLIBC_2.27`， +其实际内容是 `GLIBC_2.2` 版本的符号。假若未来 glibc 2.50 引入了一个新的 `setrlimit` 的源码版本 `GLIBC_2.50`， +那么在 riscv64 上编译出来的 glibc 中，`setrlimit` 将会存在两个二进制版本号，分别是 `GLIBC_2.27` 和 `GLIBC_2.50`。 + +新旧世界在符号版本方面存在差异的来源是，旧世界的龙架构的纪元版本号是 2.27[^a1]，而新世界的是 2.36。 +由于 glibc 中的大多数符号的源码版本号都是从 2.0 开始的，因此在旧世界中， +glibc 大多数符号的二进制版本号就是 `GLIBC_2.27`；而新世界中，相应地，大多数符号的二进制版本号是 `GLIBC_2.36`： +这样，即使通过修改二进制可执行程序，将其程序解释器强行修改为另一个世界的，也无法正常运行， +因为它期待要加载的 glibc 的符号版本在异世界中不存在。类似地，如果一个新世界的可执行程序试图加载（例如通过 `dlopen`）旧世界的（非 glibc 的）动态链接库， +也是无法正确加载的，因为该旧世界动态链接库依赖的 glibc 的符号版本在新世界中不存在。 + +[^a1]: 巧合的是，riscv64 的[纪元版本号](https://elixir.bootlin.com/glibc/glibc-2.38/source/sysdeps/unix/sysv/linux/riscv/shlib-versions#L2)也是 2.27 + +更为复杂的情况出现在 `libpthread` 中。旧世界的龙架构中，唯独 `libpthread` 的纪元版本号是 2.0， +即旧世界中 `libpthread` 和 `libc` 的纪元版本号不一致。glibc 中已知的全部 Linux 支持的架构中， +只有旧世界的龙架构存在这样的现象。这样做法的原因不得而知[^a2]，但是导致的后果是明确的。在 glibc 2.34 +之前，`libpthread` 和 `libc` 是分立的两个库。有部分符号，例如 `open`、`write` 等， +在两个库中都有定义，但是其包括的代码可能不同（通过宏定义在编译期产生区别）。 +一个多线程程序在执行时，其调用的 `open`、`write` 等符号，由 `libpthread` 覆盖了 `libc` 中的定义。 +在 glibc 2.34 以及此后的版本，`libpthread` 合并进了 `libc`， +于是 `libc` 中 `open`、`write` 等符号始终是多线程的版本。 +旧世界中 `libpthread` 和 `libc` 的纪元版本号不一致，造成了这样的 `open`、`write` +等符号在旧世界存在两个二进制版本号，分别是 `libpthread` 中的 `GLIBC_2.0` 和 `libc` 中的 `GLIBC_2.27`。 + +[^a2]: 但是可以注意到 MIPS 架构的[纪元版本号](https://elixir.bootlin.com/glibc/glibc-2.38/source/sysdeps/unix/sysv/linux/mips/shlib-versions#L25)是 2.0，并跳过了 2.1。事实上，旧世界的 `libpthread` 的纪元版本号也是 2.0，并同样跳过了 2.1。 + + +### glibc 库列表 + +动态链接的 ELF 文件（包括库和可执行程序）对于需要引入的带有版本号的符号，都会描述该符号所属的动态链接库的名称。 +但是 glibc 在执行动态链接时，会忽略实际提供对应版本符号的库的名称，这一行为在 glibc 2.30 被[引入](https://github.com/bminor/glibc/commit/f0b2132b35248c1f4a80f62a2c38cddcc802aa8c)。这为 glibc 后续将符号从其它库向 `libc` +中集中提供了便利。以 `libpthread` 中的 `pthread_join` 为例。在 glibc 2.34 以及之后的版本中， +该符号实际由 `libc` 提供，而 `libpthread` 变成了一个空白占位。对于和 glibc 2.34 以前版本链接的程序或其它库， +显然需要的是 `libpthread` 中的 `pthread_join`。在动态链接时，glibc 会正常查找到 `libc` +和 `libpthread` 库文件，从而满足了该程序和该库对所依赖的库的需求。当具体要查找 `pthread_join` 时， +glibc 的动态链接器则不考虑所要求的 `pthread_join` 的提供者，只要载入的所有库中定义有 `pthread_join` 的对应版本， +即可完成动态链接。 + +在此之后，且在新世界的纪元版本 2.36 前，又有一些库的符号被移动到了 `libc` 中，这些库文件在新世界就彻底不存在了。 +然而，对于旧世界的程序而言，这些库文件仍然是需要的，应该提供占位库文件。下表是新旧世界中， +所有对外供动态链接的库的列表。 + +库名 | 旧世界 | 新世界 | 备注 +-----|------|------|---- +`libBrokenLocale.so.1` | 存在 | 存在 +`libanl.so.1` | 存在 | 不存在 | 需要补充占位库 +`libc.so.6` | 存在 | 存在 +`libc_malloc_debug.so.0` | 不存在 | 存在 | 该库在 2.34 引入 +`libcrypt.so.1`| 存在 | 不存在 | 该库在新世界默认禁用 +`libdl.so.2` | 存在 | 存在（占位） +`libm.so.6` | 存在 | 存在 +`libnsl.so.1` | 存在 | 不存在 | 该库在新世界默认禁用 +`libpthread.so.0` | 存在 | 存在（占位） +`libresolv.so.2` | 存在 | 存在 +`librt.so.1` | 存在 | 存在（占位） +`libthread_db.so.1` | 存在 | 存在 +`libutil.so.1` | 存在 | 不存在 | 需要补充占位库 + +### 具体函数的行为区别 + +新旧世界 glibc 提供的函数的行为存在一些区别。这些区别是内核提供的用户态接口的不同导致的。 +本节将会讨论这些函数的行为区别。这里的“行为”主要指的是 glibc 对函数调用者呈现的行为。但是， +在特定的讨论中，我们也会涉及到其向内核发出系统调用的行为。 + +#### 信号相关 + +我们知道，新世界内核中，最大的信号编号是 64；而旧世界内核中，最大的信号编号是 128。 +这导致了内核接受的 `sigset_t` 数据的大小不同。然而，glibc 中定义的 `sigset_t` 结构体的大小是相同的， +总是能[容纳](https://elixir.bootlin.com/glibc/glibc-2.38/source/sysdeps/unix/sysv/linux/bits/types/__sigset_t.h) 1024 个信号。 +这意味着，新世界的 glibc 中的 `sigset_t` 数据的大小是 128 字节。因此，所有接受 `sigset_t` 结构体的 glibc 函数的 + ABI 是兼容的，不至于出现数据溢出的情况。所有读取 `sigset_t` 结构体的新世界函数，完全可以读取旧世界程序提供的 `sigset_t` 结构体，并正常工作。 +所有写入 `sigset_t` 结构体的新世界函数，也可以写入旧世界程序提供的 `sigset_t` 结构体。由于旧世界的程序会使用其中的前 128 个比特位（即 128 个信号）， +而写入 `sigset_t` 结构体的新世界函数仅会写入前 64 个比特位，所以需要补充清零随后的 64 个比特位，以保证旧世界的程序不会接收到未初始化的数据。 +此外，glibc 还提供了一些函数，用于修改 `sigset_t` 结构体或对其进行逻辑运算，这些函数仅会操作对应世界中可用的信号编号所对应的比特位， +因此对外呈现的行为有所不同。 + +下列函数属于 `sigset_t` 编辑修改类函数，其所能操作的信号编号的范围不同： + +- `sigorset` +- `sigandset` +- `sigisemptyset` +- `sigismember` +- `sigaddset` +- `sigfillset` +- `sigemptyset` +- `sigdelset` + +下列函数属于只读 `sigset_t` 的函数，新世界的该函数可以正常读取旧世界程序提供的 `sigset_t`： + +- `epoll_pwait2` +- `epoll_pwait` +- `ppoll` +- `__ppoll_chk` +- `pselect` +- `signalfd` +- `sigwaitinfo` +- `sigwait` +- `sigtimedwait` +- `__sigsuspend` +- `sigsuspend` + +下列函数要写入 `sigset_t`，如果新世界的该函数要写入旧世界提供的 `sigset_t`，还需要补充清零随后的 64 个比特位： + +- `sigpending` +- `pthread_sigmask` +- `sigprocmask` + +下列函数虽然读写了 `sigset_t`，但是完整拷贝了 `sigset_t` 结构体，故其行为与最大的信号编号无关： + +- `posix_spawnattr_getsigmask` +- `posix_spawnattr_getsigdefault` +- `posix_spawnattr_setsigmask` +- `posix_spawnattr_setsigdefault` + +#### `ucontext` 相关 + +`ucontext_t` 结构体出现在两种地方：一是在信号处理函数的第三个参数中[^1]；二是在 `getcontext`、`setcontext`、`makecontext`、`swapcontext` 函数中[^2]。 +对 glibc 的用户而言，在这两种地方的 `ucontext_t` 结构体应当能互操作[^3]。例如，一个信号处理函数在接受到信号时， +将此前用 `getcontext` 函数保存的 `ucontext_t` 结构体复制到其第三个参数所指位置，那么在该信号处理函数结束后， +程序流将会转向 `getcontext` 函数保存的那个上下文；如果这个信号处理函数又将收到的原始 `ucontext_t` 保存到其它位置， +然后在此后的某个时刻，对保存的 `ucontext_t` 调用 `setcontext` 函数，即可将程序流转回到发生信号中断的上下文。 +同时注意到，信号处理函数接受的 `ucontext_t` 结构体直接来自于内核，而 `*context` 函数是由 glibc 提供的， +所以就 `ucontext_t` 而言，glibc 提供的版本和内核提供的版本必须完全二进制兼容。这一点与其它的结构体不同， +其它的结构体，glibc 可以提供与内核不同的版本，只要 glibc 函数能正确将二者转换即可。例如，`sigaction` 结构体， +glibc 提供的版本和内核提供的版本是不一致的[^4]，需要 glibc 函数将二者转换。 + +[^1]: [`sigaction(2)`](https://man7.org/linux/man-pages/man2/sigaction.2.html) “The siginfo_t argument to a SA_SIGINFO handler” 一节 +[^2]: [`getcontext(3)`](https://man7.org/linux/man-pages/man3/getcontext.3.html) +[^3]: [`getcontext(3)`](https://man7.org/linux/man-pages/man3/getcontext.3.html) “The function setcontext() restores the user context” which “should have + been … received as the third argument to a signal handler” +[^4]: 对比 [`sigaction`](https://elixir.bootlin.com/glibc/glibc-2.38/source/sysdeps/unix/sysv/linux/bits/sigaction.h#L27) 和 + [`kernel_sigaction`](https://elixir.bootlin.com/glibc/glibc-2.38/source/sysdeps/unix/sysv/linux/kernel_sigaction.h#L9) + +截至 glibc 2.38 版本，新世界的 `*context` 函数仅能处理 `ucontext_t` 结构体中的通用（整数）寄存器部分，而不能处理浮点、向量扩展和 LBT 扩展部分。 +旧世界的 `*context` 函数能处理 `ucontext_t` 结构体中通用（整数）寄存器和浮点寄存器，但不能处理向量扩展和 LBT 扩展部分。 +此外，旧世界 glibc 提供的 `ucontext_t` 定义[^5]与旧世界内核[^6]的定义对比，可以发现前者缺少用于存放 LBT 扩展寄存器的 `uc_mcontext.sc_scr[4]` 字段， +致使后续用于存放浮点寄存器的 `uc_mcontext.sc_fpregs[32]` 字段的偏移量发生了变化。这意味着， +旧世界的 `*context` 函数在处理旧世界内核提供给信号处理函数的 `ucontext_t` 结构体时，无法正确处理浮点寄存器。 +综上所述，旧世界 glibc 也仅能正确处理 `ucontext_t` 结构体的通用（整数）寄存器部分。这样，在功能上， +恰好新旧世界达成了一致——都只能正确处理通用寄存器部分。 + +[^5]: 可以在 Loongnix 发行版的 `/usr/include/loongarch64-linux-gnu/sys/ucontext.h` 找到 +[^6]: 可以在 Loongnix 发行版的 `/usr/include/loongarch64-linux-gnu/bits/sigcontext.h` 找到 + +glibc 提供了两个函数，可以被用于注册信号处理函数，这两个函数分别是 `sigaction` 和 `signal`。 +其中，`signal` 函数是对 `sigaction` 函数的封装。这样，无论是如何注册的信号处理函数， +都会在第三个参数中接受到一个 `ucontext_t` 结构体指针。但是根据 glibc [文档](https://man7.org/linux/man-pages/man2/signal.2.html)， +`signal` 函数注册的信号处理函数只应该接受第一个参数。这意味着，如果 `signal` 函数注册的信号处理函数 +遵循了文档的要求，只接受第一个参数，那么它会忽略第三个参数，即 `ucontext_t` 结构体指针会被忽略。 +这意味着，`signal` 函数注册的信号处理函数，是新旧世界无关的，不需要针对这样的信号处理函数做任何兼容性处理。 +而 `sigaction` 函数注册的信号处理函数，是新旧世界相关的，需要额外的兼容性处理。一种可能的兼容性处理是， +当用户调用 `sigaction` 函数注册一个接受旧世界的 `ucontext_t` 结构体信号处理函数时，实际不注册这个函数， +而是注册一个包裹函数，这个包裹函数接受新世界的 `ucontext_t` 结构体，并在栈上相应构造一个旧世界的 `ucontext_t` 结构体， +然后调用用户提供的信号处理函数；在用户提供的信号处理函数返回后，将旧世界的 `ucontext_t` 结构体的内容拷贝回新世界的 `ucontext_t` 结构体中。 +需要注意的是，信号处理函数无法接受自定义的参数，这意味着原始用户提供的信号处理函数的地址必须以某种方式保存下来， +以便包裹函数调用它。而在实现这一点时要十分小心地处理锁和信号屏蔽，因为整个这个注册信号处理函数的过程不再是原子的。 + +无论如何处理，都不会改变新旧世界 `ucontext_t` 结构体完全不兼容的事实，也无法扭转旧世界 glibc +和旧世界内核 `ucontext_t` 结构体存在差异的现状，因此如果出现了新旧世界可执行程序和动态链接库的混合链接， +并且存在将 `ucontext_t` 结构体在新旧世界间传递的情况，始终无法保证正确识别 `ucontext_t` 结构体是新世界的还是旧世界的。 +不过幸运的是，这样的情况十分罕见。 + +下列函数涉及 `ucontext_t` 结构体，因此新旧世界的函数完全不二进制兼容： + +- `getcontext` +- `setcontext` +- `makecontext` +- `swapcontext` + +下列函数涉及注册能接收 `ucontext_t` 结构体的信号处理函数，因此需要额外的兼容性处理： + +- `sigaction` + +下列函数注册的信号处理函数会忽略 `ucontext_t` 结构体指针，因此无需特殊处理： + +- `signal` + +#### longjmp 相关 + +`setjmp`、`sigsetjmp`、`longjmp`、`siglongjmp` 函数是用于实现非局部跳转的函数。 +其中 `set*jmp` 函数会将当前的程序状态（可选地，包括当前的信号掩码，即 sigmask）保存到一个 `jmp_buf` 结构体中， +而 `*longjmp` 函数则将上述状态恢复。这些函数的行为与 `*context` 函数类似。在新旧世界中， +`jmp_buf` 结构体的定义完全一致，因此这些 `*jmp` 函数是完全二进制兼容的。 + +下列函数涉及 `jmp_buf` 结构体，在新旧世界间完全兼容： + +- `setjmp` +- `sigsetjmp` +- `longjmp` +- `siglongjmp` + +#### `fstat` 相关 + +新世界的内核中，缺少 `fstat` 和 `newfstatat` 系统调用。这两个系统调用可以被用于获取文件的元数据。 +其中，`fstat` 可以获取一个打开的文件描述符（file descriptor, fd）所对应的文件的元数据； +而 `newfstatat` 则既可以获取一个打开的文件描述符所对应的文件的元数据，也可以获取一个路径所对应的文件的元数据。 +在操作对象上，`statx` 与 `newfstatat` 是一致的，但是可以按需返回更多的信息。因此，在功能上， +`statx` 是 `fstat` 和 `newfstatat` 的超集，并取代了这两个系统调用。 + +在 2.38 的 glibc 中，所有 `*stat*` 函数会在编译期通过宏指令检查内核是否提供了 `fstat` 或 `newfstatat` 的定义， +如果没有，那么这些函数会调用 `statx`[^7] 并负责转换数据结构。这意味着，与旧世界相比，这些 `*stat*` 函数对外呈现的行为是不变的， +新旧世界的函数是二进制兼容的。本节会着重讨论其向内核发出系统调用的行为区别。 + +[^7]: 这些函数最终会调用 [__fstatat64_time64](https://elixir.bootlin.com/glibc/glibc-2.38/source/sysdeps/unix/sysv/linux/fstatat64.c#L157) + +对于旧世界上基于 Chromium 的浏览器和基于 Electron 的应用程序而言，Chromium 基于 seccomp 的沙箱机制会针对 `statx` +[返回](https://chromium.googlesource.com/chromium/src/sandbox/+/7462a4fd179376882292be2381a22df6819041c7%5E%21) +`ENOSYS` 错误，期待沙箱内的进程自行回落至 `fstat` 或 `newfstatat`。 +这是因为，seccomp [无法审查](https://lwn.net/Articles/799557/)系统调用的指针参数背后的内容。 +而 Chromium 的一种沙箱规则则要求程序只能操作已经打开的 fd，而不能访问任何系统路径， +因此只能放行（在新世界龙架构内核中不存在的）`fstat` ，并通过 `SIGSYS` 的钩子[检查](https://chromium.googlesource.com/chromium/src/sandbox/+/b3267c8b40b6133b2db5475caed8f6722837a95e%5E%21/#F2) `newfstatat` 并将其重写为 `fstat`。 + +为了能让这部分程序正常运行，需要调整上述函数的行为，当 `statx` 返回 `ENOSYS` 时， +改为使用 `fstat` 或 `newfstatat`；同时，需要在新世界的内核中补充 `fstat` 和 `newfstatat` 的实现。 + +glibc 中下列导出函数涉及 `fstat` 和 `newfstatat`，为兼容目前尚未适配 `statx` 的 Chromium 的沙箱机制，需要额外的兼容性处理： + +- `stat` +- `fstat` +- `lstat` +- `fstatat` + +被上述函数引用，实际进行系统调用的 glibc 内部函数有： + +- `__fstatat64_time64` + +此外，还有为 2.33 之前版本的 glibc 提供的兼容符号所指向的函数也涉及该问题： + +- `___fxstat64` +- `__fxstatat64` +- `___lxstat64` +- `___xstat64` + +#### 杂项 + +新世界系统中同时提供 `clone3` 和 `clone`，而旧世界系统中仅提供 `clone`。 +新世界的 glibc 会在编译期检查内核是否提供了 `clone3`，如果提供了， +那么 `fork` 和 `pthread_create` 等函数会调用 `clone3`。 +在运行时，如果 `clone3` 返回 `ENOSYS`， +则[回落](https://elixir.bootlin.com/glibc/glibc-2.38/source/sysdeps/unix/sysv/linux/clone-internal.c#L109)到 `clone`。 +该行为不会影响新旧世界函数的二进制兼容性。但是，`clone3` 的参数都通过内存中的结构体传递；因此出于上一节提到的原因，Chromium 的 seccomp 沙箱机制也无法审查 `clone3` 的参数， +因此对 `clone3` 一律[返回](https://chromium.googlesource.com/chromium/src/sandbox/+/482404adee4fc0487452c7ae5ac9c192b0f4fd30%5E%21) `ENOSYS` 错误， +期待 glibc 回落使用 `clone` 系统调用。 +该机制使得在 `clone3` 方面，新世界的 glibc 库函数可以兼容旧世界的 Chromium 沙箱。 +然而，个别基于 Electron 的旧世界应用，由于打包的 Chromium 版本较旧，其沙箱机制不支持针对 +`clone3` 返回 `ENOSYS`，而是返回其它的错误，致使 glibc 无法回落使用 `clone`，造成程序无法运行。 + +为了避免这一问题，如果要实现新旧世界混合链接，需要禁用 `clone3` 的支持，直接调用 `clone`。 + +此外，旧世界的 glibc 对外导出了 `___brk_addr` 符号，而新世界没有导出。