DTB for BBB?

[Shiro]

Hello,

I’m new to RTEMS (but not new to embedded RTOS deployment).  I worked through 
the BBB QuickStart and have run hello.exe on a BBB.

Question regarding the correct DTS for BBB:  in section 8.2.3.2 of the online 
docs: 

https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html?highlight=dts#beagle

I don't follow this:

We build the dtb from the FreeBSD source matching the commit hash from the 
libbsd HEAD of freebsd-org.  For example if the HEAD is at 
“19a6ceb89dbacf74697d493e48c388767126d418” …

Can anyone point me to where HEAD is determined?  And how it matched into the 
FreeBSD.org  tree?


Best regards,
-david



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: DTB for BBB?

[Shiro]

> 
>> Question regarding the correct DTS for BBB:  in section 8.2.3.2 of the 
>> online docs:
>> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html?highlight=dts#beagle
>> 
>> I don't follow this:
>> 
>> We build the dtb from the FreeBSD source matching the commit hash from the 
>> libbsd HEAD of freebsd-org.  For example if the HEAD is at 
>> “19a6ceb89dbacf74697d493e48c388767126d418” …
>> 
> The HEAD is determined by the HEAD of the freebsd-org submodule in the
> rtems-libbsd repository, which is basically the FreeBSD source. Though
> the documentation says that we should always take commit hash matching
> with the submodule HEAD, the commit id that you found in the
> documentation (i.e 19a6ceb) is the last one that has been thoroughly
> tested. You might want to use that id and build the dtb.
> 
> To build the DTB, you can use the script provided by FreeBSD in the
> following source directory:
> sys/tools/fdt/make_dtb.sh
> 
> And the right dts to build is sys/gnu/dts/arm/am335x-boneblack.dts


Thank you for the detailed explanation.  Now I get it!
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

typical RTEMS system HW?

[Shiro]

Hello,

I’m new to RTEMS but very much like its features.  I’m wonder what HW (MCU/MPU 
and memory size) RTEMS is typical used on.  Anyone care to share a bit of 
details?

Thanks,
Shiro
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: typical RTEMS system HW?

[Shiro]

> On Jul 9, 2021, at 11:40 AM, Joel Sherrill  wrote:
> 
> On Thu, Jul 8, 2021 at 3:11 AM Shiro  wrote:
>> 
>> Hello,
>> 
>> I’m new to RTEMS but very much like its features.  I’m wonder what HW 
>> (MCU/MPU and memory size) RTEMS is typical used on.  Anyone care to share a 
>> bit of details?
>> 
> 
> Well I held back hoping more people on the using side would answer.
> This is my perspective from the long-term developer view.
> 
> Most users are on 32-bit platforms. There have been 64-bit ports for a
> long time but most people aren't using them.
> 
> There are a lot of users from the space community who tend to be on
> hardened hardware. This SPARC LEON family is probably the most
> commonly used there. In the early days of the LEON predecessor
> (ERC32), I would say 1-4 MB was quite common for RAM. Other CPU
> architectures have been used in RTEMS space-based systems like
> PowerPC, Coldfire, MIPS, and ARM.
> 
> There are also a lot of users in the EPICS (Experimental Physics and
> Industrial Control System) community which is commonly used in high
> energy physics, astronomy, and other big science equipment. I would
> tend to put a lot of those users on VME and CompactPCI boards with the
> PowerPC and x86 being common. They may still use some of their old
> VME m68040 boards or at least we haven't dropped support for them.
> These mostly tend to have 4-16 MB RAM.
> 
> There are also a lot of commercial users and currently I think a lot
> of those are on ARM platforms (STM, Xilinx, NXP, etc) with RISC-V
> coming on strong. There are users on other architectures but I think
> the bulk are there now. PowerPC users seem to be realizing they are on
> the tail end of the lifecycle and need to look forward to a
> transition.
> 
> RTEMS has been ported to 16-bit CPUs but there are none currently in the tree.
> 
> You can certainly have an RTEMS application which fits into a small
> amount of Flash but as you add capabilities, you tend to pick up code
> and data space requirements. The earliest RTEMS systems would be big
> if they had 1-4 MB total Flash and RAM but that's considered small
> these days in general. I recall one m68k based system that has 96K
> total code and data space. The legacy network stack could easily run
> on 1 MB RAM. Now libbsd generally has more features and takes more
> memory. It may be able to be trimmed down but no one has invested the
> time. lwIP would be a better alternative in those cases.
> 
> If you need a lot of features, the footprint naturally grows. If you
> are on a small target board, some tests won't fit. For example, some
> of the file system tests assume a 1MB RAM disk. If you don't have the
> space, you just don't.
> 
> I still think that a large RTEMS system is on the smallest end of
> Linux systems.
> 
> Not sure this gives specific answers but that's my impression.
> 
> —joel


Wow, what an awesome reply.  Thank you for the detailed response, I appreciate 
your time.  This helps me quite a bit.  My take away is that RTEMS is not going 
to be a comfortable fit for Cortex M3/M4 MCUs with 64k to 256k RAM (although it 
can be shoehorned in with some work).

This helps me partition the MCU/MPU space by RTOS.

Thanks again,
Shiro


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] STM32 lwIP addition and CMake support

[Shiro]

Hi, Robin,

Would it be possible to retain the STM32 code, but carve out the “contaminated” 
lwIP code into a patch file.  Then RTEMS code base remains “clean” and if I, 
any user, chose to enable lwIP on STM32, I could do so by applying that patch.  
I’d contaminate my src tree, but that’d be my responsibility and in any case, 
I’d be compliant (target is after all an STM32…).

The “patch trick” to manage license contamination has worked well for others in 
the past.

Cheers,
-Shiro

> On Sep 8, 2021, at 11:51 AM, Robin Müller  wrote:
> 
> Hi,
> 
> Unfortunately, there was no other reply to the request.
> 
> Easiest solution would be to exclude the STM32 code completely out of RTEMS 
> code for now. I can host it as example code in a personal repository.
> But then I might have to change the architecture of the lwIP code again which 
> provided some building blocks to make porting/using it easier.
> 
> Kind Regards
> Robin
> 
> On Thu, 5 Aug 2021 at 17:00, Gedare Bloom  <mailto:ged...@rtems.org>> wrote:
> STM is not going to fix their Ultimate Liberty License at this time.
> https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010
>  
> <https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010>
> 
> So, we need to avoid using their example codes.
> 
> On Wed, Jun 9, 2021 at 12:16 PM Gedare Bloom  <mailto:ged...@rtems.org>> wrote:
> >
> > I joined the Issue. Thanks for working on this.
> >
> > On Wed, Jun 9, 2021 at 11:30 AM Robin Müller  > <mailto:robin.muelle...@gmail.com>> wrote:
> > >
> > > I posted a reply but I think it did not go through. Will post it now.
> > >
> > > Kind Regards
> > > Robin
> > >
> > > On Wed, 9 Jun 2021 at 18:31, Robin Müller  > > <mailto:robin.muelle...@gmail.com>> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I received a reply from STM32 about the licensing issues. They requested 
> > >> more specific information about the "vendor device restrictions"  for 
> > >> the HAL code.
> > >> The issue is here: 
> > >> https://github.com/STMicroelectronics/STM32CubeH7/issues/139 
> > >> <https://github.com/STMicroelectronics/STM32CubeH7/issues/139>
> > >> Can anyone provide more information about this (maybe even directly in 
> > >> the issue) ? I can forward it to them as well. Thanks a lot in advance!
> > >>
> > >> Kind Regards
> > >> Robin
> > >>
> > >> On Wed, 28 Apr 2021 at 02:45, Chris Johns  > >> <mailto:chr...@rtems.org>> wrote:
> > >>>
> > >>> On 28/4/21 2:58 am, Robin Müller wrote:
> > >>> > Okay, I can understand that you'd like to have one build system only. 
> > >>> > We had the
> > >>> > same issue with a former Makefile build system and the new CMake 
> > >>> > system and
> > >>> > decided to make the former system obsolete> because maintaining both 
> > >>> > of them would be too much work
> > >>> For RTEMS what we use has been selected for a range of important 
> > >>> reasons and the
> > >>> rtems-central repo and the qual work highlights the importance of those
> > >>> decisions. Waf is a python framework for building software and in 
> > >>> rtems.git our
> > >>> build system support is written in a clearly defined portable language 
> > >>> with
> > >>> power helper libraries. We can run code formatters on our build system, 
> > >>> have
> > >>> unit tests and there is even source level debuggers. We treat the build 
> > >>> system
> > >>> like any other piece of code we have.
> > >>>
> > >>> > First thing I  can do is that I split up the patch and extract the 
> > >>> > CMake
> > >>> > specific files. Concerning a clean solution to allow users to use 
> > >>> > CMake without
> > >>> > introducing files like CMakeLists.txt,
> > >>> > I am not sure right now. Extracting the information required by CMake 
> > >>> > would
> > >>> > again require scripts to export source files and include paths.
> > >>> > The simplest solution would still be a CMakeLists.txt file in the 
> > >>> > root here
> > >>> > which simply sets source files and include paths i

Re: [PATCH v2] STM32 lwIP addition and CMake support

[Shiro]

Hi, Robin,

There are a number of ways to manage this, but the first thought that comes to 
my mind is:

* Priority #1: protect the license-integrity of the RTEMS src tree.  That means 
any “license contamination” must be quarantined.
I like the way NetBSD (BSD) handles source covered by some foreign (GNU, etc.) 
license.  They keep the src in a separate dir and further  sub dirs by license.

* Priority #2: support the “difficult” platform.  Try to make the build as 
transparent and simple as for other “easy” platforms.  The magic here would be, 
I think, a recipe in the Makefile to build the STM32 lwIP source file, then 
compile…. The Makefile would need to know where the patch is…

In this way, one could remove the “foreign-license” dir tree and know the RTEMS 
tree is clean.

Just my $0.02.

Best regards,
-Shiro


> On Sep 9, 2021, at 3:01 AM, Robin Mueller  wrote:
> 
> Hi Shiro,
> 
> So you mean, retain the STM32 file unchanged in the source tree and then 
> applying the patch? Or copy it from somewhere and then apply the patch? 
> 
> I thought of that option as well.
> The only issue I see here is that I merged the (example) files provided by 
> STM32 so that one file can be used for every lwIP API. I managed to have the 
> same files for alle three APIs this way, which is the cleaner solution in my 
> opinion. But I guess I could just take the base files for the Raw API 
> provided by STM32, create the patch to add support for all other APIs and add 
> all other tweaks required for RTEMS, and then provide that patch somewhere.
> 
> Kind Regards
> Robin
> On 08.09.21 21:05, Shiro wrote:
>> Hi, Robin,
>> 
>> Would it be possible to retain the STM32 code, but carve out the 
>> “contaminated” lwIP code into a patch file.  Then RTEMS code base remains 
>> “clean” and if I, any user, chose to enable lwIP on STM32, I could do so by 
>> applying that patch.  I’d contaminate my src tree, but that’d be my 
>> responsibility and in any case, I’d be compliant (target is after all an 
>> STM32…).
>> 
>> The “patch trick” to manage license contamination has worked well for others 
>> in the past.
>> 
>> Cheers,
>> -Shiro
>> 
>>> On Sep 8, 2021, at 11:51 AM, Robin Müller >> <mailto:robin.muelle...@gmail.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> Unfortunately, there was no other reply to the request.
>>> 
>>> Easiest solution would be to exclude the STM32 code completely out of RTEMS 
>>> code for now. I can host it as example code in a personal repository.
>>> But then I might have to change the architecture of the lwIP code again 
>>> which provided some building blocks to make porting/using it easier.
>>> 
>>> Kind Regards
>>> Robin
>>> 
>>> On Thu, 5 Aug 2021 at 17:00, Gedare Bloom >> <mailto:ged...@rtems.org>> wrote:
>>> STM is not going to fix their Ultimate Liberty License at this time.
>>> https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010
>>>  
>>> <https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010>
>>> 
>>> So, we need to avoid using their example codes.
>>> 
>>> On Wed, Jun 9, 2021 at 12:16 PM Gedare Bloom >> <mailto:ged...@rtems.org>> wrote:
>>> >
>>> > I joined the Issue. Thanks for working on this.
>>> >
>>> > On Wed, Jun 9, 2021 at 11:30 AM Robin Müller >> > <mailto:robin.muelle...@gmail.com>> wrote:
>>> > >
>>> > > I posted a reply but I think it did not go through. Will post it now.
>>> > >
>>> > > Kind Regards
>>> > > Robin
>>> > >
>>> > > On Wed, 9 Jun 2021 at 18:31, Robin Müller >> > > <mailto:robin.muelle...@gmail.com>> wrote:
>>> > >>
>>> > >> Hi,
>>> > >>
>>> > >> I received a reply from STM32 about the licensing issues. They 
>>> > >> requested more specific information about the "vendor device 
>>> > >> restrictions"  for the HAL code.
>>> > >> The issue is here: 
>>> > >> https://github.com/STMicroelectronics/STM32CubeH7/issues/139 
>>> > >> <https://github.com/STMicroelectronics/STM32CubeH7/issues/139>
>>> > >> Can anyone provide more information about this (maybe even directly in 
>>> > >> the issue) ? I can forward it to them as well. Thanks a lot in advance!
>>> > >>
>>> > >> Kind Regards
>>

rtems6 sb-set-builder gdb enable-tui?

[Shiro]

Hello,

I'd like to build RTEMS' tools from git (rtems 6), but I'd like gdb
configured with "--enable-tui".  Any advice on where/how to tweak
the scripts would be appreciated.

Thanks,
Shiro
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel