public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* RE: [ECOS] Problems booting from FLASH on ARM7/AT91
@ 2001-08-13  8:54 Karl-Magnus.Moeller
  0 siblings, 0 replies; 3+ messages in thread
From: Karl-Magnus.Moeller @ 2001-08-13  8:54 UTC (permalink / raw)
  To: jlarmour; +Cc: ecos-discuss

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

Thank you very much for your input.

After a long debugging session, we found that the wrong timer was
initialized
and used for eCos. This lead to that eCos never got a tick and got stuck in
the idle loop. As always the worst bugs are the the ones that are the most
uncomplicated. But at least I've gained some experience when it comes to the
the boot process of ARM7 and the vector setup of eCos for ARM. 

We got down to some low level debugging by using some registers and a free
I/O pin on a PLD connected to the AT91 to send a serial debug output message
that we measured on an oscilloscope (both serial ports on the AT91 are used
for other functions). 

Thank you for your ideas.

Regards,
Karl-Magnus


> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Sent: den 12 augusti 2001 21:58
> To: Möller Karl-Magnus
> Cc: ecos-discuss@sourceware.cygnus.com
> Subject: Re: [ECOS] Problems booting from FLASH on ARM7/AT91
> 
> 
> Karl-Magnus.Moeller@combitechsystems.com wrote:
> > The first thread that displays a welcome
> > message on the LCD also starts. But right after that, it seems like
> > everything just locks up. And I just can't understand why.
> 
> You could use the old "printf" technique to see how far it gets (or
> "diag_printf" would be better in eCos). But my first guess 
> would be some
> problem with the clock interrupt. If you were having problems with the
> memory mapping, perhaps the IRQ vector is not pointing into 
> the memory map
> with the correct addresses.
> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 
> (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || 
> Opinions==mine
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] Problems booting from FLASH on ARM7/AT91
  2001-08-12 11:32 Karl-Magnus.Moeller
@ 2001-08-12 12:57 ` Jonathan Larmour
  0 siblings, 0 replies; 3+ messages in thread
From: Jonathan Larmour @ 2001-08-12 12:57 UTC (permalink / raw)
  To: Karl-Magnus.Moeller; +Cc: ecos-discuss

Karl-Magnus.Moeller@combitechsystems.com wrote:
> The first thread that displays a welcome
> message on the LCD also starts. But right after that, it seems like
> everything just locks up. And I just can't understand why.

You could use the old "printf" technique to see how far it gets (or
"diag_printf" would be better in eCos). But my first guess would be some
problem with the clock interrupt. If you were having problems with the
memory mapping, perhaps the IRQ vector is not pointing into the memory map
with the correct addresses.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [ECOS] Problems booting from FLASH on ARM7/AT91
@ 2001-08-12 11:32 Karl-Magnus.Moeller
  2001-08-12 12:57 ` Jonathan Larmour
  0 siblings, 1 reply; 3+ messages in thread
From: Karl-Magnus.Moeller @ 2001-08-12 11:32 UTC (permalink / raw)
  To: ecos-discuss

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

Hi,

I am using a custom board with an ARM7/AT91FR4081 and I have used the EB01
port as a starting point for my platform port.

When building for RAM, I have no problems and  eCos and the applications are
running perfectly. But when I build for ROM, things start to get bad...

At first I had problems booting from FLASH, which lead to that I had to set
the reset vector manually in vectors.S to point at the start of the text
segment. This worked out fine, even though it is an ugly approach.

eCos boots up and executes hal_platform_setup.h which initializes all Chip
Selects and performs a remap. The data segment is copied to it's final
destination in RAM. cyg_start.cpp executes and starts the driver for the LCD
display that we have on the board. The first thread that displays a welcome
message on the LCD also starts. But right after that, it seems like
everything just locks up. And I just can't understand why.

Unfortunately, the design is so compact that it is very hard to get access
to the data and address bus. My debugger won't give me much support either
(Wiggler with OCDemon). 

I appreciate all input. 

Regards,

/Karl-Magnus Möller

I have mapped the memory like this:
0x0000 0000 - 0x1001 FFFF (128kb External RAM at 10000000-1001FFFF+8kb )
and 
0x8000 0000 - 0x800F FFFF (1Mb internal FLASH connected to CS0)

This is my mlt_arm_eb01_rom.mlt:

version 0
region ram 0 10020000 0 !
region rom 80000000 100000 1 !
section fixed_vectors 0 1 1 1 1 0 1 0 20 80000020 !
section data 0 1 1 1 1 1 1 0 10000100 80040000 bss !
section bss 0 4 0 1 0 0 0 0 !
section rom_vectors 0 1 0 1 1 0 1 0 80000000 80000000 !
section text 0 1 0 1 1 1 1 1 80000100 80000100 fini fini !
section fini 0 4 0 1 0 1 0 1 rodata rodata !
section rodata 0 4 0 1 0 1 0 1 rodata1 rodata1 !
section rodata1 0 4 0 1 0 1 0 1 fixup fixup !
section fixup 0 4 0 1 0 1 0 1 gcc_except_table gcc_except_table !
section gcc_except_table 0 4 0 1 0 0 0 0 !



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-08-13  8:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-13  8:54 [ECOS] Problems booting from FLASH on ARM7/AT91 Karl-Magnus.Moeller
  -- strict thread matches above, loose matches on Subject: below --
2001-08-12 11:32 Karl-Magnus.Moeller
2001-08-12 12:57 ` Jonathan Larmour

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).