Trying to get MTD to do anything...

Trying to get MTD to do anything...

[James Hughes]

Hello all, 

sorry about this very basic (I assume) question.

I have a SandgateII PXA270 (ARM) board, and am trying to get the flash to be
recognised by MTD so I can mount a jffs2 fs over it.

The board uses Blob bootldr, and this shows 4 partitions on the flash. Last
of these is called ramdisk, from which originally the rootfs was loaded.
However I now use a rootfs over nfs so this partition is not used. I now
want to mount this partition as jffs2 as it's no longer used as a rootfs, so
I can do some performance testing of file handling on the flash itself -
which I obviously cannot do on the rootfs as it is over a network.

However, although I have enabled MTD in the kernel config, and all various
options I think I need, during kernel boot there is no indication that the
MTD driver(s) is being started up - no scanning, no flash finds etc.
Documentation for the patches for this board says MTD should be working.
Kernel version is 2.6.10.

Once booted, if I cat /proc/mtd there are no found MTD blocks.

My question (amongst many) is how do I get the MTD system to start up - what
have I missed? Is there any comprehensive documentation on this MTD system
and setting it up from the bootloader forward? (I have the book Building
Embedded Linux systems but its hasn't helped so far - but this is probably
because I am lacking a piece of information somewhere in my head which make
things clear)

James

Re: Trying to get MTD to do anything...

[Jared Hulbert]

> However, although I have enabled MTD in the kernel config, and all various
> options I think I need, during kernel boot there is no indication that the
> MTD driver(s) is being started up - no scanning, no flash finds etc.
> Documentation for the patches for this board says MTD should be working.
> Kernel version is 2.6.10.

> My question (amongst many) is how do I get the MTD system to start up - what
> have I missed?

Sounds like you are probably missing a map file for you system. 
drivers/mtd/maps/*.c

You can use the mainstone.c as a template.

Re: Trying to get MTD to do anything...

[Jared Hulbert]

> I don't know - the driver itself is being registered, since the printk I
> have put in are outputting to the kernel boot console. I get no other
> messages from the MTD system AT ALL.
>
> I asked where I need to debug to find out what causes the probe to be called
> - i.e. the area of code that starts up the MTD system, as I don't know where
> to start debugging

This seems more clear to me now.  You have a a sandgate map driver. 
You know it is being executed because of the printk()s, but it does
not actually call the probing routines.

>(I'm not talking about the map driver itself, but the
> code that call the map driver).

I'm not sure I understand your reasoning here.  The map driver is
being called.  The probing routines should be called by the map driver
but are not.  You need to debug the map driver at this point.

> There's no point in debugging in the probe
> function as I know that isn't being called.

Exactly.

> I created a file in the maps directory, which is a copy of the mainstone map
> (mainstone-flash.c)with alteration to match the sandgate2 flash map. I
> stated this in my previous message. This contains the module which is
> registered, but doesn't appear to be probed. There may be a problem with me
> misunderstanding what you mean map file - do you mean my Sandgate equivalent
> of mainstone-flash.c or is there a different map file I need to be sorting
> out?

Yes, I mean the sandgate equivalent of mainstone-flash.c.

> If it isn't being called (i.e. the probe section) how do I ensure that it
> *is* called????

Fix the map driver.

> I hope I have answered you questions satisfactorily this time.

Sorry about the unfriendly tone of the previous email.  It did not
read as I had intended.   I started and stopped that email several
times, apparently each time I restarted I added a new dig about not
answering question, oops :)

Re: Trying to get MTD to do anything...

[Jared Hulbert]

> In fact, all I know is the register function in the driver is being called -
> i.e. the function in
>
>         module_init(init_sandgate2)
>
> the init_sandgate2 function IS being called.
>
> This function simply does the following :
>
>         return driver_register(&sandgate2_flash_driver);
>
> and a printk in the function does display.
>
> I am not sure what there is to fix. The driver gets registered, but probe is
> never called. Its correctly added to the driver structure (in fact a direct
> copy from the mainstone variant, but with name changes to match sandgate2) -
> what else is there to debug?

This is very different than what I am expecting...
Actually there is no mainstone map in 2.6.10 look at the lubbock one
for reference.
http://sosdg.org/~coywolf/lxr/source/drivers/mtd/maps/lubbock-flash.c?v=2.6.10

If the map isn't doing the probe, then maybe it expects physmap stuff?
 I've always used the platform specfic map file, so I'm not going to
be any help with the physmap.  Also I don't think the phymap stuff is
optimized yet.

Re: Trying to get MTD to do anything...

[Todd Poynor]

>> This function simply does the following :
>>
>>         return driver_register(&sandgate2_flash_driver);
>>
>> and a printk in the function does display.
>>
>> I am not sure what there is to fix. The driver gets registered, but probe is
>> never called. Its correctly added to the driver structure (in fact a direct
>> copy from the mainstone variant, but with name changes to match sandgate2) -
>> what else is there to debug?

Make sure the .name field of your struct device_driver exactly matches 
the .name field of your struct device that you (hopefully) registered in 
your board file (since you're using mainstone-flash as an example see 
arch/arm/mach-pxa/mainstone.c for the board device side of it).

If you think that's setup right then debug what's going on in 
drivers/base/platform.c: platform_match().


-- 
Todd