Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customize device tree for system emulation #527

Open
RinHizakura opened this issue Dec 25, 2024 · 7 comments
Open

Customize device tree for system emulation #527

RinHizakura opened this issue Dec 25, 2024 · 7 comments
Assignees

Comments

@RinHizakura
Copy link
Collaborator

RinHizakura commented Dec 25, 2024

Currently, I want to try adding a -append option similar to QEMU to specify kernel boot args more conveniently. I want to discuss which implementation may be a better choice for the future development of rv32emu.

In more detail, system simulation is currently implemented using the -b option to provide a device tree describing the platform. However, because the device tree is coupled with the hardware (emulation) design of rv32emu itself, it means that even if the user wants to customize the device tree, he/she still needs to be based on a template like minimal.dts. Therefore, I think it might be more appropriate to design only parts of the device tree that provide specific options for tweaking.

For the requirement to customize bootargs, there are several possible options as far as I know:

  1. Use libfdt to dynamically create a device tree(similar to qemu)
  2. Use minimal.dts as the template, and then provide the option to apply dt overlay
  3. Represent dts as a formatted string, and then fill in the customized part when executing the emulator

Please let me know what you think about this.

@RinHizakura RinHizakura self-assigned this Dec 25, 2024
@jserv
Copy link
Contributor

jserv commented Dec 26, 2024

For system-level emulation, rv32emu (and semu) takes a different approach compared to QEMU. The core idea behind rv32emu is simplicity, avoiding the need to provide generic solutions upfront. Regarding device tree generation, I suggest leveraging an existing minimal DTS as a template combined with Python scripts (or other scripting tools) to generate peripherals and devices. Employing libfdt for this purpose might be unnecessarily complex.

@RinHizakura
Copy link
Collaborator Author

What do you think if we generate the DTS like make_dtb() and compile it in runtime? We can consider using #embed to embed the existing minimal.dts with some placeholder to specify the bootargs.

@jserv
Copy link
Contributor

jserv commented Dec 26, 2024

What do you think if we generate the DTS like make_dtb() and compile it in runtime?

It looks great to process text for DTB generation. However, dtc is now becoming a runtime dependency.
If using libfdt, do you think the code for generation could be as concise as kvm-host?

@RinHizakura
Copy link
Collaborator Author

RinHizakura commented Dec 26, 2024

It looks great to process text for DTB generation. However, dtc is now becoming a runtime dependency.

From system.mk I think we already have dtc dependency to build the minimalist DTS, so only if we consider the user may use the default prebuilt DTB only, the dtc should always be required.

If using libfdt, do you think the code for generation could be as concise as kvm-host?

If using libfdt, how about we use the part of dts to dtb compilation in dtc only, and use the text-based DTS as input. Ideally it should be concise.

@jserv
Copy link
Contributor

jserv commented Dec 26, 2024

If using libfdt, how about we use the part of dts to dtb compilation in dtc only, and use the text-based DTS as input. Ideally it should be concise.

That sounds like a viable approach. Please go ahead with the implementation.

@RinHizakura
Copy link
Collaborator Author

RinHizakura commented Dec 26, 2024

That sounds like a viable approach. Please go ahead with the implementation.

After some exploration, I found that the API to convert DTS to DTB, which is implemented in dtc, is not exposed as a library. This makes it difficult to use, which can make things too complicated. In the end, I don't think this is the right way.

We may not have an easy way to generate DTB from DTS without the dtc dependency. But with libfdt, we can modify the provided DTB. So I'll have two alternative solutions:

  1. Accept the dependency for dtc: RinHizakura@cb89b70ef1
    • We can ask the user to install dtc themselves, or even add the submodule and build it locally
  2. Always use the prebuilt DTB for rv32emu(may need to place DTB under rv32emu repo directly), but we can use libfdt to modify some attributes

@jserv
Copy link
Contributor

jserv commented Dec 26, 2024

We may not have an easy way to generate DTB from DTS without the dtc dependency. But with libfdt, we can modify the provided DTB. So I'll have two alternative solutions:

  1. Accept the dependency for dtc: RinHizakura@cb89b70ef1
  2. Always use the prebuilt DTB for rv32emu(may need to place DTB under rv32emu repo directly), but we can use libfdt to modify some attributes

We can include dtc as a build-time dependency and embed the compiled DTB into the emulator using tools like bin_to_c. This way, dtc won't be needed when running the emulator.

@jserv jserv added this to the release-2025.1 milestone Dec 27, 2024
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

No branches or pull requests

2 participants