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 Thu, Mar 15, 2018 at 7:00 AM, Udit agarwal wrote:
>
>
> On Thu, Mar 15, 2018 at 2:38 PM, Sebastian Huber
> wrote:
>>
>> On 15/03/18 09:20, Udit agarwal wrote:
>>>
>>> Also, will it be ok to keep atsam_trng_mutex even after user has finished
>>> using getentropy() i.e when we don't use destroy(
On Thu, Mar 15, 2018 at 2:38 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 15/03/18 09:20, Udit agarwal wrote:
>
>> Also, will it be ok to keep atsam_trng_mutex even after user has finished
>> using getentropy() i.e when we don't use destroy(&atsam_trng_mutex) at all?
>>
>
On 15/03/18 09:20, Udit agarwal wrote:
Also, will it be ok to keep atsam_trng_mutex even after user has
finished using getentropy() i.e when we don't use
destroy(&atsam_trng_mutex) at all?
Why do you want to destroy the mutex?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4,
On Thu, Mar 15, 2018 at 1:19 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 15/03/18 08:13, Udit agarwal wrote:
>
>> Oh yes, i think i misinterpreted your previous suggestion of surrounding
>> the while loop by mutex, it should be the outer while loop. some thing like
>> thi
On 15/03/18 08:13, Udit agarwal wrote:
Oh yes, i think i misinterpreted your previous suggestion of
surrounding the while loop by mutex, it should be the outer while
loop. some thing like this?:
while (n > 0) {
uint32_t random;
size_t copy;
rtems_mutex_lock(&atsam_trng_
On Thu, Mar 15, 2018 at 11:34 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
>
> On 15/03/18 05:56, Udit agarwal wrote:
>
>> +/* TRNG Register */
>> +
>> +/* RNG base address */
>>
>
> Is the module name TRNG or RNG?
>
It's TRNG. I'll correct this.
>
> +#define RNG_BASE 0x4831
On Thu, Mar 15, 2018 at 11:29 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
>
> On 15/03/18 05:56, Udit agarwal wrote:
>
>> c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/c/src/lib/libbsp/arm/atsam/startu
On 15/03/18 05:56, Udit agarwal wrote:
+/* TRNG Register */
+
+/* RNG base address */
Is the module name TRNG or RNG?
+#define RNG_BASE 0x4831
+/* RNG clock control */
+#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
This define is probably not for the TRNG register block.
On 15/03/18 05:56, Udit agarwal wrote:
c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c | 6 ++
1 file changed, 6 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..b26b6a8 100644
---
Hi,
Below is the updated patch along with the one for atsam. Please have a look.
Moreover, in error case(FRO unwanted shutdown), Error bit of status
register turns zero, indicating that FRO is no longer running.Untill now, i
haven't came across any situation where this bit turns 0. In the NETBSD
Ups. Hit reply instead of reply all. This should go to the mailing list.
--- Ursprüngliche Nachricht ---
>
> Am Mittwoch, 14. März 2018 schrieb Udit agarwal:
> > Hi,
> > @Joel This seems to be SoC specific.
> >
> >
> > So, here is the implementation with mutex, Do let me know if this is okay.
On 14/03/18 00:38, Udit agarwal wrote:
Hi,
@Joel This seems to be SoC specific.
Yes, it is an on-chip peripheral.
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_regis
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 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
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 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 pushing(Although i have done that once).
Thanks,
Udit agarwal
From 454a8ff3e0ea3393818859
Am 12.03.2018 um 20:02 schrieb Udit agarwal:
> 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 pushing(Although i have done that once).
>
> Thanks,
> Udit agarwal
>
Good news: I
21 matches
Mail list logo