Re: Using mtdparts= right?

[Bill Gatliff <bgat@billgatliff.com>]

Guys:


Got it, at least partway...

I'm running an Intel E28F640J3, and for reasons I haven't tracked down 
yet the chip ends up in READ STATUS mode by the time my map driver's 
copy_from() is called.  For the short term, I'm breakpointing there and 
forcing the chip back into READ ARRAY mode by doing this:

(gdb) set *(long*)<flash-address-from-ioremap> 0xff00ff

[I'll track down a better solution shortly]

I now also know that the reason the @offset field in my mtdparts command 
line isn't working is because although the command line is getting 
parsed correctly, do_cached_read() (or somebody underneath) isn't 
applying that offset to the addresses sent to the read/write functions 
in the map driver.  As a workaround, I modified the read/write functions 
in my map driver to look something like this:

void csb337_copy_from(struct map_info *map, void *to, unsigned long 
from, ssize_t len)
{
#if 1
  /* TODO: assume we have only one partition and offset, since I can't
     see where else to apply this offset.  b.g. 1/17/2004 */
  if (mtd_parts)
    memcpy_fromio(to, map->map_priv_1 + from + mtd_parts->offset, len);
  else
#endif
    memcpy_fromio(to, map->map_priv_1 + from , len);
}


I'm somewhat confused about where to apply this fix correctly, although 
the above code appears to work (as long as there is only one 
partition!).  MTD_READ has the mtd_info structure, but I don't see where 
it does anything involving partitions, so I don't know how to figure out 
which partition offset (if there are multiple partitions) should be 
added to the address that eventually gets handed to the map driver.

Doing it in the map driver doesn't seem right, either, because to do it 
right I'd have to do a kind of reverse-lookup in the partition and map 
structures to figure out which partition the provided address applies 
to, so I can figure out which partition offset to apply.

Of course, it could also be that I'm totally misunderstanding the 
purpose behind @offset...

I'd love to hear more from someone who actually knows how this stuff is 
intended to work.  :^)


Thanks!


b.g.



Bill Gatliff wrote:

> Guys:
>
>
> I need a quick sanity check here.  I'm giving this to my arm-linux 
> 2.4.21-rmk1 kernel (and the MTD code it contains, I'm not running from 
> CVS sources):
>
> root=/dev/mtdblock0 mtdparts=csb337-nor:1536000@0x8d43c(root)ro ...
>
> I've added a maping for "csb337-nor", which starts at the first 
> physical address of flash and contains the whole flash.  My romfs root 
> image starts at an offset of 0x8d43c from the beginning of that flash.
>
> I get this during boot:
>
> ...
> CSB337-NOR: 0x00800000 at 0x10000000
> cfi_cmdset_0001: Erase suspend on write enabled
> Using buffer write method
> mtd: Giving out device 0 to NOR flash on CSB337
> CSB337-NOR: using command line partition definition
> Creating 1 MTD partitions on "NOR flash on CSB337":
> 0x0008d43c-0x0020443c : "root"
> mtd: Giving out device 1 to root
> ...
>
> Then I get this:
>
> ...
> NetWinder Floating Point Emulator V0.97 (double precision)
> mtdblock_open
> ok
> mtdblock: read on "NOR flash on CSB337" at 0x0, size 0x400
> mtdblock_release
> ok
> Kernel panic: VFS: Unable to mount root fs on 1f:00
>
>
> I have romfs turned on, and I've stepped through a lot of code in the 
> kernel during boot.  What I've noticed is that get_sb_bdev() is 
> returning EBUSY.  I also don't understand why MTD is reading 0x400 
> bytes from the start of flash, when it should be getting the 
> superblock from 0x8d43c.
>
> Ideas?  I'm on my way to step through get_sb_bdev() now...
>
>
> Thanks!
>
>
> b.g.
>

-- 
Bill Gatliff
Embedded GNU development and training services.
bgat@billgatliff.com