This is the mail archive of the
mailing list for the eCos project.
[Bug 1000819] Add support for Atmel AT91SAM9263
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-patches at ecos dot sourceware dot org
- Date: Wed, 16 Mar 2011 16:54:05 +0000
- Subject: [Bug 1000819] Add support for Atmel AT91SAM9263
- Auto-submitted: auto-generated
- References: <firstname.lastname@example.org/>
Please do not reply to this email. Use the web interface provided at:
--- Comment #13 from Jonathan Larmour <email@example.com> 2011-03-16 16:54:03 GMT ---
(In reply to comment #11)
> Let's try to push through with review and get it checked in. I've invited all
> interested parties to add themselves to the CC list and add their own comment
> where necessary/appropriate.
> Evgeniy, the use of multiple patches is a great help - thank you!
> Let's start with the ARM7/ARM9 abstraction work (patch 1). This looks to be a
> case of moving the existing HAL cache macros (which are not appropriate for
> AT91SAM9) from the AT91 variant package to a new ARM7 package. I assume that
> there is nothing AT91-specific in the new package so it could be used by any
> other ARM7 ports in the future. Please confirm.
No ARM7 has cache, so it's safe IMO.
> As it stands, this patch should only affect AT91 targets. The risk of breaking
> other AT91 target support is small since there does not appear to be any
> changes to the macros themselves. There is a risk of breaking compatibility
> with non-contributed ports to AT91SAM7 hardware but the effort in fixing such
> breakage should be limited to adding the new ARM7 package to the target
> description in ecos.db. I don't have a problem with this.
Particularly since it's obvious due to the change in the AT91 HAL for the ARM7
HAL to be its parent (which implies active_if).
> Is there any other code in the existing AT91 variant HAL which might not be
> appropriate for AT91SAM9?
That is in fact a very important issue, and one of the harder ones with this
patch. The AT91 HAL already has lots of ifdefs, making it harder to parse and
see what's going on. I think I already mentioned (way, way back) the SH HAL
having a more tractable approach by splitting out CPUs into their own files,
and that's what patch 3 appears to be about, but whether it's sufficient to
limit that to just PIO definitions I'm distinctly unsure. Maybe we'll leave
that to discussing Patch 3 in depth.
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.