-
Notifications
You must be signed in to change notification settings - Fork 104
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
Add standalone option to regz to generate register api files without microzig framework dependency #258
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey! great patch, I like these changes. But we cut the monorepo up into smaller packages, so you need to access other packages as a dependency instead of grabbing their files directly.
@@ -14,12 +14,22 @@ pub fn build(b: *Build) !void { | |||
.iconv = false, | |||
}); | |||
|
|||
const assets = [_]struct { []const u8, []const u8 }{ | |||
.{ "../../core/src/mmio.zig", "mmio_file" }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can't grab a file directly from another package like this. Instead you need to use the handle for the core package to retrieve it.
.{ "../../core/src/mmio.zig", "mmio_file" }, | |
.{ core_dep.path("src/mmio.zig"), "mmio_file" }, |
If this causes a dependency loop then MMIO needs to be its own package. I think this would be ideal, since we could put some tooling for simulated MMIO in there as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mattnite Yeah I see what you mean. if I use the core_dep to reference it then regz can no longer be built by running zig build
in the tools/regz directory. Not sure if there is a way to tell in the build.zig if it is being run from a parent or in the current directory. Let me look into this a bit and see what I can do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be easier to just copy the Mmio
struct in the regz project to be used in standalone mode, because you also need a definition of Handler
and unhandled
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mattnite I tried to reference via core_dep but I can't seem to figure out how to make it work. None of the tools have any dependencies on the core module that I can use as a reference so I'm not quite sure how to access that dependency in the regz build.zig. Sorry but I'm pretty new to zig and the build system on this project is a bit more complicated than I am used to. Can you provide some guidance on how to access within the build.zig of regz?
Hey @mihnen my bad on the delayed response, instead of a long detailed explanation, I made a patch for you: Hopefully that helps explain, but if you have any additional questions please don't hesitate to ask! |
regz is a great tool for generating register definitions however not everybody wants to buy into the whole microzig framework just to get a board up and running. Since regz seems to be kept up to date with zig releases and has good support it makes sense to modify it to support standalone register definitions.
There are two items that need dealt with in the current generated output
The standalone mode option removes the generation of the vector table and includes the Mmio directly into the generated output (wrapped in a struct). For some reason there is a copy of mmio.zig in the tools/regz/src directory that is different than the one in core/src. I have removed the local one in regz as I could not see anywhere it was actually used and instead embed the one from core/src.
Note that tests now pass for any code changed however there are other tests that were already failing:
error: 'init_from_atdf' is not marked 'pub'
error: 'init_from_json' is not marked 'pub'
error: 'init_from_svd' is not marked 'pub'