Am 26.11.18 um 20:22 schrieb Joel Sherrill: > > > On Mon, Nov 26, 2018, 1:10 PM Christian Mauderer <l...@c-mauderer.de > <mailto:l...@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 dufa...@hda.com <mailto:dufa...@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 > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > >> <mailto:l...@c-mauderer.de <mailto:l...@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 dufa...@hda.com > <mailto:dufa...@hda.com> <mailto:dufa...@hda.com > <mailto:dufa...@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.doerf...@embedded-brains.de > <mailto:thomas.doerf...@embedded-brains.de> > >>>> <mailto:thomas.doerf...@embedded-brains.de > <mailto:thomas.doerf...@embedded-brains.de>> > >>>> <mailto:thomas.doerf...@embedded-brains.de > <mailto:thomas.doerf...@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" <dufa...@hda.com <mailto:dufa...@hda.com> > <mailto:dufa...@hda.com <mailto:dufa...@hda.com>> > >>>> <mailto:dufa...@hda.com <mailto:dufa...@hda.com>>> > >>>> An: "Development" <devel@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > >>>> <mailto:devel@rtems.org <mailto:devel@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@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > >>>> http://lists.rtems.org/mailman/listinfo/devel > >>>> -- > >>>> -- > >>>> -------------------------------------------- > >>>> embedded brains GmbH > >>>> Thomas Doerfler > >>>> Dornierstr. 4 > >>>> D-82178 Puchheim > >>>> Germany > >>>> email: thomas.doerf...@embedded-brains.de > <mailto:thomas.doerf...@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@rtems.org <mailto:devel@rtems.org> <mailto:devel@rtems.org > <mailto:devel@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@rtems.org <mailto:devel@rtems.org> > http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
