public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Frank Pagliughi <fpagliughi@mindspring.com>
To: Pazos Escudero Nuria <Nuria.PazosEscudero@he-arc.ch>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Booting from Flash in a AT91M55800A based platform
Date: Fri, 01 Aug 2008 19:34:00 -0000	[thread overview]
Message-ID: <4893651E.50703@mindspring.com> (raw)
In-Reply-To: <F7620004260C5D4DB836EDBF8CC6872D037CB694@neptune.intra.eiaj.ch>

Pazos Escudero Nuria wrote:

>Hi,
>
>I've ported eCos and RedBoot for a proprietary platform comprising the
>AT91M55800A processor a SRAM and three S29AL016D90TFI02 flash modules.
>The RAM version works fine and I can communicate with the RedBoot
>console through the serial port, but I have not yet managed to make the
>platform boot from the flash (after copying the ROM version of the
>ported RedBoot on the flash address pointed by the chip select 0). I
>don't know whether the problem comes from the platform porting or from
>the fact that eCos does not recognize the used flash chips from
>Spansion. Could you provide me any hint?
>
>Thanks in advance!
>Nuria
>
>  
>
If you're programming the Flash chips with a JTAG, then the lack of eCos 
drivers doesn't matter at this stage.
- Does the JTAG software claim that the "program and verify" worked 
properly?
- Are the Flash chips properly wired on the board?
- Did you set up the "_InitMemory" table in "hal_platform_setup.h" for 
the Flash chip(s). You need to set the base address, # wait states, etc. 
Plus the base address for each CS line must be different, even if the CS 
is disabled.
- You should be able to reset the CPU and single step through the first 
few instructions, using the JTAG and/or gdb. Remember that the chip 
starts with the first Flash (CS0) mapped to address zero. You can single 
step up to the point where the chip select registers are loaded and make 
sure that the values are being loaded properly.  But note that you can't 
step over the remap command since the debugger messes with the pipeline.
- One of the first things that the assembly startup does is set the 
master clock (and maybe the PLL) running faster. If you set them running 
faster than the external board can support, the board may lock up.


Whatever you're using to load the RAM debug code onto the board is 
initializing it properly (a JTAG initialization file?). Use that as a 
starting point. The only thing it isn't doing is setting up the Flash 
chip select registers in the EBI, so pay careful attention to that.

Frank

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

  reply	other threads:[~2008-08-01 19:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-31  8:00 Pazos Escudero Nuria
2008-08-01 19:34 ` Frank Pagliughi [this message]
2008-08-05 22:15 Lambrecht Jürgen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4893651E.50703@mindspring.com \
    --to=fpagliughi@mindspring.com \
    --cc=Nuria.PazosEscudero@he-arc.ch \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).