Abstract away board and toolchain details

[wom-bat]

Put the common bits in a makefile snippet.

[wom-bat]

Is this a good idea?

[Ivan-Velickovic]

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.

[Kswin01]

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.

[wom-bat]

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.

[Ivan-Velickovic]

I guess I don't really know what problem we're trying to solve? Why is the current approach inadequate?

[Ivan-Velickovic]

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.

[wom-bat]

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.