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

[James Olin Oden]

On 8/10/07, Ralph Siemsen <ralphs at 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