New RTEMS user..

[Chris Johns]

On 7/9/18 3:39 am, Patrick O'Banion (TMMC) wrote:
> Hello,
Hi and welcome.

> So I built my first set of "Build Tools" for the sparc erc32 as suggested in the rtems help docs.  I was able to get the gdb SIS working with a modified "Hello World" example. (see attached)

Looking goods.

> Now I want to start working towards my goal of using rtems on a development board.  Here is where the noob questions comes in...
> 1. If I create a second set of build tools for an ARM processor, what is the best way to define the directory structure for it?

The user manual has some information about this:

https://docs.rtems.org/branches/master/user/installation/prefixes-sandboxing.html

> I currently have these defined for the sparc erc32...
> 
> ~/development/rtems/5
> ~/development/rtems/src/kernel
> ~/development/rtems/src/kernel/erc32
> ~/development/rtems/src/kernel/rtems
> ~/development/rtems/src/rtems-source-builder
> Etc..
> 
> If I build a new set of build tools, can they share these directories?

The install path or prefix can be the same. If you select a common path for all
tools you want to support you need to make sure you update all tool sets if the
tools are updated. This happens on master from time to time. If you do not an
architecture's build may not match the kernel's source and that could be confusing.

If you need to update the tools I suggest you move the current tools to a backup
directory so you can trial the updated build and revert back if it fails.

  I expect I will get a second set of "arm" build tools in my
"~/development/rtems/5/bin" directory.  I can see how in the src/kernel I can
create a new build directory.  For example "~/development/rtems/src/kernel/arm"
and recompile rtems for an arm processor there without disturbing the erc32 build.

There are 2 directories for the BSP, the directory you build the BSP in and the
prefix or the directory you install the BSP into. I tend to keep the install
path for a BSP above the src tree. For example:

 ~/development/rtems/kernel
 ~/development/rtems/kernel/erc32       <- install path (prefix)
 ~/development/rtems/kernel/arm         <- install path (prefix)
 ~/development/rtems/kernel/build/erc32 <- build path
 ~/development/rtems/kernel/build/arm   <- build path
 ~/development/rtems/kernel/rtems       <- source
 ~/development/rtems/rsb/rtems-source-builder

If you need to try a new kernel build you can move 'kernel/erc32' to
'kernel/erc32-1' and if you need to wind back you can simply rename the directories.

You can also use the same install path or prefix as the tools however this is
not recommended for the development branch which is RTEMS 5. You tend to update
the kernel more often than the tools.

>  But what do you typically do for the tools?

It varies and it depends on what you or your company want to do. I have seen the
tools and kernel implemented as external cmake jobs (not something I recommend).

We provide the flexibility so you can find something that suites you.

> I could archive them in a new directory or just change the dir name to something erc32 specific...

I would install or use the real prefix you want rather than renaming after
installing and using the renamed path. Most tools will relocate but there are
some cases for some tools that may fail, ie autoconf etc.

>  There are probably numerous ways to handle it, I was just wondering if there is a standard method most rtems users prefer.

The user manual and sandboxing is as close a standard way we have.

Chris