From mboxrd@z Thu Jan 1 00:00:00 1970 From: Abbas Dadabhoy Date: Tue, 24 Feb 2004 09:22:11 -0800 Subject: [U-Boot-Users] Can we limit number of messages per day. References: <20040224170459.19AFC22DB@gabriel.aristoslogic.com> Message-ID: <403B8842.617F5981@aristoslogic.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wont it be nice to limit these number of messages to 1 or 2 a day. u-boot-users-request at lists.sourceforge.net wrote: > Send U-Boot-Users mailing list submissions to > u-boot-users at lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/u-boot-users > or, via email, send a message with subject or body 'help' to > u-boot-users-request at lists.sourceforge.net > > You can reach the person managing the list at > u-boot-users-admin at lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of U-Boot-Users digest..." > > Today's Topics: > > 1. RE: 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" > To: > 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 at lists.sourceforge.net > Cc: Bernieshu > Subject: Re: [U-Boot-Users] Where can I find a libgcc.a with software FP. > From: Wolfgang Denk > Date: Tue, 24 Feb 2004 16:58:14 +0100 > > In message 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 at denx.de > In 1750 Issac Newton became discouraged when he fell up a flight of > stairs. > > --__--__-- > > Message: 3 > To: "Laurent Mohin" > Cc: u-boot-users at lists.sourceforge.net > Subject: Re: [U-Boot-Users] telnet server on u-boot > From: Detlev Zundel > 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 > Cc: "'u-boot-users at lists.sourceforge.net'" > Subject: Re: [U-Boot-Users] Compile Error > From: Wolfgang Denk > Date: Tue, 24 Feb 2004 17:11:30 +0100 > > Dear Jim, > > in message <75490FAA49820647AB2BAFEFE08BFABC0CD98D@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" > > > > > > > > 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 at 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 > Cc: Steven Scholz , Wolfgang Denk > , > U-BOOT-USERS > Subject: Re: [U-Boot-Users] NFS support patch > From: Detlev Zundel > 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" > To: > 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 > CC: U-BOOT-USERS > 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 > To: u-boot-users at 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 at lists.sourceforge.net > Subject: Re: [U-Boot-Users] telnet server on u-boot > From: Wolfgang Denk > Date: Tue, 24 Feb 2004 17:26:35 +0100 > > In message <87fzd04g4z.fsf@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 at 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 > To: Masami Komiya > CC: U-BOOT-USERS > 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 at 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 > Cc: u-boot-users at lists.sourceforge.net > Subject: Re: [U-Boot-Users] telnet server on u-boot > From: "Laurent Mohin" > 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 > To: Wolfgang Denk > cc: u-boot-users at lists.sourceforge.net, > Bernieshu > 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 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 > 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 at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > End of U-Boot-Users Digest