dev.madaari at gmail.com
Wed Feb 28 11:24:41 UTC 2018
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
after few iterations the call function (On line 306) raises a
RTEMS_FATAL_SOURCE_EXCEPTION error which as described here
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://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
Thank you mentors for your continuous help.
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
> >>> 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
> >> 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
> 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
> >> 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.
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users