Skip to content

Conversation

@elliott10
Copy link

Support RK3588 opi5plus board

  • Added RK3588 opi5plus board platform crate

  • How to: make rk3588

  • Build and generate a U-Boot bootable image
    make ARCH=aarch64 APP_FEATURES=rk3588 MYPLAT=axplat-aarch64-rk3588 BUS=mmio SMP=8 UIMAGE=y LOG=info build
    Form an independent crate to support hardware platform, please see axplat-aarch64-rk3588

  • Updated serial device UART driver and dynamic adjustment of baud rate is supported
    Please see: dw-apb-uart

@AsakuraMizu
Copy link
Contributor

I'd like to know if this is support for generic RK3588 platforms, or if it's only support for opi5p?

@elliott10
Copy link
Author

elliott10 commented Dec 17, 2025

if this is support for generic RK3588 platforms

Yes, It works for generic RK3588 platforms.

I tried to bootstrap this StarryOS on 3 hardware boards, except for configuring the serial device baud rate, all RK3588 boards work well.
Uart baud rate:

  • opi5plus RK3588 -- 1500000
  • ROC-RK3588s-PC -- 1500000
  • aio-3588jd4 -- 115200

Please refer to the following figures:

Screenshot from 2025-12-17 16-12-10 Screenshot from 2025-12-17 15-49-30 Screenshot from 2025-12-17 15-56-14

@AsakuraMizu
Copy link
Contributor

For maintainability reasons, I suggest moving this repository to @arceos-org or @Starry-OS. I also see a dw_apb_uart patch; I think it would be good if that could be resolved.

@elliott10
Copy link
Author

elliott10 commented Dec 23, 2025

I suggest moving this repository to @arceos-org or @Starry-OS. I also see a dw_apb_uart patch

Considering the future updates of dependent crates, I would rather keep dependent crates in the author's repository.
In this way, the crate author can conveniently update functions over a long time.

@AsakuraMizu
Copy link
Contributor

Considering the future updates of dependent crates, I would rather keep dependent crates in the author's repository. In this way, the crate author can conveniently update functions over a long time.

Oh, sorry, I thought you were a member of @arceos-org or @Starry-OS. My point was simply that putting the project in the community allows the community to maintain it together; it wasn't asking you to relinquish your maintenance responsibilities.

For example, I've granted repository access to the developer of https://github.com/Starry-OS/starry-vdso. Regarding your situation, I might be more inclined to directly invite you to join @Starry-OS. I'm wondering what your thoughts are.

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