Re: mtdpart.c

Re: mtdpart.c

[David Woodhouse]

bjorn.wesen@axis.com said:
>  I noticed that pnc2000.c uses add_mtd_partitions, but this is defined
> in mtdpart.c which is not in the Makefile.. is it safe to use this or
> should I conjure up partition code myself in my mapping ? 

Use mtdpart.c

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdpart.c

[David Woodhouse]

bjorn.wesen@axis.com said:
> Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard) 
> No supported Vendor Command Set found

CONFIG_MTD_CFI_AMDSTD

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

mtdpart.c

[Bjorn Wesen]

Hi! I'm adding a physical mapping for our flash partitioning. Basically
it's just that I read a partition-table at the start of the flash, and
then I want different devices created that correspond to the different
partitions. 

I noticed that pnc2000.c uses add_mtd_partitions, but this is defined in
mtdpart.c which is not in the Makefile.. is it safe to use this or should
I conjure up partition code myself in my mapping ?

Regards,
Bjorn




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdpart.c

[Bjorn Wesen]

On Fri, 12 Jan 2001, David Woodhouse wrote:
> > in mtdpart.c which is not in the Makefile.. is it safe to use this or
> > should I conjure up partition code myself in my mapping ? 
> 
> Use mtdpart.c

Ok great!

Axis flash mapping: 200000 at e0000000
Axis flash-image: Found a CFI device at 0x0 in 16 bit mode
Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
Primary Algorithm Table at 0040
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
No Vpp line
Typical byte/word write timeout: 16 µs
Maximum byte/word write timeout: 512 µs
Full buffer write not supported
Typical block erase timeout: 1024 µs
Maximum block erase timeout: 16384 µs
Chip erase not supported
Device size: 0x200000 bytes (2 Mb)
Flash Device Interface description: 0x0002
  - supports x8 and x16 via BYTE# with asynchronous interface
Max. bytes in buffer write: 0x1
Number of Erase Block Regions: 4
  Erase Region #0: BlockSize 0x4000 bytes, 1 blocks
  Erase Region #1: BlockSize 0x2000 bytes, 2 blocks
  Erase Region #2: BlockSize 0x8000 bytes, 1 blocks
  Erase Region #3: BlockSize 0x10000 bytes, 31 blocks

Invalid Extended Query Table at 0040: 02 00 F2
No supported Vendor Command Set found
cfi_probe erred 0


:(

Wonder where it blew up - maybe I should dump the latest mtd cvs (using
2.4.0 release now)

/BW




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdpart.c

[David Woodhouse]

bjorn.wesen@axis.com said:
>  It can be a hidden CONFIG option, like Config.in sets it
> automatically for those physmappings that require it, and then just
> remove the logic to do that in the Makefile - I can check that in if
> you want :) 

Yes please.


bjorn.wesen@axis.com said:
> Axis flash: Found 1 x16 CFI device at 0x0 in 16 bit mode Number of
> erase regions is zero

That shouldn't happen. Where did you put that check? Can you enable 
DEBUG_CFI? What does it print just after you read it from the flash
at line 545:
#ifdef DEBUG_CFI
        printk("Number of erase regions: %d\n", num_erase_regions);
#endif

Having that set to zero is OK for a CFI flash - it means you erase the 
whole device in one go. But that's not the case for your device, or indeed 
any device I've yet encountered, so it's not supported by the code yet.

I'll update my own tree for the board on my desk and check it's still
working for me since the changes to fix 16-bit devices in 8-bit mode were
merged. I have AMD chips in 1x16 arrangement too.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdpart.c

[David Woodhouse]

bjorn.wesen@axis.com said:
>  I did not put any check anywhere. It printed that out of its own free
> will :) I enabled CONFIG_MTD_DEBUG with CONFIG_MTD_DEBUG_LEVEL @ 3,
> but no other lines were printed (which is suspicious).  

Er... yeah, sorry, I did the grep before the cvs update. Now I see it, and 
curiously, I observe my kernel doing the same too. I'll go through the last 
few commitlog entries and look for someone to shout at.

In the meantime, cvs up -D "last friday"

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdpart.c

[David Woodhouse]

bjorn.wesen@axis.com said:
>  I also tried dropping the HEAD of mtd in the cvs over my 2.4.0 and
> reboot, but that made the problem worse:
>
> Axis flash mapping: 200000 at 50000000
> Axis flash: Found 1 x16 CFI device at 0x0 in 16 bit mode
> Number of erase regions is zero
> cfi_probe erred 0

The changes over the weekend to fix cfi_read_query() broke it. I've cleaned 
them all up and removed the extra argument from cfi_read_query, because 
it's pointless now it's not doing any scaling of its own.

It should work for all types of device now.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdpart.c

[Bjorn Wesen]

On Fri, 12 Jan 2001, David Woodhouse wrote:
> > Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard) 
> > No supported Vendor Command Set found
> 
> CONFIG_MTD_CFI_AMDSTD

I had that configured, it looked like it detected the chip and everything
and then bailed out at the end..

BTW I have a suggestion - how about making mtdpart.o depend on a
CONFIG_option instead of trying to guess when it's needed in the Makefile
? In our system, we have all our drivers in our arch-dir, setting CONFIG
flags to bring in other drivers in the rest of the kernel. But we cannot
bring in mtdpart.o for our physical mapping, not without hacking the mtd
Makefile and that should not be necessary of course :)

It can be a hidden CONFIG option, like Config.in sets it automatically for
those physmappings that require it, and then just remove the logic to do
that in the Makefile - I can check that in if you want :)

I also tried dropping the HEAD of mtd in the cvs over my 2.4.0 and reboot,
but that made the problem worse:

Axis flash mapping: 200000 at 50000000
Axis flash: Found 1 x16 CFI device at 0x0 in 16 bit mode
Number of erase regions is zero
cfi_probe erred 0

Now it does not even probe the flash apart from the initial CFI find :)

/BW



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdpart.c

[Bjorn Wesen]

On Mon, 15 Jan 2001, David Woodhouse wrote:
> > Axis flash: Found 1 x16 CFI device at 0x0 in 16 bit mode Number of
> > erase regions is zero
> 
> That shouldn't happen. Where did you put that check? Can you enable 
> DEBUG_CFI? What does it print just after you read it from the flash
> at line 545:
> #ifdef DEBUG_CFI
>         printk("Number of erase regions: %d\n", num_erase_regions);
> #endif

I did not put any check anywhere. It printed that out of its own free will
:) I enabled CONFIG_MTD_DEBUG with CONFIG_MTD_DEBUG_LEVEL @ 3, but no
other lines were printed (which is suspicious). 

> I'll update my own tree for the board on my desk and check it's still
> working for me since the changes to fix 16-bit devices in 8-bit mode were
> merged. I have AMD chips in 1x16 arrangement too.

Great.. something must have burped because in the 2.4.0-kernel version, it
at least found the chip even though cfi_probe failed.

-BW



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdpart.c

[David Woodhouse]

bjorn.wesen@axis.com said:
>  Now on to seeing if JFFS works on it :)

Wheee. I'd recommend the linux-2_4-branch version of fs/jffs

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdpart.c

[Bjorn Wesen]

On Mon, 15 Jan 2001, David Woodhouse wrote:
> The changes over the weekend to fix cfi_read_query() broke it. I've cleaned 
> them all up and removed the extra argument from cfi_read_query, because 
> it's pointless now it's not doing any scaling of its own.
> 
> It should work for all types of device now.

Yup! Thanks.

Axis flash mapping: 200000 at 50000000
Axis flash: Found 1 x16 CFI device at 0x0 in 16 bit mode
 Amd/Fujitsu Extended Query Table v1.0 at 0x0040
number of CFI chips: 1
 Using default partition table
mtd: Giving out device 0 to boot firmware
mtd: Giving out device 1 to kernel
mtd: Giving out device 2 to filesystem

Now on to seeing if JFFS works on it :)

/BW




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

mtdpart.c

[Nikhil]

hi all,

I had a trivial doubt about the functioning of mtdpart.c.

First of all if we create the mtd partitions from the comandline (using
mtdpart=...) how can we check whether the partitions heve been created? 

I am using block2mtd for mounting JFFS2 on compact flash. whether i need
to create different partitions using fdisk and then emulate each using
block2mtd or i should use mtdpart for making partitions on a single mtd
block created using block2mtd.

which one is the better option?

-- 
Thanks & Regards

Nikhil Shirodkar
Project Engineer
NISG, CDAC