This is the mail archive of the ecos-devel@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]

Re: Intention to Port eCos to STR9


Andrew Lunn wrote:
> On Wed, Jun 14, 2006 at 02:17:37PM -0600, C. Adam Lamb wrote:
>   
>> Hi Gang,
>>
>> I?m currently looking into porting eCos to the STR912 processor.? The
>> processor is on the bleeding edge (it just came out), so I?m still waiting
>> for my eval board.
>>
>> My first goal in this message is to both let everyone know that I should be
>> starting to work on this soon and see if anyone else might be working on
>> this as well?
>>
>> Second goal is to have someone with some eCos experience make sure my
>> porting approach isn?t too far off.?
>>     
>
> O.K. First tip. Try not to have tunnel vision on the STR912. Try
> taking a look at all the STR7 and STR9 devices. Work out what is
> common and what is different. Try to make your port as generic as
> possible. So if for example the UART is the same for all devices, just
> write a STR UART driver, not a STR912 UART driver. Same goes for SPI,
> FLASH controller, etc.
Also check whether UART (or whatever) is same with some other (allready
ported) platform.
> If a peripheral for the STR9xx is different
> from the STR7xx write an STR9xx driver. And lastly, if the STR912 has
> something unque, write an STR912 unique driver. Same goes for the
> HAL. Try to split it up into a varient HAL for STR9xx and a specific
> HAL STR912. Maybe it is even possible to have a three layer HAL, with
> STR at the top. The different between the STR7 and STR9 will be the
> MMU setup. So maybe it is possible to put the MMU code into the STR9xx
> HAL package and have most of the code in the STR HAL package.
>
> The advantage of doing it like this is it makes it easier for others
> to do ports to other members of the STR family building on what you
> have done. I made a mistake here with the AT91SAM family. I did a port
> to the AT91SAM7S and later found out that the AT91SAM7X is 99% the
> same. I then ended up with a naming mess since the AT91SAM7S package
> now also supports the AT91SAM7X devices. And i guess sometime in the
> future the AT91SAM9 is going to be supported by the AT91SAM7S
> package. Ugly.
>
>   
>> I will be using the all of the GNU tools for building and debugging.?
>>     
>
> That is normal. Using anything else for compiling is virtually
> impossible. You do have more flexibility with debugging, but i still
> recommend gdb. You can add a GUI on top if you like, eg Insight, DDD,
> etc.
>
>   
>> I intend to purchase either Signum System?s JTAG Jet with Trace or the PEEDI
>> JTAG Emulator if I can?t get my company to pony up for the slightly more
>> expensive device from Signum.? Both of those devices claim to be compatible
>> with the GNU debuggers.? Anyone with experience with either of those
>> devices??
>>     
>
> I've had good experiance with PEEDI with the AT91SAM7S development
> board. You need an up to date version of gdb. The version on the eCos
> website as part of the ARM toolchain is too old for breakpoints to
> work properly.
>   
I'm using PEEDI with standard website gdb/Insight on LInux and it's ok.
But maybe I have newer firmware.

Ilija


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