GSoC'18-Introduction

Thu Mar 1 07:42:30 UTC 2018

Am 01.03.2018 um 08:07 schrieb Russell Haley:
> On Wed, Feb 28, 2018 at 3:24 AM, Udit agarwal <dev.madaari at gmail.com> wrote:
>> 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
>>

These would be two tasks that you can try out as first steps. Please
note that this have only been suggestions. If you would like to do
something else, you can have a look at that too.

The getentropy() implementation should be a quite small and
straightforward patch that you can implement and send to the mailing list.

The FDT might need some discussion before you implement it. In the best
case, that one would work for all boards and not only the BBB. Note that
the devel mailing list could be the better place to discuss it.

>> 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.

First of all: Great that you already found out where the FATAL occurs.
It's not that easy to go through all the layers in libbsd. Especially
without a debugger.

But I'm not sure whether catching the memory access violation would be
the right method here.

I think it would be a good idea to take a look at the boot process
first: We have two situations:

1. U-Boot does loads a FDT at a specified address and provides that
address to the RTEMS application. The application checks the FDT at this
address and uses it. This should be the good case.

2. U-Boot does not provide a FDT. That is the error case that you hit.
I'm not sure whether the pointer to the FDT that normally would be
provided by U-Boot has a defined value or whether it's just undefined.
If it is undefined, a memory access violation might occur (if the
pointer points to some non-existing or protected memory) but it doesn't
have to (if the pointer points to some random but existing memory).

So from my point of view, the first step would be to analyze what is
provided as FDT pointer if you boot in U-Boot without a FDT like in your
original boot line.

I'm quite sure that there had been a discussion on the mailing list
about that somewhere during last year. Most likely when Sichen added the
FDT support to BBB. But I currently can't find it.

>>
>> 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).
> https://en.wikipedia.org/wiki/Yarrow_algorithm

In RTEMS the arc4random implementation is provided by newlib. This
implementation needs a getentropy() as it's entropy source. Every
software part we port from FreeBSD sources should use the arc4random
high level calls.

One example patch that added getentropy() for the ATSAM is this one:
https://git.rtems.org/rtems/commit/?id=a9de9a7b95b2e775d7a693782f041abb2b9caa75

> 
>> 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:
> https://github.com/kibab/freebsd/tree/mmcam-new/usr.bin/sdiotool.
> 
> 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.
> 
> Russ
> 
>> 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
>>
>>
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at 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.