On 24/07/15 21:55, Rohini Kulkarni wrote:
Hi,
I have attached the report containing outputs of arm-rtems4.11-size
and arm-rtems4.11-nm -S.
From arm-rtems4.11-nm -S I don't see how memset() is accessing .text
section. The start and end values for both are not overlapping.
Maybe this patch
Hello Rohini,
please use the devel list.
On 28/07/15 07:41, Rohini Kulkarni wrote:
Hi,
I wish to understand where the interprocessor interrupts are used
during the boot process. During final initialization of SMP I can see
rtems_interrupt_handler_install(
ARM_GIC_IRQ_SGI_0,
"IPI
- Chris Johns schrieb:
On 28/07/2015 5:51 am, Joel Sherrill wrote:
> This file is RTEMS specific and I am OK with it.
Do we have tests in RTEMS for this new API ?
This is a new API to RTEMS even if it is viewed as "internal" and the
RTEMS project should treat it like any other of the APIs
- Chris Johns schrieb:
> On 28/07/2015 6:01 am, Sebastian Huber wrote:
> >
> > - Gedare Bloom schrieb:
> >> Extrapolating a bit, we would have:
> >> 4.11.0 release series (following old conventions)
> >> 5.0 next development version, no release
> >> 5.1 next release, with 5.2, 5.3, 5.4
Hello Qiao Yang,
On Saturday 25 of July 2015 14:53:35 QIAO YANG wrote:
> Hi Pavel Pisa,
>
> I've added the auto-configuration for fb section in mmu table.
> I reserve a section at the end of mmu table, make the table non-const to
> avoid errors, allocate fb before mmu initialization and fill in th
On 28/07/2015 5:51 am, Joel Sherrill wrote:
> This file is RTEMS specific and I am OK with it.
Do we have tests in RTEMS for this new API ?
This is a new API to RTEMS even if it is viewed as "internal" and the
RTEMS project should treat it like any other of the APIs it supports, ie
tests and docu
Hello Rohini and Gedare,
On Friday 24 of July 2015 15:33:03 Gedare Bloom wrote:
> What are the values of bsp_section_bss_begin, and bsp_section_bss_size?
>
> Apparently, the memset is trying to write into the .text (code)
> section, which is a very bad thing to do indeed.
>
Qiao Yang in RPi 1 BSP
On 28/07/2015 6:01 am, Sebastian Huber wrote:
>
> - Gedare Bloom schrieb:
>> Extrapolating a bit, we would have:
>> 4.11.0 release series (following old conventions)
>> 5.0 next development version, no release
>> 5.1 next release, with 5.2, 5.3, 5.4 as subsequent bugfix (maintenance)
>> rele
Hello Qiao Yang,
On Friday 24 of July 2015 18:04:47 QIAO YANG wrote:
> Some updates for you. I've found out that my previous problem with cmdline
> due to my minicom didn't wrap up the lines I've chosen the interface of
> vc to retrieve cmdline so that we don't need to parse the atag nor
> dev
- Gedare Bloom schrieb:
> Extrapolating a bit, we would have:
> 4.11.0 release series (following old conventions)
> 5.0 next development version, no release
> 5.1 next release, with 5.2, 5.3, 5.4 as subsequent bugfix (maintenance)
> releases
> 6.0 next development version after 5.0
> 6.1 nex
This file is RTEMS specific and I am OK with it.
Sebastian is about to go on holiday so it would be appreciated
to get this approved before he leaves.
OK to commit?
On 07/27/2015 07:45 AM, Sebastian Huber wrote:
Provide self-contained synchronization objects for RTEMS. The API was
designed t
This file is RTEMS specific and I am OK with it.
Sebastian is about to go on holiday so it would be appreciated
to get this approved before he leaves.
OK to commit?
On 07/27/2015 04:31 AM, Sebastian Huber wrote:
During libgcc build the first include search path for<...> is
"../newlib/libc/sys
Extrapolating a bit, we would have:
4.11.0 release series (following old conventions)
5.0 next development version, no release
5.1 next release, with 5.2, 5.3, 5.4 as subsequent bugfix (maintenance) releases
6.0 next development version after 5.0
6.1 next release after 5.1, with 6.2, 6.3, 6.4 as be
Hello,
shortly before I go on holiday, I thought it is a good time to start a
discussion about version numbers. GCC recently changed their version number
scheme and it might be something that fits also quite good for RTEMS. The
major releases are indicated by the left-most number followed by a
ohh. We acquire lock over the_thread!! Sorry for that.
_Thread_Lock_release( lock, &lock_context );
_Scheduler_Acquire( the_thread, &lock_context );
if ( the_thread->priority_generation == my_generation ) {
and generation is only important if its value changed after release and
befo
hi,
I was going through the code in _thread_change_priority(){..}
(threadchangepriority.c) and had doubt. below is the code snippet.
_Atomic_Fence( ATOMIC_ORDER_ACQ_REL );
/*
* Do not bother recomputing all the priority related information if
* we are not REALLY changing priority.
Changes relative to the previous patch set:
- Moved GPIO pin interrupts to rtems chains, instead of a local linked list;
- Restructured the pin tracking structure, separating the interrupt information
for each pin meaning that a pin without any interrupt enabled only requires 8
bytes, while keep
Added support for the new RTEMS GPIO API functions.
Test cases can be found in
https://github.com/asuol/RTEMS_rpi_testing/tree/master/GPIO
---
c/src/lib/libbsp/arm/raspberrypi/Makefile.am | 5 +
.../raspberrypi/gpio/gpio-interfaces-pi1-rev2.c| 136 +
c/src/lib/libbsp/arm/rasp
Have a look at cpukit/score/include/rtems/score/atomic.h around line
139 and also usage at testsuites/sptests/spatomic01/init.c around line
200. Different types are available depending on what you need to cas.
On Mon, Jul 27, 2015 at 11:43 AM, Saurabh Gadia wrote:
> Hi,
> To avoid data race I nee
Hi,
To avoid data race I need cmp_swap(). So is there some implementation in
java to imitate that. And for rtems which method we use for that?
Thanks,
Saurabh Gadia
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Provide self-contained synchronization objects for RTEMS. The API was
designed to be able to use it for the Newlib internal locks, the C11
threads support, the GCC thread model support and the libgomp operating
system configuration in combination with .
References:
https://lists.rtems.org/piperm
During libgcc build the first include search path for <...> is
"../newlib/libc/sys/rtems/include". Move all RTEMS specific header
files to "libc/sys/rtems/include" so that they can be found. Later
during libc build the header files in the previous location were somehow
present, but for libgcc bui
22 matches
Mail list logo
