Re: Rtems_fsmount dosfs hanging

[Andre Marques]

Hello Ritesh,

My progress on the SD card support can be found on

https://bitbucket.org/asuol/rtems-graduation-project/src/

It contains the sources and a test case (it reads a file and write 
another on the card), as well as patches so you can easily test that code.


It was based on

https://github.com/jncronin/rpi-boot/blob/master/emmc.c

and right now it may or may not work with your SD card. I got it working 
with the SD card I have used during development (4GB class 4 SanDisk SD 
card), but it does not work with the card I have now (Kingston 8GB 
microSD card on a SD adapter). I suspect this is related with the 
timeout the driver gives for each command to complete in, as it is an 
hard coded value which should be calculated by parsing the card's CSD 
register. Also the code needs some major cleanup, and some features were 
overlooked such as memory barriers.


As for SD card documentation I have used the v3 simplified specifications

SD host controller - 
https://www.sdcard.org/downloads/pls/simplified_specs/archive/partA2_300.pdf


SD physical layer - 
https://www.sdcard.org/downloads/pls/simplified_specs/archive/part1_301.pdf


Besides the broadcom datasheet.

By the way, since you replied to this thread I am not sure if I ever 
shared why it was hanging. Turns out that there was/is a conflict 
between my emmc driver and the raspberry pi clock driver. All I had to 
do was to disable the clock driver for it to work.


--André Marques.

On 08/26/14 06:38, Ritesh Harjani wrote:

Hi Andre,

I am too trying to understand SD card/MMC protocol on Raspberry pi for 
RTEMS. You said in your last mail that you have already done some 
progress on this.
Could you please share your code at some place, so that others can get 
a help from your code in case anybody else too is trying to 
understand/develop SD card support for Raspberry pi.



Thanks for the help!!
Ritesh


On Wed, May 14, 2014 at 12:30 AM, Andre Marques 
mailto:andre.lousa.marq...@gmail.com>> 
wrote:


On 05/13/14 12:15, Andrey Mozzhuhin wrote:

Do you not forget to call rtems_blkdev_request_done in read
routine of block device driver?
Also try to increase CONFIGURE_MAXIMUM_TASKS - bdbuf need some
worker tasks.


I call rtems_blkdev_request_done after each read request, and
changing CONFIGURE_MAXIMUM_TASKS to 20 (instead of 2) did not had
any impact.




>> https://github.com/jncronin/rpi-boot/blob/master/emmc.c

Hmm. Implementation specific to Raspberry Pi is not good idea. It
is better to separate MMC/SD protocol implementation and hardware
support like in FreeBSD or Linux.


Yes, the point in the end is probably to have the MMC/SD protocol
somewhere else, just like the spi-sd-card driver (SD card access
through SPI interface protocol, at c/src/libchip/i2c/spi-sd-card*).




>> Not sure how to approach this problem, as the logic seems
right. Will do more testing in the meanwhile.



Today I have re-formated the card (under Linux), and the block
data read on RPi checks with the card hexdump on Linux.

So far I tested:

- The block data that is being read, and compared with the same
block data read on Linux (small mismatch (4 bits) at the middle of
a 512 byte block before, no mismatch now)

- The request buffer contents

(http://www.rtems.org/onlinedocs/doxygen/cpukit/html/structrtems__blkdev__sg__buffer.html).
Looking at this I don't know what the User pointer is. I'm using
the buffer pointer to store my readings.

- Reading the partition table from the first block. I can read the
first block and register the card partition as a logical disk, so
reading and registering the partition table is no problem.

- Tried also a busy wait between block readings.

The result is always the same: when mounting the card partition,
it reads the first two partition blocks and then hangs.



If you get stuck share your sources and let me know.



Will try to get the code to github soon.





2014-05-13 14:03 GMT+04:00 Andre Marques
mailto:andre.lousa.marq...@gmail.com>>:

On 05/12/14 19:25, Andrey Mozzhuhin wrote:

I think you need start with simple tests without file
systems and block device driver.
Try read and write blocks with known patterns and check it
on PC and Raspberry Pi.



I have checked the data read by my emmc driver from the first
two blocks (the ones it reads) on the RPi, and compared with
an hexdump of those same two blocks on Linux, and there is a
small mismatch at the middle of the first block.

Not sure how to approach this problem, as the logic seems
right. Will do more testing in the meanwhile.



What are you use for MMC/SD protocol? Can I see it and block
device driver somewhere?


I'm porting the following code

https://github.com/jncronin/rpi-boot/blob/master/emmc.c

 

Re: [PATCH] score: Define _CPU_Start_multitasking only for LEON SPARC, not SPARC in general

[Sebastian Huber]

On 25/08/14 19:29, Joel Sherrill wrote:


On 8/25/2014 11:44 AM, Sebastian Huber wrote:

On 08/25/2014 05:04 PM, Joel Sherrill wrote:

On 8/25/2014 5:10 AM, Sebastian Huber wrote:

On 25/08/14 11:45, Daniel Cederman wrote:

---
cpukit/score/cpu/sparc/rtems/score/cpu.h |2 ++
1 file changed, 2 insertions(+)

diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h 
b/cpukit/score/cpu/sparc/rtems/score/cpu.h
index 9c38b55..d4c2ef0 100644
--- a/cpukit/score/cpu/sparc/rtems/score/cpu.h
+++ b/cpukit/score/cpu/sparc/rtems/score/cpu.h
@@ -1203,9 +1203,11 @@ register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( 
"g6" );

  void _CPU_SMP_Send_interrupt( uint32_t target_processor_index );

+  #if defined(__leon__)
  void _BSP_Start_multitasking( Context_Control *heir )
RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
  #define _CPU_Start_multitasking _BSP_Start_multitasking
+  #endif

In case it is LEON specific, then it should have a LEON specific name.


What's the overall rationale?

If its mandated by the CPU port, e.g. all the stuff defined by
no_cpu/cpu.h, then it should be _CPU_*.  In case all BSPs of a CPU port
must implement a CPU port function, then it is _BSP_*.  In case only
certain multilib variants implement it specifically, then they should
have an appropriate multilib specific prefix, e.g. _LEON3_* or
_ARMV7M_*.  Does this make sense?  Maybe we should add this stuff to the
CPU supplement.


Yeah. I get this part and we do need better rules but what's the issue
with this
one method? The ifdef made it look like only the leon flavor of RTEMS and no
others even had this method.



Actually after one night of sleep I think it makes no sense.  Now I think its 
better that all the CPU port functions should start with _CPU_*, so it is 
easier to find them and set breakpoints.


I also think that this

#define _CPU_Start_multitasking

should be changed to something like

#define CPU_HAS_DEDICATED_START_MULTITASKING (TRUE | FALSE)

to be in line with all the other CPU port variants, e.g. 
CPU_HAS_SOFTWARE_INTERRUPT_STACK etc.


--
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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Rtems_fsmount dosfs hanging

[Ritesh Harjani]

Thanks Andre,

This will be really a big help. Also, I am sure it will help anyone who
will be working over SD card/MMC interface in Raspberry pi for RTEMS.

Currently, since I don't have enough knowledge on SD spec. I am going
through the pdf that you have sent and trying to just initialize SD card on
raspberry pi.
Later I will try to read the block/sectors on SD card.


Thanks & Regards
Ritesh




On Tue, Aug 26, 2014 at 1:34 PM, Andre Marques <
andre.lousa.marq...@gmail.com> wrote:

>  Hello Ritesh,
>
> My progress on the SD card support can be found on
>
> https://bitbucket.org/asuol/rtems-graduation-project/src/
>
> It contains the sources and a test case (it reads a file and write another
> on the card), as well as patches so you can easily test that code.
>
> It was based on
>
> https://github.com/jncronin/rpi-boot/blob/master/emmc.c
>
> and right now it may or may not work with your SD card. I got it working
> with the SD card I have used during development (4GB class 4 SanDisk SD
> card), but it does not work with the card I have now (Kingston 8GB microSD
> card on a SD adapter). I suspect this is related with the timeout the
> driver gives for each command to complete in, as it is an hard coded value
> which should be calculated by parsing the card's CSD register. Also the
> code needs some major cleanup, and some features were overlooked such as
> memory barriers.
>
> As for SD card documentation I have used the v3 simplified specifications
>
> SD host controller -
> https://www.sdcard.org/downloads/pls/simplified_specs/archive/partA2_300.pdf
>
> SD physical layer -
> https://www.sdcard.org/downloads/pls/simplified_specs/archive/part1_301.pdf
>
> Besides the broadcom datasheet.
>
> By the way, since you replied to this thread I am not sure if I ever
> shared why it was hanging. Turns out that there was/is a conflict between
> my emmc driver and the raspberry pi clock driver. All I had to do was to
> disable the clock driver for it to work.
>
> --André Marques.
>
>
> On 08/26/14 06:38, Ritesh Harjani wrote:
>
> Hi Andre,
>
>  I am too trying to understand SD card/MMC protocol on Raspberry pi for
> RTEMS. You said in your last mail that you have already done some progress
> on this.
> Could you please share your code at some place, so that others can get a
> help from your code in case anybody else too is trying to
> understand/develop SD card support for Raspberry pi.
>
>
>  Thanks for the help!!
> Ritesh
>
>
> On Wed, May 14, 2014 at 12:30 AM, Andre Marques <
> andre.lousa.marq...@gmail.com> wrote:
>
>>  On 05/13/14 12:15, Andrey Mozzhuhin wrote:
>>
>>  Do you not forget to call rtems_blkdev_request_done in read routine of
>> block device driver?
>>  Also try to increase CONFIGURE_MAXIMUM_TASKS - bdbuf need some worker
>> tasks.
>>
>>
>>  I call rtems_blkdev_request_done after each read request, and changing
>> CONFIGURE_MAXIMUM_TASKS to 20 (instead of 2) did not had any impact.
>>
>>
>>
>> >> https://github.com/jncronin/rpi-boot/blob/master/emmc.c
>>
>>  Hmm. Implementation specific to Raspberry Pi is not good idea. It is
>> better to separate MMC/SD protocol implementation and hardware support like
>> in FreeBSD or Linux.
>>
>>
>>  Yes, the point in the end is probably to have the MMC/SD protocol
>> somewhere else, just like the spi-sd-card driver (SD card access through
>> SPI interface protocol, at c/src/libchip/i2c/spi-sd-card*).
>>
>>
>>
>> >> Not sure how to approach this problem, as the logic seems right. Will
>> do more testing in the meanwhile.
>>
>>
>>  Today I have re-formated the card (under Linux), and the block data read
>> on RPi checks with the card hexdump on Linux.
>>
>> So far I tested:
>>
>> - The block data that is being read, and compared with the same block
>> data read on Linux (small mismatch (4 bits) at the middle of a 512 byte
>> block before, no mismatch now)
>>
>> - The request buffer contents (
>> http://www.rtems.org/onlinedocs/doxygen/cpukit/html/structrtems__blkdev__sg__buffer.html).
>> Looking at this I don't know what the User pointer is. I'm using the buffer
>> pointer to store my readings.
>>
>> - Reading the partition table from the first block. I can read the first
>> block and register the card partition as a logical disk, so reading and
>> registering the partition table is no problem.
>>
>> - Tried also a busy wait between block readings.
>>
>> The result is always the same: when mounting the card partition, it reads
>> the first two partition blocks and then hangs.
>>
>>
>>  If you get stuck share your sources and let me know.
>>
>>
>>  Will try to get the code to github soon.
>>
>>
>>
>>
>> 2014-05-13 14:03 GMT+04:00 Andre Marques :
>>
>>>  On 05/12/14 19:25, Andrey Mozzhuhin wrote:
>>>
>>>  I think you need start with simple tests without file systems and
>>> block device driver.
>>>  Try read and write blocks with known patterns and check it on PC and
>>> Raspberry Pi.
>>>
>>>
>>>  I have checked the data read by my emmc driver from the first two
>>

Re: Rtems_fsmount dosfs hanging

[Sebastian Huber]

Hello,

I work currently on a MMC/SD driver for the DesignWare Mobile Storage Host.  I 
use the FreeBSD MMC/SD stack for this.  It is based on the USB stack library. 
I will probably publish it this week in my private Git area.


--
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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Rtems_fsmount dosfs hanging

[Ritesh Harjani]

Hi Sebastian,

You mean to say that the SD card driver for raspberry pi on RTEMS has been
already developed by you ? Which you will also be publishing by end of this
week ?


Thanks
Ritesh


On Tue, Aug 26, 2014 at 1:55 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I work currently on a MMC/SD driver for the DesignWare Mobile Storage
> Host.  I use the FreeBSD MMC/SD stack for this.  It is based on the USB
> stack library. I will probably publish it this week in my private Git area.
>
> --
> 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.
> ___
> 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: Rtems_fsmount dosfs hanging

[Sebastian Huber]

On 26/08/14 10:30, Ritesh Harjani wrote:

Hi Sebastian,

You mean to say that the SD card driver for raspberry pi on RTEMS has been
already developed by you ? Which you will also be publishing by end of this 
week ?


No, I mean that I have a port of the FreeBSD MMC/SD card stack.  The main work 
for an MMC/SD host driver is the stack.  The host specific driver then needs 
only implementations for the IOS settings and the requests.  It is similar to 
the Linux or U-Boot stack for MMC/SD cards.


--
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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS+LWIP for LPC1768 BSP

[Federico Casares]

Hi,

In the past weeks we were working on porting the last LWIP version to RTEMS
for
the LPC1768 microcontroller. Our main goal was to accomplish this with the
minimum number of changes for both projects. Fortunately, the result was
positive.

Now, we are capable of providing to the community with this new version of
the
RTEMS+LWIP port. In details:

- RTEMS: last git revision = baa3c91ecb8a3b48ef387b938fcdb6
e60b5bdc8a
- LWIP: last git revision = 63038e03055183e3bc043711ada1de3bb907e989
- LPC1768: based on MBED driver =
https://github.com/mbedmicro/mbed/tree/master/libraries/net/eth/lwip-eth/arch/TARGET_NXP


The list of changes follows:

- RTEMS OS: No changes were needed here. Despite this we will be posting a
possible improvement in the newlib maillist soon. It consist in adding the
gcc
function attribute "warn_unused_result" to the pthread_*_init functions. As
a
result, developers will be warned about checking the return value. NOTE: a
common error here could be not checking the return value, assuming a
successful
result, and trying to, for example, lock a mutex which init function has
returned ENOMEM. (We found this exact mistake in the current LWIP OS layer
implementation for Unix)

- RTEMS LPC1768_MBED BSP: We added a new section to the linker script, so we
were able to put the LWIP and driver buffers in an exact memory location
(useful
when working with DMA devices).

- RTEMS LPC1768_MBED Ethernet Driver: Based on an existing driver from
MBED, we
ported it to RTEMS. NOTE: we will be creating our own driver in the near
future.

- LWIP: As mentioned previously, we needed to put all LWIP buffers in DMA
memory
locations. Consequently, we added the "section" attribute to LWIP ram_heap
and
memp_memory buffers. Furthermore, as this is a common strategy in embedded
devices with DMA, we made it generic and we will send these changes to the
LWIP
project. Additionally, we will provide some minor adds/changes to the lwip
log
system and statistics system.

- LWIP-contrib: Some of the changes/adds were: fixing some issues related
with
posix initialization checks and allow set threads stack size.

- LWIP-test-app: A simple TCP echo server with debugging functionality
(rtems malloc statistics, rtems stack checker, lwip statistics, driver
statistics and registers dump) available.


As this new port is comprised of several patches and adds, it would be great
to have some advice in how to proceed. We can provide you with the project
as a
whole or divided into independent patches. Also, we will need to know which
parts of the port are of RTEMS interest to be submitted.

Regards.


-- 
[image: http://www.tallertechnologies.com]

Casares, Federico
Sr. Software Engineer
Taller Technologies Argentina

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/5] sptests/spcache01: Make inline assembly conditional to account for OpenRISC l.nop instruction.

[Hesham Moustafa]

Hi,

On Mon, Aug 25, 2014 at 6:15 PM, Joel Sherrill
 wrote:
> I pushed all of this set and will be testing soon.
>
Great, Thanks!

> Can you post your simulator configuration file?
>
Here it's https://github.com/heshamelmatary/or1k-rtems/blob/master/sim.cfg
Should I include it part of the or1ksim BSP directory (or anywhere else)?
> --joel
>
> On 8/22/2014 3:20 PM, Hesham ALMatary wrote:
>> ---
>>  testsuites/sptests/spcache01/init.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/testsuites/sptests/spcache01/init.c 
>> b/testsuites/sptests/spcache01/init.c
>> index 2c9d184..ad9b54f 100644
>> --- a/testsuites/sptests/spcache01/init.c
>> +++ b/testsuites/sptests/spcache01/init.c
>> @@ -27,7 +27,11 @@
>>
>>  const char rtems_test_name[] = "SPCACHE 1";
>>
>> -#define I() __asm__ volatile ("nop")
>> +#ifdef __or1k__
>> +  #define I() __asm__ volatile ("l.nop")
>> +#else
>> +  #define I() __asm__ volatile ("nop")
>> +#endif
>>
>>  #define I8() I(); I(); I(); I(); I(); I(); I(); I()
>>
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available(256) 722-9985
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/5] sptests/spcache01: Make inline assembly conditional to account for OpenRISC l.nop instruction.

[Joel Sherrill]

On 8/26/2014 8:53 AM, Hesham Moustafa wrote:
> Hi,
>
> On Mon, Aug 25, 2014 at 6:15 PM, Joel Sherrill
>  wrote:
>> I pushed all of this set and will be testing soon.
>>
> Great, Thanks!
No problem. We know this is a work in progress and it is better to
keep the delta small as progress is made.
>> Can you post your simulator configuration file?
>>
> Here it's https://github.com/heshamelmatary/or1k-rtems/blob/master/sim.cfg
> Should I include it part of the or1ksim BSP directory (or anywhere else)?
In the BSP Readme would be great.  We really need the simulator run
scripts to
support this simulator. That also captures the information.

+ rtems-testing/sim-scripts
+ rtems-tools/tester

I don't expect it to be hard to add to both once the or1ksim is built by
the RSB.

FWIW that's what I am waiting for to help debug/test if that gives you
incentive. :)

--joel
>> --joel
>>
>> On 8/22/2014 3:20 PM, Hesham ALMatary wrote:
>>> ---
>>>  testsuites/sptests/spcache01/init.c | 6 +-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/testsuites/sptests/spcache01/init.c 
>>> b/testsuites/sptests/spcache01/init.c
>>> index 2c9d184..ad9b54f 100644
>>> --- a/testsuites/sptests/spcache01/init.c
>>> +++ b/testsuites/sptests/spcache01/init.c
>>> @@ -27,7 +27,11 @@
>>>
>>>  const char rtems_test_name[] = "SPCACHE 1";
>>>
>>> -#define I() __asm__ volatile ("nop")
>>> +#ifdef __or1k__
>>> +  #define I() __asm__ volatile ("l.nop")
>>> +#else
>>> +  #define I() __asm__ volatile ("nop")
>>> +#endif
>>>
>>>  #define I8() I(); I(); I(); I(); I(); I(); I(); I()
>>>
>> --
>> Joel Sherrill, Ph.D. Director of Research & Development
>> joel.sherr...@oarcorp.comOn-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available(256) 722-9985
>>

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

Re: [PATCH 1/5] sptests/spcache01: Make inline assembly conditional to account for OpenRISC l.nop instruction.

[Hesham Moustafa]

On Tue, Aug 26, 2014 at 4:09 PM, Joel Sherrill
 wrote:
>
> On 8/26/2014 8:53 AM, Hesham Moustafa wrote:
>> Hi,
>>
>> On Mon, Aug 25, 2014 at 6:15 PM, Joel Sherrill
>>  wrote:
>>> I pushed all of this set and will be testing soon.
>>>
>> Great, Thanks!
> No problem. We know this is a work in progress and it is better to
> keep the delta small as progress is made.
>>> Can you post your simulator configuration file?
>>>
>> Here it's https://github.com/heshamelmatary/or1k-rtems/blob/master/sim.cfg
>> Should I include it part of the or1ksim BSP directory (or anywhere else)?
> In the BSP Readme would be great.  We really need the simulator run
> scripts to
> support this simulator. That also captures the information.
>
The whole configuration file (sim.cfg) content into README?
> + rtems-testing/sim-scripts
I can start with this one, would it make sense to make the or1ksim
script creates a sim.cfg file (with parameterized configurations)?
> + rtems-tools/tester
>
> I don't expect it to be hard to add to both once the or1ksim is built by
> the RSB.
>
> FWIW that's what I am waiting for to help debug/test if that gives you
> incentive. :)
>
> --joel
>>> --joel
>>>
>>> On 8/22/2014 3:20 PM, Hesham ALMatary wrote:
 ---
  testsuites/sptests/spcache01/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/testsuites/sptests/spcache01/init.c 
 b/testsuites/sptests/spcache01/init.c
 index 2c9d184..ad9b54f 100644
 --- a/testsuites/sptests/spcache01/init.c
 +++ b/testsuites/sptests/spcache01/init.c
 @@ -27,7 +27,11 @@

  const char rtems_test_name[] = "SPCACHE 1";

 -#define I() __asm__ volatile ("nop")
 +#ifdef __or1k__
 +  #define I() __asm__ volatile ("l.nop")
 +#else
 +  #define I() __asm__ volatile ("nop")
 +#endif

  #define I8() I(); I(); I(); I(); I(); I(); I(); I()

>>> --
>>> Joel Sherrill, Ph.D. Director of Research & Development
>>> joel.sherr...@oarcorp.comOn-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>> Support Available(256) 722-9985
>>>
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available(256) 722-9985
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/5] sptests/spcache01: Make inline assembly conditional to account for OpenRISC l.nop instruction.

[Joel Sherrill]

On 8/26/2014 9:38 AM, Hesham Moustafa wrote:
> On Tue, Aug 26, 2014 at 4:09 PM, Joel Sherrill
>  wrote:
>> On 8/26/2014 8:53 AM, Hesham Moustafa wrote:
>>> Hi,
>>>
>>> On Mon, Aug 25, 2014 at 6:15 PM, Joel Sherrill
>>>  wrote:
 I pushed all of this set and will be testing soon.

>>> Great, Thanks!
>> No problem. We know this is a work in progress and it is better to
>> keep the delta small as progress is made.
 Can you post your simulator configuration file?

>>> Here it's https://github.com/heshamelmatary/or1k-rtems/blob/master/sim.cfg
>>> Should I include it part of the or1ksim BSP directory (or anywhere else)?
>> In the BSP Readme would be great.  We really need the simulator run
>> scripts to
>> support this simulator. That also captures the information.
>>
> The whole configuration file (sim.cfg) content into README?
Is it too big? If so, just add a file and reference it from the readme.
>> + rtems-testing/sim-scripts
> I can start with this one, would it make sense to make the or1ksim
> script creates a sim.cfg file (with parameterized configurations)?
Look at psim or any of the skyeye based simulators. They have to create
a device
description file.
>> + rtems-tools/tester
>>
>> I don't expect it to be hard to add to both once the or1ksim is built by
>> the RSB.
>>
>> FWIW that's what I am waiting for to help debug/test if that gives you
>> incentive. :)
>>
>> --joel
 --joel

 On 8/22/2014 3:20 PM, Hesham ALMatary wrote:
> ---
>  testsuites/sptests/spcache01/init.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/testsuites/sptests/spcache01/init.c 
> b/testsuites/sptests/spcache01/init.c
> index 2c9d184..ad9b54f 100644
> --- a/testsuites/sptests/spcache01/init.c
> +++ b/testsuites/sptests/spcache01/init.c
> @@ -27,7 +27,11 @@
>
>  const char rtems_test_name[] = "SPCACHE 1";
>
> -#define I() __asm__ volatile ("nop")
> +#ifdef __or1k__
> +  #define I() __asm__ volatile ("l.nop")
> +#else
> +  #define I() __asm__ volatile ("nop")
> +#endif
>
>  #define I8() I(); I(); I(); I(); I(); I(); I(); I()
>
 --
 Joel Sherrill, Ph.D. Director of Research & Development
 joel.sherr...@oarcorp.comOn-Line Applications Research
 Ask me about RTEMS: a free RTOS  Huntsville AL 35805
 Support Available(256) 722-9985

>> --
>> Joel Sherrill, Ph.D. Director of Research & Development
>> joel.sherr...@oarcorp.comOn-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available(256) 722-9985
>>

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

[PATCH] sim-scripts: Add new or1ksim OpenRISC simulator script.

[Hesham ALMatary]

---
 sim-scripts/or1ksim.in | 155 +
 1 file changed, 155 insertions(+)
 create mode 100644 sim-scripts/or1ksim.in

diff --git a/sim-scripts/or1ksim.in b/sim-scripts/or1ksim.in
new file mode 100644
index 000..3f59e47
--- /dev/null
+++ b/sim-scripts/or1ksim.in
@@ -0,0 +1,155 @@
+#
+#  or1k/or1ksim Support 
+#
+bspSupportsGDBServerMode="yes"
+runBSP=or32-elf-sim
+bspTreeFile=sim.cfg
+
+runARGS()
+{
+  echo "-f ${bspTreeFile} ${1}"
+}
+
+checkBSPFaults()
+{
+  return 0
+}
+
+bspLimit()
+{
+  testname=$1
+  case ${testname} in
+*stackchk*)limit=5 ;;
+*fatal*)   limit=1 ;;
+*minimum*) limit=1 ;;
+*psxtime*) limit=180 ;;
+*) limit=60 ;;
+  esac
+  echo ${limit}
+}
+
+bspGeneratesGDBCommands="yes"
+
+gdbServerARGS()
+{
+  echo "-c ${bspTreeFile}"
+}
+
+bspGenerateGDBCommands()
+{
+cat 

capture engine ref_count question

[Jennifer Averett]

During discussions on capture engine modifications Daniel H.
suggested the following


> We suggest to remove the ref_count of the task structures to save

> time and locking. Otherwise we need atomic counters here?

> We suggest to free task structures when reading, by recording time of

> task deletion event we know when last event referencing the task occurred,

> when that time have passed it should be okay to free the task structure?

Can anyone see a problem with this.   My question is will this always work 
based on the zombie state of the thread?  I thought I saw
new capture tasks created during a delete when a zombie state occurred, but I 
could be incorrect on that.

It appears that because the thread was "closed", the name field is NULL when 
this happens.
We know we have seen this and it cannot occur from the Classic API. [1]

[1] This unfortunately can occur for pthreads so this may be a hole to address 
in the future.

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

[PATCH] sim-scripts: Add new or1ksim OpenRISC simulator script.

[Hesham ALMatary]

---
 sim-scripts/Makefile   |   5 +-
 sim-scripts/or1ksim.in | 155 +
 2 files changed, 159 insertions(+), 1 deletion(-)
 create mode 100644 sim-scripts/or1ksim.in

diff --git a/sim-scripts/Makefile b/sim-scripts/Makefile
index 9d9baaf..e45feae 100644
--- a/sim-scripts/Makefile
+++ b/sim-scripts/Makefile
@@ -1,6 +1,6 @@
 INSTALL_DIR=../bin
 GDBSIM_SCRIPTS=bf537Stamp ezkit533 gdbarmsim h8sim jmr3904 lm32_evr \
-  m32csim m32rsim psim sis simsh v850sim
+  m32csim m32rsim or1ksim psim sis simsh v850sim
 SKYEYE_SCRIPTS=ant5206 bf537Stamp-skyeye csb337 csb350 csb360 edb7312 \
   ezkit533-skyeye gumstix rtl22xx smdk2410 leon2-skyeye
 
@@ -130,6 +130,9 @@ m32csim m32csim-gdb: gdb-sim-run.in gdb-sim.in m32csim.in
 m32rsim m32rsim-gdb: gdb-sim-run.in gdb-sim.in m32rsim.in
./mkrun yes M32R m32r m32rsim
 
+or1ksim or1ksim-gdb: or1ksim.in
+   ./mkrun yes OR1K or1k or1ksim
+
 psim psim-gdb: gdb-sim-run.in gdb-sim.in psim.in
./mkrun yes PowerPC powerpc psim
 
diff --git a/sim-scripts/or1ksim.in b/sim-scripts/or1ksim.in
new file mode 100644
index 000..3f59e47
--- /dev/null
+++ b/sim-scripts/or1ksim.in
@@ -0,0 +1,155 @@
+#
+#  or1k/or1ksim Support 
+#
+bspSupportsGDBServerMode="yes"
+runBSP=or32-elf-sim
+bspTreeFile=sim.cfg
+
+runARGS()
+{
+  echo "-f ${bspTreeFile} ${1}"
+}
+
+checkBSPFaults()
+{
+  return 0
+}
+
+bspLimit()
+{
+  testname=$1
+  case ${testname} in
+*stackchk*)limit=5 ;;
+*fatal*)   limit=1 ;;
+*minimum*) limit=1 ;;
+*psxtime*) limit=180 ;;
+*) limit=60 ;;
+  esac
+  echo ${limit}
+}
+
+bspGeneratesGDBCommands="yes"
+
+gdbServerARGS()
+{
+  echo "-c ${bspTreeFile}"
+}
+
+bspGenerateGDBCommands()
+{
+cat 

Re: [PATCH] sim-scripts: Add new or1ksim OpenRISC simulator script.

[Hesham Moustafa]

Hi,

The first patch did not include the Makefile modifications, the
previous reply did.

Thanks,
Hesham

On Tue, Aug 26, 2014 at 7:59 PM, Hesham ALMatary
 wrote:
> ---
>  sim-scripts/Makefile   |   5 +-
>  sim-scripts/or1ksim.in | 155 
> +
>  2 files changed, 159 insertions(+), 1 deletion(-)
>  create mode 100644 sim-scripts/or1ksim.in
>
> diff --git a/sim-scripts/Makefile b/sim-scripts/Makefile
> index 9d9baaf..e45feae 100644
> --- a/sim-scripts/Makefile
> +++ b/sim-scripts/Makefile
> @@ -1,6 +1,6 @@
>  INSTALL_DIR=../bin
>  GDBSIM_SCRIPTS=bf537Stamp ezkit533 gdbarmsim h8sim jmr3904 lm32_evr \
> -  m32csim m32rsim psim sis simsh v850sim
> +  m32csim m32rsim or1ksim psim sis simsh v850sim
>  SKYEYE_SCRIPTS=ant5206 bf537Stamp-skyeye csb337 csb350 csb360 edb7312 \
>ezkit533-skyeye gumstix rtl22xx smdk2410 leon2-skyeye
>
> @@ -130,6 +130,9 @@ m32csim m32csim-gdb: gdb-sim-run.in gdb-sim.in m32csim.in
>  m32rsim m32rsim-gdb: gdb-sim-run.in gdb-sim.in m32rsim.in
> ./mkrun yes M32R m32r m32rsim
>
> +or1ksim or1ksim-gdb: or1ksim.in
> +   ./mkrun yes OR1K or1k or1ksim
> +
>  psim psim-gdb: gdb-sim-run.in gdb-sim.in psim.in
> ./mkrun yes PowerPC powerpc psim
>
> diff --git a/sim-scripts/or1ksim.in b/sim-scripts/or1ksim.in
> new file mode 100644
> index 000..3f59e47
> --- /dev/null
> +++ b/sim-scripts/or1ksim.in
> @@ -0,0 +1,155 @@
> +#
> +#  or1k/or1ksim Support
> +#
> +bspSupportsGDBServerMode="yes"
> +runBSP=or32-elf-sim
> +bspTreeFile=sim.cfg
> +
> +runARGS()
> +{
> +  echo "-f ${bspTreeFile} ${1}"
> +}
> +
> +checkBSPFaults()
> +{
> +  return 0
> +}
> +
> +bspLimit()
> +{
> +  testname=$1
> +  case ${testname} in
> +*stackchk*)limit=5 ;;
> +*fatal*)   limit=1 ;;
> +*minimum*) limit=1 ;;
> +*psxtime*) limit=180 ;;
> +*) limit=60 ;;
> +  esac
> +  echo ${limit}
> +}
> +
> +bspGeneratesGDBCommands="yes"
> +
> +gdbServerARGS()
> +{
> +  echo "-c ${bspTreeFile}"
> +}
> +
> +bspGenerateGDBCommands()
> +{
> +cat < +tar remote :50001
> +EOF
> +}
> +
> +### Generate the or1ksim device tree based upon the type of application 
> being run
> +bspGenerateDeviceTree()
> +{
> +cat < +section memory
> +  name =  "RAM"
> +  random_seed = 12345
> +  type= random
> +  ce   =  0
> +  mc   =  0
> +  baseaddr = 0x
> +  size = 0x0800
> +  delayr   =  1
> +  delayw   =  2
> +end
> +
> +section immu
> +  enabled = 0
> +  nsets = 64
> +  nways = 1
> +  pagesize = 8192
> +  hitdelay = 0
> +  missdelay = 0
> +end
> +
> +section dmmu
> +  enabled = 0
> +  nsets = 64
> +  nways = 1
> +  pagesize = 8192
> +  hitdelay = 0
> +  missdelay = 0
> +end
> +section mc
> +  enabled = 0
> +  baseaddr = 0x9000
> +  POC = 0x000a /* 32 bit SSRAM */
> +  index = 0
> +end
> +
> +section ic
> +  enabled   =   0
> +  nsets = 256
> +  nways =   1
> +  blocksize =  16
> +  hitdelay  =  20
> +  missdelay =  20
> +end
> +
> +section dc
> +  enabled = 0
> +  nsets = 256
> +  nways = 1
> +  blocksize = 16
> +  load_hitdelay = 0
> +  load_missdelay = 0
> +  store_hitdelay = 0
> +  store_missdelay = 0
> +end
> +
> +section pic
> +  enabled = 1
> +  edge_trigger = 1
> +end
> +
> +section sim
> +  verbose  =  1
> +  debug=  0
> +  profile  =  0
> +  history  =  0
> +  clkcycle = 10ns  /* 100MHz clock */
> +end
> +
> +section VAPI
> +  enabled = 1
> +  server_port = 5
> +  log_enabled = 1
> +  vapi_log_file = "vapi.log"
> +end
> +
> +section cpu
> +  ver = 0x12
> +  cfg = 0x00
> +  rev = 0x0001
> +  superscalar = 0
> +  hazards = 0
> +  dependstats = 0
> +  sbuf_len = 100
> +end
> +
> +section debug
> + enabled = 1
> + rsp_enabled = 1
> + rsp_port = 50001
> +end
> +
> +section uart
> +  enabled  = 1
> +  baseaddr = 0x9000
> +  #channel = "xterm"
> +  channel = "file:uart0.rx,uart0.tx"
> +  irq = 2
> +  16550= 1
> +end
> +
> +section pm
> +  enabled = 1
> +end
> +EOF
> +}
> +bspGeneratesDeviceTree="yes"
> --
> 1.9.3
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS+LWIP for LPC1768 BSP

[Joel Sherrill]

First. Thanks for the work and taking the time and effort to
submit it.

Specifics below, but the general answer is to submit all RTEMS
changes as reviewable patches to devel@rtems.org. We can
then review them and get them merged. This will leave us
with just the LWIP changes.

Then we can review those and begin to work with that community
to get them merged.


On 8/26/2014 6:22 AM, Federico Casares wrote:
> Hi,
>
> In the past weeks we were working on porting the last LWIP version to
> RTEMS for
> the LPC1768 microcontroller. Our main goal was to accomplish this with the
> minimum number of changes for both projects. Fortunately, the result was
> positive.
>
> Now, we are capable of providing to the community with this new
> version of the
> RTEMS+LWIP port. In details:
>
> - RTEMS: last git revision = baa3c91ecb8a3b48ef387b938fcdb6
> e60b5bdc8a
> - LWIP: last git revision = 63038e03055183e3bc043711ada1de3bb907e989
> - LPC1768: based on MBED driver =
> https://github.com/mbedmicro/mbed/tree/master/libraries/net/eth/lwip-eth/arch/TARGET_NXP
>
>
> The list of changes follows:
>
> - RTEMS OS: No changes were needed here. Despite this we will be posting a
> possible improvement in the newlib maillist soon. It consist in adding
> the gcc
> function attribute "warn_unused_result" to the pthread_*_init
> functions. As a
> result, developers will be warned about checking the return value. NOTE: a
> common error here could be not checking the return value, assuming a
> successful
> result, and trying to, for example, lock a mutex which init function has
> returned ENOMEM. (We found this exact mistake in the current LWIP OS layer
> implementation for Unix)
>
FWIW the gcc C++ library adapters for threading do not check the results
from
those operations. This is an open sore spot for us.
> - RTEMS LPC1768_MBED BSP: We added a new section to the linker script,
> so we
> were able to put the LWIP and driver buffers in an exact memory
> location (useful
> when working with DMA devices).
>
This sounds like a discrete patch to submit to devel@rtems.org.
> - RTEMS LPC1768_MBED Ethernet Driver: Based on an existing driver from
> MBED, we
> ported it to RTEMS. NOTE: we will be creating our own driver in the
> near future.
>
What is the license of these drivers?
> - LWIP: As mentioned previously, we needed to put all LWIP buffers in
> DMA memory
> locations. Consequently, we added the "section" attribute to LWIP
> ram_heap and
> memp_memory buffers. Furthermore, as this is a common strategy in embedded
> devices with DMA, we made it generic and we will send these changes to
> the LWIP
> project. Additionally, we will provide some minor adds/changes to the
> lwip log
> system and statistics system.
>
OK. Those are obviously their's to review. :)
> - LWIP-contrib: Some of the changes/adds were: fixing some issues
> related with
> posix initialization checks and allow set threads stack size.
>
What all specific to RTEMS was added? Do you want RTEMS Community review
on this?

Is there a readme/howto to configure and use LWIP on RTEMS?

It sounds like the port is largely BSP independent. Is this the case?
> - LWIP-test-app: A simple TCP echo server with debugging functionality
> (rtems malloc statistics, rtems stack checker, lwip statistics, driver
> statistics and registers dump) available.
>
Very cool!

How large was the code/data/RAM use of the test application?
>
> As this new port is comprised of several patches and adds, it would be
> great
> to have some advice in how to proceed. We can provide you with the
> project as a
> whole or divided into independent patches. Also, we will need to know
> which
> parts of the port are of RTEMS interest to be submitted.
>
RTEMS needs to nibble and digest the RTEMS stuff. That sounds pretty easy.

Then we can help or at least track and provide help getting the LWIP port
reviewed and merged by them.
> Regards.
>
>
> -- 
> http://www.tallertechnologies.com 
> Casares, Federico
> Sr. Software Engineer
> Taller Technologies Argentina
>
> San Lorenzo 47, 3rd Floor, Office 5
> Córdoba, Argentina

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

Re: [PATCH] sim-scripts: Add new or1ksim OpenRISC simulator script.

[Joel Sherrill]

This looks good except that it is missing a comment for the commit.

Can you add that and resubmit?

Thanks.
On 8/26/2014 12:59 PM, Hesham ALMatary wrote:
> ---
>  sim-scripts/Makefile   |   5 +-
>  sim-scripts/or1ksim.in | 155 
> +
>  2 files changed, 159 insertions(+), 1 deletion(-)
>  create mode 100644 sim-scripts/or1ksim.in
>
> diff --git a/sim-scripts/Makefile b/sim-scripts/Makefile
> index 9d9baaf..e45feae 100644
> --- a/sim-scripts/Makefile
> +++ b/sim-scripts/Makefile
> @@ -1,6 +1,6 @@
>  INSTALL_DIR=../bin
>  GDBSIM_SCRIPTS=bf537Stamp ezkit533 gdbarmsim h8sim jmr3904 lm32_evr \
> -  m32csim m32rsim psim sis simsh v850sim
> +  m32csim m32rsim or1ksim psim sis simsh v850sim
>  SKYEYE_SCRIPTS=ant5206 bf537Stamp-skyeye csb337 csb350 csb360 edb7312 \
>ezkit533-skyeye gumstix rtl22xx smdk2410 leon2-skyeye
>  
> @@ -130,6 +130,9 @@ m32csim m32csim-gdb: gdb-sim-run.in gdb-sim.in m32csim.in
>  m32rsim m32rsim-gdb: gdb-sim-run.in gdb-sim.in m32rsim.in
>   ./mkrun yes M32R m32r m32rsim
>  
> +or1ksim or1ksim-gdb: or1ksim.in
> + ./mkrun yes OR1K or1k or1ksim
> +
>  psim psim-gdb: gdb-sim-run.in gdb-sim.in psim.in
>   ./mkrun yes PowerPC powerpc psim
>  
> diff --git a/sim-scripts/or1ksim.in b/sim-scripts/or1ksim.in
> new file mode 100644
> index 000..3f59e47
> --- /dev/null
> +++ b/sim-scripts/or1ksim.in
> @@ -0,0 +1,155 @@
> +#
> +#  or1k/or1ksim Support 
> +#
> +bspSupportsGDBServerMode="yes"
> +runBSP=or32-elf-sim
> +bspTreeFile=sim.cfg
> +
> +runARGS()
> +{
> +  echo "-f ${bspTreeFile} ${1}"
> +}
> +
> +checkBSPFaults()
> +{
> +  return 0
> +}
> +
> +bspLimit()
> +{
> +  testname=$1
> +  case ${testname} in
> +*stackchk*)limit=5 ;;
> +*fatal*)   limit=1 ;;
> +*minimum*) limit=1 ;;
> +*psxtime*) limit=180 ;;
> +*) limit=60 ;;
> +  esac
> +  echo ${limit}
> +}
> +
> +bspGeneratesGDBCommands="yes"
> +
> +gdbServerARGS()
> +{
> +  echo "-c ${bspTreeFile}"
> +}
> +
> +bspGenerateGDBCommands()
> +{
> +cat < +tar remote :50001
> +EOF
> +}
> +
> +### Generate the or1ksim device tree based upon the type of application 
> being run
> +bspGenerateDeviceTree()
> +{
> +cat < +section memory
> +  name =  "RAM"
> +  random_seed = 12345
> +  type= random
> +  ce   =  0
> +  mc   =  0
> +  baseaddr = 0x
> +  size = 0x0800
> +  delayr   =  1
> +  delayw   =  2
> +end
> +
> +section immu
> +  enabled = 0
> +  nsets = 64
> +  nways = 1
> +  pagesize = 8192
> +  hitdelay = 0
> +  missdelay = 0
> +end
> +
> +section dmmu
> +  enabled = 0
> +  nsets = 64
> +  nways = 1
> +  pagesize = 8192
> +  hitdelay = 0
> +  missdelay = 0
> +end
> +section mc
> +  enabled = 0 
> +  baseaddr = 0x9000
> +  POC = 0x000a /* 32 bit SSRAM */
> +  index = 0
> +end
> +
> +section ic
> +  enabled   =   0 
> +  nsets = 256
> +  nways =   1
> +  blocksize =  16
> +  hitdelay  =  20
> +  missdelay =  20
> +end
> +
> +section dc
> +  enabled = 0
> +  nsets = 256
> +  nways = 1
> +  blocksize = 16
> +  load_hitdelay = 0
> +  load_missdelay = 0
> +  store_hitdelay = 0
> +  store_missdelay = 0
> +end
> +
> +section pic
> +  enabled = 1
> +  edge_trigger = 1
> +end
> +
> +section sim
> +  verbose  =  1 
> +  debug=  0 
> +  profile  =  0
> +  history  =  0
> +  clkcycle = 10ns/* 100MHz clock */
> +end
> +
> +section VAPI
> +  enabled = 1 
> +  server_port = 5
> +  log_enabled = 1
> +  vapi_log_file = "vapi.log"
> +end
> +
> +section cpu
> +  ver = 0x12
> +  cfg = 0x00
> +  rev = 0x0001
> +  superscalar = 0
> +  hazards = 0
> +  dependstats = 0
> +  sbuf_len = 100 
> +end
> +
> +section debug
> + enabled = 1 
> + rsp_enabled = 1
> + rsp_port = 50001
> +end
> +
> +section uart
> +  enabled  = 1
> +  baseaddr = 0x9000
> +  #channel = "xterm"
> +  channel = "file:uart0.rx,uart0.tx"
> +  irq = 2
> +  16550= 1
> +end
> +
> +section pm
> +  enabled = 1
> +end
> +EOF
> +}
> +bspGeneratesDeviceTree="yes"

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

[PATCH] sim-scripts: Add new or1ksim OpenRISC simulator script.

[Hesham ALMatary]

This patch adds support to run or1ksim and GDB; both of them run
separately and GDB is remotely attached to or1ksim via RSP protocol. It's 
intended to run the new or1ksim/OpenRISC BSP applications. or1ksim script
runs the simulator after generating a configuration file that specifies 
the HW features/configurations of or1ksim BSP, while or1ksim-gdb script 
runs or1k-rtems*-gdb and remotely attaches to or1ksim. Both or1ksim and 
or1ksim-gdb are passed a full path to the or1ksim BSP executable program.

---
 sim-scripts/Makefile   |   5 +-
 sim-scripts/or1ksim.in | 155 +
 2 files changed, 159 insertions(+), 1 deletion(-)
 create mode 100644 sim-scripts/or1ksim.in

diff --git a/sim-scripts/Makefile b/sim-scripts/Makefile
index 9d9baaf..e45feae 100644
--- a/sim-scripts/Makefile
+++ b/sim-scripts/Makefile
@@ -1,6 +1,6 @@
 INSTALL_DIR=../bin
 GDBSIM_SCRIPTS=bf537Stamp ezkit533 gdbarmsim h8sim jmr3904 lm32_evr \
-  m32csim m32rsim psim sis simsh v850sim
+  m32csim m32rsim or1ksim psim sis simsh v850sim
 SKYEYE_SCRIPTS=ant5206 bf537Stamp-skyeye csb337 csb350 csb360 edb7312 \
   ezkit533-skyeye gumstix rtl22xx smdk2410 leon2-skyeye
 
@@ -130,6 +130,9 @@ m32csim m32csim-gdb: gdb-sim-run.in gdb-sim.in m32csim.in
 m32rsim m32rsim-gdb: gdb-sim-run.in gdb-sim.in m32rsim.in
./mkrun yes M32R m32r m32rsim
 
+or1ksim or1ksim-gdb: or1ksim.in
+   ./mkrun yes OR1K or1k or1ksim
+
 psim psim-gdb: gdb-sim-run.in gdb-sim.in psim.in
./mkrun yes PowerPC powerpc psim
 
diff --git a/sim-scripts/or1ksim.in b/sim-scripts/or1ksim.in
new file mode 100644
index 000..3f59e47
--- /dev/null
+++ b/sim-scripts/or1ksim.in
@@ -0,0 +1,155 @@
+#
+#  or1k/or1ksim Support 
+#
+bspSupportsGDBServerMode="yes"
+runBSP=or32-elf-sim
+bspTreeFile=sim.cfg
+
+runARGS()
+{
+  echo "-f ${bspTreeFile} ${1}"
+}
+
+checkBSPFaults()
+{
+  return 0
+}
+
+bspLimit()
+{
+  testname=$1
+  case ${testname} in
+*stackchk*)limit=5 ;;
+*fatal*)   limit=1 ;;
+*minimum*) limit=1 ;;
+*psxtime*) limit=180 ;;
+*) limit=60 ;;
+  esac
+  echo ${limit}
+}
+
+bspGeneratesGDBCommands="yes"
+
+gdbServerARGS()
+{
+  echo "-c ${bspTreeFile}"
+}
+
+bspGenerateGDBCommands()
+{
+cat 

Re: [PATCH] sim-scripts: Add new or1ksim OpenRISC simulator script.

[Hesham Moustafa]

Hi,

On Tue, Aug 26, 2014 at 8:47 PM, Joel Sherrill
 wrote:
> This looks good except that it is missing a comment for the commit.
>
> Can you add that and resubmit?
>
Done. Is it Ok to submit the sim.cfg and README change for or1ksim BSP too?
> Thanks.
> On 8/26/2014 12:59 PM, Hesham ALMatary wrote:
>> ---
>>  sim-scripts/Makefile   |   5 +-
>>  sim-scripts/or1ksim.in | 155 
>> +
>>  2 files changed, 159 insertions(+), 1 deletion(-)
>>  create mode 100644 sim-scripts/or1ksim.in
>>
>> diff --git a/sim-scripts/Makefile b/sim-scripts/Makefile
>> index 9d9baaf..e45feae 100644
>> --- a/sim-scripts/Makefile
>> +++ b/sim-scripts/Makefile
>> @@ -1,6 +1,6 @@
>>  INSTALL_DIR=../bin
>>  GDBSIM_SCRIPTS=bf537Stamp ezkit533 gdbarmsim h8sim jmr3904 lm32_evr \
>> -  m32csim m32rsim psim sis simsh v850sim
>> +  m32csim m32rsim or1ksim psim sis simsh v850sim
>>  SKYEYE_SCRIPTS=ant5206 bf537Stamp-skyeye csb337 csb350 csb360 edb7312 \
>>ezkit533-skyeye gumstix rtl22xx smdk2410 leon2-skyeye
>>
>> @@ -130,6 +130,9 @@ m32csim m32csim-gdb: gdb-sim-run.in gdb-sim.in m32csim.in
>>  m32rsim m32rsim-gdb: gdb-sim-run.in gdb-sim.in m32rsim.in
>>   ./mkrun yes M32R m32r m32rsim
>>
>> +or1ksim or1ksim-gdb: or1ksim.in
>> + ./mkrun yes OR1K or1k or1ksim
>> +
>>  psim psim-gdb: gdb-sim-run.in gdb-sim.in psim.in
>>   ./mkrun yes PowerPC powerpc psim
>>
>> diff --git a/sim-scripts/or1ksim.in b/sim-scripts/or1ksim.in
>> new file mode 100644
>> index 000..3f59e47
>> --- /dev/null
>> +++ b/sim-scripts/or1ksim.in
>> @@ -0,0 +1,155 @@
>> +#
>> +#  or1k/or1ksim Support
>> +#
>> +bspSupportsGDBServerMode="yes"
>> +runBSP=or32-elf-sim
>> +bspTreeFile=sim.cfg
>> +
>> +runARGS()
>> +{
>> +  echo "-f ${bspTreeFile} ${1}"
>> +}
>> +
>> +checkBSPFaults()
>> +{
>> +  return 0
>> +}
>> +
>> +bspLimit()
>> +{
>> +  testname=$1
>> +  case ${testname} in
>> +*stackchk*)limit=5 ;;
>> +*fatal*)   limit=1 ;;
>> +*minimum*) limit=1 ;;
>> +*psxtime*) limit=180 ;;
>> +*) limit=60 ;;
>> +  esac
>> +  echo ${limit}
>> +}
>> +
>> +bspGeneratesGDBCommands="yes"
>> +
>> +gdbServerARGS()
>> +{
>> +  echo "-c ${bspTreeFile}"
>> +}
>> +
>> +bspGenerateGDBCommands()
>> +{
>> +cat <> +tar remote :50001
>> +EOF
>> +}
>> +
>> +### Generate the or1ksim device tree based upon the type of application 
>> being run
>> +bspGenerateDeviceTree()
>> +{
>> +cat <> +section memory
>> +  name =  "RAM"
>> +  random_seed = 12345
>> +  type= random
>> +  ce   =  0
>> +  mc   =  0
>> +  baseaddr = 0x
>> +  size = 0x0800
>> +  delayr   =  1
>> +  delayw   =  2
>> +end
>> +
>> +section immu
>> +  enabled = 0
>> +  nsets = 64
>> +  nways = 1
>> +  pagesize = 8192
>> +  hitdelay = 0
>> +  missdelay = 0
>> +end
>> +
>> +section dmmu
>> +  enabled = 0
>> +  nsets = 64
>> +  nways = 1
>> +  pagesize = 8192
>> +  hitdelay = 0
>> +  missdelay = 0
>> +end
>> +section mc
>> +  enabled = 0
>> +  baseaddr = 0x9000
>> +  POC = 0x000a /* 32 bit SSRAM */
>> +  index = 0
>> +end
>> +
>> +section ic
>> +  enabled   =   0
>> +  nsets = 256
>> +  nways =   1
>> +  blocksize =  16
>> +  hitdelay  =  20
>> +  missdelay =  20
>> +end
>> +
>> +section dc
>> +  enabled = 0
>> +  nsets = 256
>> +  nways = 1
>> +  blocksize = 16
>> +  load_hitdelay = 0
>> +  load_missdelay = 0
>> +  store_hitdelay = 0
>> +  store_missdelay = 0
>> +end
>> +
>> +section pic
>> +  enabled = 1
>> +  edge_trigger = 1
>> +end
>> +
>> +section sim
>> +  verbose  =  1
>> +  debug=  0
>> +  profile  =  0
>> +  history  =  0
>> +  clkcycle = 10ns/* 100MHz clock */
>> +end
>> +
>> +section VAPI
>> +  enabled = 1
>> +  server_port = 5
>> +  log_enabled = 1
>> +  vapi_log_file = "vapi.log"
>> +end
>> +
>> +section cpu
>> +  ver = 0x12
>> +  cfg = 0x00
>> +  rev = 0x0001
>> +  superscalar = 0
>> +  hazards = 0
>> +  dependstats = 0
>> +  sbuf_len = 100
>> +end
>> +
>> +section debug
>> + enabled = 1
>> + rsp_enabled = 1
>> + rsp_port = 50001
>> +end
>> +
>> +section uart
>> +  enabled  = 1
>> +  baseaddr = 0x9000
>> +  #channel = "xterm"
>> +  channel = "file:uart0.rx,uart0.tx"
>> +  irq = 2
>> +  16550= 1
>> +end
>> +
>> +section pm
>> +  enabled = 1
>> +end
>> +EOF
>> +}
>> +bspGeneratesDeviceTree="yes"
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available(256) 722-9985
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Using rtl-host in covor - some questions

[Joel Sherrill]

Chris.. ping?

Do we need to remove things from rtems-testing since the
official version is not in rtems-tools?

And what about the rtl-host build dependency? Is it time to
move it as well?

On 8/25/2014 6:17 AM, Krzysztof Mięsowicz wrote:
>
>
>
> 2014-08-24 5:32 GMT+02:00 Chris Johns  >:
>
> On 23/08/2014 2:54 pm, Krzysztof Mięsowicz wrote:
>
>
> Where should I place this image? Is there any RTEMS ftp or
> something
> like this where could I put it, or maybe should I just push it
> to some
> Dropbox or sth and download it with RSB?
>
>
> There is ftp.rtems.org  and that is where
> the image can be placed. Maybe a binary under rtems-tools.git. I
> am not sure. 
>
>
> I need to add something like '%fetch' to the RSB to allow a
> configuration file the ability to do this.
>
>
> A binary under rtems-tools repo is probably simpler for now - it could
> be placed in the same directory as other coverage-related files from
> rtems-testing repo like some css files, and configuration file
> introduced by me.
>  
>
>
>
> Chris, should I move rtl-host repo into rtems-tools or wait
> for your
> action?
>
>
> There are a couple if issues to resolve. First is how to merge the
> commit history from the rtl-host repo into the rtems-tools repo. I
> would like the commit history to be present so the history of who
> has worked on the code is maintained. Second, what is the
> structure in the rtems-tools repo and how to we integrate the
> various bits under a waf build tree ?
>
>
> About the structure - on my PC I copied rtl-host directory just into
> rtems-tools directory, so tree output is as follows:
>
> rtems-tools
> ├── doc
> │   ├── asciidoc
> │   └── images
> ├── rtemstoolkit
> ├── rtl-host
> │   ├── build-linux2
> │   ├── elftoolchain
> │   ├── libiberty
> │   ├── waf-tools
> │   └── win32
> ├── tester
> │   ├── config
> │   ├── covoar
> │   ├── rt
> │   └── rtems
> └── tools
> ├── 4.10
> ├── 4.11
> ├── 4.9
> └── libffi
>
>
> Then, I was able to point from covoar/wscript to rtl-host/build-linux2
> dir where librld.a is placed, and link with this library. I think this
> is not perfect solution, because rtl-host must be built independently
> before covoar - but it works for now. You can find diff for covoar
> wscript attached.
>

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

Re: [PATCH] sim-scripts: Add new or1ksim OpenRISC simulator script.

[Joel Sherrill]

On 8/26/2014 2:06 PM, Hesham Moustafa wrote:
> Hi,
>
> On Tue, Aug 26, 2014 at 8:47 PM, Joel Sherrill
>  wrote:
>> This looks good except that it is missing a comment for the commit.
>>
>> Can you add that and resubmit?
>>
> Done. Is it Ok to submit the sim.cfg and README change for or1ksim BSP too?
Yes. and the sim.cfg should be its own file. It is large. :)
>> Thanks.
>> On 8/26/2014 12:59 PM, Hesham ALMatary wrote:
>>> ---
>>>  sim-scripts/Makefile   |   5 +-
>>>  sim-scripts/or1ksim.in | 155 
>>> +
>>>  2 files changed, 159 insertions(+), 1 deletion(-)
>>>  create mode 100644 sim-scripts/or1ksim.in
>>>
>>> diff --git a/sim-scripts/Makefile b/sim-scripts/Makefile
>>> index 9d9baaf..e45feae 100644
>>> --- a/sim-scripts/Makefile
>>> +++ b/sim-scripts/Makefile
>>> @@ -1,6 +1,6 @@
>>>  INSTALL_DIR=../bin
>>>  GDBSIM_SCRIPTS=bf537Stamp ezkit533 gdbarmsim h8sim jmr3904 lm32_evr \
>>> -  m32csim m32rsim psim sis simsh v850sim
>>> +  m32csim m32rsim or1ksim psim sis simsh v850sim
>>>  SKYEYE_SCRIPTS=ant5206 bf537Stamp-skyeye csb337 csb350 csb360 edb7312 \
>>>ezkit533-skyeye gumstix rtl22xx smdk2410 leon2-skyeye
>>>
>>> @@ -130,6 +130,9 @@ m32csim m32csim-gdb: gdb-sim-run.in gdb-sim.in 
>>> m32csim.in
>>>  m32rsim m32rsim-gdb: gdb-sim-run.in gdb-sim.in m32rsim.in
>>>   ./mkrun yes M32R m32r m32rsim
>>>
>>> +or1ksim or1ksim-gdb: or1ksim.in
>>> + ./mkrun yes OR1K or1k or1ksim
>>> +
>>>  psim psim-gdb: gdb-sim-run.in gdb-sim.in psim.in
>>>   ./mkrun yes PowerPC powerpc psim
>>>
>>> diff --git a/sim-scripts/or1ksim.in b/sim-scripts/or1ksim.in
>>> new file mode 100644
>>> index 000..3f59e47
>>> --- /dev/null
>>> +++ b/sim-scripts/or1ksim.in
>>> @@ -0,0 +1,155 @@
>>> +#
>>> +#  or1k/or1ksim Support
>>> +#
>>> +bspSupportsGDBServerMode="yes"
>>> +runBSP=or32-elf-sim
>>> +bspTreeFile=sim.cfg
>>> +
>>> +runARGS()
>>> +{
>>> +  echo "-f ${bspTreeFile} ${1}"
>>> +}
>>> +
>>> +checkBSPFaults()
>>> +{
>>> +  return 0
>>> +}
>>> +
>>> +bspLimit()
>>> +{
>>> +  testname=$1
>>> +  case ${testname} in
>>> +*stackchk*)limit=5 ;;
>>> +*fatal*)   limit=1 ;;
>>> +*minimum*) limit=1 ;;
>>> +*psxtime*) limit=180 ;;
>>> +*) limit=60 ;;
>>> +  esac
>>> +  echo ${limit}
>>> +}
>>> +
>>> +bspGeneratesGDBCommands="yes"
>>> +
>>> +gdbServerARGS()
>>> +{
>>> +  echo "-c ${bspTreeFile}"
>>> +}
>>> +
>>> +bspGenerateGDBCommands()
>>> +{
>>> +cat <>> +tar remote :50001
>>> +EOF
>>> +}
>>> +
>>> +### Generate the or1ksim device tree based upon the type of application 
>>> being run
>>> +bspGenerateDeviceTree()
>>> +{
>>> +cat <>> +section memory
>>> +  name =  "RAM"
>>> +  random_seed = 12345
>>> +  type= random
>>> +  ce   =  0
>>> +  mc   =  0
>>> +  baseaddr = 0x
>>> +  size = 0x0800
>>> +  delayr   =  1
>>> +  delayw   =  2
>>> +end
>>> +
>>> +section immu
>>> +  enabled = 0
>>> +  nsets = 64
>>> +  nways = 1
>>> +  pagesize = 8192
>>> +  hitdelay = 0
>>> +  missdelay = 0
>>> +end
>>> +
>>> +section dmmu
>>> +  enabled = 0
>>> +  nsets = 64
>>> +  nways = 1
>>> +  pagesize = 8192
>>> +  hitdelay = 0
>>> +  missdelay = 0
>>> +end
>>> +section mc
>>> +  enabled = 0
>>> +  baseaddr = 0x9000
>>> +  POC = 0x000a /* 32 bit SSRAM */
>>> +  index = 0
>>> +end
>>> +
>>> +section ic
>>> +  enabled   =   0
>>> +  nsets = 256
>>> +  nways =   1
>>> +  blocksize =  16
>>> +  hitdelay  =  20
>>> +  missdelay =  20
>>> +end
>>> +
>>> +section dc
>>> +  enabled = 0
>>> +  nsets = 256
>>> +  nways = 1
>>> +  blocksize = 16
>>> +  load_hitdelay = 0
>>> +  load_missdelay = 0
>>> +  store_hitdelay = 0
>>> +  store_missdelay = 0
>>> +end
>>> +
>>> +section pic
>>> +  enabled = 1
>>> +  edge_trigger = 1
>>> +end
>>> +
>>> +section sim
>>> +  verbose  =  1
>>> +  debug=  0
>>> +  profile  =  0
>>> +  history  =  0
>>> +  clkcycle = 10ns/* 100MHz clock */
>>> +end
>>> +
>>> +section VAPI
>>> +  enabled = 1
>>> +  server_port = 5
>>> +  log_enabled = 1
>>> +  vapi_log_file = "vapi.log"
>>> +end
>>> +
>>> +section cpu
>>> +  ver = 0x12
>>> +  cfg = 0x00
>>> +  rev = 0x0001
>>> +  superscalar = 0
>>> +  hazards = 0
>>> +  dependstats = 0
>>> +  sbuf_len = 100
>>> +end
>>> +
>>> +section debug
>>> + enabled = 1
>>> + rsp_enabled = 1
>>> + rsp_port = 50001
>>> +end
>>> +
>>> +section uart
>>> +  enabled  = 1
>>> +  baseaddr = 0x9000
>>> +  #channel = "xterm"
>>> +  channel = "file:uart0.rx,uart0.tx"
>>> +  irq = 2
>>> +  16550= 1
>>> +end
>>> +
>>> +section pm
>>> +  enabled = 1
>>> +end
>>> +EOF
>>> +}
>>> +bspGeneratesDeviceTree="yes"
>> --
>> Joel Sherrill, Ph.D. Director of Research & Development
>> joel.sherr...@oarcorp.comOn-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available(256) 722-9985
>>

-- 
Joel Sherrill, Ph.D. Director of Research & 

RE: [PATCH] score: Define _CPU_Start_multitasking only for LEON SPARC, not SPARC in general

[Jennifer Averett]

I'm getting the following error when building the head with smp enabled.

sparc-rtems4.11-gcc -B../../../../../sis/lib/ -specs bsp_specs -qrtems 
-mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall 
-Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes 
-Wnested-externs  -Wl,--gc-sections  -mcpu=cypress   -o hello.exe init.o 
../../../../../sis/lib/librtemscpu.a(libscore_a-threadstartmultitasking.o): In 
function `_Thread_Start_multitasking':
/home/jennifer/smp/b-sis/sparc-rtems4.11/c/sis/cpukit/score/../../../../../../rtems/c/src/../../cpukit/score/src/threadstartmultitasking.c:78:
 undefined reference to `_BSP_Start_multitasking'
collect2: error: ld returned 1 exit status
gmake[6]: *** [hello.exe] Error 1
gmake[6]: Leaving directory 
`/home/jennifer/smp/b-sis/sparc-rtems4.11/c/sis/testsuites/samples/hello'
gmake[5]: *** [all-local] Error 1


> -Original Message-
> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian
> Huber
> Sent: Tuesday, August 26, 2014 3:12 AM
> To: Joel Sherrill; Daniel Cederman; devel@rtems.org
> Subject: Re: [PATCH] score: Define _CPU_Start_multitasking only for LEON
> SPARC, not SPARC in general
> 
> On 25/08/14 19:29, Joel Sherrill wrote:
> >
> > On 8/25/2014 11:44 AM, Sebastian Huber wrote:
> >> On 08/25/2014 05:04 PM, Joel Sherrill wrote:
> >>> On 8/25/2014 5:10 AM, Sebastian Huber wrote:
>  On 25/08/14 11:45, Daniel Cederman wrote:
> > ---
> > cpukit/score/cpu/sparc/rtems/score/cpu.h |2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h
> > b/cpukit/score/cpu/sparc/rtems/score/cpu.h
> > index 9c38b55..d4c2ef0 100644
> > --- a/cpukit/score/cpu/sparc/rtems/score/cpu.h
> > +++ b/cpukit/score/cpu/sparc/rtems/score/cpu.h
> > @@ -1203,9 +1203,11 @@ register struct Per_CPU_Control
> > *_SPARC_Per_CPU_current __asm__( "g6" );
> >
> >   void _CPU_SMP_Send_interrupt( uint32_t
> > target_processor_index );
> >
> > +  #if defined(__leon__)
> >   void _BSP_Start_multitasking( Context_Control *heir )
> > RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
> >   #define _CPU_Start_multitasking _BSP_Start_multitasking
> > +  #endif
>  In case it is LEON specific, then it should have a LEON specific name.
> 
> >>> What's the overall rationale?
> >> If its mandated by the CPU port, e.g. all the stuff defined by
> >> no_cpu/cpu.h, then it should be _CPU_*.  In case all BSPs of a CPU
> >> port must implement a CPU port function, then it is _BSP_*.  In case
> >> only certain multilib variants implement it specifically, then they
> >> should have an appropriate multilib specific prefix, e.g. _LEON3_* or
> >> _ARMV7M_*.  Does this make sense?  Maybe we should add this stuff to
> >> the CPU supplement.
> >>
> > Yeah. I get this part and we do need better rules but what's the issue
> > with this one method? The ifdef made it look like only the leon flavor
> > of RTEMS and no others even had this method.
> >
> 
> Actually after one night of sleep I think it makes no sense.  Now I think its
> better that all the CPU port functions should start with _CPU_*, so it is 
> easier
> to find them and set breakpoints.
> 
> I also think that this
> 
> #define _CPU_Start_multitasking
> 
> should be changed to something like
> 
> #define CPU_HAS_DEDICATED_START_MULTITASKING (TRUE | FALSE)
> 
> to be in line with all the other CPU port variants, e.g.
> CPU_HAS_SOFTWARE_INTERRUPT_STACK etc.
> 
> --
> 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.
> ___
> 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

[PATCH] Add or1ksim (sim.cfg) configuration file and edit README.

[Hesham ALMatary]

OpenRISC/or1ksim BSP: The new sim.cfg file configures or1ksim emulator with HW
capabilities that the current RTEMS/or1ksim BSP supports.

README: HOWTO run the or1ksim simulator.
---
 c/src/lib/libbsp/or1k/or1ksim/README  |  20 ++-
 c/src/lib/libbsp/or1k/or1ksim/sim.cfg | 104 ++
 2 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 c/src/lib/libbsp/or1k/or1ksim/sim.cfg

diff --git a/c/src/lib/libbsp/or1k/or1ksim/README 
b/c/src/lib/libbsp/or1k/or1ksim/README
index 43b4703..dfa3cb1 100644
--- a/c/src/lib/libbsp/or1k/or1ksim/README
+++ b/c/src/lib/libbsp/or1k/or1ksim/README
@@ -14,4 +14,22 @@ Configuration file "sim.cfg" should be provided for complex 
board
 configurations at the current directory (which you run or1ksim from) or at
 ~/.or1k/
 
-sim -f sim.cfg hello.exe
+The current sim.cfg file that configures or1ksim emulator to RTEMS/or1ksim BSP
+is at the same directory as this README. You can also use or1ksim script from 
+rtems-tools/sim-scripts.
+
+From command line type:
+
+sim -f sim.cfg $PATH_TO_RTEMS_EXE
+
+or (if you use a stable or1ksim release)
+
+or32-elf-sim -f sim.cfg $PATH_TO_RTEMS_EXE
+
+from sim-scripts:
+
+or1ksim $PATH_TO_RTEMS_EXE
+
+and then attach GDB to or1ksim from another terminal by running 
+
+or1ksim-gdb $PATH_TO_RTEMS_EXE
diff --git a/c/src/lib/libbsp/or1k/or1ksim/sim.cfg 
b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg
new file mode 100644
index 000..cfc3d2b
--- /dev/null
+++ b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg
@@ -0,0 +1,104 @@
+section memory
+  name =  "RAM"
+  random_seed = 12345
+  type= random
+  ce   =  0
+  mc   =  0
+  baseaddr = 0x
+  size = 0x0800
+  delayr   =  1
+  delayw   =  2
+end
+
+section immu
+  enabled = 0
+  nsets = 64
+  nways = 1
+  pagesize = 8192
+  hitdelay = 0
+  missdelay = 0
+end
+
+section dmmu
+  enabled = 0
+  nsets = 64
+  nways = 1
+  pagesize = 8192
+  hitdelay = 0
+  missdelay = 0
+end
+section mc
+  enabled = 0 
+  baseaddr = 0x9000
+  POC = 0x000a /* 32 bit SSRAM */
+  index = 0
+end
+
+section ic
+  enabled   =   0 
+  nsets = 256
+  nways =   1
+  blocksize =  16
+  hitdelay  =  20
+  missdelay =  20
+end
+
+section dc
+  enabled = 0
+  nsets = 256
+  nways = 1
+  blocksize = 16
+  load_hitdelay = 0
+  load_missdelay = 0
+  store_hitdelay = 0
+  store_missdelay = 0
+end
+
+section pic
+  enabled = 1
+  edge_trigger = 1
+end
+
+section sim
+  verbose  =  1 
+  debug=  0 
+  profile  =  0
+  history  =  0
+  clkcycle = 10ns  /* 100MHz clock */
+end
+
+section VAPI
+  enabled = 1 
+  server_port = 5
+  log_enabled = 1
+  vapi_log_file = "vapi.log"
+end
+
+section cpu
+  ver = 0x12
+  cfg = 0x00
+  rev = 0x0001
+  superscalar = 0
+  hazards = 0
+  dependstats = 0
+  sbuf_len = 100 
+end
+
+section debug
+ enabled = 1 
+ rsp_enabled = 1
+ rsp_port = 50001
+end
+
+section uart
+  enabled  = 1
+  baseaddr = 0x9000
+ #channel = "xterm"
+  channel = "file:uart0.rx,uart0.tx"
+  irq = 2
+  16550= 1
+end
+
+section pm
+  enabled = 1
+end
-- 
1.9.3

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

[PATCH 1/2] capture: change to use malloc/vs/rtems_workspace_alloc.

[Jennifer Averett]

Since neither malloc nor rtems_workspace_alloc should be called during a
task switch the capture task was changed to manage a pool of capture
tasks that is allocated at open.
---
 cpukit/libmisc/capture/capture-cli.c | 32 ---
 cpukit/libmisc/capture/capture.c | 79 +---
 cpukit/libmisc/capture/capture.h | 40 ++
 3 files changed, 113 insertions(+), 38 deletions(-)

diff --git a/cpukit/libmisc/capture/capture-cli.c 
b/cpukit/libmisc/capture/capture-cli.c
index 9c978d2..5e4f9b4 100644
--- a/cpukit/libmisc/capture/capture-cli.c
+++ b/cpukit/libmisc/capture/capture-cli.c
@@ -60,7 +60,7 @@ static volatile int cli_load_thread_active;
  *
  */
 
-static const char* open_usage = "usage: copen [-i] size\n";
+static const char* open_usage = "usage: copen [-i] size tasks\n";
 
 static void
 rtems_capture_cli_open (intargc,
@@ -68,7 +68,8 @@ rtems_capture_cli_open (int
argc,
 const rtems_monitor_command_arg_t* command_arg 
RC_UNUSED,
 bool   verbose RC_UNUSED)
 {
-  uint32_t  size = 0;
+  uint32_t  size[2] = {0,0};
+  int   i = 0;
   bool  enable = false;
   rtems_status_code sc;
   int   arg;
@@ -90,17 +91,21 @@ rtems_capture_cli_open (int
argc,
 }
 else
 {
-  size = strtoul (argv[arg], 0, 0);
-
-  if (size < 100)
-  {
-fprintf (stdout, "error: size must be greater than or equal to 100\n");
-return;
+  if (i>1)
+fprintf (stdout, "warning: extra parameter %s ignored\n", argv[arg]);
+  else {
+size[i] = strtoul (argv[arg], 0, 0);
+if ((i==0) && (size[i] < 100))
+{
+  fprintf (stdout, "error: size must be greater than or equal to 
100\n");
+  return;
+}
+i++;
   }
 }
   }
 
-  sc = rtems_capture_open (size, capture_timestamp);
+  sc = rtems_capture_open (size[0], size[1], capture_timestamp);
 
   if (sc != RTEMS_SUCCESSFUL)
   {
@@ -1431,17 +1436,16 @@ rtems_capture_cli_trace_records (int
argc,
 {
   if (event & 1)
   {
+char name[5];
+rtems_capture_name_to_string( rec->task->name, 5, name );
+ 
 rtems_capture_cli_print_timestamp (rec->time);
 if (last_t)
   diff = rec->time - last_t;
 last_t = rec->time;
 fprintf (stdout, " %9" PRId64 " ", diff);
 rtems_monitor_dump_id (rtems_capture_task_id (rec->task));
-fprintf (stdout, " %c%c%c%c",
- (char) (rec->task->name >> 24) & 0xff,
- (char) (rec->task->name >> 16) & 0xff,
- (char) (rec->task->name >> 8) & 0xff,
- (char) (rec->task->name >> 0) & 0xff);
+fprintf (stdout, " %s", name );
 fprintf (stdout, " %3" PRId32 " %3" PRId32 " %s\n",
 (rec->events >> RTEMS_CAPTURE_REAL_PRIORITY_EVENT) & 0xff,
 (rec->events >> RTEMS_CAPTURE_CURR_PRIORITY_EVENT) & 0xff,
diff --git a/cpukit/libmisc/capture/capture.c b/cpukit/libmisc/capture/capture.c
index 9ec07b8..6ede91d 100644
--- a/cpukit/libmisc/capture/capture.c
+++ b/cpukit/libmisc/capture/capture.c
@@ -108,6 +108,8 @@ static rtems_capture_record_t*  capture_in;
 static uint32_t capture_out;
 static uint32_t capture_flags;
 static rtems_capture_task_t*capture_tasks;
+static rtems_capture_task_t*capture_task_pool;
+static rtems_capture_task_t*capture_task_next;
 static rtems_capture_control_t* capture_controls;
 static int  capture_extension_index;
 static rtems_id capture_id;
@@ -151,6 +153,20 @@ static const char* capture_event_text[] =
   "TIMESTAMP"
 };
 
+static inline void
+rtems_capture_add_task_to_pool(
+  rtems_capture_task_t* task
+)
+{
+  if (task) {
+task->forw= capture_task_next;
+if (task->forw)
+  task->forw->back = task;
+task->back= NULL;
+capture_task_next = task;
+  }
+}
+
 /*
  * This function returns the current time. If a handler is provided
  * by the user get the time from that.
@@ -339,9 +355,9 @@ rtems_capture_create_control (rtems_name name, rtems_id id)
 
   if (control == NULL)
   {
-bool ok = rtems_workspace_allocate (sizeof (*control), (void **) &control);
+control = malloc (sizeof (*control));
 
-if (!ok)
+if (control == NULL)
 {
   capture_flags |= RTEMS_CAPTURE_NO_MEMORY;
   return NULL;
@@ -386,16 +402,18 @@ rtems_capture_create_capture_task (rtems_tcb* new_task)
   rtems_capture_control_t* control;
   rtems_name   name;
   rtems_capture_time_t time;
-  bool ok;
-
-  ok = rtems_workspace_allocate (sizeof (*task), 

[PATCH 2/2] capture01: Add multiple calls of the test so that several create/delete of tasks is called.

[Jennifer Averett]

---
 testsuites/libtests/capture01/init.c   | 33 -
 testsuites/libtests/capture01/system.h |  2 +-
 testsuites/libtests/capture01/test1.c  | 10 +-
 3 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/testsuites/libtests/capture01/init.c 
b/testsuites/libtests/capture01/init.c
index fc06597..fa92cb8 100644
--- a/testsuites/libtests/capture01/init.c
+++ b/testsuites/libtests/capture01/init.c
@@ -113,7 +113,7 @@ static void cwlist ()
   }
 }
 
-static void ctrace()
+void ctrace()
 {
   rtems_status_code   sc;
   boolcsv = false;
@@ -159,7 +159,6 @@ static void ctrace()
  (rec->events >> RTEMS_CAPTURE_CURR_PRIORITY_EVENT) & 0xff,
  (rec->events >> RTEMS_CAPTURE_EVENT_START),
  (uint64_t) rec->time);
-  else
   {
 uint32_t event;
 int  e;
@@ -170,12 +169,10 @@ static void ctrace()
 {
   if (event & 1)
   {
+char name[5];
+rtems_capture_name_to_string( rec->task->name, 5, name );
 rtems_monitor_dump_id (rtems_capture_task_id (rec->task));
-fprintf (stdout, " %c%c%c%c",
- (char) (rec->task->name >> 24) & 0xff,
- (char) (rec->task->name >> 16) & 0xff,
- (char) (rec->task->name >> 8) & 0xff,
- (char) (rec->task->name >> 0) & 0xff);
+fprintf (stdout, " %5s", name );
 fprintf (stdout, " %3" PRId32 " %3" PRId32 " %s\n",
 (rec->events >> RTEMS_CAPTURE_REAL_PRIORITY_EVENT) & 0xff,
 (rec->events >> RTEMS_CAPTURE_CURR_PRIORITY_EVENT) & 0xff,
@@ -215,7 +212,7 @@ rtems_task Init(
   rtems_task_set_priority(RTEMS_SELF, 20, &old_priority);
   rtems_task_mode(RTEMS_PREEMPT,  RTEMS_PREEMPT_MASK, &old_mode);
 
-  sc = rtems_capture_open (5000, NULL);
+  sc = rtems_capture_open (5000, 20, NULL);
   ASSERT_SC(sc);
 
   sc = rtems_capture_watch_ceiling (100);
@@ -242,10 +239,28 @@ rtems_task Init(
   sc = rtems_capture_control (true);
   ASSERT_SC(sc);
 
-  capture_test_1();
+  capture_test_1(0);
+
+  ctrace();
+  ctrace();
+
+  capture_test_1(1);
+  ctrace();
+
+  capture_test_1(3);
+
+  ctrace();
+  ctrace();
+
+  capture_test_1(4);
+  capture_test_1(5);
+  capture_test_1(6);
   
   ctrace();
   ctrace();
+  ctrace();
+  ctrace();
+  ctrace();
 
   rtems_test_end();
   exit( 0 );
diff --git a/testsuites/libtests/capture01/system.h 
b/testsuites/libtests/capture01/system.h
index 62c221f..e586b30 100644
--- a/testsuites/libtests/capture01/system.h
+++ b/testsuites/libtests/capture01/system.h
@@ -20,7 +20,7 @@ rtems_task Init(
   rtems_task_argument argument
 );
 
-void capture_test_1(void);
+void capture_test_1(int start);
 
 /* configuration information */
 
diff --git a/testsuites/libtests/capture01/test1.c 
b/testsuites/libtests/capture01/test1.c
index 5e334fc..63de241 100644
--- a/testsuites/libtests/capture01/test1.c
+++ b/testsuites/libtests/capture01/test1.c
@@ -109,7 +109,7 @@ capture_CT1c (rtems_task_argument arg)
   rtems_task_delete (RTEMS_SELF);
 }
 
-void capture_test_1 ()
+void capture_test_1 (int start)
 {
   rtems_status_code sc;
   rtems_namename;
@@ -121,7 +121,7 @@ void capture_test_1 ()
   capture_CT1b_deleted = 0;
   capture_CT1c_deleted = 0;
 
-  name = rtems_build_name('C', 'T', 'm', '1');
+  name = rtems_build_name('C', 'T', 'm', '1'+start);
 
   sc = rtems_semaphore_create (name, 1,
RTEMS_PRIORITY | RTEMS_BINARY_SEMAPHORE |
@@ -135,7 +135,7 @@ void capture_test_1 ()
 return;
   }
 
-  name = rtems_build_name('C', 'T', '1', 'a');
+  name = rtems_build_name('C', 'T', '1'+start, 'a');
 
   sc = rtems_task_create (name, 102, 2 * 1024,
   RTEMS_NO_FLOATING_POINT | RTEMS_LOCAL,
@@ -163,7 +163,7 @@ void capture_test_1 ()
 
   capture_wait (1000);
 
-  name = rtems_build_name('C', 'T', '1', 'b');
+  name = rtems_build_name('C', 'T', '1'+start, 'b');
 
   sc = rtems_task_create (name, 101, 2 * 1024,
   RTEMS_NO_FLOATING_POINT | RTEMS_LOCAL,
@@ -193,7 +193,7 @@ void capture_test_1 ()
 
   capture_wait (1000);
 
-  name = rtems_build_name('C', 'T', '1', 'c');
+  name = rtems_build_name('C', 'T', '1'+start, 'c');
 
   sc = rtems_task_create (name, 100, 2 * 1024,
   RTEMS_NO_FLOATING_POINT | RTEMS_LOCAL,
-- 
1.8.1.4

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

RE: [PATCH 3/4] capture: Remove nested rtems_interrupt_lock_acquire calls.

[Jennifer Averett]

Has there been any work done on adding an
additional lock which allows nesting?   I'm going through
a list of capture engine modifications and the addition of an
SMP nesting interrupt lock would be appreciated

Thanks

Jennifer

> -Original Message-
> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Chris Johns
> Sent: Friday, July 11, 2014 6:08 PM
> To: devel@rtems.org
> Subject: Re: [PATCH 3/4] capture: Remove nested
> rtems_interrupt_lock_acquire calls.
> 
> On 11/07/2014 4:59 pm, Sebastian Huber wrote:
> > On 2014-07-11 04:08, Chris Johns wrote:
> >> On 10/07/2014 11:44 pm, Jennifer Averett wrote:
> >>> Use of the cenable command was resulting in a lock in
> >>> rtems_interrupt_lock_acquire due to nesting.
> >>
> >> I am rejecting this change. RTEMS as an RTOS should provide support
> >> to handle this case in a consistent manner in SMP and non-SMP builds
> >> of the code.
> >>
> >> The change highlights an issue in RTEMS's locking support. This code
> >> works on a non-SMP build because the rtems_interrupt_lock_acquire
> >> nests and this is the functionality of the call it replaces. It is
> >> dangerous to promote rtems_interrupt_lock_acquire and
> >> rtems_interrupt_lock_release as replacements for old interrupt
> >> disable and enable calls if they are not functionally the same as the
> >> code they replace and functionally the same on SMP and non-SMP
> >> builds.
> >>
> >> I understand the current implementation of the rtems_interrupt_lock_*
> >> code is optimised for performance and adding nesting checks adds
> >> overhead however I feel we should considering providing support with
> >> no-nesting versions for code that can support this. The pattern in
> >> the capture engine this change addresses is a common one and forcing
> >> users to remember this issue and then rewrite exist code to manage it
> >> is not being a helpful RTOS.
> >
> > I am fine with adding additional locks which allow nesting,
> 
> Great.
> 
> > but the
> > default lock used a the lowest level must not allow nesting.
> 
> I agree.
> 
> Chris
> 
> ___
> 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: [PATCH] sim-scripts: Add new or1ksim OpenRISC simulator script.

[Joel Sherrill]

This is merged.

You should now be able to run all tests with or1ksim `find . -name "*.exe"`

But you may also want to specify the time limit argument (-l seconds) since
many may not run correctly.

If you know abort/error messages where the simulator reports that the code
barfs but doesn't exit, those can be added.

Next RSB support for or1ksim. :)

And them rtems-tester

--joel
On 8/26/2014 2:09 PM, Joel Sherrill wrote:
> On 8/26/2014 2:06 PM, Hesham Moustafa wrote:
>> Hi,
>>
>> On Tue, Aug 26, 2014 at 8:47 PM, Joel Sherrill
>>  wrote:
>>> This looks good except that it is missing a comment for the commit.
>>>
>>> Can you add that and resubmit?
>>>
>> Done. Is it Ok to submit the sim.cfg and README change for or1ksim BSP too?
> Yes. and the sim.cfg should be its own file. It is large. :)
>>> Thanks.
>>> On 8/26/2014 12:59 PM, Hesham ALMatary wrote:
 ---
  sim-scripts/Makefile   |   5 +-
  sim-scripts/or1ksim.in | 155 
 +
  2 files changed, 159 insertions(+), 1 deletion(-)
  create mode 100644 sim-scripts/or1ksim.in

 diff --git a/sim-scripts/Makefile b/sim-scripts/Makefile
 index 9d9baaf..e45feae 100644
 --- a/sim-scripts/Makefile
 +++ b/sim-scripts/Makefile
 @@ -1,6 +1,6 @@
  INSTALL_DIR=../bin
  GDBSIM_SCRIPTS=bf537Stamp ezkit533 gdbarmsim h8sim jmr3904 lm32_evr \
 -  m32csim m32rsim psim sis simsh v850sim
 +  m32csim m32rsim or1ksim psim sis simsh v850sim
  SKYEYE_SCRIPTS=ant5206 bf537Stamp-skyeye csb337 csb350 csb360 edb7312 \
ezkit533-skyeye gumstix rtl22xx smdk2410 leon2-skyeye

 @@ -130,6 +130,9 @@ m32csim m32csim-gdb: gdb-sim-run.in gdb-sim.in 
 m32csim.in
  m32rsim m32rsim-gdb: gdb-sim-run.in gdb-sim.in m32rsim.in
   ./mkrun yes M32R m32r m32rsim

 +or1ksim or1ksim-gdb: or1ksim.in
 + ./mkrun yes OR1K or1k or1ksim
 +
  psim psim-gdb: gdb-sim-run.in gdb-sim.in psim.in
   ./mkrun yes PowerPC powerpc psim

 diff --git a/sim-scripts/or1ksim.in b/sim-scripts/or1ksim.in
 new file mode 100644
 index 000..3f59e47
 --- /dev/null
 +++ b/sim-scripts/or1ksim.in
 @@ -0,0 +1,155 @@
 +#
 +#  or1k/or1ksim Support
 +#
 +bspSupportsGDBServerMode="yes"
 +runBSP=or32-elf-sim
 +bspTreeFile=sim.cfg
 +
 +runARGS()
 +{
 +  echo "-f ${bspTreeFile} ${1}"
 +}
 +
 +checkBSPFaults()
 +{
 +  return 0
 +}
 +
 +bspLimit()
 +{
 +  testname=$1
 +  case ${testname} in
 +*stackchk*)limit=5 ;;
 +*fatal*)   limit=1 ;;
 +*minimum*) limit=1 ;;
 +*psxtime*) limit=180 ;;
 +*) limit=60 ;;
 +  esac
 +  echo ${limit}
 +}
 +
 +bspGeneratesGDBCommands="yes"
 +
 +gdbServerARGS()
 +{
 +  echo "-c ${bspTreeFile}"
 +}
 +
 +bspGenerateGDBCommands()
 +{
 +cat <>>> +tar remote :50001
 +EOF
 +}
 +
 +### Generate the or1ksim device tree based upon the type of application 
 being run
 +bspGenerateDeviceTree()
 +{
 +cat <>>> +section memory
 +  name =  "RAM"
 +  random_seed = 12345
 +  type= random
 +  ce   =  0
 +  mc   =  0
 +  baseaddr = 0x
 +  size = 0x0800
 +  delayr   =  1
 +  delayw   =  2
 +end
 +
 +section immu
 +  enabled = 0
 +  nsets = 64
 +  nways = 1
 +  pagesize = 8192
 +  hitdelay = 0
 +  missdelay = 0
 +end
 +
 +section dmmu
 +  enabled = 0
 +  nsets = 64
 +  nways = 1
 +  pagesize = 8192
 +  hitdelay = 0
 +  missdelay = 0
 +end
 +section mc
 +  enabled = 0
 +  baseaddr = 0x9000
 +  POC = 0x000a /* 32 bit SSRAM */
 +  index = 0
 +end
 +
 +section ic
 +  enabled   =   0
 +  nsets = 256
 +  nways =   1
 +  blocksize =  16
 +  hitdelay  =  20
 +  missdelay =  20
 +end
 +
 +section dc
 +  enabled = 0
 +  nsets = 256
 +  nways = 1
 +  blocksize = 16
 +  load_hitdelay = 0
 +  load_missdelay = 0
 +  store_hitdelay = 0
 +  store_missdelay = 0
 +end
 +
 +section pic
 +  enabled = 1
 +  edge_trigger = 1
 +end
 +
 +section sim
 +  verbose  =  1
 +  debug=  0
 +  profile  =  0
 +  history  =  0
 +  clkcycle = 10ns/* 100MHz clock */
 +end
 +
 +section VAPI
 +  enabled = 1
 +  server_port = 5
 +  log_enabled = 1
 +  vapi_log_file = "vapi.log"
 +end
 +
 +section cpu
 +  ver = 0x12
 +  cfg = 0x00
 +  rev = 0x0001
 +  superscalar = 0
 +  hazards = 0
 +  dependstats = 0
 +  sbuf_len = 100
 +end
 +
 +section debug
 + enabled = 1
 + rsp_enabled = 1
 + rsp_port =

Re: [PATCH] Add or1ksim (sim.cfg) configuration file and edit README.

[Joel Sherrill]

Now committed.

Thanks.
On 8/26/2014 2:42 PM, Hesham ALMatary wrote:
> OpenRISC/or1ksim BSP: The new sim.cfg file configures or1ksim emulator with HW
> capabilities that the current RTEMS/or1ksim BSP supports.
>
> README: HOWTO run the or1ksim simulator.
> ---
>  c/src/lib/libbsp/or1k/or1ksim/README  |  20 ++-
>  c/src/lib/libbsp/or1k/or1ksim/sim.cfg | 104 
> ++
>  2 files changed, 123 insertions(+), 1 deletion(-)
>  create mode 100644 c/src/lib/libbsp/or1k/or1ksim/sim.cfg
>
> diff --git a/c/src/lib/libbsp/or1k/or1ksim/README 
> b/c/src/lib/libbsp/or1k/or1ksim/README
> index 43b4703..dfa3cb1 100644
> --- a/c/src/lib/libbsp/or1k/or1ksim/README
> +++ b/c/src/lib/libbsp/or1k/or1ksim/README
> @@ -14,4 +14,22 @@ Configuration file "sim.cfg" should be provided for 
> complex board
>  configurations at the current directory (which you run or1ksim from) or at
>  ~/.or1k/
>  
> -sim -f sim.cfg hello.exe
> +The current sim.cfg file that configures or1ksim emulator to RTEMS/or1ksim 
> BSP
> +is at the same directory as this README. You can also use or1ksim script 
> from 
> +rtems-tools/sim-scripts.
> +
> +From command line type:
> +
> +sim -f sim.cfg $PATH_TO_RTEMS_EXE
> +
> +or (if you use a stable or1ksim release)
> +
> +or32-elf-sim -f sim.cfg $PATH_TO_RTEMS_EXE
> +
> +from sim-scripts:
> +
> +or1ksim $PATH_TO_RTEMS_EXE
> +
> +and then attach GDB to or1ksim from another terminal by running 
> +
> +or1ksim-gdb $PATH_TO_RTEMS_EXE
> diff --git a/c/src/lib/libbsp/or1k/or1ksim/sim.cfg 
> b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg
> new file mode 100644
> index 000..cfc3d2b
> --- /dev/null
> +++ b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg
> @@ -0,0 +1,104 @@
> +section memory
> +  name =  "RAM"
> +  random_seed = 12345
> +  type= random
> +  ce   =  0
> +  mc   =  0
> +  baseaddr = 0x
> +  size = 0x0800
> +  delayr   =  1
> +  delayw   =  2
> +end
> +
> +section immu
> +  enabled = 0
> +  nsets = 64
> +  nways = 1
> +  pagesize = 8192
> +  hitdelay = 0
> +  missdelay = 0
> +end
> +
> +section dmmu
> +  enabled = 0
> +  nsets = 64
> +  nways = 1
> +  pagesize = 8192
> +  hitdelay = 0
> +  missdelay = 0
> +end
> +section mc
> +  enabled = 0 
> +  baseaddr = 0x9000
> +  POC = 0x000a /* 32 bit SSRAM */
> +  index = 0
> +end
> +
> +section ic
> +  enabled   =   0 
> +  nsets = 256
> +  nways =   1
> +  blocksize =  16
> +  hitdelay  =  20
> +  missdelay =  20
> +end
> +
> +section dc
> +  enabled = 0
> +  nsets = 256
> +  nways = 1
> +  blocksize = 16
> +  load_hitdelay = 0
> +  load_missdelay = 0
> +  store_hitdelay = 0
> +  store_missdelay = 0
> +end
> +
> +section pic
> +  enabled = 1
> +  edge_trigger = 1
> +end
> +
> +section sim
> +  verbose  =  1 
> +  debug=  0 
> +  profile  =  0
> +  history  =  0
> +  clkcycle = 10ns/* 100MHz clock */
> +end
> +
> +section VAPI
> +  enabled = 1 
> +  server_port = 5
> +  log_enabled = 1
> +  vapi_log_file = "vapi.log"
> +end
> +
> +section cpu
> +  ver = 0x12
> +  cfg = 0x00
> +  rev = 0x0001
> +  superscalar = 0
> +  hazards = 0
> +  dependstats = 0
> +  sbuf_len = 100 
> +end
> +
> +section debug
> + enabled = 1 
> + rsp_enabled = 1
> + rsp_port = 50001
> +end
> +
> +section uart
> +  enabled  = 1
> +  baseaddr = 0x9000
> + #channel = "xterm"
> +  channel = "file:uart0.rx,uart0.tx"
> +  irq = 2
> +  16550= 1
> +end
> +
> +section pm
> +  enabled = 1
> +end

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

Re: capture engine ref_count question

[Chris Johns]

On 27/08/2014 3:50 am, Jennifer Averett wrote:


 > We suggest to remove the ref_count of the task structures to save
 > time and locking. Otherwise we need atomic counters here?


You need a means of tracking the logged references to the task data in 
the trace log. The log can exist well past the life time of the task and 
the data.



 > We suggest to free task structures when reading, by recording time of
 > task deletion event we know when last event referencing the task
occurred,


I do not like this approach.


 > when that time have passed it should be okay to free the task structure?

Can anyone see a problem with this.   My question is will this always
work based on the zombie state of the thread?  I thought I saw


You cannot remove the ref_counts without an equivalent. The data is 
referenced beyond the life of a task.


Another approach could involve adding the task data to the trace buffer 
when the first reference to the task is added to the trace buffer. You 
would add the task data tagging it with some sort of "id". When added 
events related to the task the "id" is used. The trace buffer decoder 
extracts the task data building a suitable table to decode the following 
"id" references. There is a small extra bump filling the trace buffer 
with the task details but this is the cost of tracing in software. This 
approach helps solves the problem of off board streaming of the trace data.


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

Re: [PATCH 1/2] capture: change to use malloc/vs/rtems_workspace_alloc.

[Chris Johns]

On 27/08/2014 6:16 am, Jennifer Averett wrote:

Since neither malloc nor rtems_workspace_alloc should be called during a
task switch the capture task was changed to manage a pool of capture
tasks that is allocated at open.


Maybe the locking issue should be resolved first. For example the 
approach I outlined in the other thread may remove the need to manage 
task data in the capture engine and generally improve the design. For 
example the "id" could be held in the TCB.


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

Re: Using rtl-host in covor - some questions

[Chris Johns]

On 27/08/2014 5:07 am, Joel Sherrill wrote:

Chris.. ping?


I am looking at this. It will take some time to sort out. I suggest 
changes be committed to covoar assuming the current rtl-host code and if 
someone needs to built it they copy the code in. I can clean up the 
building as I sort out the merge.




Do we need to remove things from rtems-testing since the
official version is not in rtems-tools?



Is the rtems-testing version of the code being updated ?


And what about the rtl-host build dependency? Is it time to
move it as well?


Yes. I need to figure out how to do this. The rtl-host code has the 
library and then the actual tools and this may be separated. I also need 
to get the code into a structure that lets waf manage it and I this is 
what I need to look at.


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