Hi
I have been working on updating the POSIX Compliance Guide for RTEMS. The
current guide has evaluations of RTEMS versus two versions of POSIX, COO,
C11, and an assortment of POSIX profiles.
What BSD specific APIs beyond POSIX does RTEMS support? I would like to
make the API list as complete as
Hi,
@Joel This seems to be SoC specific.
So, here is the implementation with mutex, Do let me know if this is okay.
I'll then do it for atsam also.
int getentropy(void *ptr, size_t n)
{
volatile am335x_trng_register *rng = (am335x_trng_register*) RNG_BASE;
rtems_mutex lock_trng_reg = RTE
On 09/03/2018 19:55, Sebastian Huber wrote:
> On 06/11/17 10:03, Sebastian Huber wrote:
>> On 26/10/17 08:22, Sebastian Huber wrote:
>>> Please review this patch carefully. It adds a new chapter "ARM Board Support
>>> Packages" following the "ARM Specific Information" chapter. It adds a
>>> templat
On 13/03/2018 17:52, Sebastian Huber wrote:
> On 13/03/18 07:50, Sebastian Huber wrote:
>> On 13/03/18 07:47, Chris Johns wrote:
>>> On 13/03/2018 17:18, Sebastian Huber wrote:
On 13/03/18 00:49, Chris Johns wrote:
> Set the inode size to 256 to work around a newlib scandir check where a
>
On Mar 13, 2018 1:31 AM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:
On 12/03/18 20:02, Udit agarwal wrote:
> So, It looks like here's the final patch, do let me know if its ready to
> be pushed. Also, it would be really helpful if someone else also tests this
> patch before
Am 13.03.2018 um 15:59 schrieb Udit agarwal:
> Hi,
> I have updated the patch, following were the changes:
> *Removed trialling white spaces and added new line at the end of each file
> *am335x_rng_enable() is now being called only once during initialization.
> *changed directory to /arm/beagle/de
I like the sound of that! One quick question.
> ...to get it running on qemu. Real HW would be a sanity check.
What kind of real hardware would I need? I do have an x86 64-bit processor
as my primary computer, and likely one on spare / abandoned devices too
(though I'll need to confirm). Is there
When it's a macro, a function declaration causes a compiler error due to the
macro being expanded.
Partial log showing error:
https://gist.github.com/AmaanC/ab3521141479aa6f61ea25f5d74ebb4d
Closes #3331
---
c/src/lib/libbsp/i386/shared/smp/smp-imps.c | 5 +
cpukit/score/cpu/i386/include/
With HAS_SMP set, we have:
libbsp_a_LIBADD += appstart.$(OBJEXT)
When trying to build appstart.o, however, we link start.o with appcpustart.o
through the linkcmds script, which leaves several symbols unresolved, and
without the "-r" (or -i) flag, this throws undefined reference errors.
This ch
This change, excluding the #error directive, lets us make progress towards
compiling i386 targets with --enable-smp.
The #error directive needs to be there since the CPU_Interrupt_frame is used by
the SMP context switching code, and this placeholder struct, if used, would only
lead to more subtle
See this thread[1] for v1 of the patch. The changes in this version
are similar, except they *still throw a compile-time error* to
indicate the missing i386 support for SMP, while still fixing up the
rest of the problems that prevented compilation, as suggested by Joel
here[2].
[1] https://lists.r
Hi,
I have updated the patch, following were the changes:
*Removed trialling white spaces and added new line at the end of each file
*am335x_rng_enable() is now being called only once during initialization.
*changed directory to /arm/beagle/dev/bbb_getentropy.c
*Renamed TRNG register structure as:
On Tue, Mar 13, 2018 at 8:46 AM, Vidushi Vashishth
wrote:
> Hello!
>
> I am Vidushi Vashishth from Netaji Subhas Institute of Technology, Delhi
> and I intend to participate in the selection procedure for GSOC'18. I have
> already submitted the Hello world patch. The past couple of days I have
>
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 functions are available.
---
libbsd.py | 3 +--
libbsd_waf.py | 2 +-
2
On 12/03/18 16:43, Christian Mauderer wrote:
This adds a simple function for setting the PIO drive strength.
Thanks, looks good.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : se
Hello!
I am Vidushi Vashishth from Netaji Subhas Institute of Technology, Delhi
and I intend to participate in the selection procedure for GSOC'18. I have
already submitted the Hello world patch. The past couple of days I have
been going through the open projects and I am interested in the ones be
On Mar 13, 2018 1:36 AM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:
On 12/03/18 21:20, Gedare Bloom wrote:
> Since I'm pretty keen on RTEMS, I think I'll have a 2nd proposal too, which
>> I'll decide and discuss with you guys soon, hopefully! (Perhaps the
>> tracing
>> or the
17 matches
Mail list logo