au-ts
Abstract away board and toolchain details
I don't think it's worse like this but I'm not sure if it's an improvement either.
Having the toolchain extracted makes more sense than the boards I think.
There is a bit of duplication with the boards in each example but it's really simple, just for the device classes.
I think that it is a good improvement imo. Especially when we change names of devices to their proper names (like meson eth changing to dwmac4.20), or have devices with peripherals of completely different names (like the star64 with snps-uart, dwmac5.1 eth), just having a central config for that specific board will be easier for users.
But that's more from the perspective of LionsOS, where the tooling will eventually deal with all of this. After discussing with Ivan, maybe the board abstractions don't necessarily belong in the sDDF.
But that's more from the perspective of LionsOS, where the tooling will eventually deal with all of this. After discussing with Ivan, maybe the board abstractions don't necessarily belong in the sDDF.
I was mostly thinking about this for LionsOS, but would like to have the same mechanism everywhere, and this seemed the right place to start. I'm also thinking, that maybe it should be in a separate configuration/build system tree. Except I hate multiplying the number of submodules we need.
I guess I don't really know what problem we're trying to solve? Why is the current approach inadequate?
I guess I don't really know what problem we're trying to solve? Why is the current approach inadequate?
What I mean by this is that the simpler approach seems fine for sDDF example systems and the abstraction is probably better left solely to LionsOS.
I guess I don't really know what problem we're trying to solve? Why is the current approach inadequate?
What I mean by this is that the simpler approach seems fine for sDDF example systems and the abstraction is probably better left solely to LionsOS.
I'm not sure the current approach is scalable to many many boards. Merely including a board description file, rather than repeating a huge if-then-else chain means:
- Adding new boards to an existing project is easier (although one still has to create the system file)
- Modifying a board's config (e.g., switching qemu_virt_aarch64 to use Cortex A76 instead of A53) can be done in one place and tested for all examples
- documenting the board's components is in one place, rather than spread through multiple examples
- It's much easier to generate the makefiles, assuming the LionsOS config tool will do that.
There's one more thing I'm doing before making this ready for review: adding docs of how it all works in the docs directory. (there's also a minor bug I've just fixed but haven;t pushed yet ... CFLAGS_HASH wasn't actually including all the CFLAGS necesarily.
Things you can do if this is merged:
-- specify optimisation level on the commandline. make OPTIMISATION=-Os
-- Change MICROKIT _BOARD or MICROKIT_CONFIG and have things rebuild properly
-- Switch toolchains on comand line make TOOLCHAIN=gcc -- and we could add other toolchains later
-- Add boards really easily
The next change needed for adding boards easily is abstracting out a python class with the board descriptions to import in meta.py
My main concern is that the meta.py changes introduce implicitness because it tries to abstract over all the examples. I think what would be better is to keep the examples themselves declaring what they want and instead having defaults described in boards.py and so if the user wants to change how their boards are described they can do so easily without having to change boards.py which in sDDF source code.
My main concern is that the meta.py changes introduce implicitness because it tries to abstract over all the examples. I think what would be better is to keep the examples themselves declaring what they want and instead having defaults described in
boards.pyand so if the user wants to change how their boards are described they can do so easily without having to changeboards.pywhich in sDDF source code.
boards.py provides a basic set of devices for each board; in any particular meta.py you can always append to or adjust any entry in the list.
I'm expecting that for the examples in sddf it'll be enough; LionsOS and out-of-tree may need overrides.
As we get more driver classes, the Board class can be extended.
So:
board = next(filter(lambda b: b.name == "imx8mm_evk", BOARDS))
board.serial = "/soc@0/bus@30800000/spba-bus@30800000/serial@30890000"
to use serial1 in imx8mm