[U-Boot-Users] Re: U-Boot-Users digest, Vol 1 #739 - 10 msgs - U-Boot

4 May 2004

      Please remove
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

[U-Boot-Users] Re: U-Boot-Users digest, Vol 1 #739 - 10 msgs

Abbas Dadabhoy

Bob

------- End of forwarded message -------Bob

tags (0)

participants (1)