BSP for Microchip ATSAMA5D27-SOM1-EK1
Christian Mauderer
list at c-mauderer.de
Mon Nov 26 19:25:15 UTC 2018
Am 26.11.18 um 20:22 schrieb Joel Sherrill:
>
>
> On Mon, Nov 26, 2018, 1:10 PM Christian Mauderer <list at c-mauderer.de
> <mailto: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.
>
I haven't added the original files. That was most likely Alexander
Krutwig. But I assume that Sebastian had an eye on it that the original
files were unchanged in the first commit. If not, we still have the
original version that we used on some network folder and we could
provide it if necessary.
Git might have some problems with the file moves during the BSP
reorganization. But it should be able to handle that with some option (I
think --follow).
>
> Best regards
>
> Christian
>
> Am 26.11.18 um 18:37 schrieb dufault at hda.com <mailto: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>
> >> <mailto: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> <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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
> <mailto: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> <mailto: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 <mailto:devel at rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
>
More information about the devel
mailing list