Re: [PATCH rtems-docs] eng: Add rules for attribution
Hi Chris, Am 30.09.21 um 02:23 schrieb Chris Johns: On 29/9/21 6:38 pm, Christian MAUDERER wrote: To be honest: If sponsored work is a legal problem, we have that with or without a note in the files. It's only more visible with a note in the files. I don't think that a legal problem would be avoidable just by not mentioning it. That is not the legal aspect I have in mind. There exists constraints about payments for work done in relation to tax law and this varies around the world. A notice could be taken as evidence. For example a functioning non-profit such as the RTEMS Foundation can accept donations and how that money is spent is up to the foundation. The contributor has no input on that process otherwise it is tax avoidance. This area is strict and the governance is important. I will let you consider the relationship between fair attribution for the whole community and those contributing to a non-profit. Surely this must be considered, but OTOH RTEMS code is definitively a project which combines non-profit and with-profit people to create and maintain code, especially since the birth of the project was with-profit. So if it comes to contributions e.g. from our company: Yes, they are created with profit. Certain areas are handled non-profit. Maybe the question then is, how to properly distinguish them. A foundation wouldn't change the problem discussed here. Don't get me wrong: I would love to see the foundation. But I don't think that the foundation would be the the same as the RTEMS open source project from a legal point of view. It would only be another (much needed) sponsor of work and infrastructure. Sorry, a non-profit does not work that way as I stated above so no attribution can happen. This makes attribution fundamentally unfair. I agree that a "sponsored by RTEMS Foundation" entry wouldn't make sense, because the whole idea of the Foundation is to maintain RTEMS. But, regarding the "sponsored by" entry, I wouldn't talk about fairness. In the past we always had the question "who is using RTEMS" and in many cases had to shrug shoulders because we either don't know or shouldn't tell. If RTEMS user companies officially ask to be visible, I think this is something we should push and not block, right? I have to say I not entirely comfortable with this happening and I will not be encouraging additions. If Thomas wishes to discuss this further I suggest he reaches out to me personally. That makes sense, I will try next week when being back at work. Thomas. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Thomas DOERFLER Dornierstr. 4 82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de phone: +49-89-18 94 741 - 12 fax: +49-89-18 94 741 - 09 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score: Remove _Thread_queue_Do_nothing_extract()
This function was unused. It was a relict of the thread queue rework done
during the SMP support development. In an early stage, the extract operation
was called with a NULL thread queue. However, this is no longer the case. The
extract operation is only called if we have a non-NULL thread queue.
---
cpukit/score/src/threadqops.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/cpukit/score/src/threadqops.c b/cpukit/score/src/threadqops.c
index a42876cf09..972af21265 100644
--- a/cpukit/score/src/threadqops.c
+++ b/cpukit/score/src/threadqops.c
@@ -59,17 +59,6 @@ void _Thread_queue_Do_nothing_priority_actions(
_Priority_Actions_initialize_empty( priority_actions );
}
-static void _Thread_queue_Do_nothing_extract(
- Thread_queue_Queue *queue,
- Thread_Control *the_thread,
- Thread_queue_Context *queue_context
-)
-{
- (void) queue;
- (void) the_thread;
- (void) queue_context;
-}
-
static void _Thread_queue_Queue_enqueue(
Thread_queue_Queue *queue,
Thread_Control *the_thread,
@@ -1461,12 +1450,11 @@ static Thread_Control
*_Thread_queue_Priority_inherit_surrender(
}
const Thread_queue_Operations _Thread_queue_Operations_default = {
- .priority_actions = _Thread_queue_Do_nothing_priority_actions,
- .extract = _Thread_queue_Do_nothing_extract
+ .priority_actions = _Thread_queue_Do_nothing_priority_actions
/*
* The default operations are only used in _Thread_Priority_apply() and
* _Thread_Continue() and do not have a thread queue associated with them, so
- * the enqueue and first operations are superfluous.
+ * the enqueue, extract, surrender, and first operations are superfluous.
*/
};
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: IDLE Stacks Not Allocated via User Provided Stack Allocator
On Thu, Sep 30, 2021 at 12:39 AM Sebastian Huber wrote: > > On 30/09/2021 00:43, Joel Sherrill wrote: > > Hi > > > > In Feb 2020, idle thread stack memory was changed to be statically > > allocated which is good for most RTEMS deployments. However, it is > > broken when you REALLY need it to be allocated by the plugin stack > > allocator. > > > > The paravirtualized environment that tripped over this provides stack > > memory protection. A special area of memory is reserved for stacks and > > the processor and host OS enforce that the stack pointer is always > > within the reserved memory segment. This was possible prior to 5 > > branching which is what the current RTEMS support for that environment > > is based on. > > Is the memory area known at link time? In this case you can use the > linker script to place the idle stacks in this area. The idle stacks are > allocated in a special section: > > RTEMS_SECTION( ".rtemsstack.idle" ) That's a good idea and I investigated it. It might work in some setups but not this one. This environment have multiple "processes" (not POSIX processes but concurrent entities with properties) and there might be multiple in the "container". RTEMS applications run in one of the processes and there can be multiple containers with RTEMS applications. During initialization, the BSP makes a system call to determine various characteristics of the container and one of those is to get our stack memory address and size. Even if this worked, I felt like I would implement the idle thread stack allocator hook because it is generally needed. But this is the solution I'm going to have to use. > > > > > The code which needs adjusting is a combination of threadcreateidle.c > > and confdefs/percpu.h which reserves the memory. My current thinking > > is to add another stack allocator hook for the idle stacks and have it > > default to a method which does the current mechanism. This default > > method would be defines in percpu.h and instantiated unless the user > > configures another method. > > Yes, this sounds like a good approach if the memory needs to be > allocated a run-time. We only need an allocator hook. Initialization of > the allocator can be done via a system initialization handler. Why not statically like the other stack allocator parameters and hooks? > Deallocation is not needed. The allocator hook should have parameters > for the idle task stack size and the idle task index. This matches my thinking. Thanks. --joel > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] record-main-lttng.cc: Change size of empty array
Change size of kEmptyThreadName from THREAD_API_COUNT to
THREAD_NAME_SIZE.
Closes #4519
---
trace/record/record-main-lttng.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/trace/record/record-main-lttng.cc
b/trace/record/record-main-lttng.cc
index 7cfa48c..faa762d 100644
--- a/trace/record/record-main-lttng.cc
+++ b/trace/record/record-main-lttng.cc
@@ -59,7 +59,7 @@
#define BITS_PER_CHAR 8
#define COMPACT_HEADER_ID 31
-static const uint8_t kEmptyThreadName[THREAD_API_COUNT] = "";
+static const uint8_t kEmptyThreadName[THREAD_NAME_SIZE] = "";
static const uint8_t kUUID[] = {0x6a, 0x77, 0x15, 0xd0, 0xb5, 0x02, 0x4c, 0x65,
0x86, 0x78, 0x67, 0x77, 0xac, 0x7f, 0x75,
0x5a};
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Workspace Initialization Faliure Bug
Hi
I need to produce a small test case but on the way to realizing the
IDLE task stacks needed to be allocated special, I tripped across a
problem where the computed workspace needed size was so low, it
tripped the second condition in the error check in
_Heap_Get_first_and_last_block:
if (
heap_area_end < heap_area_begin
|| heap_area_size <= overhead
|| first_block_size < min_block_size
) {
/* Invalid area or area too small */
return false;
}
The computed _Workspace_Size is 8. which fails the second condition.
I ended up temporarily adding the += line in
_Workspace_Handler_initialization as a workaround
overhead = _Heap_Area_overhead( page_size );
overhead += _Heap_Min_block_size( page_size );
This was with ticker but with RTEMS thinking that all stacks came from
user controlled space and not the workspace.
I think this workaround is right in adding some to allow for the third
condition which is < min_block_size. But it might be better to have a
special case for an empty heap initialization case.
I think in this configuration, the workspace is essentially unneeded
but has to be able to be initialized. It shows that the static
allocation work has succeeded in trimming the workspace at least. But
now we have to account for an empty one. :)
Thoughts?
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Avoid dead code in thread queue surrender
This looks ok On Wed, Sep 29, 2021 at 11:40 PM Sebastian Huber wrote: > > On 23/09/2021 07:38, Sebastian Huber wrote: > > For uniprocessor configurations, this patch removes dead code in the > > _Thread_queue_Surrender() and _Thread_queue_Surrender_priority_ceiling() > > functions. > > > > Dead code is removed from _Thread_queue_Surrender_sticky(). > > Ping. > > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > ___ > 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] score: Add Thread_queue_Deadlock_status
On Fri, Sep 24, 2021 at 12:22 PM Sebastian Huber
wrote:
>
> Replace the boolen return value with the new enum
> Thread_queue_Deadlock_status. This improves the code readability.
> Improve documentation. Shorten function names.
> ---
> cpukit/include/rtems/score/threadqimpl.h | 50 ++-
> cpukit/score/src/threadchangepriority.c | 4 +-
> cpukit/score/src/threadqenqueue.c| 63 ++--
> cpukit/score/src/threadqops.c| 4 +-
> 4 files changed, 80 insertions(+), 41 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/threadqimpl.h
> b/cpukit/include/rtems/score/threadqimpl.h
> index 22e0c7f069..d4fa8b8316 100644
> --- a/cpukit/include/rtems/score/threadqimpl.h
> +++ b/cpukit/include/rtems/score/threadqimpl.h
> @@ -1339,28 +1339,56 @@ void _Thread_queue_Unblock_proxy(
> #endif
>
> /**
> - * @brief Acquires the thread queue path in a critical section.
> + * @brief This is a status code to indicate if a deadlock was detected or
> not.
> + */
> +typedef enum {
> + /**
> + * @brief The operation detected a deadlock.
> + */
> + THREAD_QUEUE_DEADLOCK_DETECTED,
> +
> + /**
> + * @brief The operation did not detect a deadlock.
> + */
> + THREAD_QUEUE_NO_DEADLOCK
> +} Thread_queue_Deadlock_status;
> +
A minor note, I might switch the order of the two enum values so that
THREAD_QUEUE_NO_DEADLOCK==0==false, as this is more consistent with
the previous usage of the bool variable statuses. However, this should
not matter since you replaced the only spots the boolean value was
being used with explicit checks against the enum type. So feel free
to ignore :)
> +#if defined(RTEMS_SMP)
> +/**
> + * @brief Acquires the thread queue path.
> *
> - * @param queue The thread queue queue.
> - * @param the_thread The thread for the operation.
> - * @param queue_context The thread queue context.
> + * The caller must own the thread queue lock.
> + *
> + * A acquired thread queue path must be released by calling
minor: A -> An
Rest of this looks good.
> + * _Thread_queue_Path_release() with the same thread queue context.
> + *
> + * @param queue is the thread queue queue.
> + *
> + * @param the_thread is the thread for the operation.
> + *
> + * @param queue_context is the thread queue context.
> *
> - * @retval true The operation was successful.
> - * @retval false The operation failed.
> + * @retval THREAD_QUEUE_NO_DEADLOCK No deadlock was detected.
> + *
> + * @retval THREAD_QUEUE_DEADLOCK_DETECTED A deadlock was detected while
> + * acquiring the thread queue path. The thread queue path must still be
> + * released by _Thread_queue_Path_release() in this case.
> */
> -#if defined(RTEMS_SMP)
> -bool _Thread_queue_Path_acquire_critical(
> +Thread_queue_Deadlock_status _Thread_queue_Path_acquire(
>Thread_queue_Queue *queue,
>Thread_Control *the_thread,
>Thread_queue_Context *queue_context
> );
>
> /**
> - * @brief Releases the thread queue path in a critical section.
> + * @brief Releases the thread queue path.
> *
> - * @param queue_context The thread queue context.
> + * The caller must have acquired the thread queue path with a corresponding
> + * _Thread_queue_Path_acquire().
> + *
> + * @param queue_context is the thread queue context.
> */
> -void _Thread_queue_Path_release_critical(
> +void _Thread_queue_Path_release(
>Thread_queue_Context *queue_context
> );
> #endif
> diff --git a/cpukit/score/src/threadchangepriority.c
> b/cpukit/score/src/threadchangepriority.c
> index 613d0cd7af..bd4fef279b 100644
> --- a/cpukit/score/src/threadchangepriority.c
> +++ b/cpukit/score/src/threadchangepriority.c
> @@ -278,11 +278,11 @@ static void _Thread_Priority_apply(
>
>if ( !_Priority_Actions_is_empty( &queue_context->Priority.Actions ) ) {
> #if defined(RTEMS_SMP)
> -_Thread_queue_Path_acquire_critical( queue, the_thread, queue_context );
> +(void) _Thread_queue_Path_acquire( queue, the_thread, queue_context );
> #endif
> _Thread_Priority_perform_actions( queue->owner, queue_context );
> #if defined(RTEMS_SMP)
> -_Thread_queue_Path_release_critical( queue_context );
> +_Thread_queue_Path_release( queue_context );
> #endif
>}
> }
> diff --git a/cpukit/score/src/threadqenqueue.c
> b/cpukit/score/src/threadqenqueue.c
> index 1b8b82eab9..ee5c6fff5e 100644
> --- a/cpukit/score/src/threadqenqueue.c
> +++ b/cpukit/score/src/threadqenqueue.c
> @@ -8,10 +8,9 @@
> * _Thread_queue_Do_dequeue(), _Thread_queue_Enqueue(),
> * _Thread_queue_Enqueue_do_nothing_extra(),
> _Thread_queue_Enqueue_sticky(),
> * _Thread_queue_Extract(), _Thread_queue_Extract_locked(),
> - * _Thread_queue_Path_acquire_critical(),
> - * _Thread_queue_Path_release_critical(),
> + * _Thread_queue_Path_acquire(), _Thread_queue_Path_release(),
> * _Thread_queue_Resume(),_Thread_queue_Surrender(),
> - * _Thread_queue_Surrender_sticky().
> + * _Thread_queue_Surrender_no_priority(), _Thread_queue_Surr
Re: [PATCH] score: Remove _Thread_queue_Do_nothing_extract()
ok
On Thu, Sep 30, 2021 at 5:51 AM Sebastian Huber
wrote:
>
> This function was unused. It was a relict of the thread queue rework done
> during the SMP support development. In an early stage, the extract operation
> was called with a NULL thread queue. However, this is no longer the case.
> The
> extract operation is only called if we have a non-NULL thread queue.
> ---
> cpukit/score/src/threadqops.c | 16 ++--
> 1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/cpukit/score/src/threadqops.c b/cpukit/score/src/threadqops.c
> index a42876cf09..972af21265 100644
> --- a/cpukit/score/src/threadqops.c
> +++ b/cpukit/score/src/threadqops.c
> @@ -59,17 +59,6 @@ void _Thread_queue_Do_nothing_priority_actions(
>_Priority_Actions_initialize_empty( priority_actions );
> }
>
> -static void _Thread_queue_Do_nothing_extract(
> - Thread_queue_Queue *queue,
> - Thread_Control *the_thread,
> - Thread_queue_Context *queue_context
> -)
> -{
> - (void) queue;
> - (void) the_thread;
> - (void) queue_context;
> -}
> -
> static void _Thread_queue_Queue_enqueue(
>Thread_queue_Queue *queue,
>Thread_Control *the_thread,
> @@ -1461,12 +1450,11 @@ static Thread_Control
> *_Thread_queue_Priority_inherit_surrender(
> }
>
> const Thread_queue_Operations _Thread_queue_Operations_default = {
> - .priority_actions = _Thread_queue_Do_nothing_priority_actions,
> - .extract = _Thread_queue_Do_nothing_extract
> + .priority_actions = _Thread_queue_Do_nothing_priority_actions
>/*
> * The default operations are only used in _Thread_Priority_apply() and
> * _Thread_Continue() and do not have a thread queue associated with them,
> so
> - * the enqueue and first operations are superfluous.
> + * the enqueue, extract, surrender, and first operations are superfluous.
> */
> };
>
> --
> 2.26.2
>
> ___
> 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: [PATCHv5] improve the format error reporting on i386
Joel, i think the patch looks good.
On Fri, Sep 24, 2021 at 6:19 PM zack leung wrote:
>
> bump
>
>
> On Thu, 23 Sept 2021 at 00:21, zack leung wrote:
>>
>> I can send an example of the exception if you want.
>>
>> zack
>>
>> On Wed, 22 Sept 2021 at 18:01, Gedare Bloom wrote:
>>>
>>> Joel,
>>>
>>> This looks good to me. I don't know if you can easily test it?
>>>
>>> Gedare
>>>
>>> On Wed, Sep 22, 2021 at 11:26 AM zack leung
>>> wrote:
>>> >
>>> > ll hex values now have 8 character width
>>> > thread id is now hex
>>> > updates #4203
>>> > ---
>>> > cpukit/score/cpu/i386/cpu.c | 6 +++---
>>> > 1 file changed, 3 insertions(+), 3 deletions(-)
>>> >
>>> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
>>> > index 77b7a7161c..786cf8b0b6 100644
>>> > --- a/cpukit/score/cpu/i386/cpu.c
>>> > +++ b/cpukit/score/cpu/i386/cpu.c
>>> > @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
>>> > CPU_Exception_frame *ctx)
>>> > {
>>> >unsigned int faultAddr = 0;
>>> >printk("--\n");
>>> > - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
>>> > PRId32 "\n",
>>> > + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread 0x%08"
>>> > PRIx32 "\n",
>>> > ctx->idtIndex,
>>> > ctx->eip,
>>> > _Thread_Executing->Object.id);
>>> >printk("--\n");
>>> >printk("Processor execution context at time of the fault was :\n");
>>> >printk("--\n");
>>> > - printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
>>> > EDX = %" PRIx32 "\n",
>>> > + printk(" EAX = 0x%08" PRIx32 "EBX = 0x%08" PRIx32 "ECX =
>>> > 0x%08" PRIx32 "EDX = 0x%08" PRIx32 "\n",
>>> > ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
>>> > - printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
>>> > ESP = %" PRIx32 "\n",
>>> > + printk(" ESI = 0x%08" PRIx32 "EDI = 0x%08" PRIx32 "EBP =
>>> > 0x%08" PRIx32 "ESP = 0x%08" PRIx32 "\n",
>>> > ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>>> >printk("--\n");
>>> >printk("Error code pushed by processor itself (if not 0) = %" PRIx32
>>> > "\n",
>>> > --
>>> > 2.33.0
>>> > ___
>>> > 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] cpukit/aarch64: Use correct context register sets
looks ok to me. On Thu, Sep 23, 2021 at 1:05 PM Kinsey Moore wrote: > > Context validation for AArch64 was ported from the ARM implementation > without a reinterpretation of the actual requirements. The spcontext01 > test just happened to pass because the set of scratch registers in ARM > is a subset of the scratch registers in AArch64. > --- > .../cpu/aarch64/aarch64-context-validate.S| 159 -- > .../aarch64-context-volatile-clobber.S| 19 +++ > 2 files changed, 123 insertions(+), 55 deletions(-) > > diff --git a/cpukit/score/cpu/aarch64/aarch64-context-validate.S > b/cpukit/score/cpu/aarch64/aarch64-context-validate.S > index 1e71bc5b3a..1daa0d6bf2 100644 > --- a/cpukit/score/cpu/aarch64/aarch64-context-validate.S > +++ b/cpukit/score/cpu/aarch64/aarch64-context-validate.S > @@ -44,35 +44,47 @@ > #include > #include > > -/* These must be 8 byte aligned to avoid misaligned accesses */ > -#define FRAME_OFFSET_X4 0x00 > -#define FRAME_OFFSET_X5 0x08 > -#define FRAME_OFFSET_X6 0x10 > -#define FRAME_OFFSET_X7 0x18 > -#define FRAME_OFFSET_X8 0x20 > -#define FRAME_OFFSET_X9 0x28 > -#define FRAME_OFFSET_X10 0x30 > -#define FRAME_OFFSET_X11 0x38 > -#define FRAME_OFFSET_LR 0x40 > +/* > + * This register size applies to X (integer) registers as well as the D > (lower > + * half floating point) registers. It does not apply to V (full size floating > + * point) registers or W (lower half integer) registers. > + */ > +#define AARCH64_REGISTER_SIZE 8 > + > +/* According to the AAPCS64, X19-X28 are callee-saved registers */ > +#define FRAME_OFFSET_X19 0x00 > +#define FRAME_OFFSET_X20 0x08 > +#define FRAME_OFFSET_X21 0x10 > +#define FRAME_OFFSET_X22 0x18 > +#define FRAME_OFFSET_X23 0x20 > +#define FRAME_OFFSET_X24 0x28 > +#define FRAME_OFFSET_X25 0x30 > +#define FRAME_OFFSET_X26 0x38 > +#define FRAME_OFFSET_X27 0x40 > +#define FRAME_OFFSET_X28 0x48 > +#define FRAME_OFFSET_LR 0x50 > > #ifdef AARCH64_MULTILIB_VFP > - /* These must be 16 byte aligned to avoid misaligned accesses */ > - #define FRAME_OFFSET_V8 0x50 > - #define FRAME_OFFSET_V9 0x60 > - #define FRAME_OFFSET_V10 0x70 > - #define FRAME_OFFSET_V11 0x80 > - #define FRAME_OFFSET_V12 0x90 > - #define FRAME_OFFSET_V13 0xA0 > - #define FRAME_OFFSET_V14 0xB0 > - #define FRAME_OFFSET_V15 0xC0 > + /* > + * According to the AAPCS64, V8-V15 are callee-saved registers, but only > the > + * bottom 8 bytes are required to be saved which correspond to D8-D15. > + */ > + #define FRAME_OFFSET_D8 0x58 > + #define FRAME_OFFSET_D9 0x60 > + #define FRAME_OFFSET_D10 0x68 > + #define FRAME_OFFSET_D11 0x70 > + #define FRAME_OFFSET_D12 0x78 > + #define FRAME_OFFSET_D13 0x80 > + #define FRAME_OFFSET_D14 0x88 > + #define FRAME_OFFSET_D15 0x90 > >/* > * Force 16 byte alignment of the frame size to avoid stack pointer > alignment > * exceptions. > */ > - #define FRAME_SIZE RTEMS_ALIGN_UP( FRAME_OFFSET_V15, 16 ) > + #define FRAME_SIZE RTEMS_ALIGN_UP( FRAME_OFFSET_D15 + > AARCH64_REGISTER_SIZE, 16 ) > #else > - #define FRAME_SIZE RTEMS_ALIGN_UP( FRAME_OFFSET_LR, 16 ) > + #define FRAME_SIZE RTEMS_ALIGN_UP( FRAME_OFFSET_LR + > AARCH64_REGISTER_SIZE, 16 ) > #endif > > .section.text > @@ -83,25 +95,27 @@ FUNCTION_ENTRY(_CPU_Context_validate) > > sub sp, sp, #FRAME_SIZE > > - str x4, [sp, #FRAME_OFFSET_X4] > - str x5, [sp, #FRAME_OFFSET_X5] > - str x6, [sp, #FRAME_OFFSET_X6] > - str x7, [sp, #FRAME_OFFSET_X7] > - str x8, [sp, #FRAME_OFFSET_X8] > - str x9, [sp, #FRAME_OFFSET_X9] > - str x10, [sp, #FRAME_OFFSET_X10] > - str x11, [sp, #FRAME_OFFSET_X11] > + str x19, [sp, #FRAME_OFFSET_X19] > + str x20, [sp, #FRAME_OFFSET_X20] > + str x21, [sp, #FRAME_OFFSET_X21] > + str x22, [sp, #FRAME_OFFSET_X22] > + str x23, [sp, #FRAME_OFFSET_X23] > + str x24, [sp, #FRAME_OFFSET_X24] > + str x25, [sp, #FRAME_OFFSET_X25] > + str x26, [sp, #FRAME_OFFSET_X26] > + str x27, [sp, #FRAME_OFFSET_X27] > + str x28, [sp, #FRAME_OFFSET_X28] > str lr, [sp, #FRAME_OFFSET_LR] > > #ifdef AARCH64_MULTILIB_VFP > - str d8, [sp, #FRAME_OFFSET_V8] > - str d9, [sp, #FRAME_OFFSET_V9] > - str d10, [sp, #FRAME_OFFSET_V10] > - str d11, [sp, #FRAME_OFFSET_V11] > - str d12, [sp, #FRAME_OFFSET_V12] > - str d13, [sp, #FRAME_OFFSET_V13] > - str d14, [sp, #FRAME_OFFSET_V14] > - str d15, [sp, #FRAME_OFFSET_V15] > + str d8, [sp, #FRAME_OFFSET_D8] > + str d9, [sp, #FRAME_OFFSET_D9] > + str d10, [sp, #FRAME_OFFSET_D10] > + str d11, [sp, #FRAME_OFFSET_D11] > + str d12, [sp, #FRAME_OFFSET_D12] > + str d13, [sp, #FRAME_OFFSET_D13] > + str d14, [sp, #FRAME_OFFSET_D14] > +
Re: [PATCH v2 1/6] cpukit/aarch64: Use correct interrupt level types
If the rest of the patch set isn't ready, please split this out for
separate submission. It looks fine to me.
On Wed, Sep 22, 2021 at 6:17 PM Kinsey Moore wrote:
>
> All other architectures use uint32_t for interrupt levels and there is
> no reason not to do so on AArch64.
> ---
> cpukit/score/cpu/aarch64/cpu.c | 4 ++--
> cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/cpukit/score/cpu/aarch64/cpu.c b/cpukit/score/cpu/aarch64/cpu.c
> index d09403a349..b36f55ae17 100644
> --- a/cpukit/score/cpu/aarch64/cpu.c
> +++ b/cpukit/score/cpu/aarch64/cpu.c
> @@ -146,7 +146,7 @@ void _CPU_Context_Initialize(
>}
> }
>
> -void _CPU_ISR_Set_level( uint64_t level )
> +void _CPU_ISR_Set_level( uint32_t level )
> {
>/* Set the mask bit if interrupts are disabled */
>level = level ? AARCH64_PSTATE_I : 0;
> @@ -156,7 +156,7 @@ void _CPU_ISR_Set_level( uint64_t level )
>);
> }
>
> -uint64_t _CPU_ISR_Get_level( void )
> +uint32_t _CPU_ISR_Get_level( void )
> {
>uint64_t level;
>
> diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
> b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
> index 82f74193a2..ae7e2bdcba 100644
> --- a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
> +++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
> @@ -204,9 +204,9 @@ static inline void
> _AARCH64_Instruction_synchronization_barrier( void )
>__asm__ volatile ( "isb" : : : "memory" );
> }
>
> -void _CPU_ISR_Set_level( uint64_t level );
> +void _CPU_ISR_Set_level( uint32_t level );
>
> -uint64_t _CPU_ISR_Get_level( void );
> +uint32_t _CPU_ISR_Get_level( void );
>
> #if defined(AARCH64_DISABLE_INLINE_ISR_DISABLE_ENABLE)
> uint64_t AArch64_interrupt_disable( void );
> --
> 2.30.2
>
> ___
> 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 v2 2/6] cpukit: Add Exception Manager
You also might separate the exception manager addition away from the
topic of recoverable exceptions. This introduces/extends the classic
API, so it needs to be vetted carefully. Although the new header
claims to be a classic API, it appears to not follow classic API
conventions. You might need to think about what needs to be exposed to
the application level, and how, versus what should be internal. And
follow the conventions for classic API usage (e.g., opaque types not
pointers).
On Wed, Sep 22, 2021 at 6:17 PM Kinsey Moore wrote:
>
> This adds the framework necessary to allow more generic handling of
> machine exceptions. This initial patch offers the ability to get the
> class of exception from the CPU_Exception_frame provided. Future
> extensions of the Exception Manager could include the ability to get
> the address of the exception if applicable or to resume execution at
> the next instruction or an arbitrary location.
> ---
> cpukit/include/rtems/exception.h | 166 ++
> spec/build/cpukit/cpuopts.yml | 2 +
> spec/build/cpukit/librtemscpu.yml | 1 +
> spec/build/cpukit/optexceptionmanager.yml | 17 +++
> 4 files changed, 186 insertions(+)
> create mode 100644 cpukit/include/rtems/exception.h
> create mode 100644 spec/build/cpukit/optexceptionmanager.yml
>
> diff --git a/cpukit/include/rtems/exception.h
> b/cpukit/include/rtems/exception.h
> new file mode 100644
> index 00..89edfd02b4
> --- /dev/null
> +++ b/cpukit/include/rtems/exception.h
> @@ -0,0 +1,166 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @brief This header file defines the Exception Manager API.
> + */
> +
> +/*
> + * Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef _RTEMS_EXCEPTION_H
> +#define _RTEMS_EXCEPTION_H
> +
> +#include
> +#include
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> + * @defgroup RTEMSAPIClassicException Exception Manager
> + *
> + * @ingroup RTEMSAPIClassic
> + *
If this is an extension of the Classic API, then it should be
following classic api naming conventions, hence I'd expect this all to
be rtems_exception_xxx(). Please clarify.
> + * @brief The Exception Manager processes all machine exceptions and passes
> + * any unhandled exceptions to the Fatal Error Manager.
> + */
> +
> +/**
> + * The following lists the generic exception classes supported by the
> Exception
> + * Management API.
> + */
> +typedef enum {
> + EXCEPTION_UNKNOWN,
> + EXCEPTION_FPU,
> + EXCEPTION_TAGGED_OVERFLOW,
> + EXCEPTION_DIV_ZERO,
> + EXCEPTION_DATA_ABORT_READ,
> + EXCEPTION_DATA_ABORT_WRITE,
> + EXCEPTION_DATA_ABORT_UNSPECIFIED,
> + EXCEPTION_INSTRUCTION_ABORT,
> + EXCEPTION_MMU_UNSPECIFIED,
> + EXCEPTION_ACCESS_ALIGNMENT,
> + EXCEPTION_SUPERVISOR,
> + EXCEPTION_TRAPPED_INSTRUCTION,
> + EXCEPTION_PC_ALIGNMENT,
> + EXCEPTION_SP_ALIGNMENT,
> + EXCEPTION_BREAKPOINT,
> + EXCEPTION_BREAK_INSTRUCTION,
> + EXCEPTION_STEP,
> + EXCEPTION_WATCHPOINT,
> + EXCEPTION_MAX
> +} Exception_Class;
> +
How did you derive these? Do they need some more documentation?
I'm not 100% on calling them "Classes". Types? Sources? I'm not sure.
> +/**
> + * @brief Resumes normal execution using the provided exception frame.
> + *
> + * This routine helps to avoid dead code in the exception handler epilogue
> and
> + * does not return. This routine may assume that the provided pointer is
> valid
> + * for resetting the exception stack.
> + *
> + * @param exception_frame The CPU_Exception_frame describing the machine
> + * e
[PATCH 0/3] Add MicroBlaze port and BSP
Hi, This patch set adds support for the MicroBlaze architecture along with a basic BSP based on Xilinx's KCU105 PetaLinux BSP configuration. The initial architecture port was started 6 or 7 years ago, I believe. To make authorship clear and preserve file history, the work is broken up into three patches. I made an effort to prune the first two patches of any files related to the old build system. Thanks, Alex White Alex White (1): microblaze: Rework for RTEMS 6 Hesham ALMatary (1): bsps: Add MicroBlaze FPGA BSP Joel Sherrill (1): score: Add MicroBlaze port bsps/include/bsp/fatal.h | 3 + bsps/microblaze/include/bsp/linker-symbols.h | 106 ++ bsps/microblaze/include/common/xil_types.h| 197 +++ bsps/microblaze/include/dev/serial/uartlite.h | 62 .../include/dev/serial/uartlite_l.h | 323 ++ bsps/microblaze/microblaze_fpga/clock/clock.c | 145 .../microblaze_fpga/console/console-io.c | 57 .../microblaze_fpga/console/debug-io.c| 66 bsps/microblaze/microblaze_fpga/include/bsp.h | 53 +++ .../microblaze_fpga/include/bsp/intc.h| 74 .../microblaze_fpga/include/bsp/irq.h | 49 +++ .../microblaze_fpga/include/bsp/timer.h | 69 .../microblaze/microblaze_fpga/include/tm27.h | 58 bsps/microblaze/microblaze_fpga/irq/irq.c | 168 + .../microblaze_fpga/start/bspreset.c | 44 +++ .../microblaze_fpga/start/bspstart.c | 43 +++ .../startup/_exception_handler.S | 52 +++ .../startup/_hw_exception_handler.S | 52 +++ .../startup/_interrupt_handler.S | 53 +++ .../microblaze_fpga/startup/sim-crtinit.S | 88 + bsps/microblaze/shared/cache/cache.c | 36 ++ bsps/microblaze/shared/dev/serial/uartlite.c | 145 .../microblaze/shared/dev/serial/uartlite_l.c | 99 ++ bsps/microblaze/shared/start/start.S | 114 +++ cpukit/score/cpu/microblaze/__tls_get_addr.c | 54 +++ cpukit/score/cpu/microblaze/cpu.c | 121 +++ cpukit/score/cpu/microblaze/cpu_asm.S | 194 +++ .../score/cpu/microblaze/include/rtems/asm.h | 138 .../cpu/microblaze/include/rtems/score/cpu.h | 305 + .../include/rtems/score/cpuatomic.h | 41 +++ .../microblaze/include/rtems/score/cpuimpl.h | 96 ++ .../include/rtems/score/microblaze.h | 57 .../microblaze/microblaze-context-switch.S| 107 ++ .../microblaze/microblaze-context-validate.S | 117 +++ .../microblaze-context-volatile-clobber.S | 28 ++ spec/build/bsps/microblaze/grp.yml| 15 + .../bsps/microblaze/microblaze_fpga/abi.yml | 20 ++ .../microblaze/microblaze_fpga/bspkcu105.yml | 24 ++ .../microblaze_fpga/bspkcu105_qemu.yml| 24 ++ .../bsps/microblaze/microblaze_fpga/grp.yml | 36 ++ .../microblaze/microblaze_fpga/linkcmds.yml | 242 + .../bsps/microblaze/microblaze_fpga/obj.yml | 51 +++ .../microblaze_fpga/optconsoleinterrupts.yml | 15 + .../microblaze_fpga/optintcbaseaddress.yml| 18 + .../microblaze_fpga/opttimerbaseaddress.yml | 18 + .../microblaze_fpga/opttimerfrequency.yml | 17 + .../optuartlitebaseaddress.yml| 18 + .../bsps/microblaze/microblaze_fpga/start.yml | 14 + .../microblaze_fpga/tstkcu105_qemu.yml| 14 + spec/build/cpukit/cpumicroblaze.yml | 29 ++ spec/build/cpukit/librtemscpu.yml | 2 + 51 files changed, 3971 insertions(+) create mode 100644 bsps/microblaze/include/bsp/linker-symbols.h create mode 100644 bsps/microblaze/include/common/xil_types.h create mode 100644 bsps/microblaze/include/dev/serial/uartlite.h create mode 100644 bsps/microblaze/include/dev/serial/uartlite_l.h create mode 100644 bsps/microblaze/microblaze_fpga/clock/clock.c create mode 100644 bsps/microblaze/microblaze_fpga/console/console-io.c create mode 100644 bsps/microblaze/microblaze_fpga/console/debug-io.c create mode 100644 bsps/microblaze/microblaze_fpga/include/bsp.h create mode 100644 bsps/microblaze/microblaze_fpga/include/bsp/intc.h create mode 100644 bsps/microblaze/microblaze_fpga/include/bsp/irq.h create mode 100644 bsps/microblaze/microblaze_fpga/include/bsp/timer.h create mode 100644 bsps/microblaze/microblaze_fpga/include/tm27.h create mode 100644 bsps/microblaze/microblaze_fpga/irq/irq.c create mode 100644 bsps/microblaze/microblaze_fpga/start/bspreset.c create mode 100644 bsps/microblaze/microblaze_fpga/start/bspstart.c create mode 100644 bsps/microblaze/microblaze_fpga/startup/_exception_handler.S create mode 100644 bsps/microblaze/microblaze_fpga/startup/_hw_exception_handler.S create mode 100644 bsps/microblaze/microblaze_fpga/startup/_interrupt_handler.S create mode 100644 bsps/microblaze/microblaze_fpga/startup/sim-crtinit.S create mode 100644 bsps/microblaze/shared/cache/cache.c
[PATCH 2/3] bsps: Add MicroBlaze FPGA BSP
From: Hesham ALMatary
---
.../microblaze_fpga/console/console-io.c | 74 +
.../microblaze/microblaze_fpga/include/bsp.h | 48 ++
.../microblaze/microblaze_fpga/include/tm27.h | 48 ++
.../microblaze/microblaze_fpga/start/start.S | 109 +
.../startup/_exception_handler.S | 38 +
.../startup/_interrupt_handler.S | 38 +
.../microblaze_fpga/startup/sim-crtinit.S | 86 +++
.../shared/include/linker-symbols.h | 104 +
cpukit/score/cpu/microblaze/cpu.c | 47 +-
.../microblaze/microblaze-context-switch.S| 89 +++
cpukit/score/cpu/microblaze/rtems/asm.h | 2 +-
cpukit/score/cpu/microblaze/rtems/score/cpu.h | 145 ++
.../cpu/microblaze/rtems/score/microblaze.h | 35 -
13 files changed, 784 insertions(+), 79 deletions(-)
create mode 100644
c/src/lib/libbsp/microblaze/microblaze_fpga/console/console-io.c
create mode 100644 c/src/lib/libbsp/microblaze/microblaze_fpga/include/bsp.h
create mode 100644 c/src/lib/libbsp/microblaze/microblaze_fpga/include/tm27.h
create mode 100644 c/src/lib/libbsp/microblaze/microblaze_fpga/start/start.S
create mode 100644
c/src/lib/libbsp/microblaze/microblaze_fpga/startup/_exception_handler.S
create mode 100644
c/src/lib/libbsp/microblaze/microblaze_fpga/startup/_interrupt_handler.S
create mode 100644
c/src/lib/libbsp/microblaze/microblaze_fpga/startup/sim-crtinit.S
create mode 100644 c/src/lib/libbsp/microblaze/shared/include/linker-symbols.h
create mode 100644 cpukit/score/cpu/microblaze/microblaze-context-switch.S
diff --git a/c/src/lib/libbsp/microblaze/microblaze_fpga/console/console-io.c
b/c/src/lib/libbsp/microblaze/microblaze_fpga/console/console-io.c
new file mode 100644
index 00..47592967ac
--- /dev/null
+++ b/c/src/lib/libbsp/microblaze/microblaze_fpga/console/console-io.c
@@ -0,0 +1,74 @@
+/**
+ * @file
+ *
+ * @ingroup microblaze_uart
+ *
+ * @brief Console Configuration.
+ */
+
+/*
+ * Copyright (C) 2015 Hesham Almatary
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+
+#include
+
+#include
+#include
+
+console_tbl Console_Configuration_Ports [] = {
+{
+ .sDeviceName = "/dev/ttyS0",
+ .deviceType = SERIAL_CUSTOM,
+ .pDeviceFns = µblaze_uart_fns,
+ .deviceProbe = NULL,
+ .pDeviceFlow = NULL,
+ .ulCtrlPort1 = UART_BASEADDRESS,
+ .ulCtrlPort2 = 0,
+ .ulClock = 9600,
+ .ulIntVector = 0
+}
+};
+
+#define PORT_COUNT \
+ (sizeof(Console_Configuration_Ports) \
+/ sizeof(Console_Configuration_Ports [0]))
+
+unsigned long Console_Configuration_Count = PORT_COUNT;
+
+static void output_char(char c)
+{
+ const console_fns *con =
+Console_Configuration_Ports [Console_Port_Minor].pDeviceFns;
+
+ if (c == '\n') {
+con->deviceWritePolled((int) Console_Port_Minor, '\r');
+ }
+ con->deviceWritePolled((int) Console_Port_Minor, c);
+}
+
+BSP_output_char_function_type BSP_output_char = output_char;
+
+BSP_polling_getchar_function_type BSP_poll_char = NULL;
diff --git a/c/src/lib/libbsp/microblaze/microblaze_fpga/include/bsp.h
b/c/src/lib/libbsp/microblaze/microblaze_fpga/include/bsp.h
new file mode 100644
index 00..cb72835571
--- /dev/null
+++ b/c/src/lib/libbsp/microblaze/microblaze_fpga/include/bsp.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2015 Hesham Almatary
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer
[PATCH 1/3] score: Add MicroBlaze port
From: Joel Sherrill
---
.../gdbmbsim/startup/_hw_exception_handler.S | 38 +
cpukit/score/cpu/microblaze/cpu.c | 168 +++
cpukit/score/cpu/microblaze/rtems/asm.h | 125 ++
cpukit/score/cpu/microblaze/rtems/score/cpu.h | 1263 +
.../cpu/microblaze/rtems/score/microblaze.h | 70 +
5 files changed, 1664 insertions(+)
create mode 100644
c/src/lib/libbsp/microblaze/gdbmbsim/startup/_hw_exception_handler.S
create mode 100644 cpukit/score/cpu/microblaze/cpu.c
create mode 100644 cpukit/score/cpu/microblaze/rtems/asm.h
create mode 100644 cpukit/score/cpu/microblaze/rtems/score/cpu.h
create mode 100644 cpukit/score/cpu/microblaze/rtems/score/microblaze.h
diff --git
a/c/src/lib/libbsp/microblaze/gdbmbsim/startup/_hw_exception_handler.S
b/c/src/lib/libbsp/microblaze/gdbmbsim/startup/_hw_exception_handler.S
new file mode 100644
index 00..bb729ca33b
--- /dev/null
+++ b/c/src/lib/libbsp/microblaze/gdbmbsim/startup/_hw_exception_handler.S
@@ -0,0 +1,38 @@
+/* Copyright (c) 2001, 2009 Xilinx, Inc. All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are
+ met:
+
+ 1. Redistributions source code must retain the above copyright notice,
+ this list of conditions and the following disclaimer.
+
+ 2. Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ 3. Neither the name of Xilinx nor the names of its contributors may be
+ used to endorse or promote products derived from this software without
+ specific prior written permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTORS "AS
+ IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+ PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
+ TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+*/
+
+ .text
+ .globl _hw_exception_handler# HW Exception Handler Label
+ .align 2
+
+ _hw_exception_handler:
+ rtedr17, 0
+ nop
diff --git a/cpukit/score/cpu/microblaze/cpu.c
b/cpukit/score/cpu/microblaze/cpu.c
new file mode 100644
index 00..27dd69b9fb
--- /dev/null
+++ b/cpukit/score/cpu/microblaze/cpu.c
@@ -0,0 +1,168 @@
+/*
+ * MicroBlaze CPU Dependent Source
+ *
+ * COPYRIGHT (c) 1989-2011.
+ * On-Line Applications Research Corporation (OAR).
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.com/license/LICENSE.
+ *
+ * $Id: cpu.c,v 1.24 2010/03/27 15:02:26 joel Exp $
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include
+#include
+#include
+
+/* _CPU_Initialize
+ *
+ * This routine performs processor dependent initialization.
+ *
+ * INPUT PARAMETERS: NONE
+ *
+ * NO_CPU Specific Information:
+ *
+ * XXX document implementation including references if appropriate
+ */
+
+void _CPU_Initialize(void)
+{
+ /*
+ * If there is not an easy way to initialize the FP context
+ * during Context_Initialize, then it is usually easier to
+ * save an "uninitialized" FP context here and copy it to
+ * the task's during Context_Initialize.
+ */
+
+ /* FP context initialization support goes here */
+}
+
+/*PAGE
+ *
+ * _CPU_ISR_Get_level
+ *
+ * NO_CPU Specific Information:
+ *
+ * XXX document implementation including references if appropriate
+ */
+
+uint32_t _CPU_ISR_Get_level( void )
+{
+ /*
+ * This routine returns the current interrupt level.
+ */
+
+ return 0;
+}
+
+/*PAGE
+ *
+ * _CPU_ISR_install_raw_handler
+ *
+ * NO_CPU Specific Information:
+ *
+ * XXX document implementation including references if appropriate
+ */
+
+void _CPU_ISR_install_raw_handler(
+ uint32_tvector,
+ proc_ptrnew_handler,
+ proc_ptr *old_handler
+)
+{
+ /*
+ * This is where we install the interrupt handler into the "raw" interrupt
+ * table used by the CPU to dispatch interrupt handlers.
+ */
+}
+
+/*PAGE
+ *
+ * _CPU_ISR_install_vector
+ *
+ * This kernel routine installs the RTEMS handler for the
+ * specified vector.
+ *
+ * Input parameters:
+ *vector - interrupt vector number
+ *old_handler - former ISR for this vector
[PATCH] bsp/imx: Add cs_change support to SPI
---
bsps/arm/imx/spi/imx-ecspi.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/bsps/arm/imx/spi/imx-ecspi.c b/bsps/arm/imx/spi/imx-ecspi.c
index 26ba812f62..4732b84713 100644
--- a/bsps/arm/imx/spi/imx-ecspi.c
+++ b/bsps/arm/imx/spi/imx-ecspi.c
@@ -350,6 +350,9 @@ static void imx_ecspi_interrupt(void *arg)
} else if (bus->in_transfer > 0) {
regs->intreg = IMX_ECSPI_RR;
} else {
+if (bus->msg->cs_change) {
+ imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
+}
--bus->msg_todo;
++bus->msg;
imx_ecspi_next_msg(bus, regs);
@@ -376,9 +379,6 @@ static int imx_ecspi_check_messages(
(msg->cs > IMX_ECSPI_MAX_CHIPSELECTS || !bus->cspins[msg->cs].valid)) {
return -EINVAL;
}
-if (msg->cs_change != 0) {
- return -EINVAL;
-}
++msg;
--size;
@@ -407,7 +407,9 @@ static int imx_ecspi_transfer(
imx_ecspi_next_msg(bus, bus->regs);
rtems_event_transient_receive(RTEMS_WAIT, RTEMS_NO_TIMEOUT);
-imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
+if (msgs[n-1].cs_change) {
+ imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
+}
}
return rv;
}
--
2.31.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
