Re: Query for GSOC Project

[Udit agarwal]

Hello Christian, Vaibhav, Sebastian,

On Mon, Mar 4, 2019 at 3:18 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Am 04.03.19 um 07:47 schrieb Sebastian Huber:
> > Hello Vaibhav Gupta,
> >
> > On 04/03/2019 07:27, Vaibhav Gupta wrote:
> >> I am unable to confirm, if the project is open for GSOC, as some of
> >> them are labelled as new/ need for funding, etc.
> >> So, I made a list of projects which I find interesting. It would be
> >> very helpful for me to finalize a project if mentors confirm which of
> >> the following projects are open/ not open for GSOC.
> >>
> >>  1. #3476 : IMFS- Improve bytes per block handling. :
> >> https://devel.rtems.org/ticket/3476
> >>  2. #3477 : IMFS - Add Configurable Allocator Support :
> >> https://devel.rtems.org/ticket/3477
> >>
> >
> > the IMFS tickets contain not enough work for a GSoC project.
> >
> >>  1. #3338 : Port CHFS to RTEMS : https://devel.rtems.org/ticket/3338
> >>
> >
> > This would be suitable GSoC project if you find a mentor. It needs to
> > deal also with the Erase Block Handler (EBH).
> >
> >>  1. #3428 : Add SDIO driver support to rtems-libbsd :
> >> https://devel.rtems.org/ticket/3428
> >> 
> >>
> >
> > I am not sure what the status of this is, it was a GSoC project before.
> > My experience is that this is close to the hardware level and difficult
> > to debug if you don't have a JTAG debugger.
>
> Last year Udit worked on this project (CC on this mail). See the
> following for the status reports:
>
> https://devel.rtems.org/wiki/GSoC/2018#UditkumarAgarwal
>
> The really relevant part of the status is the one from July 18th: The
> driver already started to work but it was still not fully functional.
> After that some more benchmarks have been carried out due to some slight
> direction change in the project.
>
> For SDIO the stack would have to be updated to the latest version of
> libbsd and some debugging would be necessary. That is most likely not
> enough work left for a complete project.
>
> Yes, For more detailed status of SDIO stack please have a look at the
following blog posts: (1
,
2 ).
The code has to be updated as per the latest version of libbsd and as
Sebastian pointed out, for debugging
purpose i'd strong recommend the use of JTAG debugger. However, it's a bit
short of being a fully-fledged GSoC project.

Also, How about the idea of porting DTrace to RTEMS? I'm not very sure
about its feasibility, but probably it can turn
out to be a significant addition in RTEMS.

> Kind regards
>
> Christian
>
> >
> > Please also have a look at the open projects page:
> >
> > https://devel.rtems.org/wiki/Developer/OpenProjects
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>


-- 
Regards,
Udit kumar agarwal
http://uditagarwal.in/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Invalid block size of 512B while setting up RFS on RAMDisk

[Udit agarwal]

On Mon, Sep 10, 2018 at 8:19 AM Chris Johns  wrote:

> On 10/09/2018 12:30, Udit agarwal wrote:
> > Hi list,
> > While setting up RFS with a block size of 512B on a RAMDisk, I had an
> I/O error
> > while formatting /dev/rda using mkrfs shell command.
> > Same procedure repeated for RFS on sd-card/USB-stick did worked with
> 512B block
> > size.
> > Any advice or a fix?
> >
> > BTW, my ramdisk block size is 512B with block count of 262144. and BSP
> used is
> > BeagleBone Black.
>
> Are you able to make a small test case?
>
> Yup, i'll make one to reproduce the error.

> Thanks
> Chris
>


-- 
Regards,
Udit kumar agarwal
http://uditagarwal.in/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Invalid block size of 512B while setting up RFS on RAMDisk

[Udit agarwal]

Hi list,
While setting up RFS with a block size of 512B on a RAMDisk, I had an I/O
error while formatting /dev/rda using mkrfs shell command.
Same procedure repeated for RFS on sd-card/USB-stick did worked with 512B
block size.
Any advice or a fix?

BTW, my ramdisk block size is 512B with block count of 262144. and BSP used
is BeagleBone Black.
-- 
Regards,
Udit kumar agarwal
http://uditagarwal.in/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[GSoC] Status update: Adding IO Benchmark to RTEMS

[Udit agarwal]

Hi all,
We've managed to run fio on RTEMS. Currently, the following IOengines are
working: psync, vsync ,sync, null, filecreate, ftruncate. Following are the
rough sd card(with FAT fs) benchmarking results i got:
During a read operation:

>
> IOPS=201, BW=804KiB/s

And during a write operation:

> IOPS=56, BW=224KiB/s

Here <https://gist.github.com/madaari/54a6c43c69a95e7b7d7a61632c8dfda6> are
the complete results. I''ve documented the procedure on my blog
<http://uditagarwal.in/> and updated the ticket #3429
<https://devel.rtems.org/ticket/3429> with the leftovers.
Immediate goal after this is to get the generated code merged upstream to
fio's main repository, i'm working on that, but that can move in parallel
with phase 2 objectives.

Regards,
Udit AGarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] beagle: Disable WiFi if libbsd is build without it.

[Udit agarwal]

Hi,
Thanks, that patch worked perfectly. Wifi is now, by default disabled.

Regards,
Udit agarwal

On Wed, May 30, 2018 at 5:04 PM, Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Update #3351.
> ---
>  rtemsbsd/include/bsp/nexus-devices.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/rtemsbsd/include/bsp/nexus-devices.h
> b/rtemsbsd/include/bsp/nexus-devices.h
> index 13d51ceb..f7003923 100644
> --- a/rtemsbsd/include/bsp/nexus-devices.h
> +++ b/rtemsbsd/include/bsp/nexus-devices.h
> @@ -37,6 +37,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
>
> @@ -58,6 +59,7 @@ SYSINIT_DRIVER_REFERENCE(usbss, simplebus);
>  SYSINIT_DRIVER_REFERENCE(musbotg, usbss);
>  SYSINIT_DRIVER_REFERENCE(sdhci_ti, simplebus);
>  SYSINIT_DRIVER_REFERENCE(mmcsd, mmc);
> +#ifdef RTEMS_BSD_MODULE_IEEE80211
>  SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
>  SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
>  SYSINIT_MODULE_REFERENCE(wlan_sta);
> @@ -66,6 +68,7 @@ SYSINIT_MODULE_REFERENCE(wlan_wep);
>  SYSINIT_MODULE_REFERENCE(wlan_tkip);
>  SYSINIT_MODULE_REFERENCE(wlan_ccmp);
>  SYSINIT_REFERENCE(rtwn_rtl8188eufw);
> +#endif /* RTEMS_BSD_MODULE_IEEE80211 */
>
>  RTEMS_BSD_DRIVER_USB;
>  RTEMS_BSD_DRIVER_USB_MASS;
> --
> 2.13.6
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

[Udit agarwal]

Hi all,
While cross-compiling fio for RTEMS, by default in the compiler call

>  -U_FORTIFY_SOURCE   -D_FORTIFY_SOURCE=2

options are used which raises the following error:

> /home/uka_in/development/benchmark/sandbox/5/lib/gcc/arm-rtems5/7.3.0/include/ssp/unistd.h:38:10:
> fatal error: ssp.h: No such file or directory
>  #include 
>   ^~~
> compilation terminated.
> make: *** [crc/crc32c-arm64.o] Error 1
>
> However, ssp.h is in the same folder.
Without these options, only sys/unistd.h is included and not the
ssp/unistd.h. Any idea why these compiler opts are raising these error?

Also, FIO needs a BSP independent method for determining the size of RAM
for it's internal working.  I'm unable to figure out any such
implementation. Any help on this too, would be great.

Regards,
Udit agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: LIST OF IO BENCHMARKS

[Udit agarwal]

Hi Gedare, Hi Joel,

On Mon, May 21, 2018 at 6:53 PM, Gedare Bloom  wrote:

> "License type customized" is not clear to me what that means, it would
> be worth explaining
>
>
In case of IOZONE's license <http://www.iozone.org/docs/Iozone_License.txt>
,  by customized license type, I just mean that it's not one of  standard
OSS licenses like GPL, BSD etc.
BTW, My domain name's DNS is currently misconfigured, website can be
accessed from here <http://81.4.107.225/wordpress/>. And for backup, I have
exported the
wordpress content to blogger(here <http://nerdyclap.blogspot.in/>). (There
are some alignment issues after exporting, mainly due to the custom CSS i
was using, i'll fix that ASAP)

Regards,
Udit Agarwal

On Sun, May 20, 2018 at 7:32 PM, Joel Sherrill  wrote:
> >
> >
> > On Sat, May 19, 2018, 5:06 PM Udit agarwal 
> wrote:
> >>
> >> Hi,
> >>
> >> On Fri, May 18, 2018 at 11:19 PM, Gedare Bloom 
> wrote:
> >>>
> >>> Udit,
> >>>
> >>> Can you please compare pros/cons of FIO, IOZONE, and Bonnie++,
> >>> probably in a blog post is a good idea.
> >>
> >> Done, here is the comparison.
> >
> >
> > That url has a hard-coded IP address in it. GSoC blogs should be hosted
> > somewhere where they will have a long life with stable URLs.
> >
> > It looks nice though. :)
> >
> >>>
> >>> The GPLv2 is not a problem for test suites / benchmarks. It is only a
> >>> problem for code that should get merged into the rtems.git.
> >>>
> >>> Gedare
> >>>
> >>> On Thu, May 17, 2018 at 5:20 AM, Udit agarwal 
> >>> wrote:
> >>> > Hi all,
> >>> > As discussed in yesterday's IRC meeting, here is the list of
> different
> >>> > IO
> >>> > benchmarks(which are supported by FreeBSD) in the decreasing order of
> >>> > their
> >>> > popularity  :
> >>> >
> >>> > FIO - License type:  GPLv2 - Widely accepted for storage device
> >>> > benchmarking
> >>> > IOZONE - License: Customized - Large number of features, Also used
> for
> >>> > storage benchmarking
> >>> > Bonnie++ - GPLv2 - Widely known filesystem benchmark, Not much used
> for
> >>> > storage benchmarking.
> >>> > IOMETER -  GPLv2 - Out of active development.
> >>> > IORATE - Flexible - Out of active development
> >>> >
> >>> > I have performed SDIO-SDHCI performance analysis using IOZONE. Here
> are
> >>> > the
> >>> > results. And i have documented the process on my blog.
> >>> >
> >>> > Regards,
> >>> >
> >>> > Udit Agarwal
> >>> >
> >>> >
> >>> > ___
> >>> > devel mailing list
> >>> > devel@rtems.org
> >>> > http://lists.rtems.org/mailman/listinfo/devel
> >>
> >>
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: LIST OF IO BENCHMARKS

[Udit agarwal]

Hi,

On Fri, May 18, 2018 at 11:19 PM, Gedare Bloom  wrote:

> Udit,
>
> Can you please compare pros/cons of FIO, IOZONE, and Bonnie++,
> probably in a blog post is a good idea.
>
Done, here
<http://81.4.107.225/wordpress/index.php/2018/05/19/comparing-io-benchmarks-fio-iozone-and-bonnie/>
is the comparison.

>
> The GPLv2 is not a problem for test suites / benchmarks. It is only a
> problem for code that should get merged into the rtems.git.
>
> Gedare
>
> On Thu, May 17, 2018 at 5:20 AM, Udit agarwal 
> wrote:
> > Hi all,
> > As discussed in yesterday's IRC meeting, here is the list of different IO
> > benchmarks(which are supported by FreeBSD) in the decreasing order of
> their
> > popularity  :
> >
> > FIO - License type:  GPLv2 - Widely accepted for storage device
> benchmarking
> > IOZONE - License: Customized - Large number of features, Also used for
> > storage benchmarking
> > Bonnie++ - GPLv2 - Widely known filesystem benchmark, Not much used for
> > storage benchmarking.
> > IOMETER -  GPLv2 - Out of active development.
> > IORATE - Flexible - Out of active development
> >
> > I have performed SDIO-SDHCI performance analysis using IOZONE. Here are
> the
> > results. And i have documented the process on my blog.
> >
> > Regards,
> >
> > Udit Agarwal
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Query regarding disk cache in RTEMS

[Udit agarwal]

On Fri, May 18, 2018 at 11:17 PM, Gedare Bloom  wrote:

> Udit,
>
> On Thu, May 17, 2018 at 9:13 AM, Udit agarwal 
> wrote:
> > Hi all,
> > I was looking at the internal working of a benchmark and the way it
> disables
> > cache for direct IO operations, needed to benchmark storage device
> drivers.
> > I have a small query regarding how cache is organized in RTEMS:
> >
> > Usually data transfer model is something like:
> > Application address space --> Page cache --> Write-back cache --> storage
> > device
> > is this model valid for RTEMS too?
> >
> > Moreover, in FreeBSD/Linux, O_DIRECT flag is used with the file
> descriptor
> > to bypass write-back cache. do we have something like that in RTEMS?
> AFAIK,
> > In RTEMS, libblock is used to transfer data to the storage device. So,
> > configuring it like:
> >>
> >>  #define CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS 0
> >
> > should disable the cache? or is there any other setting that should be
> > tweaked?
> >
>
> I think you are on the right path. We have bdbuf cache as the way to
> buffer block I/O operations. I don't know if that option is enough to
> turn off caching. You should check the user manual, and inspect the
> code.
>
> Sure, We also found that the page cache(that i mentioned up there) was
maintained in newlib itself and can be configured by setvbuf() command.

> > Regards,
> > Udit
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Query regarding disk cache in RTEMS

[Udit agarwal]

Hi all,
I was looking at the internal working of a benchmark and the way it
disables cache for direct IO operations, needed to benchmark storage device
drivers. I have a small query regarding how cache is organized in RTEMS:

Usually data transfer model is something like:
Application address space --> Page cache --> Write-back cache --> storage
device
is this model valid for RTEMS too?

Moreover, in FreeBSD/Linux, O_DIRECT flag is used with the file descriptor
to bypass write-back cache. do we have something like that in RTEMS? AFAIK,
In RTEMS, libblock is used to transfer data to the storage device. So,
configuring it like:

>  #define CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS 0
>
should disable the cache? or is there any other setting that should be
tweaked?

Regards,
Udit
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

LIST OF IO BENCHMARKS

[Udit agarwal]

Hi all,
As discussed in yesterday's IRC meeting, here is the list of different IO
benchmarks(which are supported by FreeBSD) in the decreasing order of their
popularity  :

   1. FIO - License type:  GPLv2
   <https://github.com/redhat-cip/fio/blob/master/COPYING> - Widely
   accepted for storage device benchmarking
   2. IOZONE - License: Customized
   <http://www.iozone.org/docs/Iozone_License.txt> - Large number of
   features, Also used for storage benchmarking
   3. Bonnie++ - GPLv2 - Widely known filesystem benchmark, Not much used
   for storage benchmarking.
   4. IOMETER -  GPLv2 - Out of active development.
   5. IORATE - Flexible <https://sites.google.com/site/vwiorate/home> - Out
   of active development

I have performed SDIO-SDHCI performance analysis using IOZONE. Here
<https://sites.google.com/site/vwiorate/home> are the results. And i have
documented the process on my blog
<http://81.4.107.225/wordpress/index.php/2018/05/17/microsd-card-benchmarking-on-beaglebone-black/>
.

Regards,

Udit Agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC'18 proposal - Porting SDIO driver and benchmarking

[Udit agarwal]

Hi,
We can't really merge the back-ported code with the current libbsd version
to avoid version inconsistency.
Thus, i am proposing to prepare all the necessary changes(patches), which
can be applied once the libbsd receives it's next update.


On Tue, Mar 20, 2018 at 9:14 PM, Gedare Bloom  wrote:

> I have a question about the high-level goal of this project. Is it to
> produce a back-ported version of the stack to our current libbsd, or
> is to prepare the changes necessary to apply to libbsd when it gets
> updated to a newer FreeBSD containing the sdio stack, or both?
>
> On Tue, Mar 20, 2018 at 11:41 AM, Udit agarwal 
> wrote:
> > Hi,
> >
> > On Sun, Mar 18, 2018 at 8:48 PM, Christian Mauderer 
> > wrote:
> >>
> >> Am 18.03.2018 um 14:22 schrieb Udit agarwal:
> >> > Hi all,
> >> > Here's the link to my proposal:
> >> >
> >> > https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtR
> eF_P-wNR861NMo/edit?usp=sharing
> >> >
> >> > Please have a look, and comment where ever needed.
> >> > I tried my best to make time-line as realistic as possible. Please
> feel
> >> > free to comment in case of any unbalance or overlooked task.
> >> >
> >> > Regards,
> >> > Udit agarwal
> >> >
> >> >
> >>
> >> Hello Udit,
> >>
> >> some (not too well sorted) notes:
> >>
> >> 1. One point I'm missing is the target that you produce a set of patches
> >> that can be easily merged as soon as the libbsd receives it's next
> >> update. Otherwise the only result from that project would be the
> >> comparison document.
> >>
> > That's a really good idea! I have now included that in my proposal,
> please
> > have a look.
> >>
> >>
> >> 2. I'm not sure whether the point
> >>
> >>   "Backport the SDIO driver residing within the mmccam stack to FreeBSD
> >> version being used by libbsd"
> >>
> >> is a good idea. It sounds like you want to do the backport on FreeBSD.
> >> You most likely would have a lot of work with that without any really
> >> useful results. It would be better to analyse whether some other
> >> subsystems might have an influence on the performance measurement (which
> >> I would expect to be quite few) and then do the backport directly on
> >> RTEMS libbsd.
> >>
> > Noted. I have corrected this. Moreover, i am studying several files
> > changed/modified during
> > the mmccam commit and as of now, i didn't  came across any such Non-RTEMS
> > dependency
> > that might affect systems performance. I have a query here, in
> RTEMS-libbsd
> > cam directory, there are some files
> > like cam.h and cam_ccb.h belonging to different FreeBSD head versions.
> Is it
> > because, since there has been no change in the file, so its not updated?
> >>
> >>
> >> 3. It seems that you have split up the test bench over all three phases.
> >> It might would be more efficient to search a test bench and get it
> >> running on FreeBSD as well as on RTEMS quite early. There should be no
> >> difference whether it runs on the old SD-card driver, the SDIO one or
> >> some USB stick. It should basically work with with any block device.
> >>
> >> If you start to port it to RTEMS in phase 3 and then find out that it
> >> doesn't work like expected, you will have to restart with searching some
> >> other test bench. This would mean that you can throw away all results of
> >> the workbench that you collected in between.
> >>
> > I have corrected this. So, now the first phase, I'll be porting SDIO
> driver,
> > and in the second and third phase, I'll focus on the benchmarking task.
> > Hopefully, now we have ample time to fallback and search for another
> > benchmarks in case the first one didn't work expectedly.
> >>
> >>
> >> 4. I'm not quite sure whether the amount of work would really fill all
> >> three phases. Maybe you should plan an extended goal. With that topic
> >> that could for example be a benchmark for some other drivers (like USB
> >> storage).
> >>
> > Done.
> >>
> >>
> >> 5. Currently your results are a document and a set of patches that
> >> (hopefully) can be integrated into libbsd in the future. I think that if
> >> you find some good standard performance test for block devices, porting
> >> that could be another core result that can be integrated directly and
> >> not only after a libbsd upgrade.
> >>
> > I came across several popular, multipurpose I/O benchmarks like IOZone
> and
> > IOrate with compatible license(1,2). Since, these are FreeBSD compatible
> > probably they will work. Still, I have added 'Searching and testing
> > benchmarks on FreeBSD' as one of my goal.
> >>
> >> With kind regards
> >>
> >> Christian Mauderer
> >
> >
> > Regards,
> > Udit agarwal
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC'18 proposal - Porting SDIO driver and benchmarking

[Udit agarwal]

Hi,

On Sun, Mar 18, 2018 at 8:48 PM, Christian Mauderer 
wrote:

> Am 18.03.2018 um 14:22 schrieb Udit agarwal:
> > Hi all,
> > Here's the link to my proposal:
> > https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtR
> eF_P-wNR861NMo/edit?usp=sharing
> >
> > Please have a look, and comment where ever needed.
> > I tried my best to make time-line as realistic as possible. Please feel
> > free to comment in case of any unbalance or overlooked task.
> >
> > Regards,
> > Udit agarwal
> >
> >
>
> Hello Udit,
>
> some (not too well sorted) notes:
>
> 1. One point I'm missing is the target that you produce a set of patches
> that can be easily merged as soon as the libbsd receives it's next
> update. Otherwise the only result from that project would be the
> comparison document.
>
> That's a really good idea! I have now included that in my proposal, please
have a look.

>
> 2. I'm not sure whether the point
>
>   "Backport the SDIO driver residing within the mmccam stack to FreeBSD
> version being used by libbsd"
>
> is a good idea. It sounds like you want to do the backport on FreeBSD.
> You most likely would have a lot of work with that without any really
> useful results. It would be better to analyse whether some other
> subsystems might have an influence on the performance measurement (which
> I would expect to be quite few) and then do the backport directly on
> RTEMS libbsd.
>
> Noted. I have corrected this. Moreover, i am studying several files
<http://blog.uditagarwal.in/index.php/2018/03/19/implementing-a-mmc-sd-sdio-stack-using-cam-framework/>
changed/modified during
the mmccam commit and as of now, i didn't  came across any such Non-RTEMS
dependency
that might affect systems performance. I have a query here, in RTEMS-libbsd
<https://github.com/RTEMS/rtems-libbsd/tree/master/freebsd/sys/cam> cam
directory, there are some files
like cam.h and cam_ccb.h belonging to different FreeBSD head versions. Is
it because, since there has been no change in the file, so its not updated?

>
> 3. It seems that you have split up the test bench over all three phases.
> It might would be more efficient to search a test bench and get it
> running on FreeBSD as well as on RTEMS quite early. There should be no
> difference whether it runs on the old SD-card driver, the SDIO one or
> some USB stick. It should basically work with with any block device.
>
> If you start to port it to RTEMS in phase 3 and then find out that it
> doesn't work like expected, you will have to restart with searching some
> other test bench. This would mean that you can throw away all results of
> the workbench that you collected in between.
>
> I have corrected this. So, now the first phase, I'll be porting SDIO
driver, and in the second and third phase, I'll focus on the benchmarking
task. Hopefully, now we have ample time to fallback and search for another
benchmarks in case the first one didn't work expectedly.

>
> 4. I'm not quite sure whether the amount of work would really fill all
> three phases. Maybe you should plan an extended goal. With that topic
> that could for example be a benchmark for some other drivers (like USB
> storage).
>
> Done.

>
> 5. Currently your results are a document and a set of patches that
> (hopefully) can be integrated into libbsd in the future. I think that if
> you find some good standard performance test for block devices, porting
> that could be another core result that can be integrated directly and
> not only after a libbsd upgrade.
>
> I came across several popular, multipurpose I/O benchmarks like IOZone and
IOrate with compatible license(1
<http://www.iozone.org/docs/Iozone_License.txt>,2
<https://sites.google.com/site/vwiorate/home>). Since, these are FreeBSD
compatible probably they will work. Still, I have added 'Searching and
testing benchmarks on FreeBSD' as one of my goal.

> With kind regards
>
> Christian Mauderer
>

Regards,
Udit agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC'18 proposal - Porting SDIO driver and benchmarking

[Udit agarwal]

Hi all,
Here's the link to my proposal:
https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtReF_P-wNR861NMo/edit?usp=sharing

Please have a look, and comment where ever needed.
I tried my best to make time-line as realistic as possible. Please feel
free to comment in case of any unbalance or overlooked task.

Regards,
Udit agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Query regarding libbsd update

[Udit agarwal]

Hi,
Thanks for pointing that out. I think back porting the driver would be the
most viable option. So, i'll move ahead with that.
Since, my proposal is almost ready, considering other libbsd projects at
this time, would be a bit difficult.

Thanks and regards,
Udit agarwal

On Sun, Mar 18, 2018 at 2:39 AM, Christian Mauderer 
wrote:

> Am 17.03.2018 um 19:40 schrieb Udit agarwal:
> > Hi Sebastian, Hi all,
> > One part of my GSoC project consists of importing SDIO driver from
> > FreeBSD head (as on july 2017 or later). As far as importing is
> > concerned there is a lot of information in libbsd.txt or on previous
> > GSoC student's blogs which can help me understand the process. However,
> > before importing i also need to update libbsd base to FreeBSD head(as on
> > july 2017 or later). I couldn't find much information regarding this
> > update process. It would be really helpful if you point me towards its
> > relevant documentation or give me a gist of the whole process. That
> > would again help me understand the process better, and thus propose a
> > more elaborated and realistic time-line.
> >
> > Thanks and Regards
> > Udit agarwal
> >
>
> Hello Udit,
>
> there is no step-by-step guide (or any other guide) regarding a complete
> FreeBSD update. That has to do with the fact that there is no standard
> way to do it. Each update is quite unique.
>
> The basic steps are the following ones:
>
> - Use the freebsd-to-rtems.py script to move the changes to freebsd-org
> folder.
>
> - Rebase the changes in freebsd-org to the latest head.
>
> - Re-Import the files with freebsd-to-rtems.py.
>
> - Take a look at what changed in FreeBSD and fix everything.
>
> The first three are easy. The last one is really hard if you don't know
> the code.
>
> I have seen that you are able to search through code quite quickly. But
> I also have seen that you had some trouble with the mutex in the
> getentropy patch. Although I'm sure you don't have problems learning the
> necessary basics I think that it is quite likely that it will use up too
> much time of the project. So I would suggest to plan the alternative
> solution: Backport the driver. Although with that there will be no patch
> that we can integrate into the current libbsd, it is a solution that is
> doable in the scope of your GSoC project.
>
> If you prefer to produce code that will be integrated quickly, you can
> still think about the other libbsd projects.
>
> Regards
>
> Christian Mauderer
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Query regarding libbsd update

[Udit agarwal]

Hi Sebastian, Hi all,
One part of my GSoC project consists of importing SDIO driver from FreeBSD
head (as on july 2017 or later). As far as importing is concerned there is
a lot of information in libbsd.txt or on previous GSoC student's blogs
which can help me understand the process. However, before importing i also
need to update libbsd base to FreeBSD head(as on july 2017 or later). I
couldn't find much information regarding this update process. It would be
really helpful if you point me towards its relevant documentation or give
me a gist of the whole process. That would again help me understand the
process better, and thus propose a more elaborated and realistic time-line.

Thanks and Regards
Udit agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added Getentropy() support to beagle BSP

[Udit agarwal]

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/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/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c

diff --git a/bsps/arm/include/libcpu/am335x.h
b/bsps/arm/include/libcpu/am335x.h
index 367e97c..a6fb8b8 100644
--- a/bsps/arm/include/libcpu/am335x.h
+++ b/bsps/arm/include/libcpu/am335x.h
@@ -14,11 +14,17 @@
  * Modified by Ben Gras  to add lots
  * of beagleboard/beaglebone definitions, delete lpc32xx specific
  * ones, and merge with some other header files.
+ *
+ * Modified by Udit agarwal  to add true random
+ * number generating module definitions and TRNG register structure.
  */

 #if !defined(_AM335X_H_)
 #define _AM335X_H_

+/* For TRNG register definition */
+#include 
+
 /* Interrupt controller memory map */
 #define OMAP3_DM37XX_INTR_BASE 0x4820 /* INTCPS physical address */

@@ -701,4 +707,31 @@
 #define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
(0x0020u)
 #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF

+/* TRNG Registers */
+/* TRNG base address */
+#define TRNG_BASE 0x4831
+/* Mask bits for trng clock status */
+#define AM335X_CLK_TRNG_BIT_MASK (0x3)
+/* Mask bits for output ready flag */
+#define TRNG_STATUS_RDY (1u <<  0)
+/* Mask bits for FRO related error */
+#define TRNG_STATUS_ERR (1u <<  1)
+/* Mask bits for clock status */
+#define TRNG_STATUS_CLK (1u << 31)
+/* enable module */
+#define AM335X_TRNG_ENABLE (1 << 10)
+
+/* TRNG module clock register */
+#define CM_PER_TRNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
+
+/* TRNG register structure */
+typedef struct {
+  uint64_t output; /* 00 */
+  uint32_t status; /* 08 */
+  uint32_t irq_en; /* 0c */
+  uint32_t status_clr; /* 10 */
+  uint32_t control;/* 14 */
+  uint32_t config; /* 18 */
+} am335x_trng_register;
+
 #endif
diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 8251660..c483dc4 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -40,7 +40,6 @@ libbsp_a_LIBADD =

 # Shared
 libbsp_a_SOURCES += ../../shared/bootcard.c
-libbsp_a_SOURCES += ../../shared/getentropy-cpucounter.c
 libbsp_a_SOURCES += ../../shared/src/bsp-fdt.c
 libbsp_a_SOURCES += ../../shared/bspclean.c
 libbsp_a_SOURCES += ../../shared/bspgetworkarea.c
@@ -88,6 +87,9 @@ libbsp_a_SOURCES += gpio/bbb-gpio.c
 #pwm
 libbsp_a_SOURCES += pwm/pwm.c

+#getentropy
+libbsp_a_SOURCES += dev/bbb_getentropy.c
+
 #RTC
 libbsp_a_SOURCES += rtc.c
 libbsp_a_SOURCES += ../../shared/tod.c
diff --git a/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
new file mode 100644
index 000..b3ea681
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
@@ -0,0 +1,130 @@
+/**
+* @file
+*
+* @ingroup arm_beagle
+*
+* @brief Getentropy implementation on BeagleBone Black BSP
+*/
+
+/*
+* Copyright (c) 2018 Udit agarwal 
+* All rights reserved.
+*
+* Redistribution and use in source and binary forms, with or without
+* modification, are permitted provided that the following conditions
+* are met:
+* 1. Redistributions of source code must retain the above copyright
+*notice, this list of conditions and the following disclaimer.
+* 2. Redistributions in binary form must reproduce the above copyright
+*notice, this list of conditions and the following disclaimer in the
+*documentation and/or other materials provided with the distribution.
+*
+* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
+* ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
+* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT
+* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+* SUCH DAMAGE.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* max refill 34 * 256 cycles */
+#define AM335X_TRNG_MAX_REFILL (34 << 16)
+/* min refill 33 * 64 cycles */
+#define AM335X_TRNG_MIN_REFILL (33 << 0)
+/* startup 33 * 256 cycles */
+#define AM33

Re: [PATCH] Added Getentropy() support to beagle BSP

[Udit agarwal]

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

---
 c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

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..54a1cef 100644
--- a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
+++ b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
@@ -17,6 +17,9 @@
 #include 
 #include 

+static rtems_mutex atsam_trng_mutex =
+RTEMS_MUTEX_INITIALIZER("atsam_trng");
+
 static void atsam_trng_enable(void)
 {
  PMC_EnablePeripheral(ID_TRNG);
@@ -25,6 +28,8 @@ static void atsam_trng_enable(void)

 int getentropy(void *ptr, size_t n)
 {
+  rtems_mutex_lock(&atsam_trng_mutex);
+
  while (n > 0) {
uint32_t random;
size_t copy;
@@ -50,7 +55,7 @@ int getentropy(void *ptr, size_t n)
n -= copy;
ptr += copy;
  }
-
+  rtems_mutex_unlock(&atsam_trng_mutex);
  return 0;
 }

-- 
1.9.1

On Thu, Mar 15, 2018 at 7:52 PM, Gedare Bloom  wrote:

> 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(&atsam_trng_mutex) at
> all?
> >>
> >>
> >> Why do you want to destroy the mutex?
> >
> > Just trying to reduce redundancy, but then i don't think that's a good
> idea.
> > BTW, here's atsam patch, please have a look:
> >
> > From 35313002ea19715c5914c5983a24471b0763aa68 Mon Sep 17 00:00:00 2001
> > From: Udit agarwal 
> > Date: Thu, 15 Mar 2018 16:21:51 +0530
> > Subject: [PATCH] Added mutex across TRNG_GetRandData
>
> In the commit message, identify the rtems subsystem. I guess we don't
> have detailed advice on the wiki for this, but here I guess we usually
> would have something like "arm/atsam: protect TRNG_GetRandData with
> mutex"
>
> >
> > ---
> >  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..2789970 100644
> > --- a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
> > +++ b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
> > @@ -16,6 +16,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +
> > +static rtems_mutex atsam_trng_mutex =
> > RTEMS_MUTEX_INITIALIZER("atsam_trng");
> >
> The second line should be indented 2 more levels (4 spaces).
> https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line
>
> >  static void atsam_trng_enable(void)
> >  {
> > @@ -25,6 +28,9 @@ static void atsam_trng_enable(void)
> >
> >  int getentropy(void *ptr, size_t n)
> >  {
> > +
> > +rtems_mutex_lock(&atsam_trng_mutex);
> The number of indent spaces here look wrong to me. It should be 2.
>
> > +
> >  while (n > 0) {
> >  uint32_t random;
> >  size_t copy;
> > @@ -51,6 +57,7 @@ int getentropy(void *ptr, size_t n)
> >  ptr += copy;
> >  }
> >
> > +rtems_mutex_unlock(&atsam_trng_mutex);
> ditto.
>
> >  return 0;
> >  }
> >
> > --
> > 1.9.1
> >
> >
> >>
> >>
> >>
> >> --
> >> 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  : sebastian.hu...@embedded-brains.de
> >> PGP : Public key available on request.
> >>
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >>
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added Getentropy() support to beagle BSP

[Udit agarwal]

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?
>>
>
> Why do you want to destroy the mutex?

Just trying to reduce redundancy, but then i don't think that's a good
idea. BTW, here's atsam patch, please have a look:

>From 35313002ea19715c5914c5983a24471b0763aa68 Mon Sep 17 00:00:00 2001
From: Udit agarwal 
Date: Thu, 15 Mar 2018 16:21:51 +0530
Subject: [PATCH] Added mutex across TRNG_GetRandData

---
 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..2789970 100644
--- a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
+++ b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
@@ -16,6 +16,9 @@
 #include 
 #include 
 #include 
+#include 
+
+static rtems_mutex atsam_trng_mutex =
RTEMS_MUTEX_INITIALIZER("atsam_trng");

 static void atsam_trng_enable(void)
 {
@@ -25,6 +28,9 @@ static void atsam_trng_enable(void)

 int getentropy(void *ptr, size_t n)
 {
+
+rtems_mutex_lock(&atsam_trng_mutex);
+
 while (n > 0) {
 uint32_t random;
 size_t copy;
@@ -51,6 +57,7 @@ int getentropy(void *ptr, size_t n)
 ptr += copy;
 }

+rtems_mutex_unlock(&atsam_trng_mutex);
 return 0;
 }

-- 
1.9.1



>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, G
> <https://maps.google.com/?q=ess+:+Dornierstr.+4,+D-82178+Puchheim,+G&entry=gmail&source=g>
> ermany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added Getentropy() support to beagle BSP

[Udit agarwal]

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
>> this?:
>> while (n > 0) {
>> uint32_t random;
>> size_t copy;
>>
>> rtems_mutex_lock(&atsam_trng_mutex);
>>
>
> Now you correctly use the mutex to produce 32-bits of random data.
> Currently the likely user of getrandom() is
>
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=
> blob;f=newlib/libc/stdlib/arc4random.c;h=33ed46a5e9e
> 756d4e216cb7686589eb60993;hb=HEAD#l89
>
> So, you need 12 mutex lock/unlock operations for this. I would protect the
> while (n > 0) loop with a single mutex lock/unlock.

Ok,Like this?
rtems_mutex_lock(&atsam_trng_mutex);
while (n > 0) {
   .
   .
}
rtems_mutex_unlock(&atsam_trng_mutex);

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?

>
>
> --
> 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  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added Getentropy() support to beagle BSP

[Udit agarwal]

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
>> +/* RNG clock control */
>> +#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
>>
>
> This define is probably not for the TRNG register block. Should it move
> the corresponding register block?
>
This define is to enable clock for TRNG module by setting the bit in the
main clock register. Should i place this define with other CM definitions?

>
> +/* rng module clock status bits */
>> +#define AM335X_CLK_RNG_BIT_MASK (0x3)
>> +/* Offset from RNG base for output ready flag */
>> +#define RNG_STATUS_RDY (1u <<  0)
>> +/* Offset from RNG base for FRO related error */
>> +#define RNG_STATUS_ERR (1u <<  1)
>> +/* Offset from RNG base for clock status */
>> +#define RNG_STATUS_CLK (1u << 31)
>>
>
> Are these offsets or bits?
>
I should have probably marked them as mask bits.

>
> +/* enable module */
>> +#define AM335X_RNG_ENABLE (1 << 10)
>> +
>>
>
> --
> 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  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added Getentropy() support to beagle BSP

[Udit agarwal]

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/startup/getentropy-trng.c
>> b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
>> index 11e24dc..b26b6a8 100644
>> --- a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
>> +++ b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
>> @@ -17,6 +17,8 @@
>>  #include 
>>  #include 
>>
>> +static rtems_mutex atsam_trng_reg = RTEMS_MUTEX_INITIALIZER("atsam
>> _trng_reg");
>>
>
> Is this a register or a mutex?
>

> +
>>  static void atsam_trng_enable(void)
>>  {
>>  PMC_EnablePeripheral(ID_TRNG);
>> @@ -29,9 +31,12 @@ int getentropy(void *ptr, size_t n)
>>  uint32_t random;
>>  size_t copy;
>>
>> +rtems_mutex_lock(&atsam_trng_reg);
>>  while ((TRNG_GetStatus() & TRNG_ISR_DATRDY) == 0) {
>>  /* wait */
>>  }
>> +
>> +rtems_mutex_unlock(&atsam_trng_reg);
>>
>
> Now the status register read is protected by a mutex.
>
> random = TRNG_GetRandData();
>>
>
> Can you ensure that this read is correct in a multi-threaded application
> (the status register has the right value during the read)?
>
> 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_mutex);

while ((TRNG_GetStatus() & TRNG_ISR_DATRDY) == 0) {
/* wait */
}

random = TRNG_GetRandData();

/*
 * Read TRNG status one more time to avoid race condition.
 * Otherwise we can read (and clear) an old ready status but get
 * a new value. The ready status for this value wouldn't be
 * reset.
 */
TRNG_GetStatus();

copy = sizeof(random);
if (n < copy ) {
copy = n;
}
memcpy(ptr, &random, copy);
n -= copy;
ptr += copy;

rtems_mutex_unlock(&atsam_trng_mutex);
}


>
>>  /*
>> @@ -51,6 +56,7 @@ int getentropy(void *ptr, size_t n)
>>  ptr += copy;
>>  }
>>
>> +rtems_mutex_destroy(&atsam_trng_reg);
>>
>
> Here  you destroy the mutex. What happens if you call getentropy() a
> second time?


> return 0;
>>  }
>>
>
> --
> 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  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added Getentropy() support to beagle BSP

[Udit agarwal]

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
<http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/arm/omap/am335x_trng.c>
and in linux kernel
<https://github.com/torvalds/linux/blob/68fed41e0ff6c0332520a0d70ac05be2a7d9130e/drivers/char/hw_random/omap-rng.c>
(line 241 ) implementation of am335x_trng, it seems they aren't checking
for this bit. Instead they are only using RNG_STATUS_RDY as an indication
of successful random data generation.

*Patch: atsam*

>From ae0c79ae4850503259c64387dea69346e7d7b1d4 Mon Sep 17 00:00:00 2001
From: Udit agarwal 
Date: Thu, 15 Mar 2018 09:43:13 +0530
Subject: [PATCH] Fixed mutual exclusion of critical section

---
 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
--- a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
+++ b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
@@ -17,6 +17,8 @@
 #include 
 #include 

+static rtems_mutex atsam_trng_reg =
RTEMS_MUTEX_INITIALIZER("atsam_trng_reg");
+
 static void atsam_trng_enable(void)
 {
 PMC_EnablePeripheral(ID_TRNG);
@@ -29,9 +31,12 @@ int getentropy(void *ptr, size_t n)
 uint32_t random;
 size_t copy;

+rtems_mutex_lock(&atsam_trng_reg);
 while ((TRNG_GetStatus() & TRNG_ISR_DATRDY) == 0) {
 /* wait */
 }
+
+rtems_mutex_unlock(&atsam_trng_reg);
 random = TRNG_GetRandData();

 /*
@@ -51,6 +56,7 @@ int getentropy(void *ptr, size_t n)
 ptr += copy;
 }

+rtems_mutex_destroy(&atsam_trng_reg);
 return 0;
 }

-- 
1.9.1

*Patch BBB*

>From ea885f9681c14f324917469b295e7489f56c10e7 Mon Sep 17 00:00:00 2001
From: Udit agarwal 
Date: Thu, 15 Mar 2018 09:24:35 +0530
Subject: [PATCH] Added getentropy support to beagle BSP

---
 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 | 126
+++
 3 files changed, 162 insertions(+), 1 deletion(-)
 create mode 100644 c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c

diff --git a/bsps/arm/include/libcpu/am335x.h
b/bsps/arm/include/libcpu/am335x.h
index 367e97c..6170ef3 100644
--- a/bsps/arm/include/libcpu/am335x.h
+++ b/bsps/arm/include/libcpu/am335x.h
@@ -14,11 +14,17 @@
  * Modified by Ben Gras  to add lots
  * of beagleboard/beaglebone definitions, delete lpc32xx specific
  * ones, and merge with some other header files.
+ *
+ * Modified by Udit agarwal  to add random
+ * number generating module definitions and TRNG register structure.
  */

 #if !defined(_AM335X_H_)
 #define _AM335X_H_

+/* For TRNG register definition */
+#include 
+
 /* Interrupt controller memory map */
 #define OMAP3_DM37XX_INTR_BASE 0x4820 /* INTCPS physical address */

@@ -701,4 +707,31 @@
 #define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
(0x0020u)
 #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF

+/* TRNG Register */
+
+/* RNG base address */
+#define RNG_BASE 0x4831
+/* RNG clock control */
+#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
+/* rng module clock status bits */
+#define AM335X_CLK_RNG_BIT_MASK (0x3)
+/* Offset from RNG base for output ready flag */
+#define RNG_STATUS_RDY (1u <<  0)
+/* Offset from RNG base for FRO related error */
+#define RNG_STATUS_ERR (1u <<  1)
+/* Offset from RNG base for clock status */
+#define RNG_STATUS_CLK (1u << 31)
+/* enable module */
+#define AM335X_RNG_ENABLE (1 << 10)
+
+/* TRNG register structure */
+typedef struct {
+  uint64_t output; /* 00 */
+  uint32_t status; /* 08 */
+  uint32_t irq_en; /* 0c */
+  uint32_t status_clr; /* 10 */
+  uint32_t control;/* 14 */
+  uint32_t config; /* 18 */
+} am335x_trng_register;
+
 #endif
diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 8251660..c483dc4 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -40,7 +40,6 @@ libbsp_a_LIBADD =

 # Shared
 libbsp_a_SOURCES += ../../shared/bootcard.c
-libbsp_a_SOURCES += ../../shared/getentropy-cpucounter.c
 libbsp_a_SOURCES += ../../shared/src/bsp-fdt.c
 libbsp_a_SOURCES += ../../shared/bspclean.c
 libbsp_a_SOURCES += ../../shared/bspgetworkarea.c
@@ -88,6 +87,9 @@ libbsp_a_SOURCES += gpio/bbb-gpio.c
 #pwm
 libbsp_a_SOURCES += pwm/pwm.c

+#getentropy
+libbsp_a_SOURCES += dev/bbb_getentropy.c
+
 #RTC
 libbsp_a_SOURCES += rtc.c

Re: [PATCH] Added Getentropy() support to beagle BSP

[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.
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 = RTEMS_MUTEX_INITIALIZER("lock_trng_reg");

while (n > 0)
{
uint64_t random;
size_t copy;

/* for mutual exclusion synchronization between multiple
   access to TRNG register in different contexts */
rtems_mutex_lock(&lock_trng_reg);

/* wait untill RNG becomes ready with next set of random data */
while( ( rng->status & RNG_STATUS_RDY ) == 0 )
{
/* wait */
}

random = trng_getranddata(rng);
/* clear the status flag after reading to generate new random
   value */
rng->status_clr = RNG_STATUS_RDY;
rtems_mutex_unlock(&lock_trng_reg);

/* checking for error by masking all bits other then error bit in
   status register */
if( ((rng->status & RNG_STATUS_ERR)>>1) == 1)
{
copy = sizeof(random);
if ( n < copy )
{
copy = n;
}
memcpy(ptr, &random, copy);
n -= copy;
ptr = (char*)ptr + copy;
}
}

rtems_mutex_destroy(&lock_trng_reg);
return 0;
}


On Wed, Mar 14, 2018 at 2:15 AM, Joel Sherrill  wrote:

>
>
> On Mar 13, 2018 1:31 AM, "Sebastian Huber"  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 pushing(Although i have done that once).
>>
>> Thanks,
>> Udit agarwal
>>
>>
>> From 454a8ff3e0ea3393818859874705a54b098c6081 Mon Sep 17 00:00:00 2001
>> From: Udit agarwal mailto:dev.mada...@gmail.com>>
>>
>> Date: Tue, 13 Mar 2018 00:20:28 +0530
>> Subject: [PATCH] Added Getentropy() support to beagle BSP
>>
>> ---
>>  bsps/arm/include/libcpu/am335x.h   |  37 ++-
>>  c/src/lib/libbsp/arm/beagle/Makefile.am|   4 +-
>>  .../libbsp/arm/beagle/getentropy/bbb_getentropy.c  | 116
>> +
>>  3 files changed, 155 insertions(+), 2 deletions(-)
>>  create mode 100644 c/src/lib/libbsp/arm/beagle/ge
>> tentropy/bbb_getentropy.c
>>
>> diff --git a/bsps/arm/include/libcpu/am335x.h
>> b/bsps/arm/include/libcpu/am335x.h
>> index 367e97c..cedd637 100644
>> --- a/bsps/arm/include/libcpu/am335x.h
>> +++ b/bsps/arm/include/libcpu/am335x.h
>> @@ -14,11 +14,17 @@
>>   * Modified by Ben Gras > b...@shrike-systems.com>> to add lots
>>
>>   * of beagleboard/beaglebone definitions, delete lpc32xx specific
>>   * ones, and merge with some other header files.
>> + *
>> + * Modified by Udit agarwal > dev.mada...@gmail.com>> to add random
>>
>> + * number generating module definitions and TRNG register structure.
>>   */
>>
>>  #if !defined(_AM335X_H_)
>>  #define _AM335X_H_
>>
>> +/* For TRNG register definition */
>> +#include 
>> +
>>  /* Interrupt controller memory map */
>>  #define OMAP3_DM37XX_INTR_BASE 0x4820 /* INTCPS physical address */
>>
>> @@ -701,4 +707,33 @@
>>  #define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
>> (0x0020u)
>>  #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF
>>
>> -#endif
>> +/* TRNG Register */
>> +
>> +/* RNG base address */
>> +#define RNG_BASE 0x4831
>> +/* RNG clock control */
>> +#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
>> +/* rng module clock status bits */
>> +#define AM335X_CLK_RNG_BIT_MASK (0x3)
>> +/* Offset from RNG base for output ready flag */
>> +#define RNG_STATUS_RDY (1u <<  0)
>> +/* Offset from RNG base for FRO related error */
>> +#define RNG_STATUS_ERR (1u <<  1)
>> +/* Offset from RNG base for clock status */
>> +#define RNG_STATUS_CLK (1u << 31)
>> +/* enable module */
>> +#define AM335X_RNG_ENABLE (1 << 10)
>> +
>> +/* TRNG register structure */
>> +struct bbb_trng_register
>> +{
>> +uint64_t output; /* 00 */
>> +uint32_t status; /* 08 */
>> +uint32_t irq_en; /* 0c */
>> +uint32_t status_clr; /* 10 */
>> +uint32_t control;/* 14 */
>> +uint32_t config; /* 

Re: [PATCH] Added Getentropy() support to beagle BSP

[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/dev/bbb_getentropy.c
*Renamed TRNG register structure as: am335x_trng_register
I have tested the patch after making above changes and it worked as before.

I need some suggestion regarding the solution to the problem raised during
parallel execution of getentropy(),
In that case, Two processes can actually fetch same random number. I was
thinking to implement some sort of
flag set/reset variable in shared memory, which can be used to implement a
lock for TRNG register access something
like a binary semaphore.

>From b10e55c7f5cc8ca95b0d9b6a8cc7b8e37330544b Mon Sep 17 00:00:00 2001
From: Udit agarwal 
Date: Tue, 13 Mar 2018 15:50:43 +0530
Subject: [PATCH] Added getentropy support to Beagle BSP

---
 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 | 117
+++
 3 files changed, 153 insertions(+), 1 deletion(-)
 create mode 100644 c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c

diff --git a/bsps/arm/include/libcpu/am335x.h
b/bsps/arm/include/libcpu/am335x.h
index 367e97c..6170ef3 100644
--- a/bsps/arm/include/libcpu/am335x.h
+++ b/bsps/arm/include/libcpu/am335x.h
@@ -14,11 +14,17 @@
  * Modified by Ben Gras  to add lots
  * of beagleboard/beaglebone definitions, delete lpc32xx specific
  * ones, and merge with some other header files.
+ *
+ * Modified by Udit agarwal  to add random
+ * number generating module definitions and TRNG register structure.
  */

 #if !defined(_AM335X_H_)
 #define _AM335X_H_

+/* For TRNG register definition */
+#include 
+
 /* Interrupt controller memory map */
 #define OMAP3_DM37XX_INTR_BASE 0x4820 /* INTCPS physical address */

@@ -701,4 +707,31 @@
 #define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
(0x0020u)
 #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF

+/* TRNG Register */
+
+/* RNG base address */
+#define RNG_BASE 0x4831
+/* RNG clock control */
+#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
+/* rng module clock status bits */
+#define AM335X_CLK_RNG_BIT_MASK (0x3)
+/* Offset from RNG base for output ready flag */
+#define RNG_STATUS_RDY (1u <<  0)
+/* Offset from RNG base for FRO related error */
+#define RNG_STATUS_ERR (1u <<  1)
+/* Offset from RNG base for clock status */
+#define RNG_STATUS_CLK (1u << 31)
+/* enable module */
+#define AM335X_RNG_ENABLE (1 << 10)
+
+/* TRNG register structure */
+typedef struct {
+  uint64_t output; /* 00 */
+  uint32_t status; /* 08 */
+  uint32_t irq_en; /* 0c */
+  uint32_t status_clr; /* 10 */
+  uint32_t control;/* 14 */
+  uint32_t config; /* 18 */
+} am335x_trng_register;
+
 #endif
diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 8251660..c483dc4 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -40,7 +40,6 @@ libbsp_a_LIBADD =

 # Shared
 libbsp_a_SOURCES += ../../shared/bootcard.c
-libbsp_a_SOURCES += ../../shared/getentropy-cpucounter.c
 libbsp_a_SOURCES += ../../shared/src/bsp-fdt.c
 libbsp_a_SOURCES += ../../shared/bspclean.c
 libbsp_a_SOURCES += ../../shared/bspgetworkarea.c
@@ -88,6 +87,9 @@ libbsp_a_SOURCES += gpio/bbb-gpio.c
 #pwm
 libbsp_a_SOURCES += pwm/pwm.c

+#getentropy
+libbsp_a_SOURCES += dev/bbb_getentropy.c
+
 #RTC
 libbsp_a_SOURCES += rtc.c
 libbsp_a_SOURCES += ../../shared/tod.c
diff --git a/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
new file mode 100644
index 000..b2aea71
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
@@ -0,0 +1,117 @@
+/**
+* @file
+*
+* @ingroup arm_beagle
+*
+* @brief Getentropy implementation on BeagleBone Black BSP
+*/
+
+/*
+* Copyright (c) 2018 Udit agarwal 
+* All rights reserved.
+*
+* Redistribution and use in source and binary forms, with or without
+* modification, are permitted provided that the following conditions
+* are met:
+* 1. Redistributions of source code must retain the above copyright
+*notice, this list of conditions and the following disclaimer.
+* 2. Redistributions in binary form must reproduce the above copyright
+*notice, this list of conditions and the following disclaimer in the
+*documentation and/or other materials provided with the distribution.
+*
+* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
+* ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+* FOR ANY DIRECT, I

[PATCH] Added Getentropy() support to beagle BSP

[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


>From 454a8ff3e0ea3393818859874705a54b098c6081 Mon Sep 17 00:00:00 2001
From: Udit agarwal 
Date: Tue, 13 Mar 2018 00:20:28 +0530
Subject: [PATCH] Added Getentropy() support to beagle BSP

---
 bsps/arm/include/libcpu/am335x.h   |  37 ++-
 c/src/lib/libbsp/arm/beagle/Makefile.am|   4 +-
 .../libbsp/arm/beagle/getentropy/bbb_getentropy.c  | 116
+
 3 files changed, 155 insertions(+), 2 deletions(-)
 create mode 100644 c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c

diff --git a/bsps/arm/include/libcpu/am335x.h
b/bsps/arm/include/libcpu/am335x.h
index 367e97c..cedd637 100644
--- a/bsps/arm/include/libcpu/am335x.h
+++ b/bsps/arm/include/libcpu/am335x.h
@@ -14,11 +14,17 @@
  * Modified by Ben Gras  to add lots
  * of beagleboard/beaglebone definitions, delete lpc32xx specific
  * ones, and merge with some other header files.
+ *
+ * Modified by Udit agarwal  to add random
+ * number generating module definitions and TRNG register structure.
  */

 #if !defined(_AM335X_H_)
 #define _AM335X_H_

+/* For TRNG register definition */
+#include 
+
 /* Interrupt controller memory map */
 #define OMAP3_DM37XX_INTR_BASE 0x4820 /* INTCPS physical address */

@@ -701,4 +707,33 @@
 #define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
(0x0020u)
 #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF

-#endif
+/* TRNG Register */
+
+/* RNG base address */
+#define RNG_BASE 0x4831
+/* RNG clock control */
+#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
+/* rng module clock status bits */
+#define AM335X_CLK_RNG_BIT_MASK (0x3)
+/* Offset from RNG base for output ready flag */
+#define RNG_STATUS_RDY (1u <<  0)
+/* Offset from RNG base for FRO related error */
+#define RNG_STATUS_ERR (1u <<  1)
+/* Offset from RNG base for clock status */
+#define RNG_STATUS_CLK (1u << 31)
+/* enable module */
+#define AM335X_RNG_ENABLE (1 << 10)
+
+/* TRNG register structure */
+struct bbb_trng_register
+{
+uint64_t output; /* 00 */
+uint32_t status; /* 08 */
+uint32_t irq_en; /* 0c */
+uint32_t status_clr; /* 10 */
+uint32_t control;/* 14 */
+uint32_t config; /* 18 */
+};
+typedef struct bbb_trng_register bbb_trng_register;
+
+#endif
\ No newline at end of file
diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 8251660..5d5ade3 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -40,7 +40,6 @@ libbsp_a_LIBADD =

 # Shared
 libbsp_a_SOURCES += ../../shared/bootcard.c
-libbsp_a_SOURCES += ../../shared/getentropy-cpucounter.c
 libbsp_a_SOURCES += ../../shared/src/bsp-fdt.c
 libbsp_a_SOURCES += ../../shared/bspclean.c
 libbsp_a_SOURCES += ../../shared/bspgetworkarea.c
@@ -88,6 +87,9 @@ libbsp_a_SOURCES += gpio/bbb-gpio.c
 #pwm
 libbsp_a_SOURCES += pwm/pwm.c

+#getentropy
+libbsp_a_SOURCES += getentropy/bbb_getentropy.c
+
 #RTC
 libbsp_a_SOURCES += rtc.c
 libbsp_a_SOURCES += ../../shared/tod.c
diff --git a/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
b/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
new file mode 100644
index 000..134bf3b
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
@@ -0,0 +1,116 @@
+/**
+* @file
+*
+* @ingroup arm_beagle
+*
+* @brief Getentropy implementation on BeagleBone Black BSP
+*/
+
+/*
+* Copyright (c) 2018 Udit agarwal 
+* All rights reserved.
+*
+* Redistribution and use in source and binary forms, with or without
+* modification, are permitted provided that the following conditions
+* are met:
+* 1. Redistributions of source code must retain the above copyright
+*notice, this list of conditions and the following disclaimer.
+* 2. Redistributions in binary form must reproduce the above copyright
+*notice, this list of conditions and the following disclaimer in the
+*documentation and/or other materials provided with the distribution.
+*
+* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
+* ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
+* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT
+* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+* OUT OF THE USE OF THIS

Re: getentropy() implementation on BBB

[Udit agarwal]

Hi,
I have updated the patch and tested getentropy() , it did seem to work
(Logs: here
<https://gist.github.com/madaari/17bdec209eac993538b0192fba014918>).
Moreover, i've added BSD-2-clause license please verify it once. Also, i
need to shift
TRNG register structure from AM335x.h to bbb_getentropy.c . since, keeping
it in am335x.h
requires including stdint.h (for uint32_t etc) which i don't think would be
right, do let me know if this
is the right way.

Here's the patch:
>From f87b39708dd06482957fc7b33e78ab0ee095287b Mon Sep 17 00:00:00 2001
From: Udit agarwal 
Date: Sun, 11 Mar 2018 23:34:17 +0530
Subject: [PATCH] Added getentropy support to BBB BSP

---
 bsps/arm/include/libcpu/am335x.h   |  22 +++-
 c/src/lib/libbsp/arm/beagle/Makefile.am|   4 +-
 .../libbsp/arm/beagle/getentropy/bbb_getentropy.c  | 128
+
 3 files changed, 152 insertions(+), 2 deletions(-)
 create mode 100644 c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c

diff --git a/bsps/arm/include/libcpu/am335x.h
b/bsps/arm/include/libcpu/am335x.h
index 367e97c..bbdc8d0 100644
--- a/bsps/arm/include/libcpu/am335x.h
+++ b/bsps/arm/include/libcpu/am335x.h
@@ -14,6 +14,9 @@
  * Modified by Ben Gras  to add lots
  * of beagleboard/beaglebone definitions, delete lpc32xx specific
  * ones, and merge with some other header files.
+ *
+ * Modified by Udit agarwal  to add random
+ * number generating module definitions.
  */

 #if !defined(_AM335X_H_)
@@ -701,4 +704,21 @@
 #define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
(0x0020u)
 #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF

-#endif
+/* TRNG Register */
+
+/* RNG base address */
+#define RNG_BASE 0x4831
+/* RNG clock control */
+#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
+/* rng module clock status bits */
+#define AM335X_CLK_RNG_BIT_MASK (0x3)
+/* Offset from RNG base for output ready flag */
+#define RNG_STATUS_RDY (1u <<  0)
+/* Offset from RNG base for FRO related error */
+#define RNG_STATUS_ERR (1u <<  1)
+/* Offset from RNG base for clock status */
+#define RNG_STATUS_CLK (1u << 31)
+/* enable module */
+#define AM335X_RNG_ENABLE (1 << 10)
+
+#endif
\ No newline at end of file
diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 8251660..5d5ade3 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -40,7 +40,6 @@ libbsp_a_LIBADD =

 # Shared
 libbsp_a_SOURCES += ../../shared/bootcard.c
-libbsp_a_SOURCES += ../../shared/getentropy-cpucounter.c
 libbsp_a_SOURCES += ../../shared/src/bsp-fdt.c
 libbsp_a_SOURCES += ../../shared/bspclean.c
 libbsp_a_SOURCES += ../../shared/bspgetworkarea.c
@@ -88,6 +87,9 @@ libbsp_a_SOURCES += gpio/bbb-gpio.c
 #pwm
 libbsp_a_SOURCES += pwm/pwm.c

+#getentropy
+libbsp_a_SOURCES += getentropy/bbb_getentropy.c
+
 #RTC
 libbsp_a_SOURCES += rtc.c
 libbsp_a_SOURCES += ../../shared/tod.c
diff --git a/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
b/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
new file mode 100644
index 000..117c6b8
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
@@ -0,0 +1,128 @@
+/**
+* @file
+*
+* @ingroup arm_beagle
+*
+* @brief Getentropy implementation on BeagleBone Black BSP
+*/
+
+/*
+*Copyright 2018 Udit kumar agarwal 
+*
+*Redistribution and use in source and binary forms, with or without
+*modification, are permitted provided that the following conditions are
met:
+*
+*1. Redistributions of source code must retain the above copyright notice,
+*   this list of conditions and the following disclaimer.
+*
+*2. Redistributions in binary form must reproduce the above copyright
notice,
+*   this list of conditions and the following disclaimer in the
documentation
+*   and/or other materials provided with the distribution.
+*
+*THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS"
+*AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+*IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
+*ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+*LIABLE FOR ANY DIRECT,INDIRECT, INCIDENTAL, SPECIAL,EXEMPLARY, OR
+*CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+*SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,OR PROFITS; OR BUSINESS
+*INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,WHETHER IN
CONTRACT,
+*STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+*ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY
+*OF SUCH DAMAGE.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* max refill 34 * 256 cycles */
+#define AM335X_RNG_MAX_REFILL (34 << 16)
+/* min refill 33 * 64 cycles */
+#define AM335X_RNG_MIN_REFILL (33 << 0)
+/* startup 33 * 256

Re: Suggestions regarding GSoC project

[Udit agarwal]

Hi all,

On Sat, Mar 10, 2018 at 5:07 PM, Christian Mauderer 
wrote:

> Am 10.03.2018 um 02:14 schrieb Udit agarwal:
> > Hi all, Hi Christian Mauderer, Hi Russel Haley,
> >
> > I need some reviews/suggestions from the community regarding the idea of
> > Porting FreeBSD's SDIO driver to RTEMS via libbsd , building and testing
> > on Beaglebone Black BSP and then benchmarking it against our existing
> > SDHC driver.
> >
> > Also, at this point, I find it a bit difficult to estimate the length of
> > this project, whether it's doable within GSoC timeframe or if it's
> > easier then my expectations then will it be a good idea to include other
> > libbsd based projects like #3223 <https://devel.rtems.org/ticket/3223>
> > or #3222 <https://devel.rtems.org/ticket/3222> in my proposal to make it
> > a bit fair and strong.
> >
> > Regards,
> > Udit agarwal
> >
> >
>
> Hello Udit,
>
> like I already said in another mail, it is a nice idea to have some
> performance numbers and a comparison between the two SD driver versions
> for the BBB in RTEMS and FreeBSD. There are currently only few numbers
> regarding how well FreeBSD drivers work on RTEMS compared to FreeBSD.
>
> Please note that the following list is only a first suggestion how I
> would approach this project. Some others might have other ideas and of
> course you can use another approach too.
>
> Some parts of the work are a little hard to estimate. So maybe adding an
> extended goal (like testing some other SDIO hardware beneath SD cards)
> could be added. But producing some good documentation should be the main
> goal of that project.
>
> Basically you will need the following points for that:
>
> -> A good solid test strategy for a performance test that works on
> FreeBSD and on RTEMS. Note that for that you maybe have to avoid using a
> file system. If used with the wrong options, the FAT file system on
> RTEMS is really a performance killer and would distort the comparison.
>
> Ok, i'll search for different benchmarks for that, keeping file system in
mind.

> -> A test setup for FreeBSD with the two different drivers. Most likely
> you can use the same system with two different kernel versions for that.
> Maybe you should search for the exact version where the driver has been
> added to avoid any other performance patches.
>
> -> On RTEMS the test setup might become a little more tricky: You need
> both driver versions. Ideally from the same commits like the ones you
> use for the FreeBSD tests. And that might become complicated:
>
> We had some problems in the past that the libbsd became quite
> unmaintainable because different parts had used different versions of
> FreeBSD as a base. For example that made it impossible to use USB
> Ethernet devices. About end of 2016 we resolved that. Now there is
> always only one version of FreeBSD used throughout the complete libbsd.
>
> So to get both driver versions, there are two possibilities:
>
> 1. Ignore that rule and port a newer driver to the current version of
> libbsd. That is a bad idea because than we will again have problems with
> different versions. This kind of patch most likely couldn't be accepted
> in the official libbsd repository.
>
> 2. Update libbsd to a more recent version and use that to test the new
> driver. Then (on a branch) port the old driver to this new version. I
> would think that this is a better idea but it involves one big problem:
> Updating the libbsd to a newer FreeBSD version. That needs some good
> knowledge about the libbsd structure and about FreeBSD.
>
> This point most likely needs the most discussion.
>
> Updating libbsd seems to be a bit 'more involved' task. SDIO subsystem was
first added to FreeBSD
on 9, july, 2017 (here
<https://github.com/freebsd/freebsd/search?p=1&q=sdio&type=Commits&utf8=%E2%9C%93>)
, and our libbsd base is on FreeBSD head as on 2016-08-23 (here
<https://lists.rtems.org/pipermail/devel/2016-November/016343.html>). So,
Incorporating SDIO driver needs updating libbsd to FreeBSD head on/after
9/07/2017.(right?)
@sebastian sir, maybe you would like to give some insight into this?

Please note that this point is also vital for how much code from you
> will be visible after the project. Of course this kind of project will
> produce quite some documentation beneath the code which is great too.
> But if it is a important point for you that you can show a lot of code
> after GSoC, you might should think about whether that project is a good
> one for you.
>
That's not really an issue, our main aim for GSoC is to learn, to get an
intro of the
open source developing commun

Suggestions regarding GSoC project

[Udit agarwal]

Hi all, Hi Christian Mauderer, Hi Russel Haley,

I need some reviews/suggestions from the community regarding the idea of
Porting FreeBSD's SDIO driver to RTEMS via libbsd , building and testing on
Beaglebone Black BSP and then benchmarking it against our existing SDHC
driver.

Also, at this point, I find it a bit difficult to estimate the length of
this project, whether it's doable within GSoC timeframe or if it's easier
then my expectations then will it be a good idea to include other libbsd
based projects like #3223 <https://devel.rtems.org/ticket/3223>  or #3222
<https://devel.rtems.org/ticket/3222> in my proposal to make it a bit fair
and strong.

Regards,
Udit agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: getentropy() implementation on BBB

[Udit agarwal]

Thanks, I just came across ticket #3053
<https://devel.rtems.org/ticket/3053> , which talks about changing RTEMS
license from GNU GPL to BSD-2-Clause (i was initially unaware of this!).
I'll make the required changes.

Regards,
Udit agarwal

On Wed, Mar 7, 2018 at 4:23 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 07/03/18 11:26, Udit agarwal wrote:
>
>> > +/*
>> > + * Copyright (c) 2018 Udit kumar agarwal > http://gmail.com>>
>> > + *
>> > + * The license and distribution terms for this file may be
>> > + * found in the file LICENSE in this distribution or at
>> > + * http://www.rtems.org/license/LICENSE <http://www.rtems.org/license/
>> LICENSE>.
>> > + */
>>
>
> What about new contributions from new authors? Do we want to use a
> BSD-2-Clause license for RTEMS or not?
>
> --
> 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  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: getentropy() implementation on BBB

[Udit agarwal]

Hi,
I have updated the code, please have a look.
>From 74b8f4f5b9dd929b71ed5fb9dd0bc721a6f27a28 Mon Sep 17 00:00:00 2001
From: Udit agarwal 
Date: Wed, 7 Mar 2018 15:52:13 +0530
Subject: [PATCH] Added getentropy support to beagle BSP

---
 bsps/arm/include/libcpu/am335x.h   | 34 -
 c/src/lib/libbsp/arm/beagle/Makefile.am|  4 +
 .../libbsp/arm/beagle/getentropy/bbb_getentropy.c  | 88
++
 3 files changed, 125 insertions(+), 1 deletion(-)
 create mode 100644 c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c

diff --git a/bsps/arm/include/libcpu/am335x.h
b/bsps/arm/include/libcpu/am335x.h
index 367e97c..92af6dc 100644
--- a/bsps/arm/include/libcpu/am335x.h
+++ b/bsps/arm/include/libcpu/am335x.h
@@ -14,6 +14,9 @@
  * Modified by Ben Gras  to add lots
  * of beagleboard/beaglebone definitions, delete lpc32xx specific
  * ones, and merge with some other header files.
+ *
+ * Modified by Udit agarwal  to add random
+ * number generating module definitions along with register structure.
  */

 #if !defined(_AM335X_H_)
@@ -701,4 +704,33 @@
 #define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
(0x0020u)
 #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF

-#endif
+/* TRNG Register */
+
+/* RNG base address */
+#define RNG_BASE 0x4831
+/* RNG clock control */
+#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
+/* rng module clock status bits */
+#define AM335X_CLK_RNG_BIT_MASK (0x3)
+/* Offset from RNG base for output ready flag */
+#define RNG_STATUS_RDY (1u <<  0)
+/* Offset from RNG base for FRO related error */
+#define RNG_STATUS_ERR (1u <<  1)
+/* Offset from RNG base for clock status */
+#define RNG_STATUS_CLK (1u << 31)
+/* enable module */
+#define AM335X_RNG_ENABLE (1 << 10)
+
+/* TRNG register structure */
+struct bbb_trng_register
+{
+uint64_t output; /*00*/
+uint32_t status; /*08*/
+uint32_t irq_en; /*0c*/
+uint32_t status_clr; /*10*/
+uint32_t control; /*14*/
+uint32_t config; /*18*/
+};
+typedef struct bbb_trng_register bbb_trng_register;
+
+#endif
\ No newline at end of file
diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 8251660..bf92081 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -88,9 +88,13 @@ libbsp_a_SOURCES += gpio/bbb-gpio.c
 #pwm
 libbsp_a_SOURCES += pwm/pwm.c

+#getentropy
+libbsp_a_SOURCES += getentropy/bbb_getentropy.c
+
 #RTC
 libbsp_a_SOURCES += rtc.c
 libbsp_a_SOURCES += ../../shared/tod.c
+
 # Clock
 libbsp_a_SOURCES += clock.c
 libbsp_a_SOURCES += ../../shared/clockdrv_shell.h
diff --git a/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
b/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
new file mode 100644
index 000..5b7c5d0
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
@@ -0,0 +1,88 @@
+/**
+* @file
+*
+* @ingroup arm_beagle
+*
+* @brief Getentropy implementation on BeagleBone Black BSP
+*/
+
+/*
+* Copyright (c) 2018 Udit kumar agarwal 
+*
+* The license and distribution terms for this file may be
+* found in the file LICENSE in this distribution or at
+* http://www.rtems.org/license/LICENSE.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* max refill 34 * 256 cycles */
+#define AM335X_RNG_MAX_REFILL (34 << 16)
+/* min refill 33 * 64 cycles */
+#define AM335X_RNG_MIN_REFILL (33 << 0)
+/* startup 33 * 256 cycles */
+#define AM335X_RNG_STARTUP_CYCLES (33 << 16)
+
+/* maximun and minimum refill cycle sets the number of samples to be taken
+   from FRO to generate random number */
+static void am335x_rng_enable(bbb_trng_register *rng)
+{
+rng->control = rng->config = 0;
+rng->config |= AM335X_RNG_MIN_REFILL | AM335X_RNG_MAX_REFILL ;
+rng->control |= AM335X_RNG_STARTUP_CYCLES | AM335X_RNG_ENABLE ;
+}
+
+static void am335x_rng_clock_enable(void)
+{
+*(volatile uint8_t *) CM_PER_RNG_CLKCTRL = 2;
+while( *(volatile uint32_t *) CM_PER_RNG_CLKCTRL &
AM335X_CLK_RNG_BIT_MASK ) {}
+}
+
+static uint64_t trng_getranddata(bbb_trng_register *rng)
+{
+uint64_t output = rng->output;
+return output;
+}
+
+int getentropy(void *ptr, size_t n)
+{
+volatile const bbb_trng_register  *rng = (bbb_trng_register*) RNG_BASE;
+am335x_rng_enable(rng);
+while (n > 0)
+{
+uint64_t random;
+size_t copy;
+
+/* wait untill RNG becomes ready with next set of random data */
+while( ( rng->status & RNG_STATUS_RDY ) == 0 );
+
+random = trng_getranddata(rng);
+
+/* Checking for error by masking all bits other then error bit in
status register */
+if( ((rng->status & RNG_STATUS_ERR)>>1) == 0)
+{
+/* clear the status flag after reading to generate new random
value*/
+rng

Re: getentropy() implementation on BBB

[Udit agarwal]

Hi,
Here's the updated code(I have also attached the patch PFA):

>From 96e6e1bfd8cffeef5d309eb0a07fe2bfd086ef0a Mon Sep 17 00:00:00 2001
From: Udit agarwal 
Date: Tue, 6 Mar 2018 20:07:44 +0530
Subject: [PATCH] Added getentropy support to BBB BSP

---
 bsps/arm/beagle/headers.am |  1 +
 bsps/arm/beagle/include/bsp/bbb_getentropy.h   | 57 +++
 bsps/arm/include/libcpu/am335x.h   | 16 +
 c/src/lib/libbsp/arm/beagle/Makefile.am|  4 ++
 .../libbsp/arm/beagle/getentropy/bbb_getentropy.c  | 80
++
 5 files changed, 158 insertions(+)
 create mode 100644 bsps/arm/beagle/include/bsp/bbb_getentropy.h
 create mode 100644 c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c

diff --git a/bsps/arm/beagle/headers.am b/bsps/arm/beagle/headers.am
index 6692d0b..ac4ff7c 100644
--- a/bsps/arm/beagle/headers.am
+++ b/bsps/arm/beagle/headers.am
@@ -12,3 +12,4 @@ include_bsp_HEADERS +=
../../../../../../bsps/arm/beagle/include/bsp/bbb-pwm.h
 include_bsp_HEADERS +=
../../../../../../bsps/arm/beagle/include/bsp/beagleboneblack.h
 include_bsp_HEADERS += ../../../../../../bsps/arm/beagle/include/bsp/i2c.h
 include_bsp_HEADERS += ../../../../../../bsps/arm/beagle/include/bsp/irq.h
+include_bsp_HEADERS +=
../../../../../../bsps/arm/beagle/include/bsp/bbb_getentropy.h
diff --git a/bsps/arm/beagle/include/bsp/bbb_getentropy.h
b/bsps/arm/beagle/include/bsp/bbb_getentropy.h
new file mode 100644
index 000..5e46f89
--- /dev/null
+++ b/bsps/arm/beagle/include/bsp/bbb_getentropy.h
@@ -0,0 +1,57 @@
+/**
+ * @file
+ *
+ * @ingroup arm_beagle
+ *
+ * @brief TRNG Definations
+ */
+
+/*
+ * Copyright (c) 2018 Udit kumar agarwal 
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+
+#ifndef _TRNG_
+#define _TRNG_
+
+/*--
+ * Headers
+
**/
+
+#include 
+
+
/*--
+ * Register structure
+
**/
+
+struct rng {
+uint64_t output; /*00*/
+uint32_t status; /*08*/
+uint32_t irq_en; /*0c*/
+uint32_t status_clr; /*10*/
+uint32_t control; /*14*/
+uint32_t config; /*18*/
+};
+
+typedef volatile struct rng *rng_ref_t;
+
+/**/
+/* Exported
functions */
+/**/
+
+/* configure and enable RNG module  */
+static void am335x_rng_enable(rng_ref_t);
+/* enable module clock for random number generator */
+static void am335x_rng_clock_enable(void);
+/* outputs random data */
+static uint64_t trng_getranddata(rng_ref_t);
+/* Copy random data of a specified size to the pointer supplied */
+int getentropy(void *ptr, size_t);
+
+
+
+#endif /* #ifndef _TRNG_ */
\ No newline at end of file
diff --git a/bsps/arm/include/libcpu/am335x.h
b/bsps/arm/include/libcpu/am335x.h
index 367e97c..8b58f1a 100644
--- a/bsps/arm/include/libcpu/am335x.h
+++ b/bsps/arm/include/libcpu/am335x.h
@@ -14,6 +14,9 @@
  * Modified by Ben Gras  to add lots
  * of beagleboard/beaglebone definitions, delete lpc32xx specific
  * ones, and merge with some other header files.
+ *
+ * Modified by Udit agarwal  to add random
+ * number generating module definations
  */

 #if !defined(_AM335X_H_)
@@ -701,4 +704,17 @@
 #define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
(0x0020u)
 #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF

+/* TRNG Register */
+
+/* RNG base address */
+#define RNG_BASE0x4831
+/* RNG clock control */
+#define CM_PER_RNG_CLKCTRLAM335X_CM_PER_ADDR | 9<<4
+/* Offset from RNG base for output ready flag */
+#define RNG_STATUS_RDY(1u <<  0)
+/* Offset from RNG base for FRO related error*/
+#define RNG_STATUS_ERR(1u <<  1)
+/* Offset from RNG base for clock status */
+#define RNG_STATUS_CLK(1u << 31)
+
 #endif
diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 8251660..bf92081 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -88,9 +88,13 @@ libbsp_a_SOURCES += gpio/bbb-gpio.c
 #pwm
 libbsp_a_SOURCES += pwm/pwm.c

+#getentropy
+libbsp_a_SOURCES += getentropy/bbb_getentropy.c
+
 #RTC
 libbsp_a_SOURCES += rtc.c
 libbsp_a_SOURCES += ../../shared/tod.c
+
 # Clock
 libbsp_a_SOURCES += clock.c
 libbsp_a_SOURCES += ../../shared/clockdrv_shell.h
diff --git a/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
b/c/src/lib/libbsp/arm/beagle/getentropy/bbb_g

Implementing a check on FDT header

[Udit agarwal]

Hi,
While going through uboot docs, i found something intresting:
Here <https://www.denx.de/wiki/DULG/UBootCmdGroupExec>(Sec: 5.9.4.2), It is
given that if FDT is not passed as the third argument to bootm command
then, by default a data structure called bd_info(given here
<https://github.com/u-boot/u-boot/blob/53193a4f07c9e7a7d42493863712352cf16f1258/include/asm-generic/u-boot.h>)
is passed instread of the pointer to fdt. Thus, the argument being passed
to bsp_fdt_copy function during start.S shouldn't be random(or NULL).
Now, checking for the presence of bd_info can allow us to load an empty FDT
in case of missing bootm param. I did load media01 test with empty FDT and
it didn't crashed(Logs:here
<https://gist.github.com/madaari/74ba18a375e320108587a0d29cda6985>).
In case, if the FDT is loaded by the user, now we can implement a FDT
header check to confirm it's validity.One possible way to do that could be
via libfdt(there's a build in function that checks for magic number) as
given in this
<https://github.com/RTEMS/rtems/tree/5eb769ca8b553b4378a773967f08de20847794db/testsuites/libtests/libfdt01>
test. Other possible way(I am not sure about it) could be a validy check
within uboot itself(Given here
<https://lists.denx.de/pipermail/u-boot/2012-March/121281.html>).

Moreover, I have a doubt, Why is uboot RTEMS format depreciated as per your
discussions in previous threads?
Thanks!
Regards,
Udit agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

getentropy() implementation on BBB

[Udit agarwal]

Hi,
I tried implementing getentropy on BBB, below is the patch. Please have a
look.
I followed these(1
<https://e2e.ti.com/support/arm/sitara_arm/f/791/t/355064> & 2
<http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/arm/omap/am335x_trng.c>)
links for code reference. and this
<https://docs.google.com/spreadsheets/d/1VpghMlLtrWQIrcvCsRg3ueRZkX0eGSQkFnzjfsqrd8A/view#gid=0>
for register reference. Moreover, what further configuration in RTEMS is
needed to execute and test this code along with getentropy() sample
testcode?


+ /*
+  * Copyright (c) 2018 embedded brains GmbH.  All rights reserved.
+  *
+  *  embedded brains GmbH
+  *  Dornierstr. 4
+  *  82178 Puchheim
+  *  Germany
+  *  
+  *
+  * The license and distribution terms for this file may be
+  * found in the file LICENSE in this distribution or at
+  * http://www.rtems.org/license/LICENSE.
+  */
+
+ #include 
+ #include 
+ #include 
+ #include 
+
+ #define RNG_BASE0x4831
+ #define CM_PER_RNG_CLKCTRL0x44e00090
+ #define RNG_STATUS_RDY(1u <<  0)  // output ready for reading
+ #define RNG_STATUS_ERR(1u <<  1)  // FRO shutdown alarm
+ #define RNG_STATUS_CLK(1u << 31)  // module functional clock active
(no irq)
+
+ typedef volatile struct rng *rng_ref_t;
+
+ struct rng {
+ /*00*/uint64_t output;//r-
+ /*08*/uint32_t status;//r-
+ /*0c*/uint32_t irq_en;//rw
+ /*10*/uint32_t status_clr;//-c
+ /*14*/uint32_t control;//rw
+ /*18*/uint32_t config;//rw
+ };
+
+ static void TRNG_Enable(rng_ref_t rng){
+ rng->config = 0
+ | 34 << 16  // max refill 34 * 256 cycles
+ | 33 <<  0;  // min refill 33 * 64 cycles
+ rng->control = 0
+ | 33 << 16  // startup 33 * 256 cycles
+ |  1 << 10;  // enable module
+ }
+
+ static void beagle_trng_clock_enable(void)
+ {
+ // enable module clock
+ *(volatile uint8_t *) CM_PER_RNG_CLKCTRL = 2;
+ while( *(volatile uint32_t *) CM_PER_RNG_CLKCTRL & 0x3 ) {}
+ }
+
+ static uint64_t TRNG_GetRandData(){
+ uint64_t output = rng->output;
+ return output;
+ }
+
+ int getentropy(void *ptr, size_t n)
+ {
+ rng_ref_t const rng = (rng_ref_t) RNG_BASE;
+ TRNG_Enable(rng);
+ while (n > 0) {
+ uint64_t random;
+ size_t copy;
+
+ while( ( rng->status & RNG_STATUS_RDY ) == 0 ); //wait
+
+ random = TRNG_GetRandData(rng);
+
+ /*
+  * Read TRNG status one more time to avoid race condition.
+  * Otherwise we can read (and clear) an old ready status but get
+  * a new value. The ready status for this value wouldn't be
+  * reset.
+  */
+ rng->status_clr = RNG_STATUS_RDY;
+
+ copy = sizeof(random);
+ if (n < copy ) {
+ copy = n;
+ }
+ memcpy(ptr, &random, copy);
+ n -= copy;
+ ptr += copy;
+ }
+
+ return 0;
+ }
+
+ RTEMS_SYSINIT_ITEM(
+   beagle_trng_clock_enable,
+   RTEMS_SYSINIT_DEVICE_DRIVERS,
+   RTEMS_SYSINIT_ORDER_LAST
+ );

Regards,
Udit agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel