On 07/04/2014 04:20 PM, Joel Sherrill wrote:
On Jul 4, 2014 3:47 AM, Daniel Hellstrom wrote:
>
> On 07/03/2014 04:55 PM, Joel Sherrill wrote:
> > I am wondering if I don't have a vision for what this
> > series of patches is trying to accomplish in whole.
> * make exit-code propagate to debug
On Jul 4, 2014 1:00 PM, Pavel Pisa wrote:
>
> Hello Sebastian,
>
> On Tuesday 01 of July 2014 16:58:40 Sebastian Huber wrote:
> > On 2014-07-01 16:56, Sebastian Huber wrote:
> > > gcc/ChangeLog
> > > 2014-07-01 Sebastian Huber
> > >
> > > * config/arm/t-rtems-eabi: Add
> > > mthumb/m
Hello Sebastian,
On Tuesday 01 of July 2014 16:58:40 Sebastian Huber wrote:
> On 2014-07-01 16:56, Sebastian Huber wrote:
> > gcc/ChangeLog
> > 2014-07-01 Sebastian Huber
> >
> > * config/arm/t-rtems-eabi: Add
> > mthumb/march=armv7-r/mfpu=vfpv3-d16/mfloat-abi=hard,
> > mbig-endian/
On Jul 4, 2014 10:09 AM, Daniel Cederman wrote:
>
> > This limits the API to the default cpu_set_t. Other routines like
> > pthread_setaffinity_np() don't have this limitation.
>
> I looked at pthread_setaffinity_np() and got a bit confused. I see that
> it takes both a pointer to a cpu_set_t a
> This limits the API to the default cpu_set_t. Other routines like
> pthread_setaffinity_np() don't have this limitation.
I looked at pthread_setaffinity_np() and got a bit confused. I see that
it takes both a pointer to a cpu_set_t and the size of the cpu set. It
forwards it to _Scheduler_Se
On Jul 4, 2014 3:47 AM, Daniel Hellstrom wrote:
>
> On 07/03/2014 04:55 PM, Joel Sherrill wrote:
> > I am wondering if I don't have a vision for what this
> > series of patches is trying to accomplish in whole.
> * make exit-code propagate to debugger/hypervisor. I though this would be
> nice fo
On Jul 4, 2014 4:49 AM, Sebastian Huber
wrote:
>
> On 2014-07-03 11:37, Daniel Cederman wrote:
> > /**
> > + * @brief Sends a SMP message to a set of processors.
> > + *
> > + * The sending processor may be part of the set.
> > + *
> > + * @param[in] cpus The set of target processors of the
On 2014-07-04 11:56, Daniel Cederman wrote:
> I think it is a general bug if you change the trap responsible for the
> IPI after the start request of the secondary processors. At which point
> does this problem happen currently?
The trap responsible for IPIs is only set before the secondary
On 2014-07-04 11:56, Daniel Cederman wrote:
> With this implementation cache routines must not be called from
> interrupt context. This should be mentioned in the documentation.
>
> It is extremely difficult to implement it in a way so that it can be
> used from interrupt context.
There a
On 07/04/2014 11:52 AM, Sebastian Huber wrote:
On 2014-07-03 11:37, Daniel Cederman wrote:
/**
+ * @brief Sends a SMP message to a set of processors.
+ *
+ * The sending processor may be part of the set.
+ *
+ * @param[in] cpus The set of target processors of the message.
+ * @param[in] me
Thank you for you comments Sebastian!
> With this implementation cache routines must not be called from
> interrupt context. This should be mentioned in the documentation.
>
> It is extremely difficult to implement it in a way so that it can be
> used from interrupt context.
There are some sync
On 07/04/2014 08:25 AM, Sebastian Huber wrote:
On 2014-07-03 09:29, Daniel Hellstrom wrote:
By removing the bsp_reset() mechanism and instead relying on the
CPU_Fatal_halt() routine SMP and single-core can halt by updating
the _Internal_errors_What_happened structure and set the state to
SYSTEM_
Thank you for your comments Joel!
> I really don't like adding calls to anything BSP_xxx in score/cpu.
>
> Can this be done in bsp_postdriver_hook() for the LEON3?
It is only the main cpu that calls bsp_postdriver_hook() and the cache
invalidation code needs to be run on the secondary cpus. I c
> I think it is a general bug if you change the trap responsible for the
> IPI after the start request of the secondary processors. At which point
> does this problem happen currently?
The trap responsible for IPIs is only set before the secondary
processors are started and is not changed after
On 2014-07-03 11:37, Daniel Cederman wrote:
/**
+ * @brief Sends a SMP message to a set of processors.
+ *
+ * The sending processor may be part of the set.
+ *
+ * @param[in] cpus The set of target processors of the message.
+ * @param[in] message The message.
+ */
+void _SMP_Send_message_
On 07/03/2014 05:00 PM, Joel Sherrill wrote:
On 7/3/2014 2:29 AM, Daniel Hellstrom wrote:
By removing the bsp_reset() mechanism and instead relying on the
CPU_Fatal_halt() routine SMP and single-core can halt by updating
the _Internal_errors_What_happened structure and set the state to
SYSTEM_ST
On 07/03/2014 04:55 PM, Joel Sherrill wrote:
I am wondering if I don't have a vision for what this
series of patches is trying to accomplish in whole.
* make exit-code propagate to debugger/hypervisor. I though this would be nice
for other architectures as well.
* make SMP fatal exit work
* ins
Hello Joel,
Thanks for your comments.
On 07/03/2014 04:27 PM, Joel Sherrill wrote:
This looks mostly mechanical and the biggest issue is
what to do with the source in the generic shutdown
case. The first thing is that I think this is already handled
and the information is stored in
_Internal_
On 07/03/2014 04:48 PM, Joel Sherrill wrote:
I don't have a problem with this in principle but reviewing
the earlier patches and seeing similar names in other
BSPs makes me wonder if we can't get a better name.
Isn't this really just bsp_reset?
Yes it is, on LEON2 and ERC32, but not on LEON3. L
19 matches
Mail list logo
