为什么我的 SWI 指令挂起?(BeagleBone Black, ARM Cortex-A8 cpu) [英] Why does my SWI instruction hang? (BeagleBone Black, ARM Cortex-A8 cpu)

问题描述

我开始为使用 ARM 的 BeagleBone Black 编写玩具操作系统基于 Cortex-A8 的 TI Sitara AM3359 SoC 和 U-Boot 引导加载程序.我有一个简单的独立 hello world 应用程序写入 UART0，到目前为止我可以通过 U-Boot 加载，现在我正在尝试继续中断处理程序，但我无法让 SWI 做任何事情，只能挂起设备.

I'm starting to write a toy OS for the BeagleBone Black, which uses an ARM Cortex-A8-based TI Sitara AM3359 SoC and the U-Boot bootloader. I've got a simple standalone hello world app writing to UART0 that I can load through U-Boot so far, and now I'm trying to move on to interrupt handlers, but I can't get SWI to do anything but hang the device.

根据 AM335x TRM(从第 4099 页开始，如果您感兴趣的话)，中断向量表被映射到 ROM 中的 0x20000.ROM SWI 处理程序分支到 0x4030ce08 处的 RAM，后者分支到存储在 0x4030ce28 处的地址.(最初，这是 0x20084 处的唯一死循环.)

According to the AM335x TRM (starting on page 4099, if you're interested), the interrupt vector table is mapped in ROM at 0x20000. The ROM SWI handler branches to RAM at 0x4030ce08, which branches to the address stored at 0x4030ce28. (Initially, this is a unique dead loop at 0x20084.)

我的代码将所有 ARM 处理器模式的 SP 设置到它们自己位于 RAM 顶部的区域，并在 CPSR 中启用中断，然后执行始终挂起的 SWI 指令.(也许跳到一些死循环指令?)我看过一堆示例，并阅读了我能找到的任何文档，但我没有看到我遗漏了什么.

My code sets up all the ARM processor modes' SP to their own areas at the top of RAM, and enables interrupts in the CPSR, then executes an SWI instruction, which always hangs. (Perhaps jumping to some dead-loop instruction?) I've looked at a bunch of samples, and read whatever documentation I could find, and I don't see what I'm missing.

目前我与电路板的唯一交互是通过 UART0 与我的 linux 机器的串行连接.U-Boot 初始化 UART0，并允许通过串行连接加载二进制文件.

Currently my only interaction with the board is over serial connection on UART0 with my linux box. U-Boot initializes UART0, and allows loading of the binary over the serial connection.

这是相关的程序集:

.arm
.section ".text.boot"

.equ usr_mode,          0x10
.equ fiq_mode,          0x11
.equ irq_mode,          0x12
.equ svc_mode,          0x13
.equ abt_mode,          0x17
.equ und_mode,          0x1b
.equ sys_mode,          0x1f

.equ swi_vector,        0x4030ce28

.equ rom_swi_b_addr,    0x20008
.equ rom_swi_addr,      0x20028
.equ ram_swi_b_addr,    0x4030CE08
.equ ram_swi_addr,      0x4030CE28

.macro setup_mode mode, stackpointer
    mrs r0, cpsr
    mov r1, r0
    and r1, r1, #0x1f
    bic r0, r0, #0x1f
    orr r0, r0, #\mode
    msr cpsr_csfx, r0
    ldr sp, =\stackpointer
    bic r0, r0, #0x1f
    orr r0, r0, r1
    msr cpsr_csfx, r0
.endm

.macro disable_interrupts
    mrs r0, cpsr
    orr r0, r0, #0x80
    msr cpsr_c, r0
.endm

.macro enable_interrupts
    mrs r0, cpsr
    bic r0, r0, #0x80
    msr cpsr_c, r0
.endm

.global _start
_start:
    // Initial SP
    ldr r3, =_C_STACK_TOP
    mov sp, r3

    // Set up all the modes' stacks
    setup_mode fiq_mode, _FIQ_STACK_TOP
    setup_mode irq_mode, _IRQ_STACK_TOP
    setup_mode svc_mode, _SVC_STACK_TOP
    setup_mode abt_mode, _ABT_STACK_TOP
    setup_mode und_mode, _UND_STACK_TOP
    setup_mode sys_mode, _C_STACK_TOP

    // Clear out BSS
    ldr r0, =_bss_start
    ldr r1, =_bss_end
    mov r5, #0
    mov r6, #0
    mov r7, #0
    mov r8, #0

    b _clear_bss_check$

_clear_bss$:
    stmia r0!, {r5-r8}

_clear_bss_check$:
    cmp r0, r1
    blo _clear_bss$

    // Load our SWI handler's address into
    // the vector table
    ldr r0, =_swi_handler
    ldr r1, =swi_vector
    str r0, [r1]

    // Debug-print out these SWI addresses
    ldr r0, =rom_swi_b_addr
    bl print_mem

    ldr r0, =rom_swi_addr
    bl print_mem

    ldr r0, =ram_swi_b_addr
    bl print_mem

    ldr r0, =ram_swi_addr
    bl print_mem

    enable_interrupts

swi_call$:
    swi #0xCC
    bl kernel_main
    b _reset


.global _swi_handler
_swi_handler:
    // Get the SWI parameter into r0
    ldr r0, [lr, #-4]
    bic r0, r0, #0xff000000

    // Save lr onto the stack
    stmfd sp!, {lr}
    bl print_uint32
    ldmfd sp!, {pc}

那些调试打印产生预期值:

Those debugging prints produce the expected values:

00020008: e59ff018
00020028: 4030ce08
4030ce08: e59ff018
4030ce28: 80200164

(根据objdump，0x80200164确实是_swi_handler.0xe59ff018是指令ldr pc, [pc, #0x20]".)

(According to objdump, 0x80200164 is indeed _swi_handler. 0xe59ff018 is the instruction "ldr pc, [pc, #0x20]".)

我错过了什么?似乎这样应该可行.

What am I missing? It seems like this should work.

推荐答案

板载固件改变 ARM 执行模式和位置与各种模式相关的向量表.在我自己的情况下(裸机在权限级别 1 执行并由 BBB 的 uBoot 启动的代码片段)活动向量表位于地址 0x9f74b000.

The firmware on the board changes the ARM execution mode and the locations of the vector tables associated with the various modes. In my own case (a bare-metal snippet code executed at Privilege Level 1 and launched by BBB's uBoot) the active vector table is at address 0x9f74b000.

一般来说，您可能会使用类似以下函数来定位活动向量表:

In general, you might use something like the following function to locate the active vector table:

static inline unsigned int *get_vectors_address(void)
{
    unsigned int v;

    /* read SCTLR */
    __asm__ __volatile__("mrc p15, 0, %0, c1, c0, 0\n"
            : "=r" (v) : : );
    if (v & (1<<13))
        return (unsigned int *) 0xffff0000;
    /* read VBAR */
    __asm__ __volatile__("mrc p15, 0, %0, c12, c0, 0\n"
            : "=r" (v) : : );
    return (unsigned int *) v;
}

这篇关于为什么我的 SWI 指令挂起?(BeagleBone Black, ARM Cortex-A8 cpu)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！