Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000819
--- Comment #33 from Daniel Helgason <[email protected]> 2011-05-24 19:28:12 BST --- (In reply to comment #29) > Hi, > > ...As such the AT91SAM9 > series should be implemented as 4 separate platforms under this structure, > although they probably be using common peripheral devices which may also be > shared with the rest of the AT91 family... That's the way I see it, too. > ...The > question I see is do we need to introduce a new set of devices for the > AT91SAM9 > series, only if there are significant enhancements or interoperability issues > would be my humble opinion.... I don't understand. Do you mean all AT91SAM9 SoC in one AT91SAM9 package? Or additional AT91 peripherals? > ...The problem I see with supporting the SAM3 from the > same IO package is that the peripheral bus structure usually implemented on > cortex devices is not the same as the earlier models. Perhaps the IO package > should be divided by peripheral bus structure AHB,AMBA etc. Okay that's enough > from me. About the only problem I had with using existing AT91 drivers with the SAM3 is that, under Cortex arch, the interrupt number is no longer the same as the AT91 peripheral ID. Also, I had to duplicate all the AT91 peripheral definitions into the SAM3 port. Way too much duplication. That's why I think having the AT91 package just be a I/O support package would be a good thing. Dan H. -- 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.
