add support for "eeprom info"

This patch adds a new sub command to eeprom called "info". This allows eeprom driver writers to implement a way of querying the device. For example, SPI flashes have status commands, jedec ids, part ids, and other fun stuff. It's useful to be able to quickly probe this data (so you know things are detected properly and all that jazz).

I made the function weak so that people aren't required to implement this function (mostly so that it does not break all the SPI drivers out there right now).

Quoted 5 lines · In message <[email protected]> you wrote:

This patch adds a new sub command to eeprom called "info". This allows eeprom driver writers to implement a way of querying the device. For example, SPI flashes have status commands, jedec ids, part ids, and other fun stuff. It's useful to be able to quickly probe this data (so you know things are detected properly and all that jazz).

How is this suppoesed to work on the "normal" EEPROm devices which are typically attached to the I2C bus?

Quoted 3 lines

I made the function weak so that people aren't required to implement this function (mostly so that it does not break all the SPI drivers out there right now).

... and I2C.

common/cmd_eeprom.c int do_eeprom ( cmd_tbl_t * cmdtp, int flag, int · line 110

Quoted 12 lines

common/cmd_eeprom.c +3 -1

+extern int  eeprom_info (void) __attribute__((weak));
 #if defined(CFG_EEPROM_WREN)
 extern int eeprom_write_enable (unsigned dev_addr, int state);
 #endif

@@ -104,7 +105,8 @@ int do_eeprom ( cmd_tbl_t * cmdtp, int flag, int
 argc, char *argv[])
 
 			puts ("done\n");
 			return rcode;
-		}
+		} else if (argc == 2 && eeprom_info && strcmp (argv[1], "info") == 0)
+			return eeprom_info ();

... && eeprom_info && ...?

Does that mean that a weak function resolves to a NULL pointer? Is this guaranteed?

Quoted 2 lines

... and I2C.

i have no idea, i dont use i2c flashes. i dont know if there is any standard for them. if there isnt, easy enough to protect with CONFIG_SPI.

Quoted 2 lines

Does that mean that a weak function resolves to a NULL pointer? Is this guaranteed?

of course. an undefined weak function resolves to 0.

Quoted 5 lines · In message <[email protected]> you wrote:

Quoted 1 line

... and I2C.

i have no idea, i dont use i2c flashes. i dont know if there is any standard for them. if there isnt, easy enough to protect with CONFIG_SPI.

We're not talking about flashes. We're talking about EEPROM. For example things like a AT24C164 or similar, see for example
http://www.atmel.com/dyn/resources/prod_documents/doc0105.pdf

the semantics are irrelevant. it's an external non-volatile memory device accessed via the eeprom command. the document you posted looks like that device doesnt have any way of querying it, so eeprom_info() for that device

would be useless. if this is normal among i2c eeproms, i'll repost the patch

with eeprom_info behind CONFIG_SPI. most SPI flashes nowadays support the jedec id command which allows for dynamic detection (which is how the Blackfin SPI driver that i wrote works). hook up any SPI flash and it "jus> t works".

Quoted 4 lines · In message <[email protected]> you wrote:

with eeprom_info behind CONFIG_SPI. most SPI flashes nowadays support the jedec id command which allows for dynamic detection (which is how the Blackfin SPI driver that i wrote works). hook up any SPI flash and it "just works".

I think you are doing something wrong when you try to use "eeprom" to access "SPI flash" - these are differnt entities...

Quoted 7 lines · Wolfgang Denk

Quoted 5 lines · In message <[email protected]> you wrote:

with eeprom_info behind CONFIG_SPI. most SPI flashes nowadays support the jedec id command which allows for dynamic detection (which is how the Blackfin SPI driver that i wrote works). hook up any SPI flash and it "just works".

Quoted 3 lines

I think you are doing something wrong when you try to use "eeprom" to access "SPI flash" - these are differnt entities...

then what is the "correct" method ? i dont see any other usable option in u-boot for hooking up SPI flashes without writing my own subsystem. -mike

Hey Mike,

Quoted 10 lines · Mike Frysinger

Quoted 8 lines · Wolfgang Denk

Quoted 4 lines · In message <[email protected]> you wrote:

with eeprom_info behind CONFIG_SPI. most SPI flashes nowadays support the jedec id command which allows for dynamic detection (which is how the Blackfin SPI driver that i wrote works). hook up any SPI flash and it "just works".

I think you are doing something wrong when you try to use "eeprom" to access "SPI flash" - these are differnt entities...

Quoted 2 lines

then what is the "correct" method ? i dont see any other usable option in u-boot for hooking up SPI flashes without writing my own subsystem.

Until recently SPI in U-boot was synonymous with 'SPI-based EEPROM'. In fact, CONFIG_SPI doesn't mean 'configure support for a SPI controller', it means 'configure support for a SPI EEPROM'. This is of course yet another artifact from another day that it would be nice to clean up.

I introduced CONFIG_HARD_SPI in the latest release cycle, and included a driver for a Freescale controller. It would be nice to have other drivers added for generic SPI support. My preference would be for you to expand the 'spi' command with something like:

'spi eeprom info'

Quoted 5 lines

drivers added for generic SPI support. My preference would be for you to expand the 'spi' command with something like:

'spi eeprom info'

i dont see how in the long run, this is any different from today. Wolfgang can still argue that the SPI flash is not an eeprom device, so "spi eeprom ..." is not appropriate. which means there is still no subsystem whatsoever for accessing SPI flashes.

If the device is SPI flash, then why not call it like that, i. e.

spi flash info

Or
spiflash info

to make it similar to the "nand" commands?

On the other hand, it might be still too shortsighted to tie this to the bus interface. For example, what about dataflash? As discussed many times before, we have similar issues with dataflash devices.

I don't have a good idea how to do it, but maybe this is a chance to get a good solution for NAND, dataflash, SPI flash and who knows what else?

Quoted 4 lines · In message <[email protected]> you wrote:

with eeprom_info behind CONFIG_SPI. most SPI flashes nowadays support the jedec id command which allows for dynamic detection (which is how the Blackfin SPI driver that i wrote works). hook up any SPI flash and it "just works".

I think you are doing something wrong when you try to use "eeprom" to access "SPI flash" - these are differnt entities...

Quoted 3 lines

I think you are doing something wrong when you try to use "eeprom" to access "SPI flash" - these are differnt entities...

let's make sure we're talking about the same thing. SPI flashes are eeproms that have a SPI interface. so Spansion's S25FLxxxx, ST's m25pxtmels AT45DBxxxx, Winbond's W25Xxx/W25Pxx, and such. they need to be erased before writing, are split up into some unit size, etc... all SPI flashes nowadays conform to the JEDEC standard (JEP106) which allows for querying of manufacturer/device ids so that they can be dynamically detected. sounds to me like "eeprom" is the correct interface for utilizing these devices.

Quoted 11 lines · In message <[email protected]> you wrote:

Quoted 2 lines

I think you are doing something wrong when you try to use "eeprom" to access "SPI flash" - these are differnt entities...

let's make sure we're talking about the same thing. SPI flashes are eeproms that have a SPI interface. so Spansion's S25FLxxxx, ST's m25pxtmels AT45DBxxxx, Winbond's W25Xxx/W25Pxx, and such. they need to be erased before writing, are split up into some unit size, etc... all SPI flashes nowadays conform to the JEDEC standard (JEP106) which allows for querying of manufacturer/device ids so that they can be dynamically detected. sounds to me like "eeprom" is the correct interface for utilizing these devices.

Sounds to me as if you were talking about flash devices with a SPI bus interface.

The original SPI eeprom support was implemented som 7+ years ago for the Siemens CCM board; this is where the "CONFIG_SPI" stuff in common/cmd_eeprom.c comes from, and this was supported by the cpu/mpc8xx/spi.c SPI driver. Note that this was a real EEPROM device, i. e. we just needed spi_read() and spi_write() functions to access it. No erase, no sectors or any such stuff.

That was an EEPROM - what you have looks like a flash device to me.

at the moment, the Blackfin SPI flash driver hides all of the erasing/writing stuff for the user so that it integrates easily into the eeprom command. i'm going to guess that you dont like the sound of that at all ;).

Well, there is a big difference between NOR flash and your device:
NOR flash is memory, but your's is a storage device attached to some bus interface (SPI here). The problem is that we don't have a good solution to interface with such devices yet.

Using the eeprom command for such devices is misleading, IMO. If you can live with the spiflash command, then this is not perfect, but I guess it will have to do for now as we don't have a better solution yet.

Quoted 10 lines · Wolfgang Denk

Well, there is a big difference between NOR flash and your device:
NOR flash is memory, but your's is a storage device attached to some bus interface (SPI here). The problem is that we don't have a good solution to interface with such devices yet.

Using the eeprom command for such devices is misleading, IMO. If you can live with the spiflash command, then this is not perfect, but I guess it will have to do for now as we don't have a better solution yet.

so we're clear, the proposed interface is:
spiflash info
spiflash <read|write> address offset count
spiflash erase offset count

and once this comes together (i dont think it'll take long), we can consider a generic "flash" command. i'm still not sure what it'll gain us (if anything) ... but i guess once we have more things to look at and compare, we can make a better decision
-mike

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
------------------------------------------------------------------------

_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Quoted 11 lines · Mike Frysinger

Quoted 9 lines · Wolfgang Denk

Well, there is a big difference between NOR flash and your device:
NOR flash is memory, but your's is a storage device attached to some bus interface (SPI here). The problem is that we don't have a good solution to interface with such devices yet.

Using the eeprom command for such devices is misleading, IMO. If you can live with the spiflash command, then this is not perfect, but I guess it will have to do for now as we don't have a better solution yet.

Quoted 4 lines

so we're clear, the proposed interface is:
spiflash info
spiflash <read|write> address offset count
spiflash erase offset count

This sounds fine to me. The address is obviously a ram source/destination address. I vote for an offset in bytes and a count in bytes. If the offset is not an appropriate sector boundary, it is an error. The count can be a partial sector without problems. Having the offset and count in different units is confusing IMHO, so bytes for both.

Also, Mike, I assume you will also add a module similar to env_eeprom.c to support environment in spiflash?