May 2004 - U-Boot

[U-Boot-Users] Using MotLoad as flash bootloader???
by Oliver Korpilla 06 May '04

06 May '04

Hello! The MVME5500 directly supports booting a Linux kernel from the net and from disk. A ROM/RAM/flash boot option seems to be missing. Does anybody know, how to use the Motload to boot a kernel from flash (maybe with the ELF-loader, or by putting a kernel in a correct place). I already tried loading the kernel (PPLUS image) into memory and executing it directly (with offsets 0 and 100 from its load address) and putting the BUGBOOT image into the start of both flash banks (reserved as kernel space anyway by the supplied MTD partition mapping). It would be really nice to know if somebody has solved this problem, or if somebody could give some useful hints! Thanks in advance, Oliver Korpilla

1 0

[U-Boot-Users] u-boot and ramdisk
by Peter Billek (VI/SEA) 06 May '04

06 May '04

hi Can someone tell if u-boot or it's predecessor armboot supports booting the linux kernel from a ramdisk, and how this is done? I am sure there are some doc's about it. I found a lot of doc's from other bootloader and ramdisk's in general, but nothing related to u-boot(armboot) thanks for your help Peter Billek Board Level Design, Realtime SW Local Design Center VIE Ericsson Enterprise GmbH Pottendorfer Strasse 25-27 A-1121 Vienna / Austria Tel: +43 1 81100 4791 Fax: +43 1 81100 11 4791 mailto:peter.billek@ericsson.com www.ericsson.com

2 1

[U-Boot-Users] Re: [Fwd: PATCH: Some additions to README]
by Tolunay Orkun 05 May '04

05 May '04

Wolfgang, I sent this patch twice (Apr 9 & 20). What is the status? It is not executable code so it is probably not as high priority for you but I think you agree keeping README file up to date is important as well. In particular, you had asked me to provide descriptions for some CONFIG_ variables. I hope this patch gets in before other patches modify the same sorted lists I've updated (and re-sorted). Re-sorting the lists takes some time. Perhaps we need a better way to organize them (current 3 column approach is difficult as when you insert a new board name in the middle almost everything shifts) Best regards, Tolunay > Wolfgang, > > I am not sure if my README file patch is still in your pipeline. You have > already applied another patch that I sent the same day as this one... > > Best regards, > Tolunay > > ---------------------------- Original Message ---------------------------- > Subject: PATCH: Some additions to README > Date: Wed, April 7, 2004 3:44 pm > To: "Wolfgang Denk" <wd(a)denx.de> > Cc: u-boot-users(a)lists.sourceforge.net > -------------------------------------------------------------------------- > > Changelog: > > - Added CONFIG_CSB272 and csb272_config to > appropriate lists (and resorted) > - Added descriptions for some MII/PHY options > - Added description for CONFIG_I2CFAST > - Added description for environment variable i2cfast

1 0

[U-Boot-Users] New NAND code patch
by Pantelis Antoniou 05 May '04

05 May '04

Hello The following patch is a rewrite of the NAND code of u-boot. Details are provided in the doc/README.NAND file. * Patch by Pantelis Antoniou, 5 May 2004: - NAND code rewrite and new functionality. Regards Pantelis common/cmd_nand.c | 2472 ++++++++++++++++++++++++++++++----------------------- doc/README.NAND | 83 + include/mtd_nand.h | 168 +++ net/nfs.c | 31 net/tftp.c | 30 5 files changed, 1723 insertions(+), 1061 deletions(-)

1 0

[U-Boot-Users] Re: [Patch]New board support : RPXlite_DW [continued]
by Wolfgang Denk 05 May '04

05 May '04

In message <20040505083555.31651.qmail(a)web15204.mail.bjs.yahoo.com> you wrote: > For the sake of no feedback,I posted the left patch to > your queue. Your patch is broken because your mail tool inserted line wrappings. It is too big for the mailing list. It is missing critical information. Please see section "Submitting Patches" in the README for the required items. Rejected. Please clean up, and resubmit. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de I have a very small mind and must live with it. -- Edsger Dijkstra

1 0

[U-Boot-Users] Re: U-Boot-Users digest, Vol 1 #739 - 10 msgs
by Abbas Dadabhoy 04 May '04

04 May '04

Please remove u-boot-users-request(a)lists.sourceforge.net wrote: > Send U-Boot-Users mailing list submissions to > u-boot-users(a)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(a)lists.sourceforge.net > > You can reach the person managing the list at > u-boot-users-admin(a)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 <okorpil(a)fh-landshut.de> > To: Mike McCullough <mike(a)mccengineering.com> > CC: Wolfgang Denk <wd(a)denx.de>, > u-boot-users <u-boot-users(a)lists.sourceforge.net> > 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 <mike(a)mccengineering.com> > Cc: okorpil(a)fh-landshut.de, > u-boot-users <u-boot-users(a)lists.sourceforge.net> > Subject: Re: [U-Boot-Users] [Newbie help] Motorola Board with GT64260 > From: Wolfgang Denk <wd(a)denx.de> > Date: Mon, 03 May 2004 12:23:42 +0200 > > In message <5.1.0.14.2.20040502213935.0129c038(a)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(a)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 <waite(a)skycomputers.com> > To: u-boot-users(a)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 <configuration>" > > 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 <configuration> 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?= <samsongshu(a)yahoo.com.cn> > To: wd(a)denx.de > Cc: u-boot-users(a)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.c… > > --__--__-- > > Message: 5 > Date: Mon, 3 May 2004 14:26:14 -0400 > From: "Dave Ellis" <DGE(a)sixnetio.com> > To: "Pantelis Antoniou" <panto(a)intracom.gr> > Cc: "U-Boot Users" <u-boot-users(a)lists.sourceforge.net> > 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?= <samsongshu(a)yahoo.com.cn> > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] [Patch]New board support : lite_dw > From: Wolfgang Denk <wd(a)denx.de> > Date: Mon, 03 May 2004 22:05:33 +0200 > > Dear Sam, > > in message <20040503155816.12658.qmail(a)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(a)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 <waite(a)skycomputers.com> > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] Configuration System > From: Wolfgang Denk <wd(a)denx.de> > Date: Mon, 03 May 2004 22:12:53 +0200 > > Dear Brian, > > in message <200405030705.57724.waite(a)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 <configuration>" > > 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 <configuration> 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(a)denx.de > Der Dativ ist dem Genitiv sein Tod. > > --__--__-- > > Message: 8 > From: "Bob White" <bwhite(a)perigee.com> > Organization: Perigee, LLC > To: u-boot-users(a)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" <bwhite(a)perigee.com> > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] Dual-Port SRAM > From: Wolfgang Denk <wd(a)denx.de> > 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(a)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?= <samsongshu(a)yahoo.com.cn> > Subject: Re: [U-Boot-Users] [Patch]New board support : lite_dw > To: Wolfgang Denk <wd(a)denx.de> > Cc: u-boot-users(a)lists.sourceforge.net > > Wolfgang Denk <wd(a)denx.de> 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 <board.h> 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.c… > > --__--__-- > > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > End of U-Boot-Users Digest

1 0

[U-Boot-Users] Unsubscribe
by Abbas Dadabhoy 04 May '04

04 May '04

Please remove. I attempted to remove earlier but your website requires password. u-boot-users-request(a)lists.sourceforge.net wrote: > Send U-Boot-Users mailing list submissions to > u-boot-users(a)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(a)lists.sourceforge.net > > You can reach the person managing the list at > u-boot-users-admin(a)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 <okorpil(a)fh-landshut.de> > To: Mike McCullough <mike(a)mccengineering.com> > CC: Wolfgang Denk <wd(a)denx.de>, > u-boot-users <u-boot-users(a)lists.sourceforge.net> > 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 <mike(a)mccengineering.com> > Cc: okorpil(a)fh-landshut.de, > u-boot-users <u-boot-users(a)lists.sourceforge.net> > Subject: Re: [U-Boot-Users] [Newbie help] Motorola Board with GT64260 > From: Wolfgang Denk <wd(a)denx.de> > Date: Mon, 03 May 2004 12:23:42 +0200 > > In message <5.1.0.14.2.20040502213935.0129c038(a)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(a)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 <waite(a)skycomputers.com> > To: u-boot-users(a)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 <configuration>" > > 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 <configuration> 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?= <samsongshu(a)yahoo.com.cn> > To: wd(a)denx.de > Cc: u-boot-users(a)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.c… > > --__--__-- > > Message: 5 > Date: Mon, 3 May 2004 14:26:14 -0400 > From: "Dave Ellis" <DGE(a)sixnetio.com> > To: "Pantelis Antoniou" <panto(a)intracom.gr> > Cc: "U-Boot Users" <u-boot-users(a)lists.sourceforge.net> > 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?= <samsongshu(a)yahoo.com.cn> > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] [Patch]New board support : lite_dw > From: Wolfgang Denk <wd(a)denx.de> > Date: Mon, 03 May 2004 22:05:33 +0200 > > Dear Sam, > > in message <20040503155816.12658.qmail(a)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(a)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 <waite(a)skycomputers.com> > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] Configuration System > From: Wolfgang Denk <wd(a)denx.de> > Date: Mon, 03 May 2004 22:12:53 +0200 > > Dear Brian, > > in message <200405030705.57724.waite(a)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 <configuration>" > > 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 <configuration> 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(a)denx.de > Der Dativ ist dem Genitiv sein Tod. > > --__--__-- > > Message: 8 > From: "Bob White" <bwhite(a)perigee.com> > Organization: Perigee, LLC > To: u-boot-users(a)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" <bwhite(a)perigee.com> > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] Dual-Port SRAM > From: Wolfgang Denk <wd(a)denx.de> > 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(a)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?= <samsongshu(a)yahoo.com.cn> > Subject: Re: [U-Boot-Users] [Patch]New board support : lite_dw > To: Wolfgang Denk <wd(a)denx.de> > Cc: u-boot-users(a)lists.sourceforge.net > > Wolfgang Denk <wd(a)denx.de> 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 <board.h> 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.c… > > --__--__-- > > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > End of U-Boot-Users Digest

1 0

RE: [U-Boot-Users] [PATCH] lan91c96 driver MAC address detection
by Woodruff, Richard 04 May '04

04 May '04

:) You might say that the u-boot 'bootp command implementation', which utilizes the bootp protocol, will initialize the ether driver which in turn causes mac address initialization. All u-boot network 'commands' do this as their protocols require that the mac is setup as a precondition to their use. I have to admit the first time I read the post I was confused to the intent. Regards, Richard W. > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users- > admin(a)lists.sourceforge.net] On Behalf Of Wolfgang Denk > Sent: Tuesday, May 04, 2004 12:02 PM > To: Dave Peverley > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] [PATCH] lan91c96 driver MAC address detection > > In message <40978D65.7030805(a)mpc-data.co.uk> you wrote: > > > > > You cannot use BOOTP (nor ony other network related protocol) to > > > detect a MAC address!!! > > I think that either we operate on utterly different brainwave-lengths > > or theres some kind of language barrier issue here! > > BOOTP is a well-defined protocol which is based on the assumption > that you have a network interface that can be used to send and > receive packets. To do so, the interface must be initialized. BOOTP > does in NO WAY work if your interface does not have a MAC address > set. Especially, it does NOT retrieve the MAC address from anywhere. > > > If you issue a 'bootp' command to u-boot via its interface as I stated, > > the following call sequence happens if you're using the lan91c96 (with > > patch) or smc91111 ethernet devices : > > > > do_bootp() [cmd_net.c] > > netboot_common() [cmd_net.c] > > NetLoop() [net.c] > > eth_init() [lan91c96.c] > > Stop here. eth_init() performs the initialization of the ethernet > interface, if this did not happen before, because an initialized > ethernet interface is a precondition to use BOOTP. > > > So in practical use, issuing a bootp detects the mac address of the > > adapter. > > No, no, no. This is plainly wrong. > > > Well, the following network related protocol calls : > > do_tftpb() > > do_rarpb() > > do_dhcp() > > do_nfs() > > all call netboot_common() so will in effect detect the MAC address as > > well ;-) > > None of these protocols has ato do anything with setting the MAC > address. Please don't mix things up. > > You could as well claim that bootp sets the baudrate of the serial > console, because to run bootp you must execute an initialization > sequence which includes the serial port, thus setting the baudrate. > > IT AIN'T SO! > > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de > Oh, that sound of male ego. You travel halfway across the galaxy and > it's still the same song. > -- Eve McHuron, "Mudd's Women", stardate 1330.1 > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

[U-Boot-Users] relocation problem
by Petre Pircalabu 04 May '04

04 May '04

Hello, My name is Petre Pircalabu and I'm a student in Bucharest, Romania. I'm currently trying to port U-Boot 1.1.1 to an Xscale board based on the PXA255 processor.I used the Csb226 board as starting place, I modified the memsetup.S file according to my board.(I tested the memory writing and reading a value to/from the SDRAM, and then I used the FFUART as an output). The program work well until it should jump to start_armboot (/cpu/pxa/start.S:175). What intrigues me the most is that when i try to read a value from SDRAM (where the program should be after relocation - 0xa1fe0000 and higher, i get only 0's ). If you have any suggestion, please help me Thanks in advance, Petre

2 1

RE: [U-Boot-Users] [PATCH] lan91c96 driver MAC address detection
by Woodruff, Richard 04 May '04

04 May '04

Actually, I added the following 2 functions to remove related problems... Aside from the warning you will find that if you 'directly' boot your system and have NOT set the mac address via the indirect bootp probe, a kernel built for a nfsroot won't make it, as the kernel driver assumes a valid mac is set (or available). So, in my board's misc_init_r() I make sure to probe for a chip, if its there go ahead and set the mac address up. (several boards I've used didn't have a serial eeprom). Seems like some chips do something similar (reset anyway) in lib_arm/board.c, but I think its better to done at the board level. This probably also kills the mac warning. Regards, Richard W. =============== Added to smc91111.c ======================= static int smc_probe(void) { int bank; bank = SMC_inw (BANK_SELECT); if ((bank & 0xFF00) != 0x3300) return -1; return 0; } /* * Set MAC address even if smc_open is not called by u-boot. Its a good idea * for the mac to be set in the chip when the kernel starts (no eeprom case). */ int eth_mac_config(bd_t *bd) { int err, i; err = smc_probe(); if(err >= 0){ SMC_SELECT_BANK (1); smc_get_ethaddr (bd); for (i = 0; i < 6; i++) SMC_outb (smc_mac_addr[i], ADDR0_REG + i); } return err; } ========== in myboard.c file ================ int misc_init_r (void) { #ifdef CONFIG_DRIVER_SMC91111 DECLARE_GLOBAL_DATA_PTR; extern int eth_mac_config(bd_t *); /* for development board enable ethernet */ /* take chip out of reset (need shadow reg) */ toto_bcr_write( toto_bcr_read() | TOTO_BCR_COM_RESET); udelay(300); eth_mac_config(gd->bd); /* set mac addr in chip */ #endif return(0); } > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users- > admin(a)lists.sourceforge.net] On Behalf Of Dave Peverley > Sent: Tuesday, May 04, 2004 7:33 AM > To: Wolfgang Denk > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] [PATCH] lan91c96 driver MAC address detection > > Wolfgang Denk wrote: > > The rules are simple and documented: > Sure, I've read these... > > > You cannot use BOOTP (nor ony other network related protocol) to > > detect a MAC address!!! > I think that either we operate on utterly different brainwave-lengths > or theres some kind of language barrier issue here! > > If you issue a 'bootp' command to u-boot via its interface as I stated, > the following call sequence happens if you're using the lan91c96 (with > patch) or smc91111 ethernet devices : > > do_bootp() [cmd_net.c] > netboot_common() [cmd_net.c] > NetLoop() [net.c] > eth_init() [lan91c96.c] > smc_open() [lan91c96.c] > smc_get_ethaddr() [lan91c96.c] > get_rom_mac() [lan91c96.c] > > So in practical use, issuing a bootp detects the mac address of the > adapter. > > > (nor ony other network related protocol) > Well, the following network related protocol calls : > do_tftpb() > do_rarpb() > do_dhcp() > do_nfs() > all call netboot_common() so will in effect detect the MAC address as > well ;-) > > Best Wishes, > > Dave Peverley > > ------------------------------------------------------------------------ -- > - > Dave Peverley, Software Engineer, MPC Data Limited. > Phone : [+44] (0) 1225 868 228 Web : http://www.mpc- > data.co.uk > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users

2 1