Re: RTEMS Deployment | Solution for building generic BSPs (#9)

2025-12-22 Thread Amar Takhar (@amar)



Amar Takhar commented on a discussion: 
https://gitlab.rtems.org/rtems/tools/rtems-deployment/-/issues/9#note_137705


Thanks, lots of great detail here, something I forgot to add is that the GUI 
only works off of Git repositories so a version is either a `git hash`, `tag`, 
or a `branch`. There will not be any downloadable versions the users specifies 
what they want and the default will always be `main`. A version of the GUI put 
into a release can have it's default version set to the release tag.

I'm not sure what the solution is as it has to be worked into rtems-deployment 
somehow.

Previous, historical versions can be kept in rtems-deployment as static `json` 
files though?  These are not dynamic and would never change.  Hosting them 
online somewhere does not make sense as once they are generated that's it for 
the life of the project.  I can go back and generate those so we know for what 
release version of RTEMS which BSPs and architectures are available.

As for main, I don't know I guess I'm stuck now forever checking out RTEMS 
which is what I really wanted to avoid doing.  This means both rtems-deployment 
and the RSB will have to use that specific checked out repository so we're not 
constantly checking out copies of the RTEMS git repository for every action.  
Is it possible to tell both to only use the locally checked out version of 
RTEMS?

-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/tools/rtems-deployment/-/issues/9#note_137705
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

Re: RTEMS Deployment | Solution for building generic BSPs (#9)

2025-12-22 Thread Chris Johns (@chris)



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

Re: RTEMS Deployment | Solution for building generic BSPs (#9)

2025-12-22 Thread Amar Takhar (@amar)


Reassigned Issue 9

https://gitlab.rtems.org/rtems/tools/rtems-deployment/-/issues/9

Amar Takhar was added as an assignee.

-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/tools/rtems-deployment/-/issues/9
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

Re: RTEMS Deployment | Solution for building generic BSPs (#9)

2025-12-22 Thread Amar Takhar (@amar)



Amar Takhar commented: 
https://gitlab.rtems.org/rtems/tools/rtems-deployment/-/issues/9#note_137635


I need a solution for this please that I can work on thank you let's discuss it 
here.

-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/tools/rtems-deployment/-/issues/9#note_137635
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

Re: RTEMS Deployment | Solution for building generic BSPs (#9)

2025-12-22 Thread Amar Takhar (@amar)


Reassigned Issue 9

https://gitlab.rtems.org/rtems/tools/rtems-deployment/-/issues/9

Chris Johns was added as an assignee.

-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/tools/rtems-deployment/-/issues/9
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