What is the correct way to make an mtdchar device available?

What is the correct way to make an mtdchar device available?

[James Olin Oden]

I have a system with the ST Micro M50FW080 firmware hub.  I have
checked the source code and the jedec_probe module has detection code
for that driver.  So I've done:

   modprobe jedec_probe
   modprobe mtdchar

Both modules load with no output going to the console.   No /dev/mtd#
device appears (there are two firmware hubs so I would assume mtd0 and
mtd1 would apprear).  If I do a mknod, the device is there but I
cannot read from it.

I have now tried this with both the Fedora Core 6 kernel and the RHEL
5 kernel (all of which have mtd configured, and are using 2.6.18
kernel (with RedHats legion of patches).

What am I missing?  What is the correct way to bring up an mtdchar device?

Thanks...james

Re: What is the correct way to make an mtdchar device available?

[Ralph Siemsen]

On Wed, Aug 08, 2007 at 01:50:29PM -0400, James Olin Oden wrote:

> I have a system with the ST Micro M50FW080 firmware hub.  I have
> checked the source code and the jedec_probe module has detection code
> for that driver.  So I've done:

I'm not familiar with this device, but you appear to be missing a
mapping driver (see drivers/mtd/maps, the most common being "physmap").
You'll likely need to know the physical address and size of your flash
device.  Once addresses are known, then the xyz_probe routines will be
called to identify the device supposedly there.

I could be way off base, maybe the "firmware hub" works more magically.
My description is more for flash that is soldered on the board.

-R

Re: What is the correct way to make an mtdchar device available?

[James Olin Oden]

On 8/8/07, Ralph Siemsen <ralphs@netwinder.org> wrote:
> On Wed, Aug 08, 2007 at 01:50:29PM -0400, James Olin Oden wrote:
>
> > I have a system with the ST Micro M50FW080 firmware hub.  I have
> > checked the source code and the jedec_probe module has detection code
> > for that driver.  So I've done:
>
> I'm not familiar with this device, but you appear to be missing a
> mapping driver (see drivers/mtd/maps, the most common being "physmap").
> You'll likely need to know the physical address and size of your flash
> device.  Once addresses are known, then the xyz_probe routines will be
> called to identify the device supposedly there.
>
Yeah, I saw something about "physmap" in one web page.  The module was
not available on my system, but it looks like its in the source code,
which means RedHat did not have it configured to build.  I can work
with that.

> I could be way off base, maybe the "firmware hub" works more magically.
> My description is more for flash that is soldered on the board.
No its just a flash chip soldered on the board, that they call a
firmware hub, because the intent of the mother board manufacturer was
to place BIOS in it.

Thank you...james

>
> -R
>

Re: What is the correct way to make an mtdchar device available?

[James Olin Oden]

On 8/8/07, Ralph Siemsen <ralphs@netwinder.org> wrote:
> On Wed, Aug 08, 2007 at 01:50:29PM -0400, James Olin Oden wrote:
>
> > I have a system with the ST Micro M50FW080 firmware hub.  I have
> > checked the source code and the jedec_probe module has detection code
> > for that driver.  So I've done:
>
> I'm not familiar with this device, but you appear to be missing a
> mapping driver (see drivers/mtd/maps, the most common being "physmap").
> You'll likely need to know the physical address and size of your flash
> device.  Once addresses are known, then the xyz_probe routines will be
> called to identify the device supposedly there.

Is there any documentation anywhere that talks about the mapping
driver, their uses and requriements?

I started looking into this and the config involves answering things
like "physical start address of flash mapping".   I guess that would
be the start adress of where the FWH maps itself into memory, but
since there are two on the system setting this does not seem
appropriate.

Also, is there anything that explains what one might need to do in the
context of simply making a flash chip available for reading and
writing through mtdchar mtdblock?

Thanks...james
>
> I could be way off base, maybe the "firmware hub" works more magically.
> My description is more for flash that is soldered on the board.
>
> -R
>

Re: What is the correct way to make an mtdchar device available?

[Ralph Siemsen]

On Thu, Aug 09, 2007 at 03:03:12PM -0400, James Olin Oden wrote:
 
> Is there any documentation anywhere that talks about the mapping
> driver, their uses and requriements?

Not specifically, that I am aware of.  There is some documentation
in Documentation/DocBook/mtdnand.tmpl althought it is geard towards
NAND flash particulars.  I actually started writing a little HOWTO
after I had figured it out, but it never got far enough to be useful.

> I started looking into this and the config involves answering things
> like "physical start address of flash mapping".   I guess that would
> be the start adress of where the FWH maps itself into memory, but
> since there are two on the system setting this does not seem
> appropriate.

When you have multiple chips arranged contiguously, then you just give
it the beginning address of the block, and the total size.  The code 
does multiple probes in this region to identify the individual flash
chips.  Interleaved devices (eg. two x16 devices on a 32-bit bus)
are also handled the same way.

Flash is often physically located at the very top, or very bottom, of
the memory map.  So if you have say 16MiB of flash, chances are that it
is mapped at address 0xff000000 with a size of 0x01000000.

In the drivers/mtd/maps directory you will see a large number of very
similar mapping drivers for various boards.  They differ in how they
get the address/size parameters-- some are hardcoded for specific boards,
others read information dynamically from the bootloader, etc.  Many of
them also handle partitioning of the flash -- splitting physical devices
into multiple logical ones, much like you'd do on a hard disk.

> Also, is there anything that explains what one might need to do in the
> context of simply making a flash chip available for reading and
> writing through mtdchar mtdblock?

I presume you've see the FAQ and the general documention on the
www.linux-mtd.infradead.org web site?  The general steps are to turn
on MTD debug options in your kernel, enable the appropriate mapping 
driver, and then look through the "dmesg" during boot-up, you should
see your flash chip detected.  If not, check the mapping driver...
You should see something along these lines:

[...]
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
ide-floppy driver 0.99.newide
physmap platform flash device: 01000000 at ff000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
 Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
erase region 0: offset=0x0,size=0x20000,blocks=128
[...]

Once the chip is detected, you can enable mtdblock/char drivers and
then probably you want filesystem (JFFS2/YAFFS etc) on top of that.

-R

Re: What is the correct way to make an mtdchar device available?

[James Olin Oden]

> When you have multiple chips arranged contiguously, then you just give
> it the beginning address of the block, and the total size.  The code
> does multiple probes in this region to identify the individual flash
> chips.  Interleaved devices (eg. two x16 devices on a 32-bit bus)
> are also handled the same way.
>
> Flash is often physically located at the very top, or very bottom, of
> the memory map.  So if you have say 16MiB of flash, chances are that it
> is mapped at address 0xff000000 with a size of 0x01000000.
>
So is there a way to tell physmap this information when you load it,
rather than have it hard coded in the kernel?  Or am I
misunderstanding things?

> In the drivers/mtd/maps directory you will see a large number of very
> similar mapping drivers for various boards.  They differ in how they
> get the address/size parameters-- some are hardcoded for specific boards,
> others read information dynamically from the bootloader, etc.  Many of
> them also handle partitioning of the flash -- splitting physical devices
> into multiple logical ones, much like you'd do on a hard disk.
So does this mean I would need to create one of these drivers for each
of my firmware hub types?

Also, what roll then does the code in jedec_probe play in all this?
My simple fantasy was that since there was "probe" info for my two
flash devices (i.e. the two I needed to support) I should only need to
load jedec_probe and mtdchar.  But that was not the case...so where is
my thinking wrong?

>
> > Also, is there anything that explains what one might need to do in the
> > context of simply making a flash chip available for reading and
> > writing through mtdchar mtdblock?
>
> I presume you've see the FAQ and the general documention on the
> www.linux-mtd.infradead.org web site?
Yeah your presumption is correct.  I think what the FAQ needs is some
question like:

   I have flash device X used for BIOS, what do I need to do to update my BIOS?

or even:

  How do I update my BIOS with MTD?

The crazy part is once I get the thing detected and the mtdchar device
up its, a very simple process.  If I get this going at some point I am
definately willing to provide the text for that part of the FAQ.   I
think the issue I am having is that though I'm comfortable in the
kernel and with programing in linux, I'm not an embedded developer and
most of the docs are geared towards "so you want to put a filesystem
on this flash device" or "so you want to boot from this flash device",
but the subsystem at least as much as I can understand is clearly
suitable for the "so you want to update your bios" users.

Thanks...james

Re: What is the correct way to make an mtdchar device available?

[Ralph Siemsen]

On Fri, Aug 10, 2007 at 10:20:49AM -0400, James Olin Oden wrote:
>
> So is there a way to tell physmap this information when you load it,
> rather than have it hard coded in the kernel?  Or am I
> misunderstanding things?

Some of the physmap variants obtain the information from (say) the
BIOS or OpenFirmware.  It would be fairly trivial to make physmap
take module parameters that you pass at modprobe/insmod time.  The
reason this isn't done is because most users are trying to boot off
the flash chip (on embedded systems), so its too late... you have to
provide the address at compile time, or query the firmware.

> Also, what roll then does the code in jedec_probe play in all this?
> My simple fantasy was that since there was "probe" info for my two
> flash devices (i.e. the two I needed to support) I should only need to
> load jedec_probe and mtdchar.  But that was not the case...so where is
> my thinking wrong?

You've got an address space of 2^32 bytes, not counting larger 36/64 bit
possibilities, extra memory spaces hiding behind bridges, etc.  It is 
just not feasible to proble them all for flash devices.  And there is
no other way to enumerate flash chips on a bus (unlike say PCI or USB,
where you can walk through each device in turn).

So the kernel must be told where to go looking for flash chips.  It will
then use the code in jedec_probe (or cfi_probe for CFI-compliant chips)
to identify any chip at the specified address.  It will do so once at
the beginning of the address/size you specified.  If a device is found,
but is smaller than the size you specified, then the kernel will try to
probe a second time right after the first device ends.  This way it will
find numerous chips that are contiguous in the memory space.

> Yeah your presumption is correct.  I think what the FAQ needs is some
> question like:
> 
>    I have flash device X used for BIOS, what do I need to do to update my BIOS?
> 
> or even:
> 
>   How do I update my BIOS with MTD?

I think this is (currently) a fairly uncommon situation.  Most of the
MTD users are working in embedded systems where the entire operating
system (kernel, userspace and all) lives in the flash.  They have to
get MTD running really early on in their development cycle, eg. as 
part of bringing up the kernel on the board, while adjusting IRQs and
such things.  Relatively few people have a fully-working PC that boots
where they later decide they want to access some on-board flash.

> The crazy part is once I get the thing detected and the mtdchar device
> up its, a very simple process.  If I get this going at some point I am
> definately willing to provide the text for that part of the FAQ.   I
> think the issue I am having is that though I'm comfortable in the
> kernel and with programing in linux, I'm not an embedded developer and
> most of the docs are geared towards "so you want to put a filesystem
> on this flash device" or "so you want to boot from this flash device",
> but the subsystem at least as much as I can understand is clearly
> suitable for the "so you want to update your bios" users.

I think you hit the nail on the hammer there.  I should probably mention
that commodity PC hardware may have some additional locking to prevent
users from accidentally erasing their BIOS.  It could come in the form of
a GPIO signal that has to be toggled, etc.  If such hardware is present,
it will likely be motherboard-specific, and it would need to be handled
in a customized variant of the mapping driver.  Another issue could be
the "window size", eg. you might only see 64kB of the flash chip even
when the device is larger due to how the southbridge is setup.

I am guessing the LinuxBIOS folks have dealt with these sorts of issues,
perhaps worth a look to see what they've come up with.

-R

Re: What is the correct way to make an mtdchar device available?

[James Olin Oden]

On 8/10/07, Ralph Siemsen <ralphs@netwinder.org> wrote:
> On Fri, Aug 10, 2007 at 10:20:49AM -0400, James Olin Oden wrote:
> >
> > So is there a way to tell physmap this information when you load it,
> > rather than have it hard coded in the kernel?  Or am I
> > misunderstanding things?
>
> Some of the physmap variants obtain the information from (say) the
> BIOS or OpenFirmware.  It would be fairly trivial to make physmap
> take module parameters that you pass at modprobe/insmod time.  The
> reason this isn't done is because most users are trying to boot off
> the flash chip (on embedded systems), so its too late... you have to
> provide the address at compile time, or query the firmware.
If I get it working with my test system then I'll likely generate said patch.

<snip>
> So the kernel must be told where to go looking for flash chips.  It will
> then use the code in jedec_probe (or cfi_probe for CFI-compliant chips)
> to identify any chip at the specified address.  It will do so once at
> the beginning of the address/size you specified.  If a device is found,
> but is smaller than the size you specified, then the kernel will try to
> probe a second time right after the first device ends.  This way it will
> find numerous chips that are contiguous in the memory space.
>
I understand now.

> > Yeah your presumption is correct.  I think what the FAQ needs is some
> > question like:
> >
> >    I have flash device X used for BIOS, what do I need to do to update my BIOS?
> >
> > or even:
> >
> >   How do I update my BIOS with MTD?
>
> I think this is (currently) a fairly uncommon situation.  Most of the
> MTD users are working in embedded systems where the entire operating
> system (kernel, userspace and all) lives in the flash.  They have to
> get MTD running really early on in their development cycle, eg. as
> part of bringing up the kernel on the board, while adjusting IRQs and
> such things.  Relatively few people have a fully-working PC that boots
> where they later decide they want to access some on-board flash.
Presently, system manufacturers excpect you to update your BIOS from
within windows or DOS, which too me is just kind of silly, not easily
automated (which holds more weight than the fact that I think its kind
of silly (-;).   As it turns out, MTD has support for some of the
firmware hubs (flash chips) that are used by BIOS's, so theoretically
it should be able to be used in this non-embeded environment way.

>
> I think you hit the nail on the hammer there.  I should probably mention
> that commodity PC hardware may have some additional locking to prevent
> users from accidentally erasing their BIOS.  It could come in the form of
> a GPIO signal that has to be toggled, etc.  If such hardware is present,
> it will likely be motherboard-specific, and it would need to be handled
> in a customized variant of the mapping driver.  Another issue could be
> the "window size", eg. you might only see 64kB of the flash chip even
> when the device is larger due to how the southbridge is setup.
>
Bummer.  It sounds like they are going out of their way to make it
hard to automate BIOS updates.   That explanation may explain why our
current proprietary driver did not work on a system that had the same
south bridge and firmware hub, but was not built by us.

> I am guessing the LinuxBIOS folks have dealt with these sorts of issues,
> perhaps worth a look to see what they've come up with.
I will check that out.

Thank you...james

Re: What is the correct way to make an mtdchar device available?

[Leon Woestenberg]

Hello all,

On 8/10/07, James Olin Oden <james.oden@gmail.com> wrote:
> On 8/10/07, Ralph Siemsen <ralphs@netwinder.org> wrote:
> > On Fri, Aug 10, 2007 at 10:20:49AM -0400, James Olin Oden wrote:
> > >
> > >   How do I update my BIOS with MTD?
> > ...
> Bummer.  It sounds like they are going out of their way to make it
> hard to automate BIOS updates.   That explanation may explain why our
> current proprietary driver did not work on a system that had the same
> south bridge and firmware hub, but was not built by us.
>
> > I am guessing the LinuxBIOS folks have dealt with these sorts of issues,
> > perhaps worth a look to see what they've come up with.
> I will check that out.
>

I once tried the same on a Supermicro server. I had to do this before
I could access the memory. I think I used some flashtool from
Linuxbios as well.

http://www.esrac.ele.tue.nl/~leon/linux/patches/2.4.27-bios-unreserved.patch

I don't remember the details though, this has been over 16 months ago
and we have never used it in production.

I'ld love to hear your results.

*** Assume that you screw up your BIOS image / chip --- so make sure
you have a working copy or a second machine you can use to boot from,
and/or BIOS flash tool. etc etc ***

Regards,
-- 
Leon