Re: Building newly for 6/rtems-arm blows on compiling iOS_failure.cc

[Mr. Andrei Chichak]

Yes, I noticed it was not clang but gcc that was complaining about --->  
<—— that long after I hit send. I was hoping for your forgiveness.

I went into /Users/andreichichak/quick-start/src/rsb and did a find . -name 
ctype_inline.h
I love being able to cut/paste between computers.

Giving:

./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bionic/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/qnx/qnx6.1/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/vxworks/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/uclibc/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/djgpp/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/hpux/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/newlib/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bsd/dragonfly/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bsd/netbsd/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bsd/freebsd/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bsd/openbsd/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bsd/darwin/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/mingw32/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/gnu-linux/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/generic/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/solaris/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/tpf/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/mingw32-w64/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/aix/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
  <—— this one
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/armv7-r+fp/hard/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/cortex-m7/hard/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/armv7-r/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/cortex-r52/hard/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/armv7-a/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/armv6-m/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/armv7-a+simd/hard/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/cortex-m3/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h

RTEMS5 for arm on macOS 12.3. Or how Apple blew up RTEMS.

[Mr. Andrei Chichak]

Good day. It must be Friday afternoon, because my RTEMS5 install has been 
messed up. Yes, this install worked until now.

RTEMS5, stm32f4 BSP, macOS

I recently updated macOS to 12.3 (Monterey) and a “feature" of 12.3 is the 
removal of python 2.7. This caused arm-rtems5-gdb to fail with:

dyld[12480]: Library not loaded: 
/System/Library/Frameworks/Python.framework/Versions/2.7/Python 
 Referenced from: /Users/andreichichak/RTEMS5/rtems/5/bin/arm-rtems5-gdb
 Reason: tried: 
'/System/Library/Frameworks/Python.framework/Versions/2.7/Python' (no such 
file), '/Library/Frameworks/Python.framework/Versions/2.7/Python' (no such 
file) 
Abort trap: 6

I went back to my install scripts, grabbed the latest RSB blob, then

../source-builder/sb-set-builder —prefix=$HOME/RTEMS5/rtems/5 5/rtems-arm

goes well for a while then fails setting up to build gdb with:

config: tools/rtems-gdb-9.1-1.cfg
error: config error: gdb-common-1.cfg:99: "gdb: python: header file not found: 
python3.8/Python.h, please install”

I had python 3.9 installed, so I used brew and installed 3.8, uninstalled 3.9, 
reinstalled 3.8, rebooted, but I get the same rsb failure.

I’m not sure how python is supposed to be configured. Maybe this is a clue:

python —version
-bash: python: command not found

python3 —version
Python 3.8.9

I seem to have a couple of instances of Python.h in an appropriately named 
directory:

/usr/local/Cellar/python@3.8/3.8.13/Frameworks/Python.framework/Versions/3.8/include/python3.8/Python.h
/System/Volumes/Data/usr/local/Cellar/python@3.8/3.8.13/Frameworks/Python.framework/Versions/3.8/include/python3.8/Python.h

But something doesn’t seem to be pointing at one of those folders so the rsb 
script can find it.

Any hints?

Thanks,

Andrei


-
Andrei Chichak

Systems Developer
CBF Systems Inc.
225 College Plaza
8215 112 Street.
EDMONTON, ALBERTA
T6G 2C8
CANADA

Phone: 780-628-2072
Skype: andrei.chichak










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

$ ./waf bsp_list --rtems-bsps=sparc/ doesn't work

[Mr. Andrei Chichak]

I’m going through the docs at 
https://docs.rtems.org/branches/master/user/bld/index.html 
 and section 7.3.2 
BSP List has a broken command

./waf bsp_list

Works nicely, but adding the —rtems-bsps=  param to it always gives the result:

No BSP matches with the specified patterns: 'sparc/'

whatever pattern you give it.

(master head)

Andrei___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Getting STM32H7 ethernet networking working

[Mr. Andrei Chichak]

Is the README.md in the master branch of rtems-libbsd the recommended set of 
instructions for getting the STM32H7 networking blob built?

Previously I had been following the RTEMS Networking User Manual, but the 
README.md file says that I should build my BSP with networking turned off.
>From this I figured that networking turned on would bring in the legacy 
>networking stack, which should not be mentioned.

Does the Networking User Manual describe the (shhh) legacy networking stack, or 
the bsd stack?

Does this mean that the bsd networking stack is a library that my application 
links against? Is that the right way to look at this?

Thanks,
Andrei 

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

Re: Using LwIP on the STM32H7

[Mr. Andrei Chichak]

Can you point me at Sebastian’s driver? I haven’t been able to find it in the 
repo.

A

> On 2021-February-01, at 16:05, Joel Sherrill  wrote:
> 
> 
> 
> On Mon, Feb 1, 2021 at 4:54 PM Mr. Andrei Chichak  <mailto:gro...@chichak.ca>> wrote:
> Oh, crap, I’m off by 3 orders of magnitude, I’ve got 512KB. 
> 
> That's an LWIP candidate. :) 
> 
> But Sebastian did a driver for libbsd for the H7 series. If you have more 
> memory
> or can attach external RAM, that's an option. 
> 
> 
> Bother, I need a nap already.
> 
> A
> 
>> On 2021-February-01, at 15:35, Joel Sherrill > <mailto:j...@rtems.org>> wrote:
>> 
>> 
>> 
>> On Mon, Feb 1, 2021 at 4:25 PM Andrei Chichak > <mailto:and...@chichak.ca>> wrote:
>> any guidance choosing between “Legacy Stack” and libbsd?
>> 
>> This one is easy. Please please please please do NOT choose the legacy 
>> stack. :)
>> 
>> The legacy stack should only be used on projects that are using it and those 
>> are encouraged to move along to libbsd or lwip or new hardware.  We have no
>> plans to eliminate the legacy stack from the world. But as Gedare said, we 
>> want 
>> to move it to a separate repository. If someone cares, then it gets a build 
>> system
>> and can be used with a strong discouragement.
>> 
>> It is 20+ years old now and IPV4 only. Do the math. :)
>>  
>> 
>> I’ve got a 512MB of RAM processor, so I expect that I’ll have lots left 
>> over. But that is TBD.
>> 
>> 512MB is still huge in RTEMS terms. That won't be a problem for libbsd at 
>> all.  It is when you
>> start considering targets with < 16MB that we have concerns. I suspect that 
>> number is <4MB 
>> but the original BSP for the legacy stack only had 1MB for code and data 
>> space. It is clear 
>> some boards that could run the legacy stack will not be capable of running 
>> libbsd but we
>> don't have a hard cutoff yet.
>> 
>> --joel
>> 
>> A
>> 
>>> On 2021-February-01, at 15:21, Joel Sherrill >> <mailto:j...@rtems.org>> wrote:
>>> 
>>> 
>>> 
>>> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom >> <mailto:ged...@rtems.org>> wrote:
>>> 
>>> 
>>> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns >> <mailto:chr...@rtems.org>> wrote:
>>> On 2/2/21 8:32 am, Mr. Andrei Chichak wrote:
>>> > Is there any advantage to using bsd networking over LWiP, or vice versa? 
>>> 
>>> They are different stacks with different feature sets and different hardware
>>> resource demands. I am not familiar with the features of LwIP so I am not 
>>> the
>>> best person to compare them.
>>> 
>>> The BSD stack has most of the features you get with FreeBSD. It has IPv4, 
>>> IPv6,
>>> IPsec, VLAN, bridging, dhcp, openssl, lots of routing alternatives, packet
>>> filtering and more. It has a range of useful commands including tcpdump.
>>> 
>>> The BSD based system provides a solid base to solve a range of networking 
>>> issues
>>> your RTEMS device may encounter at the system level and not at the low level
>>> programming level.
>>> 
>>> The BSD stack uses a lot more resources to do all this and LwIP may be a 
>>> prefect
>>> fit. I welcome RTEMS being able to support a range of networking solutions.
>>> 
>>> 
>>> I have a student (Vijay) working on refactoring libnetworking out of RTEMS, 
>>> and will be testing ability to compile legacy vs libbsd. If the lwip build 
>>> is demonstrated and clear, I can have him also look at bringing that into 
>>> the fold. This is in line with https://devel.rtems.org/ticket/3850 
>>> <https://devel.rtems.org/ticket/3850>
>>> 
>>> One thing to be aware of is that all the POSIX networking header files for 
>>> RTEMS are in newlib and always present. I had to address this and lwip when 
>>> we did Deos+RTEMS. Deos uses lwip as their native stack running in a 
>>> partition and other partitions use a client to get to it. The lwip 
>>> constants had values that were not the same as the RTEMS BSD headers for 
>>> POSIX defines. There were also some places where the structure definitions 
>>> did not align. I had to write a bit of mapping in the client. When lwip 
>>> works at all, it would be awesome to have a way for it to ignore their own 
>>> minimal POSIX API files and build against ours. 
>>> 
>>> This would be 

Re: Using LwIP on the STM32H7

[Mr. Andrei Chichak]

Oh, crap, I’m off by 3 orders of magnitude, I’ve got 512KB. 

Bother, I need a nap already.

A

> On 2021-February-01, at 15:35, Joel Sherrill  wrote:
> 
> 
> 
> On Mon, Feb 1, 2021 at 4:25 PM Andrei Chichak  <mailto:and...@chichak.ca>> wrote:
> any guidance choosing between “Legacy Stack” and libbsd?
> 
> This one is easy. Please please please please do NOT choose the legacy stack. 
> :)
> 
> The legacy stack should only be used on projects that are using it and those 
> are encouraged to move along to libbsd or lwip or new hardware.  We have no
> plans to eliminate the legacy stack from the world. But as Gedare said, we 
> want 
> to move it to a separate repository. If someone cares, then it gets a build 
> system
> and can be used with a strong discouragement.
> 
> It is 20+ years old now and IPV4 only. Do the math. :)
>  
> 
> I’ve got a 512MB of RAM processor, so I expect that I’ll have lots left over. 
> But that is TBD.
> 
> 512MB is still huge in RTEMS terms. That won't be a problem for libbsd at 
> all.  It is when you
> start considering targets with < 16MB that we have concerns. I suspect that 
> number is <4MB 
> but the original BSP for the legacy stack only had 1MB for code and data 
> space. It is clear 
> some boards that could run the legacy stack will not be capable of running 
> libbsd but we
> don't have a hard cutoff yet.
> 
> --joel
> 
> A
> 
>> On 2021-February-01, at 15:21, Joel Sherrill > <mailto:j...@rtems.org>> wrote:
>> 
>> 
>> 
>> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom > <mailto:ged...@rtems.org>> wrote:
>> 
>> 
>> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns > <mailto:chr...@rtems.org>> wrote:
>> On 2/2/21 8:32 am, Mr. Andrei Chichak wrote:
>> > Is there any advantage to using bsd networking over LWiP, or vice versa? 
>> 
>> They are different stacks with different feature sets and different hardware
>> resource demands. I am not familiar with the features of LwIP so I am not the
>> best person to compare them.
>> 
>> The BSD stack has most of the features you get with FreeBSD. It has IPv4, 
>> IPv6,
>> IPsec, VLAN, bridging, dhcp, openssl, lots of routing alternatives, packet
>> filtering and more. It has a range of useful commands including tcpdump.
>> 
>> The BSD based system provides a solid base to solve a range of networking 
>> issues
>> your RTEMS device may encounter at the system level and not at the low level
>> programming level.
>> 
>> The BSD stack uses a lot more resources to do all this and LwIP may be a 
>> prefect
>> fit. I welcome RTEMS being able to support a range of networking solutions.
>> 
>> 
>> I have a student (Vijay) working on refactoring libnetworking out of RTEMS, 
>> and will be testing ability to compile legacy vs libbsd. If the lwip build 
>> is demonstrated and clear, I can have him also look at bringing that into 
>> the fold. This is in line with https://devel.rtems.org/ticket/3850 
>> <https://devel.rtems.org/ticket/3850>
>> 
>> One thing to be aware of is that all the POSIX networking header files for 
>> RTEMS are in newlib and always present. I had to address this and lwip when 
>> we did Deos+RTEMS. Deos uses lwip as their native stack running in a 
>> partition and other partitions use a client to get to it. The lwip constants 
>> had values that were not the same as the RTEMS BSD headers for POSIX 
>> defines. There were also some places where the structure definitions did not 
>> align. I had to write a bit of mapping in the client. When lwip works at 
>> all, it would be awesome to have a way for it to ignore their own minimal 
>> POSIX API files and build against ours. 
>> 
>> This would be similar to how the newlib headers define a very complete POSIX 
>> API set but each target OS may only support a subset of it.
>> 
>> As it is, I wonder if there is a conflict between the RTEMS newlib network 
>> .h files and those provided by lwip which could cause issues.
>>  
>> 
>> We have no certain timeline yet, but it is now work-in-progress. We will 
>> bring to devel when progress is made. If we do lwIP too, we will aim to do a 
>> performance analysis with real hardware, so that we can hopefully provide 
>> evidence to help these kind of questions. 
>> 
>> -Gedare 
>> 
>> Chris
>> ___
>> users mailing list
>> users@rtems.org <mailto:users@rtems.org>
>> http://lists.rtems.org/mailman/listinfo/users 
>> <http://list

Re: Using LwIP on the STM32H7

[Mr. Andrei Chichak]

any guidance choosing between “Legacy Stack” and libbsd?

I’ve got a 512MB of RAM processor, so I expect that I’ll have lots left over. 
But that is TBD.

A

> On 2021-February-01, at 15:21, Joel Sherrill  <mailto:j...@rtems.org>> wrote:
> 
> 
> 
> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom  <mailto:ged...@rtems.org>> wrote:
> 
> 
> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> On 2/2/21 8:32 am, Mr. Andrei Chichak wrote:
> > Is there any advantage to using bsd networking over LWiP, or vice versa? 
> 
> They are different stacks with different feature sets and different hardware
> resource demands. I am not familiar with the features of LwIP so I am not the
> best person to compare them.
> 
> The BSD stack has most of the features you get with FreeBSD. It has IPv4, 
> IPv6,
> IPsec, VLAN, bridging, dhcp, openssl, lots of routing alternatives, packet
> filtering and more. It has a range of useful commands including tcpdump.
> 
> The BSD based system provides a solid base to solve a range of networking 
> issues
> your RTEMS device may encounter at the system level and not at the low level
> programming level.
> 
> The BSD stack uses a lot more resources to do all this and LwIP may be a 
> prefect
> fit. I welcome RTEMS being able to support a range of networking solutions.
> 
> 
> I have a student (Vijay) working on refactoring libnetworking out of RTEMS, 
> and will be testing ability to compile legacy vs libbsd. If the lwip build is 
> demonstrated and clear, I can have him also look at bringing that into the 
> fold. This is in line with https://devel.rtems.org/ticket/3850 
> <https://devel.rtems.org/ticket/3850>
> 
> One thing to be aware of is that all the POSIX networking header files for 
> RTEMS are in newlib and always present. I had to address this and lwip when 
> we did Deos+RTEMS. Deos uses lwip as their native stack running in a 
> partition and other partitions use a client to get to it. The lwip constants 
> had values that were not the same as the RTEMS BSD headers for POSIX defines. 
> There were also some places where the structure definitions did not align. I 
> had to write a bit of mapping in the client. When lwip works at all, it would 
> be awesome to have a way for it to ignore their own minimal POSIX API files 
> and build against ours. 
> 
> This would be similar to how the newlib headers define a very complete POSIX 
> API set but each target OS may only support a subset of it.
> 
> As it is, I wonder if there is a conflict between the RTEMS newlib network .h 
> files and those provided by lwip which could cause issues.
>  
> 
> We have no certain timeline yet, but it is now work-in-progress. We will 
> bring to devel when progress is made. If we do lwIP too, we will aim to do a 
> performance analysis with real hardware, so that we can hopefully provide 
> evidence to help these kind of questions. 
> 
> -Gedare 
> 
> Chris
> ___
> users mailing list
> users@rtems.org <mailto:users@rtems.org>
> http://lists.rtems.org/mailman/listinfo/users 
> <http://lists.rtems.org/mailman/listinfo/users>___
> users mailing list
> users@rtems.org <mailto:users@rtems.org>
> http://lists.rtems.org/mailman/listinfo/users 
> <http://lists.rtems.org/mailman/listinfo/users>
-
Andrei Chichak
4024-120 STREET
EDMONTON, ALBERTA
T6J 1X8
CANADA


Phone: 780-434-6266
Skype: andrei.chichak






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

Re: Using LwIP on the STM32H7

[Mr. Andrei Chichak]

Is there any advantage to using bsd networking over LWiP, or vice versa? 

With Robin’s BSP, if it gets released, I think I should be able to finish up my 
bsd networking BSP for STM32F7. I’ll also see what I can do about getting it 
going for F4 as well.

Andrei

> On 2021-January-29, at 12:21, Gedare Bloom  > wrote:
> 
> 
> 
> On Fri, Jan 29, 2021 at 9:57 AM Robin Müller  > wrote:
> The whole code base I'm using might go public soon so I will also send the 
> link here
> as soon as it is. I think this might also be useful for people who would like 
> to evaluate how to set up Eclipse and the CMake build system for 
> their application
> 
> Kind Regards
> Robin
> 
> This will be greatly appreciated, thank you. Glad you got it working, and in 
> relatively short order!
>  
> On Fri, 29 Jan 2021 at 17:47, Robin Müller  > wrote:
> Alright, I figured out the issue, that was an application level problem, the 
> UDP frames are received and sent without issues as far as I can see.
> I think I might submit a patch soon with some of initial improvements. But I 
> will summarize the changes I had to do here for now in case other people want 
> to 
> use lwIP, based on the example application provided by STM.
> 
> BSP Changes:
> 
> Inside bsps/arm/stm32h7/start/bspstart.c:
> 
> I changed the HAL_GetTick() function, which returned 0 previously to return 
> the tick count by default: 
> 
> uint32_t HAL_GetTick(void)
> {
>   return rtems_clock_get_ticks_since_boot();
> }
> 
> I'm not sure whether there was a specific reason to have it return 0 by 
> default, but that led to some issues because this function is generally 
> called by the 
> HAL or by example applications and it's a lot of hassle to replace every call 
> with  rtems_clock_get_ticks_since_boot() 
> 
> bsps/arm/shared/start/linkcmds.base:
> 
> I added following section to the linker file.
> This is a really ugly solution because this file is used by all ARM bsps. I 
> might look into how to make it stm32h7 specific, but it worked for me now 
> because
> I only have the STM32H7
> 
> /* Ugly solution for now */
> .lwip_sec (NOLOAD) : ALIGN_WITH_INPUT {
> . = ABSOLUTE(0x3004);
> *(.RxDecripSection)
> . = ABSOLUTE(0x30040060);
> *(.TxDecripSection)
> . = ABSOLUTE(0x30040200);
>*(.RxArraySection)
> } >SRAM_3 AT> REGION_TEXT_LOAD
> 
> bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c:
> 
> On line 364 in HAL_ETH_Init, comment out the preprocessor guards to set the 
> DSL to 64bit. I don't know what this line exactly does yet, but it was 
> necessary 
> to get lwIP to work properly.
> 
> #ifndef __rtems__
>/* SET DSL to 64 bit */
>MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
> #endif /* __rtems__ */
> 
> On line 2648 in ETH_DMATxDescListInit comment the preprocessor guard so that 
> the function is executed. This is necessary
> so the DMA descriptors are set up properly.
> 
> Do the same for ETH_DMARxDescListInit starting at line 2687.
> 
> I think that was all. Hope it helps some people
> 
> Kind Regards
> Robin Müller
> 
> 
> 
> On Fri, 29 Jan 2021 at 15:45, Robin Müller  > wrote:
> I think I might have found one issue. In the HAL_ETH_Init(ETH_HandleTypeDef 
> *heth) function 
> 
> The following piece of code was excluded:
> 
> #ifndef __rtems__
>   /* SET DSL to 64 bit */
>   MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
> #endif /* __rtems__ */
> 
> I reintroduced the line and now I have been able to receive UDP frames and 
> send some back. I am still missing some frames, but at least it's working now.
> I might look into how to put the lwIP section in a separate linkcmd file once 
> I have figured out why some frames are missing, but the way I see it, 
> it is driver specific (STM used SDRAM3 for the required lwIP memory. One way 
> would be to add an option in the config.ini like STM32H7_USE_LWIP and then
> load those additional sections for lwIP.
> 
> Kind Regards
> Robin
> 
> On Fri, 29 Jan 2021 at 14:18, Joel Sherrill  > wrote:
> 
> 
> On Fri, Jan 29, 2021, 5:52 AM Robin Müller  > wrote:
> Hi,
> 
> I am actually configuring the MPU with the following function, which was 
> taken over from the STM32 example project:
> 
> /*Configure the MPU attributes */
> void MPU_Config(void)
> {
> MPU_Region_InitTypeDef MPU_InitStruct;
> 
> /* Disable the MPU */
> HAL_MPU_Disable();
> 
> /* Configure the MPU attributes as Device not cacheable
>  for ETH DMA descriptors */
> MPU_InitStruct.Enable = MPU_REGION_ENABLE;
> MPU_InitStruct.BaseAddress = 0x3004;
> MPU_InitStruct.Size = MPU_REGION_SIZE_256B;
> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
> MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
> 

Re: Using LwIP on the STM32H7

[Mr. Andrei Chichak]

Good morning,

I’ve been trying to get ethernet on STM32F7 going using the bsd networking 
stack (not going that well, there is a LOT of undocumented knowledge to 
straighten out).


The STM32x7 ethernet controllers need their descriptors and data areas to be 
located on 32-byte boundaries with a combination of cache being turned off and 
buffering being turned off. This is a side effect of the STM32x7 DMA and data 
caching.

The examples that ST have for LWiP under FreeRTOS have some issues with the 
linker file having overlapping sections and the stack (above the ETH data 
areas) being left with no cache and no buffering. The space above the rx/tx 
buffers is also less than the stack space minimum specified in the linker file 
as well.  Some rearranging of the ETH descriptors and data areas would be 
prudent. Like push them to the top of SRAM and locate the stack below.

To get this all going, they set up the MPU for two overlapping sections, one 
being the top 16kB of SRAM and the other the 256B that contain the ETH 
descriptors. I believe the MPU regions can be set in increments of 32Bytes, so 
setting up the cache and buffering should be do-able without affecting the 
stack.



In RTEMS it appears that I have to pull the data and lengths out of some mbufs 
(I had to look that up), and push it all into the data areas. Using LWiP, I 
think you do similar things, just pulling the data out of the pbuf chains.

On the STM forums is an item about how to actually get a working ETH going on 
ST processors. There’s all sorts of issues including Cube generating code for 
ST’s dev boards that has the incorrect address for the PHY chip.
Take a look at: 
https://community.st.com/s/question/0D50XBOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32
 


More later,

Andrei



-
Andrei Chichak

Systems Developer
CBF Systems Inc.
225 College Plaza
8215 112 Street.
EDMONTON, ALBERTA
T6G 2C8
CANADA

Phone: 780-628-2072
Skype: andrei.chichak










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

Re: Issue with configure on MacOS

[Mr. Andrei Chichak]

> On 2021-January-05, at 19:47, Joel Sherrill  wrote:
> 
> 
> 
> On Tue, Jan 5, 2021, 8:36 PM mailto:gro...@chichak.ca>> 
> wrote:
> 
>> Any ideas or pointers?
>> 
>> Did you forget to add something to c/src/libbsp? The autoconf builds system 
>> files are under the old tree while all the code is under bsps/. This makes 
>> it easier to remove the old build system when all is done.
>> 
>> 
> 
> likely. In c/src/lib/libbsp/arm I created a new folder called stm32f767 that 
> contains configure.ac  and Makefile.am with (my version 
> of) appropriate modifications for my ‘767 board.
> 
> I assumed that autoconf would pick up all of the stuff in c/src and somehow 
> use bsps, but do I need to munge any config files or is the presence of the 
> BSP folders in bsps and c/src/lib/libbsp all?
> 
> Is the bsp listed in the M4 file in libbsp/arm?

Direct hit! Updating that file made the build work much better.

There are still some issues, naturally, but that’s got me going again.

Thanks Joel.

Andrei


> 
> 
> Andrei
> ___
> users mailing list
> users@rtems.org 
> http://lists.rtems.org/mailman/listinfo/users 
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Issue with configure on MacOS

[Mr. Andrei Chichak]

Good year!

Can anybody point me at a guide or set of notes for setting up a new BSP for 
RTEMS 5, derived from an existing one, so that ‘configure’ will pick it up?

At one point I took Sebastian’s STM32H7 BSP and munged it to work with an F767, 
but then the whole BSP system changed, my scripts broke, and I’ll have to start 
again.

I need to know things like what directory to place my BSP, and how to get the 
build system to recognize it.

I’m using the RTEMS User Manual 5.1 as my guide, targeting RTEMS 5 using MacOS 
Mojave as a host. 

I have the tools built and the script getting the kernel code is:

cd ~/RTEMS5/rtems
mkdir kernel
cd kernel
git clone git://git.rtems.org/rtems.git  rtems
cd rtems
git checkout 5

Then I patch in my stm32f767 BSP. I move:

configuration info into …/kernel/rtems/c/src/lib/libbsp/arm/stm32f767,  stolen 
from ../stm32f4 for now
code into …/kernel/rtems/bsp/arm/stm32f767, stolen from ../stm32f4 for now

and the script for building the kernel is

cd ~/RTEMS5/rtems/kernel/rtems
./bootstrap -c && ~/RTEMS5/rtems/rsb/source-builder/sb-bootstrap
cd ..
mkdir stm32f4
cd stm32f4
$HOME/RTEMS5/rtems/kernel/rtems/configure --prefix=$HOME/RTEMS5/rtems/5 \
--target=arm-rtems5 --enable-rtemsbsp=stm32f4 --enable-posix \
--disable-networking
make -j10 all

Building for stm32f4 builds clean.

Then I altered the script above swapping stm32f767 for stm32f4 and I get:

...
rm -f make/stm32f767.cache
make -f /Users/andreichichak/RTEMS5/rtems/kernel/rtems/c/src/make/bsp.mak \
'RTEMS_BSP=stm32f767' 'RTEMS_ROOT=.' \
make/stm32f767.cache
config.status: creating lib/libbsp/Makefile
config.status: executing depfiles commands
=== configuring in make 
(/Users/andreichichak/RTEMS5/rtems/kernel/stm32f767/arm-rtems5/c/stm32f767/make)
configure: running /bin/sh 
/Users/andreichichak/RTEMS5/rtems/kernel/rtems/c/src/make/configure 
--disable-option-checking '--prefix=/Users/andreichichak/RTEMS5/rtems/5'  
'--host=arm-rtems5' '--build=x86_64-apple-darwin18.7.0' '--target=arm-rtems5' 
'--enable-posix' '--disable-networking' 'BSP_VERBOSE_FATAL_EXTENSION=1' 
'--with-target-subdir=arm-rtems5' 
'--exec-prefix=/Users/andreichichak/RTEMS5/rtems/5/arm-rtems5' 
'--includedir=/Users/andreichichak/RTEMS5/rtems/5/arm-rtems5/include' 
'build_alias=x86_64-apple-darwin18.7.0' 'host_alias=arm-rtems5' 
'target_alias=arm-rtems5' '--with-project-root=../../' 
'--with-project-top=../../' 
'--with-rtems-build-top=/Users/andreichichak/RTEMS5/rtems/kernel/stm32f767/arm-rtems5/c/stm32f767'
 '--with-rtems-source-top=/Users/andreichichak/RTEMS5/rtems/kernel/rtems' 
'RTEMS_BSP=stm32f767' 'RTEMS_BSP_FAMILY=stm32f767' 'CFLAGS=-mthumb 
-mcpu=cortex-m4 -O2 -g -ffunction-sections -fdata-sections -Wall 
-Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes 
-Wnested-externs' --cache-file=/dev/null 
--srcdir=/Users/andreichichak/RTEMS5/rtems/kernel/rtems/c/src/make
checking for gmake... no
checking for make... make
checking build system type... x86_64-apple-darwin18.7.0
checking host system type... arm-unknown-rtems5
checking rtems target cpu... arm
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-rtems5-strip... arm-rtems5-strip
checking for a thread-safe mkdir -p... 
/Users/andreichichak/RTEMS5/rtems/kernel/rtems/c/src/make/../../../install-sh 
-c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for RTEMS_BSP... stm32f767
checking for cat... /bin/cat
checking for cp... /bin/cp
checking for mv... /bin/mv
checking for ln... /bin/ln
checking whether ln -s works... yes
checking for chmod... /bin/chmod
checking for sort... /usr/bin/sort
checking for touch... /usr/bin/touch
checking for cmp... /usr/bin/cmp
checking for sed... /usr/bin/sed
checking for gm4... /opt/local/bin/gm4
checking for bash... /bin/bash
checking for style of include used by make... GNU
checking for arm-rtems5-gcc... arm-rtems5-gcc
checking for arm-rtems5-gcc... (cached) arm-rtems5-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-rtems5-gcc accepts -g... yes
checking for arm-rtems5-gcc option to accept ISO C89... none needed
checking dependency style of arm-rtems5-gcc... gcc3
checking how to run the C preprocessor... arm-rtems5-gcc -E
checking whether arm-rtems5-gcc accepts -isystem... yes
checking whether arm-rtems5-gcc accepts --pipe... yes
checking whether arm-rtems5-gcc --pipe accepts -specs... yes
checking whether CPU supports SMP... disabled
checking for arm-rtems5-g++... arm-rtems5-g++
checking whether we are using the GNU C++ 

Re: RTEMS book - Real-Time Systems Development with RTEMS and Multicore Processors

[Mr. Andrei Chichak]

Thank you Joel and Gedare.

Ordered and on its way.

A

> On 2020-December-08, at 14:10, Karel Gardas  > wrote:
> 
> 
> Wow! Such a book! Anyway, looking where it's available, I've found that
> kindle edition is quite cheaper on amazon.de  -- only 88 
> euros in
> comparison with $160 on US amazon...
> 
> Thanks,
> Karel
> 
> On 12/8/20 9:57 PM, Juan Solano wrote:
>> Hi all,
>> 
>> has anybody around here read and can recommend the recent book on RTEMS, 
>> Real-Time Systems Development with RTEMS and Multicore Processors (from 
>> Gedare Bloom and Joel Sherrill)?
>> 
>> I am starting with RTEMS and I am contemplating to buy it, but it is really 
>> expensive (170$).
>> 
>> Rgds,
>> Juan.
>> ___
>> users mailing list
>> users@rtems.org 
>> http://lists.rtems.org/mailman/listinfo/users
>> 
> 
> ___
> users mailing list
> users@rtems.org 
> http://lists.rtems.org/mailman/listinfo/users




-
Andrei Chichak

Systems Developer
CBF Systems Inc.
225 College Plaza
8215 112 Street.
EDMONTON, ALBERTA
T6G 2C8
CANADA

Phone: 780-628-2072
Skype: andrei.chichak










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

mDNS DNS-SD ZeroConf in RTEMS 5 ?

[Mr. Andrei Chichak]

I’m looking for a bit of guidance. I’m working on a piece of equipment that 
will sit out on a local ethernet network, providing a service, and my ex-Cisco 
buddy says that there are standard services to do service advertising and 
discovery and that I should use them rather than rolling my own.

To that end, I was wondering if the bsd networking stack in RTEMS 5 had the 
widgets to support service advertising through the mDNS/DNS-SD system?

I’ll be working with and STM32F767, but Seb’s work on the STM32H7 networking 
should open up the ethernet and bsd network stack to the F767. 

If this all fails I could drop back to using LwIP out of ST’s HAL, but it would 
probably be better to use the existing RTEMS features.

Opinions?

Thanks, Andrei


-
Andrei Chichak

Systems Developer
CBF Systems Inc.
225 College Plaza
8215 112 Street.
EDMONTON, ALBERTA
T6G 2C8
CANADA

Phone: 780-628-2072
Skype: andrei.chichak










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

Re: Fatal source exception in loopback sample on powerpc/qoriq_e6500_64

[Mr. Andrei Chichak]

Not knowing much about what you are doing, but working with other members of 
the PPC family (MPC5634M) currently, your error dump is showing an IVOR2, which 
is a data storage interrupt, but doesn’t show some of the interesting registers.


SRRO will point at the instruction that caused the fault
SRR1 contains the MCR at the time of the fault

but 

DEAR = 0x0404dda8

is the address in the page that was being accessed when the fault happened. So 
you may know what is being accessed, but not from where.

Take a look at https://www.nxp.com/docs/en/reference-manual/E6500RM.pdf  
section 4.9.4 for more info.

I’ve seen this a lot when dereferencing pointers to addresses that the MMU 
doesn’t have mapped. IVOR6 shows up when you try and execute from addresses 
that are not in the MMU.

From what I’ve encountered, you should embrace this section of the manual since 
you will routinely see IVOR2, and 6.

Maybe this will help.

A


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

Re: STM32 Nucleo F429ZI bsp ?

[Mr. Andrei Chichak]

The ‘429 shares a data sheet with the STM32F407VGT6 that is the basis of the 
STM32F4 BSP.

The 429 has more RAM (256k vs 192k), and the ZI version has more Flash (2M vs 
1M). This would mean that the linker files would need to be altered simply. 

The 429 mostly adds an LCD controller and support for external SDRAM, but none 
of those things are covered by the STM32F4 BSP anyway.

I’m using the STM32F4 BSP with a ‘405 processor (a cheaper ‘407 without 
ethernet), and according to ST CubeMX, the VG version of the 429 is pin 
compatible.

I wouldn’t expect that you would have to do much to use the STM32F4 BSP on the 
‘429ZI, just change the linker file. I’d also expect that you could use the BSP 
unaltered, and you’d just have a reduced address space while you learn.

Andrei

> On 2020-August-24, at 09:52, Richi Dubey  wrote:
> 
> Hi,
> 
> Until someone helps with your exact question, have a look at this link: 
> https://stackoverflow.com/questions/47069698/rtems-stm32f4-how-to-use-bsp 
> . 
> The author of the question has built a Cortex M4 board too.
> 
> Good luck.
> 
> On Mon, Aug 24, 2020 at 6:26 PM Juan Solano  > wrote:
> Hi all,
> 
> I am learning rtems, trying to use it with the STM32 Nucleo F429ZI, a Cortex 
> M4 board. I don't know yet my way around and I am not sure how difficult is 
> to adapt a generic ARM bsp to a specific board. Does anybody know if some 
> work has already been done in the Nucleo boards?
> 
> Regards,
> Juan.
> ___
> users mailing list
> users@rtems.org 
> http://lists.rtems.org/mailman/listinfo/users 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users


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

devel.rtems.org down?

[Mr. Andrei Chichak]

Executing:
cd $HOME/quick-start/src/rsb/rtems
../source-builder/sb-set-builder --source-only-download 5/rtems-arm

Getting:
RTEMS Source Builder - Set Builder, 5 (b45df48a51bc)
Build Set: 5/rtems-arm
Build Set: 5/rtems-autotools.bset
Build Set: 5/rtems-autotools-internal.bset
config: tools/rtems-autoconf-2.69-1.cfg
package: autoconf-2.69-x86_64-apple-darwin18.7.0-1
Creating source directory: sources
download: https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz 
 -> 
sources/autoconf-2.69.tar.gz
downloading: sources/autoconf-2.69.tar.gz - 1.8MB of 1.8MB (100%)   
config: tools/rtems-automake-1.12.6-1.cfg
package: automake-1.12.6-x86_64-apple-darwin18.7.0-1
download: https://ftp.gnu.org/gnu/automake/automake-1.12.6.tar.gz 
 -> 
sources/automake-1.12.6.tar.gz
downloading: sources/automake-1.12.6.tar.gz - 2.0MB of 2.0MB (100%)   
Creating source directory: patches
download: 
https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff
 

 -> patches/automake-1.12.6-bugzilla.redhat.com 
-1239379.diff
download: 
https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
 

 error: 
error: downloading 
https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
 

 all paths have failed, giving up
Build FAILED
error: downloading 
https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
 

 all paths have failed, giving up
Build Set: Time 0:00:07.223354
error: downloading 
https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
 

 all paths have failed, giving up
Build Set: Time 0:00:07.229660
error: downloading 
https://devel.rtems.org/raw-attachment/ticket/2616/automake-1.12.6-bugzilla.redhat.com-1239379.diff:
 

 all paths have failed, giving up
Build Set: Time 0:00:07.253637
Build FAILED

Poking around, I find that devel.rtems.org  isn’t 
answering.

Thanks,
Andrei___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Link errors with an install using quick-start guide

[Mr. Andrei Chichak]

Hi,

It’s me again. I thought I would try and update my tools since a lot has 
changed in the last year and I haven’t been keeping stuff up to date.

So I followed Chris’ quick-start docs on the web pages to install an RTEMS 5 
set for arm stm32f4. 

It should be pretty straight forward, I’ve done this before for 4.11 and put 
together a bsp for STM32F7, but it’s fighting.

I put together a simple hello world, to make sure that I can get stuff to 
compile clean. No. I’m using the RTEMS plugin for Eclipse (yes it still works).

The linker is bitching about a whole bunch of missing symbols. I expect that 
there is a problem finding a library.

Any pointers?

Thanks,

Andrei



make all 
Building file: ../source/main.c
Invoking: RTEMS C Compiler
/Users/andreichichak/quick-start/rtems/5/bin/arm-rtems5-gcc 
-B/Users/andreichichak/quick-start/rtems/5/arm-rtems5/stm32f4/lib/ -specs 
bsp_specs -qrtems -ffunction-sections -fdata-sections -mthumb -mcpu=cortex-m4 
-Os -g -Wall -c -fmessage-length=0 -pipe -MMD -MP -MF"source/main.d" 
-MT"source/main.o" -o "source/main.o" "../source/main.c"
Finished building: ../source/main.c
 
Building target: rt5test.exe
Invoking: RTEMS Linker
/Users/andreichichak/quick-start/rtems/5/bin/arm-rtems5-gcc 
-B/Users/andreichichak/quick-start/rtems/5/arm-rtems5/stm32f4/lib/ -specs 
bsp_specs -qrtems -ffunction-sections -fdata-sections -mthumb -mcpu=cortex-m4 
-Wl,--gc-sections -o "rt5test.exe"  ./source/main.o   
/Users/andreichichak/quick-start/rtems/5/lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
 /Users/andreichichak/quick-start/rtems/5/arm-rtems5/stm32f4/lib/start.o: in 
function `bsp_start_vector_table_begin':
(.bsp_start_text+0x0): undefined reference to `_ISR_Stack_area_end'
/Users/andreichichak/quick-start/rtems/5/lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
 /Users/andreichichak/quick-start/rtems/5/arm-rtems5/stm32f4/lib/start.o: in 
function `bsp_start_vector_table_end':
/Users/andreichichak/quick-start/src/rtems/c/src/lib/libbsp/arm/stm32f4/../../../../../../bsps/arm/shared/start/start.S:396:
 undefined reference to `_ISR_Stack_area_end'
/Users/andreichichak/quick-start/rtems/5/lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
 
/Users/andreichichak/quick-start/rtems/5/arm-rtems5/stm32f4/lib/librtemscpu.a(free.o):
 in function `rtems_fatal':
/Users/andreichichak/quick-start/src/rtems/cpukit/include/rtems/fatal.h:88: 
undefined reference to `RTEMS_Malloc_Heap'
/Users/andreichichak/quick-start/rtems/5/lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
 
/Users/andreichichak/quick-start/rtems/5/arm-rtems5/stm32f4/lib/librtemscpu.a(malloc_deferred.o):
 in function `rtems_heap_allocate_aligned_with_boundary':
/Users/andreichichak/quick-start/src/rtems/c/src/../../cpukit/libcsupport/src/malloc_deferred.c:126:
 undefined reference to `RTEMS_Malloc_Heap'
/Users/andreichichak/quick-start/rtems/5/lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
 
/Users/andreichichak/quick-start/src/rtems/c/src/../../cpukit/libcsupport/src/malloc_deferred.c:126:
 undefined reference to `rtems_malloc_dirty_helper'
/Users/andreichichak/quick-start/rtems/5/lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
 
/Users/andreichichak/quick-start/src/rtems/c/src/../../cpukit/libcsupport/src/malloc_deferred.c:126:
 undefined reference to `rtems_malloc_extend_handler'
/Users/andreichichak/quick-start/rtems/5/lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
 
/Users/andreichichak/quick-start/rtems/5/arm-rtems5/stm32f4/lib/librtemscpu.a(malloc_initialize.o):
 in function `RTEMS_Malloc_Initialize':
/Users/andreichichak/quick-start/src/rtems/c/src/../../cpukit/libcsupport/src/malloc_initialize.c:53:
 undefined reference to `Configuration'
/Users/andreichichak/quick-start/rtems/5/lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
 
/Users/andreichichak/quick-start/src/rtems/c/src/../../cpukit/libcsupport/src/malloc_initialize.c:53:
 undefined reference to `RTEMS_Malloc_Heap'
/Users/andreichichak/quick-start/rtems/5/lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
 
/Users/andreichichak/quick-start/rtems/5/arm-rtems5/stm32f4/lib/librtemscpu.a(threadsetstate.o):
 in function `_Thread_Set_state_locked':
/Users/andreichichak/quick-start/src/rtems/c/src/../../cpukit/score/src/threadsetstate.c:48:
 undefined reference to `_Scheduler_Table'
/Users/andreichichak/quick-start/rtems/5/lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
 
/Users/andreichichak/quick-start/rtems/5/arm-rtems5/stm32f4/lib/librtemscpu.a(threadsetstate.o):
 in function `_Thread_Set_state':
/Users/andreichichak/quick-start/src/rtems/c/src/../../cpukit/score/src/threadsetstate.c:63:
 undefined reference to `_Scheduler_Table'
/Users/andreichichak/quick-start/rtems/5/lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
 
/Users/andreichichak/quick-start/rtems/5/arm-rtems5/stm32f4/lib/librtemscpu.a(threadstackfree.o):
 in function `_Thread_Stack_Free':

Re: function declare

[Mr. Andrei Chichak]

Assume that you are using C and C has a facility to bind together object 
modules from different files.

You define a function in one file, it has a bunch of parameters and doesn’t 
return anything.

In another file you use that function but don’t have a prototype that tells the 
compiler anything about the function.

Now assume that the compiler was written in 1972, and doesn’t benefit from 
things like mind reading.

C assumes, by default, that a function has one integer parameter and returns an 
integer, unless otherwise told. What other choices has it got? Nothing really. 

So in later versions of C, they introduced a thing called a prototype that 
gives the compiler a hint about the parameters and return values of a function.

All that you needed was to take your function header, put a semicolon on the 
end and paste it before the call to the function and the compiler would have 
done what you wanted instead of what you said.

Better yet, take that prototype and put it into a header file and whenever you 
want to call the function, put in an include statement, the compiler get’s the 
information about the parameters and return values, and overrides the int func( 
int) default nature.

A

> On 2019-June-26, at 12:41 AM, Jython  wrote:
> 
> I have a function named  oled_write_temp in a.c, if i dont declare it in a.h 
> , then i will get the wrong supply value in the function within main call, 
> why?
> 
> if i  declare it in a.h, then all is right
> 
> void oled_write_temp(float set_temp, const float supply, float return_temp)
> {
> 
> int base_x = 12, base_y = 60;
> 
> char buffer[20] = {0};
> 
> printf("supply_temp %f at %s\n", supply, __FUNCTION__);
> 
> snprintf(buffer, 20, "SUPPLY:%.2f", supply);
> printf("supply_temp string %s\n", buffer);
> 
> oled_clear_area(base_x, base_y + 16, 122, base_y + 32);
> OLED_ShowString(base_x, base_y + 16, buffer, 16, 1);
> 
> memset(buffer, 0, sizeof(buffer));
> snprintf(buffer, 20, "RETURN:%.2f", return_temp);
> OLED_ShowString(base_x, base_y + 36, buffer, 16, 1);
> 
> memset(buffer, 0, sizeof(buffer));
> snprintf(buffer, 20, "SET   :%.2f", set_temp);
> OLED_ShowString(base_x, base_y + 56, buffer, 16, 1);
> 
> }
> 
> ps: watch line  printf("supply_temp %f at %s\n", supply, __FUNCTION__);
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users


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

Re: stm32 external SRAM

[Mr. Andrei Chichak]

A 407 doesn’t normally have external RAM.

ARMs have flash at 0 and the 407 has RAM at 0x2000  as you discussed 
earlier.

If you want to work with external flash or RAM, you have to set up the FSMC or 
FMC to support it, but that isn’t a part of the dev board that Sebastian used 
for the BSP port.

The external memory is going to be very specific to your board. Which board are 
you working with?

A

> On 2019-June-13, at 06:23, Christian Mauderer 
>  wrote:
> 
> On 05/06/2019 02:55, Jython wrote:
>> Hello!
>> 
>> 2. In the normal (non-debugging) case, the linker script still
>>places the 
>> 
>>.text section near zero, but places the start of the .data and .bss
>>sections at the start location of the MPC555's internal RAM. The
>>system startup code then configures the external RAM just after the
>>internal RAM in memory, forming one large block from the two RAM
>>devices.
>> 
>> from https://devel.rtems.org/wiki/TBR/BSP/Ss555
>> 
>> but i dont know how to configure the external RAM just after the
>> internal RAM in memory?
>> hope you could give me some guide!
>>  
>> 
> 
> Hello Jython,
> 
> the documentation you linked is for an MPC. But your subject line
> mentions an STM32. What controller / BSP are you using?
> 
> Best regards
> 
> Christian Mauderer
> -- 
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users

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

Re: RTEMS scheduler bug ?

[Mr. Andrei Chichak]

> On 2019-April-04, at 7:23 AM, Joel Sherrill  wrote:
> 
> 
> 
> On Thu, Apr 4, 2019 at 7:28 AM Sebastian Huber 
>  > wrote:
> Hello,
> 
> On 04/04/2019 14:09, Catalin Demergian wrote:
> > Hi Andrei,
> > thank you for the elaborated answer !
> >
> > I checked my STM32 Cube settings, I have 3 enabled interrupts and they 
> > all have the preemption priority/sub priority set to zero !
> > it seems I ran into the same issue you had in 2015 :)
> > I will take your advice - change the priorities, regenerate the code 
> > and see what happens.
> 
> I mentioned this possible problem some months ago:
> 
> https://lists.rtems.org/pipermail/users/2018-September/032600.html 
> 
> 
> Andrei's answer is definitely a bit more elaborate.
> 
> Thanks Andrei! I am glad you are past this but let's do a post-game analysis 
> of what
> could be better next time so no one else suffers as much. These are random 
> ideas
> and I am open to more.

If I am setting up a new project, I’ll grab the BSP, or even just start a new 
project in eclipse, put together a model in CubeMX and - BAM - run into this 
issue.

I’ve seen this before, so I know where to go in my email stash to find my 
writeup of the solution and go and fix the interrupt priorities. But this only 
happens about once a year, so I don’t reflexively remember the minutia. 

Someone, other than me, will get mislead by the defaults in CubeMX and take the 
default 0 priorities and trip over the stupid rules. Without Cube, you’ll still 
get 0 priorities. Or you can choose your own priorities, but you need to know 
the stupid rule and use large value interrupt priorities.

So, how do we let people know that this is an issue with the STM32 series? 
Maybe an STM32 appendix to the c-user guide. That could be a good place to put 
stuff like “UART3 is used as a console on pins X and Y. To change these pins, 
alter these values in the BSP and rebuild”.

In the mean time, I’m just starting another project using an STM32F4 and RTEMS 
and I just remembered that I haven’t set the interrupt priorities properly. 
SIGH.

A

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

RTEMS 5 build on a Mac with the latest compilers?

[Mr. Andrei Chichak]

Hi,

I was wondering if anybody has tried to do a clean build if the HEAD with 
Apple’s latest version of Xcode?

Apple dropped Xcode 10.0 yesterday with all fo the associated command line 
tools. Since these are used to build the RTEMS tools, it seemed to be a 
dangerous update.

I always get a flinch when there is a .0 version compiler being dropped and I’m 
in the middle of a project.

Just wondering,

Andrei

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

Stitching in another BSP into V5

[Mr. Andrei Chichak]

Hello,

I’ve been using a BSP for the STM32F767 that was derived from the STM32F4 BSP. 

I had it stitched into the source tree, but the way that BSPs are handled has 
changed and I can’t get ./bootstrap to recognize my BSP’s existence.

What I did was to take my BSP and copy it into rtems/bsps/arm.

Is there some file that I have to munge to let bootstrap know that it should 
pick up my BSP?



For reference, my build script is:

cd
cd development/rtems
git clone git://git.rtems.org/rtems.git rtems
cd rtems
cp -R ~/RTEMSInstall/stm32f767 bsps/arm
./bootstrap
cd ..
mkdir b-stm32f767
cd b-stm32f767
$HOME/development/rtems/kernel/rtems/configure 
--prefix=$HOME/development/rtems/5 \
  --target=arm-rtems5 --enable-rtemsbsp=stm32f767 --enable-posix
make -j 8
make install


Thanks,
Andrei___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Malloc from ISR?

[Mr. Andrei Chichak]

(sorry if this ended up on the Devel list.)

I’m working with ST’s HAL USB stack, and to initialize the various structures, 
they use a USB interrupt as a trigger.

In this interrupt,  they malloc some space for a descriptor (504 bytes).

The RTEMS malloc always returns 0.

Is there a guard against calling malloc in an interrupt context?

I managed to get around the problem by doing a static allocation, but I was 
just wondering.


Andrei

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

Re: An issue with ARM interrupts revisits.

[Mr. Andrei Chichak]

One question though, where can I tap into the OS to figure out what priorities 
my ISRs are actually using?

If there is something odd with the encoding that ST uses for priorities, I 
could actually be fighting an issue with CubeMX for F7 that is causing my ISRs 
to be interpreted as NMIs again.

A

> On 2017-November-23, at 12:28 AM, Sebastian Huber 
>  wrote:
> 
> On 22/11/17 07:33, Sebastian Huber wrote:
>> I have absolutely no idea how you can end up in _ARMV7M_Thread_dispatch() 
>> with an unexpected interrupt level.
> 
> I think if you call an operating system service which leads to a thread 
> dispatch in a NMI handler, then you could end up with this situation. You can 
> test this with the following patch and run the spintrcritical10 test program.
> 
> diff --git a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c 
> b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> index 1c17a92cb5..f0ebe1506f 100644
> --- a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> +++ b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> @@ -104,7 +104,7 @@ static void _ARMV7M_Systick_handler_install(void)
> {
>  _ARMV7M_Set_exception_priority_and_handler(
>ARMV7M_VECTOR_SYSTICK,
> -BSP_ARMV7M_SYSTICK_PRIORITY,
> +1,
>_ARMV7M_Systick_handler
>  );
> }
> 
> -- 
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> 

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