This is the mail archive of the ecos-discuss@sources.redhat.com 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]

Philips LPC2294


As the subject indicates I'm using a Philips LPC2294 microcontroller, and am attempting
to port ecos to it.  I found reference, on the list, to a port for the LPC2106, and have
been referencing that patch for guidance, where applicable.  I'm using the ecos-2.0 sources,
and am using the arm-elf tool chain, which I obtained from the ecos.sourceware.org website.
I'm using the Anthony Massa book as a reference guide as well.

The Massa book indicates that a good place to start is to get the 'redboot' image going,
and then move forward from there.  OK, Fair enough.

The LPC2294 has rom (flash) and ram located at:

    ram : ORIGIN = 0x40000000, LENGTH = 0x00004000
    rom : ORIGIN = 0x00000000, LENGTH = 0x00040000

The hardware I am currently working with is from Phytec, and they have added additional rom
(flash) and ram at:

    ram0 : ORIGIN = 0x81000000, LENGTH = 0x00100000
    rom0 : ORIGIN = 0x80000000, LENGTH = 0x00200000

To date, I have not been able to get very far into the boot process, for example:

        mov     r0,#0           // move vectors
        ldr     r1,=__exception_handlers
#ifndef CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
        // Wait with this if stubs are included (see further down).
        ldr     r2,[r1,#0x04]   // undefined instruction
        str     r2,[r0,#0x04]
        ldr     r2,[r1,#0x24]
        str     r2,[r0,#0x24]
#endif
        ldr     r2,[r1,#0x08]   // software interrupt
        str     r2,[r0,#0x08]

Neglecting the stuff inside the #ifndef/#endif the assumption here, I believe, is that 'ram' is
at 0x0, and 'rom' is at 0x__exception_handlers (or there about); and as such, the swi interrupt
needs to be relocated from ram to rom.  In the case of the LPC2xxx, this isn't true; well, I'm
certain that this isn't true of the LPC2294 and neighbors, not certain about the whole LPC2xxx
family.  None the less, when the instruction:

        str r2,[r0,#0x08]

is executed, the processor hangs.  I believe that a 'undefined_instruction' exception occurs,
and then .... well, everything melts down.  This particular assumption occurs at a number of
points during the bootup procedure, 'warm_reset' and 'start'.

So ... what's the 'preferred' method to handle this situation?

Do I have to add a whole new architecture strain?  This doesn't seem like the right thing to do,
as the LPC2xxx is based off of the ARM7TDMI-S core -- it is, essentially, an 'arm' processor.

Is there another alternative?

One more thing, while not critical, but thought I should ask:

According to this comment, found in packages/hal/arm/arch/v2_0/src/vectors.S:

        // Run kernel + application in THUMB mode
        THUMB_MODE(r1,10)

The kernel and application will be runin thumb mode, I would prefer to run in ARM mode as that will
enrichen the instruction set, and I'm not (currently) concerned about the memory savings (waste?)
(though, that may change).

The 'priority' item, is to get the dang thing to boot.

If there is anyone with the time and patience who would be willing to help guide me through this
whole 'porting' process, I would greatly appreciate it.  I think I've made great strides forward
in identifying what is going on (well, I'd like to think so, anyway).  However, a second opinion
would be helpful, as I may have 'glossed' over something else which is the _real_ problem.

xavyer


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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