GSoC'18-Introduction

[Udit agarwal]

Hi,
Sorry for late reply, i am having my mid term examinations ongoing.

So as of now, I'm having following two short term tasks:
      *Adding a check on targets that needs FDT , and then raising an
error/warning rather then a crash if missing FDT
      *Implementation of getentropy() on BBB

For the first task, i did debug a bit and found that in case of missing
FDT, during kernel memory initialization i.e during mi_startup()(here
<https://github.com/RTEMS/rtems-libbsd/blob/3c967ca2388b57d828f16e8b55ec6ccb34824a18/freebsd/sys/kern/init_main.c>),
after few iterations the call function (On line 306) raises a
RTEMS_FATAL_SOURCE_EXCEPTION error which as described here
<http://rtems-devel.rtems.narkive.com/zeHkcKMr/how-memory-access-violation-should-be-handled>
occurs during memory access violation. So, wrapping it with a different an
exception handler, might allow us raise a more specific error regarding
missing FDT blob. Do let me know if i'm on a right track! Here
<https://gist.github.com/madaari/c6d524bc06e896359f9535d90c0a447a> are the
update logs. I have wrapped the the mi_startup with multiple printfs for
debugging, that makes it a bit clumsy but i guess i need to stick to it
before getting my Jlink segger EDU, probably in few days :0.

For getentropy(), It looks like FreeBSD uses another similar sys call
read_random as described here
<https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4>. getentropy()
<https://man.openbsd.org/getentropy.2> seems to be a part of OpenBSD.

Implementing and Benchmarking SDIO driver seems to be a great project for
GSoC, but as per its current status (here <https://wiki.freebsd.org/SDIO>)
, it's partially developed.(the webpage seems to be a bit outdated, i'll
confirm from their maintainers). Till then i'll study more about it's
implementation.
Thank you mentors for your continuous help.

Regards,
Udit agarwal

On Wed, Feb 28, 2018 at 10:22 AM, Chris Johns <chrisj at rtems.org> wrote:

> On 28/02/2018 15:37, Christian Mauderer wrote:
> > Yes, seems that I misunderstood it. So OpenOCD will remain on top of the
> recommendation list.
>
> For open solutions currently it seems so.
>
> >
> >>> As a positive report: I have a quite stable setup with the Segger
> J-Link
> >>> EDU.
> >>
> >> I do not run Linux and do not put Macs close to hardware so I cannot
> run their
> >> closed source GDB server. I will stick with a fully open solution I can
> control
> >> and fix.
> >
> > Most of the time I prefere open solutions too. I had some problems with
> OpenOCD on another target and bought the J-Link for that one. I only
> re-used it for the Beagle and it run quite well.
>
> Nice. Please add it to the Wiki and some instructions if you feel it is
> needed.
> It should be up to users to decide based on their needs and budget.
>
> >>
> >>> The EDU is a affordable variant with the disadvantage that it must
> >>> only be used for non-commericial purpose.
> >>
> >> Ouch, messy. If I am paid to work on open source is that a
> non-commmercial
> >> purpose or commercial purpose? What if I am paid more for coding and I
> debug for
> >> free? ;)
> >
> > Same problem as allways with licensing. I would expect that GSoC is more
> educationall than commercial. But it's an edge case.
>
> Agreed.
>
> > For my applications I dont have a problem to distinguish because we have
> another debugger at work. So I can separate these quite well.
>
> For a BBB? I think we should list solutions, commercial or open, cheap or
> expensive.
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180228/3519a73e/attachment-0002.html>