Chris Johns commented: https://gitlab.rtems.org/rtems/tools/rtems-deployment/-/issues/9#note_137639 I appreciate the detail and if deployment can provide the support I am more than happen to see it added. --- Deployment requires you provide an RSB on the `configure` command line. An instance of the RSB provides a specific set of architecture versioned tool sets that match a specific kernel version or branch set of architectures. It is always a 1:1 relationship. The RSB can only report the build sets it has and the contents of configurations of those build sets. If you ask it to build a BSP that does not exists it will try and the kernel build will report an error. Deployment probes the RSB for the RSB version during configure. This means a configured instance of deployment has a 1:1 relationship with the kernel sources by association due to the dependence on the RSB. --- There are two types of RSBs, a branch version or a released version. A released version will only fetch the RTEMS kernel source from the release URL. A branch version will fetch from gitlab a specific hash version set in a configuration file. The hash is from the same branch as the RSB. --- Deployment and the RSB do not hold the `arch/bsp` list the referenced RTEMS kernel supports. We manually maintain the architecture tool sets in the RSB so they match the list of BSP architectures in the kernel sources. User applications in C or C++ code are built to a specific version of the kernel and tools. This means the normal project flow is to select a version and to develop with it. If you know the RSB version you know the kernel and if you know the kernel you can run the `rtems-bsps` to generate a list or BSPs. Currently there is no tool or resource that can collect a map of `arch/bsp` per version. That is a view of the project that sits above deployment. --- Users normally hold kernel `config.ini` files that configure a BSP for target hardware they are using. This can be as simple as the UART port, default board rate or it could be deeply embedded like a bus clock speed. Users will want to provide such a file and these files are specific to a BSP. --- The deployment `config` directory holds a static set of vertical software stacks. It is designed to be open place for open or common software stacks users can use. --- To generate a BSP list you need a version of kernel sources. The `rtems-bsps` command is pretty basic and scans the sources for known things that let it generate a list. It provides a stable user interface while the way the list is formed can change. --- If a global resource of `rtems-bsps` JSON output is available could it be downloaded by the GUI? A release could hold `ARCH-BSP.json` (a known URL) and maybe automation could maintain versions for active branches? -- View it on GitLab: https://gitlab.rtems.org/rtems/tools/rtems-deployment/-/issues/9#note_137639 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
