From mboxrd@z Thu Jan 1 00:00:00 1970 From: Abbas Dadabhoy Date: Tue, 04 May 2004 11:26:11 -0700 Subject: [U-Boot-Users] Re: U-Boot-Users digest, Vol 1 #739 - 10 msgs References: Message-ID: <4097E043.79422A39@aristoslogic.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Please remove u-boot-users-request at lists.sourceforge.net wrote: > Send U-Boot-Users mailing list submissions to > u-boot-users at lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/u-boot-users > or, via email, send a message with subject or body 'help' to > u-boot-users-request at lists.sourceforge.net > > You can reach the person managing the list at > u-boot-users-admin at lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of U-Boot-Users digest..." > > Today's Topics: > > 1. Re: [Newbie help] Motorola Board with GT64260 (Oliver Korpilla) > 2. Re: [Newbie help] Motorola Board with GT64260 (Wolfgang Denk) > 3. Re: Configuration System (Brian Waite) > 4. [Patch]New board support : lite_dw (=?gb2312?q?Sam=20Song?=) > 5. RE: New NAND code draft (Dave Ellis) > 6. Re: [Patch]New board support : lite_dw (Wolfgang Denk) > 7. Re: Configuration System (Wolfgang Denk) > 8. Dual-Port SRAM (Bob White) > 9. Re: Dual-Port SRAM (Wolfgang Denk) > 10. Re: [Patch]New board support : lite_dw (=?gb2312?q?Sam=20Song?=) > > --__--__-- > > Message: 1 > Date: Mon, 03 May 2004 11:46:14 +0200 > From: Oliver Korpilla > To: Mike McCullough > CC: Wolfgang Denk , > u-boot-users > Subject: Re: [U-Boot-Users] [Newbie help] Motorola Board with GT64260 > > Mike McCullough wrote: > >> > >> BTW: MCC Systems sells a "Linux SDK" which includes a port of U-Boot > >> to the MVME5500 board (see http://www.mccengineering.com/linuxsdks.htm) > > > > > > Actually, MCC does NOT have a port of U-boot to the Motorola 5500 board > > as we used the onboard MOTload software instead. Since MOTLoad worked > > just fine for us (once we figured it out) we didn't do the U-Boot port. > > > > MotLoad actually netboots fine, but AFAIK it doesn't boot from flash (a > capability I already have gladly exploited with the MVME2100 and the > PPCbug). While it seems that a lot of setups often seem to be perfectly > ok with a netboot (which seems to be very popular with VxWorks as well), > for my setup a flash boot setup would really be the better choice - > especially since on the MVME5500 flash is an abundant resource: 32-40MB > are more than enough for a really nice root filesystem, don't you think? > (I've not even ran out of the 4MB on the MVME2100 by now - thanks, > uClibc and BusyBox!!!) > > >> Maybe we should start a "black list" of companies who don't give > >> their patches back to the public source tree. > > > > Well, everything that we list on our Web site is freely available. You > > just have to do the same amount of hunting (and integration!) that MCC did. > > > > I'm not fond of black-listing myself. Isn't that what big companies do?? > > > > Well, as long as the Linux vendors either hide their Linux kernels, or > release only trimmed down versions of them (and no patchset), I guess > the bootloader is not the worst problem - ok, ok, of course to people on > this list this is actually an issue at heart!! But with all the closed > mailing lists, and proprietary patchsets for customers only, open-source > projects seem to be pretty much to be on the exploited side of the deal > to me. :( > > This is of course a general comment, and not about your special SDK > vendor, which I have no experience with yet! > > Thanks, and with kind regards, > Oliver Korpilla > > --__--__-- > > Message: 2 > To: Mike McCullough > Cc: okorpil at fh-landshut.de, > u-boot-users > Subject: Re: [U-Boot-Users] [Newbie help] Motorola Board with GT64260 > From: Wolfgang Denk > Date: Mon, 03 May 2004 12:23:42 +0200 > > In message <5.1.0.14.2.20040502213935.0129c038@pop3.ttlc.net> you wrote: > > > > Actually, MCC does NOT have a port of U-boot to the Motorola 5500 board as > > we used the onboard MOTload software instead. Since MOTLoad worked just > > fine for us (once we figured it out) we didn't do the U-Boot port. > > You're right. I didn't read the page carefully enough. Sorry for the > confusion. > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de > Pig: An animal (Porcus omnivorous) closely allied to the human race > by the splendor and vivacity of its appetite, which, however, is in- > ferior in scope, for it balks at pig. - Ambrose Bierce > > --__--__-- > > Message: 3 > From: Brian Waite > To: u-boot-users at lists.sourceforge.net > Subject: Re: [U-Boot-Users] Configuration System > Date: Mon, 3 May 2004 07:05:57 -0400 > > =2D----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday 30 April 2004 07:19 pm, Wolfgang Denk wrote: > > > > I definitely don't want to have to add 25 new files with meta- or > > > > config data just to get my job done. > > > > > > I don't think it will take that at all. Maybe a couple 2 or 3? > > > > Ummm... is you add only 3 files, you will have at least one monster > > of a config file which nobody will be able to understand nor > > maintain. > > > =46irst, let me say I don't find the configurator that we are talking about= > all=20 > the helpful to my work, but I think I might have a solution that will reduc= > e=20 > the maintainability. So what I was thinking about was using the maintainers= > =20 > file along with a configurator script in the tools directory. The=20 > configurator would be all the smarts. It would read the MAINTAINERS file, = > =20 > which has the bits in a well-defined structure, and generate the views with= > =20 > some type of filtering. So you could say "Show me all boards supporting CPU= > =20 > xyz" or "Show me all boards supported by CPU xyz". The obvioous final step = > of=20 > the configurator is "make " > > Here are the pros and cons I see to this: > > PROS:=20 > * The only new files are specificaly for the configurator and only need be= > =20 > modified to fix the configurator. > * Only the people interested in the system need to know about it. > * Automatically updated with each supported board. > * Minimal added work for Wolfgang. > * It can be extracted from the tree and maintained on the side until Wolfga= > ng=20 > has the time to review and appove it. > * No one other then the interested parties has to do anything other than ad= > d=20 > their board to the MAINTAINERS list to work in u-boot. > * It does not preclude the make well known system. > * Many others I am sure :) > > CONS: > * More files in the u-boot tree. > * The configurator itself becomes somewhat complex. > * Many others I am sure :) > > Jon, Wolfgang what are your thoughts on a system like this?=20 > > Thanks > Brian > =2D----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQFAlieVmxLCz0u+Ko8RAtc2AJ9kwRymVMYLSTs09ENX7OZBBQOGuACfeRM9 > IEsWwBilha9w46iUmnqrURw=3D > =3D7yQG > =2D----END PGP SIGNATURE----- > > --__--__-- > > Message: 4 > Date: Mon, 3 May 2004 23:58:16 +0800 (CST) > From: =?gb2312?q?Sam=20Song?= > To: wd at denx.de > Cc: u-boot-users at lists.sourceforge.net > Subject: [U-Boot-Users] [Patch]New board support : lite_dw > > Dear Mr. Wolfgang, > > Before sending the patch,I need to consult with you a > couple of points.First is the new board name.I prefer > to give a new name,lite_dw.Actually,it is DW version > of RPXlite board but have three differences with CW > version,which was ported by Yoo. Jonghoon. > > Board CPU SDRAM FLASH > CW[u-boot] MPC850 16MB 4MB > DW[On my hand] MPC823e 64MB 16MB > > So the possible name could be RPXlite_DW or lite_dw.In > Linux kernel tree,it can be found as RPXlite_DW.But I > add some new features for this board,a software > development platform of EmbeddedPlanet Co. > > Secondly,I'd like to support the following features on > this board for the moment. > 1. LCD panel support; > 2. 64MHz/48MHz system clock options; > 3. ENV_IS_IN_FLASH/ENV_IS_IN_NVRAM; > > Any suggestion? > > Best regards, > > Sam > > _________________________________________________________ > Do You Yahoo!? > ????TT???????????????????????? > http://cn.rd.yahoo.com/mail_cn/tag/SIG=1402c0to2/**http%3A%2F%2Fhp.allyes.com%2Flaserjet%2Fgamestory%2Findex.html%3Fjumpid%3Dex_hphqapcn_MongooseLJ1010%2F201073CN407016%2FYahoo > > --__--__-- > > Message: 5 > Date: Mon, 3 May 2004 14:26:14 -0400 > From: "Dave Ellis" > To: "Pantelis Antoniou" > Cc: "U-Boot Users" > Subject: [U-Boot-Users] RE: New NAND code draft > > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01C4313C.1E2DA173 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Pantelis Antoniou wrote: > > In the attached patch you can see the progress of my work > > in the NAND rewrite. > >=20 > > This is not suitable for inclusion yet. > > I tried it with a flash with no bad blocks. With the > attached patch it worked for booting from JFFS2, and=20 > erasing/writing new JFFS2 images. My system copies > the boot partition to RAM and U-Boot's JFFS2 uses the > RAM copy. > > The patch just fixes my configuration file and makes=20 > cmd_nand.c build when CONFIG_MTD_NAND_UNSAFE is not defined. > > > Things that work now: > >=20 > > 1. Correct handling of bad blocks. > > I only tried a nand with no bad blocks. I'll simulate > some bad blocks when the read.jffs2 support is added. > > > 2. NAND boot works > > not tried > > > 4. Direct to NAND tftp/nfs support. > > not tried > > > Things that are probably borked: > >=20 > > 1. Multiple chip support (I don't have such hardware available > > and the previous code was kinda of unclear. > > not tried (I don't have the hardware either.) > > > 3. JFFS2 support although there is probably b0rken. > > 4. The read.xxx/write.xxx support is just not there yet. > > I need to be able to specify the range of NAND to read from > (like read.jffs2 does), then I will test the JFFS2 read/write > with bad blocks. > > Dave Ellis > > ------_=_NextPart_001_01C4313C.1E2DA173 > Content-Type: application/octet-stream; > name="nand-sixnet.diff" > Content-Transfer-Encoding: base64 > Content-Description: nand-sixnet.diff > Content-Disposition: attachment; > filename="nand-sixnet.diff" > > SW5kZXg6IGNvbW1vbi9jbWRfbmFuZC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 > PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvY3ZzL3Ut > Ym9vdC5zZi91LWJvb3QvdS1ib290L2NvbW1vbi9jbWRfbmFuZC5jLHYKcmV0cmlldmluZyByZXZp > c2lvbiAxLjE2CmRpZmYgLXAgLXUgLXIxLjE2IGNtZF9uYW5kLmMKLS0tIGNvbW1vbi9jbWRfbmFu > ZC5jCTMgTWF5IDIwMDQgMTQ6MTQ6MzUgLTAwMDAJMS4xNgorKysgY29tbW9uL2NtZF9uYW5kLmMJ > MyBNYXkgMjAwNCAxNDoxMjoyMiAtMDAwMApAQCAtMTE4NCw2ICsxMTg0LDE0IEBAIHN0YXRpYyBp > bnQgbmFuZF9tYWtlX2JpdF9lcnJvcihzdHJ1Y3QgbmEKIAogCXJldHVybiAwOwogfQorI2Vsc2UK > K3N0YXRpYyBpbnQgbmFuZF9tYXJrX2JhZF9zZWN0b3Ioc3RydWN0IG5hbmRfY2hpcCogbmFuZCwg > aW50IHNlY3RvcikKK3sKKyNpZmRlZiBOQU5EX0RFQlVHCisJcHJpbnRmKCJub3QgbWFya2luZyBz > ZWN0b3IgQDB4JTA4eCBhcyBiYWQuXG4iLCBzZWN0b3IpOworI2VuZGlmCisJcmV0dXJuIDA7Cit9 > CiAjZW5kaWYKIAogc3RhdGljIGludCBuYW5kX2VyYXNlKHN0cnVjdCBuYW5kX2NoaXAgKm5hbmQs > IGludCBvZnMsIGludCBsZW4sIGludCBjbGVhbikKSW5kZXg6IGluY2x1ZGUvY29uZmlncy9TWE5J > ODU1VC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 > PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvY3ZzL3UtYm9vdC5zZi91LWJvb3QvdS1i > b290L2luY2x1ZGUvY29uZmlncy9TWE5JODU1VC5oLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjQK > ZGlmZiAtcCAtdSAtcjEuNCBTWE5JODU1VC5oCi0tLSBpbmNsdWRlL2NvbmZpZ3MvU1hOSTg1NVQu > aAkxMCBTZXAgMjAwMyAyMjozMDo1NSAtMDAwMAkxLjQKKysrIGluY2x1ZGUvY29uZmlncy9TWE5J > ODU1VC5oCTMgTWF5IDIwMDQgMTQ6MTA6MTYgLTAwMDAKQEAgLTE2Miw2ICsxNjIsOCBAQAogI2Rl > ZmluZQlDRkdfSkZGUzJfUkFNU0laRSAweDIwMDAwMAkvKiBOQU5EIGJvb3QgcGFydGl0aW9uIGlz > IDJNaUIJKi8KIAogLyogTkFORCBmbGFzaCBzdXBwb3J0ICovCisjZGVmaW5lIENPTkZJR19KRkZT > Ml9OQU5ECisjZGVmaW5lIENPTkZJR19NVERfTkFORF9WRVJJRllfV1JJVEUKICNkZWZpbmUgQ09O > RklHX01URF9OQU5EX0VDQ19KRkZTMgogI2RlZmluZSBDRkdfTUFYX05BTkRfREVWSUNFCTEJLyog > TWF4IG51bWJlciBvZiBOQU5EIGRldmljZXMJKi8KICNkZWZpbmUgU0VDVE9SU0laRSA1MTIK > > ------_=_NextPart_001_01C4313C.1E2DA173-- > > --__--__-- > > Message: 6 > To: =?gb2312?q?Sam=20Song?= > Cc: u-boot-users at lists.sourceforge.net > Subject: Re: [U-Boot-Users] [Patch]New board support : lite_dw > From: Wolfgang Denk > Date: Mon, 03 May 2004 22:05:33 +0200 > > Dear Sam, > > in message <20040503155816.12658.qmail@web15203.mail.bjs.yahoo.com> you wrote: > > > > Before sending the patch,I need to consult with you a > > couple of points.First is the new board name.I prefer > > to give a new name,lite_dw.Actually,it is DW version > > Sorry, but there are too mane "lite" boards already. We need a more > distinctive name. > > > So the possible name could be RPXlite_DW or lite_dw.In > > Linux kernel tree,it can be found as RPXlite_DW.But I > > If the Linux kernel tree uses RPXlite_DW, then this is what we should > use, too. I think it is a very good idea to use the same name when- > ever possible. > > > Secondly,I'd like to support the following features on > > this board for the moment. > > 1. LCD panel support; > > This can be done as two build targets, like the TQM823L_config and > TQM823L_LCD_config. > > > 2. 64MHz/48MHz system clock options; > > If possible, make it automatically detect the clock frequency and > auto-adjust. Your users will praise you if the same binary image > works on both configurations. > > > 3. ENV_IS_IN_FLASH/ENV_IS_IN_NVRAM; > > Either make it a different build targets, or select a standard > configuration and let the user decide to modify the board config > file. > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de > Es ist nicht genug zu wissen, man mu? auch anwenden; es ist nicht ge- > nug zu wollen, man mu? auch tun. -- Goethe, Maximen und Reflexionen > > --__--__-- > > Message: 7 > To: Brian Waite > Cc: u-boot-users at lists.sourceforge.net > Subject: Re: [U-Boot-Users] Configuration System > From: Wolfgang Denk > Date: Mon, 03 May 2004 22:12:53 +0200 > > Dear Brian, > > in message <200405030705.57724.waite@skycomputers.com> you wrote: > > > > First, let me say I don't find the configurator that we are talking about all > > the helpful to my work, but I think I might have a solution that will reduce > > the maintainability. So what I was thinking about was using the maintainers > > Ummm... Do you really mean what I'm reading here? > > If it's not helpful, and reduces maintainability, then what is it > good for at all? > > > file along with a configurator script in the tools directory. The > > configurator would be all the smarts. It would read the MAINTAINERS file, > > which has the bits in a well-defined structure, and generate the views with > > some type of filtering. So you could say "Show me all boards supporting CPU > > xyz" or "Show me all boards supported by CPU xyz". The obvioous final step of > > the configurator is "make " > > What should this be good for? > > Normally, the user has a board on his desk, which is labeled as > "foo", and all he needs to know is that the board name "foo" will be > supported by either "make foo_config; make all" or simply by "MAKEALL > foo". > > If you are looking for similar boards while porting to some custom > hardware, just scanning the CPU types does not help at all. You will > need a lot of other parameters like memory map, RAM and flash chip > types, bus width, flash sector layout, where to put the environment, > which commands shall be supported, etc. etc. > > > PROS: > > * The only new files are specificaly for the configurator and only need be > > modified to fix the configurator. > > * Only the people interested in the system need to know about it. > > * Automatically updated with each supported board. > > Assuming somebody adds the relevant entries to the MAINTAINERS file. > This is nothing you can rely on. > > > * Minimal added work for Wolfgang. > > * It can be extracted from the tree and maintained on the side until Wolfgang > > has the time to review and appove it. > > * No one other then the interested parties has to do anything other than add > > their board to the MAINTAINERS list to work in u-boot. > > * It does not preclude the make well known system. > > * Many others I am sure :) > > > > CONS: > > * More files in the u-boot tree. > > Not a real problem. > > > * The configurator itself becomes somewhat complex. > > * Many others I am sure :) > > One other: I see zero advantage. > > > Jon, Wolfgang what are your thoughts on a system like this? > > Either I don't understand at all what you have in mind, or we have > very, very different goals -- "reducing maintainability" is most > definitely not on my wish list ;-) > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de > Der Dativ ist dem Genitiv sein Tod. > > --__--__-- > > Message: 8 > From: "Bob White" > Organization: Perigee, LLC > To: u-boot-users at lists.sourceforge.net > Date: Mon, 03 May 2004 16:18:32 -0400 > Subject: [U-Boot-Users] Dual-Port SRAM > > I've got a board with a dual-port SRAM attached to the 440GP on the > peripheral bus (at CS1_N). I can map the TLB and access the device > from the bdi2000 and the u-boot command prompt (see gigeth.cfg below.) > > What configuration is necessary to map this memory into the kernel? > Can you point me to some examples? How does it then get accessed from > a user program? > > Thanks. > > ================ gigeth.cfg ================ > [INIT] > ; Setup TLB > WTLB 0xFF000075 0x1FF0003F ;Flash TLB Entry - 16Mb page > WTLB 0x00000098 0x0000003F ;SDRAM 256MB @ 0x00000000 > > ; Setup Peripheral Bus > ; > ; Flash -- 8MB @ FF800000 > ; > WDCR 0x12 0x00000010 ;Select EBC0_B0AP > WDCR 0x13 0x9B015480 ;B0AP: Flash and SRAM > WDCR 0x12 0x00000000 ;Select EBC0_B0CR > WDCR 0x13 0xFF87A000 ;B0CR: 8MB at 0xFF800000, r/w, 16bit > ; > ; Dual-port -- 128KB @ FF600000 > ; -- @ FF700000 CS2_N for Semaphore > ; > WDCR 0x12 0x00000011 ;Select EBC0_B1AP > WDCR 0x13 0x9B015480 ;B1AP: Flash and SRAM > WDCR 0x12 0x00000001 ;Select EBC0_B1CR > WDCR 0x13 0xff61e000 ;B1CR: 1MB at 0xFF600000, r/w, 32bit > ; (We really only have 128KB, but 1MB > ; block is the smallest that we can > ; define.) > > WDCR 0x12 0x00000012 ;Select EBC0_B2AP > WDCR 0x13 0x9B015480 ;B2AP: Flash and SRAM > WDCR 0x12 0x00000002 ;Select EBC0_B2CR > WDCR 0x13 0xff71e000 ;B2CR: 1MB at 0xFF700000, r/w, 32bit > ; (We really map this space to set > ; the semaphore connected as CS2_N) > > ; Setup SDRAM Controller (DDR SDRAM) > WDCR 0x10 0x00000082 ;Select SDRAM0_CLKTR > WDCR 0x11 0x40000000 ;CLKTR: Advance 90 degrees > WDCR 0x10 0x00000080 ;Select SDRAM0_TR0 > WDCR 0x11 0x410A4012 ;TR0: V2.0 > ;WDCR 0x11 0x41054009 ;TR0: V1.0 > WDCR 0x10 0x00000081 ;Select SDRAM0_TR1 > WDCR 0x11 0x8080082B ;TR1: V2.0 > ;WDCR 0x11 0x40400800 ;TR1: V1.0 > WDCR 0x10 0x00000040 ;Select SDRAM0_B0CR > WDCR 0x11 0x00062001 ;B0CR: 32MByte @ 0x00000000 Mode 2 > WDCR 0x10 0x00000030 ;Select SDRAM0_RTR > WDCR 0x11 0x08200000 ;RTR: V2.0 > ;WDCR 0x11 0x06180000 ;RTR: V1.0 > WDCR 0x10 0x00000020 ;Select SDRAM0_CFG0 > WDCR 0x11 0x04000000 ;CFG0: 32bit, PMU disable > WDCR 0x11 0x84800000 ;CFG0: enable SDRAM > > [TARGET] > JTAGCLOCK 1 ;use 8 MHz JTAG clock > CPUTYPE 440 ;the used target CPU type > ;BDIMODE LOADONLY ;the BDI working mode (LOADONLY | > AGENT) > BDIMODE AGENT > BREAKMODE HARD ;SOFT or HARD, HARD uses PPC hardware > breakpoint > STEPMODE HWBP ;JTAG or HWBP, HWBP uses one or two > hardware breakpoints > ;VECTOR CATCH ;catch unhandled exceptions > STARTUP RESET > WORKSPACE 0x00005000 > ;MMU XLAT 0xC0000000 ;enable virtual address mode > ;PTBASE 0x00000000 ;address where kernel/user stores > pointer to page table > ;SIO 7 9600 ;TCP port for serial IO > WAKEUP 1000 > > [HOST] > ;IP 151.120.25.118 ;Linux host > IP 192.168.0.49 ;Windows host > FILE vmlinux > FORMAT BIN 0x00000000 > START 0x00000000 > LOAD MANUAL ;load code MANUAL or AUTO after reset > DEBUGPORT 2001 > DUMP dump.bin > ;DUMP dump.bin ;Linux: dump.bin must already exist > and public writable > > [FLASH] > WORKSPACE 0x00004000 ;workspace in SDRAM for fast programming > algorithm > ;WORKSPACE 0xFFC00000 ;workspace in SRAM for fast programming > algorithm > CHIPTYPE STRATAX16 ;Flash type (AM29F | AM29BX8 | AM29BX16 | > I28BX8 | I28BX16) > CHIPSIZE 0x800000 ;The size of one flash chip in bytes (e.g. > AM29F040 = 0x80000) > BUSWIDTH 16 ;The width of the flash memory bus in bits (8 > | 16 | 32) > FILE u-boot.bin ;The file to program > ERASE 0xFFF80000 ;erase U-Boot sector 1 > ERASE 0xFFFA0000 ;erase U-Boot sector 2 > ERASE 0xFFFE0000 ;erase U-Boot sector 4 (3 is environment) > > [REGS] > IDCR1 0x010 0x011 ;SDRAM0_CFGADDR and SDRAM0_CFGDATA > IDCR2 0x012 0x013 ;EBC0_CFGADDR and EBC0_CFGDATA > IDCR3 0x014 0x015 ;EBM0_CFGADDR and EBM0_CFGDATA > IDCR4 0x016 0x017 ;PPM0_CFGADDR and PPM0_CFGDATA > FILE reg440gp.def > ============================================ > > Bob > -- > Robert B. White Perigee, A Division of Sensis Corp > Software Design Engr 316 Commerce Blvd. > TEL: 315.453.7842x29 Liverpool, NY 13088 > FAX: 315.453.7917 www.Perigee.com > > ------- End of forwarded message -------Bob > -- > Robert B. White Perigee, A Division of Sensis Corp > Software Design Engr 316 Commerce Blvd. > TEL: 315.453.7842x29 Liverpool, NY 13088 > FAX: 315.453.7917 www.Perigee.com > Bob > -- > Robert B. White Perigee, A Division of Sensis Corp > Software Design Engr 316 Commerce Blvd. > TEL: 315.453.7842x29 Liverpool, NY 13088 > FAX: 315.453.7917 www.Perigee.com > > --__--__-- > > Message: 9 > To: "Bob White" > Cc: u-boot-users at lists.sourceforge.net > Subject: Re: [U-Boot-Users] Dual-Port SRAM > From: Wolfgang Denk > Date: Mon, 03 May 2004 22:53:56 +0200 > > In message <409670D8.12901.1AF7BA5E@localhost> you wrote: > > > > What configuration is necessary to map this memory into the kernel? > > Can you point me to some examples? How does it then get accessed from > > a user program? > > You posted the same questions to the PPC mailing list before. Why > don't you wait a bit for replies? > > And what has this to do with U-Boot? It's off topic here! > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de > The optimum committee has no members. > - Norman Augustine > > --__--__-- > > Message: 10 > Date: Tue, 4 May 2004 09:09:03 +0800 (CST) > From: =?gb2312?q?Sam=20Song?= > Subject: Re: [U-Boot-Users] [Patch]New board support : lite_dw > To: Wolfgang Denk > Cc: u-boot-users at lists.sourceforge.net > > Wolfgang Denk wrote: > > If the Linux kernel tree uses RPXlite_DW, then this > > is what we should use, too. I think it is a very > > good idea to use the same name when- > > ever possible. > > OK. I choose the name,RPXlite_DW, for this board. > > > > Secondly,I'd like to support the following > > > features on this board for the moment. > > > 1. LCD panel support; > > This can be done as two build targets, like the > > TQM823L_config and TQM823L_LCD_config. > > OK.I did it. > > > > 2. 64MHz/48MHz system clock options; > > If possible, make it automatically detect the > > clock frequency and auto-adjust. Your users > > will praise you if the same binary image > > works on both configurations. > > This is really a challenge for me.I meant to build two > targets for it and did.How to make it?Usually we set > PLPRCR in to choose system clock for board > init.It seems that it's programmers to decide the > value according to CPU max frequency and oscillator's > frequency on the board.Any clue with it? > > > > 3. ENV_IS_IN_FLASH/ENV_IS_IN_NVRAM; > > > > Either make it a different build targets, or > > select a standard configuration and let the > > user decide to modify the board config file. > > I really want to make the second possible.Did u-boot > command do this job? > > Best regards, > > Sam > > _________________________________________________________ > Do You Yahoo!? > ????TT???????????????????????? > http://cn.rd.yahoo.com/mail_cn/tag/SIG=1402c0to2/**http%3A%2F%2Fhp.allyes.com%2Flaserjet%2Fgamestory%2Findex.html%3Fjumpid%3Dex_hphqapcn_MongooseLJ1010%2F201073CN407016%2FYahoo > > --__--__-- > > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > End of U-Boot-Users Digest