BSP for Microchip ATSAMA5D27-SOM1-EK1

Joel Sherrill joel at rtems.org
Mon Nov 26 19:22:10 UTC 2018


On Mon, Nov 26, 2018, 1:10 PM Christian Mauderer <list at c-mauderer.de wrote:

> Hello Peter,
>
> yes, that sounds about right. I'm not entirely sure about the name of
> the file we used as a base back then. I would have to take a look at the
> exact version at work.
>
> I think the new software should be based on the "legacy" one so I would
> expect that the interface is at least similar. But yes, it will be some
> work to use the updated libraries. Especially because there are some
> RTEMS-patches in the legacy libraries to work around some bugs.
>

Was the original software committed unmodified? If so, then the changes to
fix bugs should be easy to find via git.

>
> Best regards
>
> Christian
>
> Am 26.11.18 um 18:37 schrieb dufault at hda.com:
> > It will be some work to update.  I believe what’s in the existing port
> > is from this:
> > atmel-software-package-samv7:  Legacy software package for samv7, same70
> > and sams70 product families.
> > while the newest software that supports the ATSAMA5 is here, with a
> > different directory layout.
> > atmel-software-package: Atmel Software Package
> >
> >> On Nov 25, 2018, at 14:45 , Christian Mauderer <list at c-mauderer.de
> >> <mailto:list at c-mauderer.de>> wrote:
> >>
> >> Hello Peter,
> >>
> >> Thomas mentioned already the bug that has been reported to Microchip.
> >> Please note that I had two more problems with the BSP on another
> >> customers board:
> >>
> >> - The core clock couldn't be set to the maximum frequency from the data
> >> sheet. Both possible configurations for that frequency didn't work. The
> >> first one would have set the PLL to the same frequency as the CPU core
> >> clock. With that the system was not stable. The other setting (a divider
> >> of two after the PLL) seemed to work better but that forced me to set
> >> the PLL to a higher frequency than the data sheet specified. I ended up
> >> with the lower frequency.
> >>
> >> - The external SDRAM seemed to introduce some jitter into the core PLL
> >> too (not only in the USB PLL which was the reason for the USB bug). With
> >> higher frequency configurations the system sometimes had an odd
> >> behaviour: A comparison went wrong when it should go well. Again that
> >> lead to a slightly lower frequency that seemed stable. So the board now
> >> runs on only about two thirds of the maximum frequency specified by
> >> Microchip.
> >>
> >> If you still want to use the ATSAM chip: Microchip managed to get a
> >> better community around the libraries that are used in the BSP for that
> >> chip. There is a newer version of them somewhere on github. If there is
> >> funding for it, I would suggest to update the ones that are integrated
> >> in the ATSAM BSP by the newer ones. They contain quite some bug fixes.
> >> But it will need some work to do that.
> >>
> >> With kind regards
> >>
> >> Christian Mauderer
> >>
> >> Am 25.11.18 um 19:42 schrieb dufault at hda.com <mailto:dufault at hda.com>:
> >>> Thank you for the advice.  I will not need USB, but will need SDRAM and
> >>> don’t need poor support.  Microchip? You tried to push RTEMS for this
> >>> platform tied to space applications, are you monitoring this?  The
> >>> platform looks like just what I need but not if you’re not supporting
> it.
> >>>
> >>>> On Nov 25, 2018, at 13:23 , Thomas Dörfler
> >>>> <thomas.doerfler at embedded-brains.de
> >>>> <mailto:thomas.doerfler at embedded-brains.de>
> >>>> <mailto:thomas.doerfler at embedded-brains.de>> wrote:
> >>>>
> >>>> Peter,
> >>>>
> >>>> just to make you aware: we designed a board with the ATSAMV7 chip and
> >>>> hit some nasty and at least one really ugly bug: operating the USB
> >>>> interface concurrently with external SDRAM does not work. Half a year
> >>>> after reporting this bug, Microchip confirmed it, but did not plan any
> >>>> fix for it. BTW: The conbination (USB+SDRAM) was also available on
> >>>> Microchip's evaluation board, but obviously was not tested together at
> >>>> Microchips labs...
> >>>>
> >>>> So: I recommend you to tripple check, whether the ATSAMA5 meets all of
> >>>> your expectations.
> >>>>
> >>>>
> >>>> Kind regards,
> >>>>
> >>>> Thomas.
> >>>>
> >>>> ----- Ursprüngliche Mail -----
> >>>> Von: "Peter Dufault" <dufault at hda.com <mailto:dufault at hda.com>
> >>>> <mailto:dufault at hda.com>>
> >>>> An: "Development" <devel at rtems.org <mailto:devel at rtems.org>
> >>>> <mailto:devel at rtems.org>>
> >>>> Gesendet: Sonntag, 25. November 2018 18:38:19
> >>>> Betreff: BSP for Microchip ATSAMA5D27-SOM1-EK1
> >>>>
> >>>> I need to evaluate this for a multi-chip application.
> >>>>
> >>>> This part is a result of Microchip’s take-over of ATMEL.  I’m
> >>>> double-checking that to create a BSP based on this I should start with
> >>>> the existing ATSAMV7 BSP, I think the peripherals (e.g. network chip
> >>>> and so on) are the same as the existing ATSAMV7 port.
> >>>>
> >>>> Peter
> >>>> -----------------
> >>>> Peter Dufault
> >>>> HD Associates, Inc.      Software and System Engineering
> >>>>
> >>>> This email is delivered through the public internet using protocols
> >>>> subject to interception and tampering.
> >>>>
> >>>> _______________________________________________
> >>>> devel mailing list
> >>>> devel at rtems.org <mailto:devel at rtems.org> <mailto:devel at rtems.org>
> >>>> http://lists.rtems.org/mailman/listinfo/devel
> >>>> --
> >>>> --
> >>>> --------------------------------------------
> >>>> embedded brains GmbH
> >>>> Thomas Doerfler
> >>>> Dornierstr. 4
> >>>> D-82178 Puchheim
> >>>> Germany
> >>>> email: Thomas.Doerfler at embedded-brains.de
> >>>> Phone: +49-89-18 94 741-12
> >>>> Fax:   +49-89-18 94 741-09
> >>>> PGP: Public key available on request.
> >>>>
> >>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >>>
> >>> Peter
> >>> -----------------
> >>> Peter Dufault
> >>> HD Associates, Inc.      Software and System Engineering
> >>>
> >>> This email is delivered through the public internet using protocols
> >>> subject to interception and tampering.
> >>>
> >>>
> >>> _______________________________________________
> >>> devel mailing list
> >>> devel at rtems.org <mailto:devel at rtems.org>
> >>> http://lists.rtems.org/mailman/listinfo/devel
> >>>
> >>
> >
> > Peter
> > -----------------
> > Peter Dufault
> > HD Associates, Inc.      Software and System Engineering
> >
> > This email is delivered through the public internet using protocols
> > subject to interception and tampering.
> >
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20181126/2338d7f8/attachment-0002.html>


More information about the devel mailing list