Am29LV065D woes???

Am29LV065D woes???

[Luke]

Hello all,

I have just read through the MTD HOWTO and am trying
to figure out what everything means.  I am new to
flash and at work I was given a project to figure out
how to use flash in an embedded linux system.  The
system uses a Cyrix 486dx4 as the processor and has 4
banks of 8M of SDRAM (so 32 M total) and a Am29LV065D
flash chip.

The data sheet for this flash chip says it is CFI
compliant which sounds good as the main example in the
HOWTO is a CFI example.  Some other things that may be
relevant from the data sheet (like I said I am NEW to
this stuff):

Am29LV065D:
    - 64 Megabit (8M x 8-bit)
    - uniform sector flash memory
    - 128 64 Kbyte sectors
    - 8,388,608 = 0x800000 bytes total
    - data appears on DQ0 - DQ7

I built a kernel with the relevant pieces (nothing as
a module) and when I burn the kernel/initrd/linux
loader onto the flash (through a dongle connected on
the parallel cable and some flash burning utility that
amd has made) 

When I reboot I get a working linux system, mostly.  I
get the message about no CFI flash chip found.  I am
assumng that for one that I have entered the wrong
values when I was compiling the kernel.  When setting
the physical address mapping in the mtd section of the
kernel - what should the values be for this chip?  I
assume from the above info that the bus width is 8 bit
and the size is 0x800000 - but I am unsure what to put
down for an address to start.  Do I want this to point
to someplace on the chip not already used by the
kernel, initrd, linux loader, and the bios (which is
sitting in the last 256k region on the flash).

I want to be able to eventually mount the free space
on the flash and use it as I would use any other
mounted device.


Any help and suggestions would GREATLY be
appreciated!!!

Thanks,
Luke
 




__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Re: Am29LV065D woes???

[Vipin Malik]

>When setting
>the physical address mapping in the mtd section of the
>kernel - what should the values be for this chip?  I
>assume from the above info that the bus width is 8 bit
>and the size is 0x800000 - but I am unsure what to put
>down for an address to start.

That's entirely dependent on your hardware- as to which address range it 
decodes the chip select (CS) line going to the flash chip.

Look in the schematic of your hardware- see where the chip select line on 
the flash chip is connected to. If it's connected to a PAL or FPGA on your 
board, then get hold of the spec of the chip select decoding logic and see 
where in the memory space that cs is decoded.

If it is going to your (embedded PC on a chip) processor (if that's the 
case- like in an AMD SC520 or Intel 386EX) then either look in the bios 
settings where the PAR (programmable address range) chip select registers 
are being set or you may have to program them yourself- say in the 
physmap.c file before you do the probe for the flash chip.

The sc520cdp.c is a good example for this case.

Best of Luck

Vipin

Re: Am29LV065D woes -- ZFMicro MachZ help?

[Luke]

I appreciate the help so far - I have been trying to read what I can about
my system.

--- Vipin Malik <vipin@embeddedlinuxworks.com> wrote:
> 
> That's entirely dependent on your hardware- as to which address range it
> decodes the chip select (CS) line going to the flash chip.
...
> If it is going to your (embedded PC on a chip) processor (if that's the 
> case- like in an AMD SC520 or Intel 386EX) then either look in the bios 
> settings where the PAR (programmable address range) chip select
> registers are being set or you may have to program them yourself- say in
> the physmap.c file before you do the probe for the flash chip.

The flash is going directly to the processor.  In this case it is a
ZFMicro MachZ chip (Cyrix 486 dx4) - the documentation on the physical
address space is very confusing to me.  Has anyone tried using MTD for
this chip?

In the bios, one can configure mem_cs_0 (0-3 actually) memory page size,
memory base, and memory offset.  I have 2 Am29LV065D 8M flash chips - one
linked to mem_cs_0 and the other to mem_cs_1.  The confusing part comes
with the Rom Extension Linux Loader that comes with the platform.  Looking
at the assemby for this loader it seems as though it uses the default
settings set in bios for mem_cs_0 and then the loader changes these values
to address an initrd, and kernel address space.  

I am still a little bewildered on how to configure MTD - I am plugging
along reading lots of code.  If anyone has any more suggestions it would
be great!  What kinds of things should I look for in the MachZ
documentation that might help me configure MTD?

Thanks a lot,
Luke 

ps.  Is the prefered setup to have an initrd (with the root fs) or to have
a root jffs2 on a mtd device?  Is this always possible?  


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Re: Am29LV065D woes -- ZFMicro MachZ help?

[Vipin Malik]

At 05:35 PM 8/13/2001 -0700, Luke wrote:
>The flash is going directly to the processor.

Well in that case, you have on board programmable chip select's.
There must be registers that are associated with each chip select that define
the base physical address, the databus width, the wait states, what type of 
memory
is located there (read only or read/write) etc.

You must look for these registers and program them to an address that you 
will be happy with.
Of course if the flash chips are already booting your bios etc. you 
probably want to dump the contents
and decode what the base address is and just use that.

This is exactly like the AMD SC520 processor, except I doubt that the 
registers to program the
chip selects are in the same location :)


>ps.  Is the prefered setup to have an initrd (with the root fs) or to have
>a root jffs2 on a mtd device?  Is this always possible?

Really your call. You can do both. The initrd will get you a pristine root 
fs each time.
The root JFFS2 is more "direct" that you can make permanent changes to the 
root fs
just by writing to the root fs.

Re: Am29LV065D woes -- ZFMicro MachZ help?

[Changwoo Ryu]

Luke <luke_epsilon@yahoo.com> writes:

> I appreciate the help so far - I have been trying to read what I can about
> my system.
> 
> --- Vipin Malik <vipin@embeddedlinuxworks.com> wrote:
> > 
> > That's entirely dependent on your hardware- as to which address range it
> > decodes the chip select (CS) line going to the flash chip.
> ...
> > If it is going to your (embedded PC on a chip) processor (if that's the 
> > case- like in an AMD SC520 or Intel 386EX) then either look in the bios 
> > settings where the PAR (programmable address range) chip select
> > registers are being set or you may have to program them yourself- say in
> > the physmap.c file before you do the probe for the flash chip.
> 
> The flash is going directly to the processor.  In this case it is a
> ZFMicro MachZ chip (Cyrix 486 dx4) - the documentation on the physical
> address space is very confusing to me.  Has anyone tried using MTD for
> this chip?
> 
> In the bios, one can configure mem_cs_0 (0-3 actually) memory page size,
> memory base, and memory offset.  I have 2 Am29LV065D 8M flash chips - one
> linked to mem_cs_0 and the other to mem_cs_1.  The confusing part comes
> with the Rom Extension Linux Loader that comes with the platform.  Looking
> at the assemby for this loader it seems as though it uses the default
> settings set in bios for mem_cs_0 and then the loader changes these values
> to address an initrd, and kernel address space.  

You don't need the register values (set by the linux loader) after
linux/initrd loading.  Then the regsiter values should be changed
before probing the flash.

You can read the H/W manual "ZF-Logic" section about setting the
values.

-- 
Changwoo Ryu

Re: Am29LV065D woes -- ZFMicro MachZ help?

[Luke]

Howdy,

I am excited to get to work tomorrow and pour over the ZFMicro tech docs -
man that sounds sad.

--- Vipin Malik <vipin@embeddedlinuxworks.com> wrote:
> At 05:35 PM 8/13/2001 -0700, Luke wrote:

> Well in that case, you have on board programmable chip select's.
> There must be registers that are associated with each chip select that
> define the base physical address, the databus width, the wait
states,what type of memory is located there (read only or read/write) etc.

You think these registers are located on the ZFMicro chip somewhere,
right?  If I am understanding you correctly, I need to duplicate the
action that the bios does when setting the chip select registers.  

> You must look for these registers and program them to an address that
> you will be happy with. Of course if the flash chips are already booting
> your bios etc. you probably want to dump the contents and decode what
the base address is and just use that.

How would I go about dumping this?  

The bios seems to launch what it calls an Option Rom Extension (A Phoenix
Bios feature - maybe others too) - and the extension it launches is called
the Linux Loader Option Rom Extension.   It is this program that (I
believe) programs the chip selects to get the system booting.  When the
bios first starts it has values in the chip select (mem_cs_0) which allows
this linux loader option rom to load.

> This is exactly like the AMD SC520 processor, except I doubt that the 
> registers to program the chip selects are in the same location :)

I will look more closely at the sc520cdp.c code and hopefully I can just
tweak the appropriate addresses.  So if I create a file zfmicro.c (with
the sc520cdp.c code as a rough template) where do I put this file when
compiling the kernel?  I am new to this kind of thing too (that is messing
with kernel driver source code).

Thanks again!  I am having fun learning how this stuff works! (slowly)

Later,
Luke

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

ZFMicro MachZ success with the Am29LV065D

[Luke]

Hello all,

I appreciate the help and encouragement by those on the list that have been pointing me in the
right direction.  Tonight I had some successes with the MachZ (ZFMicro's Cyrix 486dx4 embedded
chip) and understanding how it deals with memory devices.  

>From some ZF documentation that someone was kind enough to send me:

"The ZFL allows the MachZ to control up to four external memory devices on the ISA bus.  These
devices can be mapped into the system memory address space.  Typically, this feature is used to
map external Flash memory into the address space without external address decoding logic
necessary. 

These devices are connected externally to the ISA BUS address, data and memr/memw signals.  Each
device has a dedicated mem_cs signal generated by ZFL.  Each device can occupy up to 16 Mbytes
(occupying all 24 address lines).  The minimum window size is 8Kbyte"

I was successful getting the MTD driver to find 1 of 2 of the AM29LV065D flash chips by just
setting the ZFL MemWindow0 base address register to 0 the MemWindow0 window size to 8Mbytes and
the MemWindow0 page address register to 0.  This was conveniently done in the bios linux loader
(ZFMicro has an Option Rom Linux Loader written in assembly that comes with their chip)- right
before it does a far jump to the kernel setup code.  In the kernel I just set (in make xconfig)
the physical address to 256Mbytes and the size to 8Mbytes and it worked!  I guess?? I could have
set the MemWindow0 base address register to 256M and it would be the same (since because of the
ISA-PCI address mapping, the same memory window will roll over every 16MBytes on the entire 4GByte
PCI memory space).  I chose 256Mbytes since that is the maximum size of SDRAM accessible to the
MachZ chip.

As I have it right now, linux loads and I see:

physmap flash device: 800000 at 10000000
Physically mapped flash: Found 1 x8 devices at 0x0 in 8-bit mode
 Amd/Fujitsu Extended Query Table v1.1 at 0x0040
number of CFI chips: 1
mtd: Giving out device 0 to Physically mapped flash

and if I cat /proc/mtd I see

dev:      size        erasesize          name
mtd0    00800000      00010000        "physically mapped flash"


I tried a few different things and haven't got the second chip recognized yet.  I tried setting
the size (in the make xconfig dialog) to 16M and setting the MemWindow1 base address register to
8Mbytes (with MemWindow1 page register 0 and size 8Mbytes) - but that didn't work.  Do I need to
do something else to get MTD to work with multiple flash devices?

I know this is long and drawn out and that I may be rambling from my sleepiness - I do appreciate
the help I have been given.  I did have a JFFS2 question or two also.

I want to mount these 2 flash devices (well all of one and half of the other since the other half
is filled with the kernel and initrd, this seems like it should be straightforward by messing with
the MemWin0 size register and page register to point to the right portion of the first flash
device).

I don't have any image - I just want these 2 flash chips to be initially empty file systems where
I can write data that is collected from some atmospheric sensors hooked up to the embedded system.
 Do I need mkfs.jffs on the embedded system or can I use it on my development system and then
transfer it over?  I am a little confused by this in the HOWTO. Do I need to have the erase
utility on the embedded system and erase the /dev/mtd0 device and then just mount it?  Any further
examples or words to this effect would be good to see.

Thanks again,
Luke

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: ZFMicro MachZ success with the Am29LV065D

[Vipin Malik]

At 11:08 PM 8/22/2001 -0700, Luke wrote:

>As I have it right now, linux loads and I see:
>
>physmap flash device: 800000 at 10000000
>Physically mapped flash: Found 1 x8 devices at 0x0 in 8-bit mode
>  Amd/Fujitsu Extended Query Table v1.1 at 0x0040
>number of CFI chips: 1
>mtd: Giving out device 0 to Physically mapped flash
>
>and if I cat /proc/mtd I see
>
>dev:      size        erasesize          name
>mtd0    00800000      00010000        "physically mapped flash"
>
>
>I tried a few different things and haven't got the second chip recognized 
>yet.  I tried setting
>the size (in the make xconfig dialog) to 16M and setting the MemWindow1 
>base address register to
>8Mbytes (with MemWindow1 page register 0 and size 8Mbytes) - but that 
>didn't work.  Do I need to
>do something else to get MTD to work with multiple flash devices?

What "map" driver are you using. If it's the generic "physmap" one 
(physmap.c), then you need to loop in
the detection code in the driver for each physical chip on your board 
(actually each physical chip on your board
that is to be mapped as a separate MTD device- so if you have two physical 
8bit chips on a 16bit bus (interleave of 2), you don't need to loop).

See the sc520cdp.c file as an example.


>I know this is long and drawn out and that I may be rambling from my 
>sleepiness - I do appreciate
>the help I have been given.  I did have a JFFS2 question or two also.
>
>I want to mount these 2 flash devices (well all of one and half of the 
>other since the other half
>is filled with the kernel and initrd, this seems like it should be 
>straightforward by messing with
>the MemWin0 size register and page register to point to the right portion 
>of the first flash
>device).
>
>I don't have any image - I just want these 2 flash chips to be initially 
>empty file systems where
>I can write data that is collected from some atmospheric sensors hooked up 
>to the embedded system.
>  Do I need mkfs.jffs on the embedded system or can I use it on my 
> development system and then
>transfer it over?

You don't need mkfs.jffs on your end system. This guy is only used i you 
want to go the mkiso fs route- i.e.
build a binary image off line then burn it in the mtd device (think of 
mkfs.jffs2 -> mkisofs and copying to the mtd device as cdrecord).

I personally never use this program- as JFFS2 also supports populating the 
fs "by hand"- i.e. make sure that the mtd device is completely erased (the 
first time), then mount the JFFS2 fs. This will result in a blank JFFS2 fs. 
Then just copy the files over that you need.
To make further copies (for e.g. in production), just "dd" the entire mtd 
image out to a file. You can then use this file as a binary image to 
initialize other systems.

Vipin

P.S. Once you have successfully detected your flash as an mtd device, could 
you please make an entry into my mtd flash device database at:
http://www.embeddedlinuxworks.com/db.html

Re: ZFMicro MachZ success with the Am29LV065D

[Luke]

Howdy,

I am trying to mount part of the flash0 device right now as I don't want to mount the portion that
has my bios or initrd or kernel - this "looks" straightforward for the ZFMicro but I am getting
some interesting errors.  I will work on messing with the second physical flash device later.

in the ZFL registers space I set
    MemWindow0 window size to 500000h (I want a 5 Mbyte section mounted)
    MemWindow0 page address to 1c0000h (the initrd and kernel are below this)
    MemWindow0 base address to 10000000h (this will be mapped at 256Mbyte in the
                                          physical memory space - above any SDRAM
                                          conflicts)

As I have it right now, linux loads and I see:

physmap flash device: 500000 at 10000000
Physically mapped flash: Found 1 x8 devices at 0x0 in 8-bit mode
 Amd/Fujitsu Extended Query Table v1.1 at 0x0040
number of CFI chips: 1
mtd: Giving out device 0 to Physically mapped flash

and if I cat /proc/mtd I see
dev:      size        erasesize          name
mtd0    00800000      00010000        "physically mapped flash"

should this size still be 8 Mbytes?  That is the physical size of the flash but I should be
mapping only part of the flash.

When I try to mount mtdblock0 I get the following (I made a directory /mnt/mtd before the next
line):

# mount -t jffs2 /dev/mtdblock0 /mnt/mtd
mtdblock_open
ok           
JFFS2: Erase block at 0x00000000 is not formatted. It will be erased
JFFS2: Erase block at 0x00010000 is not formatted. It will be erased
JFFS2: Erase block at 0x00020000 is not formatted. It will be erased
...
(this continues erasing 64k chunks at a time until)
...
JFFS2: Erase block at 0x004c0000 is not formatted. It will be erased
JFFS2: Erase block at 0x004d0000 is not formatted. It will be erased
JFFS2: Erase block at 0x004e0000 is not formatted. It will be erased
JFFS2: Erase block at 0x004f0000 is not formatted. It will be erased
Unable to handle kernel paging request at virtual address c2d00000  
 printing eip:                                                    
c018eacd      
*pde = 01f93067
*pte = 00000000
Oops: 0000     
CPU:    0 
EIP:    0010:[<c018eacd>]
EFLAGS: 00010216         
eax: c2d00000   ebx: 0000000c   ecx: 00000003   edx: c1bafe30
esi: c2d00000   edi: c1bafe30   ebp: 0000000c   esp: c1bafd80
ds: 0018   es: 0018   ss: 0018                               
Process mount (pid: 16, stackpage=c1baf000)
Stack: c10988d8 c1bafde4 c1bafdf4 c018bcec c01c6600 c1bafe30 00500000 0000000c 
       00500000 00000000 00000000 c10988a0 c01c6600 c01a2581 c01e2670 c01e2a3f 
       00500000 00000000 00000010 ffffffff 00000005 00000000 c1bae000 00000000 
Call Trace: [<c018bcec>] [<c01a2581>] [<c015c2aa>] [<c015bffd>] [<c015e7ad>]   
   [<c015b4d7>] [<c012f6d3>] [<c013008f>] [<c01301a3>] [<c013042b>] [<c01246eb>]
 
   [<c013028f>] [<c01304cc>] [<c0106f83>] 
     
Code: f3 a5 f6 c3 02 74 02 66 a5 f6 c3 01 74 01 a4 5b 5e 5f c3 53 
 <0>Kernel panic: Aiee, killing interrupt handler!                
In interrupt handler - not syncing                

----
any ideas on what to try?  I am using the standard "physmap" driver and the mtd stuff in kernel
2.4.8-ac7.

Thanks,
Luke

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: ZFMicro MachZ success with the Am29LV065D

[Vipin Malik]

At 07:54 AM 8/23/2001 -0700, Luke wrote:
>Howdy,
>
>I am trying to mount part of the flash0 device right now as I don't want 
>to mount the portion that
>has my bios or initrd or kernel - this "looks" straightforward for the 
>ZFMicro but I am getting
>some interesting errors.  I will work on messing with the second physical 
>flash device later.
>
>in the ZFL registers space I set
>     MemWindow0 window size to 500000h (I want a 5 Mbyte section mounted)
>     MemWindow0 page address to 1c0000h (the initrd and kernel are below this)
>     MemWindow0 base address to 10000000h (this will be mapped at 256Mbyte 
> in the
>                                           physical memory space - above 
> any SDRAM
>                                           conflicts)

Normally, one map's the entire flash as far as the chip select's are 
concerned, and set's the start/length logically in the map driver (in your 
case physmap.c).
Of course you don't want to start/stop in the middle of a sector. Only on 
sector boundaries please :)

Not quite sure if this is causing your JFFS2 panic, but it's worth trying 
out. If this is not it, then you have to run the oops messages through 
ksymoops and provide a trace as to where in the src the panic is taking place.

Vipin


>As I have it right now, linux loads and I see:
>
>physmap flash device: 500000 at 10000000
>Physically mapped flash: Found 1 x8 devices at 0x0 in 8-bit mode
>  Amd/Fujitsu Extended Query Table v1.1 at 0x0040
>number of CFI chips: 1
>mtd: Giving out device 0 to Physically mapped flash
>
>and if I cat /proc/mtd I see
>dev:      size        erasesize          name
>mtd0    00800000      00010000        "physically mapped flash"
>
>should this size still be 8 Mbytes?  That is the physical size of the 
>flash but I should be
>mapping only part of the flash.
>
>When I try to mount mtdblock0 I get the following (I made a directory 
>/mnt/mtd before the next
>line):
>
># mount -t jffs2 /dev/mtdblock0 /mnt/mtd
>mtdblock_open
>ok
>JFFS2: Erase block at 0x00000000 is not formatted. It will be erased
>JFFS2: Erase block at 0x00010000 is not formatted. It will be erased
>JFFS2: Erase block at 0x00020000 is not formatted. It will be erased
>...
>(this continues erasing 64k chunks at a time until)
>...
>JFFS2: Erase block at 0x004c0000 is not formatted. It will be erased
>JFFS2: Erase block at 0x004d0000 is not formatted. It will be erased
>JFFS2: Erase block at 0x004e0000 is not formatted. It will be erased
>JFFS2: Erase block at 0x004f0000 is not formatted. It will be erased
>Unable to handle kernel paging request at virtual address c2d00000
>  printing eip:
>c018eacd
>*pde = 01f93067
>*pte = 00000000
>Oops: 0000
>CPU:    0
>EIP:    0010:[<c018eacd>]
>EFLAGS: 00010216
>eax: c2d00000   ebx: 0000000c   ecx: 00000003   edx: c1bafe30
>esi: c2d00000   edi: c1bafe30   ebp: 0000000c   esp: c1bafd80
>ds: 0018   es: 0018   ss: 0018
>Process mount (pid: 16, stackpage=c1baf000)
>Stack: c10988d8 c1bafde4 c1bafdf4 c018bcec c01c6600 c1bafe30 00500000 
>0000000c
>        00500000 00000000 00000000 c10988a0 c01c6600 c01a2581 c01e2670 
> c01e2a3f
>        00500000 00000000 00000010 ffffffff 00000005 00000000 c1bae000 
> 00000000
>Call Trace: [<c018bcec>] [<c01a2581>] [<c015c2aa>] [<c015bffd>] 
>[<c015e7ad>]
>    [<c015b4d7>] [<c012f6d3>] [<c013008f>] [<c01301a3>] [<c013042b>] 
> [<c01246eb>]
>
>    [<c013028f>] [<c01304cc>] [<c0106f83>]
>
>Code: f3 a5 f6 c3 02 74 02 66 a5 f6 c3 01 74 01 a4 5b 5e 5f c3 53
>  <0>Kernel panic: Aiee, killing interrupt handler!
>In interrupt handler - not syncing
>
>----
>any ideas on what to try?  I am using the standard "physmap" driver and 
>the mtd stuff in kernel
>2.4.8-ac7.
>
>Thanks,
>Luke
>
>__________________________________________________
>Do You Yahoo!?
>Make international calls for as low as $.04/minute with Yahoo! Messenger
>http://phonecard.yahoo.com/

ZFMicro MachZ modification of physmap.c

[Luke]

Hello,

--- Vipin Malik <vipin@embeddedlinuxworks.com> wrote:
> 
> Normally, one map's the entire flash as far as the chip select's are 
> concerned, and set's the start/length logically in the map driver (in your 
> case physmap.c).
> Of course you don't want to start/stop in the middle of a sector. Only on 
> sector boundaries please :)
> 

It seems that the standard physmap.c just takes the 3 CONFIG_* inputs of start (of the physical
memory address to look for the flash),length, and bus width.  To change the offset of the flash to
access do you modify the return from ioremap() ?

For example, if I have an 8 Mbyte flash chip that I want to access with MTD and I only want to map
from byte offset 0x300000 to 0x700000 of the flash I should set my CONFIG_MTD_PHYSMAP_LEN to 4
Mbytes and inside the physmap.c code add an offset of 0x300000 to something?

Sorry for being a slow learner on this one,
Luke


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: ZFMicro MachZ modification of physmap.c

[Vipin Malik]

At 12:41 PM 8/23/2001 -0700, Luke wrote:
>Hello,
>
>--- Vipin Malik <vipin@embeddedlinuxworks.com> wrote:
> >
> > Normally, one map's the entire flash as far as the chip select's are
> > concerned, and set's the start/length logically in the map driver (in your
> > case physmap.c).
> > Of course you don't want to start/stop in the middle of a sector. Only on
> > sector boundaries please :)
> >
>
>It seems that the standard physmap.c just takes the 3 CONFIG_* inputs of 
>start (of the physical
>memory address to look for the flash),length, and bus width.  To change 
>the offset of the flash to
>access do you modify the return from ioremap() ?

no, you don't mess with the return value from ioremap. That's what the 
kernel is telling you it's mapped your requested physical memory to 
(logical memory).


>For example, if I have an 8 Mbyte flash chip that I want to access with 
>MTD and I only want to map
>from byte offset 0x300000 to 0x700000 of the flash I should set my 
>CONFIG_MTD_PHYSMAP_LEN to 4
>Mbytes and inside the physmap.c code add an offset of 0x300000 to something?

I really haven't mapped partial chips myself, so you'll have to play around 
with what I am suggesting (unless some one else that has done this chimes in :)

I would look at the partition code (that partition's the flash in multiple 
mtd devices). Essentially you need to do the same. At the very least, you 
should be able to define a partition for the section that you don't want to 
use and not mount anything on that.

There's plenty of examples in some of the other physical map drivers that 
have examples of multiple mtd partitions on the same flash chip.

Vipin