Re: Need help to run a smp testsuite on erc32 with multi core

[Richi Dubey]

Hii,

I stumbled upon this problem again while trying to set up the
debugging environment. I have opened a small task ticket:
https://devel.rtems.org/ticket/3983#ticket.

On Wed, Apr 8, 2020 at 11:14 PM Gedare Bloom  wrote:
>
>
>
> On Wed, Apr 8, 2020, 11:17 AM Richi Dubey  wrote:
>>
>> Dear Dr. Bloom,
>>
>> I understand. I would be more specific from next time.
>>
>> When I ran sis with no multi-core option, the result came out same as when I 
>> ran it with -m 2 option, (To simulate the executable with 2 cores). And on 
>> reading sis manual, I understood it didn't support erc32 multiprocessing, 
>> now I know the reason was because erc32 is a single core processor.
>>
>> I built erc32 on SPARC - RTEMS with --enable-smp option enabled.
>>
>> On trying to run the debugger, sparc-rtems5-gdb [file], It doesnt not 
>> support the command " tar sim -erc32" anymore(from 
>> https://devel.rtems.org/wiki/Debugging/sis) and I didn't know how to set a 
>> simulator as a target.
>
> This page is outdated. It needs to be reviewed, relevant info moved to docs, 
> and page content replaced by a pointer to the docs.
>
> This should be added as a SmallTask ticket.
>
>>
>> Thank you.
>>
>> On Wed, Apr 8, 2020 at 1:03 AM Gedare Bloom  wrote:
>>>
>>> On Tue, Apr 7, 2020 at 1:30 PM Richi Dubey  wrote:
>>> >
>>> > Hey everyone,
>>> >
>>> > Can someone please help me out with running a smp testsuite on 
>>> > erc32(which uses SPARC instruction set). I tried using sis, but the -m 
>>> > option for multi core doesnt seem to work, as the sis readme says: "-m 
>>> > cores : Enable the number of cores (2 - 4) in a leon3 or RISC-V 
>>> > multi-processor system." and that sis supports:
>>> >
>>> What do you mean it doesn't seem to work? What was broken/how do you
>>> know it was broken?
>>>
>>> How did you configure/build rtems?
>>>
>>> How did you invoke sis?
>>>
>>> What is the output of running sis?
>>>
>>> >  " sis is capable of emulating four different processor systems:
>>> >  ERC32 ERC32 SPARC V7 processor
>>> > LEON2 LEON2 SPARC V8 processor
>>> > LEON3 LEON3 SPARC V8 processor
>>> >  RISC-V RISC-V (RV32IMACFD) processor "
>>> >
>>> > So if sis does not support multi-core for erc32 systems, what should I 
>>> > use to run a smp program on erc32?
>>> >
>>> >
>>> > ___
>>> > devel mailing list
>>> > devel@rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Adding fenv support for ARM

[Joel Sherrill]

On Fri, May 15, 2020, 5:59 PM Eshan Dhawan  wrote:

>
>
> On Fri, May 15, 2020 at 2:22 AM Eshan Dhawan 
> wrote:
>
>>
>>
>> On Wed, May 13, 2020 at 7:40 PM Joel Sherrill  wrote:
>>
>>> National free hint day!!!
>>>
>>> Look above the line that is reported. You will see __BEGIN_DECL. It
>>> isn't defined. It is intended to expand to the __cplusplus wrapper.
>>>
>>> After you fix this, you will sequentially find 2 other things to change
>>> in this file.
>>>
>>> I have made those changes when a new error occurs from the assembler in
>> arm thumb mode
>> There is no support for vfp instructions in arm thumb.
>>
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/BABGHDBB.html
>> So in which file will the compiler instructions given in the page
>> 
>> added?
>>
> FreeBSD has added file and architecture-specific flags in their
> makefile.inc
> https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/Makefile.inc
> How will it be added in newlib
> I tried adding the flags -mfpu=vfp -mfloat-abi=softfp (used in FreeBSD) to
> makefile.in but no effect.
>

This isn't going to work with newlib. They don't specify CPU flags that way.

The fenv code is going to have to compile for every multilib variant built
by arm-rtems and arm-eabi. You will have to use conditionals based on the
flags gcc uses to indicate the various cpu features. This command should be
close to how you you dump them.

gcc -dM -E - 
> thanks
> -Eshan
>
>> Errors :
>>
>> make[9]: Entering directory
>> '/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/libm/machine/arm'
>> arm-rtems5-gcc
>> -B/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/
>> -isystem
>> /home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/targ-include
>> -isystem /home/eshan/development/newlib/newlib-cygwin/newlib/libc/include
>>  -mthumb -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
>> -DPACKAGE_VERSION=\"3.3.0\" -DPACKAGE_STRING=\"newlib\ 3.3.0\"
>> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
>> -I../../../../../../../newlib-cygwin/newlib/libm/machine/arm -I
>> ../../../../../../../newlib-cygwin/newlib/libm/machine/arm/../../../../newlib/libm/common
>> -fno-builtin -mfpu=vfpv2 -ffunction-sections -fdata-sections
>>  -D_COMPILING_NEWLIB -DCLOCK_PROVIDED -DMALLOC_PROVIDED -DEXIT_PROVIDED
>> -DSIGNAL_PROVIDED -DGETREENT_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED
>> -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC
>> -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET
>> -D_NO_WORDEXP -D_NO_POPEN -D_NO_POSIX_SPAWN -DHAVE_INIT_FINI  -g -O2
>>  -mthumb -c -o lib_a-fenv-vfp.o `test -f 'fenv-vfp.c' || echo
>> '../../../../../../../newlib-cygwin/newlib/libm/machine/arm/'`fenv-vfp.c
>> /tmp/ccEHiFws.s: Assembler messages:
>> /tmp/ccEHiFws.s:37: Error: selected processor does not support `vmrs
>> r3,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:48: Error: selected processor does not support `vmsr
>> fpscr,r3' in Thumb mode
>> /tmp/ccEHiFws.s:81: Error: selected processor does not support `vmrs
>> r3,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:119: Error: selected processor does not support `vmrs
>> r3,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:134: Error: selected processor does not support `vmsr
>> fpscr,r3' in Thumb mode
>> /tmp/ccEHiFws.s:169: Error: selected processor does not support `vmrs
>> r3,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:182: Error: selected processor does not support `vmsr
>> fpscr,r3' in Thumb mode
>> /tmp/ccEHiFws.s:217: Error: selected processor does not support `vmrs
>> r3,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:251: Error: selected processor does not support `vmrs
>> r0,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:288: Error: selected processor does not support `vmrs
>> r3,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:303: Error: selected processor does not support `vmsr
>> fpscr,r0' in Thumb mode
>> /tmp/ccEHiFws.s:340: Error: selected processor does not support `vmrs
>> r3,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:374: Error: selected processor does not support `vmrs
>> r3,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:390: Error: selected processor does not support `vmsr
>> fpscr,r3' in Thumb mode
>> /tmp/ccEHiFws.s:424: Error: selected processor does not support `vmsr
>> fpscr,r3' in Thumb mode
>> /tmp/ccEHiFws.s:457: Error: selected processor does not support `vmrs
>> r1,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:466: Error: selected processor does not support `vmsr
>> fpscr,r3' in Thumb mode
>> /tmp/ccEHiFws.s:478: Error: selected processor does not support `vmrs
>> r2,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:503: Error: selected processor does not support `vmsr
>> fpscr,r3' in Thumb mode
>> /tmp/ccEHiFws.s:543: Error: selected processor does not support `vmrs
>> r0,fpscr' in Thumb mode
>> /tmp/ccEHiFws.s:559: Error: selected processor does not support `vmsr
>> fpscr,r3' in T

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

[Gedare Bloom]

Utkarsh,

What do you mean by "This would although mean that we would have page
tables of  1MB."

Check that you use plain text when inlining a reply, or at least that you
broke the reply format.

Gedare

On Fri, May 15, 2020, 6:04 PM Utkarsh Rai  wrote:

>
>
> On Thu, May 14, 2020 at 10:23 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello Utkarsh Rai,
>>
>> On 13/05/2020 14:30, Utkarsh Rai wrote:
>> > Hello,
>> > My GSoC project,  providing thread stack protection support, has to be
>> > a user-configurable feature.
>> > My question is,  what would be the best way to implement this, my idea
>> > was to model it based on the existing system configuration
>> > , but
>> > Dr. Gedare pointed out that configuration is undergoing heavy changes
>> > and may look completely different in future releases. Kindly advise me
>> > as to what would be the best way to proceed.
>> before we start with an implementation. It would be good to define what
>> a thread stack protection support is supposed to do.
>
>
> The thread stack protection mechanism will protect against stack overflow
> errors and will completely isolate the thread stacks from each other.
> Sharing of thread stack will be possible only when the user makes explicit
> calls to do so. More details about this can be found in this thread
> .
>
>> Then there should
>> be a concept for systems with a Memory Protection Unit (MPU) and a
>> concept for systems with a Memory Management Unit (MMU). MMUs may
>> provide normal 4KiB Pages, large Pages (for example 1MiB) or something
>> more flexible. We should identify BSPs which should have support for
>> this. For each BSP should be a concept. Then we should think about how a
>> user can configure this feature.
>
> For memory protection will have a 1:1 VA-PA address translation that means
>> a 4KiB page size will be set for both the MPU and MMU, a 1:1 mapping will
>> ensure we will have to do lesser page table walks.This would although mean
>> that we would have page tables of  1MB. I will be first providing the
>> support for Armv7 based BSPs (RPi , BBB, etc. have MMU support) then when I
>> have a working example I will move on to provide the support for RISC-V.
>> which has MPU support.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

[Joel Sherrill]

On Sat, May 16, 2020 at 10:14 AM Gedare Bloom  wrote:

> Utkarsh,
>
> What do you mean by "This would although mean that we would have page
> tables of  1MB."
>
> Check that you use plain text when inlining a reply, or at least that you
> broke the reply format.
>
> Gedare
>
> On Fri, May 15, 2020, 6:04 PM Utkarsh Rai  wrote:
>
>>
>>
>> On Thu, May 14, 2020 at 10:23 AM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> Hello Utkarsh Rai,
>>>
>>> On 13/05/2020 14:30, Utkarsh Rai wrote:
>>> > Hello,
>>> > My GSoC project,  providing thread stack protection support, has to be
>>> > a user-configurable feature.
>>> > My question is,  what would be the best way to implement this, my idea
>>> > was to model it based on the existing system configuration
>>> > ,
>>> but
>>> > Dr. Gedare pointed out that configuration is undergoing heavy changes
>>> > and may look completely different in future releases. Kindly advise me
>>> > as to what would be the best way to proceed.
>>> before we start with an implementation. It would be good to define what
>>> a thread stack protection support is supposed to do.
>>
>>
>> The thread stack protection mechanism will protect against stack overflow
>> errors and will completely isolate the thread stacks from each other.
>> Sharing of thread stack will be possible only when the user makes explicit
>> calls to do so. More details about this can be found in this thread
>> .
>>
>>> Then there should
>>> be a concept for systems with a Memory Protection Unit (MPU) and a
>>> concept for systems with a Memory Management Unit (MMU). MMUs may
>>> provide normal 4KiB Pages, large Pages (for example 1MiB) or something
>>> more flexible. We should identify BSPs which should have support for
>>> this. For each BSP should be a concept. Then we should think about how a
>>> user can configure this feature.
>>
>> For memory protection will have a 1:1 VA-PA address translation that
>>> means a 4KiB page size will be set for both the MPU and MMU, a 1:1 mapping
>>> will ensure we will have to do lesser page table walks.This would although
>>> mean that we would have page tables of  1MB. I will be first providing the
>>> support for Armv7 based BSPs (RPi , BBB, etc. have MMU support) then when I
>>> have a working example I will move on to provide the support for RISC-V.
>>> which has MPU support.
>>
>>
I think Sebastian is asking exactly what I did. What are the processor
(specific CPU) requirements to support thread stack protection?

For example, to be effective, I imagine a 1MB granularity might be
sufficient to protect code versus data/bss. But it is likely insufficient
to protect thread stacks.

Similarly, a processor with a limited number of "protection areas" would be
unsuitable as a basis for implementing thread stack protection. Here I am
thinking of the PowerPC with a handful of TLB registers. You would have to
turn on paging.

This is the general guidance that needs to be provided so anyone can
evaluate how much protection they really can have on their target.

--joel

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

RTEMS Presentation at ISORC 2020 next week (online, free)

[Joel Sherrill]

Hi

Gedare and I have a presentation at IEEE ISORC 2020 (
https://isorc.github.io/2020/) next week and the program is online. The
conference was supposed to be in Nashville but it is now virtual and
FREE!!!  This is a nice conference and hopefully the free and virtual part
make it more appealing to register and listen in. Of course, there is the
added benefit of listening to Gedare present. :)

Details at https://www.rtems.org/node/133 including a link to the
conference and YouTube version of the presentation.

This is a great conference which has had multiple RTEMS papers over the
years.

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