-
Notifications
You must be signed in to change notification settings - Fork 101
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
Comments
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. |
What do you think if we generate the DTS like |
It looks great to process text for DTB generation. However, |
From
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. |
After some exploration, I found that the API to convert DTS to DTB, which is implemented in We may not have an easy way to generate DTB from DTS without the
|
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. |
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 likeminimal.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:
minimal.dts
as the template, and then provide the option to apply dt overlayPlease let me know what you think about this.
The text was updated successfully, but these errors were encountered: