On 26/7/19 4:23 pm, Sebastian Huber wrote:
> On 26/07/2019 07:41, Chris Johns wrote:
>> On 26/7/19 3:07 pm, Sebastian Huber wrote:
>>> On 26/07/2019 07:06, Sebastian Huber wrote:
Hello Chris,
I am not sure, if using r8 is the right thing to do since r8..r14 are
banked
in F
On 26/07/2019 07:41, Chris Johns wrote:
On 26/7/19 3:07 pm, Sebastian Huber wrote:
On 26/07/2019 07:06, Sebastian Huber wrote:
Hello Chris,
I am not sure, if using r8 is the right thing to do since r8..r14 are banked
in FIQ mode. I think the bsp_start_arm_drop_hyp_mode needs to be changed to
n
There are no known ARMv7-M chips with a dual lockstep mode.
Update #3773.
---
bsps/arm/shared/start/start.S | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S
index 80b7d44dbe..a7fd7eda62 100644
--- a/bsp
This makes it easier to review changes in start.S.
Update #3773.
---
bsps/arm/shared/start/bsp-start-init-registers.S | 105 ---
bsps/arm/shared/start/start.S| 59 -
c/src/lib/libbsp/arm/tms570/Makefile.am | 1 -
3 files changed, 55
This fixes the corruption of r3 by the call to
bsp_start_arm_drop_hyp_mode().
Moving the code makes it easier to review changes in start.S.
Close #3773.
---
bsps/arm/shared/start/bsp-start-in-hyp-support.S | 76
bsps/arm/shared/start/start.S| 42 +
On 26/7/19 3:42 pm, Sebastian Huber wrote:
> On 26/07/2019 07:37, Chris Johns wrote:
>> On 26/7/19 3:06 pm, Sebastian Huber wrote:
>>> Hello Chris,
>>>
>>> I am not sure, if using r8 is the right thing to do since r8..r14 are
>>> banked in
>>> FIQ mode.
>>
>> The ARM docs I referenced say the regi
On 26/07/2019 07:41, Chris Johns wrote:
On 26/7/19 3:07 pm, Sebastian Huber wrote:
On 26/07/2019 07:06, Sebastian Huber wrote:
Hello Chris,
I am not sure, if using r8 is the right thing to do since r8..r14 are banked
in FIQ mode. I think the bsp_start_arm_drop_hyp_mode needs to be changed to
n
On 26/07/2019 07:37, Chris Johns wrote:
On 26/7/19 3:06 pm, Sebastian Huber wrote:
Hello Chris,
I am not sure, if using r8 is the right thing to do since r8..r14 are banked in
FIQ mode.
The ARM docs I referenced say the register is general purpose. There is other
docs they say something else?
On 26/7/19 3:07 pm, Sebastian Huber wrote:
> On 26/07/2019 07:06, Sebastian Huber wrote:
>> Hello Chris,
>>
>> I am not sure, if using r8 is the right thing to do since r8..r14 are banked
>> in FIQ mode. I think the bsp_start_arm_drop_hyp_mode needs to be changed to
>> not touch r3, it can use r1 i
On 26/7/19 3:06 pm, Sebastian Huber wrote:
> Hello Chris,
>
> I am not sure, if using r8 is the right thing to do since r8..r14 are banked
> in
> FIQ mode.
The ARM docs I referenced say the register is general purpose. There is other
docs they say something else?
This is early boot code who wh
On 26/07/2019 07:06, Sebastian Huber wrote:
Hello Chris,
I am not sure, if using r8 is the right thing to do since r8..r14 are
banked in FIQ mode. I think the bsp_start_arm_drop_hyp_mode needs to be
changed to not touch r3, it can use r1 instead.
I think the code should move to start.S also.
Hello Chris,
I am not sure, if using r8 is the right thing to do since r8..r14 are
banked in FIQ mode. I think the bsp_start_arm_drop_hyp_mode needs to be
changed to not touch r3, it can use r1 instead.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germa
From: Chris Johns
- The RPi calls C code which trashes scratch registers.
Closes #3773
---
bsps/arm/shared/start/start.S | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S
index 80b7d44db
Hi
I just wanted to let everyone know that I have this pending on a branch and
can build it using the current but there is a problem linking libm on the
newlib git master. Once I have the RSB updated, I will look at pushing this.
To let Vaibhav continue pushing on fenv, if we decide the configure
On Tue, Jul 23, 2019, 8:57 PM Joel Sherrill wrote:
> Hi
>
> Just a note to remind you that we need to find a way to get the ndbm
> documentation into newlib. Since they put a marked up man page at the top
> of the .c file, I expect there are only two choices.
>
> (1) Put it at the top of ndbm.c a
Hi
I am in the middle of building tools with a newlib bump to include the ndbm
addition. When I commit the patch which adds a test, builds with older
toolsets will break.
I think I should conditionalize the test on the presence of one of the new
methods.
Thoughts?
--joel
___
Hi Joel,
unfortunately, Taster is closed-source, so that won't help.
I'll see what output I can get out of Frama-C and its open-source plugins.
Regards, Andrew
> On 25 Jul 2019, at 10:37, Andrew Butterfield
> wrote:
>
> Hi Joel,
>
> a quick answer:
>
>> On 24 Jul 2019, at 18:23, Joel Sher
Hi,
I just found out that the Module Dependencies don't have any influence on
the initialization process.
I have to look at SYSINIT and am currently reading their docs.
If anyone could point me to the rtems part of this, it would be great.
Best,
Nils
On Wed, 24 Jul 2019 at 16:53, Nils Hölscher
Hi Joel,
a quick answer:
> On 24 Jul 2019, at 18:23, Joel Sherrill wrote:
>
> Random question: Does Frama-C offer anything here?
I've found a Frama-C plugin called "Taster" that does this - seems to be built
around Airbus coding standards.
I'll do a bit more digging into this later today.
R
>
> > 1. Gather the information from two record events
> > (RTEMS_RECORD_THREAD_SWITCH_OUT and RTEMS_RECORD_THREAD_SWITCH_IN)
> with
> > the same timestamp on the same CPU.
> >
> > A CPU can have many records events. Since RTEMS_RECORD_THREAD_SWITCH_IN
> > is received after RTEMS_RECORD
On 25/07/2019 09:24, Ravindra Kumar Meena wrote:
>
https://github.com/rmeena840/rtems-tools/commit/f7838f156006064ffc53b1b1d3fb01f80ef15ae4
No, sorry, this is not what we need. Maybe you should delete this code
part and start from scratch.
We process record events and p
>
> >
> https://github.com/rmeena840/rtems-tools/commit/f7838f156006064ffc53b1b1d3fb01f80ef15ae4
>
> No, sorry, this is not what we need. Maybe you should delete this code
> part and start from scratch.
>
> We process record events and produce LTTNG events. Is this clear?
>
> Your task is:
>
> 1. G
22 matches
Mail list logo
