This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1000819] Add support for Atmel AT91SAM9263


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000819

--- Comment #13 from Jonathan Larmour <jifl@ecoscentric.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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]