feat(system-cfg): Add a global system configuration package

[miguelafsilva5]

PR Description

This PR attempts to create a configuration file that concentrate the majority of system configurations used by throughout all packages. These include: platform, toolchain, architecture name, path directories to the test sources and repos, among others.

The main goal of this PR is to decrease the verbose in the several package recipes as well as improving the readability and development of system recipes (default.nix).

The following code is required in the default.nix being built.

system-cfg  = callPackage ./bao-nix/pkgs/system-cfg/system-cfg.nix{
      inherit platform;
      bao-tests = ./bao-tests;
      tests_srcs = ./src;
      baremetal_patch = ./baremetal.patch;
    };

It allows for the calling of packages to be done with less inputs, which were often repeated. Using a guest package as an example. It inherits the system-cfg attribute from the recipe which contains the attributes that were previously inputs. (e.g. bao-tests, tests_srcs, baremetal_patch).

    guests = [
          (callPackage (./bao-nix/pkgs/guest/baremetal-remote-tf.nix)
                  { 
                    inherit system-cfg;
                    inherit toolchain;
                    guest_name = "baremetal";
                    inherit list_tests;  #will not be inherited in the future, 
                                         #it will have to be defined per guest
                    inherit list_suites; #will not be inherited in the future,
                                         #it will have to be defined per guest 
                    inherit log_level; #maybe move to the cfg file?                    
                  }
          )
      ];

It also allows the recipe to be written with less verbose, using the attributes available in the system-cfg. The following example ilustrates how the attributtes are intended to be used, without requiring the recipe to use the previous dictionaries to decipher which is the architecture and toolchain names.

        export ARCH=${system-cfg.arch}
        export CROSS_COMPILE=${system-cfg.toolchain_name}-

Considerations

• The list of tests and suites were left out of the system-cfg as these attributes will be specific to each guest.
• There is a possibility that the toolchain should be a package made available from the system-cfg.
• The usage of a standard package file might not be the ideal for the current use case. A possible alternative might be using flakes.
• There might be other attributes that should be moved to the system-cfg, currently or in the future.
• Only a single guest recipe was modified since we will try to consolidate all baremetal guest recipes into a single one in the near future.

I'm opening this PR as a draft, hoping to invite some discussion and insights.

P.S.: please ignore the 3 first commits. These belong to #9 . And this PR assumes that #9 is accepted

[Diogo21Costa]

This looks good. I have just made a few adjustments for clarity and coherence:

This LGTM. I have only two comments regarding this PR:

1. I'm not particularly fond of the name "sytstem-cfg". In my opinion, it would be more appropriate to use something like "platform_dependencies", "platform_utils", or "platform_config" since it encompasses a set of configurations related to the target platform.
2. Regarding the firmware, I believe it would be better to organize the firmware related to each platform (e.g., qemu-aarch64-virt.nix, qemu-riscv64-virt.nix) inside a folder named "platforms". Eventually, we could further categorize it by architectures (e.g., firmware/platforms/armv8-a, firmware/platforms/armv8-r, firmware/platforms/risc-v). Alternatively, we could define the architectures within the firmware itself (firmware/armv8-a, firmware/armv8-r, firmware/risc-v), and within each architecture, place the related firmware and platforms accordingly.

[miguelafsilva5]

This looks good. I have just made a few adjustments for clarity and coherence:

This LGTM. I have only two comments regarding this PR:

1. I'm not particularly fond of the name "sytstem-cfg". In my opinion, it would be more appropriate to use something like "platform_dependencies", "platform_utils", or "platform_config" since it encompasses a set of configurations related to the target platform.
2. Regarding the firmware, I believe it would be better to organize the firmware related to each platform (e.g., qemu-aarch64-virt.nix, qemu-riscv64-virt.nix) inside a folder named "platforms". Eventually, we could further categorize it by architectures (e.g., firmware/platforms/armv8-a, firmware/platforms/armv8-r, firmware/platforms/risc-v). Alternatively, we could define the architectures within the firmware itself (firmware/armv8-a, firmware/armv8-r, firmware/risc-v), and within each architecture, place the related firmware and platforms accordingly.

re: @Diogo21Costa

1: My idea behind the naming was that the recipe would encompass more than platform-related attributes. As it stands, it currently receives and outputs the directories for the bao-tests repo and test sources, which are not tied to the platform. However, I do agree that the proposed name might not be the best.

2: The firmware being on the PR is a mistake of mine. We should discuss in the #9 . Nonetheless, I disagree with the creation of more directories. Wher would you put the u-boot, atf and openSBI packages on your directory tree? I think it is a much cleaner and scalable solution to have a single .nix file per platform under the firmware folder. The package link (firmware/$platform) clearly identifies what it contains and for what target. The remaining packages (u-boot, atf, openSBI, etc) have their own folder. Lastly, I don't think you have any firmware tied to architecture. Maybe only the toolchain. And further separating the recipes would increase the complexity of the system.

[Diogo21Costa]

1: My idea behind the naming was that the recipe would encompass more than platform-related attributes. As it stands, it currently receives and outputs the directories for the bao-tests repo and test sources, which are not tied to the platform. However, I do agree that the proposed name might not be the best.

Ok, now I see. It makes sense to me now. What do you think about changing the naming to something like setup_cfg as it encompasses both the platform configuration and also the details related to the test setup?

2: The firmware being on the PR is a mistake of mine. We should discuss in the #9 . Nonetheless, I disagree with the creation of more directories. Wher would you put the u-boot, atf and openSBI packages on your directory tree? I think it is a much cleaner and scalable solution to have a single .nix file per platform under the firmware folder. The package link (firmware/$platform) clearly identifies what it contains and for what target. The remaining packages (u-boot, atf, openSBI, etc) have their own folder. Lastly, I don't think you have any firmware tied to architecture. Maybe only the toolchain. And further separating the recipes would increase the complexity of the system.

Crystal clear to me now! Moreover, I agree with this struct.

[miguelafsilva5]

1: My idea behind the naming was that the recipe would encompass more than platform-related attributes. As it stands, it currently receives and outputs the directories for the bao-tests repo and test sources, which are not tied to the platform. However, I do agree that the proposed name might not be the best.

Ok, now I see. It makes sense to me now. What do you think about changing the naming to something like setup_cfg as it encompasses both the platform configuration and also the details related to the test setup?

2: The firmware being on the PR is a mistake of mine. We should discuss in the #9 . Nonetheless, I disagree with the creation of more directories. Wher would you put the u-boot, atf and openSBI packages on your directory tree? I think it is a much cleaner and scalable solution to have a single .nix file per platform under the firmware folder. The package link (firmware/$platform) clearly identifies what it contains and for what target. The remaining packages (u-boot, atf, openSBI, etc) have their own folder. Lastly, I don't think you have any firmware tied to architecture. Maybe only the toolchain. And further separating the recipes would increase the complexity of the system.

Crystal clear to me now! Moreover, I agree with this struct.

I've updated the PR to use your suggest naming.