Re: Elan SC520 - problem with MTD

Re: Elan SC520 - problem with MTD

[Robert Kaiser]

Hi Alexander,

On Mon, 23 Apr 2001 you wrote:
> Hello Robert!
> Thank You very much for Your help.
> I worked with kernel 2.2.18 but could not achieve a success.
> Now I use Linux kernel 2.4.0 and latest version MTD from CVS. After booting
> in /proc/mtd I see :
> dev:    size   erasesize  name
> mtd0: 00800000 00040000 "SC520CDP Flash Bank #0"
> mtd1: 00800000 00040000 "SC520CDP Flash Bank #1"
> 
> Das ist fantastik!
> It was a good present for me last week ( my son was born last week!).

Well, congratulations to you and your wife then!!

> Now I must place a kernel to a flash and booting from it.
> What steps should be undertaken to reach that result?

One Question: Do you want to keep the BIOS ?

If yes, then I have a working solution, but it is not very nice:

Some Background info: 

In order to persuade the BIOS to boot from the Flash, you have to enable it's
"disk" emulation:  the BIOS can treat each of the flash banks as an emulated
disk. So far so good, but: these "disk" functions are only accessible through
the BIOS int 13h call, thus, you can't access it from Linux.

Worse even, the BIOS insists on doing "wear levelling" (i.e. it tries to
distribute erases evenly over all flash blocks). It does this by remapping
flash blocks when they have seen to many write erases. Therefore,  if you
write a continuous stream of data to the flash using the BIOS int13h function,
the BIOS will scatter your data all over the flash memory in an unpredictable
way. There is no way (other than buying a customized BIOS from General
Software) to disable his wear levelling. So the bottom line is:

* If you want to use the BIOS to boot from Flash, you must enable it's Disk
  emulation.
* If you use the Disk emulation, you must do all accesses to the boot flash
  through the BIOS int 13h.
* Bootloaders can access the Flash through the BIOS, but Linux can't.

Thus you essentially have to sacrifice one of the two banks entirely for booting
a kernel from it. Quite a waste considering it has 8 MB. In order to get a
bootable (via the BIOS) flash "disk", the easiest way is to put a minimal DOS
system on it with your kernel and LOADLIN. You can then run LOADLIN
from AUTOEXEC.BAT to boot your Linux Kernel.

As I said, this is ugly, but it should work.

However, if you want to get rid of the BIOS, you have to write your own startup
code for the board, which is not a trivial task. Actually, I'm currently
working on something like that, but it is not ready for release yet and I'm
making only slow progress as I have about a hundred other things to do.
However, I believe, Vipin Malik has gotten this to work for himself. Maybe if
you ask him nicely...

Cheers

Rob

----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


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

Re: Elan SC520 - problem with MTD

[David Woodhouse]

rob@sysgo.de said:
>  Some Background info: 
> In order to persuade the BIOS to boot from the Flash, you have to
> enable it's "disk" emulation:  the BIOS can treat each of the flash
> banks as an emulated disk. So far so good, but: these "disk" functions
> are only accessible through the BIOS int 13h call, thus, you can't
> access it from Linux.

> Worse even, the BIOS insists on doing "wear levelling" (i.e. it tries
> to distribute erases evenly over all flash blocks). It does this by
> remapping flash blocks when they have seen to many write erases.
> Therefore,  if you write a continuous stream of data to the flash
> using the BIOS int13h function, the BIOS will scatter your data all
> over the flash memory in an unpredictable way. There is no way (other
> than buying a customized BIOS from General Software) to disable his
> wear levelling. So the bottom line is: 

Has nobody tried to reverse-engineer the format they use for this and 
provide a driver in Linux? See the FTL and NFTL drivers for examples and 
ideas on how the BIOS might be doing the translation.

--
dwmw2




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

RE: Elan SC520 - problem with MTD

[Alex Lennon]

>> However, if you want to get rid of the BIOS, you have to write your own
startup
>> code for the board, which is not a trivial task. Actually, I'm currently
>> working on something like that, but it is not ready for release yet and
I'm
>> making only slow progress as I have about a hundred other things to do.
>> However, I believe, Vipin Malik has gotten this to work for himself.
Maybe if
>> you ask him nicely...

I this BIOS compressed ? If not you should be able to write a simple BIOS
extension
to hook INT13h or INT19h. Then when your BIOS proper executes the interrupt
your
custom BIOS extension code loads your kernel out of linear flash - or do you
see a
problem with this approach ?

Regards,

	Alex




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

RE: Elan SC520 - problem with MTD

[Robert Kaiser]

On Mon, 23 Apr 2001 you wrote:
> >> However, if you want to get rid of the BIOS, you have to write your own
> startup
> >> code for the board, which is not a trivial task. Actually, I'm currently
> >> working on something like that, but it is not ready for release yet and
> I'm
> >> making only slow progress as I have about a hundred other things to do.
> >> However, I believe, Vipin Malik has gotten this to work for himself.
> Maybe if
> >> you ask him nicely...
> 
> I this BIOS compressed ? If not you should be able to write a simple BIOS
> extension
> to hook INT13h or INT19h. Then when your BIOS proper executes the interrupt
> your
> custom BIOS extension code loads your kernel out of linear flash - or do you
> see a
> problem with this approach ?

Interesting idea -- a bit like the DOC approach  ;-)

Though I'm not sure if I understand that BIOS extension part right. As  far as I
can tell, the BIOS is not compressed, but it occupies the only ROM socket on the
board. A BIOS extension would have to be put in a seperate ROM, along with an
0xaa55 header and a checksum so the BIOS calls it, right ? 

In principle this could work. One would basically have to put part of the
MTD code into the BIOS extension to do the flash accesses. Keep in mind though
that the BIOS must be entered and left in real-mode (i.e. no access beyond 
1MB), so the BIOS extension would have to make the transition to protected mode
and back. I've done this a couple of times but this stuff is sooo ugly
that I always want to forget all about  it immediately after the job is done ;-)

To be honest, I don't think this is worth the trouble, I'd rather dump the BIOS
completely and write my own startup code.


Rob

----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


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

RE: Elan SC520 - problem with MTD

[Alex Lennon]

Rob,

>>Though I'm not sure if I understand that BIOS extension part right. As
far as I
>>can tell, the BIOS is not compressed, but it occupies the only ROM socket
on the
>>board. A BIOS extension would have to be put in a seperate ROM, along with
an
>>0xaa55 header and a checksum so the BIOS calls it, right ?

Yes indeed - a cut and paste job with an EPROM burner should do the job,
given
there is a couple of Kb free up there :-) Alternatively, and I guess this is
_particularly_
implementation specific, if the flash array is visible at boot time around
0xC000:0 - DFFF:0
you can put the BIOS extension in the flash array where the BIOS should pick
it up

>>In principle this could work. One would basically have to put part of the
>>MTD code into the BIOS extension to do the flash accesses. Keep in mind
though
>>that the BIOS must be entered and left in real-mode (i.e. no access beyond
>>1MB), so the BIOS extension would have to make the transition to protected
mode
>>and back. I've done this a couple of times but this stuff is sooo ugly
>>that I always want to forget all about  it immediately after the job is
done ;-)

I'm looking at this myself at the moment - the simplest solution is to
perform the hook,
load a zImage into low mem and let the Linux startup code handle the nasty
protected
mode bits 'n' pieces. Works fine for me under 2.2. Unfortunately I really
can't seem to
manage to get 2.4 down to < 500Kb so I need bzImage which means that - yes -
there is some protected mode support required. Alternatively it might be
possible to
throw the kernel up to 0x100000 using 32-bit real mode. I need to check on
this....

Regards,

	Alex




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

RE: Elan SC520 - problem with MTD

[Robert Kaiser]

On Mon, 23 Apr 2001 you wrote: 
> I'm looking at this myself at the moment - the simplest solution is to
> perform the hook,
> load a zImage into low mem and let the Linux startup code handle the nasty
> protected
> mode bits 'n' pieces. Works fine for me under 2.2. Unfortunately I really
> can't seem to
> manage to get 2.4 down to < 500Kb so I need bzImage which means that - yes -
> there is some protected mode support required. Alternatively it might be
> possible to
> throw the kernel up to 0x100000 using 32-bit real mode. I need to check on
> this....

If you're interested in this kind of stuff, have a look at our GPLed ROM loader.

ftp://ftp.sysgo.de/pub/elinos/1.0/updates/rolo_1.1_src.tar.gz

It loads a bzimage using 32-bit real mode. It is written mostly in C, but it
doesn't compile  with gcc (you need bcc). 

Rob

----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


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

Re: Elan SC520 - problem with MTD

[Vipin Malik]

Wow! Where (and why ;) were your hiding this gem for so long?!!!

This is the answer to a lot of maiden's prayers! Robert, are you the "rob" in the
CVS Id in the files?

Vipin

P.S. I saw a couple of mails ago that some folks mentioned that I have successfully

booted the linux kernel directly out of flash and installed the JFFS(2) as the root
fs
(and a ext2 fs as a compressed fs in ramdisk). That is all true.

Expect boot the kernel directly out of flash part, everything else is fully
documented
(some may say "painfully fully" documented) in my HOWTO in the CVS.

I have supplied, on request, the files to boot the kernel out of flash.  The
original source
of the hacked kernel boot code to do this was AMD (and it's open source of course).

Please let me know if you want those. HOWEVER! The solution is not a very elegant
one.
It involves making changes to some startup files (bootset.S and setup.S) in the
Linux
startup code itself.

Furthermore it only works with the 2.2.x series and with zImage (not bzImage).
Hence i've not
put it into CVS.

I think, if I understood the capabilities of the linked ftp files below properly,
this could be the
very elegant solution that we all were looking for. I'll investigate this a bit
further.




Robert Kaiser wrote:

> On Mon, 23 Apr 2001 you wrote:
> > I'm looking at this myself at the moment - the simplest solution is to
> > perform the hook,
> > load a zImage into low mem and let the Linux startup code handle the nasty
> > protected
> > mode bits 'n' pieces. Works fine for me under 2.2. Unfortunately I really
> > can't seem to
> > manage to get 2.4 down to < 500Kb so I need bzImage which means that - yes -
> > there is some protected mode support required. Alternatively it might be
> > possible to
> > throw the kernel up to 0x100000 using 32-bit real mode. I need to check on
> > this....
>
> If you're interested in this kind of stuff, have a look at our GPLed ROM loader.
>
> ftp://ftp.sysgo.de/pub/elinos/1.0/updates/rolo_1.1_src.tar.gz
>
> It loads a bzimage using 32-bit real mode. It is written mostly in C, but it
> doesn't compile  with gcc (you need bcc).
>
> Rob
>
> ----------------------------------------------------------------
> Robert Kaiser                         email: rkaiser@sysgo.de
> SYSGO RTS GmbH
> Am Pfaffenstein 14                    phone: (49) 6136 9948-762
> D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org



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

Re: Elan SC520 - problem with MTD

[Robert Kaiser]

On Die, 24 Apr 2001 you wrote:
> Wow! Where (and why ;) were your hiding this gem for so long?!!!

It's been there all the time ....

> 
> This is the answer to a lot of maiden's prayers! Robert, are you the "rob" in the
> CVS Id in the files?

Yep :-)

If there is enough public interest in this, maybe I can setup a home
page/public CVS for it some day. If only I had more time :-(


> P.S. I saw a couple of mails ago that some folks mentioned that I have
> successfully booted the linux kernel directly out of flash and installed
> the JFFS(2) as the root
> fs (and a ext2 fs as a compressed fs in ramdisk). That is all true.
> 
> I have supplied, on request, the files to boot the kernel out of flash.  The
> original source of the hacked kernel boot code to do this was AMD (and it's
> open source of course).
> Please let me know if you want those.

Yes, please !

> HOWEVER! The solution is not a very
> elegant one.
> It involves making changes to some startup files (bootset.S and setup.S) in the
> Linux startup code itself.

I am currently writing code to support booting  the SC520 CDP from ROM
without BIOS using the above mentioned ROM bootloader (BTW, it's name is
"ROLO" :-)).

What I'm mostly interested in is the startup/initialization sequence for that
board. Once it has been properly initialized, the generic ROLO code should
work out of the box.

I have some code that does the basic SC520 initialization right after
reset and I am now trying to initialize the Super I/O chip (I have just
received the chip manual from Acerlabs). After that, I need to figure out a way
to setup the set up the PCI bridge... Another thing that is still missing in my
code is a proper RAM size detection. 

So any working code you might have along these lines -no matter how ugly-
would probably be helpful to me.

Rob

----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


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

Re: Elan SC520 - problem with MTD

[David Woodhouse]

rob@sysgo.de said:
>  I have some code that does the basic SC520 initialization right after
> reset and I am now trying to initialize the Super I/O chip (I have
> just received the chip manual from Acerlabs). After that, I need to
> figure out a way to setup the set up the PCI bridge... Another thing
> that is still missing in my code is a proper RAM size detection. 

> So any working code you might have along these lines -no matter how
> ugly- would probably be helpful to me.

Talk to the LinuxBIOS people. They have much of this working.

--
dwmw2




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

Re: Elan SC520 - problem with MTD

[Ronald G Minnich]

On Tue, 24 Apr 2001, David Woodhouse wrote:

> > just received the chip manual from Acerlabs). After that, I need to
> > figure out a way to setup the set up the PCI bridge... Another thing
> > that is still missing in my code is a proper RAM size detection. 
> 
> > So any working code you might have along these lines -no matter how
> > ugly- would probably be helpful to me.
> 
> Talk to the LinuxBIOS people. They have much of this working.

hi rob, what is it you need to do?

ron



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

Re: Boot kernel from flash on CDPSC520 w/o BIOS!

[Alexander Melichenko]

Hello, Vipin!
To boot kernel from flash I do :
- reset the board (z).
- init it (yi).
- load lstart16.abs to it (ns lstart16.abs ff800, ns lstart16.abs 7ff800).
- load zImage to it with offset 0 (ns zImage 0).
After that I reboot CDP, but nothing is happening.
What step is wrong? 

Alexander Melichenko.




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

Re: Boot kernel from flash on CDPSC520 w/o BIOS!

[Vipin Malik]

Alexander Melichenko wrote:

> Hello, Vipin!
> To boot kernel from flash I do :
> - reset the board (z).
> - init it (yi).
> - load lstart16.abs to it (ns lstart16.abs ff800, ns lstart16.abs 7ff800).

Nope. You need to load the lstart16.abs file to the BIOS FLASH chip, NOT to
the FLASH bank0

>
> - load zImage to it with offset 0 (ns zImage 0).

Where did you init the root fs? Whe  zFlashImage boots, it will look to mount
the root fs. Also you need to
tell zFlah image what the root device is. See the HOWTO for more details.

>
> After that I reboot CDP, but nothing is happening.
> What step is wrong?

This is quite a complicated procedure. Make sure that you can read/write the
/mtd partitions. Read the HOWTO.

Vipin

>
>
> Alexander Melichenko.



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

Re: Boot kernel from flash on CDPSC520 w/o BIOS!

[Alexander Melichenko]

On Friday, April 27, Vipin Malic wrote :


> Alexander Melichenko wrote:
>
> > Hello, Vipin!
> > To boot kernel from flash I do :
> > - reset the board (z).
> > - init it (yi).
> > - load lstart16.abs to it (ns lstart16.abs ff800, ns lstart16.abs
7ff800).
>
> Nope. You need to load the lstart16.abs file to the BIOS FLASH chip, NOT
to
> the FLASH bank0
>
> >
> > - load zImage to it with offset 0 (ns zImage 0).
>
> Where did you init the root fs? Whe  zFlashImage boots, it will look to
mount
> the root fs. Also you need to
> tell zFlah image what the root device is. See the HOWTO for more details.
>
> >
> > After that I reboot CDP, but nothing is happening.
> > What step is wrong?
>
> This is quite a complicated procedure. Make sure that you can read/write
the
> /mtd partitions. Read the HOWTO.
>

Hello, Vipin!
Are the next steps correct?
- put lstart16.abs to 29F040 flash with offset 40000 (ns lstart16.abs
40000);
- put zImage to 29LV017 bank0 with offset 0 (???).
- put zFlash (root file system) to 29LV017 bank1 with offset 0 (???).
- rdev /dev/mtdblock??  /dev/mtdblock??.
- rdev -R zImage 0.

I experimented with that and other options, but currently result is bad.

Thank You.
           Alexander.



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

RE: Elan SC520 - problem with MTD

[mark.langsdorf]

Looks like I took the wrong week to go on vacation.

Could everyone who is currently doing work with either
the AMD Elan Sc520 Customer Development Platform or the
AMD Elan Net520 Demonstration Board please send me an
email and tell me what they're doing with it and what
kind of support they need from AMD?  I'll be glad to
provide whatever help/co-ordination I can.

And I'm working on getting that stupid license .pdf
removed from the tarball.  Sorry about that.

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

> -----Original Message-----
> From: Robert Kaiser [mailto:rob@sysgo.de]
> Sent: Tuesday, April 24, 2001 2:56 AM
> To: Vipin Malik
> Cc: Alex Lennon; mtd@infradead.org; jffs-dev
> Subject: Re: Elan SC520 - problem with MTD
> 
> 
> On Die, 24 Apr 2001 you wrote:
> > Wow! Where (and why ;) were your hiding this gem for so long?!!!
> 
> It's been there all the time ....
> 
> > 
> > This is the answer to a lot of maiden's prayers! Robert, 
> are you the "rob" in the
> > CVS Id in the files?
> 
> Yep :-)
> 
> If there is enough public interest in this, maybe I can setup a home
> page/public CVS for it some day. If only I had more time :-(
> 
> 
> > P.S. I saw a couple of mails ago that some folks mentioned 
> that I have
> > successfully booted the linux kernel directly out of flash 
> and installed
> > the JFFS(2) as the root
> > fs (and a ext2 fs as a compressed fs in ramdisk). That is all true.
> > 
> > I have supplied, on request, the files to boot the kernel 
> out of flash.  The
> > original source of the hacked kernel boot code to do this 
> was AMD (and it's
> > open source of course).
> > Please let me know if you want those.
> 
> Yes, please !
> 
> > HOWEVER! The solution is not a very
> > elegant one.
> > It involves making changes to some startup files (bootset.S 
> and setup.S) in the
> > Linux startup code itself.
> 
> I am currently writing code to support booting  the SC520 CDP from ROM
> without BIOS using the above mentioned ROM bootloader (BTW, 
> it's name is
> "ROLO" :-)).
> 
> What I'm mostly interested in is the startup/initialization 
> sequence for that
> board. Once it has been properly initialized, the generic 
> ROLO code should
> work out of the box.
> 
> I have some code that does the basic SC520 initialization right after
> reset and I am now trying to initialize the Super I/O chip (I 
> have just
> received the chip manual from Acerlabs). After that, I need 
> to figure out a way
> to setup the set up the PCI bridge... Another thing that is 
> still missing in my
> code is a proper RAM size detection. 
> 
> So any working code you might have along these lines -no 
> matter how ugly-
> would probably be helpful to me.
> 
> Rob
> 
> ----------------------------------------------------------------
> Robert Kaiser                         email: rkaiser@sysgo.de
> SYSGO RTS GmbH
> Am Pfaffenstein 14                    phone: (49) 6136 9948-762
> D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10
> 
> To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
> the body of a message to majordomo@axis.com
> 



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

Re: Elan SC520 - problem with MTD

[Alexander Melichenko]

Hello, Robert!
On  Sun, 15 April 2001, Robert Kaiser wrote :


>
> Hello Alexander
>
> On Fri, 13 Apr 2001, Alexander Melichenko wrote:
>
> > Hello, Robert!
> > I downloaded latest version of MTD from CVS with Your sc520cdp.c file. I
> > compile kernel with
> > MTD support, but result is not very good. During booting I see
> >   physmap flash device: 400000 at 800000
> >   Physically mapped flash : Found no CFI device at location zero
> >
> > After booting file /proc/mtd consists only:
> >    dev:       size      erasesize      name
> >
> > What does it mean?
>
> I suspect that you have not enabled CONFIG_MTD_CFI and/or
> CONFIG_MTD_JEDEC. The two 8MB Flash banks on the SC520CDP
> seem to be CFI compliant devices while the boot ROM is a JEDEC
> device. The sc520cdp.c module just provides a mapping (i.e.
> addresses and access methods for the Flash, but the probing stuff
> is in the CFI and JEDEC section.
>
>
> > Can you sent me your .config file? May be I check wrong option before
kernel
> > compilation?
>
> I'm sending you a copy of my .config file. It is from a 2.4.3 kernel,
> but the CONFIG_MTD_* options should work for you too.
>
> [Be careful not to write to device /dev/,mtd3. (Unless you want to
> overwrite your boot ROM).]
>

I checked my .config file and found following:
  - CONFIG_MTD_PHYSMAP was "CONFIG_MTD_PHYSMAP =y". I uncheked this option.
  - CONFIG_MTD_CFI=y
  - CONFIG_MTD_JEDEC=y
The rest of the options were as in your file.
I recompiled a kernel. During the boot up procces there were no messages
about MTD or CFI. After booting up in
file /proc/mtd was a record:
    dev:       size      erasesize      name

I hoped to see more informations in this file.

What should I do next?
May be I must reset some jumpers on CDP boards?

Thanks.
Alexander Melichenko.




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

Elan SC520 - problem with MTD

[Alexander Melichenko]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Hello!
We use Elan SC520 CDP Rev.1.3.
I have linux-2.2.18 (on hard drive) with MTD support. I use MTD MAKEDEV script to make MTD devices. I want to place kernel image into flash. But when I do 
  #cat zFlashImage > /dev/mtd0
I see the message : bash: /dev/mtd0: No such device
 
During booting I see following messages :
AMD Elan SC520 flash mapping: 1000000 at 4800000 
mapped physical memory to c4800000
Elan SC520 Physically mapped flash: Found no CFI device at location zero
JFFS version 1.0, (C) 1999, 2000 Axis Communications AB

When I inspect directory /proc  I see 2 (!!!) files mtd with no information about MTD devices.
 
How can I solve this problem?

Thanks for any help.
Alexander Melichenko.


[-- Attachment #2: Type: text/html, Size: 1234 bytes --]

Re: Elan SC520 - problem with MTD

[Robert Kaiser]

On Mit, 11 Apr 2001 you wrote:
> We use Elan SC520 CDP Rev.1.3.
> I have linux-2.2.18 (on hard drive) with MTD support. I use MTD MAKEDEV script to make MTD devices. I want to place kernel image into flash. But when I do 
>   #cat zFlashImage > /dev/mtd0
> I see the message : bash: /dev/mtd0: No such device
>  
> During booting I see following messages :
> AMD Elan SC520 flash mapping: 1000000 at 4800000 
> mapped physical memory to c4800000
> Elan SC520 Physically mapped flash: Found no CFI device at location zero
> JFFS version 1.0, (C) 1999, 2000 Axis Communications AB
> 
> When I inspect directory /proc  I see 2 (!!!) files mtd with no information about MTD devices.
>  
> How can I solve this problem?

Which mapping module are you using ?

There is one specifically designed for the SC520 CDP in the current MTD CVS.
It works fine on my (rev1.2) board. 

Cheers

Rob

----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


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

Re: Elan SC520 - problem with MTD

[Vipin Malik]

Alexander,

Since you are programming the flash directly into the mtd0 device, I presume that you are trying to boot from it directly.

Be aware of the following (this is true at least for the Rev 1.2 board). This is due to some
hardware challenged software programmer! (that's one for all the knocks the hardware people have taken from
the software guys everywhere :):

This caused me about half a week of misery before I figured it out.

/* The Embedded Systems BIOS decodes the first FLASH starting at
   0x8400000. This is a *terrible* place for it because accessing
   the flash at this location causes the A22 address line to be high
   (that's what 0x8400000 binary's out to be). But this is the highest
   order address line on the raw flash devices themselves!!
   This causes the top HALF of the flash to be accessed first. Beyond
   the physical limits of the flash, the flash chip aliases over (to
   0x880000 which causes the bottom half to be accessed. This splits the
   flash into two and inverts it! If you then try to access this from another
   program that does NOT do this insanity, then you *will* access the
   first half of the flash, but not find what you expect there. That
   stuff is in the *second* half!
*/

Enjoy,

Vipin



Robert Kaiser wrote:

> On Mit, 11 Apr 2001 you wrote:
> > We use Elan SC520 CDP Rev.1.3.
> > I have linux-2.2.18 (on hard drive) with MTD support. I use MTD MAKEDEV script to make MTD devices. I want to place kernel image into flash. But when I do
> >   #cat zFlashImage > /dev/mtd0
> > I see the message : bash: /dev/mtd0: No such device
> >
> > During booting I see following messages :
> > AMD Elan SC520 flash mapping: 1000000 at 4800000
> > mapped physical memory to c4800000
> > Elan SC520 Physically mapped flash: Found no CFI device at location zero
> > JFFS version 1.0, (C) 1999, 2000 Axis Communications AB
> >
> > When I inspect directory /proc  I see 2 (!!!) files mtd with no information about MTD devices.
> >
> > How can I solve this problem?
>
> Which mapping module are you using ?
>
> There is one specifically designed for the SC520 CDP in the current MTD CVS.
> It works fine on my (rev1.2) board.
>
> Cheers
>
> Rob
>
> ----------------------------------------------------------------
> Robert Kaiser                         email: rkaiser@sysgo.de
> SYSGO RTS GmbH
> Am Pfaffenstein 14                    phone: (49) 6136 9948-762
> D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org



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

Re: Elan SC520 - problem with MTD

[Alexander Melichenko]

Robert Kaiser wrote:
> Which mapping module are you using ?
>
> There is one specifically designed for the SC520 CDP in the current MTD
CVS.
> It works fine on my (rev1.2) board.
>
> Cheers
>
> Rob
>

I used e520.c (from AMD site), but after your letter I found that sc520cdp.c
there is on CVS.
I plan probing it today. Thank You very much.

Alexander Melichenko
LiveRepair.com Inc.
email: AlexanderM@lrpeople.com






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

Re: Elan SC520 - problem with MTD

[David Woodhouse]

AlexanderM@lrpeople.com said:
> I used e520.c (from AMD site), but after your letter I found that
> sc520cdp.c there is on CVS. I plan probing it today. Thank You very much.

What's the difference between the one in CVS and the one from AMD, other 
than the 'interesting' licence on the latter?

--
dwmw2




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

Re: Elan SC520 - problem with MTD

[Robert Kaiser]

On Die, 17 Apr 2001 you wrote:
> AlexanderM@lrpeople.com said:
> > I used e520.c (from AMD site), but after your letter I found that
> > sc520cdp.c there is on CVS. I plan probing it today. Thank You very much.
> 
> What's the difference between the one in CVS and the one from AMD, other 
> than the 'interesting' licence on the latter?

>From a brief look at it, I'd say that it is intended for AMD's "Net520" eval
board, not the SC520 CDP. The addresses it uses to access Flash are not
valid on the SC520 CDP, (at least not with the configuration established by the
General Software BIOS that the board comes with).

Rob


----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


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

Re: Elan SC520 - problem with MTD

[David Woodhouse]

rob@sysgo.de said:
> On Die, 17 Apr 2001 you wrote:
> > What's the difference between the one in CVS and the one from AMD, other 
> > than the 'interesting' licence on the latter?

>  From a brief look at it, I'd say that it is intended for AMD's
> "Net520" eval board, not the SC520 CDP. The addresses it uses to
> access Flash are not valid on the SC520 CDP, (at least not with the
> configuration established by the General Software BIOS that the board
> comes with).

OK, so the right thing to do would be to import it into CVS with a name 
like 'net520.c' ?

--
dwmw2




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

Re: Elan SC520 - problem with MTD

[Robert Kaiser]

On Die, 17 Apr 2001 you wrote:
> OK, so the right thing to do would be to import it into CVS with a name 
> like 'net520.c' ?

Probably (assuming the 'interesting' license allows it). Maybe someone with
access to a Net520 board could be persuaded to test/maintain it ?

Rob

----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


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

Re: Elan SC520 - problem with MTD

[David Woodhouse]

rob@sysgo.de said:
>  Probably (assuming the 'interesting' license allows it). Maybe
> someone with access to a Net520 board could be persuaded to test/
> maintain it ? 

The 'interesting' licence is just a mistake on the web site - I don't think
they really meant to claim copyright on the entire MTD snapshot tarball :) 

The ideal volunteer for testing/maintenance would be Mark, but he appears to
be away till April 25th, by which time I'm hoping to have completed the
merge. If I actually do manage to send patches off by then, I'll just
include it as net520.c. Otherwise I'll seek his advice upon his return.

--
dwmw2




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

Re: Elan SC520 - problem with MTD

[Vipin Malik]

[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]

This is the board that I am working with myself. I've got this working for
quite a while and have sent
my "physmap.c" file to a few folks personally (that's the original physmap.c
file from CVS hacked for the SC520 CDP- this was before there was
a physmap file in CVS for this board.)

Anywhy, why I bring this is up, there is a *nasty* surprise waiting for folks
that use the default address of 0x8400000 as programmed by the BIOS
shipped with the board.

This "nasty surpirse" is documented in my hacked physmap.c that I reproduct
below (and attached):

/* The Embedded Systems BIOS decodes the first FLASH starting at
   0x8400000. This is a *terrible* place for it bacause accessing
   the flash at this location causes the A22 address line to be high
   (that's what 0x8400000 binary's out to be). But this is the highest
   order address line on the raw flash devices themselves!!
   This causes the top HALF of the flash to be accessed first. Beyond
   the physical limits of the flash, the flash chip aliases over (to
   0x880000 which causes the bottom half to be accessed. This splits the
   flash into two and inverts it! If you then try to acces this from another
   program that does NOT do this insanity, then you *will* access the
   first half of the flash, but not find what you expect there. That
   stuff is in the *second* half!
*/

So, what's the problem you ask? Well if you don't want to use the BIOS to boot
the board
and want to boot the kernel image directly from flash (which I wanted to do and
finally did),
you would probably decode the FLASH starting at a more sensible location- like
0x8800000 in the
first place. But you won't find the kernel there if you put it there when the
board was booted
with the original BIOS. That kernel is sitting in the second half of the flash
bank, even though you put
it at the start of /dev/mtd0!

Attached is my physmap.c file. There is code there to change to PAR reg's to
redecode the FLASH
at a more sensible location. There is also some code that dumps all PAR reg's
that may be useful
to others.

I suggest that whoever checked the sc520cdp.c file into CVS, at the very least
pick up the above comments
and include them as a warning, even if they don't want to reprogram the PAR at
the new and proper address
(I suggest that we reprogram the PAR regs).

Sorry for the long post.

Vipin








David Woodhouse wrote:

> rob@sysgo.de said:
> >  Probably (assuming the 'interesting' license allows it). Maybe
> > someone with access to a Net520 board could be persuaded to test/
> > maintain it ?
>
> The 'interesting' licence is just a mistake on the web site - I don't think
> they really meant to claim copyright on the entire MTD snapshot tarball :)
>
> The ideal volunteer for testing/maintenance would be Mark, but he appears to
> be away till April 25th, by which time I'm hoping to have completed the
> merge. If I actually do manage to send patches off by then, I'll just
> include it as net520.c. Otherwise I'll seek his advice upon his return.
>
> --
> dwmw2
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

[-- Attachment #2: physmap.c --]
[-- Type: text/plain, Size: 9538 bytes --]

/*
 *	physmap.c - mapper for AMD Elan SC520 CDP eval board.
 *              based on Mark Langsdorf's net e520 file.
 *
 *              Modified for the SC520 CDP by Vipin Malik
 *
 *		based on pnc2000 by Crossnet Co.
 *
 * Copyright (C) 2000 Mark Langsdorf (mark.langsdorf@amd.com)
 *
 * This code is under the GPL, version 2.0
 *
 *
 * Basically, this is a physical memory map driver with 2 Flash banks
 * w/ 2 partitions each.
 *
 * If this code is used on custom designed boards, the
 * WINDOW_ADDR and WINDOW_SIZE parameters may have to
 * be changed, as well as the size of partition 2.
 *
 */
#include <linux/module.h>
#include <linux/malloc.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <asm/io.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/map.h>
#include <linux/mtd/partitions.h>
#include <linux/config.h>



/* Changes for the SC520 eval board -Vipin Malik
   NOTE: This code assumes equal size, contigious  flash 
   banks.
*/
#define NUMBANKS    2
/* The Embedded Systems BIOS decodes the first FLASH starting at
   0x8400000. This is a *terrible* place for it bacause accessing
   the flash at this location causes the A22 address line to be high
   (that's what 0x8400000 binary's out to be). But this is the highest
   order address line on the raw flash devices themselves!!
   This causes the top HALF of the flash to be accessed first. Beyond
   the physical limits of the flash, the flash chip aliases over (to
   0x880000 which causes the bottom half to be accessed. This splits the
   flash into two and inverts it! If you then try to acces this from another
   program that does NOT do this insanity, then you *will* access the
   first half of the flash, but not find what you expect there. That 
   stuff is in the *second* half!
   
   Starting to address the flash at 0x8800000 here solves this problem.
   This of course assumes that the PAR register for ROMCS0# is wide enough
   to address at least 12Megs of memory starting at 0x8400000.
*/
#define WINDOW_ADDR_BANK0 0x8800000

/* #define WINDOW_ADDR_BANK0 0x8400000 */

#define WINDOW_SIZE       0x0800000
/* BANK1 is assumed to start where BANK0 ends.*/
#define WINDOW_ADDR_BANK1 WINDOW_ADDR_BANK0 + WINDOW_SIZE



/* 
 * MAP DRIVER STUFF
 */

static struct mtd_info *mymtd[2] = {NULL, NULL};

__u8 physmap_read8(struct map_info *map, unsigned long ofs)
{
	return readb(map->map_priv_1 + ofs);
}

__u16 physmap_read16(struct map_info *map, unsigned long ofs)
{
	return readw(map->map_priv_1 + ofs);
}

__u32 physmap_read32(struct map_info *map, unsigned long ofs)
{
	return readl(map->map_priv_1 + ofs);
}

void physmap_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
{
	memcpy_fromio(to, map->map_priv_1 + from, len);
}

void physmap_write8(struct map_info *map, __u8 d, unsigned long adr)
{
	writeb(d, map->map_priv_1 + adr);
}

void physmap_write16(struct map_info *map, __u16 d, unsigned long adr)
{
	writew(d, map->map_priv_1 + adr);
}

void physmap_write32(struct map_info *map, __u32 d, unsigned long adr)
{
	writel(d, map->map_priv_1 + adr);
}

void physmap_copy_to(struct map_info *map, unsigned long to, const void *from, ssize_t len)
{
	memcpy_toio(map->map_priv_1 + to, from, len);
}

/*
  Each struct below defines one flash bank. Then each bank is
  partitioned into 2 partitions of equal (4MB) each. This can easily
  be changed as long as each partition starts/ends on sector boundary.
*/
struct map_info physmap_map[NUMBANKS] = {
       {
        "Elan SC520 Physically mapped flash BANK 0",
	WINDOW_SIZE,
	4,   /* Bus width in octets. 4= 32bit */
	physmap_read8,
	physmap_read16,
	physmap_read32,
	physmap_copy_from,
	physmap_write8,
	physmap_write16,
	physmap_write32,
	physmap_copy_to,
	0, /* set_vpp */
	0, /* map_priv_1 */
	0, /* map_priv_2 */
	0, /* fldrv_priv ?? */
	0  /* fldrv_destroy */
       },
       {
        "Elan SC520 Physically mapped flash BANK 1",
	WINDOW_SIZE,
	4,   /* Bus width in octets. 4= 32bit */
	physmap_read8,
	physmap_read16,
	physmap_read32,
	physmap_copy_from,
	physmap_write8,
	physmap_write16,
	physmap_write32,
	physmap_copy_to,
	0, /* set_vpp */
	0, /* map_priv_1 */
	0, /* map_priv_2 */
	0, /* fldrv_priv ?? */
	0  /* fldrv_destroy */
       }
};

/*
 * MTD 'PARTITIONING' STUFF 
 */
#define NUM_PARTITIONS 1

/*
  The following will give you:
  /dev/mtd0: partition1 of flash BANK0
  /dev/mtd1: partition2 of flash BANK0
  
  /dev/mtd2: partition1 of flash BANK1
  /dev/mtd3: partition2 of flash BANK1
*/
static struct mtd_partition physmap_partitions[NUM_PARTITIONS] = {
	{
                name: "Partition 1",      /* The first partition */
		size: 0x800000,       
		offset: 0
	}
};

#if LINUX_VERSION_CODE < 0x20212 && defined(MODULE)
#define init_physmap init_module
#define cleanup_physmap cleanup_module
#endif

mod_init_t init_physmap(void)
{

#define ROMCS_REG_RSV_BIT_MASK  (unsigned short)0x1E37
  
	unsigned long iomapadr;
	int i, cnt;
	unsigned short romcs1, romcs2; 
	volatile unsigned char dump;



	/* Print out all the PAR registers to see whick register sets the ROMCS0# and ROMCS1#.*/
	iomapadr = (unsigned long) ioremap_nocache(0xFFFEF000, 0xFFF);

	
        for(cnt=0; cnt <= 15; cnt++){
	  printk("PAR%i=0x%lxh\n", cnt, *((unsigned long *)(iomapadr+(cnt*4)+0x88)));
	}
	/*Now set PAR8 to 0x8800000 and PAR9 to 0x9000000 */
	*((unsigned long *)(iomapadr+(8*4)+0x88)) = (unsigned long)0xaa1fc880; /* PAR8, cache disabled, 0x80h 64KB pages */
	*((unsigned long *)(iomapadr+(9*4)+0x88)) = (unsigned long)0xca1fc900; /* PAR9, cache disabled, 0x80h 64KB pages  */

	/* Now set PAR10 (which was orig unused for selecting 32KB in GP mem space using GPCS4# (for accessing the FRAM) */
	*((volatile unsigned long *)(iomapadr+(10*4)+0x88)) = (unsigned long)0x502000D0; /* PAR10,GP memory,GPCS4 @0xD0000,32KB */

	asm volatile ("wbinvd\n\t"); /* invalidate the cache as the ELAN book instructs. Hope this is the correct way.  */

	printk("PAR%i=0x%lxh\n", 8, *((unsigned long *)(iomapadr+(8*4)+0x88)));


	printk("PAR%i=0x%lxh\n", 9, *((unsigned long *)(iomapadr+(9*4)+0x88)));

	printk("PAR%i=0x%lxh\n", 10, *((unsigned long *)(iomapadr+(10*4)+0x88)));

	/* Get the ROMCS1 and ROMCS0 chipselect registers.*/
	romcs1 = *((unsigned short *)(iomapadr+0x54));
	romcs2 = *((unsigned short *)(iomapadr+0x56));

	printk("ROMCS1=0x%xh\n", romcs1);
	printk("ROMCS2=0x%xh\n", romcs2);

	*((volatile unsigned short *)(iomapadr+0x54)) = (romcs1 |(unsigned short)0x0007)&ROMCS_REG_RSV_BIT_MASK; /* 7 wait states*/
	*((volatile unsigned short *)(iomapadr+0x56)) = (romcs2 |(unsigned short)0x0007)&ROMCS_REG_RSV_BIT_MASK; /* 7 wait states*/


	/* Get the ROMCS1 and ROMCS0 chipselect registers.*/
	romcs1 = *((unsigned short *)(iomapadr+0x54));
	romcs2 = *((unsigned short *)(iomapadr+0x56));

	printk("ROMCS1=0x%xh\n", romcs1);
	printk("ROMCS2=0x%xh\n", romcs2);

	printk("GPECHO = 0x%xh\n", *((unsigned char *)(iomapadr+0xC00)));
	printk("GPCSDW = 0x%xh\n", *((unsigned char *)(iomapadr+0xC01)));
	printk("GPCSQUAL = 0x%xh\n", *((unsigned short *)(iomapadr+0xC02)));
	printk("GPCSRT = 0x%xh\n", *((unsigned char *)(iomapadr+0xC08)));
	printk("GPCSPW = 0x%xh\n", *((unsigned char *)(iomapadr+0xC09)));
	printk("GPCSOFF = 0x%xh\n", *((unsigned char *)(iomapadr+0xC0A)));
	printk("GPRDW = 0x%xh\n", *((unsigned char *)(iomapadr+0xC0B)));
	printk("GPRDOFF = 0x%xh\n", *((unsigned char *)(iomapadr+0xC0C)));
	printk("GPWRW = 0x%xh\n", *((unsigned char *)(iomapadr+0xC0D)));
	printk("GPWROFF = 0x%xh\n", *((unsigned char *)(iomapadr+0xC0E)));
	printk("GPALEW = 0x%xh\n", *((unsigned char *)(iomapadr+0xC0F)));
	printk("GPALEOFF = 0x%xh\n", *((unsigned char *)(iomapadr+0xC10)));

	printk("CSPFS = 0x%xh\n", *((unsigned char *)(iomapadr+0xC24)));

	iounmap((void *) iomapadr); /* Free the iomapping */


	/* *************   The actual FLASH mtd stuff starts here   **************  */
	iomapadr = (unsigned long) ioremap_nocache(WINDOW_ADDR_BANK0, WINDOW_SIZE * NUMBANKS);

	if (!iomapadr) {
		printk("physmap.c:MTD:Failed to ioremap the physical memory!\n");
		return -EIO;
	}
	else 
		printk("physmap.c:MTD:mapped physical memory to %08lx\n", iomapadr);


	for(i = 0; i < NUMBANKS; i++){ 

	       printk(KERN_INFO "AMD Elan Sc520 flash mapping defined: %x at %x\n", 
		      WINDOW_SIZE, 
		      WINDOW_ADDR_BANK0 + (i * WINDOW_SIZE)); /* assumes equally sized windows */

       	       physmap_map[i].map_priv_1 = iomapadr + (i * WINDOW_SIZE); /* assumes equally sized windows */

	       mymtd[i] = (struct mtd_info *)do_cfi_probe(&physmap_map[i]);

	       if (mymtd[i]) {
		   printk(KERN_INFO "physmap flash module installed for flash BANK%i\n", i);
#ifdef MODULE
		   mymtd[i]->module = THIS_MODULE;
#endif
		   if( add_mtd_partitions(mymtd[i], physmap_partitions, NUM_PARTITIONS) < 0){

		     goto ERR_JMPOUT;
		   }
		   
	       }else{

		     goto ERR_JMPOUT;
	       }
	}

	return 0;

       /* Bad  stuff has happened. Clean up and return error. */
 ERR_JMPOUT: 
	iounmap((void *) iomapadr);     /* give back our memory mapping */
	for( i = 0; i < NUMBANKS; i++){
	  physmap_map[i].map_priv_1 = 0;
	}

	inter_module_put("cfi_probe");	

	return -ENXIO;

}

mod_exit_t cleanup_physmap(void)
{

	int i;
	
	for (i=0; i<2; i++) {
		if (mymtd[i]) {
			del_mtd_partitions(mymtd[i]);
			map_destroy(mymtd[i]);
		}
	}

	if (physmap_map[0].map_priv_1) {
		iounmap((void *) physmap_map[0].map_priv_1);
		for( i = 0; i < NUMBANKS; i++){
		       physmap_map[i].map_priv_1 = 0;
		}
	}
}

module_init(init_physmap);
module_exit(cleanup_physmap);

Re: Elan SC520 - problem with MTD

[David Woodhouse]

vipin.malik@daniel.com said:
>  Anywhy, why I bring this is up, there is a *nasty* surprise waiting
> for folks that use the default address of 0x8400000 as programmed by
> the BIOS shipped with the board.

OK, so it's likely that the two drivers use different addresses just 
because they expect the board to have been set up differently? Is it 
possible to read the current values of these registers and ioremap() 
accordingly? Then we can make it a config option to reprogram them to a 
sane address. 

--
dwmw2




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

Re: Elan SC520 - problem with MTD

[Vipin Malik]

David Woodhouse wrote:

> vipin.malik@daniel.com said:
> >  Anywhy, why I bring this is up, there is a *nasty* surprise waiting
> > for folks that use the default address of 0x8400000 as programmed by
> > the BIOS shipped with the board.
>
> OK, so it's likely that the two drivers use different addresses just
> because they expect the board to have been set up differently? Is it
> possible to read the current values of these registers and ioremap()
> accordingly? Then we can make it a config option to reprogram them to a
> sane address.

Well, that's assuming that the same regs are used by the different boot
utilities to
decode the FLASH banks. There are 15 different regs to do this job. You
can use any 2!

I guess that it could be done, you run though all 15 and (looking at the
bits) first figure out which
reg is used for the FLASH CS, then which address it's decoding the flash
at.

Urgh!

In a proper system, the physmap.c file is *not* the place to setup
chipselect registers. Like I said,
what I did was a hack to work around some work done by a hardware
challenged software guy ;)

Maybe just the warning that this funny business is going on and some
sample code, normally commented out,
to "fix it"?

Then when one, does one's own init routine and boots straight from flash,
they would have init the FLASH CS registers
to the proper place anyway so one wouldn't need to do this stuff in this
file anyway.

Vipin


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



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

Re: Elan SC520 - problem with MTD

[David Woodhouse]

vipin.malik@daniel.com said:
> Well, that's assuming that the same regs are used by the different
> boot utilities to decode the FLASH banks. There are 15 different regs
> to do this job. You can use any 2!

> I guess that it could be done, you run though all 15 and (looking at
> the bits) first figure out which reg is used for the FLASH CS, then
> which address it's decoding the flash at.

> Urgh!

OK, I wish I hadn't asked now :)

I think I'm just going to stick my head in the sand on this one and accept 
what I'm given. It's just a leafnode driver, and I really can't keep 
track of them all unless they're doing something particularly naughty.

If AMD see fit to provide me with a new map driver and an explanation of 
why it either obsoletes or complements the existing one, I'll include it.

--
dwmw2




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

Re: Elan SC520 - problem with MTD

[Robert Kaiser]

Hi David,

On Mit, 18 Apr 2001 you wrote:
> I think I'm just going to stick my head in the sand on this one and accept 
> what I'm given. It's just a leafnode driver, and I really can't keep 
> track of them all unless they're doing something particularly naughty.

FYI, I have just checked in a new version of the sc520cdp.c mapping that
does the PAR reprogramming as suggested by Vipin. The old behavior (i.e.
keep the weird mapping setup by the BIOS) is still available by commenting
out a single line. (I decided against a config option for this).

Cheers

Rob


----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


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

Re: Elan SC520 - problem with MTD

[Robert Kaiser]

On Die, 17 Apr 2001 you wrote:
> OK, so it's likely that the two drivers use different addresses just 
> because they expect the board to have been set up differently? 

[Assuming by the "two drivers" you mean the e520.c file by AMD and my
 sc520cdp.c in MTD CVS]

Probably not: The e520.c expects the flash at physical address 0x2000000,
where the SC520 CDP board potentially has RAM.

Rob


----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


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

Re: Elan SC520 - problem with MTD

[Robert Kaiser]

Hi Vipin,

On Die, 17 Apr 2001 you wrote:
> 
> This is the board that I am working with myself. I've got this working for
> quite a while and have sent
> my "physmap.c" file to a few folks personally (that's the original physmap.c
> file from CVS hacked for the SC520 CDP- this was before there was
> a physmap file in CVS for this board.)
> 
> [snip]
>
> I suggest that whoever checked the sc520cdp.c file into CVS,

.. That would be me ...

>,at the very least
> pick up the above comments
> and include them as a warning, even if they don't want to reprogram the PAR at
> the new and proper address

Sorry, I wasn't aware of your work in this area when I wrote sc520cdp.c and
decided to contribute it. My main goal was to use the flash for a JFFS
filesystem, so this strange mapping used by the BIOS wasn't a problem for me.

> (I suggest that we reprogram the PAR regs).

I tend to agree, though the fact that we are deviating from the BIOS's
configuration this way makes me wonder if there should be a config option
for it. OTOH, MTD already has more than enough config options already
and I'm hesitant to add another one. (Just try to imagine how to write a
one-paragraph entry for Configure.help to explain to people what this option
does without scaring them away).

Rob


----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


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

Re: Elan SC520 - problem with MTD

[Vipin Malik]

Robert Kaiser wrote:

> Hi Vipin,
>
> On Die, 17 Apr 2001 you wrote:
> >
> > This is the board that I am working with myself. I've got this working for
> > quite a while and have sent
> > my "physmap.c" file to a few folks personally (that's the original physmap.c
> > file from CVS hacked for the SC520 CDP- this was before there was
> > a physmap file in CVS for this board.)
> >
> > [snip]
> >
> > I suggest that whoever checked the sc520cdp.c file into CVS,
>
> .. That would be me ...
>
> >,at the very least
> > pick up the above comments
> > and include them as a warning, even if they don't want to reprogram the PAR at
> > the new and proper address
>
> Sorry, I wasn't aware of your work in this area when I wrote sc520cdp.c and
> decided to contribute it.

No problem. The fault was mine, that I did not do what you did in the first place
(i.e. make a
board specific file and check it in). Thanks for doing that.


> My main goal was to use the flash for a JFFS
> filesystem, so this strange mapping used by the BIOS wasn't a problem for me.

If you *always* access the FLASH banks after the board has been init by the BIOS,
then
you will never know that this insanity is going on, as it is behind the scenes and
completely transparent.

I ran into this problem, when I tried to init the flash manually while I had booted
a full Linux
system from the BIOS, then removed the BIOS and tried to boot the kernel (stored
into the flash
in the above step), directly from the FLASH bank0. This time, there was some
*other* custom code
that init the processor (and the PAR registers) and mapped the FLASH banks to a
more sensible address.


>
>
> > (I suggest that we reprogram the PAR regs).
>
> I tend to agree, though the fact that we are deviating from the BIOS's
> configuration this way makes me wonder if there should be a config option
> for it. OTOH, MTD already has more than enough config options already
> and I'm hesitant to add another one. (Just try to imagine how to write a
> one-paragraph entry for Configure.help to explain to people what this option
> does without scaring them away).

On further thought, I think that at the very least we should include a
"Warning" regarding
this issue in the sc520cdp.c file and include the PAR register setting code- albeit
commented out,
as an example.

I agree that we should NOT have a config option for this issue.

Vipin

>
>
> Rob
>
> ----------------------------------------------------------------
> Robert Kaiser                         email: rkaiser@sysgo.de
> SYSGO RTS GmbH
> Am Pfaffenstein 14                    phone: (49) 6136 9948-762
> D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10



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