Skip to contentSkip to conversation

get_module_symbol / put_module_symbol

DISCUSSION Sébastien Côté 4 participants 10 messages Aug 7, 2000 – Sep 8, 2000 Memory technology devices (MTD)

lore
Share & tools
lore
#0 lore raw

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.

Signature · 4 lines
Sébastien Côté


To unsubscribe, send "unsubscribe mtd" to [email protected]
#1 lore raw
Quoted 5 lines · [email protected] 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 [email protected]

#2 lore raw
Quoted 8 lines · David Woodhouse
Quoted 5 lines · [email protected] 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.

Quoted 5 lines

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 ?

Signature · 4 lines
Sébastien Côté


To unsubscribe, send "unsubscribe mtd" to [email protected]
#3 lore raw

MTD support for 8x16 devices

In reply to David Woodhouse

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 [email protected]

#4 lore raw

Re: MTD support for 8x16 devices

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

Quoted 35 lines · 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?

Quoted 3 lines

Alice

To unsubscribe, send "unsubscribe mtd" to [email protected]

To unsubscribe, send "unsubscribe mtd" to [email protected]

#5 lore raw

Re: MTD support for 8x16 devices

In reply to Alice Hennessy
Quoted 2 lines · [email protected] 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?

Quoted 4 lines · [email protected] 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.

Quoted 3 lines · [email protected] 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 [email protected]

#6 lore raw

Re: MTD support for 8x16 devices

Quoted 6 lines · David Woodhouse
Quoted 2 lines · [email protected] 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?

Quoted 6 lines

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.

Quoted 11 lines
Quoted 4 lines · [email protected] 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.

Quoted 9 lines
Quoted 3 lines · [email protected] 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. ;)

Quoted 4 lines

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

Thanks,

Alice

To unsubscribe, send "unsubscribe mtd" to [email protected]

#7 lore raw

Re: MTD support for 8x16 devices

Quoted 2 lines · [email protected] 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.

Quoted 5 lines · [email protected] 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.

Quoted 1 line · [email protected] 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 [email protected]

#8 lore raw

get_module_symbol

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 [email protected]

#9 lore raw

Re: get_module_symbol

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 [email protected]