February 2004 - U-Boot

[U-Boot-Users] FPGA load problem
by Shlomo_Kut＠mksinst.com 26 Feb '04

26 Feb '04

Hi, Our board has a XILINX Spartan FPGA XC2S200E. I have customized the FPGA load function that I found in esd/command/fpga. I find by looking at the data in a logic analyzer that all the data reaches the FPGA intact but done does not get set. I attach the code to this message. Can anybody help? P.S. Why do most people write there own fpga loader instead of using cmd_fpga? regards Shlomo Kut Software Engineer MKS Instruments Tenta Products Tel: 972-8-9181015 Fax: 972-8-9181020 www.mksinst.com

2 1

[U-Boot-Users] GDB-BDM for Coldfire
by Stuart Wood 26 Feb '04

26 Feb '04

Hi All, I'm having trouble setting up the BDM interface for GDB. My target board is the M5282EVB. I've been following Bernard Kuhn's tutorial "U-Boot for Motorola Coldfire M5272C3 and M5282EVB" but I'm getting the following error when running GDB and setting the target. GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-bdm-elf". gdbinit.init:1: Error in sourced command file: Undefined target command: "bdm /dev/bdmcf0". Try "help target". The driver seems to be loaded. [root@localhost My_Preloader]# lsmod | grep bdm bdm 28104 0 (unused) [root@localhost My_Preloader]# ls -l /dev/bdmcf0 crw-rw-rw- 1 root root 34, 4 Feb 25 07:43 /dev/bdmcf0 Also I did change bdm.c line 1230 to 0xc05, /* BDM_REG_RAMBAR */ Any help would be appreciated! Also is the gdb patches been included in gdb-6.0? and does the BDM sourceforge project support the 5282? Thanks! Stuart

1 0

RE: [U-Boot-Users] What areas of SDRAM are used by u-boot
by Gupta, Kshitij 25 Feb '04

25 Feb '04

_____________________________________________ U-Boot 1.0.0 (Feb 19 2004 - 11:23:36) U-Boot code: 11000000 -> 11015790 BSS: -> 11019494 _________________________________________________ This is what gets printed when I boot my board. Also you can find it out by looking at the TEXT_ADDR defined in boards/xxxxx/config.mk file. regards -kshitij -----Original Message----- From: Shlomo_Kut(a)mksinst.com [mailto:Shlomo_Kut@mksinst.com] Sent: Tuesday, February 24, 2004 2:03 PM To: Gupta, Kshitij Subject: RE: [U-Boot-Users] What areas of SDRAM are used by u-boot I don't see them. Do I need to enable any debug options? regards Shlomo Kut Software Engineer MKS Instruments Tenta Products Tel: 972-8-9181015 Fax: 972-8-9181020 www.mksinst.com "Gupta, Kshitij" <kshitij(a)ti.com> 02/24/2004 12:31 AM To: "'Shlomo_Kut(a)mksinst.com'" <Shlomo_Kut(a)mksinst.com> cc: Subject: RE: [U-Boot-Users] What areas of SDRAM are used by u-boot hi, u-boot prints the area of SDRAM it uses. Just check the messages on your terminal emulator. regards -kshitij -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Shlomo_Kut(a)mksinst.com Sent: Tuesday, February 24, 2004 12:40 PM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] What areas of SDRAM are used by u-boot Hi, I am trying to define the area of SDRAM that is to be tested using mtest. How can I determine what areas of SDRAM are used by u-boot so I don't trample on it by mistake? regards Shlomo Kut Software Engineer MKS Instruments Tenta Products Tel: 972-8-9181015 Fax: 972-8-9181020 www.mksinst.com ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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

[U-Boot-Users] initrd
by Marco Schramel 25 Feb '04

25 Feb '04

hi, My own buildt U-boot runs on my evalboard. Now i ve downloaded the linuxppc_2_4_devel, have configured it for 8270 and builded it (with ELDK). How are the right steps for initializing the board with kernel and initrd? I thing it is: unlock ...... erase .... tftpboot 100000 kernelimage printenv filesize cp.b 100000 100000 filesize tftpboot 100000 uInitRD printenv filesize cp.b 100000 300000 filesize setenv bootm 100000 300000 saveenv bootm reset Can i do this like this way ??? Thanks Marco --------- Marco Schramel R&D Bartec GmbH Schulstr. 30 94239 Gotteszell, Germany www.bartec.de Marco.Schramel(a)go.bartec.de Phone: +49 (0)9929/301332 Fax: +49 (0)9929/301112

2 1

[U-Boot-Users] Copyright and license for mkimage
by Cam 25 Feb '04

25 Feb '04

Hello Wolfgang I am hoping to clarify the rights to use and distribute the mkimage binary. I would like to distribute a mkimage binary (or possibly a derived work) to facilitate checking uImage files as part of a remote software update. The mkimage binary is made from crc32.c which is amenable to such use: (a URL for version 1.1.3 of zlib.h is http://cvs.sourceforge.net/viewcvs.py/*checkout*/gnu-darwin/zlib-1.1.3/zlib… ) However the mkimage.c file is: * (C) Copyright 2000-2003 * DENX Software Engineering * Wolfgang Denk, wd(a)denx.de * All rights reserved. What advice can you give? Has anyone else used mkimage in this way? Thanks -Cam PS: apologies if this is a FAQ, the list archives are currently down. -- camilo(a)mesias.co.uk <--

2 1

[U-Boot-Users] Can we limit number of messages per day.
by Abbas Dadabhoy 25 Feb '04

25 Feb '04

Wont it be nice to limit these number of messages to 1 or 2 a day. 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: Problems with u-boot, PPChameleonEVB and MontaVista kernel (Andy Hawkins) > 2. Re: Where can I find a libgcc.a with software FP. (Wolfgang Denk) > 3. Re: telnet server on u-boot (Detlev Zundel) > 4. Re: Compile Error (Wolfgang Denk) > 5. Re: NFS support patch (Detlev Zundel) > 6. RE: Problems with u-boot, PPChameleonEVB and MontaVista kernel (Andy Hawkins) > 7. Re: NFS support patch (Steven Scholz) > 8. Memory Access Problem (sudhakar rajashekhara) > 9. Re: telnet server on u-boot (Wolfgang Denk) > 10. Re: NFS support patch (Steven Scholz) > 11. Re: telnet server on u-boot (Laurent Mohin) > 12. Re: Where can I find a libgcc.a with software FP. (Marius Groeger) > > --__--__-- > > Message: 1 > From: "Andy Hawkins" <a.hawkins(a)cabletime.com> > To: <u-boot-users(a)lists.sourceforge.net> > Subject: RE: [U-Boot-Users] Problems with u-boot, PPChameleonEVB and MontaVista kernel > Date: Tue, 24 Feb 2004 15:45:44 -0000 > > > Is there any special reason to use their kernel? What does it > contain > > that you cannot find in DAVE's / our tested and working kernel tree? > > Well, we've decided to use the MontaVista distribution / development > environment, and that integrates nicely with their kernel build tools. > There may well be features that are present in the MontaVista kernel > tree that we would like to use too (although I'd have to check the > details). I think the general feeling is that having one source for > all this is the best way to go (if we can get it to work). > > > You have to accept the fact that "similar" is not good enough. > You > > must use a kernel which has been proted to the _exact_ > matching > > board, or you will run into problems sooner or later - at least > if > > you don't understand EXACTLY what you are doing (which seems not > to > > be the case - no offence meant). > > You're absolutely right, I don't understand exactly what I'm doing :). > No offence taken whatsoever. I've read through most of 'Understanding > the Linux Kernel', but unfortunately it only covers the early kernel > boot process for the i386 architecture. Is there any other reference > that can give more information for the PowerPC? > > > Of course. You shall break compatibility to the rest of the > world > > just to make their kernel work. What a nonsense. > > > > > I do have access to a BDI2000, that I've used to break into > > a running > > > kernel (at start_here), but can't get it to break when I use the > > > MontaVista kernel. From this, I assume that it's failing somewhere > > > very early in the linux boot process. > > > > > > Can anyone offer any advice? > > > > Your question is a FAQ: > > > http://www.denx.de/twiki/bin/view/DULG/LinuxHangsAfterUncompressingKer > nel > > I've followed the information in that FAQ. However, all it tells me to > do is match up the bd_info structures, and check clock information. > > > What I cannot understand is why you are wasting your time (and > ours) if you > > have a working kernel which you can use. > > It just seems to make sense to try to keep everything (kernel, apps, > development etc.) under 'one roof' (i.e. MontaVista) if at all > possible. > > I think whichever kernel tree we use, we're going to have to do some > porting either way, so I'd appreciate some guidance as to where in the > kernel I should be looking to resolve the problems we currently have > (as I might need the knowledge gained when we come to adding further > customisations later). > > We *do* have a BDI 2000, but I think my ability to be able to debug > this problem is hindered by my limited knowledge of the kernel startup > code. > > Any pointers on how to improve that knowledge (URLs, book and the > like), with specific reference to the PowerPC processor, would be much > appreciated. > > Thanks to all who have replied thus far. > > Andy > > --__--__-- > > Message: 2 > To: u-boot-users(a)lists.sourceforge.net > Cc: Bernieshu <bernie.shu(a)smartbridges.com> > Subject: Re: [U-Boot-Users] Where can I find a libgcc.a with software FP. > From: Wolfgang Denk <wd(a)denx.de> > Date: Tue, 24 Feb 2004 16:58:14 +0100 > > In message <Pine.LNX.4.56.0402241626510.21705(a)mag.sysgo.com> Marius Groeger wrote: > > > > This is a problem with the gcc/binutils toochain, which doesn't handle > > -msoft-float the way we want it. The error you're seeing isn't really > > one, since neither the U-Boot code nor the quoted functions in > > libgcc.a actually use FP instructions. It's only the ELF binary tags > > that don't match. > > I'm not sure. I don't know for certain for ARM, but on other archi- > tectures GCC will happily generate FP instructions for example to > perform fast memory copy operations (like when assigning structures > of the "right" size). > > 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 > In 1750 Issac Newton became discouraged when he fell up a flight of > stairs. > > --__--__-- > > Message: 3 > To: "Laurent Mohin" <laurent.mohin(a)acterna.com> > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] telnet server on u-boot > From: Detlev Zundel <dzu(a)denx.de> > Date: 24 Feb 2004 17:05:32 +0100 > > Hello Laurent, > > > For some remote instruments, I need to be able to have a telnet access to > > the boot in case of my Linux kernel and file system are down (after an > > upgrade for example). > > I don't think that u-boot provide telnet support and I had a look at > > another boot project called redboot that provide such a functionality. > > I have a couple of questions : > > Does anybody see another solution than telnet to control a remote > > instrument? > > Has anybody already tried to add telnet server to u-boot? It seems to be a > > challenging task because we need to add TCP support. > > U-Boot does not contain any TCP implementation. I doubt that this > will be doable with reasonable effort. Writing a standard conform > TCP implementation is a daunting task that even many proprietary > systems could not solve, i.e. there are many TCP implementations > working well in "the lab" _only_. > > What I had in mind is a "UDP console" as it was implemented some time > ago for the Linux kernel also (there was a patch floating around). > Googling for it I found at least this link [1]. This would of course > need a "special" program to access the console but it is a much more > realistic target to aim at. > > > Has anybody used both u-boot and redboot and can point me the main > > advantages and drawbacks of both? > > Sorry, I can't help you there. > > Cheers > Detlev > > [1] http://www.linux.it/kerneldocs/sercons/sercons.html > > -- > Directories are added, deleted, and rearranged much as you would > expect, even if you don't know it's what you'd expect. > -- Tom Lord in TLA Documentation > > --__--__-- > > Message: 4 > To: Jim Xu <Jim.Xu(a)flextronics.com> > Cc: "'u-boot-users(a)lists.sourceforge.net'" <u-boot-users(a)lists.sourceforge.net> > Subject: Re: [U-Boot-Users] Compile Error > From: Wolfgang Denk <wd(a)denx.de> > Date: Tue, 24 Feb 2004 17:11:30 +0100 > > Dear Jim, > > in message <75490FAA49820647AB2BAFEFE08BFABC0CD98D(a)dalnt225.dal.flextronics.com> you wrote: > > > > I downloaded and installed the ELDK. My board is Motorola FADS860T. I did: > ... > > {standard input}:19: Error: Relocation cannot be done when using > > -mrelocatable > > Seems you are using the new (3.0) ELDK which is based on GCC-3.x with > an old version of U-boot. > > > Do I miss something in the build process? > > Your U-Boot sources are too old for this compiler. GCC-3.x requires a > few adaptions which were added in later versions of U-Boot. See for > example the source tree (1.0.2) which is included with the ELDK. > > > ------_=_NextPart_001_01C3FAEC.4DA52400 > > Content-Type: text/html; > > charset="iso-8859-1" > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > > <HTML><HEAD> > > And PLEASE do NOT post HTML!! > > 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 > The most exciting phrase to hear in science, the one that heralds new > discoveries, is not "Eureka!" (I found it!) but "That's funny ..." > -- Isaac Asimov > > --__--__-- > > Message: 5 > To: Masami Komiya <mkomiya(a)sonare.it> > Cc: Steven Scholz <steven.scholz(a)imc-berlin.de>, Wolfgang Denk > <wd(a)denx.de>, > U-BOOT-USERS <u-boot-users(a)lists.sourceforge.net> > Subject: Re: [U-Boot-Users] NFS support patch > From: Detlev Zundel <dzu(a)denx.de> > Date: 24 Feb 2004 17:13:17 +0100 > > Hi Masami & Steven, > > > I have no objection. > > > > Masami Komiya > > > > Steven Scholz wrote: > > > Hi > > > > > >>> I uploaded NFS support patch to my web site. > > >>> > > >>> http://www.sonare.it/u-boot/u-boot-nfs.patch.gz > > >> > > >> > > >> Well done, thanks a lot! > > >> > > >> Checked in. > > > I think CFG_CMD_NFS should be considered "non-standard". It does not > > > even compile for AT91RM9200. > > As long as the NFS support does not compile on all platforms it should > probably be non-standard - _iff_ it compiles on all platforms I would > certainly reconsider this as the code impact is minimal but the > feature will be very helpful (IMHO). > > But until then, Steven can you share the compile problems with us so > we can fix them? There should really be no general reason why this > should not work on ARM, or am I missing something? > > Thanks! > Detlev > > -- > Directories are added, deleted, and rearranged much as you would > expect, even if you don't know it's what you'd expect. > -- Tom Lord in TLA Documentation > > --__--__-- > > Message: 6 > From: "Andy Hawkins" <a.hawkins(a)cabletime.com> > To: <u-boot-users(a)lists.sourceforge.net> > Subject: RE: [U-Boot-Users] Problems with u-boot, PPChameleonEVB and MontaVista kernel > Date: Tue, 24 Feb 2004 16:16:09 -0000 > > > Then you will either have to move all the modifications needed > for > > the PPCHameleon board into their kernel tree (thus creating > something > > which again is not the original MV kernel), or have MV provide > a > > kernel extended in such way. > > That's what I'm expecting to have to do, but unfortunately know where > to look for the changes I need to make is difficult. > > > Yes, and this is your most pressing problem. When the > parameters > > passed to the Linux kernel are correct you will at least get > some > > boot messages, and see where the kernel crashes then (which it > will > > do). > > Well, I think I *have* matched up the two structures, but we're still > not seeing anything. Where can I put breakpoints in the kernel to try > to work out why we're not getting any boot messages? > > > I think you can use another kernel tree (like that from our > CVS > > server) without problems. If you feel you must move our patches > into > > the MV tree please feel free to do so - all the history and > comments > > are available for free on our CVS server. You can extract the > patches > > that are relevant for the PPChameleon board and try applying them > to > > the MV tree - I don't expect any serious problems there. > > At the risk of asking newbie questions, how would I go about doing > this? > > Thanks again for all the help so far, it's much appreciated. > > Andy > > --__--__-- > > Message: 7 > Date: Tue, 24 Feb 2004 17:17:27 +0100 > From: Steven Scholz <steven.scholz(a)imc-berlin.de> > CC: U-BOOT-USERS <u-boot-users(a)lists.sourceforge.net> > Subject: Re: [U-Boot-Users] NFS support patch > > Hi Detlev, > > >>>I think CFG_CMD_NFS should be considered "non-standard". It does not > >>>even compile for AT91RM9200. > >=20 > > As long as the NFS support does not compile on all platforms it should > > probably be non-standard - _iff_ it compiles on all platforms I would > > certainly reconsider this as the code impact is minimal but the > > feature will be very helpful (IMHO). > >=20 > > But until then, Steven can you share the compile problems with us so > > we can fix them? There should really be no general reason why this > > should not work on ARM, or am I missing something? > > No big deal. > There's no get_ticks() yet for AT91RM9200. I fixed that and I am about=20 > to test it and to provide a patch real soon now. > > --=20 > Steven Scholz > > imc Measurement & Control imc Me=DFsysteme GmbH > Voltastr. 5 Voltastr. 5 > 13355 Berlin 13355 Berlin > Germany Deutschland > > --__--__-- > > Message: 8 > Date: Tue, 24 Feb 2004 08:26:52 -0800 (PST) > From: sudhakar rajashekhara <rsudhakar_blr(a)yahoo.com> > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] Memory Access Problem > > Hi, > > We have ported U-boot and Linux to a custom 8280 > board. For this board, the LED base has been set at > 0x2200A000. I am able to write to this base from > U-boot using mw command and control the LED display. > But if I try to access the same memory from Linux, the > kernel is raising an exception. I even tried to map > this memory area by calling ioremap in MMU_init but > the result was same. Do I have to do any other > configuration in the Linx kernel to access this memory > area? Following is the log: > > regards, > Sudhakar. > > ======================================================= > Oops: kernel access of bad area, sig: 11 > > NIP: C0139034 XER: 00000000 LR: C0139024 SP: C05B9F90 > REGS: c05b9ee0 TRAP: 0300 > Not tainted > > MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 > > DAR: 2200A000, DSISR: 22000000 > > TASK = c05b8000[1] 'swapper' Last syscall: -1 > > last math 00000000 last altivec 00000000 > > GPR00: FFFFFFFF C05B9F90 C05B8000 C0110000 00001032 > 00000001 00000001 00000000 > > GPR08: F0000088 2200A000 C012D417 C05B9EA0 C0170000 > 00000000 10000000 00000000 > GPR24: 00000000 00000000 40000000 007FFF7E 007FFF00 > 00000000 C0170000 007FFEB0 > Call backtrace: > ======================================================= > > __________________________________ > Do you Yahoo!? > Yahoo! Mail SpamGuard - Read only the mail you want. > http://antispam.yahoo.com/tools > > --__--__-- > > Message: 9 > To: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] telnet server on u-boot > From: Wolfgang Denk <wd(a)denx.de> > Date: Tue, 24 Feb 2004 17:26:35 +0100 > > In message <87fzd04g4z.fsf(a)deepthought.outer.space.org> Detlev Zundel wrote: > > > > > For some remote instruments, I need to be able to have a telnet access to > > > the boot in case of my Linux kernel and file system are down (after an > > > upgrade for example). > > > I don't think that u-boot provide telnet support and I had a look at > > > another boot project called redboot that provide such a functionality. > > > I have a couple of questions : > > > Does anybody see another solution than telnet to control a remote > > > instrument? > > There are many solutions. You don't provide much informatiuon about > your workign environment so it is difficult to make a good recommen- > dation. Standard solutions include: use a modem to attach to the > serial console; use a terminal server to attach to the serial > console; etc. > > > What I had in mind is a "UDP console" as it was implemented some time > > ago for the Linux kernel also (there was a patch floating around). > > Googling for it I found at least this link [1]. This would of course > > need a "special" program to access the console but it is a much more > > realistic target to aim at. > > This has been discussed before indeed for U-Boot, too. Interest for > such a feature seems to pretty limited, though. > > 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 > An expert is a person who avoids the small errors while sweeping on > to the grand fallacy. > > --__--__-- > > Message: 10 > Date: Tue, 24 Feb 2004 17:37:09 +0100 > From: Steven Scholz <steven.scholz(a)imc-berlin.de> > To: Masami Komiya <mkomiya(a)sonare.it> > CC: U-BOOT-USERS <u-boot-users(a)lists.sourceforge.net> > Subject: Re: [U-Boot-Users] NFS support patch > > Masami Komiya wrote: > > > I uploaded NFS support patch to my web site. > > > > http://www.sonare.it/u-boot/u-boot-nfs.patch.gz > > > > If you are interested in, please evaluate. > > > > The most part of this is taken from etherboot. > > > > To use NFS support, add the definition CFG_CMD_NFS > > to CONFIG_COMMANDS defined in the configration file > > of your board. > > I tried it but it does not work on my ARM (AT91RM9200) board: > > multiIO> nfs 0x20500000 10.0.2.9:/opt/eldk/arm_920TDI/uImage > File transfer via NFS from server 10.0.2.9; our IP address is 10.0.9.155 > Filename '/opt/eldk/arm_920TDI/uImage'. > Load address: 0x20500000 > Loading: ################################################################# > ############################################# > done > Bytes transferred = 560892 (88efc hex) > > Fair enough so far. The length is correct. But apparently I did not > get the correct data: > > multiIO> md.w 0x20500000 > 20500000: 0500 4c89 3b40 5f7c 0000 0000 3b40 b77a ...L@;|_....@;z. > 20500010: 0000 0000 3b40 b77a 0000 0000 ffff ffff ....@;z......... > 20500020: ffff ffff ffff ffff ffff ffff ffff ffff ................ > 20500030: ffff ffff ffff ffff ffff ffff ffff ffff ................ > 20500040: ffff ffff ffff ffff ffff ffff ffff ffff ................ > 20500050: ffff ffff ffff ffff ffff ffff ffff ffff ................ > 20500060: ffff ffff ffff ffff ffff ffff ffff ffff ................ > 20500070: ffff ffff ffff ffff ffff ffff ffff ffff ................ > > But it should look like this: > > scholz@Pinguin:/opt/eldk/arm_920TDI> hexdump uImage | head > 0000000 0527 5619 1fb4 eeca 1640 146c 0800 bc8e > 0000010 0020 0080 0020 0080 455f 8430 0205 0102 > 0000020 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000040 8b1f 0808 6c13 4016 0302 696c 756e 2e78 > 0000050 6962 006e bdec 7c0d 555c 3f99 ee7e a4bc > 0000060 6493 dc9a 1264 6d08 b7a0 806d 0180 da6e > 0000070 a100 74a6 8b4a 5b54 da65 a806 3558 d140 > > What's the problem? > > -- > Steven Scholz > > imc Measurement & Control imc Me?systeme GmbH > Voltastr. 5 Voltastr. 5 > 13355 Berlin 13355 Berlin > Germany Deutschland > > --__--__-- > > Message: 11 > To: Wolfgang Denk <wd(a)denx.de> > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] telnet server on u-boot > From: "Laurent Mohin" <laurent.mohin(a)acterna.com> > Date: Tue, 24 Feb 2004 17:41:58 +0100 > > Wolfgang, > > In message above, you wrote : > > > > For some remote instruments, I need to be able to have a telnet access > to > > > the boot in case of my Linux kernel and file system are down (after an > > > > upgrade for example). > > > I don't think that u-boot provide telnet support and I had a look at > > > another boot project called redboot that provide such a functionality. > > > I have a couple of questions : > > > Does anybody see another solution than telnet to control a remote > > > instrument? > > > There are many solutions. You don't provide much informatiuon about > > your workign environment so it is difficult to make a good recommen- > > dation. Standard solutions include: use a modem to attach to the > > serial console; use a terminal server to attach to the serial > > console; etc. > > Use of a modem or a terminal server to attach to the serial console is not > a good solution for me, because I hope to deploy at least several hundred > of instruments. And the only link I have with them is thru Ethernet. > That's why I'm looking for something similar as telnet. > > Thanks for your reply, > > Laurent > > --__--__-- > > Message: 12 > Date: Tue, 24 Feb 2004 17:53:39 +0100 (CET) > From: Marius Groeger <mgroeger(a)sysgo.com> > To: Wolfgang Denk <wd(a)denx.de> > cc: u-boot-users(a)lists.sourceforge.net, > Bernieshu <bernie.shu(a)smartbridges.com> > Subject: Re: [U-Boot-Users] Where can I find a libgcc.a with software FP. > > On Tue, 24 Feb 2004, Wolfgang Denk wrote: > > > In message <Pine.LNX.4.56.0402241626510.21705(a)mag.sysgo.com> Marius Groeger wrote: > > > > > > This is a problem with the gcc/binutils toochain, which doesn't handle > > > -msoft-float the way we want it. The error you're seeing isn't really > > > one, since neither the U-Boot code nor the quoted functions in > > > libgcc.a actually use FP instructions. It's only the ELF binary tags > > > that don't match. > > > > I'm not sure. I don't know for certain for ARM, but on other archi- > > tectures GCC will happily generate FP instructions for example to > > perform fast memory copy operations (like when assigning structures > > of the "right" size). > > I'm having similar doubts, as I wrote in my previous post. Please read > it again (to the end.) > > In practice, however, I have not seen this kind of optimising as of > yet. Maybe on ARM there is no gain in performance. Unless there is a > proper (read: for all ARM architectures, and working like we know it > from powerpc-linux) -msoft-float patch for GCC 3, I'm inclined to just > (carefully) drop -msoft-float from *boot. > > I'm curious about Robert Schwebel's assessment of this issue, since I > know he's been workin on this. > > Regards, > Marius > > -- > Marius Groeger <mgroeger(a)sysgo.com> > Project Manager > > SYSGO Real-Time Solutions AG | Embedded and Real-Time Software > Am Pfaffenstein 14 > 55270 Klein-Winternheim, Germany > > Voice: +49-6136-9948-0 | FAX: +49-6136-9948-10 > www.sysgo.com | www.elinos.com | www.osek.de > > --__--__-- > > _______________________________________________ > 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

3 2

[U-Boot-Users] ARM soft float
by Robert Schwebel 25 Feb '04

25 Feb '04

Bcc: Subject: Re: [U-Boot-Users] Where can I find a libgcc.a with software FP. Reply-To: In-Reply-To: <Pine.LNX.4.56.0402241740180.787(a)mag.sysgo.com> Hi, On Tue, Feb 24, 2004 at 05:53:39PM +0100, Marius Groeger wrote: > In practice, however, I have not seen this kind of optimising as of > yet. Maybe on ARM there is no gain in performance. Unless there is a > proper (read: for all ARM architectures, and working like we know it > from powerpc-linux) -msoft-float patch for GCC 3, I'm inclined to just > (carefully) drop -msoft-float from *boot. How do you handle the ARM variants which have a hardware FPU then? I didn't work with a cpu which has one yet, but there are some out there. > I'm curious about Robert Schwebel's assessment of this issue, since I > know he's been workin on this. We should probably discuss that on crossgcc as there are others like Benedikt Spranger, Marc Kleine-Budde and Dan Kegel, who may give better comments on this than me, I didn't have time to investigate the problem further than trying Nico's patch and integrate it into PTXdist. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4

2 1

[U-Boot-Users] Adding is_console_quiet() to support runtime changes in console output
by Jon Diekema 25 Feb '04

25 Feb '04

Product: - u-boot Version: - 1.0.2 CHANGELOG: * Patch by Jon Diekema, 24 Jeb 2004: - Adding is_console_quiet() to support runtime changes in console output CVS Comments: - Adding the CFG_CONSOLE_IS_QUIET option to support runtime changes in console output. The is_console_quiet() function is used to determine the status of quiet mode. Quiet mode is based on the value of the "quiet" environment variable. Non-zero values indicate that quiet mode is active. Patched files: - README - include/console.h - common/console.c - common/cmd_nvedit.c

2 1

[U-Boot-Users] Fix NFS support bug
by Masami Komiya 24 Feb '04

24 Feb '04

I forget to update the variable NetBootFileXferSize in store_block() and misunderstood about the message "Bytes transferred ..." at the end of file tranfer. Please apply this patch if you want to use NFS file download. Masami Komiya @ Tokyo.JP

2 1

Re: [U-Boot-Users] U-Boot and S3c2410
by asnua＠eircom.net 24 Feb '04

24 Feb '04

Wolfgang/Gerrit/Matt, Thanks for your help.... I think that I finally figured out how to boot the kernel. I looked at the definitions for ZTEXTADDR and ZRELADDR and found that they were at 0x30008000. So I made my load and entry points to be that address. I then offset my tftp address so that it would not overwrite 0x30008000. Unfortunately, it dies after I get the message... Uncompressing Linux.... done, booting the kernel. SMDK2410 # tftpboot 30a00000 myzImage.img TFTP from server 192.xxx.xx.xx; our IP address is 192.xxx.xx.xx Filename 'myzImage.img'. Load address: 0x30a00000 Loading: ################################################################# ################################################################# done Bytes transferred = 662556 (a1c1c hex) SMDK2410 # bootm ## Booting image at 30a00000 ... Image Name: 2.4.18 kernel Created: 2004-02-24 17:33:16 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 662492 Bytes = 647 kB Load Address: 30008000 Entry Point: 30008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux................................................ done, bootin g the kernel. >From what I've read on this list it now looks like the kernel is getting the wrong info passed. Thanks again, Dave Wolfgang Denk <wd(a)denx.de> wrote: < < In message <1077551762.4835.50.camel@nios> you wrote: < > I'm far from an expert on the matter ;) < > But I would try to set the addresses to 0x30000000 then. The kernel will < < This depends on how the kernel was linked. < < > be expanded to RAM first and then a jump will be made to the address in < > the RAM to start executing the kernel. < > < > In my situation, I used 0x0 as start/entry. RAM starts on that address < > too. < < This is correct on PowerPC, but wrong on all other systems. < < The address to be used is defined in the Linux kernel's linker < commands / scripts; seach which value of PTEXTADDR gets defined in < "arch/arm/Makefile" for your board; in your "arch/arm/boot/Makefile" < you should then have a build target like this: < < uImage: compressed/piggy.gz < mkimage -A arm -O linux -T kernel -C gzip \ < -a $(PTEXTADDR) -e $(PTEXTADDR) \ < -n 'ARM Linux-$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)' \ < -d compressed/piggy.gz $@ < < < 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 < It may be that your whole purpose in life is simply to serve as a < warning to others. <

1 0

RE: [U-Boot-Users] telnet server on u-boot
by VanBaren, Gerald (AGRE) 24 Feb '04

24 Feb '04

I've used UDP packets on other projects using NetCat (nc -u) http://netcat.sourceforge.net/ to give me an interactive console over UDP. This works really well for command/response type interaction. It works less well on console messages type interactions when the embedded system is spontaneously sending print messages. Since UDP is connectionless, you need to determine when and to whom to send print messages. As I see it, there are a couple of options: 1) Use an environment variable to set the IP address and the port of the destination. If the env var doesn't exist or is set to 0, suppress the UDP packets. Note that this would allow the destination to be the broadcast IP address which would be good for capturing packets, and especially usefull for using a host to log them, but bad if you have lots of embedded systems all spewing lots of messages. It would also allow the embedded system to target a given host. 2) If the embedded system receives a packet on the console UDP port, send all console packets back to the sender. This would allow the interaction to be triggered by an arbitrary host, but would require that host to knock on the door of the embedded system first (not good for initial power up messages). My preference would be #1. gvb > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Laurent > Mohin > Sent: Tuesday, February 24, 2004 11:42 AM > To: Wolfgang Denk > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] telnet server on u-boot > > > Wolfgang, > > In message above, you wrote : > > > > For some remote instruments, I need to be able to have a > telnet access > to > > > the boot in case of my Linux kernel and file system are > down (after an > > > > upgrade for example). > > > I don't think that u-boot provide telnet support and I > had a look at > > > another boot project called redboot that provide such a > functionality. > > > I have a couple of questions : > > > Does anybody see another solution than telnet to control a remote > > > instrument? > > > There are many solutions. You don't provide much > informatiuon about > > your workign environment so it is difficult to make a good > recommen- > > dation. Standard solutions include: use a modem to > attach to the > > serial console; use a terminal server to attach to > the serial > > console; etc. > > Use of a modem or a terminal server to attach to the serial > console is not > a good solution for me, because I hope to deploy at least > several hundred > of instruments. And the only link I have with them is thru Ethernet. > That's why I'm looking for something similar as telnet. > > Thanks for your reply, > > Laurent > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0

[U-Boot-Users] Problems with u-boot, PPChameleonEVB and MontaVista kernel
by Andy Hawkins 24 Feb '04

24 Feb '04

Hi all, I'm trying to get up and running with u-boot on a PPChameleonEVB, running the MontaVista kernel. I can successfully compile u-boot 1.0.0-pre and the kernel that came with the board (2.4.20 from the eldk), and boot the board successfully. However, when I try to compile the MontaVista kernel, the board will not boot. Their kernel doesn't directly support the PPChameleonEVB, so I'm using the one for the IBM 405EP eval (which the PPChameleon appears to be very similar to). I'm 'manually' running make pImage to build the kernel after the MontaVista targetconf tool has run the build, and booting from vmlinux.PPCBoot using tftp. I've been in touch with MontaVista, and they suggest re-building u-boot, but changing the definition of the bd_info struction (in include/asm-ppc/u-boot.h) to match that in the kernel. I've done this, but the boot still stops in the same place. I've compiled u-boot in debug mode, and this is what we see: reset U-Boot 1.0.0-pre (Feb 24 2004 - 10:11:24) CPU: IBM PowerPC 405EP Rev. B at 133.333 MHz (PLB=133, OPB=66, EBC=33 MHz) IIC Boot EEPROM disabled PCI async ext clock used, internal PCI arbiter enabled 16 kB I-Cache 16 kB D-Cache Board: ### No HW ID - assuming PPChameleonEVB I2C: ready DRAM: 32 MB Top of RAM usable for U-Boot at: 02000000 Reserving 182k for U-Boot at: 01fd2000 Reserving 257k for malloc() at: 01f91900 Reserving 132 Bytes for Board Info at: 01f9187c Reserving 48 Bytes for Global Data at: 01f9184c Stack Pointer at: 01f91828 New Stack Pointer is: 01f91828 Now running in RAM - U-Boot at: 01fd2000 FLASH: 4 MB U-Boot relocated to 01fd2000 NAND:Probing at 0xff000000 32 MB ### main_loop entered: bootdelay=10 ### main_loop: bootcmd="run nfsargs addip addcons;bootm $(kernel_addr)" Hit any key to stop autoboot: 10 0 => run net_selc f ENET Speed is 10 Mbps - HALF duplex connection TFTP from server 191.53.51.21; our IP address is 191.53.51.200 Filename 'vmlinux.PPCBoot'. Load address: 0x200000 Loading: [snip tftp progress] done Bytes transferred = 629509 (99b05 hex) ## Booting image at 00200000 ... Image Name: Linux-2.4.18_mvl30-405ep_eval Created: 2004-02-24 10:18:07 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 629445 Bytes = 614.7 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x01F911D8 => set upper limit to 0x00800000 ## cmdline at 0x007FFF00 ... 0x007FFF70 bd address = 0x01F9187C memstart = 0x00000000 memsize = 0x02000000 flashstart = 0xFFFC0000 flashsize = 0x00400000 flashoffset = 0x00029B00 sramstart = 0x00000000 sramsize = 0x00000000 bootflags = 0x0000A000 procfreq = 133.333 MHz plb_busfreq = 133.333 MHz pci_busfreq = 33.333 MHz ethaddr = 00:50:C2:1E:AF:FE eth1addr = 00:50:C2:1E:AF:FD IP addr = 191.53.51.200 baudrate = 115200 bps ## Loading RAMDisk Image at ffd00000 ... Image Name: Simple Embedded Linux Framework Created: 2002-10-24 9:30:38 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 1476478 Bytes = 1.4 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## initrd at 0xFFD00040 ... 0xFFE687BD (len=1476478=0x16877E) Loading Ramdisk to 01e28000, end 01f9077e ... OK ## Transferring control to Linux (at address 00000000) ... I do have access to a BDI2000, that I've used to break into a running kernel (at start_here), but can't get it to break when I use the MontaVista kernel. From this, I assume that it's failing somewhere very early in the linux boot process. Can anyone offer any advice? Many thanks. Andy

4 15

[U-Boot-Users] Memory Access Problem
by sudhakar rajashekhara 24 Feb '04

24 Feb '04

Hi, We have ported U-boot and Linux to a custom 8280 board. For this board, the LED base has been set at 0x2200A000. I am able to write to this base from U-boot using mw command and control the LED display. But if I try to access the same memory from Linux, the kernel is raising an exception. I even tried to map this memory area by calling ioremap in MMU_init but the result was same. Do I have to do any other configuration in the Linx kernel to access this memory area? Following is the log: regards, Sudhakar. ======================================================= Oops: kernel access of bad area, sig: 11 NIP: C0139034 XER: 00000000 LR: C0139024 SP: C05B9F90 REGS: c05b9ee0 TRAP: 0300 Not tainted MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 2200A000, DSISR: 22000000 TASK = c05b8000[1] 'swapper' Last syscall: -1 last math 00000000 last altivec 00000000 GPR00: FFFFFFFF C05B9F90 C05B8000 C0110000 00001032 00000001 00000001 00000000 GPR08: F0000088 2200A000 C012D417 C05B9EA0 C0170000 00000000 10000000 00000000 GPR24: 00000000 00000000 40000000 007FFF7E 007FFF00 00000000 C0170000 007FFEB0 Call backtrace: ======================================================= __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools

2 1

RE: [U-Boot-Users] Memory Access Problem
by Muhammad Sarwar 24 Feb '04

24 Feb '04

kernel is not be mapping this address (0x2200A000) by itself. As you're mapping LED base to a user space virtual address, the easiest solution would be if you can have your LED base at physical in the already mapped range. Somewhere above 0xe0000000 for example. Then you'll have phys=virtual...no mapping required. Another way is to map LED base where it is physically but have it mapped somewhere for example above 0xf0000000 and then you have to change the mapping in the xxxx_map_io() function in arch/ppc/kernel/xxxx_setup.c to account for this. Regards, Muhammad Sarwar Mangrove Systems Inc. -----Original Message----- From: sudhakar rajashekhara [mailto:rsudhakar_blr@yahoo.com] Sent: Tuesday, February 24, 2004 11:27 AM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] Memory Access Problem Hi, We have ported U-boot and Linux to a custom 8280 board. For this board, the LED base has been set at 0x2200A000. I am able to write to this base from U-boot using mw command and control the LED display. But if I try to access the same memory from Linux, the kernel is raising an exception. I even tried to map this memory area by calling ioremap in MMU_init but the result was same. Do I have to do any other configuration in the Linx kernel to access this memory area? Following is the log: regards, Sudhakar. ======================================================= Oops: kernel access of bad area, sig: 11 NIP: C0139034 XER: 00000000 LR: C0139024 SP: C05B9F90 REGS: c05b9ee0 TRAP: 0300 Not tainted MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 2200A000, DSISR: 22000000 TASK = c05b8000[1] 'swapper' Last syscall: -1 last math 00000000 last altivec 00000000 GPR00: FFFFFFFF C05B9F90 C05B8000 C0110000 00001032 00000001 00000001 00000000 GPR08: F0000088 2200A000 C012D417 C05B9EA0 C0170000 00000000 10000000 00000000 GPR24: 00000000 00000000 40000000 007FFF7E 007FFF00 00000000 C0170000 007FFEB0 Call backtrace: ======================================================= __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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] Where can I find a libgcc.a with software FP.
by Bernieshu 24 Feb '04

24 Feb '04

Hi, all. Where can I find a suitable u-boot compiler for ixp425? I once downloaded cross-compiler from ftp://ftp.arm.linux.org.uk/pub/armlinux/toolchain, and www.snapgear.com. They complain the similar issue as following. Mainly it is the libgcc.a did not support software FP. Can anybody give some info on this? arm-linux-ld: ERROR: /usr/local/lib/gcc-lib/arm-linux/3.3.2/be/libgcc.a(_udivsi3.o) uses hardware FP, whereas u-boot uses software FP File in wrong format: failed to merge target specific data of file /usr/local/lib/gcc-lib/arm-linux/3.3.2/be/libgcc.a(_udivsi3.o)

3 4

Re: [U-Boot-Users] telnet server on u-boot
by Laurent Mohin 24 Feb '04

24 Feb '04

Wolfgang, In message above, you wrote : > > For some remote instruments, I need to be able to have a telnet access to > > the boot in case of my Linux kernel and file system are down (after an > > upgrade for example). > > I don't think that u-boot provide telnet support and I had a look at > > another boot project called redboot that provide such a functionality. > > I have a couple of questions : > > Does anybody see another solution than telnet to control a remote > > instrument? > There are many solutions. You don't provide much informatiuon about > your workign environment so it is difficult to make a good recommen- > dation. Standard solutions include: use a modem to attach to the > serial console; use a terminal server to attach to the serial > console; etc. Use of a modem or a terminal server to attach to the serial console is not a good solution for me, because I hope to deploy at least several hundred of instruments. And the only link I have with them is thru Ethernet. That's why I'm looking for something similar as telnet. Thanks for your reply, Laurent

1 0

[U-Boot-Users] telnet server on u-boot
by Laurent Mohin 24 Feb '04

24 Feb '04

Hello all, For some remote instruments, I need to be able to have a telnet access to the boot in case of my Linux kernel and file system are down (after an upgrade for example). I don't think that u-boot provide telnet support and I had a look at another boot project called redboot that provide such a functionality. I have a couple of questions : Does anybody see another solution than telnet to control a remote instrument? Has anybody already tried to add telnet server to u-boot? It seems to be a challenging task because we need to add TCP support. Has anybody used both u-boot and redboot and can point me the main advantages and drawbacks of both? Thanks for replying, Laurent MOHIN ACTERNA

3 2

[U-Boot-Users] Compile Error
by Jim Xu 24 Feb '04

24 Feb '04

Howdy, I downloaded and installed the ELDK. My board is Motorola FADS860T. I did: install ppc_8xx in ELDK, make FADS860T_config in U-Boot, make all. Here is what I got: ppc_8xx-gcc -g -Os -mrelocatable -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0x02800000 -I/opt/daljxu/u-boot/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/daljxu/ELDK/usr/bin/../lib/gcc-lib/ppc-linux/3.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8xx -ffixed-r2 -ffixed-r29 -mstring -mcpu=860 -msoft-float -Wall -Wstrict-prototypes -c -o timer.o timer.c {standard input}: Assembler messages: {standard input}:19: Error: Relocation cannot be done when using -mrelocatable make[1]: *** [timer.o] Error 1 rm sched.o hello_world.o make[1]: Leaving directory `/mnt/sda/daljxu/u-boot/u-boot-1.0.0/examples' make: *** [subdirs] Error 1 Do I miss something in the build process? Thanks, Jim _________________________ Jim Xu, SMTS-SW Flextronics International Phone: (469) 229-2154 Email: jim.xu(a)flextronics.com <mailto:jim.xu@flextronics.com>

2 1

[U-Boot-Users] new board support: eXalion platform
by Demke, Torsten 24 Feb '04

24 Feb '04

Message re-send because first attachement was too big! Hello Wolfgang, attached you can find the board support for our "eXalion" platform. CPU: MPC824x CHANGELOG: * Patch by Torsten Demke, 24 Feb 2004: Add support for the eXalion platform (SPSW-8240, F-30, F-300) Best regards, Torsten Torsten Demke Software Engineer Force Computers GmbH - A Solectron Company - Lilienthalstr. 15 D-85579 Neubiberg/München Tel. ++49/89/60814-404 Fax ++49/89/60814-112 mailto:torsten.demke@fci.com www.forcecomputers.com

1 0

[U-Boot-Users] RE: running custom apps under uboot
by Sonia Martinez 24 Feb '04

24 Feb '04

Hi, We had a similar problem some time ago (see https://sourceforge.net/mailarchive/forum.php?thread_id=3802343&forum_id=12… ).. and thanks to those answers we succeeded in making hello_world work. We changed the U-boot/examples/makefile file like this: ifeq ($(ARCH),arm) LOAD_ADDR = 0x40000 endif Because, by default, the load address was 0xc100000, and in our platform there was no memory at this location. We got the hello_world.bin and burnt it in Flash (in 0x00040000) using JFlash. Then only type: go 40000 Hello World!! We have a PXA250 based platform, you'll have to do something similar with your arquitecture.. Hope this helps!! Best regards Sonia

2 1

[U-Boot-Users] What areas of SDRAM are used by u-boot
by Shlomo_Kut＠mksinst.com 24 Feb '04

24 Feb '04

Hi, I am trying to define the area of SDRAM that is to be tested using mtest. How can I determine what areas of SDRAM are used by u-boot so I don't trample on it by mistake? regards Shlomo Kut Software Engineer MKS Instruments Tenta Products Tel: 972-8-9181015 Fax: 972-8-9181020 www.mksinst.com

1 0

[U-Boot-Users] How can I test my second serial port under u-boot
by Shlomo_Kut＠mksinst.com 24 Feb '04

24 Feb '04

Hi, We are in the process of bringing up our new board and we need to be able to test the second serial port i.e. ttyS1. Is there any command that we can use in u-boot to test this? regards Shlomo Kut Software Engineer MKS Instruments Tenta Products Tel: 972-8-9181015 Fax: 972-8-9181020 www.mksinst.com

1 0

RE: [U-Boot-Users] patch for OMAP1610 board
by Gupta, Kshitij 24 Feb '04

24 Feb '04

hi Wolfgang, We shifted some IRQ specific code (which is more board specific) to the platform.S file. The watchdog reset code was already there in platform.S file, so just removed the duplicate code from start.S :). This makes the cpu specific file more usable for other boards based on arm926. regards -kshitij -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Wolfgang Denk Sent: Tuesday, February 24, 2004 4:53 AM To: Rahul Shanbhag Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] patch for OMAP1610 board Dear Rahul, in message <000001c3f6bc$85c39da0$0953579d@a0875497> you wrote: > > I am submitting a patch for u-boot on 1610 innovator with some corrections > in start.S file(arm926ejs cpu) and platform.S file (1610 innovator board). > This patch moves some board specific initializations from the cpu specific > file to the board specific file. I see that you not only shift code, but also removed the code to disable the watchdog. Is this intentionally? Shouldn't we keep this part of the code somewhere, at least when CONFIG_WATCHDOG is not defined? 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 The more we disagree, the more chance there is that at least one of us is right. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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] [PATCH] New board support for the Xilinx ML300 platform
by Peter Ryser 24 Feb '04

24 Feb '04

At ftp://customer:xilinx@ftp.xilinx.com/upload/ml300.patch.gz find a patch that adds support for the Xilinx ML300 platform to U-Boot. Some documentation is provided in doc/README.ml300. The CHANGELOG entry is attached to this email. Please apply the patch to the repository. Thanks and with best regards, - Peter * Patch by Peter Ryser, 20 Feb 2004: Add support for the Xilinx ML300 platform (http://www.xilinx.com/ml300).

4 16

[U-Boot-Users] running custom apps under uboot
by himbA 24 Feb '04

24 Feb '04

hi I would like to code standalone app under uboot that would test my eth chip. I tried running hello_world.srec from ram location and I got 'prefetch abort' on go. My procedure follows: tftp a0100000 hello_world.srec go a0140004 test test2 (go a0100000 test test2) address value for go is memory location plus offset defined in Makefile. Both go commands yield an error and reset the board. I would like to know what file and how to modify it to get standalone programs running from memory. regards, himba

3 4

[U-Boot-Users] 答复: [U-Boot-Users] U-Boot and IOP80321
by kelphon.Tang (唐天兵) 24 Feb '04

24 Feb '04

Dear wolfgang, I think there are many people need such function, and I want to setup a team to porting iop80321 for u-boot. Dear all, any suggests will be a good think. and I need your help. > Happy Work, Happy Life ;) > ------------------------------------------- > Kelphon Tang > SW2, DSBU > MiTAC Research(shanghai) LTD. > Tel: 86-21-62479332 ext:2238 > Fax: 86-21-62479474 -----原始?件----- ?件人: Wolfgang Denk [mailto:wd@denx.de] ?送??: 2004年2月23日 17:57 收件人: kelphon.Tang (昄毞條) 主?: Re: [U-Boot-Users] U-Boot and IOP80321 In message <2D0FAB2B2342734183F200047F996CF08415F2(a)mrsmail.mitac.com.cn> you wrote: > > I am dev a board base on Intel's 80321 CPU, and I am not sure if the > u-boot can support such board. U-Boot supports XScale processrs, so a port to the 80321 should be pretty straightforward. > have anyone done such work to porting u-boot support this board now? No. > or I can get some document about u-boot and 80321? because I have > review U-Boot's document, I don't find document about this You will have to perform the port yourself. > ------_=_NextPart_001_01C3F9EC.13146E50 > Content-Type: text/html; > charset="big5" > Content-Transfer-Encoding: quoted-printable > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> Please do NOT post HTML!!! Post plain text only! 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 Too many people are ready to carry the stool when the piano needs to be moved.

2 1

[U-Boot-Users] patch to tftp.c
by Josh Fryman 24 Feb '04

24 Feb '04

this patch for "tftp.c" fixes a logical error in the prior implementation supporting direct-tftp-to-flash. this puts in some additional safety checks to make sure you don't cross a flash boundary during the course of a write. this will catch such actions before starting, and complain verbosely about what the actual problem is. -josh

2 1

[U-Boot-Users] patch to net.c
by Josh Fryman 24 Feb '04

24 Feb '04

this patch fixes "DEBUG" information so it's set based on the global DEBUG flag. it also makes the debug printing consistent with other parts of the code tree. -josh

2 1

[U-Boot-Users] patch to common.h
by Josh Fryman 24 Feb '04

24 Feb '04

here's a small patch that permits stringification in an ISO C portable way. eg, you can have #define FOO xyzabc and someplace else call Xstr(FOO) which will literally be replaced with "xyzabc" this was very useful in a couple of key places in some other patches and new-platform support. -josh

2 1

[U-Boot-Users] patch to LUBBOCK files
by Josh Fryman 24 Feb '04

24 Feb '04

with the prior changes in the lan91c96.c files, it requires a very small change in the lubbock header file (configs/lubbock.h). this adds a #define for the attribute address space for the lan chip. -josh

2 1

[U-Boot-Users] patch for SMsC 91C96 ethernet driver
by Josh Fryman 24 Feb '04

24 Feb '04

hi all, attached is a patch for lan91c96.c, a network driver apparently only used by the lubbock board and my platform port. the patch does a variety of things. i'd appreciate feedback, corrections, reports of breakage, etc. i'm also not sure that this is necessarily the "best" solution for some of the problems we had. - support little-endian mode to push MAC address correctly - removal of the hard-coded "attribute space" and replacement with a #define constant - clean up the hardware-init, smc-open, and smc-enable to more closely follow the manual in how to set parameters - a couple of minor cleanups -josh

2 1

[U-Boot-Users] patch for SMsC LAN91C96 driver header
by Josh Fryman 24 Feb '04

24 Feb '04

this is a corresponding patch for the header file, a couple of minor tweaks. -josh

2 1

[U-Boot-Users] patch for dlmalloc.c
by Josh Fryman 24 Feb '04

24 Feb '04

attached is a patch to permit debug info in dlmalloc.c. comments? -josh

2 1

[U-Boot-Users] small AT91RM9200 ethernet patch
by Steven Scholz 24 Feb '04

24 Feb '04

Hi there, please consider the attached patch. * Patch by Steven Scholz, 20 Feb 2004: - Add support for MII commands on AT91RM9200 boards - some cleanup in AT91RM9200 ethernet code -- Steven Scholz imc Measurement & Control imc Meßsysteme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin 13355 Berlin Germany Deutschland Index: cpu/at91rm9200/at91rm9200_ether.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/cpu/at91rm9200/at91rm9200_ether.c,v retrieving revision 1.3 diff -p -u -r1.3 at91rm9200_ether.c --- cpu/at91rm9200/at91rm9200_ether.c 19 Oct 2003 23:22:11 -0000 1.3 +++ cpu/at91rm9200/at91rm9200_ether.c 20 Feb 2004 14:14:05 -0000 @@ -310,8 +310,9 @@ static UCHAR at91rm9200_EmacReadPhy (AT9 unsigned short *pInput) { p_mac->EMAC_MAN = (AT91C_EMAC_HIGH & ~AT91C_EMAC_LOW) | - (AT91C_EMAC_CODE_802_3) | (AT91C_EMAC_RW_R) | - (RegisterAddress << 18); + (AT91C_EMAC_RW_R) | + (RegisterAddress << 18) | + (AT91C_EMAC_CODE_802_3); udelay (10000); @@ -421,8 +422,14 @@ int eth_init (bd_t * bd) p_mac->EMAC_RBQP = (long) (&rbfdt[0]); p_mac->EMAC_RSR &= ~(AT91C_EMAC_RSR_OVR | AT91C_EMAC_REC | AT91C_EMAC_BNA); - p_mac->EMAC_CFG = (p_mac->EMAC_CFG | AT91C_EMAC_CAF | AT91C_EMAC_NBC | AT91C_EMAC_RMII) + + p_mac->EMAC_CFG = (p_mac->EMAC_CFG | AT91C_EMAC_CAF | AT91C_EMAC_NBC) & ~AT91C_EMAC_CLK; + +#ifdef CONFIG_AT91C_USE_RMII + p_mac->EMAC_CFG |= AT91C_EMAC_RMII; +#endif + p_mac->EMAC_CTL |= AT91C_EMAC_TE | AT91C_EMAC_RE; return 0; @@ -462,5 +469,25 @@ int eth_rx (void) void eth_halt (void) { }; + +#if (CONFIG_COMMANDS & CFG_CMD_MII) +int miiphy_read(unsigned char addr, unsigned char reg, unsigned short * value) +{ + at91rm9200_EmacEnableMDIO (p_mac); + at91rm9200_EmacReadPhy (p_mac, reg, value); + at91rm9200_EmacDisableMDIO (p_mac); + return 0; +} + +int miiphy_write(unsigned char addr, unsigned char reg, unsigned short value) +{ + at91rm9200_EmacEnableMDIO (p_mac); + at91rm9200_EmacWritePhy (p_mac, reg, &value); + at91rm9200_EmacDisableMDIO (p_mac); + return 0; +} +#endif /* CONFIG_COMMANDS & CFG_CMD_MII */ + #endif /* CONFIG_COMMANDS & CFG_CMD_NET */ + #endif /* CONFIG_DRIVER_ETHER */ Index: include/configs/at91rm9200dk.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/configs/at91rm9200dk.h,v retrieving revision 1.5 diff -p -u -r1.5 at91rm9200dk.h --- include/configs/at91rm9200dk.h 6 Dec 2003 23:55:11 -0000 1.5 +++ include/configs/at91rm9200dk.h 20 Feb 2004 14:14:05 -0000 @@ -112,6 +116,7 @@ #define CONFIG_DRIVER_ETHER #define CONFIG_NET_RETRY_COUNT 20 +#define CONFIG_AT91C_USE_RMII #define CONFIG_HAS_DATAFLASH 1 #define CFG_SPI_WRITE_TOUT (5*CFG_HZ)

2 1

[U-Boot-Users] Re: [PATCH] New board support for the Xilinx ML300 platform
by Wolfgang Denk 24 Feb '04

24 Feb '04

Dear Peter, in message <40362618.2080806(a)xilinx.com> you wrote: > > in the attachment find the gzipped patch that adds support for the > Xilinx ML300 platform to U-Boot. Some documentation is provided in > doc/README.ml300. > > The CHANGELOG entry is also attached. > > Please apply this patch to the repository. Added. Thanks a lot! 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 No, I'm not going to explain it. If you can't figure it out, you didn't want to know anyway... :-) - Larry Wall in <1991Aug7.180856.2854(a)netlabs.com>

1 0

[U-Boot-Users] [PATCH] Nios: WATCHDOG preparation
by Stephan Linz 24 Feb '04

24 Feb '04

Hi all, attached patch includes the WATCHDOG_RESET() macro at some more points in U-Boot so I can use it in my upcoming new Nios board support. Please, merge it with current CVS tree -- thanks. -- Best regards, Stephan Linz

2 4

[U-Boot-Users] patch for dlmalloc.c and cfi_flash.c
by Josh Fryman 24 Feb '04

24 Feb '04

hi all, attached is a patch for two different quick fixes. dlmalloc: enable the debug data. instead of having #if0 everywhere, replace with #ifdef DEBUG. cfi_flash: i shared this patch with brad, and he asked i send it on. he's going to try to find a better long-term solution. for the CFI interface to support little-endian, it does byte swapping. unfortunately, the byte-swapping was only coded for 16-bit width. this corrects the coding to be more "correct" and adds 32-bit support. comments? -josh

2 1

[U-Boot-Users] SystemACE Patch
by Stephen Williams 24 Feb '04

24 Feb '04

Are there problems with the last iteration of my SystemACE support patch? After the last attempt, I didn't hear any complaints about formatting, so in case I just got lost in the frey, here again is my SystemACE support. -- Steve Williams "The woods are lovely, dark and deep. steve at XXXXXXXXXX But I have promises to keep, http://www.XXXXXXXXXX and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." diff -purN -xEntries -x'*.orig' u-boot.orig/README u-boot/README --- u-boot.orig/README 2004-02-08 14:55:39.000000000 -0800 +++ u-boot/README 2004-02-09 16:06:41.000000000 -0800 @@ -1410,6 +1410,20 @@ The following options need to be configu allows to read/write in Dataflash via the standard commands cp, md... +- SystemACE Support: + CONFIG_SYSTEMACE + + Adding this option adds support for Xilinx SystemACE + chips attached via some sort of local bus. The address + of the chip must alsh be defined in the + CFG_SYSTEMACE_BASE macro. For example: + + #define CONFIG_SYSTEMACE + #define CFG_SYSTEMACE_BASE 0xf0000000 + + When SystemACE support is added, the "ace" device type + becomes available to the fat commands, i.e. fatls. + - Show boot progress: CONFIG_SHOW_BOOT_PROGRESS diff -purN -xEntries -x'*.orig' u-boot.orig/common/Makefile u-boot/common/Makefile --- u-boot.orig/common/Makefile 2004-01-06 14:38:21.000000000 -0800 +++ u-boot/common/Makefile 2004-02-03 17:41:27.000000000 -0800 @@ -28,7 +28,7 @@ LIB = libcommon.a AOBJS = COBJS = main.o ACEX1K.o altera.o bedbug.o \ - cmd_autoscript.o \ + cmd_ace.o cmd_autoscript.o \ cmd_bdinfo.o cmd_bedbug.o cmd_bmp.o cmd_boot.o cmd_bootm.o \ cmd_cache.o cmd_console.o \ cmd_date.o cmd_dcr.o cmd_diag.o cmd_doc.o cmd_dtt.o \ diff -purN -xEntries -x'*.orig' u-boot.orig/common/cmd_ace.c u-boot/common/cmd_ace.c --- u-boot.orig/common/cmd_ace.c 1969-12-31 16:00:00.000000000 -0800 +++ u-boot/common/cmd_ace.c 2004-02-04 18:46:50.000000000 -0800 @@ -0,0 +1,205 @@ +/* + * Copyright (c) 2004 Picture Elements, Inc. + * Stephen Williams (XXXXXXXXXXXXXXXX) + * + * This source code is free software; you can redistribute it + * and/or modify it in source code form under the terms of the GNU + * General Public License as published by the Free Software + * Foundation; either version 2 of the License, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + */ +#ident "$Id:$" + +/* + * The Xilinx SystemACE chip support is activated by defining + * CONFIG_SYSTEMACE to turn on support, and CFG_SYSTEMACE_BASE + * to set the base address of the device. This code currently + * assumes that the chip is connected via a byte-wide bus. + * + * The CONFIG_SYSTEMACE also adds to fat support the device class + * "ace" that allows the user to execute "fatls ace 0" and the + * like. This works by making the systemace_get_dev function + * available to cmd_fat.c:get_dev and filling in a block device + * description that has all the bits needed for FAT support to + * read sectors. + */ + +# include <common.h> +# include <command.h> +# include <systemace.h> +# include <part.h> +# include <asm/io.h> + +#ifdef CONFIG_SYSTEMACE + +/* + * The ace_readw and writew functions read/write 16bit words, but the + * offset value is the BYTE offset as most used in the Xilinx + * datasheet for the SystemACE chip. The CFG_SYSTEMACE_BASE is defined + * to be the base address for the chip, usually in the local + * peripheral bus. + */ +static unsigned ace_readw(unsigned offset) +{ + return readw(CFG_SYSTEMACE_BASE+offset); +} + +static unsigned ace_writew(unsigned val, unsigned offset) +{ + writew(val, CFG_SYSTEMACE_BASE+offset); +} + +/* */ + +static unsigned long systemace_read(int dev, + unsigned long start, + unsigned long blkcnt, + unsigned long *buffer); + +static block_dev_desc_t systemace_dev = {0}; + +static int get_cf_lock(void) +{ + int retry = 10; + + /* CONTROLREG = LOCKREG */ + ace_writew(0x0002, 0x18); + + /* Wait for MPULOCK in STATUSREG[15:0] */ + while (! (ace_readw(0x04) & 0x0002)) { + + if (retry < 0) + return -1; + + udelay(100000); + retry -= 1; + } + + return 0; +} + +static void release_cf_lock(void) +{ + /* CONTROLREG = none */ + ace_writew(0x0000, 0x18); +} + +block_dev_desc_t * systemace_get_dev(int dev) +{ + /* The first time through this, the systemace_dev object is + not yet initialized. In that case, fill it in. */ + if (systemace_dev.blksz == 0) { + systemace_dev.if_type = IF_TYPE_UNKNOWN; + systemace_dev.part_type = PART_TYPE_UNKNOWN; + systemace_dev.type = DEV_TYPE_HARDDISK; + systemace_dev.blksz = 512; + systemace_dev.removable = 1; + systemace_dev.block_read = systemace_read; + } + + return &systemace_dev; +} + +/* + * This function is called (by dereferencing the block_read pointer in + * the dev_desc) to read blocks of data. The return value is the + * number of blocks read. A zero return indicates an error. + */ +static unsigned long systemace_read(int dev, + unsigned long start, + unsigned long blkcnt, + unsigned long *buffer) +{ + unsigned val; + int retry; + unsigned char*dp = (unsigned char*)buffer; + + if (get_cf_lock() < 0) { + unsigned status = ace_readw(0x04); + + /* If CFDETECT is false, card is missing. */ + if (! (status&0x0010)) { + printf("** CompactFlash card not present. **\n"); + return 0; + } + + printf("**** ACE locked away from me (STATUSREG=%04x)\n", status); + return 0; + } + + retry = 2000; + for (;;) { + unsigned val = ace_readw(0x04); + + /* If CFDETECT is false, card is missing. */ + if (! (val & 0x0010)) { + printf("**** ACE CompactFlash not found.\n"); + release_cf_lock(); + return 0; + } + + /* If RDYFORCMD, then we are ready to go. */ + if (val & 0x0100) + break; + + if (retry < 0) { + printf("**** SystemACE not ready.\n"); + release_cf_lock(); + return 0; + } + + udelay(1000); + retry -= 1; + } + + /* Write LBA block address */ + ace_writew(start & 0xffff, 0x10); + start >>= 16; + ace_writew(start & 0xff, 0x12); + + /* Write sector count | ReadMemCardData. */ + ace_writew(blkcnt | 0x0300, 0x14); + + /* CONTROLREG = CFGRESET|LOCKREQ */ + ace_writew(0x0082, 0x18); + + retry = blkcnt * 16; + while (retry > 0) { + int idx; + + /* Wait for buffer to become ready. */ + while (! (ace_readw(0x04) & 0x0020)) { + udelay(1000); + } + + /* Read 16 words of 2bytes from the sector buffer. */ + for (idx = 0 ; idx < 16 ; idx += 1) { + unsigned short val = ace_readw(0x40); + *dp++ = val & 0xff; + *dp++ = (val>>8) & 0xff; + } + + retry -= 1; + } + + release_cf_lock(); + + return blkcnt; +} + + +#endif + +/* + * $Log: $ + */ + diff -purN -xEntries -x'*.orig' u-boot.orig/common/cmd_fat.c u-boot/common/cmd_fat.c --- u-boot.orig/common/cmd_fat.c 2003-10-15 16:53:50.000000000 -0700 +++ u-boot/common/cmd_fat.c 2004-02-03 21:18:51.000000000 -0800 @@ -63,6 +63,12 @@ block_dev_desc_t *get_dev (char* ifname, return(mmc_get_dev(dev)); } #endif +#if defined(CONFIG_SYSTEMACE) + if (strcmp(ifname,"ace")==0) { + extern block_dev_desc_t * systemace_get_dev(int dev); + return(systemace_get_dev(dev)); + } +#endif return NULL; } diff -purN -xEntries -x'*.orig' u-boot.orig/disk/part.c u-boot/disk/part.c --- u-boot.orig/disk/part.c 2004-01-03 11:43:49.000000000 -0800 +++ u-boot/disk/part.c 2004-02-03 18:04:47.000000000 -0800 @@ -36,7 +36,7 @@ #if ((CONFIG_COMMANDS & CFG_CMD_IDE) || \ (CONFIG_COMMANDS & CFG_CMD_SCSI) || \ (CONFIG_COMMANDS & CFG_CMD_USB) || \ - (CONFIG_MMC) ) + (CONFIG_MMC) || (CONFIG_SYSTEMACE) ) /* ------------------------------------------------------------------------- */ /* @@ -107,7 +107,8 @@ void dev_print (block_dev_desc_t *dev_de #if ((CONFIG_COMMANDS & CFG_CMD_IDE) || \ (CONFIG_COMMANDS & CFG_CMD_SCSI) || \ - (CONFIG_COMMANDS & CFG_CMD_USB) ) + (CONFIG_COMMANDS & CFG_CMD_USB) || \ + defined(CONFIG_SYSTEMACE) ) #if defined(CONFIG_MAC_PARTITION) || \ defined(CONFIG_DOS_PARTITION) || \ diff -purN -xEntries -x'*.orig' u-boot.orig/disk/part_dos.c u-boot/disk/part_dos.c --- u-boot.orig/disk/part_dos.c 2003-09-10 15:30:55.000000000 -0700 +++ u-boot/disk/part_dos.c 2004-02-03 18:06:24.000000000 -0800 @@ -37,7 +37,8 @@ #if ((CONFIG_COMMANDS & CFG_CMD_IDE) || \ (CONFIG_COMMANDS & CFG_CMD_SCSI) || \ - (CONFIG_COMMANDS & CFG_CMD_USB) ) && defined(CONFIG_DOS_PARTITION) + (CONFIG_COMMANDS & CFG_CMD_USB) || \ + (CONFIG_SYSTEMACE)) && defined(CONFIG_DOS_PARTITION) /* Convert char[4] in little endian format to the host format integer */ diff -purN -xEntries -x'*.orig' u-boot.orig/include/systemace.h u-boot/include/systemace.h --- u-boot.orig/include/systemace.h 1969-12-31 16:00:00.000000000 -0800 +++ u-boot/include/systemace.h 2004-02-04 18:47:32.000000000 -0800 @@ -0,0 +1,31 @@ +#ifndef __systemace_H +#define __systemace_H +/* + * Copyright (c) 2004 Picture Elements, Inc. + * Stephen Williams (steve(a)picturel.com) + * + * This source code is free software; you can redistribute it + * and/or modify it in source code form under the terms of the GNU + * General Public License as published by the Free Software + * Foundation; either version 2 of the License, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + */ +#ident "$Id:$" + +#ifdef CONFIG_SYSTEMACE + +# include <part.h> + +block_dev_desc_t * systemace_get_dev(int dev); + +#endif +#endif

2 1

[U-Boot-Users] Removing duplicate "FPGA Support" notes from the README file
by Jon Diekema 23 Feb '04

23 Feb '04

Product: - u-boot Version: - 1.0.2 CHANGELOG: * Patch by Jon Diekema, 14 Jeb 2004: - Removing duplicate "FPGA Support" notes from the README file. This section is repeated twice in the README file. CVS Comments: - Removing duplicate "FPGA Support" notes -- -------------------\\----------------------\\---------------------------- Jon Diekema | Custom IDEAS | http://www.cideas.com/ diekema(a)cideas.com | Grand Rapids, MI |

2 1

RE: [U-Boot-Users] [PATCH] Support for OMAP1610 H2 platform
by Woodruff, Richard 23 Feb '04

23 Feb '04

That file happens to have one more minor fix since then. In udelay(): If( (tmo + tmp) < tmp ) /* if setting this for ... */ Should be: If( tmo + tmp + 1) < tmp ) /* if setting this ... */ I found when leaving it set for a long time I could get caught in an infinite loop... the time rolled between get_time() and the and the call to get_timer_masked(). You generally don't hit it unless you let the board sits at the boot prompt for long. I'll submit more patches in the future for this and other fixes.......unless Wolfgang applies them first, as I have recently sent him a snapshot. Regards, Richard W. -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Wolfgang Denk Sent: Monday, February 23, 2004 3:35 PM To: Kamat, Nishant Cc: 'u-boot-users(a)lists.sourceforge.net' Subject: Re: [U-Boot-Users] [PATCH] Support for OMAP1610 H2 platform In message <536A1C579C92D71193CC0008C791B02E02F1551E(a)dlee08.itg.ti.com> you wrote: > > This patch adds support for the OMAP1610 H2 platform. It also adds to > cpu/arm926ejs/interrupt.c the fixes that Richard Woodruff had submitted for > arm925 (see below). Finally, a minor timer related bug in OMAP1610 Innovator > is fixed and support for booting through Flash or ROM is added for both the > OMAP1610 Innovator and H2. Added, thanks. 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 If in any problem you find yourself doing an immense amount of work, the answer can be obtained by simple inspection. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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

[U-Boot-Users] [Patch] correct machine check reason in cpu/mpc5xxx/traps.c
by Reinhard Meyer 23 Feb '04

23 Feb '04

This patch corrects the reason printout on machine check exceptions for the 603e processor in the MPC5200. It is the PowerPC numbered bits 12 to 15 that should be tested, not the bits 2**12 to 2**15. A similiar change could be appropriate for other 603e based MPCs... Changelog: * patch by Reinhard Meyer, 14 Feb 2004 Corrected tested bits in machine check exception in cpu/mpc5xxx/traps.c

2 1

RE: [U-Boot-Users] patch for CFI flash driver
by Brad Kemp 23 Feb '04

23 Feb '04

Josh, I re-ran the test to fast (use mm instead of nm), the results are be => md 0xe8180000 e8180000: ff060708 0ffa8f64 090a0b0c 0d0e0f10 .......d........ e8180010: 11121314 15161718 0000ffff 0ffa8f64 ...............d e8180020: ffffffff ffffffff ffffffff ffffffff ................ e8180030: ffffffff ffffffff ffffffff ffffffff ................ > -----Original Message----- > From: Brad Kemp > Sent: Monday, February 23, 2004 4:42 PM > To: 'Josh Fryman' > Cc: u-boot-users(a)lists.sourceforge.net > Subject: RE: [U-Boot-Users] patch for CFI flash driver > > > Josh, > I think the solution to the 8 bit x8/x16 problem is to > separate the query command matching from the commands that > are written to the flash. Not having an 8bit x8/x16 > implementation has made it hard for me to work this out. > > As for your patch. While it does let me copy odd amounts of > data at unaligned boundaries (something the driver did not > previosly do). The results I get are not correct. Below I > have filled memory with 010203040506... And copied part of it > to a previously erase sector in flash. > > > => nm 0x140000 > 00140000: ffffffff ? 01020304 > 00140000: 01020304 ? 05060708 > 00140000: 05060708 ? 090a0b0c > 00140000: 090a0b0c ? 0d0e0f10 > 00140000: 0d0e0f10 ? 11121314 > 00140000: 11121314 ? 15161718 > 00140000: 15161718 ? 191a1b1c > 00140000: 191a1b1c ? 1d1e1f20 > 00140000: 1d1e1f20 ? 21222324 > 00140000: 21222324 ? 25262728 > 00140000: 25262728 ? 292a2b2c > 00140000: 292a2b2c ? 2d2e2f30 > 00140000: 2d2e2f30 ? . > > => cp.b 0x140005 0xe8180003 0x15 > Copy to Flash... done > => md 0xe8180000 > e8180000: ffffffff 0ffe99cc ffffffff ffffffff ................ > e8180010: ffffffff ffffffff 0000ffff 0ffe99cc ................ > e8180020: ffffffff ffffffff ffffffff ffffffff ................ > e8180030: ffffffff ffffffff ffffffff ffffffff ................ > e8180040: ffffffff ffffffff ffffffff ffffffff ................ > > > -----Original Message----- > > From: Josh Fryman [mailto:fryman@cc.gatech.edu] > > Sent: Monday, February 23, 2004 3:29 PM > > To: Brad Kemp > > Cc: u-boot-users(a)lists.sourceforge.net > > Subject: Re: [U-Boot-Users] patch for CFI flash driver > > > > > > hi brad, > > > > > I think this patch will break 8bit x8/x16 implementions. > > > > not surprising :) i was worried i was breaking things when > i did that > > solution, but wasn't sure how it would break. > > > > > The reports I got back from the field indicated that the > port width > > > had to be halved to get flash writes to work sucessfully on 8bit > > > x8/x16 implementations. I think there is a better solution to the > > > problem than the one that was originally implemented. > > > > i'm almost certain of it. i don't design well after a long day of > > debugging problems. > > > > do you have a nice solution to the problem? or do you just have the > > same "there has to be a better way" feeling about it that i do? i > > can go back and try to actually design a proper solution, but i was > > hoping the "fix" would give you the insight needed that > you'd have an > > elegant solution... > > > > cheers, > > > > -josh > > > > (another idea was to malloc a sufficiently large buffer, read in > > current flash contents, do the update to memory, then call the > > existing -unhacked- routines to write back to flash on nice > > boundaries to kill padding problems and alignment issues... but this > > seemed like an even worse approach.) > > > > >

1 0

RE: [U-Boot-Users] patch for CFI flash driver
by Brad Kemp 23 Feb '04

23 Feb '04

Josh, I think the solution to the 8 bit x8/x16 problem is to separate the query command matching from the commands that are written to the flash. Not having an 8bit x8/x16 implementation has made it hard for me to work this out. As for your patch. While it does let me copy odd amounts of data at unaligned boundaries (something the driver did not previosly do). The results I get are not correct. Below I have filled memory with 010203040506... And copied part of it to a previously erase sector in flash. => nm 0x140000 00140000: ffffffff ? 01020304 00140000: 01020304 ? 05060708 00140000: 05060708 ? 090a0b0c 00140000: 090a0b0c ? 0d0e0f10 00140000: 0d0e0f10 ? 11121314 00140000: 11121314 ? 15161718 00140000: 15161718 ? 191a1b1c 00140000: 191a1b1c ? 1d1e1f20 00140000: 1d1e1f20 ? 21222324 00140000: 21222324 ? 25262728 00140000: 25262728 ? 292a2b2c 00140000: 292a2b2c ? 2d2e2f30 00140000: 2d2e2f30 ? . => cp.b 0x140005 0xe8180003 0x15 Copy to Flash... done => md 0xe8180000 e8180000: ffffffff 0ffe99cc ffffffff ffffffff ................ e8180010: ffffffff ffffffff 0000ffff 0ffe99cc ................ e8180020: ffffffff ffffffff ffffffff ffffffff ................ e8180030: ffffffff ffffffff ffffffff ffffffff ................ e8180040: ffffffff ffffffff ffffffff ffffffff ................ > -----Original Message----- > From: Josh Fryman [mailto:fryman@cc.gatech.edu] > Sent: Monday, February 23, 2004 3:29 PM > To: Brad Kemp > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] patch for CFI flash driver > > > hi brad, > > > I think this patch will break 8bit x8/x16 implementions. > > not surprising :) i was worried i was breaking things when i did that > solution, but wasn't sure how it would break. > > > The reports I got back from the field indicated that the port width > > had to be halved to get flash writes to work sucessfully on 8bit > > x8/x16 implementations. I think there is a better solution to the > > problem than the one that was originally implemented. > > i'm almost certain of it. i don't design well after a long day of > debugging problems. > > do you have a nice solution to the problem? or do you just have the > same "there has to be a better way" feeling about it that i do? i > can go back and try to actually design a proper solution, but i was > hoping the "fix" would give you the insight needed that you'd have an > elegant solution... > > cheers, > > -josh > > (another idea was to malloc a sufficiently large buffer, read in > current flash contents, do the update to memory, then call the > existing -unhacked- routines to write back to flash on nice > boundaries to kill padding problems and alignment issues... but this > seemed like an even worse approach.) > >

1 0

[U-Boot-Users] [Patch] Added EVAL5200 support in rtc/mk48t59.c
by Reinhard Meyer 23 Feb '04

23 Feb '04

This patch enables support of the EVAL5200 board's M48T08 realtime clock Changelog: not worth mentioning adding another #elsif -or- if required: * patch by Reinhard Meyer, 14 Feb 2004 Added support for the M48T08 on the EVAL5200 board in rtc/mk48t59.c

2 1

[U-Boot-Users] Calling show_boot_progress() whenever POST "FAILED" is printed.
by Jon Diekema 23 Feb '04

23 Feb '04

Product: - u-boot Version: - 1.0.2 CHANGELOG: - Calling show_boot_progress() whenever POST "FAILED" is printed. Background: - We ran into a board that is having memory failure. On bootup it reports: ... DRAM: 128MB Memory error at 0700053c, wrote ffffffff, read ffffffdd ! POST memory FAILED FLASH: 2MB Net: FCC2 ETHERNET POST cpu PASSED Autobooting... Then it attempts to boot, gets a kernel panic, and resets after 180 seconds. The problem is the POST memory failure never gets flagged anywhere other than the serial output, so unless you watch the serial output for it, the only indication is a crash and reset. CVS Comments: - Calling show_boot_progress() whenever POST "FAILED" is printed.

2 1

[U-Boot-Users] [PATCH] Support for OMAP1610 H2 platform
by Kamat, Nishant 23 Feb '04

23 Feb '04

Hi all, This patch adds support for the OMAP1610 H2 platform. It also adds to cpu/arm926ejs/interrupt.c the fixes that Richard Woodruff had submitted for arm925 (see below). Finally, a minor timer related bug in OMAP1610 Innovator is fixed and support for booting through Flash or ROM is added for both the OMAP1610 Innovator and H2. Best regards, Nishant > -----Original Message----- > From: Woodruff, Richard > Sent: Thursday, October 16, 2003 12:28 PM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] cpu/arm925 timer fixes. > > > Hello, > > This patch fixes a few bugs which made udelay() not work > properly on 925 based systems. A while back when I increased > my boards clock speed I ran into quite a few problems which > resulted in these fixes. > > I think the Innovator should be switched over to use a real > udelay code instead of its busy spins. They do not scale at > all with clock speed, and do not keep the useful timestamp > properly updating. > > Regards, > > Richard W. > >

2 1

[U-Boot-Users] [PATCH] Nios: timer with variable period; POST preparation
by Stephan Linz 23 Feb '04

23 Feb '04

Hi all, Hi Scott, here are two small patches I need for my upcoming new Nios board support. Scott, could you check-up the patches at your DK1C20 board and note Wolfgang and me so we can put it into CVS ? -- thanks. 1/2 tick timer supports variable (programmable) periods (min. 1 ms tick) 2/2 some small preparation for upcoming POST support for Nios arch -- Best regards, Stephan Linz

2 1

RE: [U-Boot-Users] Adding support for a 'similar to existing' boa rd
by Kamat, Nishant 23 Feb '04

23 Feb '04

Wolfgang, I would like to change the '1610innovator-' like directory and file names to general 'omap1610' to include support for both the boards. Is that okay. If yes, would you like me to send one patch containing changes to existing files, and another containing the re-naming stuff, just so that it is easy for you to identify the changes? Or one single patch is ok? Thanks, Nishant > > > In message > <536A1C579C92D71193CC0008C791B02E02DE106B(a)dlee08.itg.ti.com> > you wrote: > > > > I wish to add support for another TI OMAP1610 board which > is code-wise > > very similar to the OMAP1610 Innovator. Would you please > suggest what > > is better > > - creating another directory structure for that board > (which is probably > > technically correct), or adding changes to the OMAP1610 > Innovator's files > > with #ifdef's? The changes in code would be 10-15 lines at most. > > You probably want to have your own board config file in > include/configs/; if the changes in the board specific > directory are really that small some #ifdef's are OK. > > Best regards, > > Wolfgang Denk >

2 1

[U-Boot-Users] Patch MIP405 Board
by Denis Peter 23 Feb '04

23 Feb '04

Dear Wolfgang, the attached patch against the current CVS adds POST support for the MIP405 Board. CHANGELOG: * Patch by Denis Peter, 11 Feb 2004 add POST support for the MIP405 board With best regards, Denis

2 1

RE: [U-Boot-Users] patch for CFI flash driver
by Brad Kemp 23 Feb '04

23 Feb '04

Josh, I think this patch will break 8bit x8/x16 implementions. The reports I got back from the field indicated that the port width had to be halved to get flash writes to work sucessfully on 8bit x8/x16 implementations. I think there is a better solution to the problem than the one that was originally implemented. Brad > -----Original Message----- > From: Josh Fryman [mailto:fryman@cc.gatech.edu] > Sent: Saturday, February 21, 2004 12:30 AM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] patch for CFI flash driver > > > > attached is a full patch for the CFI flash driver. it tries > to correct > a problem i spent a lot of time examining. i've sent the > patch to brad > (the maintainer) as well, but wanted to post it here for > others to give > feedback on as well. > > if anyone has a better solution, other ideas, etc, i'd > appreciate hearing > them. > > in short, in "write_buff(...)", the platform i'm using needs > to be able to > pass in any mixture of alignments and lengths. ie, the > target flash addr > may not be aligned on a nice boundary, and the > memory-to-write-from may > not be either. > > there was a very rudimentary "check" in the prior version > that would try > to do something for misaligned boundaries, but it just didn't > work. it > wound up writing padding to the beginning or end of the > flash, which would > make things fail (ie, CRC) all over the place. it also wound > up dropping > (!!) bytes under certain conditions, never writing them at all. > > below is my "fix". again, i think this is a hack, albeit a > robust one at > the moment. i think there's a better way to do this, or at least a > cleaner way, but i wanted to get your feedback on it. i'm > not sure what > the "better way" is. > > the first function, flash_write_aligned, is _always_ handed a nicely > aligned block of data to write. the "data" pointer and the > "addr" flash > target location are always on a boundary which is a multiple > of the width. > (ie, 8, 16, 32, or 64-bits.) count is the number of bytes, > but it's also > promised to be an integer multiple of the width. > > the revised version of "write_buff()" uses the "READ_CURR" > macro in two > places... but otherwise is fairly commented by itself. it > does essentially > a pre-alignment set of operations, then does a block-write > via the first > function "write_aligned", and then does any necessary tail > corrections. > > any thoughts? > > -josh >

2 1