>
> > Should I include whole metadata content in that char metadata[]?
>
> Yes, if everything is constant.
>
Okay
https://github.com/rmeena840/rtems-tools/commit/13c81bfb3a72dd777507f3bf92a96ec50ab7dd17
At the end of the file fwrite() is writing some small binary data. I don't
know why that is
>
> No, not a typedef. Something like this:
>
> diff --git a/misc/record/record-main.c b/misc/record/record-main.c
> index 314bb78..b5d1a66 100644
> --- a/misc/record/record-main.c
> +++ b/misc/record/record-main.c
> @@ -422,19 +422,28 @@ static rtems_record_client_status handler(
> return
On 08/08/2019 08:43, Ravindra Kumar Meena wrote:
No, not a typedef. Something like this:
diff --git a/misc/record/record-main.c b/misc/record/record-main.c
index 314bb78..b5d1a66 100644
--- a/misc/record/record-main.c
+++ b/misc/record/record-main.c
@@ -422,19 +422,28 @@
On 06/08/2019 21:22, Joel Sherrill wrote:
FWIW the pages converted by the high school students during Google Code-in
to be in the SW Eng Guide were from Wiki pages which ultimately need to be
deleted. There needs to be a pass to compare Rest version against the Wiki
version and then delete the
On Thu, Aug 8, 2019 at 1:06 PM Ravindra Kumar Meena
wrote:
> > Should I include whole metadata content in that char metadata[]?
>>
>> Yes, if everything is constant.
>>
> Okay
>
> https://github.com/rmeena840/rtems-tools/commit/13c81bfb3a72dd777507f3bf92a96ec50ab7dd17
>
>
> At the end of the
On Thu, Aug 8, 2019 at 1:02 AM Sebastian Huber
wrote:
>
> On 06/08/2019 21:22, Joel Sherrill wrote:
> > FWIW the pages converted by the high school students during Google Code-in
> > to be in the SW Eng Guide were from Wiki pages which ultimately need to be
> > deleted. There needs to be a pass
Hi
I had forgotten about this but someone reminded me. I don't know how close
to correct it is or what's deficient. The wiki blames Gedare for it.
https://devel.rtems.org/attachment/wiki/Developer/Coding/Conventions/rtems.uncrustify
-joel
___
devel
P.S. The link to "device-tree" section is not working.
On Thu, Aug 8, 2019 at 3:10 PM Gedare Bloom wrote:
>
> Vijay's copyright should probably go in the start of the user's manual.
>
> On Thu, Aug 8, 2019 at 7:38 AM Joel Sherrill wrote:
> >
> > Pushed. Thanks.
> >
> > I assume Gedare pinged
OK, this patch kills building gdb for RISC-V - I will resubmit with a proper
fix ...
Jiri.
On 8/8/19 10:45 PM, Jiri Gaisler wrote:
> Small patch for RSB to disable building sis inside gdb.
>
> I will follow up with a patch for rtems-tools to clean up rtems-test targets
> for sis ...
>
> Jiri.
Vijay's copyright should probably go in the start of the user's manual.
On Thu, Aug 8, 2019 at 7:38 AM Joel Sherrill wrote:
>
> Pushed. Thanks.
>
> I assume Gedare pinged you also about the objcopy :)
>
> --joel
>
> On Wed, Aug 7, 2019 at 5:12 PM Vijay Kumar Banerjee
> wrote:
>>
>> ---
>>
RSB does not longer install the stand-alone version of sis. Even though the RSB
log claims is does, the binary is not copied to the install location:
installing: sis-2.17-x86_64-linux-gnu-1 -> /opt/rtems/5 does nothing
There has been a few commits that changes the RSB install scripts
Small patch for RSB to disable building sis inside gdb.
I will follow up with a patch for rtems-tools to clean up rtems-test targets
for sis ...
Jiri.
>From 9165334d3ffe9996276de9c7843998124890c3e3 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler
Date: Thu, 8 Aug 2019 22:20:39 +0200
Subject:
This is really easy to fix and hopefully Jiri can produce a patch since I
am about to leave for the weekend.
The git master has this in erc32 configure.ac. It should be in both sis/
configure.ac and erc32/configure.ac
in our gdb 8.2.1 with patches.
# Keep in sync with gdb's configure.ac list.
This time it also works on RISC-V ... :-)
>From e5460e9ecb9995298319653460fab8852274c211 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler
Date: Thu, 8 Aug 2019 22:20:39 +0200
Subject: [PATCH] Disable built-in sis in gdb.
* Avoid building problems on Cygwin et al.
* Avoid mix-up with more recent
Unless it causes an issue, I would really like to leave sis enabled inside
gdb. It really is such a nice environment to debug.
On Thu, Aug 8, 2019, 4:47 PM Jiri Gaisler wrote:
> This time it also works on RISC-V ... :-)
>
> ___
> devel mailing list
>
I can confirm something is wrong. The install step does copy something
though, I get a tree like this:
/share/rtems/rsb:
sis-2.17-x86_64-linux-gnu-1.txt sis-2.17-x86_64-linux-gnu-1.xml
I gave --log option to sb-set-builder. I can see the build compiled.
It looks like %clean is running before
On Thu, Aug 8, 2019 at 3:53 PM Gedare Bloom wrote:
>
> I can confirm something is wrong. The install step does copy something
> though, I get a tree like this:
> /share/rtems/rsb:
> sis-2.17-x86_64-linux-gnu-1.txt sis-2.17-x86_64-linux-gnu-1.xml
>
> I gave --log option to sb-set-builder. I can
On 8/8/19 11:48 PM, Joel Sherrill wrote:
> Unless it causes an issue, I would really like to leave sis enabled inside
> gdb. It really is such a nice environment to debug.
Stand-alone sis has a gdb server, so the gdb debug environment should be
identical. In gdb, just do target extended-remote
print_item() cleanup:
https://github.com/rmeena840/rtems-tools/commit/76f1d2898729c9f885abaef1e33a58247c4760dd
What to do for bound access for api_id? Should I use exit( EXIT_SUCCESS )
for this?
The LTTng metadata also needs a license at the top. What should I add there?
Thanks
--
I think Sebastian wrote the configuration.
On Thu, Aug 8, 2019 at 9:53 AM Joel Sherrill wrote:
>
> Hi
>
> I had forgotten about this but someone reminded me. I don't know how close
> to correct it is or what's deficient. The wiki blames Gedare for it.
>
>
On Thu, Aug 8, 2019, 5:06 PM Jiri Gaisler wrote:
>
> On 8/8/19 11:48 PM, Joel Sherrill wrote:
>
> Unless it causes an issue, I would really like to leave sis enabled inside
> gdb. It really is such a nice environment to debug.
>
> Stand-alone sis has a gdb server, so the gdb debug environment
On 9/8/19 7:59 am, Gedare Bloom wrote:
> On Thu, Aug 8, 2019 at 3:53 PM Gedare Bloom wrote:
>>
>> I can confirm something is wrong. The install step does copy something
>> though, I get a tree like this:
>> /share/rtems/rsb:
>> sis-2.17-x86_64-linux-gnu-1.txt sis-2.17-x86_64-linux-gnu-1.xml
>>
rtems-main.c cleanup:
https://github.com/rmeena840/rtems-tools/commit/527fc0f2f3c971c21741b28b1f0ecde6efb6eb4a
Copyright added:
https://github.com/rmeena840/rtems-tools/commit/dc0cc02e805691bd0fd6a42abe4a0e068587c0ed
Have a look.
>
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and
Pushed. Thanks.
I assume Gedare pinged you also about the objcopy :)
--joel
On Wed, Aug 7, 2019 at 5:12 PM Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:
> ---
> user/bsps/arm/beagle.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On 08/08/2019 14:03, Ravindra Meena wrote:
+Step 4: After successfully connected to the target, we can get event records
+item from QEMU target text format by using the following commands:
+
+.. code-block:: none
+
+ cd rtems-tools
+ ./build/misc/rtems-record -H 169.254.XXX.XXX -p 1234 | head
Hi
If you are subscribed to the build@ mailing list, then you saw the flurry
of test
results from over night. I built every variant and ran the test suite with
RTEMS
debug on and off. Here are some observations:
+ rv64imafd only has one test pass
+ rv64_iamd_medany only has one test pass
+
---
images/user/event-recording-trace.png | Bin 0 -> 9573 bytes
images/user/event-recording-trace.puml | 12 +++
user/tracing/eventrecording.rst| 117 -
3 files changed, 128 insertions(+), 1 deletion(-)
create mode 100644 images/user/event-recording-trace.png
27 matches
Mail list logo
