Hey everyone!
Here's a link to a draft of my proposal (also shared through the GSoC
website, and linked to on the wiki):
https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550GDvVDS5QufvAnFE/edit?usp=sharing
I'd appreciate all comments - even if you're just skimming, let me know if
you
Cheers! Thanks for taking the time to test them!
On Fri, Mar 16, 2018 at 10:06 PM Joel Sherrill wrote:
> Thanks.
>
> I just pushed these.
>
> I compiled all PC386 BSP family members with and without multiprocessing.
>
> --joel
>
> On Tue, Mar 13, 2018 at 11:14 AM, Amaan Cheval
> wrote:
>
>> Wh
On Mar 16, 2018 2:17 PM, "Gedare Bloom" wrote:
high-level comments:
* add citations to relevant literature that you used for inspiration.
* start to write a design plan for the bsp-level framework you envision.
* it would be a good idea to review the existing mmu support in RTEMS.
* link to this
From: Udit agarwal
---
c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
index 11e24dc..d3f1cf5 100644
--- a/c/src/lib/libbsp
Vijay,
On Fri, Mar 16, 2018 at 10:59 AM, Vijay Kumar Banerjee
wrote:
> building couverture-qemu from rtems-source-builder (
> https://github.com/cillianodonnell/rtems-source-builder/tree/couverture-build
> )
> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>
> I have attached the error
Yes this is something more than my build, I'll need someone a bit more
expert in the RSB to step in there. In the meantime, lets just build
couverture-qemu manually so we can see is everything else working.
git clone https://github.com/AdaCore/qemu
cd qemu
./configure --target-list=sparc-softmmu
high-level comments:
* add citations to relevant literature that you used for inspiration.
* start to write a design plan for the bsp-level framework you envision.
* it would be a good idea to review the existing mmu support in RTEMS.
* link to this google doc as your "Draft" from your GSoC applic
the same error comes when I try to build qemu from the
RTEMS/rtems-source-builder as well
is the issue coming from my system ? I'm using fedora 27 64bit
On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee"
wrote:
> yes , the same thing happens
>
> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell"
>
yes , the same thing happens
On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell"
wrote:
> If you build regular qemu with the RSB, does the same thing happen?
>
> Try
>
> ../source-builder/sb-set-builder --log=qemu_log.txt
> --prefix=$HOME/development/5 devel/qemu
>
>
> On 16 March 2018 at 16:48, Vija
Check out the csv file in rtems-docs/posix-compliance. Chris and I put
together a new POSIX Compliance Guide. It is on docs.rtems.org.
Check out the guide and the new csv. Up to date and lots of POSIX profiles.
:)
Even has guidance on finding methods to implement. Between that and the
ticket, sho
Hi
I just wanted to remind everyone that the deadline for applying
is March 27. I would encourage you all to go ahead and make sure
you are registered in the Google system and have submitted at
least the beginnings of your proposal. You can continue to edit
and refine. But if you forget to submit,
Sir,
I have prepared a draft proposal for GSoC 2018 as suggested by you.
I request you to please guide me whether I have made it correctly or not,
whether I have written some big plans or more things can be included.
The link for the Proposal is:
https://docs.google.com/document/d/1boKGnnzQGCzxIV
If you build regular qemu with the RSB, does the same thing happen?
Try
../source-builder/sb-set-builder --log=qemu_log.txt
--prefix=$HOME/development/5 devel/qemu
On 16 March 2018 at 16:48, Vijay Kumar Banerjee
wrote:
> still the same error
>
> -- vijay
>
> On 16 March 2018 at 21:39, Cillian
Are you interested in the POSIX Compliance project?
If so, you really need to get your proposal together and submitted. Then we
can worry about doing the work proposed. With no proposal, you can't
get accepted.
https://devel.rtems.org/ticket/2966 is the POSIX Compliance ticket. It
has sub-tickets
Hello Developers,
At this point of time, I have built the newlib for SPARC BSP and subscribed
myself for newlib mailing list.Could you please suggest me any library or
some of the functions that is needed to port to newlib? Any response from
your side would be
greatly appreciated.
That would be g
Hello Gedare,
thanks for taking a look at them.
Best regards
Christian
- Ursprüngliche Mail -
> Von: "Gedare Bloom"
> An: "Christian Mauderer"
> CC: "RTEMS Devel"
> Gesendet: Freitag, 16. März 2018 15:07:05
> Betreff: Re: Waiting for approval of three patches
> on it.
>
> On Fri, M
- Ursprüngliche Mail -
> Von: "Gedare Bloom"
> An: "Christian Mauderer"
> CC: "RTEMS Devel"
> Gesendet: Freitag, 16. März 2018 15:08:39
> Betreff: Re: [PATCH] bsp/atsam: Fix GMAC Rx Descriptor fields.
> On Wed, Mar 14, 2018 at 10:51 AM, Christian Mauderer
> wrote:
>> ---
>> bsps/arm/a
still the same error
-- vijay
On 16 March 2018 at 21:39, Cillian O'Donnell wrote:
> Just checked and the build was failing because one of the patches needed
> its hash to be updated to sha256. Just pushed that change. The build
> finishes successfully on my end. Pull that change into couverture
Thanks.
I just pushed these.
I compiled all PC386 BSP family members with and without multiprocessing.
--joel
On Tue, Mar 13, 2018 at 11:14 AM, Amaan Cheval
wrote:
> When it's a macro, a function declaration causes a compiler error due to
> the
> macro being expanded.
>
> Partial log showing
Just checked and the build was failing because one of the patches needed
its hash to be updated to sha256. Just pushed that change. The build
finishes successfully on my end. Pull that change into couverture-build
branch and try it again. I'm not seeing any automake stuff here, so just
check that a
building couverture-qemu from rtems-source-builder (
https://github.com/cillianodonnell/rtems-source-builder/tree/couverture-build
)
gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
I have attached the error report .
-- vijay
On 15 March 2018 at 19:17, Cillian O'Donnell wrote:
>
>
> O
From: Udit agarwal
---
bsps/arm/include/libcpu/am335x.h | 33 ++
c/src/lib/libbsp/arm/beagle/Makefile.am | 4 +-
c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c | 130 +++
3 files changed, 166 insertions(+), 1 deletion(-)
create mode 100644 c
On Tue, Mar 13, 2018 at 10:02 AM, Christian Mauderer
wrote:
> Some applications (like the civetweb web server) still use functions
> that are deprecated by openssl. If OPENSSL_NO_DEPRECATED is defined,
> openssl will not provide these functions. This patch removes the define
> so that the function
On Wed, Mar 14, 2018 at 10:51 AM, Christian Mauderer
wrote:
> ---
> bsps/arm/atsam/include/libchip/include/gmac.h | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/bsps/arm/atsam/include/libchip/include/gmac.h
> b/bsps/arm/atsam/include/libchip/include/gmac
on it.
On Fri, Mar 16, 2018 at 3:37 AM, Christian Mauderer
wrote:
> Hello,
>
> in the last three days I've sent a few patches to the mailing list.
> Would it be possible for one of our core maintainers to have a look at
> them and approve them (if they are OK) so that I can commit them?
>
> - 13.
Looks fine to me.
On Thu, Mar 15, 2018 at 4:09 AM, Christian Mauderer
wrote:
> ---
> rtemsbsd/sys/dev/atsam/if_atsam.c | 52
> +--
> 1 file changed, 44 insertions(+), 8 deletions(-)
>
> diff --git a/rtemsbsd/sys/dev/atsam/if_atsam.c
> b/rtemsbsd/sys/dev/atsa
Hello Udit,
Now I think you should re-send this patch as a separate submission. In
this case, it would also be a good idea to tag it as "v2". You can use
for this the "-v 2" command line argument to git-format-patch, and
then git-send-email on the output file(s). Probably, you may want to
resend y
Patch for BBB:
>From a6b3b58a38a6925bf26b6573f36fc652708f9f32 Mon Sep 17 00:00:00 2001
From: Udit agarwal
Date: Fri, 16 Mar 2018 15:37:05 +0530
Subject: [PATCH] arm/beagle: add TRNG based getentropy implementation
---
bsps/arm/include/libcpu/am335x.h | 33 ++
c/src/lib/libb
Thanks for pointing that out, I have rectified the indentation errors.
Here's the patch for atsam:
>From 8e5e17525a76e68bc4d869d0af9700aaa5628483 Mon Sep 17 00:00:00 2001
From: Udit agarwal
Date: Fri, 16 Mar 2018 14:54:53 +0530
Subject: [PATCH] arm/atsam: protect TRNG_GetRandData with mutex
---
On 16/03/18 08:01, Chris Johns wrote:
Hi,
The monitor commands are registered automatically in `rtems_shell_init_once()`
which means an application has no control over these being present, the command
mix and naming, for example there is a `config` command in the monitor.
I am not sure what to
We have hit this problem with rtems 4.10.
I think the monitor commands should be treated the same as the other shell
commands.
It should be possible to disable via shellconfig.h - by default all are
enabled, but that can be disabled.
In our application, the monitor 'exit' command was particula
Hi,
just my two cents: Would an additional call
'rtems_shell_init_once_commandset()' make sense, where the user can specify,
which comamnds are available?
I agree that changing the functionality of an existing call is not a good idea.
Thomas.
- Ursprüngliche Mail -
Von: "Chris Johns"
Hello,
in the last three days I've sent a few patches to the mailing list.
Would it be possible for one of our core maintainers to have a look at
them and approve them (if they are OK) so that I can commit them?
- 13.03.: [PATCH] openssl: Provide deprecated functions.
This one enables some extr
Hi,
The monitor commands are registered automatically in `rtems_shell_init_once()`
which means an application has no control over these being present, the command
mix and naming, for example there is a `config` command in the monitor.
I am not sure what to do, if it is removed some applications m
34 matches
Mail list logo
