Re: Flash device IDs

Re: Flash device IDs

[Andries.Brouwer]

    From: David Woodhouse <dwmw2@infradead.org>

    >  No, I am afraid this thing doesn't let me talk to raw flash, or if it
    > does, I have not yet discovered how.

    Ok... so when you issue write commands, you're pretending it's a normal
    SCSI hard drive and issuing requests with the _logical_ block numbers?
    You don't have to grok the SmartMedia format and issue _physical_
    addresses on the flash, handle ECC, the block chains, etc.?

It is worse. The commands are SCSI-like, but vendor-unique.
So one has to discover the commands and the details of the
media format. I wrote an ECC routine, and do something more
or less random for the connection between logical and physical blocks.
If you have ECC and LBA/PBA handling, then there is more to merge.

[Things are not quite straightforward. I think the media uses
512+16 byte sectors, but my SCSI commands must use 512+64 byte
sectors.][Of course 512 and 16 are variables. Don't know about 64.]

Andries

Re: Flash device IDs

[David Woodhouse]

Andries.Brouwer@cwi.nl said:
>  It is worse. The commands are SCSI-like, but vendor-unique. So one
> has to discover the commands and the details of the media format. I
> wrote an ECC routine, and do something more or less random for the
> connection between logical and physical blocks. If you have ECC and
> LBA/PBA handling, then there is more to merge.

>From a brief perusal of the code, it looks like the commands map to basic 
operations on NAND flash - read/write/erase commands?

> [Things are not quite straightforward. I think the media uses 512+16
> byte sectors, but my SCSI commands must use 512+64 byte sectors.][Of
> course 512 and 16 are variables. Don't know about 64.] 

That definitely sounds like you're dealing with raw NAND flash chips - 
512 bytes with 16 bytes of 'spare' area - albeit through a _very_ 
strange interface.

If we have to write code to handle the actual SmartMedia translation layer,
which does translation of logical addresses to physical addresses for reads
and handles safely writing the data to a new address before updating the
metadata and possibly erasing old versions of the replaced logical sector,
etc, then we should make sure it works with both the USB readers and the 
raw flash chips.


--
dwmw2

Re: Flash device IDs

[David Woodhouse]

Andries.Brouwer@cwi.nl said:
>  No, I am afraid this thing doesn't let me talk to raw flash, or if it
> does, I have not yet discovered how. 

Ok... so when you issue write commands, you're pretending it's a normal 
SCSI hard drive and issuing requests with the _logical_ block numbers? You 
don't have to grok the SmartMedia format and issue _physical_ addresses on 
the flash, handle ECC, the block chains, etc.?

--
dwmw2

Re: Flash device IDs

[Andries.Brouwer]

David Woodhouse writes:

    Andries.Brouwer@cwi.nl said:
    > In include/linux/mtd/nand_ids.h there is some information about device
    > IDs and device properties of NAND flash devices.

    > In drivers/usb/storage/sddr09.c there is very similar information.
    > Probably both tables should be merged.

    Yes, probably. If the SDDR-09 lets you talk to the raw flash rather than 
    doing the SmartMedia format for you in hardware/firmware then that support
    probably also wants to be separated so it can be used on any hardware. 

Maybe you can look at ftp.XX.kernel.org people/aeb/*sddr09*.
I used identifiers nand_* when I thought things would be useful
for both (so that they should be outside of the usb tree).
Maybe we can find a suitable setup.

No, I am afraid this thing doesn't let me talk to raw flash,
or if it does, I have not yet discovered how.

Andries

Re: Flash device IDs

[David Woodhouse]

Andries.Brouwer@cwi.nl said:
> In include/linux/mtd/nand_ids.h there is some information about device
> IDs and device properties of NAND flash devices.

> In drivers/usb/storage/sddr09.c there is very similar information.
> Probably both tables should be merged.

Yes, probably. If the SDDR-09 lets you talk to the raw flash rather than 
doing the SmartMedia format for you in hardware/firmware then that support
probably also wants to be separated so it can be used on any hardware. 

--
dwmw2

Flash device IDs

[Andries.Brouwer]

In include/linux/mtd/nand_ids.h there is some information
about device IDs and device properties of NAND flash devices.

In drivers/usb/storage/sddr09.c there is very similar information.
Probably both tables should be merged.

Various comments:

- The combination NAND_MFR_TOSHIBA, 0x79 is missing in nand_flash_ids[].
  An appropriate line might be

	{"Toshiba TH58NS100DC",   NAND_MFR_TOSHIBA, 0x79, 27, 0, 3, 0x4000},

- The type names given as first item in this struct are too precise.
  They include all kinds of stuff like voltage and temperature range, etc.
  But the device ID only give the size, page size, erase size, I think.
  So, given any card, it is quite likely that the kernel report on it
  will have incorrect type number.
  Moreover, I get the strong impression that Toshiba and Samsung use
  identical device IDs, so that one does not need to know the
  manufacturer to interpret the device ID.
  Probably we should delete the first two items from the
  struct nand_flash_dev, and have something like

static inline char *nand_flash_manufacturer(int manuf_id) {
        switch(manuf_id) {
        case NAND_MFR_TOSHIBA:
                return "Toshiba";
        case NAND_MFR_SAMSUNG:
                return "Samsung";
        default:
                return "unknown";
        }
}

  for the manufacturer.

- In sddr09.c it is suggested that the Read Device ID command
  returns two bytes. But it may return more. My source has the
  comment

/*
 * Read Device ID Command: 12 bytes.
 * byte 0: opcode: ED
 *
 * Returns 2 bytes: Manufacturer ID and Device ID.
 * On more recent cards 3 bytes: the third byte is an option code A5
 * signifying that the secret command to read an 128-bit ID is available.
 * On still more recent cards 4 bytes: the fourth byte C0 means that
 * a second read ID cmd is available.
 */

  Nobody knows anything about this secret command?


I hope to come with a patch one of these centuries.

Andries