Supported flash memory

Supported flash memory

[Russ.Dill]

After attempting to find flash memory for the LART board (Intel DT28F160F3B),
I've decided I need a plan B. So while I'm calling different suppliers around
the world (any tips here would be appreciated), I'm designing my own StrongARM
board, but with different flash/more flash options. I plan to use what seems to
be the most popular non BGA footprint, TSOP-48. I'm printing out data sheets
from various manufactures now to find the best way to make the most universal
footprint/layout. 

Besides footprints, pinouts, etc, my other concern is software. The logical
combination would seem to be blob/mtd. What flash products are known or probable
to be compatible with this combination, what should I look for to attempt to
assertain compatibilty? Does blob/mtd work transparently with a 16bit or 32bit
ROM bus?

I of course know that blob will have to be modified to accept various flash
configurations, I'm asking about compatibilty without having to completely
rewrite large portions of mtd or blob.


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

Re: Supported flash memory

[David Woodhouse]

Russ.Dill@asu.edu said:
>  Besides footprints, pinouts, etc, my other concern is software. The
> logical combination would seem to be blob/mtd. What flash products are
> known or probable to be compatible with this combination, what should
> I look for to attempt to assertain compatibilty? Does blob/mtd work
> transparently with a 16bit or 32bit ROM bus? 

The MTD code ought to work with any CFI-compliant flash chip from Intel or 
AMD, and with a few others too. In most combinations of bus size / 
interleave.

I don't know about blob, but RedBoot should support most of the flash 
setups you're likely to encounter, too.

--
dwmw2




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

Re: Supported flash memory

[Kenneth Johansson]

David Woodhouse wrote:

> Russ.Dill@asu.edu said:
> >  Besides footprints, pinouts, etc, my other concern is software. The
> > logical combination would seem to be blob/mtd. What flash products are
> > known or probable to be compatible with this combination, what should
> > I look for to attempt to assertain compatibilty? Does blob/mtd work
> > transparently with a 16bit or 32bit ROM bus?
>
> The MTD code ought to work with any CFI-compliant flash chip from Intel or
> AMD, and with a few others too. In most combinations of bus size /
> interleave.
>

I have a custom made flassh module,so-dimm (72 pin), that I want to use but
don't know if  I can .

The module can have up to 16 chips. (AMD)
Every chip has a to be in 8 bit mode.
The address range is divided into 8 chip select, giving a 16 bit data bus.
Thus I can't do any other access than 16 bit and always activate two chip's.

Also, we make them with a version that has a boot block (different block
size) but I think MTD can handle that or ?
I don't see any problem switching over to a version with all block the same
size.


>
> I don't know about blob, but RedBoot should support most of the flash
> setups you're likely to encounter, too.
>

Why do the boot code need to support flash? Flash looks like a ordinary ROM
for everything not knowing the magic sequence.




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

Re: Supported flash memory

[David Woodhouse]

kenneth.johansson@inn.ericsson.se said:
>  The module can have up to 16 chips. (AMD) 
>  Every chip has a to be in 8 bit mode.
> The address range is divided into 8 chip select, giving a 16
> bit data bus. Thus I can't do any other access than 16 bit and always
> activate two chip's. 

OK, if it's CFI flash that should work.


>  Also, we make them with a version that has a boot block (different
> block size) but I think MTD can handle that or ?

We support that on AMD chips as of a couple of weeks ago. The logic is the 
same for Intel chips and the merge will happen soon. 

>  Why do the boot code need to support flash? Flash looks like a
> ordinary ROM for everything not knowing the magic sequence. 

For booting, it doesn't. For downloading a new kernel over CF Ethernet or 
xmodem and putting it into the flash, it does.

--
dwmw2




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

Re: Supported flash memory

[David Woodhouse]

Russ.Dill@asu.edu said:
>  What about flashes that say they have CUI (Command user interface)
> and SR (Status register)? 

Not sure. I haven't encountered those. 

> what are CFI commands? are they 8bit, 16bit? 

Can be either. 

> if you have 2 chips giving you a 32bit databus, does it write out the same
> command on the high lane and the low lane?  

Yep.


Russ.Dill@asu.edu said:
>  I've noticed LART connects address and data lines to flash in
> positions most convienent to route. Does this break any CFI
> functionality? 

What do you mean? It's generally considered quite rude for hardware 
designers to connect nets to _completely_ random places on the chips, 
although sometimes it wouldn't really surprise me.



--
dwmw2




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

Re: Supported flash memory

[Kenneth Johansson]

David Woodhouse wrote:

> Russ.Dill@asu.edu said:
> >  I've noticed LART connects address and data lines to flash in
> > positions most convienent to route. Does this break any CFI
> > functionality?
>
> What do you mean? It's generally considered quite rude for hardware
> designers to connect nets to _completely_ random places on the chips,
> although sometimes it wouldn't really surprise me.
>

Well with SRAM you can intercange any data pin with another data pin and
likewise with the adress bus and nothing would notice. Doing this with ROM or
FLASH makes things quite interesting. This would mean that anything trying to
program the device has to do translation.

If you get random routing to simplify layout to work it would probably qualify
for the nobel price.




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

Re: Supported flash memory

[David Woodhouse]

kenneth.johansson@inn.ericsson.se said:
>  Well with SRAM you can intercange any data pin with another data pin
> and likewise with the adress bus and nothing would notice. Doing this
> with ROM or FLASH makes things quite interesting. This would mean that
> anything trying to program the device has to do translation.

For address lines, this is fixed up by the 'map' driver. For data lines it's
a little more annoying. But include/linux/cfi_endian.h could theoretically
at least do any form of swapping you desire.


--
dwmw2




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

Re: Supported flash memory

[Nicolas Pitre]

On Fri, 5 Jan 2001, David Woodhouse wrote:

> Russ.Dill@asu.edu said:
> >  I've noticed LART connects address and data lines to flash in
> > positions most convienent to route. Does this break any CFI
> > functionality?
>
> What do you mean? It's generally considered quite rude for hardware
> designers to connect nets to _completely_ random places on the chips,
> although sometimes it wouldn't really surprise me.

They did!  My recommendation to Erik Mouw (the software guy from the LART
team) was to modify cfi_build_cmd() to sweezle the bits appropriately.


Nicolas



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

Re: Supported flash memory

[Nicolas Pitre]

On Fri, 5 Jan 2001, David Woodhouse wrote:

>
> kenneth.johansson@inn.ericsson.se said:
> >  Well with SRAM you can intercange any data pin with another data pin
> > and likewise with the adress bus and nothing would notice. Doing this
> > with ROM or FLASH makes things quite interesting. This would mean that
> > anything trying to program the device has to do translation.
>
> For address lines, this is fixed up by the 'map' driver. For data lines it's
> a little more annoying. But include/linux/cfi_endian.h could theoretically
> at least do any form of swapping you desire.

This is required only for flash in command mode, so cfi_build_cmd() is the
best place to shuffle bits.  Everything is likely to be shuffled at compile
time and raw reads/writes aren't impacted.


Nicolas



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

Re: Supported flash memory

[David Woodhouse]

On Fri, 5 Jan 2001, Nicolas Pitre wrote:

> This is required only for flash in command mode, so cfi_build_cmd() is the
> best place to shuffle bits.  Everything is likely to be shuffled at compile
> time and raw reads/writes aren't impacted.

Also need it for reading query results. cpu_to_cfi16() et al are provided
for this purpose. I suppose we should provide cpi_to_cfi8() and
cfi8_to_cpu() too.

-- 
dwmw2




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

Re: Supported flash memory

[David Woodhouse]

On Fri, 5 Jan 2001, Kenneth Johansson wrote:

> David Woodhouse wrote:
> > What do you mean? It's generally considered quite rude for hardware
> > designers to connect nets to _completely_ random places on the chips,
> > although sometimes it wouldn't really surprise me.
>
> Well with SRAM you can intercange any data pin with another data pin
> and likewise with the adress bus and nothing would notice. Doing this
> with ROM or FLASH makes things quite interesting. This would mean that
> anything trying to program the device has to do translation.
>
> If you get random routing to simplify layout to work it would probably
> qualify for the nobel price.

I just looked at the LART schematics. Ouch.

I fixed up the data line munging in cfi_endian.h. Doing a map driver is
left as an exercise for the reader.

static inline cfi32_to_cpu(__u32 x)
{
	__u32 ret;

	ret =  (x & 0x08009000) >> 11;
	ret |= (x & 0x00002000) >> 10;
	ret |= (x & 0x04004000) >> 8;
	ret |= (x & 0x00000010) >> 4;
	ret |= (x & 0x91000820) >> 3;
	ret |= (x & 0x22080080) >> 2;
	ret |= (x & 0x40000400);
	ret |= (x & 0x00040040) << 1;
	ret |= (x & 0x00110000) << 4;
	ret |= (x & 0x00220100) << 5;
	ret |= (x & 0x00800208) << 6;
	ret |= (x & 0x00400004) << 9;
	ret |= (x & 0x00000001) << 12;
	ret |= (x & 0x00000002) << 13;

	return ret;
}
static inline cpu_to_cfi32(__u32 x)
{
	__u32 ret;

	ret =  (x & 0x00010012) << 11;
	ret |= (x & 0x00000008) << 10;
	ret |= (x & 0x00040040) << 8;
	ret |= (x & 0x00000001) << 4;
	ret |= (x & 0x12200104) << 3;
	ret |= (x & 0x08820020) << 2;
	ret |= (x & 0x40000400);
	ret |= (x & 0x00080080) >> 1;
	ret |= (x & 0x01100000) >> 4;
	ret |= (x & 0x04402000) >> 5;
	ret |= (x & 0x20008200) >> 6;
	ret |= (x & 0x80000800) >> 9;
	ret |= (x & 0x00001000) >> 12;
	ret |= (x & 0x00004000) >> 13;

	return ret;
}

-- 
dwmw2




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

Supported Flash memory

[Jose Guilberto]

	Hello,

	Is it possible to boot Linux from any kind of flash memory with
the MTD project? If not, what are the basic requirements of the flash
memory on a SBC to allow booting from it? 

	Thank you very much for your help.

	Jose Guilberto



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

Re: Supported Flash memory

[David Woodhouse]

guilbert@ee.nmt.edu said:
> 
> 	Is it possible to boot Linux from any kind of flash memory with the
> MTD project? If not, what are the basic requirements of the flash
> memory on a SBC to allow booting from it?  

The MTD stuff doesn't really handle booting - it's only Linux drivers for 
once you've managed to boot the kernel. There are some patches for Grub to 
make it work from a DiskOnChip, and there is some code in the boot/ 
directory of the CVS tree for making the kernel boot from ROM/flash as a 
BIOS extension. Also see LinuxBIOS  - http://www.linuxbios.org/

--
dwmw2




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