[ECOS] FIS problem

[ECOS] FIS problem

[Jing Luo]

Hi,

I had suffering the FLASH DEVICE Support for Redboot for several days.

I can't copy RAM startup Redboot image to ROM after porting FIS on Intel
XSCALE 80200EVB.
Serial port hang during programming to Flash.
Can you help me on this problem?

Procedure:
1. Program ROM start Redboot to FLASH
2. fis init to initialize Flash configuration in Redboot, map as the
following:
RedBoot> fis list

in REDBOOT_FIS: fis_addr @ 0x000f0000, flash_end @ 0x000fffff, block_size =
0x10
000

Name              FLASH addr  Mem addr    Length      Entry point

RedBoot           0x00000000  0x00000000  0x00020000  0x00000000

RedBoot[backup]   0x00020000  0x00020000  0x00020000  0x00000000

RedBoot config    0x000E0000  0x000E0000  0x00001000  0x00000000

FIS directory     0x000F0000  0x000F0000  0x00010000  0x00000000

3. load -m ymodem for RAM start Redboot successfully

\x06Entry point: 0xc0020040, address range: 0xc0020000-0xc002ba6c

xyzModem - CRC mode, 2(SOH)/140(STX)/0(CAN) packets, 3 retries

4. copy RAM startuo Redboot image to secondary Redboot area using the
following command:

RedBoot> fis create RedBoot[backup] -f 0x00020000 -e 0xc0020040 -b
0xc0020000 -r
 0xc0020000 -l 0x20000

An image named 'RedBoot[backup]' exists - are you sure (y/n)? y

... Erase from 0x00020000-0x00040000: ..

... Program from 0xc0020000-0xc0040000 at 0x00020000: 
(Before Program: addr = 0x20000, data @ 0xc0020000, size = 0x10000,
block_mask = 0xffff0000, buffer_size =
0x0) -- my debug information





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

Re: [ECOS] FIS problem

[Jonathan Larmour]

[ sorry for the delay in replying - ecos-discuss postings are only answered
when we have time ]

Jing Luo wrote:
> I can't copy RAM startup Redboot image to ROM after porting FIS on Intel
> XSCALE 80200EVB.
> Serial port hang during programming to Flash.
> Can you help me on this problem?

My guess is the following:

The flash driver has to have its write functions copied into RAM when it is
programming flash and running out of ROM (as is happening here). This is
because you can't access the code in flash that you are running from as you
program it.

There's two ways, and which is used is governed by
CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM option in io/flash which the low level
drivers will set. Depending on this, the relevant functions will hvae been
put in a ".2ram" section by the linker (controlled by
__attribute__((section(".2ram"))) in the code), or have to be copied by
hand. What could be happening is that you have the option set such that the
common code thinks the programming code is already in RAM
(CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM == 0), but actually isn't.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

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

RE: [ECOS] FIS problem

[Jing Luo]

Thanks for the reply.
I've solved the problem. It is because I messed up the cache configuration
of MMU table.


-----Original Message-----
From: Stephen Goadhouse [mailto:stephen.goadhouse@adiengineering.com]
Sent: Thursday, April 25, 2002 8:12 PM
To: Jing Luo
Cc: ecos-discuss@sources.redhat.com
Subject: RE: [ECOS] FIS problem



My first question is how did you do the port.  If you started with the
IQ80310 port, it sets up addresses 0x00000000-0x00001000 to actually point
to physical addresses, 0xc0000000-0xc0001000 (which is SDRAM).  This is so
the vector table can be modified but still exist at the reset address of
0x00000000.  The SDRAM will not respond to the Flash commands as the Flash
code expects.  However, the Flash at physical addresses
0x00000000-0x00001000 is mapped to virtual addresses 0xc0000000-0xc0001000.
You'll need to setup a MACRO to translate the addresses properly (ie., if
try to write to 0x00000000, write to 0xc0000000 instead).

Also, something else to watch out for is the register hole within Flash for
the IQ80310.  They had to skip over a section of addresses within the Flash
area because those addresses were really companion chip registers.  You do
not need to do that for the 80200EVB.

> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Jing Luo
> Sent: Wednesday, April 24, 2002 11:57 AM
> To: 'Jonathan Larmour'; Jing Luo
> Cc: ecos-discuss@sources.redhat.com
> Subject: RE: [ECOS] FIS problem
>
>
> Hi Jonathan,
>
> Thanks for your reply. I know I can count on you when I have
> problem on eCos
> and RedBoot.
> FIS init and fis create RedBoot[backup] works now. :-)
> But, I have been struggling with the following problem on Intel
> 80200EVB for
> a week, may be some one can help me on this?
>
> When I try to create ROM-start Redboot version to FLASH block 0 using
> fis create RedBoot -b 0xc1200000 -s 0x1b880 ( 0xc1200000 is the ROM-start
> Redboot image address in SRAM, image size is 0x1b880),
> erasing block 0 and block 1 works, but hang on program flash block 0 start
> on address 0x0.
> The flash chip I have is TE28F016B3TA90, 2MB 8-bit flash.
> But the same command for creating RedBoot[backup] works. The only
> difference
> is RedBoot[backup] programs FLASH block 3 & 4 from address 0x20000 to
> 0x40000.
>
> Is there bug in Redboot FLASH driver or is there any unknown errata in the
> specific FLASH?
>
> -----Original Message-----
> From: Jonathan Larmour [mailto:jlarmour@redhat.com]
> Sent: Saturday, April 20, 2002 5:22 PM
> To: Jing Luo
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] FIS problem
>
>
> [ sorry for the delay in replying - ecos-discuss postings are
> only answered
> when we have time ]
>
> Jing Luo wrote:
> > I can't copy RAM startup Redboot image to ROM after porting FIS on Intel
> > XSCALE 80200EVB.
> > Serial port hang during programming to Flash.
> > Can you help me on this problem?
>
> My guess is the following:
>
> The flash driver has to have its write functions copied into RAM
> when it is
> programming flash and running out of ROM (as is happening here). This is
> because you can't access the code in flash that you are running
> from as you
> program it.
>
> There's two ways, and which is used is governed by
> CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM option in io/flash which the low level
> drivers will set. Depending on this, the relevant functions will hvae been
> put in a ".2ram" section by the linker (controlled by
> __attribute__((section(".2ram"))) in the code), or have to be copied by
> hand. What could be happening is that you have the option set
> such that the
> common code thinks the programming code is already in RAM
> (CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM == 0), but actually isn't.
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>


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

RE: [ECOS] FIS problem

[Stephen Goadhouse]

My first question is how did you do the port.  If you started with the
IQ80310 port, it sets up addresses 0x00000000-0x00001000 to actually point
to physical addresses, 0xc0000000-0xc0001000 (which is SDRAM).  This is so
the vector table can be modified but still exist at the reset address of
0x00000000.  The SDRAM will not respond to the Flash commands as the Flash
code expects.  However, the Flash at physical addresses
0x00000000-0x00001000 is mapped to virtual addresses 0xc0000000-0xc0001000.
You'll need to setup a MACRO to translate the addresses properly (ie., if
try to write to 0x00000000, write to 0xc0000000 instead).

Also, something else to watch out for is the register hole within Flash for
the IQ80310.  They had to skip over a section of addresses within the Flash
area because those addresses were really companion chip registers.  You do
not need to do that for the 80200EVB.

> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Jing Luo
> Sent: Wednesday, April 24, 2002 11:57 AM
> To: 'Jonathan Larmour'; Jing Luo
> Cc: ecos-discuss@sources.redhat.com
> Subject: RE: [ECOS] FIS problem
>
>
> Hi Jonathan,
>
> Thanks for your reply. I know I can count on you when I have
> problem on eCos
> and RedBoot.
> FIS init and fis create RedBoot[backup] works now. :-)
> But, I have been struggling with the following problem on Intel
> 80200EVB for
> a week, may be some one can help me on this?
>
> When I try to create ROM-start Redboot version to FLASH block 0 using
> fis create RedBoot -b 0xc1200000 -s 0x1b880 ( 0xc1200000 is the ROM-start
> Redboot image address in SRAM, image size is 0x1b880),
> erasing block 0 and block 1 works, but hang on program flash block 0 start
> on address 0x0.
> The flash chip I have is TE28F016B3TA90, 2MB 8-bit flash.
> But the same command for creating RedBoot[backup] works. The only
> difference
> is RedBoot[backup] programs FLASH block 3 & 4 from address 0x20000 to
> 0x40000.
>
> Is there bug in Redboot FLASH driver or is there any unknown errata in the
> specific FLASH?
>
> -----Original Message-----
> From: Jonathan Larmour [mailto:jlarmour@redhat.com]
> Sent: Saturday, April 20, 2002 5:22 PM
> To: Jing Luo
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] FIS problem
>
>
> [ sorry for the delay in replying - ecos-discuss postings are
> only answered
> when we have time ]
>
> Jing Luo wrote:
> > I can't copy RAM startup Redboot image to ROM after porting FIS on Intel
> > XSCALE 80200EVB.
> > Serial port hang during programming to Flash.
> > Can you help me on this problem?
>
> My guess is the following:
>
> The flash driver has to have its write functions copied into RAM
> when it is
> programming flash and running out of ROM (as is happening here). This is
> because you can't access the code in flash that you are running
> from as you
> program it.
>
> There's two ways, and which is used is governed by
> CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM option in io/flash which the low level
> drivers will set. Depending on this, the relevant functions will hvae been
> put in a ".2ram" section by the linker (controlled by
> __attribute__((section(".2ram"))) in the code), or have to be copied by
> hand. What could be happening is that you have the option set
> such that the
> common code thinks the programming code is already in RAM
> (CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM == 0), but actually isn't.
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>



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

RE: [ECOS] FIS problem

[Jesper Skov]

On Wed, 2002-04-24 at 17:57, Jing Luo wrote:
> When I try to create ROM-start Redboot version to FLASH block 0 using 
> fis create RedBoot -b 0xc1200000 -s 0x1b880 ( 0xc1200000 is the ROM-start
> Redboot image address in SRAM, image size is 0x1b880),
> erasing block 0 and block 1 works, but hang on program flash block 0 start
> on address 0x0.
> The flash chip I have is TE28F016B3TA90, 2MB 8-bit flash.
> But the same command for creating RedBoot[backup] works. The only difference
> is RedBoot[backup] programs FLASH block 3 & 4 from address 0x20000 to
> 0x40000.

By any chance, is there a gap in the flash used for board magic? I know
on some platforms, the range 0x10-0x20 contain board identification
stuff, overriding flash memory in that range.

Obviously, any attempt to program that range is going to fail. In
particular, if the flash driver loops waiting for a status update on the
programmed address, it may hang.

Jesper


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

RE: [ECOS] FIS problem

[Jing Luo]

Hi Jonathan,

Thanks for your reply. I know I can count on you when I have problem on eCos
and RedBoot.
FIS init and fis create RedBoot[backup] works now. :-)
But, I have been struggling with the following problem on Intel 80200EVB for
a week, may be some one can help me on this?

When I try to create ROM-start Redboot version to FLASH block 0 using 
fis create RedBoot -b 0xc1200000 -s 0x1b880 ( 0xc1200000 is the ROM-start
Redboot image address in SRAM, image size is 0x1b880),
erasing block 0 and block 1 works, but hang on program flash block 0 start
on address 0x0.
The flash chip I have is TE28F016B3TA90, 2MB 8-bit flash.
But the same command for creating RedBoot[backup] works. The only difference
is RedBoot[backup] programs FLASH block 3 & 4 from address 0x20000 to
0x40000.

Is there bug in Redboot FLASH driver or is there any unknown errata in the
specific FLASH?

-----Original Message-----
From: Jonathan Larmour [mailto:jlarmour@redhat.com]
Sent: Saturday, April 20, 2002 5:22 PM
To: Jing Luo
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] FIS problem


[ sorry for the delay in replying - ecos-discuss postings are only answered
when we have time ]

Jing Luo wrote:
> I can't copy RAM startup Redboot image to ROM after porting FIS on Intel
> XSCALE 80200EVB.
> Serial port hang during programming to Flash.
> Can you help me on this problem?

My guess is the following:

The flash driver has to have its write functions copied into RAM when it is
programming flash and running out of ROM (as is happening here). This is
because you can't access the code in flash that you are running from as you
program it.

There's two ways, and which is used is governed by
CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM option in io/flash which the low level
drivers will set. Depending on this, the relevant functions will hvae been
put in a ".2ram" section by the linker (controlled by
__attribute__((section(".2ram"))) in the code), or have to be copied by
hand. What could be happening is that you have the option set such that the
common code thinks the programming code is already in RAM
(CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM == 0), but actually isn't.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

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