From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14nEms-00048m-00 for mtd-list@infradead.org; Wed, 11 Apr 2001 08:11:34 +0100 Received: from h154.195-230-144.ukrpack.net ([195.230.144.154] helo=srv1.lrpeople.com) by infradead.org with esmtp (Exim 3.20 #2) id 14nEmq-00048g-00 for mtd@infradead.org; Wed, 11 Apr 2001 08:11:33 +0100 Message-ID: <00ae01c0c24e$5b566480$4d02010a@lrpeople.com> From: "Alexander Melichenko" To: Subject: Elan SC520 - problem with MTD Date: Wed, 11 Apr 2001 10:12:16 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01C0C26F.E25EDCC0" Sender: owner-mtd@infradead.org List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00AB_01C0C26F.E25EDCC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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=20 #cat zFlashImage > /dev/mtd0 I see the message : bash: /dev/mtd0: No such device =20 During booting I see following messages : AMD Elan SC520 flash mapping: 1000000 at 4800000=20 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. =20 How can I solve this problem? Thanks for any help. Alexander Melichenko. ------=_NextPart_000_00AB_01C0C26F.E25EDCC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello!
We use Elan SC520 CDP = Rev.1.3.
I have=20 linux-2.2.18 (on hard drive) with MTD support. I use MTD MAKEDEV = script to=20 make MTD devices. I want to place kernel image into flash. But when I do =
#cat zFlashImage > /dev/mtd0
I see the message : bash:=20 /dev/mtd0: No such device

During booting I see following = messages=20 :
AMD Elan SC520 flash mapping: 1000000 at 4800000
mapped = physical memory=20 to c4800000
Elan SC520 Physically mapped flash: Found no CFI device = at=20 location zero
JFFS version 1.0, (C) 1999, 2000 Axis Communications=20 AB

When I inspect directory /proc I = see 2 (!!!)=20 files mtd with no information about MTD devices.

How can I = solve=20 this problem?

Thanks for any help.
Alexander=20 Melichenko.

------=_NextPart_000_00AB_01C0C26F.E25EDCC0-- To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14nK1Q-0005Yi-00 for mtd-list@infradead.org; Wed, 11 Apr 2001 13:46:56 +0100 Received: from ns.sysgo.de ([213.68.67.98] helo=rob.devdep.sysgo.de) by infradead.org with esmtp (Exim 3.20 #2) id 14nK1H-0005Yb-00 for mtd@infradead.org; Wed, 11 Apr 2001 13:46:54 +0100 From: Robert Kaiser Reply-To: rob@sysgo.de To: "Alexander Melichenko" Subject: Re: Elan SC520 - problem with MTD Date: Wed, 11 Apr 2001 14:22:59 +0200 Content-Type: text/plain References: <00ae01c0c24e$5b566480$4d02010a@lrpeople.com> In-Reply-To: <00ae01c0c24e$5b566480$4d02010a@lrpeople.com> Cc: MIME-Version: 1.0 Message-Id: <01041114460500.00396@rob> Content-Transfer-Encoding: 8bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14nLij-0006Qi-00 for mtd-list@infradead.org; Wed, 11 Apr 2001 15:35:45 +0100 Received: from mail1.danielind.com ([12.19.96.6]) by infradead.org with esmtp (Exim 3.20 #2) id 14nLih-0006P8-00 for mtd@infradead.org; Wed, 11 Apr 2001 15:35:44 +0100 Message-ID: <3AD46B4D.56D713A6@danielind.com> Date: Wed, 11 Apr 2001 09:33:49 -0500 From: Vipin Malik MIME-Version: 1.0 To: Alexander Melichenko CC: rob@sysgo.de, mtd@infradead.org Subject: Re: Elan SC520 - problem with MTD References: <00ae01c0c24e$5b566480$4d02010a@lrpeople.com> <01041114460500.00396@rob> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14naV2-0004kj-00 for mtd-list@infradead.org; Thu, 12 Apr 2001 07:22:36 +0100 Received: from h154.195-230-144.ukrpack.net ([195.230.144.154] helo=srv1.lrpeople.com) by infradead.org with esmtp (Exim 3.20 #2) id 14naV0-0004kd-00 for mtd@infradead.org; Thu, 12 Apr 2001 07:22:35 +0100 Message-ID: <002901c0c310$aa21aa80$4d02010a@lrpeople.com> From: "Alexander Melichenko" To: Cc: References: <00ae01c0c24e$5b566480$4d02010a@lrpeople.com> <01041114460500.00396@rob> Subject: Re: Elan SC520 - problem with MTD Date: Thu, 12 Apr 2001 09:23:10 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14p5P9-0005Kj-00 for mtd-list@infradead.org; Mon, 16 Apr 2001 10:34:43 +0100 Received: from h154.195-230-144.ukrpack.net ([195.230.144.154] helo=srv1.lrpeople.com) by infradead.org with esmtp (Exim 3.20 #2) id 14p5P7-0005Kd-00 for mtd@infradead.org; Mon, 16 Apr 2001 10:34:42 +0100 Message-ID: <003d01c0c650$2a262480$4d02010a@lrpeople.com> From: "Alexander Melichenko" To: References: Subject: Re: Elan SC520 - problem with MTD Date: Mon, 16 Apr 2001 12:35:17 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14pVhc-0000UW-00 for mtd-list@infradead.org; Tue, 17 Apr 2001 14:39:32 +0100 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237] helo=passion.cambridge.redhat.com) by infradead.org with esmtp (Exim 3.20 #2) id 14pVhb-0000UQ-00 for mtd@infradead.org; Tue, 17 Apr 2001 14:39:31 +0100 From: David Woodhouse In-Reply-To: <002901c0c310$aa21aa80$4d02010a@lrpeople.com> References: <002901c0c310$aa21aa80$4d02010a@lrpeople.com> <00ae01c0c24e$5b566480$4d02010a@lrpeople.com> <01041114460500.00396@rob> To: "Alexander Melichenko" Cc: rob@sysgo.de, mtd@infradead.org Subject: Re: Elan SC520 - problem with MTD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Apr 2001 14:38:47 +0100 Message-ID: <19294.987514727@redhat.com> Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14pVtL-0000Xu-00 for mtd-list@infradead.org; Tue, 17 Apr 2001 14:51:39 +0100 From: Robert Kaiser Reply-To: rob@sysgo.de To: David Woodhouse Subject: Re: Elan SC520 - problem with MTD Date: Tue, 17 Apr 2001 15:42:31 +0200 Content-Type: text/plain References: <002901c0c310$aa21aa80$4d02010a@lrpeople.com> <01041114460500.00396@rob> <19294.987514727@redhat.com> In-Reply-To: <19294.987514727@redhat.com> Cc: "Alexander Melichenko" , mtd@infradead.org MIME-Version: 1.0 Message-Id: <01041715513200.02005@rob> Content-Transfer-Encoding: 8bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14pVwK-0000Yg-00 for mtd-list@infradead.org; Tue, 17 Apr 2001 14:54:44 +0100 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237] helo=passion.cambridge.redhat.com) by infradead.org with esmtp (Exim 3.20 #2) id 14pVwJ-0000Ya-00 for mtd@infradead.org; Tue, 17 Apr 2001 14:54:43 +0100 From: David Woodhouse In-Reply-To: <01041715513200.02005@rob> References: <01041715513200.02005@rob> <002901c0c310$aa21aa80$4d02010a@lrpeople.com> <01041114460500.00396@rob> <19294.987514727@redhat.com> To: rob@sysgo.de Cc: "Alexander Melichenko" , mtd@infradead.org, mark.langsdorf@amd.com Subject: Re: Elan SC520 - problem with MTD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Apr 2001 14:54:31 +0100 Message-ID: <20801.987515671@redhat.com> Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14pW4O-0000db-00 for mtd-list@infradead.org; Tue, 17 Apr 2001 15:03:04 +0100 From: Robert Kaiser Reply-To: rob@sysgo.de To: David Woodhouse Subject: Re: Elan SC520 - problem with MTD Date: Tue, 17 Apr 2001 15:58:04 +0200 Content-Type: text/plain References: <01041715513200.02005@rob> <19294.987514727@redhat.com> <20801.987515671@redhat.com> In-Reply-To: <20801.987515671@redhat.com> Cc: "Alexander Melichenko" , mtd@infradead.org, mark.langsdorf@amd.com MIME-Version: 1.0 Message-Id: <01041716025800.02061@rob> Content-Transfer-Encoding: 8bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14pW9T-0000fw-00 for mtd-list@infradead.org; Tue, 17 Apr 2001 15:08:19 +0100 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237] helo=passion.cambridge.redhat.com) by infradead.org with esmtp (Exim 3.20 #2) id 14pW9S-0000fq-00 for mtd@infradead.org; Tue, 17 Apr 2001 15:08:18 +0100 From: David Woodhouse In-Reply-To: <01041716025800.02061@rob> References: <01041716025800.02061@rob> <01041715513200.02005@rob> <19294.987514727@redhat.com> <20801.987515671@redhat.com> To: rob@sysgo.de Cc: "Alexander Melichenko" , mtd@infradead.org, mark.langsdorf@amd.com Subject: Re: Elan SC520 - problem with MTD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Apr 2001 15:08:11 +0100 Message-ID: <22300.987516491@redhat.com> Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14pXUv-0001jB-00 for mtd-list@infradead.org; Tue, 17 Apr 2001 16:34:33 +0100 Message-ID: <3ADC62AE.66B350ED@daniel.com> Date: Tue, 17 Apr 2001 10:35:10 -0500 From: Vipin Malik MIME-Version: 1.0 To: David Woodhouse CC: rob@sysgo.de, Alexander Melichenko , mtd@infradead.org, mark.langsdorf@amd.com Subject: Re: Elan SC520 - problem with MTD References: <01041716025800.02061@rob> <01041715513200.02005@rob> <19294.987514727@redhat.com> <20801.987515671@redhat.com> <22300.987516491@redhat.com> Content-Type: multipart/mixed; boundary="------------065AE57C6FF570C311B26891" Sender: owner-mtd@infradead.org List-ID: This is a multi-part message in MIME format. --------------065AE57C6FF570C311B26891 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 --------------065AE57C6FF570C311B26891 Content-Type: text/plain; charset=us-ascii; name="physmap.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="physmap.c" /* * 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 #include #include #include #include #include #include #include #include /* 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); --------------065AE57C6FF570C311B26891-- To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14pYLy-0002br-00 for mtd-list@infradead.org; Tue, 17 Apr 2001 17:29:22 +0100 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237] helo=passion.cambridge.redhat.com) by infradead.org with esmtp (Exim 3.20 #2) id 14pYLx-0002bl-00 for mtd@infradead.org; Tue, 17 Apr 2001 17:29:21 +0100 From: David Woodhouse In-Reply-To: <3ADC62AE.66B350ED@daniel.com> References: <3ADC62AE.66B350ED@daniel.com> <01041716025800.02061@rob> <01041715513200.02005@rob> <19294.987514727@redhat.com> <20801.987515671@redhat.com> <22300.987516491@redhat.com> To: Vipin Malik Cc: rob@sysgo.de, Alexander Melichenko , mtd@infradead.org, mark.langsdorf@amd.com Subject: Re: Elan SC520 - problem with MTD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Apr 2001 17:26:04 +0100 Message-ID: <5360.987524764@redhat.com> Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14pYd8-0002rC-00 for mtd-list@infradead.org; Tue, 17 Apr 2001 17:47:06 +0100 Message-ID: <3ADC73B1.1960BC87@daniel.com> Date: Tue, 17 Apr 2001 11:47:45 -0500 From: Vipin Malik MIME-Version: 1.0 To: David Woodhouse CC: rob@sysgo.de, Alexander Melichenko , mtd@infradead.org, mark.langsdorf@amd.com Subject: Re: Elan SC520 - problem with MTD References: <3ADC62AE.66B350ED@daniel.com> <01041716025800.02061@rob> <01041715513200.02005@rob> <19294.987514727@redhat.com> <20801.987515671@redhat.com> <22300.987516491@redhat.com> <5360.987524764@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14pdmK-0007Af-00 for mtd-list@infradead.org; Tue, 17 Apr 2001 23:16:56 +0100 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237] helo=passion.cambridge.redhat.com) by infradead.org with esmtp (Exim 3.20 #2) id 14pdmI-0007AZ-00 for mtd@infradead.org; Tue, 17 Apr 2001 23:16:55 +0100 From: David Woodhouse In-Reply-To: <3ADC73B1.1960BC87@daniel.com> References: <3ADC73B1.1960BC87@daniel.com> <3ADC62AE.66B350ED@daniel.com> <01041716025800.02061@rob> <01041715513200.02005@rob> <19294.987514727@redhat.com> <20801.987515671@redhat.com> <22300.987516491@redhat.com> <5360.987524764@redhat.com> To: Vipin Malik Cc: rob@sysgo.de, Alexander Melichenko , mtd@infradead.org, mark.langsdorf@amd.com Subject: Re: Elan SC520 - problem with MTD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Apr 2001 23:16:35 +0100 Message-ID: <10578.987545795@redhat.com> Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14psD6-00059x-00 for mtd-list@infradead.org; Wed, 18 Apr 2001 14:41:32 +0100 From: Robert Kaiser Reply-To: rob@sysgo.de To: Vipin Malik Subject: Re: Elan SC520 - problem with MTD Date: Wed, 18 Apr 2001 15:14:56 +0200 Content-Type: text/plain References: <01041716025800.02061@rob> <22300.987516491@redhat.com> <3ADC62AE.66B350ED@daniel.com> In-Reply-To: <3ADC62AE.66B350ED@daniel.com> Cc: David Woodhouse , Alexander Melichenko , mtd@infradead.org MIME-Version: 1.0 Message-Id: <01041815411600.00407@rob> Content-Transfer-Encoding: 8bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14psVv-0005Po-00 for mtd-list@infradead.org; Wed, 18 Apr 2001 15:00:59 +0100 From: Robert Kaiser Reply-To: rob@sysgo.de To: David Woodhouse Subject: Re: Elan SC520 - problem with MTD Date: Wed, 18 Apr 2001 15:50:43 +0200 Content-Type: text/plain References: <3ADC62AE.66B350ED@daniel.com> <22300.987516491@redhat.com> <5360.987524764@redhat.com> In-Reply-To: <5360.987524764@redhat.com> Cc: Vipin Malik , Alexander Melichenko , mtd@infradead.org, mark.langsdorf@amd.com MIME-Version: 1.0 Message-Id: <01041816004001.00407@rob> Content-Transfer-Encoding: 8bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14puS3-0006e1-00 for mtd-list@infradead.org; Wed, 18 Apr 2001 17:05:07 +0100 Message-ID: <3ADDBB5E.1ADE4AC1@daniel.com> Date: Wed, 18 Apr 2001 11:05:50 -0500 From: Vipin Malik MIME-Version: 1.0 To: rob@sysgo.de CC: David Woodhouse , Alexander Melichenko , mtd@infradead.org Subject: Re: Elan SC520 - problem with MTD References: <01041716025800.02061@rob> <22300.987516491@redhat.com> <3ADC62AE.66B350ED@daniel.com> <01041815411600.00407@rob> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14qJ40-0003HR-00 for mtd-list@infradead.org; Thu, 19 Apr 2001 19:21:56 +0100 From: Robert Kaiser Reply-To: rob@sysgo.de To: David Woodhouse Subject: Re: Elan SC520 - problem with MTD Date: Thu, 19 Apr 2001 20:11:18 +0200 Content-Type: text/plain References: <3ADC73B1.1960BC87@daniel.com> <5360.987524764@redhat.com> <10578.987545795@redhat.com> In-Reply-To: <10578.987545795@redhat.com> Cc: Vipin Malik , Alexander Melichenko , mtd@infradead.org, mark.langsdorf@amd.com MIME-Version: 1.0 Message-Id: <01041920213500.03722@rob> Content-Transfer-Encoding: 8bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14rdwO-0003x9-00 for mtd-list@infradead.org; Mon, 23 Apr 2001 11:51:36 +0100 Received: from ns.sysgo.de ([213.68.67.98] helo=rob.devdep.sysgo.de) by infradead.org with esmtp (Exim 3.20 #2) id 14rdwM-0003x3-00 for mtd@infradead.org; Mon, 23 Apr 2001 11:51:34 +0100 From: Robert Kaiser Reply-To: rob@sysgo.de To: "Alexander Melichenko" Subject: Re: Elan SC520 - problem with MTD Date: Mon, 23 Apr 2001 11:59:48 +0200 Content-Type: text/plain References: <01041713245700.01481@rob> <005801c0cbd3$2bdb3c60$4d02010a@lrpeople.com> In-Reply-To: <005801c0cbd3$2bdb3c60$4d02010a@lrpeople.com> Cc: mtd@infradead.org MIME-Version: 1.0 Message-Id: <01042312512000.00451@rob> Content-Transfer-Encoding: 8bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14rg7Y-00052s-00 for mtd-list@infradead.org; Mon, 23 Apr 2001 14:11:16 +0100 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237] helo=passion.cambridge.redhat.com) by infradead.org with esmtp (Exim 3.20 #2) id 14rg7X-00052m-00 for mtd@infradead.org; Mon, 23 Apr 2001 14:11:16 +0100 From: David Woodhouse In-Reply-To: <01042312512000.00451@rob> References: <01042312512000.00451@rob> <01041713245700.01481@rob> <005801c0cbd3$2bdb3c60$4d02010a@lrpeople.com> To: rob@sysgo.de Cc: "Alexander Melichenko" , mtd@infradead.org Subject: Re: Elan SC520 - problem with MTD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Apr 2001 14:10:38 +0100 Message-ID: <6654.988031438@redhat.com> Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14rgk1-0005Sq-00 for mtd-list@infradead.org; Mon, 23 Apr 2001 14:51:01 +0100 Received: from mailserver.arcom.co.uk ([194.200.159.162]) by infradead.org with esmtp (Exim 3.20 #2) id 14rgjp-0005Sk-00 for mtd@infradead.org; Mon, 23 Apr 2001 14:50:49 +0100 From: "Alex Lennon" To: , "Alexander Melichenko" Cc: Subject: RE: Elan SC520 - problem with MTD Date: Mon, 23 Apr 2001 14:45:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <01042312512000.00451@rob> Sender: owner-mtd@infradead.org List-ID: >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14rh8c-0005kW-00 for mtd-list@infradead.org; Mon, 23 Apr 2001 15:16:26 +0100 Received: from ns.sysgo.de ([213.68.67.98] helo=rob.devdep.sysgo.de) by infradead.org with esmtp (Exim 3.20 #2) id 14rh8Z-0005kO-00 for mtd@infradead.org; Mon, 23 Apr 2001 15:16:24 +0100 From: Robert Kaiser Reply-To: rob@sysgo.de To: "Alex Lennon" Subject: RE: Elan SC520 - problem with MTD Date: Mon, 23 Apr 2001 15:54:52 +0200 Content-Type: text/plain References: In-Reply-To: Cc: MIME-Version: 1.0 Message-Id: <01042316161301.01109@rob> Content-Transfer-Encoding: 8bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14rhMl-0005to-00 for mtd-list@infradead.org; Mon, 23 Apr 2001 15:31:03 +0100 Received: from mailserver.arcom.co.uk ([194.200.159.162]) by infradead.org with esmtp (Exim 3.20 #2) id 14rhMk-0005ti-00 for mtd@infradead.org; Mon, 23 Apr 2001 15:31:02 +0100 From: "Alex Lennon" To: Cc: Subject: RE: Elan SC520 - problem with MTD Date: Mon, 23 Apr 2001 15:26:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <01042316161301.01109@rob> Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14rhjm-00069l-00 for mtd-list@infradead.org; Mon, 23 Apr 2001 15:54:50 +0100 Received: from ns.sysgo.de ([213.68.67.98] helo=rob.devdep.sysgo.de) by infradead.org with esmtp (Exim 3.20 #2) id 14rhjk-00069f-00 for mtd@infradead.org; Mon, 23 Apr 2001 15:54:49 +0100 From: Robert Kaiser Reply-To: rob@sysgo.de To: "Alex Lennon" Subject: RE: Elan SC520 - problem with MTD Date: Mon, 23 Apr 2001 16:43:00 +0200 Content-Type: text/plain References: In-Reply-To: Cc: MIME-Version: 1.0 Message-Id: <01042316543802.01109@rob> Content-Transfer-Encoding: 8bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14rpPx-0002Vh-00 for mtd-list@infradead.org; Tue, 24 Apr 2001 00:06:53 +0100 Received: from mail1.danielind.com ([12.19.96.6]) by infradead.org with esmtp (Exim 3.20 #2) id 14rpPl-0002Ux-00 for mtd@infradead.org; Tue, 24 Apr 2001 00:06:42 +0100 Message-ID: <3AE4B5B3.26E340E8@daniel.com> Date: Mon, 23 Apr 2001 18:07:32 -0500 From: Vipin Malik MIME-Version: 1.0 To: rob@sysgo.de CC: Alex Lennon , mtd@infradead.org, jffs-dev Subject: Re: Elan SC520 - problem with MTD References: <01042316543802.01109@rob> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14s0KZ-0005zU-00 for mtd-list@infradead.org; Tue, 24 Apr 2001 11:46:03 +0100 Received: from ns.sysgo.de ([213.68.67.98] helo=rob.devdep.sysgo.de) by infradead.org with esmtp (Exim 3.20 #2) id 14s0KW-0005zO-00 for mtd@infradead.org; Tue, 24 Apr 2001 11:46:00 +0100 From: Robert Kaiser Reply-To: rob@sysgo.de To: Vipin Malik Subject: Re: Elan SC520 - problem with MTD Date: Tue, 24 Apr 2001 09:56:26 +0200 Content-Type: text/plain References: <01042316543802.01109@rob> <3AE4B5B3.26E340E8@daniel.com> In-Reply-To: <3AE4B5B3.26E340E8@daniel.com> Cc: Alex Lennon , mtd@infradead.org, jffs-dev MIME-Version: 1.0 Message-Id: <01042412450101.00394@rob> Content-Transfer-Encoding: 8bit Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14s1xt-00076H-00 for mtd-list@infradead.org; Tue, 24 Apr 2001 13:30:45 +0100 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237] helo=passion.cambridge.redhat.com) by infradead.org with esmtp (Exim 3.20 #2) id 14s1xf-00076B-00 for mtd@infradead.org; Tue, 24 Apr 2001 13:30:36 +0100 From: David Woodhouse In-Reply-To: <01042412450101.00394@rob> References: <01042412450101.00394@rob> <01042316543802.01109@rob> <3AE4B5B3.26E340E8@daniel.com> To: rob@sysgo.de Cc: Vipin Malik , Alex Lennon , mtd@infradead.org, jffs-dev , linuxbios@lanl.gov Subject: Re: Elan SC520 - problem with MTD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Apr 2001 13:28:58 +0100 Message-ID: <18549.988115338@redhat.com> Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14s3Tv-00087F-00 for mtd-list@infradead.org; Tue, 24 Apr 2001 15:07:55 +0100 Date: Tue, 24 Apr 2001 08:07:38 -0600 (MDT) From: Ronald G Minnich To: David Woodhouse cc: rob@sysgo.de, Vipin Malik , Alex Lennon , mtd@infradead.org, jffs-dev , linuxbios@lanl.gov Subject: Re: Elan SC520 - problem with MTD In-Reply-To: <18549.988115338@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mtd@infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.20 #2) id 14sqRL-0004OY-00 for mtd-list@infradead.org; Thu, 26 Apr 2001 19:24:31 +0100 Received: from amdext2.amd.com ([163.181.251.1]) by infradead.org with esmtp (Exim 3.20 #2) id 14sqRE-0004OS-00 for mtd@infradead.org; Thu, 26 Apr 2001 19:24:25 +0100 From: mark.langsdorf@amd.com Message-ID: <0FA1031B65A9D111960900805F9FA8E103B9F3F5@txexmta8.amd.com> To: rob@sysgo.de, vipin.malik@daniel.com cc: ajlennon@arcom.co.uk, mtd@infradead.org, jffs-dev@axis.com Subject: RE: Elan SC520 - problem with MTD Date: Thu, 26 Apr 2001 13:23:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-mtd@infradead.org List-ID: 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