This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Philips LPC2294
- From: Xavier <xavier at localhost dot localdomain>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Sun, 5 Sep 2004 18:55:59 -0700
- Subject: [ECOS] 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