On 26/06/2019 00:22, Chris Johns wrote:
On 25/6/19 9:59 pm, Sebastian Huber wrote:
Can't you use the
B4.1.94 ID_PFR1, Processor Feature Register 1, VMSA
and test for the Virtualization Extensions?
This is a neater solution. Can I assume the ASID support part of the
virtualization extensions
On 25/06/2019 18:03, Ravindra Kumar Meena wrote:
> +/* 1024 events are defined. The events are taking values from 0
to 1023. */
> +typedef enum events_e : uint64_t {
Does this make the enum forced into a 64-bit integer type?
Yes, the rtems_record_event variable is 64 bit.
On 26/06/2019 06:20, Ravindra Kumar Meena wrote:
> + ctf_item.event = __builtin_bswap32( item->event );
Why is there this byte swap?
It will set its value in big-endian.
What it does here depends on the native endian setting.
Since this value will be passed as
big-endian. I
>
>
> Is this working right? Please regenerate a single squashed patch.
> Check for git errors (no newline at end of file?)
>
> Just a thought, I'm not sure if it makes sense: Will we eventually
> need separate metadata files for each of the 4 kinds of record event
> layouts? 32b be, 32b le, 64b
>
>
> I had a look at the metadata file:
>
> typedef enum events_e : uint64_t_be {
>
Because I am passing the item->event value in big-endian byte order. This
will take passed value in big-endian byte order.
Now metadata trace description is in little-endian
trace {
major = 1;
minor = 8;
>
> > + ctf_item.event = __builtin_bswap32( item->event );
>
> Why is there this byte swap?
>
It will set its value in big-endian. Since this value will be passed as
big-endian. I have defined the typealias for the same in the metadata.
typealias integer { size = 64; align = 8; signed = false;
On 25/6/19 9:59 pm, Sebastian Huber wrote:
> Can't you use the
>
> B4.1.94 ID_PFR1, Processor Feature Register 1, VMSA
>
> and test for the Virtualization Extensions?
This is a neater solution. Can I assume the ASID support part of the
virtualization extensions and op 3 is consistent?
>
> I
Hello
I am sorry i was not able to inform on devel. I was feeling weakness, was
not well, so took rest. Couldn't work last 2 days. I will continue it now.
On Tue, Jun 25, 2019, 11:06 PM Gedare Bloom wrote:
> Hi Vaibhav,
>
> How did this turn out? I was surprised not to hear about this
>
Hi
I hate to ask a question which I could partially answer with grep but what
subset of stdatomic.h is used internally by RTEMS. An important
consideration of this question is did we have reasons to avoid any of the
APIs?
Any concerns about these not working on any particular processor? Failing?
On 25/06/2019 19:42, Gedare Bloom wrote:
> On Tue, Jun 25, 2019 at 10:36 AM Vijay Kumar Banerjee
> wrote:
>>
>>
>>
>> On Tue, Jun 25, 2019 at 9:32 PM Gedare Bloom wrote:
>>>
>>> On Tue, Jun 25, 2019 at 5:34 AM Vijay Kumar Banerjee
>>> wrote:
Hello,
The First Evaluation is
I had a look at the metadata file:
typedef enum events_e : uint64_t_be {
Why is it like this? Your structure looks like this:
typedef struct ctf_event {
uint32_t event_id;
uint64_t ns;
uint32_t cpu;
rtems_record_event
- Am 25. Jun 2019 um 19:32 schrieb Ravindra Kumar Meena rmeena...@gmail.com:
> Hi Sebastian,
>
> I have resolved the issue I was facing with rtems_record_event variable. I
> have sent the two patches. One is for stream file generation and another
> one is for metadata file for the same.
- Am 25. Jun 2019 um 19:18 schrieb Ravindra Kumar Meena rmeena...@gmail.com:
> ---
> misc/record/record-main.c | 26 +-
> 1 file changed, 9 insertions(+), 17 deletions(-)
>
> diff --git a/misc/record/record-main.c b/misc/record/record-main.c
> index cd7ef4f..7764109
On Tue, Jun 25, 2019 at 11:33 AM Ravindra Kumar Meena
wrote:
>
> Hi Sebastian,
>
> I have resolved the issue I was facing with rtems_record_event variable. I
> have sent the two patches. One is for stream file generation and another one
> is for metadata file for the same. Please apply the
Is this working right? Please regenerate a single squashed patch.
Check for git errors (no newline at end of file?)
Just a thought, I'm not sure if it makes sense: Will we eventually
need separate metadata files for each of the 4 kinds of record event
layouts? 32b be, 32b le, 64b be, 64b le? if
On Tue, Jun 25, 2019 at 10:36 AM Vijay Kumar Banerjee
wrote:
>
>
>
> On Tue, Jun 25, 2019 at 9:32 PM Gedare Bloom wrote:
>>
>> On Tue, Jun 25, 2019 at 5:34 AM Vijay Kumar Banerjee
>> wrote:
>> >
>> > Hello,
>> >
>> > The First Evaluation is going on and I here I would summarize all the
>> >
Hi Vaibhav,
How did this turn out? I was surprised not to hear about this
approach by now, and whether or not it worked for you.
You should post some updates to github, even if it is not working
code, on a branch or something, to show what you are trying out and to
have a history of what you
Hi Sebastian,
I have resolved the issue I was facing with rtems_record_event variable. I
have sent the two patches. One is for stream file generation and another
one is for metadata file for the same. Please apply the patches.
Now, babeltrace is able to read the stream file. I have cross-checked
---
misc/ctf/metadata | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/misc/ctf/metadata b/misc/ctf/metadata
index 068e4ba..3351575 100644
--- a/misc/ctf/metadata
+++ b/misc/ctf/metadata
@@ -4,10 +4,12 @@ typealias integer { size = 8; align = 8; signed = false; } :=
---
misc/record/record-main.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/misc/record/record-main.c b/misc/record/record-main.c
index cd7ef4f..7764109 100644
--- a/misc/record/record-main.c
+++ b/misc/record/record-main.c
@@ -146,20 +146,12 @@
On Tue, Jun 25, 2019 at 9:32 PM Gedare Bloom wrote:
> On Tue, Jun 25, 2019 at 5:34 AM Vijay Kumar Banerjee
> wrote:
> >
> > Hello,
> >
> > The First Evaluation is going on and I here I would summarize all the
> progress
> > that the project has made in the first Phase.
> >
> > 1. The major
On Tue, Jun 25, 2019 at 10:28 AM Ravindra Kumar Meena
wrote:
>>
>> I have only had a look at the specification, but according to
>> https://diamon.org/ctf/#spec4.1.3 you can set the global "byte_order" of
>> your stream in the trace description of your metadata file and override this
>>
>
> I have only had a look at the specification, but according to
> https://diamon.org/ctf/#spec4.1.3 you can set the global "byte_order" of
> your stream in the trace description of your metadata file and override
> this default behavior for certain types.
> In the metadata file of your
On Tue, Jun 25, 2019 at 6:13 AM Joel Sherrill wrote:
>
>
>
> On Fri, Jun 21, 2019 at 9:22 AM Vaibhav Gupta
> wrote:
>>
>>
>>
>> On Fri, Jun 21, 2019, 7:19 PM Joel Sherrill wrote:
>>>
>>>
>>>
>>> On Fri, Jun 21, 2019 at 3:37 AM Vaibhav Gupta
>>> wrote:
Hello,
I figured it out.
25th June work summary:
I sent the two patches today. One is for trace stream file generation and
another one is metadata file for the same. Babeltrace is printing only one
value wrong rest all values are correct. I think there is byte order issue
with it.
--
*Ravindra Kumar Meena*,
B. Tech.
On Tue, Jun 25, 2019 at 5:34 AM Vijay Kumar Banerjee
wrote:
>
> Hello,
>
> The First Evaluation is going on and I here I would summarize all the progress
> that the project has made in the first Phase.
>
> 1. The major progress is the completion of the I2C adaptation layer in the
> libbsd
>
On Mon, Jun 24, 2019 at 10:58 PM Ravindra Meena wrote:
>
> ---
> misc/ctf/metadata | 1059
> +
> 1 file changed, 1059 insertions(+)
> create mode 100644 misc/ctf/metadata
>
> diff --git a/misc/ctf/metadata b/misc/ctf/metadata
> new file mode
Hi Ravindra,
> -Ursprüngliche Nachricht-
> Von: devel [mailto:devel-boun...@rtems.org] Im Auftrag von Ravindra
> Kumar Meena
> Gesendet: Dienstag, 25. Juni 2019 14:39
> An: Sebastian Huber
> Cc: devel
> Betreff: Re: GSoC Project | Basic Support for Trace Compass
>
> Hi Sebastian,
>
>
Hi Sebastian,
Like I said that all values are correct(ns, CPU, data) except
rtems_record_event. This is happening because of byte order issue.
This is the warning output of babeltrace
[warning] Unknown value 927712935936 in enum.
0 RTEMS_RECORDING_EVENT: { ns = 4281426372217274368, cpu = 0,
On Fri, Jun 21, 2019 at 9:22 AM Vaibhav Gupta
wrote:
>
>
> On Fri, Jun 21, 2019, 7:19 PM Joel Sherrill wrote:
>
>>
>>
>> On Fri, Jun 21, 2019 at 3:37 AM Vaibhav Gupta
>> wrote:
>>
>>> Hello,
>>> I figured it out.
>>> .
>>> Below is the output given by shell
>>> ..
>>> ..
>>> ..
>>>
Can't you use the
B4.1.94 ID_PFR1, Processor Feature Register 1, VMSA
and test for the Virtualization Extensions?
I am not sure if pre ARMv7-AR processors have this register.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47
On Tue, Jun 25, 2019 at 5:04 PM Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:
> Hello,
>
> The First Evaluation is going on and I here I would summarize all the
> progress
> that the project has made in the first Phase.
>
> 1. The major progress is the completion of the I2C adaptation
Hello,
The First Evaluation is going on and I here I would summarize all the
progress
that the project has made in the first Phase.
1. The major progress is the completion of the I2C adaptation layer in the
libbsd
along with the iicbus driver imports. The v4 of the driver [1] has
been
From: Chris Johns
Closes #3760
---
bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
b/bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
index
On 25/06/2019 07:33, Chris Johns wrote:
On 25/6/19 2:50 pm, Ravindra Meena wrote:
misc/record/record-main.c | 38 +++---
I feel a top level directory for `trace` in rtems-tools will make is easier to
collect and group all trace relate code and tools. I suggest
On 25/06/2019 10:49, Ravindra Kumar Meena wrote:
> [242/254] Compiling misc/record/record-main.c
> ../misc/record/record-main.c: In function ‘print_item’:
> ../misc/record/record-main.c:152:14: warning: variable
‘seconds’ set
> but
> not used
On 25/06/2019 10:49, Ravindra Kumar Meena wrote:
> [242/254] Compiling misc/record/record-main.c
> ../misc/record/record-main.c: In function ‘print_item’:
> ../misc/record/record-main.c:152:14: warning: variable
‘seconds’ set
> but
> not used
>
> > [242/254] Compiling misc/record/record-main.c
> > ../misc/record/record-main.c: In function ‘print_item’:
> > ../misc/record/record-main.c:152:14: warning: variable ‘seconds’ set
> > but
> > not used [-Wunused-but-set-variable]
> >uint32_t seconds;
> >
From: Chris Johns
Closes #3762
---
bsps/arm/shared/cp15/arm-cp15-set-exception-handler.c | 9 +++--
cpukit/score/cpu/arm/include/libcpu/arm-cp15.h| 7 ++-
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/bsps/arm/shared/cp15/arm-cp15-set-exception-handler.c
On 25/06/2019 09:48, Ravindra Kumar Meena wrote:
> Do you get compiler warnings with this version?
>
>
> No I didn't get any compiler warning or error.
How did you configure the build? Did you somehow disable the warnings?
[242/254] Compiling
>
> > Hi Sebastian,
> >
> > I have sent the two patches. One is event stream file generation patch
> > and another one is metadata for it. Please apply the patches.
>
> Could you please check it in your rtems-tools repository.
>
Yes. I have already updated it. My rtems-tools workplace is
>
> > Do you get compiler warnings with this version?
> >
> >
> > No I didn't get any compiler warning or error.
>
> How did you configure the build? Did you somehow disable the warnings?
> [242/254] Compiling misc/record/record-main.c
> ../misc/record/record-main.c: In function
Hi,
First evaluatin of GSoC project has begun. It is from 24th June to 28th
June. I would like summarize everything I have done so far.
1. Updated the rtems-docs with the current state of generation of trace
record item from the QEMU target.
---
libbsd.py | 1 +
rtemsbsd/sys/dev/iicbus/rtems-i2c.c | 231
2 files changed, 232 insertions(+)
create mode 100644 rtemsbsd/sys/dev/iicbus/rtems-i2c.c
diff --git a/libbsd.py b/libbsd.py
index a25d3a8a..6ad046b8 100644
--- a/libbsd.py
---
freebsd/sys/dev/iicbus/iic.c| 506 ++
freebsd/sys/dev/iicbus/iic.h| 72
freebsd/sys/dev/iicbus/iicbus.c | 378
freebsd/sys/dev/iicbus/iicbus.h | 83 +
freebsd/sys/dev/iicbus/iiconf.c | 527
---
freebsd/usr.sbin/i2c/i2c.c| 35 +++
libbsd.py | 2 ++
rtemsbsd/include/machine/rtems-bsd-commands.h | 2 ++
rtemsbsd/include/rtems/netcmds-config.h | 2 ++
rtemsbsd/rtems/rtems-bsd-shell-i2c.c | 35
---
Makefile.todo | 13 ++
buildset/default.ini | 1 +
libbsd.py | 35
rtemsbsd/include/bsp/nexus-devices.h | 4 +
.../machine/rtems-bsd-kernel-namespace.h | 29 +++
---
freebsd/usr.sbin/i2c/i2c.c | 733 +
1 file changed, 733 insertions(+)
create mode 100644 freebsd/usr.sbin/i2c/i2c.c
diff --git a/freebsd/usr.sbin/i2c/i2c.c b/freebsd/usr.sbin/i2c/i2c.c
new file mode 100644
index ..084682a1
--- /dev/null
+++
On Tue, Jun 25, 2019 at 1:47 AM wrote:
> From: Christian Mauderer
>
> The old driver worked well for EEPROMS with the RTEMS EEPROM driver. But
> it had problems with a lot of other situations. Although it's not a
> direct port, the new driver is heavily modeled after the FreeBSD ti_i2c
>
49 matches
Mail list logo
