[U-Boot-Users] Unsubscribe
Please remove. I attempted to remove earlier but your website requires password.
u-boot-users-request@lists.sourceforge.net wrote:
Send U-Boot-Users mailing list submissions to u-boot-users@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@lists.sourceforge.net
You can reach the person managing the list at u-boot-users-admin@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:
- Re: [Newbie help] Motorola Board with GT64260 (Oliver Korpilla)
- Re: [Newbie help] Motorola Board with GT64260 (Wolfgang Denk)
- Re: Configuration System (Brian Waite)
- [Patch]New board support : lite_dw (=?gb2312?q?Sam=20Song?=)
- RE: New NAND code draft (Dave Ellis)
- Re: [Patch]New board support : lite_dw (Wolfgang Denk)
- Re: Configuration System (Wolfgang Denk)
- Dual-Port SRAM (Bob White)
- Re: Dual-Port SRAM (Wolfgang Denk)
- 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@fh-landshut.de To: Mike McCullough mike@mccengineering.com CC: Wolfgang Denk wd@denx.de, u-boot-users u-boot-users@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@mccengineering.com Cc: okorpil@fh-landshut.de, u-boot-users u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [Newbie help] Motorola Board with GT64260 From: Wolfgang Denk wd@denx.de 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@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@skycomputers.com To: u-boot-users@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@yahoo.com.cn To: wd@denx.de Cc: u-boot-users@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.
- LCD panel support;
- 64MHz/48MHz system clock options;
- 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.co...
--__--__--
Message: 5 Date: Mon, 3 May 2004 14:26:14 -0400 From: "Dave Ellis" DGE@sixnetio.com To: "Pantelis Antoniou" panto@intracom.gr Cc: "U-Boot Users" u-boot-users@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
- 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.
- NAND boot works
not tried
- Direct to NAND tftp/nfs support.
not tried
Things that are probably borked: =20
- 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.)
- JFFS2 support although there is probably b0rken.
- 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@yahoo.com.cn Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [Patch]New board support : lite_dw From: Wolfgang Denk wd@denx.de 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.
- LCD panel support;
This can be done as two build targets, like the TQM823L_config and TQM823L_LCD_config.
- 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.
- 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@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@skycomputers.com Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Configuration System From: Wolfgang Denk wd@denx.de 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 <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@denx.de Der Dativ ist dem Genitiv sein Tod.
--__--__--
Message: 8 From: "Bob White" bwhite@perigee.com Organization: Perigee, LLC To: u-boot-users@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@perigee.com Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Dual-Port SRAM From: Wolfgang Denk wd@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@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@yahoo.com.cn Subject: Re: [U-Boot-Users] [Patch]New board support : lite_dw To: Wolfgang Denk wd@denx.de Cc: u-boot-users@lists.sourceforge.net
Wolfgang Denk wd@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.
- LCD panel support;
This can be done as two build targets, like the TQM823L_config and TQM823L_LCD_config.
OK.I did it.
- 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?
- 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.co...
--__--__--
U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
End of U-Boot-Users Digest
participants (1)
-
Abbas Dadabhoy