diff options
Diffstat (limited to 'Documentation/arch/arm')
| -rw-r--r-- | Documentation/arch/arm/index.rst | 2 | ||||
| -rw-r--r-- | Documentation/arch/arm/kernel_mode_neon.rst | 4 | ||||
| -rw-r--r-- | Documentation/arch/arm/omap/dss.rst | 2 | ||||
| -rwxr-xr-x | Documentation/arch/arm/samsung/clksrc-change-registers.awk | 2 | ||||
| -rw-r--r-- | Documentation/arch/arm/vlocks.rst | 4 | ||||
| -rw-r--r-- | Documentation/arch/arm/zte/index.rst | 10 | ||||
| -rw-r--r-- | Documentation/arch/arm/zte/zx297520v3.rst | 166 |
7 files changed, 185 insertions, 5 deletions
diff --git a/Documentation/arch/arm/index.rst b/Documentation/arch/arm/index.rst index afe17db294c4..b15621093f7a 100644 --- a/Documentation/arch/arm/index.rst +++ b/Documentation/arch/arm/index.rst @@ -75,3 +75,5 @@ SoC-specific documents sti/overview vfp/release-notes + + zte/index diff --git a/Documentation/arch/arm/kernel_mode_neon.rst b/Documentation/arch/arm/kernel_mode_neon.rst index 9bfb71a2a9b9..1efb6d35b7bd 100644 --- a/Documentation/arch/arm/kernel_mode_neon.rst +++ b/Documentation/arch/arm/kernel_mode_neon.rst @@ -121,4 +121,6 @@ observe the following in addition to the rules above: * Compile the unit containing the NEON intrinsics with '-ffreestanding' so GCC uses its builtin version of <stdint.h> (this is a C99 header which the kernel does not supply); -* Include <arm_neon.h> last, or at least after <linux/types.h> +* Do not include <arm_neon.h> directly: instead, include <asm/neon-intrinsics.h>, + which tweaks some macro definitions so that system headers can be included + safely. diff --git a/Documentation/arch/arm/omap/dss.rst b/Documentation/arch/arm/omap/dss.rst index a40c4d9c717a..9d39679235a3 100644 --- a/Documentation/arch/arm/omap/dss.rst +++ b/Documentation/arch/arm/omap/dss.rst @@ -314,7 +314,7 @@ Kernel boot arguments omapfb.mode=<display>:<mode>[,...] - Default video mode for specified displays. For example, - "dvi:800x400MR-24@60". See drivers/video/modedb.c. + "dvi:800x400MR-24@60". See drivers/video/fbdev/core/modedb.c. There are also two special modes: "pal" and "ntsc" that can be used to tv out. diff --git a/Documentation/arch/arm/samsung/clksrc-change-registers.awk b/Documentation/arch/arm/samsung/clksrc-change-registers.awk index 7be1b8aa7cd9..48464397088c 100755 --- a/Documentation/arch/arm/samsung/clksrc-change-registers.awk +++ b/Documentation/arch/arm/samsung/clksrc-change-registers.awk @@ -163,4 +163,4 @@ BEGIN { } } -// && ! /clksrc_clk.*=.*{/ { print $0 } +// && ! /clksrc_clk.*=.*{/ { print $0 }} diff --git a/Documentation/arch/arm/vlocks.rst b/Documentation/arch/arm/vlocks.rst index 737aa8661a21..b0ac33263086 100644 --- a/Documentation/arch/arm/vlocks.rst +++ b/Documentation/arch/arm/vlocks.rst @@ -102,10 +102,10 @@ Features and limitations if (I_won) { /* we won the town election, let's go for the state */ my_state = states[(this_cpu >> 8) & 0xf]; - I_won = vlock_lock(my_state, this_cpu & 0xf)); + I_won = vlock_lock(my_state, this_cpu & 0xf); if (I_won) { /* and so on */ - I_won = vlock_lock(the_whole_country, this_cpu & 0xf]; + I_won = vlock_lock(the_whole_country, this_cpu & 0xf); if (I_won) { /* ... */ } diff --git a/Documentation/arch/arm/zte/index.rst b/Documentation/arch/arm/zte/index.rst new file mode 100644 index 000000000000..0ed80b60b746 --- /dev/null +++ b/Documentation/arch/arm/zte/index.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +======= +ZTE SoC +======= + +.. toctree:: + :maxdepth: 1 + + zx297520v3 diff --git a/Documentation/arch/arm/zte/zx297520v3.rst b/Documentation/arch/arm/zte/zx297520v3.rst new file mode 100644 index 000000000000..d33f454bc895 --- /dev/null +++ b/Documentation/arch/arm/zte/zx297520v3.rst @@ -0,0 +1,166 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +==================================== +Booting Linux on ZTE zx297520v3 SoCs +==================================== + +Author: Stefan Dösinger + +Date : 27 Jan 2026 + +1. Hardware description +--------------------------- +Zx297520v3 SoCs use a 64-bit capable Cortex-A53 CPU and GICv3, although they +run in arm32 mode only. The CPU has support EL3, but no hypervisor (EL2) and +it seems to lack VFP and NEON. + +The SoC is used in a number of cheap LTE to WiFi routers, both battery powered +MiFis and stationary CPEs. In addition to the CPU these devices usually have +64 MB Ram (although some is shared with the LTE chip), 128 MB NAND flash, an +SDIO connected RTL8192-type Wifi chip limited to 2.4 ghz operation, USB 2, +and buttons. Devices with as low as 32 MB or as high as 128 MB ram exist, as +do devices with 8 or 16 MB of NOR flash. + +Some devices, especially the stationary ones, have 100 mbit Ethernet and an +Ethernet switch. + +Usually the devices have LEDs for status indication, although some have SPI or +I2C connected displays. + +Some have an SD card slot. If it exists, it is a better choice for the root +file system because it easily outperforms the built-in NAND. + +The LTE interface runs on a separate DSP called ZSP880. It is probably derived +from LSI ZSPs and has an undocumented instruction set. The ZSP communicates +with the main CPU via SRAM and DRAM and a mailbox hardware that can generate +IRQs on either ends. + +There is also a Cortex M0 CPU, which is responsible for early HW initialization +and starting the Cortex A53 CPU. It does not have any essential purpose once +U-Boot is started. An SRAM-based handover protocol exists to run custom code on +this CPU. + +2. Booting via USB +--------------------------- + +The Boot ROM has support for booting custom code via USB. This mode can be +entered by connecting a Boot PIN to GND or by modifying the third byte on NAND +(set it to anything other than 0x5A aka 'Z'). A free software tool to start +custom U-Boot and kernels can be found here: + +https://github.com/zx297520v3-mainline/zx297520v3-loader + +If USB download mode is entered but no boot commands are sent through USB, the +device will proceed to boot normally after a few seconds. It is therefore +possible to enable USB boot permanently and still leave the default boot files +in place. + +https://github.com/zx297520v3-mainline/u-boot-mainline + +Contains an U-Boot version that can be used with the USB loader and sets up the +CPU and interrupt controller to comply with Linux's booting requirements. + +3. Building for built-in U-Boot +------------------------------- +The devices come with an ancient U-Boot that loads legacy uImages from NAND and +boots them without a chance for the user to interrupt. The images are stored in +files ap_cpuap.bin and ap_recovery.bin on a jffs2 partition named imagefs, +usually mtd4. A file named "fotaflag" switches between the two modes. + +In addition to the uImage header, those files have a 384-byte signature header, +which is used for authenticating the images on some devices. Most devices have +this authentication disabled and it is enough to pad the uImage files with 384 +zero bytes. + +Builtin U-Boot also poorly sets up the CPU. Read the next section for details +on this. It has no support for loading DTBs, so CONFIG_ARM_APPENDED_DTB is +needed. + +So to build an image that boots from NAND the following steps are necessary: + +1) Patch the assembly code from section 3 into arch/arm/kernel/head.S. +2) make zx29_defconfig +3) make [-j x] +4) cat arch/arm/boot/zImage arch/arm/boot/dts/zte/[device].dtb > kernel+dtb +5) mkimage -A arm -O linux -T kernel -C none -a 0x20008000 -d kernel+dtb uimg +6) dd if=/dev/zero bs=1 count=384 of=ap_recovery.bin +7) cat uimg >> ap_recovery.bin +8) Place this file onto imagefs on the device. Delete ap_cpuap.bin if the + free space is not enough. +9) Create the file fotaflag: echo -n FOTA-RECOVERY > fotaflag + +For development, booting ap_recovery.bin is recommended because the normal boot +mode arms the watchdog before starting the kernel. + +4. CPU and GIC Setup +--------------------------- + +Generally CPU and GICv3 need to be set up according to the requirements spelled +out in Documentation/arch/arm64/booting.rst. For zx297520v3 this means: + +1. GICD_CTLR.DS=1 to disable GIC security +2. Enable access to ICC_SRE +3. Disable trapping IRQs into monitor mode +4. Configure EL2 and below to run in insecure mode. +5. Configure timer PPIs to active-low. + +The kernel sources provided by ZTE do not boot either (interrupts do not work +at all). They are incomplete in other aspects too, so it is assumed that there +is some workaround similar to the one described in this document somewhere in +the binary blobs. + +The assembly code below is given as an example of how to achieve this: + +:: + + #include <linux/irqchip/arm-gic-v3.h> + #include <asm/assembler.h> + #include <asm/cp15.h> + + @ Detect sane bootloaders and skip the hack + ldr r3, =0xf2000000 + ldr r3, [r3] + ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS) + cmp r3, r4 + beq skip_zx_hack + @ This allows EL1 to handle ints hat are normally handled by EL2/3. + ldr r3, =0xf2000000 + str r4, [r3] + + cps #MON_MODE + + @ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART + @ seems to respond only to non-secure addresses. I have taken insipiration from + @ Raspberry pi's armstub7.S here. + mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable + @ Allow hypervisor call. + mcr p15, 0, r3, c1, c1, 0 + + @ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low. + ldr r3, =0xF22020a8 + ldr r4, =0x50 + str r4, [r3] + ldr r3, =0xF22020ac + ldr r4, =0x14 + str r4, [r3] + + @ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg + @ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3. + mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3 + orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values? + mcr p15, 6, r3, c12, c12, 5 + mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1 + orr r3, #(ICC_SRE_EL1_SRE) + mcr p15, 0, r3, c12, c12, 5 + + @ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access + @ for EL2. + mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE + orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE) + mcr p15, 4, r3, c12, c9, 5 + isb + + @ Back to SVC mode + cps #SVC_MODE + skip_zx_hack: + |