cmdlineparts and chip initialization order

cmdlineparts and chip initialization order

[Marc Singer]

With a command line like this:

  console=ttyAM0 root=/dev/hda1 mtdparts=norflash:2m(boot),-(root);nandflash:32k(apex)ro,-(root)

I am able to initialization partitions for the NOR flash, but not the
NAND flash.  It look like the problem is that the NOR flash driver is
initializing before the mtdparts command line parsed, but the NAND
flash isn't.

All code is linked into the kernel--no modules.

Moving the cmdlinepart.o file to the end of the list appears to
prevent the command line from being parsed.

Is this a recognized problem with a known solution.

BTW, it looks like none of the other NAND drivers expect a command
line partition setup.  Has anyone else tried?

Cheers.

Re: cmdlineparts and chip initialization order

[Thomas Gleixner]

On Thu, 2004-11-11 at 14:01 -0800, Marc Singer wrote:
> With a command line like this:
>   console=ttyAM0 root=/dev/hda1 mtdparts=norflash:2m(boot),-(root);nandflash:32k(apex)ro,-(root)
> I am able to initialization partitions for the NOR flash, but not the
> NAND flash.  It look like the problem is that the NOR flash driver is
> initializing before the mtdparts command line parsed, but the NAND
> flash isn't.
> Moving the cmdlinepart.o file to the end of the list appears to
> prevent the command line from being parsed.

The commandline parition code must be registered as a partition parser
before any mapping driver is initialized. So it's not surprising that it
does not work when it is linked in last, as the init functions are
called in link order 

> BTW, it looks like none of the other NAND drivers expect a command
> line partition setup.  Has anyone else tried?

It has nothing to do with NOR or NAND. The driver calls a parition
parser.

Provide more detailed information, please. Switch on MTD debugging and
add some MTD_DEBUG in the relevant places.

tglx

Re: cmdlineparts and chip initialization order

[Aras Vaichas]

Marc Singer wrote:
> With a command line like this:
> 
>   console=ttyAM0 root=/dev/hda1 mtdparts=norflash:2m(boot),-(root);nandflash:32k(apex)ro,-(root)
> 
> I am able to initialization partitions for the NOR flash, but not the
> NAND flash.  It look like the problem is that the NOR flash driver is
> initializing before the mtdparts command line parsed, but the NAND
> flash isn't.
 > <SNIP>
> BTW, it looks like none of the other NAND drivers expect a command
> line partition setup.  Has anyone else tried?

I recently had to do this and had the same problem. I took a look at the low 
level driver code for my particular processor and noted that not all MTD 
drivers had partition parsing code.

e.g  in at91_dataflash.c there is parser related code:

int parse_cmdline_partitions(struct mtd_info *master,
                 struct mtd_partition **pparts, const char *mtd_id);
and ...

#ifdef CONFIG_MTD_CMDLINE_PARTS
         char mtdID[14];
#endif

and ...

#ifdef CONFIG_MTD_CMDLINE_PARTS
         sprintf(mtdID, "dataflash%i", nr_devices-1);
         mtd_parts_nr = parse_cmdline_partitions(device, &mtd_parts, mtdID);
#endif

This parsing code is missing from at91_nand.c, and that's why I wasn't able to 
setup my NAND partitions from the command line (previous posting).


regards,

Aras

Re: cmdlineparts and chip initialization order

[Marc Singer]

On Thu, Nov 11, 2004 at 11:51:13PM +0100, Thomas Gleixner wrote:
> Provide more detailed information, please. Switch on MTD debugging and
> add some MTD_DEBUG in the relevant places.

In this dmesg dump, you can see that the CMDLINE-PART stuff occurs
before the NAND driver is initialized and after the NOR driver.  I am
assuming that this is the reason that the nand driver doesn't receive
partitions.  Is this not the case?


lpd79524 flash device: 1000000 at 44000000
lpd79524_norflash: Found 1 x16 devices at 0x0 in 16-bit bank
lpd79524_norflash: Found 1 x16 devices at 0x800000 in 16-bit bank
 Intel/Sharp Extended Query Table at 0x0031
cfi_cmdset_0001: Erase suspend on write enabled
Using buffer write method
DEBUG-CMDLINE-PART: parse_cmdline_partitions top
DEBUG-CMDLINE-PART: parsing <2m(boot),-(root);lpd79524_nandflash:32k(apex)ro,-(>
DEBUG-CMDLINE-PART: partition 1: name <root>, offset 0, size ffffffff, mask fla0
DEBUG-CMDLINE-PART: partition 0: name <boot>, offset 0, size 200000, mask flags0
DEBUG-CMDLINE-PART: mtdid=<lpd79524_norflash> num_parts=<2>
DEBUG-CMDLINE-PART: parsing <32k(apex)ro,-(root)>
DEBUG-CMDLINE-PART: partition 1: name <root>, offset 0, size ffffffff, mask fla0
DEBUG-CMDLINE-PART: partition 0: name <apex>, offset 0, size 8000, mask flags 3
DEBUG-CMDLINE-PART: mtdid=<lpd79524_nandflash> num_parts=<2>
2 cmdlinepart partitions found on MTD device lpd79524_norflash
Creating 2 MTD partitions on "lpd79524_norflash":
0x00000000-0x00200000 : "boot"
mtd: Giving out device 0 to boot
0x00200000-0x01000000 : "root"
mtd: Giving out device 1 to root
NAND device: Manufacturer ID: 0x98, Chip ID: 0x75 (Toshiba NAND 32MiB 3,3V 8-bi)
Scanning device for bad blocks
mtd: Giving out device 2 to lpd79524_nandflash

Re: cmdlineparts and chip initialization order

[Marc Singer]

I now understand why the partitions weren't being parsed.  I didn't
realize that the driver itself was responsible for calling the code
that parses partitions.

Cheers.