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
next prev parent 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).