get_module_symbol / put_module_symbol

get_module_symbol / put_module_symbol

[Sébastien Côté]

Hi,

I want to compile MTD builtin in the kernel but the usage of
get_module_symbol and put_module_symbol makes it impossible at the
moment.  I grepped -r 'put_module_symbol' in linux/drivers/* for linux
2.2.16 and MTD was the only driver using it.  I'm not sure how this
should be replaced but I'd really like to get rid of it.

-- 
Sébastien Côté


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

Re: get_module_symbol / put_module_symbol

[David Woodhouse]

scote1@Matrox.COM said:
>  I want to compile MTD builtin in the kernel but the usage of
> get_module_symbol and put_module_symbol makes it impossible at the
> moment.  I grepped -r 'put_module_symbol' in linux/drivers/* for linux
> 2.2.16 and MTD was the only driver using it.  I'm not sure how this
> should be replaced but I'd really like to get rid of it. 

There's a fairly small patch to add put_module_symbol() to the 2.2 kernel, 
and to change the behaviour of get_module_symbol() accordingly - to make it 
match the 2.4 versions.

If you can come up with a better way to handle use counts, feel free.

--
dwmw2




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

Re: get_module_symbol / put_module_symbol

[Sébastien Côté]

David Woodhouse wrote:
> 
> scote1@Matrox.COM said:
> >  I want to compile MTD builtin in the kernel but the usage of
> > get_module_symbol and put_module_symbol makes it impossible at the
> > moment.  I grepped -r 'put_module_symbol' in linux/drivers/* for linux
> > 2.2.16 and MTD was the only driver using it.  I'm not sure how this
> > should be replaced but I'd really like to get rid of it.
> 
> There's a fairly small patch to add put_module_symbol() to the 2.2 kernel,
> and to change the behaviour of get_module_symbol() accordingly - to make it
> match the 2.4 versions.
> 
> If you can come up with a better way to handle use counts, feel free.


The problem is I want to compile a kernel with modules completly
disabled and right now it's not possible.
I COULD enable modules but since I want JFFS on my root partition, MTD
must be built in and I don't have any use for any other module.

But as I see it, the only problem is that get_module_sumbol() and
put_...() are called even if MTD isn't a module.  There's no need to
track use counts when you're not a module, right ?

-- 
Sébastien Côté


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

MTD support for 8x16 devices

[Alice Hennessy]

Hi,

 I am using the MTD driver  to accomodate two different products,  one  with
an AMD
and one  with an Intel Strata.   Both are the 8x16 variety.   I have several
questions:

1. The Strata is placed on the board as a byte wide device so I've added
another check in cfi_probe_new_chip() to try accessing the cfi ident info at
address 0xaa as well as the 0x55  (for buswidth of 1) and return an
"cfi_ident_adjustment" so that cfi_cfi_probe can correctly access the cfi
ident info (since the cfi ident field InterfaceDesc hasn't been read yet).
Is this an acceptable method to handle this?

2.  I've added code to support  1_by_8 functions in cfi_cmdset_0001.c for the
strata.  I've also added big endian and unaligned support in
cfi_amdext_write_2_by_16().   I've also added some support to handle different
erase sector sizes within one chip.  Has any of this already been checked in
recently?  And what is the procedure?

3.  For both products, I have made use of  my own combo of physmap.c and
nora.c so that the flash address and len can be set in menuconfig and the
flash can be partitioned.    It seems that this version of physmap.c can be
used in a very generic way if we also move buswidth into menuconfig.   I'm
also thinking about different ways for the partition sizes to be set outside
of physmap.c.   - any opinions?   Perhaps board specifics should be contained
in a header file and
be set via menuconfig or command line or ?

4.   I need to implement a char device where the customer wants to write to
the flash and have all the erase details handle by the driver.  They want to
simply do a dd into the device.  They don't need a file system
implementation.   Has there been any thought about doing this type of thing at
the driver level?


Alice







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

Re: MTD support for 8x16 devices

[Stéphane Laroche]

Hi Alice,

The cfi_probe.c and cfi_cmdset_0002.c files have been modified in the CVS version
to support more bus bandwidths and chip modes.

It would seem you're working with an old version.  You should get the latest CVS
files (see how on http://www.linux-mtd.infradead.org).

-Stephane

Alice Hennessy wrote:

> Hi,
>
>  I am using the MTD driver  to accomodate two different products,  one  with
> an AMD
> and one  with an Intel Strata.   Both are the 8x16 variety.   I have several
> questions:
>
> 1. The Strata is placed on the board as a byte wide device so I've added
> another check in cfi_probe_new_chip() to try accessing the cfi ident info at
> address 0xaa as well as the 0x55  (for buswidth of 1) and return an
> "cfi_ident_adjustment" so that cfi_cfi_probe can correctly access the cfi
> ident info (since the cfi ident field InterfaceDesc hasn't been read yet).
> Is this an acceptable method to handle this?
>
> 2.  I've added code to support  1_by_8 functions in cfi_cmdset_0001.c for the
> strata.  I've also added big endian and unaligned support in
> cfi_amdext_write_2_by_16().   I've also added some support to handle different
> erase sector sizes within one chip.  Has any of this already been checked in
> recently?  And what is the procedure?
>
> 3.  For both products, I have made use of  my own combo of physmap.c and
> nora.c so that the flash address and len can be set in menuconfig and the
> flash can be partitioned.    It seems that this version of physmap.c can be
> used in a very generic way if we also move buswidth into menuconfig.   I'm
> also thinking about different ways for the partition sizes to be set outside
> of physmap.c.   - any opinions?   Perhaps board specifics should be contained
> in a header file and
> be set via menuconfig or command line or ?
>
> 4.   I need to implement a char device where the customer wants to write to
> the flash and have all the erase details handle by the driver.  They want to
> simply do a dd into the device.  They don't need a file system
> implementation.   Has there been any thought about doing this type of thing at
> the driver level?
>
> Alice
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org



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

Re: MTD support for 8x16 devices

[David Woodhouse]

ahennessy@mvista.com said:
>  Has any of this already been checked in recently?  And what is the
> procedure?

Stéphane already pointed you at the latest CVS. If you want write access, 
let me have a SSH public key and a sample of your work :)

Can you confirm the mapping of the flash chips - you've got two interleaved
16-bit devices ('2_by_16') but you can only actually access them a byte at 
a time? What is the CPU? What happens if you _do_ try to read a whole word 
instead of only a byte?



ahennessy@mvista.com said:
>  I'm also thinking about different ways for the partition sizes to be
> set outside of physmap.c.   - any opinions?   Perhaps board specifics
> should be contained in a header file and be set via menuconfig or
> command line or ?

I think it's probably best to keep it in a header file or in physmap.c 
itself. The driver can default to no partitioning, and we can set up some
#defines at the beginning which allow people to change it as they see fit.


ahennessy@mvista.com said:
> 4.   I need to implement a char device where the customer wants to
> write to the flash and have all the erase details handle by the
> driver.  They want to simply do a dd into the device. 

No. Erase is a single ioctl() call, or a single invocation of the 
'eraseall' utility. The customer is wrong. :)

--
dwmw2




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

Re: MTD support for 8x16 devices

[Alice Hennessy]

David Woodhouse wrote:

> ahennessy@mvista.com said:
> >  Has any of this already been checked in recently?  And what is the
> > procedure?
>
> Stéphane already pointed you at the latest CVS. If you want write access,
> let me have a SSH public key and a sample of your work :)

Ok, I will do that.  I also just found out  that I need to subscribe to the
mtd-cvs list to follow what is being checked in?

>
>
> Can you confirm the mapping of the flash chips - you've got two interleaved
> 16-bit devices ('2_by_16') but you can only actually access them a byte at
> a time? What is the CPU? What happens if you _do_ try to read a whole word
> instead of only a byte?

One product has two interleaved 16 devices and is recognized as such by
cfi_probe_new_chip() and can be read as a whole word.

The other product has a single strata chip (8x16 variety) set in byte mode so
the bus width is 1.  The cfi ident info is requested at address 0xaa and read
starting at 0x20 so this is new code that I've added.   I'll  merge my code to
make use of the new define CFI_DEVICETYPE_X8 which I'm assuming was added for
this purpose?

The CPU is  PPC405GP.

>
>
> ahennessy@mvista.com said:
> >  I'm also thinking about different ways for the partition sizes to be
> > set outside of physmap.c.   - any opinions?   Perhaps board specifics
> > should be contained in a header file and be set via menuconfig or
> > command line or ?
>
> I think it's probably best to keep it in a header file or in physmap.c
> itself. The driver can default to no partitioning, and we can set up some
> #defines at the beginning which allow people to change it as they see fit.

Ok.

>
>
> ahennessy@mvista.com said:
> > 4.   I need to implement a char device where the customer wants to
> > write to the flash and have all the erase details handle by the
> > driver.  They want to simply do a dd into the device.
>
> No. Erase is a single ioctl() call, or a single invocation of the
> 'eraseall' utility. The customer is wrong. :)

Sooo,  I need to do the extra logic outside the driver level. ;)

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

Thanks,

Alice




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

Re: MTD support for 8x16 devices

[David Woodhouse]

ahennessy@mvista.com said:
>  Ok, I will do that.  I also just found out  that I need to subscribe
> to the mtd-cvs list to follow what is being checked in? 

Yep. I did have that going to the main list at one point, but people 
apparently prefer to have it separated.


ahennessy@mvista.com said:
>  The other product has a single strata chip (8x16 variety) set in byte
> mode so the bus width is 1.  The cfi ident info is requested at
> address 0xaa and read starting at 0x20 so this is new code that I've
> added.   I'll  merge my code to make use of the new define
> CFI_DEVICETYPE_X8 which I'm assuming was added for this purpose?

Dunno. That was added after I last looked at the CFI probe code.


ahennessy@mvista.com said:
> Sooo,  I need to do the extra logic outside the driver level. ;) 

See (and probably rename) util/doc_loadbios

--
dwmw2




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

get_module_symbol

[Alice Hennessy]

Hi,

Couple of questions:

get_module_symbol()  is not finding "cfi_cmdset_0002"  in my environment
because the symbol table has version info after the function name.    Any
clue why?  (I'm not building mtd as a module) - I'm currently getting
around this by using  strncmp.

Also,  in mtdchar.c  mtd_write()  -> should be passing kbuf instead of buf
in  (*(mtd->write)) call,  correct?

Thanks,
Alice



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

Re: get_module_symbol

[David Woodhouse]

Turn off CONFIG_MODVERSIONS or fix the places where it calls 
get_module_symbol() to somehow use the correct string.

--
dwmw2




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