October 2004 - U-Boot

[U-Boot-Users] E1 initialization sequence.
by Prathima_Kolar 26 Oct '04

26 Oct '04

Hello All, I have been trying to provide E1 support for my custom board based on MPC8266ADS. E1 is connected to SCC on my custom board. I am using E1/T1 Quadfalc(PEF22554) I did not find any piece of code for E1 in U-boot. I have searched on the internet for possible initialization steps but could not find any. Could anyone please shed some light on this. Thanks & Warm Regards, Prathima. ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. **************************************************************************

1 0

[U-Boot-Users] NAND hardware ECC
by Shannon Holland 26 Oct '04

26 Oct '04

It looks like we're going to be wanting to use hardware ecc on our board (since the S3C2410 supports it and our u-boot loader only has code space to use hardware ecc). It would appear that u-boot's 3 byte ecc is not compatible with the hardware algorithm used by the S3C2410 (whatever that algorithm is, I have been unable to find any documentation on it). So, I would like to add support for hardware ecc to cmd_nand.c. Before I embark on this, I wanted to check to see if anyone else is working on this or had preferences as to how it should be done? Thanks! Shannon

1 0

[U-Boot-Users] Netconsole env vars
by Robin Gilks 26 Oct '04

26 Oct '04

Just had a configuration that failed to work so I'm after a sanity check to see if others see it. In net/net.c, the netconsole path through the code seems to depend on 'serverip' being set in a couple of places (i.e. a couple of switch statements have TFTP and NETCONS as the same condition). Is this right? I can't see what the connection is between serverip and ncip at present!! -- Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks(a)tait.co.nz New Zealand ======================================================================= This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. =======================================================================

1 0

[U-Boot-Users] ARM Integrator CP/AP support?
by Shawn 26 Oct '04

26 Oct '04

Hi, Different core modules can be plugged into Integrator CP or AP board. Now I have some patches to support different core modules on top of Integrator CP/AP but has some little problem need help. My proposal is as follows. xtract_integrator = $(subst _946es,,$(subst _config,,$1)) xtract_integrator_cm = $(subst integratorap,,$(subst integratorcp,,$(subst _config,,$1))) integratorap_config \ integratorap_946es_config \ integratorcp_config \ integratorcp_946es_config : unconfig @cm=$(call xtract_integrator_cm,$@); \ case $$cm in \ _946es) cm=arm946es;; \ *) cm=arm926ejs;; \ esac; \ echo "cm=$$cm"; \ if [ "$$cm" == "arm946es" ]; then \ echo "#define CONFIG_ARM946ES 1 /* This is an arm946es CPU core */" >> ./include/con fig.h ; \ echo "... configured for ARM946ES"; \ else \ echo "#define CONFIG_ARM926EJS 1 /* This is an arm926ejs CPU core */" >> ./include/c onfig.h ; \ echo "... configured for ARM926EJS"; \ fi; \ ./mkconfig -a $(call xtract_integrator,$@) arm $$cm $(call xtract_integrator,$@) But one more thing I need to change is the u-boot.lds file in board/integratorcp and board/integratorap. .text : { cpu/arm926ejs/start.o (.text) *(.text) } I need to change the directory cpu/arm926ejs/start.o to some value of cpu/$$cm/start.o. A simple SED or AWK command may be able to fulfill this but I'm not familiar either of them. Can someone help? Thanks, -Shawn.

1 0

RE: [U-Boot-Users] PATCH: Introducing CONFIG_BOARD_PRE_RESET
by VanBaren, Gerald (AGRE) 25 Oct '04

25 Oct '04

> -----Original Message----- > From: Steven Scholz [mailto:steven.scholz@imc-berlin.de] > Sent: Monday, October 25, 2004 10:40 AM > To: VanBaren, Gerald (AGRE) > Cc: u-boot-users > Subject: Re: [U-Boot-Users] PATCH: Introducing CONFIG_BOARD_PRE_RESET > > Hi Gerald, > > > I like your suggestion a lot, but I would suggest a "#ifdef" around > > the common.h kind of like I hand-pasted in below (probably > > incorrectly, but you get my meaning). > > > int board_postclk_init (void); > > int board_early_init_r (void); > > void board_poweroff (void); > > +#ifdef CONFIG_BOARD_PRE_RESET > > +void board_pre_reset (void); > > +#endif > > Since functions like board_postclk_init and > board_early_init_r etc. don't have an #ifdef I decided to go > the same way. > > Do you see any problems without #ifdef ? > > -- > Steven Scholz The reason I suggested the #ifdef is because the actual code implementation is surrounded by the #ifdef so, if you don't have CONFIG_BOARD_PRE_RESET defined, you will have a declaration of board_pre_reset() but no code implementing it. I forgot off-hand if this is a problem, but I think it is (too lazy to be a language lawyer at the moment). gvb ****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak: ****************************************** 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. ******************************************

4 4

RE: [U-Boot-Users] PPC as host
by VanBaren, Gerald (AGRE) 25 Oct '04

25 Oct '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf > Of Richard Klingler > Sent: Monday, October 25, 2004 11:02 AM > To: u-boot-users > Subject: [U-Boot-Users] PPC as host > > Evening (o; > > > Apparently no one uses Linux PPC as host? > So no one ever had problems cross-compiling u-boot for > another target then (o; > > > In the top Makefile we have: > > ifndef CROSS_COMPILE > ifeq ($(HOSTARCH),ppc) > CROSS_COMPILE = > else > .... > > which always picks up the host ppc compiler regardless what > ARCH you have defined for your board... > > > Since I don't use PPC as target someone might come up with a > better idea then: > > ifeq ($(HOSTARCH,$(ARCH)) > CROSS_COMPILE = > else > ... > > > In my case it is YDL-3.0.1 PPC Linux running on G4. > This doesn't happen on OSX since it is solved in the top > config.mk file. > > > best regards > rick The Makefile makes its best guess about cross compilers given very limited information. It may guess wrong, as you are seeing. For more information, see: http://www.denx.de/twiki/bin/view/DULG/ELDKUsage <blockquote> * After the installation utility completes, export the CROSS_COMPILE variable: bash$ export CROSS_COMPILE=ppc_8xx- TIP The trailing '-' character in the CROSS_COMPILE variable value is optional and has no effect on the cross tools behavior. </blockquote> A related hint (if you don't like the export hint) is in http://www.denx.de/twiki/bin/view/DULG/LinuxConfiguration <blockquote> If your host computer is not the same architecture as the target system, and if you got your kernel tree from kernel.org or other "official" sources, then you may have to supply an architecture override and a cross compiler definition. The most reliable way to do this is to specify them on the make command line as part of the make command. If this is the case, use for example: bash$ make ARCH=ppc CROSS_COMPILE=ppc_8xx- </blockquote> gvb ****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak: ****************************************** 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. ******************************************

3 2

[U-Boot-Users] Ebony (440GP) fails to bootp in Linux after U-Boot...
by Rani Glaser 25 Oct '04

25 Oct '04

Hi, I've been using the the IBM booter that comes with the Ebony and successfully booted my Linux kernel (2.6.8.1 based) on the Ebony. This includes the IBM booter doing tftp, then the kernel running bootp/dhcp and mounting the nfs smoothly. Lately I've been trying to move to u-boot. Although installation of u-boot to the flash and booting u-boot went quite fine, I'm unable to finish the kernel boot process. First I generated a kernel for the IBM booter using the make and tftp-loaded zImage.ebony. Everything works fine. Then switched to the u-boot flash (using U46 SW1). Then I generated the linux kernel using "make uImage", using "tftpbootm 0x500000 /somewhere/uImage ; bootm 0x50000". (IBM booter used same 0x500000 address). It loads nicely then just keeps trying to "BOOTP". Configuring the IP by hand just moves the problem later to the NFS mounting process since no ethernet traffic exists. I did notice that the kernel doesn't automatically load the u-boot MAC address correctly (kernel originally showed MAC is ff:ff:ff:ff:ff:ff on u-boot), so for the time being I patched the source of the MAC and inserted it by hand into the kernel code (now the kernel shows the correct MAC when booting). Again, this runs fine on the IBM booter. However, after I boot using u-boot, there doesn't seem to be any traffic coming from the kernel (monitored using ethereal). I turned on some debugging features in the 440GP EMAC driver, and it seems that the EMAC driver gets request to transmit the BOOTP request, but nothing comes in or out. Anyone have any solutions for this?!? Please help me out. Many thanks, Rani Glaser ranig <at> go-wlan.com

2 1

RE: [U-Boot-Users] PATCH: Introducing CONFIG_BOARD_PRE_RESET
by VanBaren, Gerald (AGRE) 25 Oct '04

25 Oct '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf > Of Steven Scholz > Sent: Monday, October 25, 2004 10:28 AM > To: u-boot-users > Subject: [U-Boot-Users] PATCH: Introducing CONFIG_BOARD_PRE_RESET > > Hi there, > > as mentioned on list before some boards/cpus might need some > extra code to be executed _before_ rebooting. E.g. the i.MX > hangs when doing "reset" while the LCD controller is still enabled. > > That is why I'd like to introduce CONFIG_BOARD_PRE_RESET and > board_pre_reset(). > The attached does exactly that. But only for cpu/arm920t. > If wished I'll add the appropriate code to all cpu/$(CPU)/cpu.c files. > > * Patch by Steven Scholz, 25 Oct 2004: > - Introducing CONFIG_BOARD_PRE_RESET and board_pre_reset() to allow > code to be executed before actually rebooting > > -- > Steven Scholz Hi Steven, I like your suggestion a lot, but I would suggest a "#ifdef" around the common.h kind of like I hand-pasted in below (probably incorrectly, but you get my meaning). gvb Index: include/common.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/common.h,v retrieving revision 1.46 diff -p -u -r1.46 common.h --- include/common.h 10 Oct 2004 18:41:14 -0000 1.46 +++ include/common.h 25 Oct 2004 13:32:15 -0000 @@ -318,6 +318,9 @@ int board_late_init (void); int board_postclk_init (void); /* after clocks/timebase, before env/serial */ int board_early_init_r (void); void board_poweroff (void); +#ifdef CONFIG_BOARD_PRE_RESET +void board_pre_reset (void); +#endif #if defined(CFG_DRAM_TEST) int testdram(void); ****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak: ****************************************** 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. ******************************************

2 1

[U-Boot-Users] Compile problem for ARM / LPD7A400
by Devraj Mukherjee 25 Oct '04

25 Oct '04

Hi everyone, I am using arm-linux GCC 3.3 with GlibC 2.3.2. I have managed to compile a Linux version 2.6 kernel with this setup and patches for Logic PD card engine LPD7A400. I am trying to get a version of U-Boot with working with the same. I have applied all available patches, that I gathered for the board from this list serve. I get the following errors when I am trying to compile UBoot. Is there anyone who can encoutnered this problem and if so any lead? Thanks in advance. Dump from compile time: In file included from cfi_flash.c:48: /home/devraj/lpd7a400/uboot/u-boot-1.1.1.lpd7a400/include/asm/processor.h:52: parse error before `1' /home/devraj/lpd7a400/uboot/u-boot-1.1.1.lpd7a400/include/asm/processor.h:52: warning: no semicolon at end of struct or union /home/devraj/lpd7a400/uboot/u-boot-1.1.1.lpd7a400/include/asm/processor.h:54: parse error before `}' /home/devraj/lpd7a400/uboot/u-boot-1.1.1.lpd7a400/include/asm/processor.h:58: field `insn' has incomplete type make[1]: *** [cfi_flash.o] Error 1 make[1]: Leaving directory `/home/devraj/lpd7a400/uboot/u-boot-1.1.1.lpd7a400/drivers' make: *** [drivers/libdrivers.a] Error 2 Regards, Devraj

2 1

Re: [U-Boot-Users] question about net/net.c
by Robin Getz 25 Oct '04

25 Oct '04

Wolfgang requested: >Can you please re-send this question in form of a (suggested / >potential) patch? That would be much more readable. Sorry for the delay - traveling over the weekend... ============================================= --- ../cvs/u-boot_1.1.1/net/net.c 2004-07-02 04:45:14.000000000 -0700 +++ ./u-boot_1.1.1/net/net.c 2004-10-25 05:59:54.000000000 -0700 @@ -1241,7 +1241,7 @@ case ARPOP_REPLY: /* arp reply */ /* are we waiting for a reply */ if (!NetArpWaitPacketIP || !NetArpWaitPacketMAC) - break; + return; #ifdef ET_DEBUG printf("Got ARP REPLY, set server/gtwy eth addr (%02x:%02x:%02x:%02x:%02x:%02x)\n", arp->ar_data[0], arp->ar_data[1], @@ -1276,7 +1276,7 @@ #endif return; } - + break; case PROT_RARP: #ifdef ET_DEBUG puts ("Got RARP\n"); ======================================================= This will fix the issue described previously, where: 1. u-boot initiates a tftp transfer 2. u-boot sets a flag "NetArpWaitPacketMAC = 1" 3. u-boot sends ARP Request on network to find the MAC address of tftp server 4. server is a little slow, and u-boot has not yet received the ARP so, u-boot sends ARP Request on network to find the MAC address of tftp server 5. tftp server responds back to first request with it's MAC address, and u-boot sees this, and accepts it. 6. u-boot sets the flag "NetArpWaitPacketMAC = 0" as it got the ARP reply 7. tftp server responds back to second request with it's MAC address, and u-boot sees this, and accepts it. At this point as u-boot is not waiting (NetArpWaitPacketMAC is 0) for ARP reply breaks out of the switch that handles ARP reply. But this break is not to return from the complete handler and thus falls into RARP handler code. 8. u-boot prints out "invalid RARP header".

1 0