[U-Boot-Users] Re: U-Boot-Users digest, Vol 1 #739 - 10 msgs
Abbas Dadabhoy
a.dadabhoy at aristoslogic.com
Tue May 4 20:26:11 CEST 2004
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 <okorpil at fh-landshut.de>
> To: Mike McCullough <mike at mccengineering.com>
> CC: Wolfgang Denk <wd at denx.de>,
> u-boot-users <u-boot-users at 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 at mccengineering.com>
> Cc: okorpil at fh-landshut.de,
> u-boot-users <u-boot-users at lists.sourceforge.net>
> Subject: Re: [U-Boot-Users] [Newbie help] Motorola Board with GT64260
> From: Wolfgang Denk <wd at denx.de>
> Date: Mon, 03 May 2004 12:23:42 +0200
>
> In message <5.1.0.14.2.20040502213935.0129c038 at 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 <waite at skycomputers.com>
> 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 <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 at yahoo.com.cn>
> 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" <DGE at sixnetio.com>
> To: "Pantelis Antoniou" <panto at intracom.gr>
> Cc: "U-Boot Users" <u-boot-users at 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 at yahoo.com.cn>
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [Patch]New board support : lite_dw
> From: Wolfgang Denk <wd at denx.de>
> Date: Mon, 03 May 2004 22:05:33 +0200
>
> Dear Sam,
>
> in message <20040503155816.12658.qmail at 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 <waite at skycomputers.com>
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Configuration System
> From: Wolfgang Denk <wd at denx.de>
> Date: Mon, 03 May 2004 22:12:53 +0200
>
> Dear Brian,
>
> in message <200405030705.57724.waite at 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 at denx.de
> Der Dativ ist dem Genitiv sein Tod.
>
> --__--__--
>
> Message: 8
> From: "Bob White" <bwhite at perigee.com>
> 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" <bwhite at perigee.com>
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Dual-Port SRAM
> From: Wolfgang Denk <wd at denx.de>
> Date: Mon, 03 May 2004 22:53:56 +0200
>
> In message <409670D8.12901.1AF7BA5E at 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?= <samsongshu at yahoo.com.cn>
> Subject: Re: [U-Boot-Users] [Patch]New board support : lite_dw
> To: Wolfgang Denk <wd at denx.de>
> Cc: u-boot-users at lists.sourceforge.net
>
> Wolfgang Denk <wd at 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.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
More information about the U-Boot
mailing list