russ.haley at gmail.com
Thu Mar 1 07:07:09 UTC 2018
On Wed, Feb 28, 2018 at 3:24 AM, Udit agarwal <dev.madaari at gmail.com> wrote:
> 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 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. getentropy() seems to be a part of OpenBSD.
FreeBSD uses Fortuna, which is a successor to the Yarrow toolset (an
excellent package for it's day).
> Implementing and Benchmarking SDIO driver seems to be a great project for
> GSoC, but as per its current status (here) , 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.
Not sure what you mean by partially developed. The stack has been
committed to the HEAD revision. I have used the MMCCAM SDIO driver on
FreeBSD for the mmc card on a Beaglebone. The code is quite solid and
there is a port for IMX hardware (indicating maturity). Ilya has code
for a Broadcom Wi-Fi chipset here:
Regardless of Wi-Fi, you could create an RTEMS image with the standard
SDHC driver sets and an image with CAMMMC stack in place and then
measure the performance of the two. (I say that like I know how libbsd
works but I don't).
As a note, innovative software can sit around in FreeBSD for a
very...long...time before someone comes along and pushes it into the
main code base. There is a huge amount of code that goes dead just
waiting for someone to say "hey, I tested this and it's good." I don't
expect the SDIO driver to die, but I wouldn't go by the wiki.
I'm sorry you haven't received any response on FreeBSD-arm@ about your
Wi-Fi card. Adrian Chadd is the guy to talk to about the Atheros
Hardware Abstraction Layer (which is what holds back your cards
support). I've spoken to him about other cards and most of the code is
there and it just needs to be wired together (I think it says that on
the wiki too). If you're really keen on getting it supported, start
doing some research on the driver layout and the HAL and ask a
technical question in the same thread. He may pipe up. The other thing
to do is sit on IRC and ask questions. It's a little hit and miss
depending on Time Zones, but the communication is much more open.
> 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
>> 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.
>> > 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
> users mailing list
> users at rtems.org
More information about the users