Jedec.c problems in mtd-20000704

Jedec.c problems in mtd-20000704

[mark.langsdorf]

I'm sorry if this got patched in the latest CVS, but my
employer's proxy does not seem to support CVS, or perhaps
vice versa, so I have to use the latest tarball.

I've been having some problems with the 20000704 tarball in 
regards to jedec.c - first, I can't find a configuration
option that sets a symbol to compile jedec.c, and the Makefile
(in kernel) doesn't seem to have a rule to compile it.  I've
fixed that, but I wasn't sure if that was intentional or not.

Second, jedec.c (v 1.1) uses several members of the map_info 
structure that are no longer in the map_info structure.  
bus_width and band_size exist in the 1.4 version, but only 
buswidth exists in the 1.5 version.  Is there a suggested way 
to handle this change?

Mark Langsdorf
Advanced Micro Devices, Inc             Tel: 512.602.3756
5204 E. Ben White Blvd. M/S 590         Fax: 512.602.5051
Austin, TX 78741                        mark.langsdorf@amd.com


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

Re: Jedec.c problems in mtd-20000704

[David Woodhouse]

On Thu, 20 Jul 2000 mark.langsdorf@amd.com wrote:

> I'm sorry if this got patched in the latest CVS, but my
> employer's proxy does not seem to support CVS, or perhaps
> vice versa, so I have to use the latest tarball.

You really need to track the CVS. Can you at least get outgoing SSH? If
so, I can give you an account on infradead.org.

> 
> I've been having some problems with the 20000704 tarball in 
> regards to jedec.c 

 ... it doesn't compile and it can't be enabled. Those two aren't just
coincidence :) Jgg sent it to me and I dropped it in as-is, to prevent
duplication of effort.

Change bus_width to buswidth as necessary, and remove the bank_size
altogether, or make it an extra argument to the _probe() routines rather
than putting it in the struct mtd_info.

--
dwmw2



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

ELANSC400

[Gregory Schallert]

Well,  Here's a new guy to the crowd.

I've Just started playing with the MTD drivers for linux and I have a couple
of questions.
I am currently working on a project that (will) store the linux kernel/os on
flash.  We are useing the ElanSC400 chip and a board that has 3 pairs of
AM29F016EC Flash Chips arranged such that the high byte of the data goes to
one chip and the low byte goes to the other.  I was wondering if the MTD
supports this?  These chips are JEDEC compatiable.

Also I wrote a test program that run in user space and I tried using mmap()
to read the device and it seems to work OK as long as I map /dev/mem as
MAP_PRIVATE.  I would like to be able to write to Memory < 1M directly.  If
I change the flage to MAP_SHARED, mmap() falied with "Permision denied"  Any
ideas?

Greg Schallert
Dawning Technoligies Inc



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

RE: ELANSC400

[Simon Munton]

Hi Greg,

My company's using a board with an ElanSC410 and 4 AM29LV017B flash chips,
connected as yours are. I've just got MTD working on it, and have mounted
and used JFFS on them. 

I don't believe the 29F016 is a CFI compliant device, so you won't be able
to use the cfi_xxxxx routines from MTD directly, but it wouldn't be too hard
to get a driver going for the 29F016 - you could probably use the actual
read/write/erase functions from cfi_cmdset_0002.c directly.

Simon

========================================================
Simon Munton				simonm@m4data.co.uk
M4 Data Ltd					Tel: 44-1749-683800
Mendip Court, Bath Rd, Wells		Fax: 44-1749-673928
Somerset, BA5 3DG, England




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

Re: ELANSC400

[Stuart Lynne]

In article <005001bff32c$b59a92a0$8e00a8c0@gpc>,
Gregory Schallert <gschallert@dawning.com> wrote:
>Well,  Here's a new guy to the crowd.
>
>I've Just started playing with the MTD drivers for linux and I have a couple
>of questions.
>I am currently working on a project that (will) store the linux kernel/os on
>flash.  We are useing the ElanSC400 chip and a board that has 3 pairs of
>AM29F016EC Flash Chips arranged such that the high byte of the data goes to
>one chip and the low byte goes to the other.  I was wondering if the MTD
>supports this?  These chips are JEDEC compatiable.
>
>Also I wrote a test program that run in user space and I tried using mmap()
>to read the device and it seems to work OK as long as I map /dev/mem as
>MAP_PRIVATE.  I would like to be able to write to Memory < 1M directly.  If
>I change the flage to MAP_SHARED, mmap() falied with "Permision denied"  Any
>ideas?

The flash parts on the SC400 are mapped through the SC400 MMU. There are 
several models, but the easiest is to map them 8kb at a time into a memory
window in low memory (0xc8000 if I remember correctly).

Once there you can access them as normal flash memory. 

-- 
                                            __O 
Fireplug - a Lineo company                _-\<,_ 
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <sl@fireplug.net>       www.fireplug.net        604-461-7532


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

Re: ELANSC400

[Kira Brown]

On 24 Jul 2000, Stuart Lynne wrote:

> The flash parts on the SC400 are mapped through the SC400 MMU. There are 
> several models, but the easiest is to map them 8kb at a time into a memory
> window in low memory (0xc8000 if I remember correctly).

Actually, it can be anywhere between 0xc8000 and 0xd4000, maybe even
higher than that, I can't remember.  The MMU isn't really involved.  the
SC4x0 generates a bunch of chipselects whose active address windows can be
set using addressed registers.  The PCMCIA system is involved on SC400,
and the vestiges of it are involved on SC410.  Interestingly, there's also
a chip called SC405, but I can't get AMD to admit that it exists...

kira.



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

Re: ELANSC400

[Stuart Lynne]

On Tue, Jul 25, 2000 at 09:59:28AM +0100, Kira Brown wrote:
> 
> 
> On 24 Jul 2000, Stuart Lynne wrote:
> 
> > The flash parts on the SC400 are mapped through the SC400 MMU. There are 
> > several models, but the easiest is to map them 8kb at a time into a memory
> > window in low memory (0xc8000 if I remember correctly).
> 
> Actually, it can be anywhere between 0xc8000 and 0xd4000, maybe even
> higher than that, I can't remember.  The MMU isn't really involved.  the
> SC4x0 generates a bunch of chipselects whose active address windows can be
> set using addressed registers.  The PCMCIA system is involved on SC400,
> and the vestiges of it are involved on SC410.  Interestingly, there's also
> a chip called SC405, but I can't get AMD to admit that it exists...
 
Well it has been a year since I wrote that driver.... so I checked the SC400 
Register Set Manual..

The simple way is to use MMS Window A which is 32k bytes wide with a fixed
address range of B0000-B7FFFh (Pg. 3-40).

This is of course assuming the Flash devices are wired to their own select
line which is the norm on their (AMD) reference board. 

I suppose you could can also use the PC Card A or B memory space. That is
not what they (AMD) do on their reference board.

-- 
                                            __O 
Fireplug - a Lineo company                _-\<,_ 
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <sl@fireplug.net>         www.lineo.com         604-461-7532


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

Re: ELANSC400

[David Woodhouse]

sl@whiskey.fireplug.net said:
>  The flash parts on the SC400 are mapped through the SC400 MMU. There
> are  several models, but the easiest is to map them 8kb at a time into
> a memory window in low memory (0xc8000 if I remember correctly).

> Once there you can access them as normal flash memory. 

Any more details on how to set up and modify the mapping?

Preferably in the form of source code based on octagon-5066.c :)



--
dwmw2




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

Re: Jedec.c problems in mtd-20000704

[Jason Gunthorpe]

On Thu, 20 Jul 2000 mark.langsdorf@amd.com wrote:

> Second, jedec.c (v 1.1) uses several members of the map_info 
> structure that are no longer in the map_info structure.  
> bus_width and band_size exist in the 1.4 version, but only 
> buswidth exists in the 1.5 version.  Is there a suggested way 
> to handle this change?

The jedec stuff is not fully merged in properly yet.. So it doesn't work
without a little help of some sort.

I want to see if I can get back to that, but if you need it then I do not
recommend waiting for me :<

The code *does* work, I have tested it fairly well outside of the linux
environment. The tests I have been doing are on a 32 bit FLASH SIMM with 4
devices interleved together.

I did not write a write routine for anything other than that, but it
should be easy to see how to make a new one, IIRC :>

Jason



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

Re: Jedec.c problems in mtd-20000704

[Jason Gunthorpe]

On Fri, 21 Jul 2000, David Woodhouse wrote:

> Change bus_width to buswidth as necessary, and remove the bank_size
> altogether, or make it an extra argument to the _probe() routines rather
> than putting it in the struct mtd_info.

The JEDEC code has to refer to bank_size so it either goes into the main
structure or the private structure. All banked chips need that number so
IMHO you might as well make it common.

Check out the banked read routine to see why.

Jason



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