Skip to content

Conversation

SiyuanSun0736
Copy link

By adding the ARCH variable to some rules in the makefile, enabling support for other architectures in the makefiles under the payload directory, and converting some RISC-V64 assembly code into AArch64 assembly, successful AArch support for the payload part was achieved. Additionally, modifications were made to the axhal part by referencing oscomp/arceos to enable uspace support under AArch64. A section of pflash was added to arch64-qemu-virt.toml. Together, these changes accomplished support for tour/u_*_0and tour/m_*_0.

Example:
Compiling for AArch64:

make  
make ARCH=aarch64  
rm -f pflash.img  
rm -f disk.img  
make pflash_img ARCH=aarch64  
make disk_img ARCH=aarch64  
make payload ARCH=aarch64  
./update_disk.sh ./payload/hello_c/hello  
make run A=tour/m_3_0 ARCH=aarch64 LOG=debug BLK=y  

Compiling for RISC-V64:

make  
rm -f pflash.img  
rm -f disk.img  
make pflash_img  
make disk_img  
make payload  
./update_disk.sh ./payload/hello_c/hello  
make run A=tour/m_3_0 LOG=debug BLK=y  

…加架构支持选项;在 main.rs 中为不同架构的用户任务启动添加条件编译支持
* upstream/main:
  use new tour_test.sh( created by @yjymosheng ) for CI.
  tour/u_* apps in CI
  add github ci for tour
  add tour test script
  Update tour-README.md
  Update tour-README.md
  update rust-toolchain to 2024-09-04 for fix crate home@0.5.11 compiling problem
  update README for oscamp quick start guide
  update arceos/modules/bump_allocator/src/lib.rs for rust analyzer
  update arceos/Cargo.toml: add axfs_ramfs
  add vscode settings.json: "rust-analyzer.cargo.target": "riscv64gc-unknown-none-elf"
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR extends support to AArch64 by parameterizing architecture in Makefiles, updating payload assembly, and adding AArch64-specific handlers in axhal.

  • Introduces ARCH variable and multi-arch support in payload Makefiles
  • Updates _start assembly in main.rs for AArch64 syscall entry
  • Adds AArch64 task-pointer caching and trap handling in axhal

Reviewed Changes

Copilot reviewed 32 out of 32 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
arceos/payload/origin/src/main.rs Added AArch64 _start assembly block
arceos/payload/origin/Makefile Parameterized ARCH, TARGET_TRIPLE, clean loop
arceos/payload/mapfile_c/Makefile Added ARCH branching for compiler toolchains
arceos/payload/hello_c/Makefile Added ARCH branching for compiler toolchains
arceos/payload/fileops_c/Makefile Added ARCH branching for compiler toolchains
arceos/payload/Makefile Passed ARCH down into subdirectories
arceos/modules/axhal/src/cpu.rs Introduced cache_current_task_ptr for AArch64
arceos/modules/axhal/src/arch/aarch64/* Updated trap.S, trap.rs, mod.rs, context.rs to integrate AArch64 uspace and caching
arceos/modules/*/Cargo.toml Added new dependencies (log)
arceos/Makefile Propagated ARCH to payload, updated GDB breakpoint
arceos/Cargo.toml Added new workspace examples
Comments suppressed due to low confidence (1)

arceos/payload/origin/Makefile:35

  • This recipe calls an undefined get-target-triple target. It will fail at clean time. Consider using the already-computed TARGET_TRIPLE variable or implement a Makefile function that maps ARCH to the correct triple.
        cargo clean -p $(TARGET) --target $$(make --no-print-directory ARCH=$$arch get-target-triple) --release 2>/dev/null || true; \

#[cfg(target_arch = "aarch64")]
core::arch::asm!(
"sub sp, sp, #4", // AArch64 栈操作
"mov sp, x0", // 设置返回值为 0
Copy link
Preview

Copilot AI May 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The assembly line mov sp, x0 incorrectly moves the stack pointer instead of setting the return value. It should be mov x0, #0 (or mov x0, xzr) to zero the return register before the svc instruction.

Suggested change
"mov sp, x0", // 设置返回值为 0
"mov x0, #0", // 设置返回值为 0

Copilot uses AI. Check for mistakes.

@shilei-massclouds
Copy link
Collaborator

There're some unhandled exceptions or compile-errors:

  1. u_4_0:
    image

  2. m_3_0:
    image

  3. m_3_1: This hasn't been finished??
    image

Suggest to fix these problems.
Or provide a checklist in this PR to declare finished and unfinished items.

Copy link
Collaborator

@shilei-massclouds shilei-massclouds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix exceptions in u_4_0, m_3_0, m_3_1 or provide a checklist of finished items.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For ‘mk_pflash’, how about to define a function with args to handle all these three archs?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pflash_img code is located in the oscamp/arceos/scripts/make/utils.mk file, which defines a macro called mk_pflash .
This macro builds a Rust project origin for different target architectures (such as RISC-V 64-bit or AArch64) and packages it into a specific "pflash" image file, depending on the ARCH parameter passed in (for example, from oscamp/arceos/Makefile ).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You copied the implementation of 'mk_pflash' for riscv64 to other two archs, so there're three copies of 'mk_pflash' with minor differences (related to arch). We can try to just define a single 'mk_pflash' function and pass in 'arch' argument.
An exmaple is 'make_disk_image' function in 'utils.mk'.

@SiyuanSun0736
Copy link
Author

The modifications for u_4_0 and m_3_1 have been submitted, but the EC 0b000000 error did not occur on my computer. I've also added handling for 0b000000, though I'm not sure if it will resolve the issue.

My environment is UBUNTU 22.04, with aarch64-linux-musl-gcc version 11.2.1, LLVM and Clang version 14.0.0, and QEMU version 9.2.1. May I ask what your build versions are?
image

@shilei-massclouds
Copy link
Collaborator

There're still exceptions,

For m_3_0:
image

For m_3_1:
image

Also for m_1_1:
image

My Environment:
Ubuntu 22.04.2 LTS
aarch64-linux-musl: 11.2.1
llvm and clang: 14.0.0
QEMU emulator version 9.2.0

@SiyuanSun0736
Copy link
Author

Dear Professor,
I have submitted modifications for:

  1. The mk_pflash rule's parameter usage.
  2. m_1_1.
  3. The Dockerfile.
    Instructions for using the Dockerfile have been written into arceos/README.md.

Thank you for your hard work.

@SiyuanSun0736
Copy link
Author

The following modifications have been submitted:

  1. CI updates
  2. README revisions
  3. utils.mk adjustments
  4. Payload changes
    All tests were successful

@shilei-massclouds shilei-massclouds self-requested a review May 26, 2025 13:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants