jffs2+mtd+big endian problem

jffs2+mtd+big endian problem

[Li Yang-r58472]

Hi,

I'm doing a JFFS2 port to a PowerPC target board.  I have several questions while porting.

1. Which kind of endian should I use in JFFS2?  Mkfs.jffs2 (older version, I have tried the new binary on JFFS2 website, the big-endian option breaks) can generate images of the two endian types.

2. I added a new map file in driver/mtd/maps directory.  Which read/write/memcpy operation should I use?  __raw_readw() or readw()? Or Inw()?  They determined whether to swap bytes.

I have tried several cases.  When I use little-endian fs and __raw_read(), the JFFS2 mount got error: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0x8519 instead.  

However, after I change to use big-endian fs, mount can be successful.  Create new file on JFFS2 got error: Node totlen on flash (0x44000000) != totlen in node ref (0x00000044).  Seems data written to flash are 32-bit byte-swaped.

Has anyone here done JFFS2 on Powerpc Big-endian system?  What are your options?


--
Leo Li
Software Engineer
Metrowerks -- a Motorola company
Linux Solutions Group
 
Office: +8610-65642272
LeoLi@motorola.com
 

Re: jffs2+mtd+big endian problem

[David Woodhouse]

On Mon, 2004-01-19 at 16:43 +0800, Li Yang-r58472 wrote:
> Hi,
> 
> I'm doing a JFFS2 port to a PowerPC target board.  I have several
> questions while porting.
> 
> 1. Which kind of endian should I use in JFFS2?  Mkfs.jffs2 (older
> version, I have tried the new binary on JFFS2 website, the big-endian
> option breaks) can generate images of the two endian types.

There are two options. First, you can try a fixed version of mkfs.jffs2
which gets the byte-swapping right. I've uploaded the current CVS
version, 1.39, to sources.redhat.com now -- I think that should be OK.

Second, you could use the current CVS JFFS2 code (you should probably
use that anyway since it has a lot of optimisations missing from older
kernels), and make it use little-endian images by defining
JFFS2_LITTLE_ENDIAN instead of JFFS2_NATIVE_ENDIAN at about line 90 of
include/linux/jffs2.h

> 2. I added a new map file in driver/mtd/maps directory.  Which
> read/write/memcpy operation should I use?  __raw_readw() or readw()?
> Or Inw()?  They determined whether to swap bytes.

That depends on how your hardware is wired up. It's probably best not to
try this with JFFS2, which introduces its own endianness complexity...
try it with raw read/write (and the erase ioctl of course) on the
/dev/mtd devices. Read and write data in units of 1, 2 and 4 bytes at
various offsets and see what you get.

> I have tried several cases.  When I use little-endian fs and
> __raw_read(), the JFFS2 mount got error: jffs2_scan_eraseblock():
> Magic bitmask 0x1985 not found at 0x00000000: 0x8519 instead.  
> 
> However, after I change to use big-endian fs, mount can be successful.
> Create new file on JFFS2 got error: Node totlen on flash (0x44000000)
> != totlen in node ref (0x00000044).  Seems data written to flash are
> 32-bit byte-swaped.

That's odd. If you look in the image file you downloaded to the board,
is it telling the truth? Do you actually see (00,00,00,44) or
(44,00,00,00). Can you make the actual image available to me to play
with, and I'll tell you whether it's a valid image and your board
mapping is at fault, or whether it's an invalid image.

> Has anyone here done JFFS2 on Powerpc Big-endian system?  What are
> your options?

Mostly people using JFFS2 on PPC are using it in big-endian mode, I
think.

-- 
dwmw2

RE: jffs2+mtd+big endian problem

[Joakim Tjernlund]

> Second, you could use the current CVS JFFS2 code (you should probably
> use that anyway since it has a lot of optimisations missing from older
> kernels), and make it use little-endian images by defining
> JFFS2_LITTLE_ENDIAN instead of JFFS2_NATIVE_ENDIAN at about line 90 of
> include/linux/jffs2.h

Why little endian? Have you standardized on little endian for JFFS2? The 
last I remember there was a discussion about JFFS2 endianness but no decision.
I think little endian is the way of the past, big endian is the future.

 Jocke 

Re: jffs2+mtd+big endian problem

[Li Yang]

On Mon, 2004-01-19 at 17:17, David Woodhouse wrote:
> On Mon, 2004-01-19 at 16:43 +0800, Li Yang-r58472 wrote:
> > Hi,
> >
> > I'm doing a JFFS2 port to a PowerPC target board.  I have several
> > questions while porting.
> >
> > 1. Which kind of endian should I use in JFFS2?  Mkfs.jffs2 (older
> > version, I have tried the new binary on JFFS2 website, the
big-endian
> > option breaks) can generate images of the two endian types.
> 
> There are two options. First, you can try a fixed version of
mkfs.jffs2
> which gets the byte-swapping right. I've uploaded the current CVS
> version, 1.39, to sources.redhat.com now -- I think that should be OK.
> 
> Second, you could use the current CVS JFFS2 code (you should probably
> use that anyway since it has a lot of optimisations missing from older
> kernels), and make it use little-endian images by defining
> JFFS2_LITTLE_ENDIAN instead of JFFS2_NATIVE_ENDIAN at about line 90 of
> include/linux/jffs2.h

I have some problem accessing CVS from the damned corporate network. 
I'm a poor guy living on binaries and snapshots.  :(  Thanks for you
update.
I'm using JFFS2 code from kernel-2.4.22.  Seems it's pretty old code in
the kernel.  Could you kindly give me a recent snapshot or direct me to
a link to download it?

> 
> > 2. I added a new map file in driver/mtd/maps directory.  Which
> > read/write/memcpy operation should I use?  __raw_readw() or readw()?
> > Or Inw()?  They determined whether to swap bytes.
> 
> That depends on how your hardware is wired up. It's probably best not
to
> try this with JFFS2, which introduces its own endianness complexity...
> try it with raw read/write (and the erase ioctl of course) on the
> /dev/mtd devices. Read and write data in units of 1, 2 and 4 bytes at
> various offsets and see what you get.
> 
> > I have tried several cases.  When I use little-endian fs and
> > __raw_read(), the JFFS2 mount got error: jffs2_scan_eraseblock():
> > Magic bitmask 0x1985 not found at 0x00000000: 0x8519 instead.
> >
> > However, after I change to use big-endian fs, mount can be
successful.
> > Create new file on JFFS2 got error: Node totlen on flash
(0x44000000)
> > != totlen in node ref (0x00000044).  Seems data written to flash are
> > 32-bit byte-swaped.
> 
> That's odd. If you look in the image file you downloaded to the board,
> is it telling the truth? Do you actually see (00,00,00,44) or
> (44,00,00,00). Can you make the actual image available to me to play
> with, and I'll tell you whether it's a valid image and your board
> mapping is at fault, or whether it's an invalid image.

The image generated by mkfs.jffs2 with -b seems ok, but it's not all
right after I done some operations on the target.  In the bottom is the
log of these operations.

Yes, I have examined a section which is formatted by the target board. 
The first several bytes of the section are:  

fe3c0000: 03208519 0c000000 98dc60f0 ffffffff    . ........`.....
fe3c0010: ffffffff ffffffff ffffffff ffffffff    ................

They are all 32-bit swapped.  I traced into the JFFS2 code, and know it
use mtd->write to write data into flash.  Which function is it turned
out to be finally?  Is it the write defined in the drivers/mtd/maps/
files?  I used __raw_write*() at the very beginning, it shouldn't be
like this.

> 
> > Has anyone here done JFFS2 on Powerpc Big-endian system?  What are
> > your options?
> 
> Mostly people using JFFS2 on PPC are using it in big-endian mode, I
> think.
> 
> --
> dwmw2

Log of the operations: 

# mount -t jffs2 /dev/mtdblock1 /mnt
mtdblock_open
ok
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c0000:
0x0320 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c0004:
0x0c00 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c0008:
0x98dc instead
JFFS2: Erase block at 0x003c0000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00400000:
0x0320 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00400004:
0x0c00 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00400008:
0x98dc instead
JFFS2: Erase block at 0x00400000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00440000:
0x0320 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00440004:
0x0c00 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00440008:
0x98dc instead
JFFS2: Erase block at 0x00440000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00480000:
0x0320 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00480004:
0x0c00 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00480008:
0x98dc instead
JFFS2: Erase block at 0x00480000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c0000:
0x0320 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c0004:
0x0c00 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c0008:
0x98dc instead
JFFS2: Erase block at 0x004c0000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00500000:
0x0320 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00500004:
0x0c00 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00500008:
0x98dc instead
JFFS2: Erase block at 0x00500000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00540000:
0x0320 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00540004:
0x0c00 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00540008:
0x98dc instead
JFFS2: Erase block at 0x00540000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00580000:
0x0320 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00580004:
0x0c00 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00580008:
0x98dc instead
JFFS2: Erase block at 0x00580000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x005c0000:
0x0320 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x005c0004:
0x0c00 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x005c0008:
0x98dc instead
JFFS2: Erase block at 0x005c0000 is not formatted. It will be erased
# cd /mnt
# ls
bin      dev      home     mnt      prj_tmp  root     tmp      var
boot     etc      lib      opt      proc     sbin     usr
# touch abc
Node totlen on flash (0x44000000) != totlen in node ref (0x00000044)
# ls
abc      boot     etc      lib      opt      proc     sbin     usr
bin      dev      home     mnt      prj_tmp  root     tmp      var
# echo "jhskjfsldfjdklsf" > abc
Node totlen on flash (0x44000000) != totlen in node ref (0x00000044)
Node totlen on flash (0x44000000) != totlen in node ref (0x00000044)

Re: jffs2+mtd+big endian problem

[David Woodhouse]

On Mon, 2004-01-19 at 18:58 +0800, Li Yang wrote:
> I have some problem accessing CVS from the damned corporate network. 

How strange. I can make the machine available for dialin if you want --
it's funny how a few international phone calls make managers suddenly
want to lean on incompetent IS staff to fix broken firewalls :)

If you really can't even use CONNECT through an HTTP proxy, there are
nightly snapshots at ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/

> The image generated by mkfs.jffs2 with -b seems ok, but it's not all
> right after I done some operations on the target.  In the bottom is the
> log of these operations.
> 
> Yes, I have examined a section which is formatted by the target board. 
> The first several bytes of the section are:  
> 
> fe3c0000: 03208519 0c000000 98dc60f0 ffffffff    . ........`.....
> fe3c0010: ffffffff ffffffff ffffffff ffffffff    ................
> 
> They are all 32-bit swapped.  I traced into the JFFS2 code, and know it
> use mtd->write to write data into flash.  Which function is it turned
> out to be finally?  Is it the write defined in the drivers/mtd/maps/
> files?  I used __raw_write*() at the very beginning, it shouldn't be
> like this.

This sounds like you're using byte-swapping operations in your map
driver. You should be using __raw_write*() not write*(). You said you
were 'at the very beginning'... are you still doing that now?

-- 
dwmw2

Re: jffs2+mtd+big endian problem

[Li Yang]

On Mon, 2004-01-19 at 19:04, David Woodhouse wrote:
> On Mon, 2004-01-19 at 18:58 +0800, Li Yang wrote:
> > I have some problem accessing CVS from the damned corporate network. 
> 
> How strange. I can make the machine available for dialin if you want --
> it's funny how a few international phone calls make managers suddenly
> want to lean on incompetent IS staff to fix broken firewalls :)

Well, I hope i can do so.  But I have to get a modem first.  =)

> 
> If you really can't even use CONNECT through an HTTP proxy, there are
> nightly snapshots at ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/

No, I can't use CONNECT through an HTTP proxy.  I think they intend to
do so due to some *security* reason, anyway, the network is absolutely
not secure in my opinion.  It's so kind of you to provide the snapshot.

> 
> > The image generated by mkfs.jffs2 with -b seems ok, but it's not all
> > right after I done some operations on the target.  In the bottom is the
> > log of these operations.
> > 
> > Yes, I have examined a section which is formatted by the target board. 
> > The first several bytes of the section are:  
> > 
> > fe3c0000: 03208519 0c000000 98dc60f0 ffffffff    . ........`.....
> > fe3c0010: ffffffff ffffffff ffffffff ffffffff    ................
> > 
> > They are all 32-bit swapped.  I traced into the JFFS2 code, and know it
> > use mtd->write to write data into flash.  Which function is it turned
> > out to be finally?  Is it the write defined in the drivers/mtd/maps/
> > files?  I used __raw_write*() at the very beginning, it shouldn't be
> > like this.
> 
> This sounds like you're using byte-swapping operations in your map
> driver. You should be using __raw_write*() not write*(). You said you
> were 'at the very beginning'... are you still doing that now?

I have verified my maps/ file.  I'm using __raw_write*() now.  Here is
part of my maps file, I don't know if the memcpy_toio() matters.

#define WINDOW_ADDR 0xfe000000
#define WINDOW_SIZE 0x800000
                                                                                                       
static struct mtd_partition physmap_partitions[] = {
/* Put your own partition definitions here */
        {
                name:           "JFFS2",
                size:           0x600000,
                offset:         0,
        }, {
                name:           "uImage",
                size:           0x100000,
                offset:         0x600000,
                mask_flags:     MTD_WRITEABLE,  /* force read-only */
        }, {
                name:           "u-boot",
                size:           0x40000,
                offset:         0x700000,
                mask_flags:     MTD_WRITEABLE,  /* force read-only */
        }, {
                name:           "u-boot env",
                size:           0x40000,
                offset:         0x740000,
                mask_flags:     MTD_WRITEABLE,  /* force read-only */
        }
};
                                                                                                       
#define NUM_PARTITIONS  (sizeof(physmap_partitions)/sizeof(struct
mtd_partition))
                                                                                                       
static struct mtd_info *mymtd;
                                                                                                       
__u8 ads_read8(struct map_info *map, unsigned long ofs)
{
        return __raw_readb(map->map_priv_1 + ofs);
}
                                                                                                       
__u16 ads_read16(struct map_info *map, unsigned long ofs)
{
        return __raw_readw(map->map_priv_1 + ofs);
}
                                                                                                       
__u32 ads_read32(struct map_info *map, unsigned long ofs)
{
        return __raw_readl(map->map_priv_1 + ofs);
}
                                                                                                       
void ads_copy_from(struct map_info *map, void *to, unsigned long from,
ssize_t len)
{
        memcpy_fromio(to, (void *)(map->map_priv_1 + from), len);
}
                                                                                                       
void ads_write8(struct map_info *map, __u8 d, unsigned long adr)
{
        __raw_writeb(d, map->map_priv_1 + adr);
        mb();
}
                                                                                                       
void ads_write16(struct map_info *map, __u16 d, unsigned long adr)
{
        __raw_writew(d, map->map_priv_1 + adr);
        mb();
}
                                                                                                       
void ads_write32(struct map_info *map, __u32 d, unsigned long adr)
{
        __raw_writel(d, map->map_priv_1 + adr);
        mb();
}
                                                                                                       
void ads_copy_to(struct map_info *map, unsigned long to, const void
*from, ssize_t len)
{
        memcpy_toio((void *)(map->map_priv_1 + to), from, len);
}

struct map_info ads_map = {
        name: "Flash SIMM",
        size: WINDOW_SIZE,
        buswidth: 4,
        read8: ads_read8,
        read16: ads_read16,
        read32: ads_read32,
        copy_from: ads_copy_from,
        write8: ads_write8,
        write16: ads_write16,
        write32: ads_write32,
        copy_to: ads_copy_to
};


--
Thank you 
Leo

Re: jffs2+mtd+big endian problem

[David Woodhouse]

On Tue, 2004-01-20 at 12:20 +0800, Li Yang wrote:
> > This sounds like you're using byte-swapping operations in your map
> > driver. You should be using __raw_write*() not write*(). You said you
> > were 'at the very beginning'... are you still doing that now?
> 
> I have verified my maps/ file.  I'm using __raw_write*() now.  Here is
> part of my maps file, I don't know if the memcpy_toio() matters.

It doesn't -- it'll never get used. All you need are read32, write32 and
copy_from. Try this...
                                                                      
__u32 ads_read32(struct map_info *map, unsigned long ofs)
{
        return *(volatile __u32 *)(map->map_priv_1 + ofs);
}
                                                                                                       
void ads_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
{
        memcpy(to, (void *)(map->map_priv_1 + from), len);
}
                                                                                                       
void ads_write32(struct map_info *map, __u32 d, unsigned long adr)
{
        *(volatile __u32 *)(map->map_priv_1 + adr) = d;
        mb();
}
 

Did you try reading and writing chunks of 1, 2 and 4 bytes directly
to/from /dev/mtd0?

-- 
dwmw2

Re: jffs2+mtd+big endian problem

[Li Yang]

On Tue, 2004-01-20 at 15:32, David Woodhouse wrote:
> On Tue, 2004-01-20 at 12:20 +0800, Li Yang wrote:
> > > This sounds like you're using byte-swapping operations in your map
> > > driver. You should be using __raw_write*() not write*(). You said you
> > > were 'at the very beginning'... are you still doing that now?
> > 
> > I have verified my maps/ file.  I'm using __raw_write*() now.  Here is
> > part of my maps file, I don't know if the memcpy_toio() matters.
> 
> It doesn't -- it'll never get used. All you need are read32, write32 and
> copy_from. Try this...
>                                                                       
> __u32 ads_read32(struct map_info *map, unsigned long ofs)
> {
>         return *(volatile __u32 *)(map->map_priv_1 + ofs);
> }
>                                                                                                        
> void ads_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
> {
>         memcpy(to, (void *)(map->map_priv_1 + from), len);
> }
>                                                                                                        
> void ads_write32(struct map_info *map, __u32 d, unsigned long adr)
> {
>         *(volatile __u32 *)(map->map_priv_1 + adr) = d;
>         mb();
> }
>  
> 
> Did you try reading and writing chunks of 1, 2 and 4 bytes directly
> to/from /dev/mtd0?

It's very strange even when I use the complex mapping as you given above
the write is still 32bit swapped.  And I tried writing 1, 2 and 4 bytes
using cp.  For block device, write is successful but still swapped.  For
char device, the following error message is given.

# cp u16 /dev/mtd1
MTD_open
MTD_ioctl
Invalid ioctl 402c7413 (MEMGETINFO = 40204d01)
MTD_write
MTD_close
# cp u16 /dev/mtdblock1
mtdblock_open
ok
mtdblock: read on "JFFS" at 0x0, size 0x200
mtdblock: write on "JFFS" at 0x0, size 0x200
mtdblock_release
mtdblock: writing cached data for "JFFS" at 0x0, size 0x40000
ok
#


-- 
Li Yang <leoli@motorola.com>
Metrowerks

Re: jffs2+mtd+big endian problem

[Li Yang]

Thank you.  I got it.

In drivers/mtd/chips/sharp.c line 362
There is a hard coded cpu_to_le32 swap, which caused the swap issue.

I have tried to use Jedec_probe instead of sharp driver, but it always
recognizes my sharp flash as Intel flash, they have the same vendor id
and product id. Ugly.  And then something goes wrong.  So I have to
stick to the obsoleted sharp driver.  Thank you for the continued help.

-- 

Li Yang <leoli@motorola.com>

Metrowerks

Re: jffs2+mtd+big endian problem

[David Woodhouse]

On Thu, 2004-02-05 at 11:07 +0800, Li Yang wrote:
> Thank you.  I got it.
> 
> In drivers/mtd/chips/sharp.c line 362
> There is a hard coded cpu_to_le32 swap, which caused the swap issue.

Aha :)

> I have tried to use Jedec_probe instead of sharp driver, but it always
> recognizes my sharp flash as Intel flash, they have the same vendor id
> and product id. Ugly.  And then something goes wrong.  So I have to
> stick to the obsoleted sharp driver.  Thank you for the continued help.

Hmmm. I'd feel happier if you were to identify the 'something' which
goes wrong. I was just about to remove the sharp driver from the tree on
the basis that it's obsolete.

Could it be as simple as disabling the erase suspend?

-- 
dwmw2

Re: jffs2+mtd+big endian problem

[Li Yang]

On Thu, 2004-02-05 at 15:00, David Woodhouse wrote:
> On Thu, 2004-02-05 at 11:07 +0800, Li Yang wrote:
> > I have tried to use Jedec_probe instead of sharp driver, but it always
> > recognizes my sharp flash as Intel flash, they have the same vendor id
> > and product id. Ugly.  And then something goes wrong.  So I have to
> > stick to the obsoleted sharp driver.  Thank you for the continued help.
> 
> Hmmm. I'd feel happier if you were to identify the 'something' which
> goes wrong. I was just about to remove the sharp driver from the tree on
> the basis that it's obsolete.
XXXXXXXX flash device: 800000 at fe000000
Search for id:(ff89 ffaa) interleave(2) type(2)
Search for id:(ff89 ffaa) interleave(2) type(2)
Search for id:(ff89 ffaa) interleave(2) type(2)
Search for id:(ff89 ffaa) interleave(2) type(2)
Search for id:(ff89 ffaa) interleave(2) type(2)
Search for id:(89 aa) interleave(2) type(1)
MTD jedec_match(): Check fit 0x00000000 + 0x00200000 = 0x00200000
MTD jedec_match(): check unlock addrs 0x0555 0x02aa
MTD jedec_match(): check ID's disappear when not in ID mode
MTD jedec_match(): return to ID mode
MTD jedec_probe_chip(): matched device 0x89,0xaa unlock_addrs: 0x0555
0x02aa
Found: Intel I28F016S3
Flash SIMM: Found 2 x8 devices at 0x0 in 32-bit mode
Probe at addr_unlock2(0x00400000 + 0xc0185aac) past the end of the
map(0x007fffff)
Using word write method
mtd: Giving out device 0 to Flash SIMM
Using XXXXXXXX partition definition
Creating 4 MTD partitions on "Flash SIMM":
0x00000000-0x00600000 : "JFFS"
mtd: partition "JFFS" extends beyond the end of device "Flash SIMM" --
size truncated to 0x400000
mtd: Giving out device 1 to JFFS
0x00600000-0x00700000 : "uImage"
mtd: partition "uImage" is out of reach -- disabled
mtd: Giving out device 2 to uImage
0x00700000-0x00740000 : "u-boot"
mtd: partition "u-boot" is out of reach -- disabled
mtd: Giving out device 3 to u-boot
0x00740000-0x00780000 : "u-boot env"
mtd: partition "u-boot env" is out of reach -- disabled
mtd: Giving out device 4 to u-boot env


> 
> Could it be as simple as disabling the erase suspend?

The Flash SIMM is 8M byte, but it is probed to be 4M only.

-- 
Li Yang <leoli@motorola.com>
Metrowerks

Re: jffs2+mtd+big endian problem

[David Woodhouse]

On Thu, 2004-02-05 at 17:02 +0800, Li Yang wrote:
> Search for id:(ff89 ffaa) interleave(2) type(2)
> Search for id:(ff89 ffaa) interleave(2) type(2)
> Search for id:(ff89 ffaa) interleave(2) type(2)
> Search for id:(ff89 ffaa) interleave(2) type(2)
> Search for id:(ff89 ffaa) interleave(2) type(2)
> Search for id:(89 aa) interleave(2) type(1)

The 'sharp.c' driver handles four 8-bit chips in parallel. Your probes
above aren't _looking_ for that. Did you enable the advanced CFI options
and then disable 4-way interleave? 

> MTD jedec_match(): Check fit 0x00000000 + 0x00200000 = 0x00200000
> MTD jedec_match(): check unlock addrs 0x0555 0x02aa
> MTD jedec_match(): check ID's disappear when not in ID mode
> MTD jedec_match(): return to ID mode
> MTD jedec_probe_chip(): matched device 0x89,0xaa unlock_addrs: 0x0555
> 0x02aa
> Found: Intel I28F016S3
> Flash SIMM: Found 2 x8 devices at 0x0 in 32-bit mode
> Probe at addr_unlock2(0x00400000 + 0xc0185aac) past the end of the
> map(0x007fffff)

That's odd too. What is that pointer doing in addr_unlock2? Possibly not
relevant though.

-- 
dwmw2

Re: jffs2+mtd+big endian problem

[Li Yang]

On Thu, 2004-02-05 at 17:27, David Woodhouse wrote:
> On Thu, 2004-02-05 at 17:02 +0800, Li Yang wrote:
> > Search for id:(ff89 ffaa) interleave(2) type(2)
> > Search for id:(ff89 ffaa) interleave(2) type(2)
> > Search for id:(ff89 ffaa) interleave(2) type(2)
> > Search for id:(ff89 ffaa) interleave(2) type(2)
> > Search for id:(ff89 ffaa) interleave(2) type(2)
> > Search for id:(89 aa) interleave(2) type(1)
> 
> The 'sharp.c' driver handles four 8-bit chips in parallel. Your probes
> above aren't _looking_ for that. Did you enable the advanced CFI options
> and then disable 4-way interleave? 
Oh, yes.  I enabled the advanced CFI options, but not the CFI geometry
selection.  Because I saw there is a BIG_ENDIAN_BYTE option under it,
maybe I was a little bit too nervous about the endian setting. =)  I
will try again without the advanced CFI options.
> 
> > MTD jedec_match(): Check fit 0x00000000 + 0x00200000 = 0x00200000
> > MTD jedec_match(): check unlock addrs 0x0555 0x02aa
> > MTD jedec_match(): check ID's disappear when not in ID mode
> > MTD jedec_match(): return to ID mode
> > MTD jedec_probe_chip(): matched device 0x89,0xaa unlock_addrs: 0x0555
> > 0x02aa
> > Found: Intel I28F016S3
> > Flash SIMM: Found 2 x8 devices at 0x0 in 32-bit mode
> > Probe at addr_unlock2(0x00400000 + 0xc0185aac) past the end of the
> > map(0x007fffff)
> 
> That's odd too. What is that pointer doing in addr_unlock2? Possibly not
> relevant though.
They are just baffling numbers to me.

-- 
Li Yang <leoli@motorola.com>
Metrowerks