August 2007 - U-Boot

[U-Boot-Users] u-boot for ML405
by Zvika Vered 27 Aug '07

27 Aug '07

Hello, Xilinx ML405 can be booted from on board PROM via JTAG. I want to link the u-boot ELF with the EDK design and load the FPGA via JTAG. Upon reset, I want that the u-boot code will be copied to RAM and run from RAM. 1. Did anyone made the changes in u-boot for Xilinx ML405 ? Can you send those changes ? 2. Does u-boot contains code that copies itself from ROM to RAM ? Where is this code in u-boot folders ? Thanks, Zvika Vered

1 0

Re: [U-Boot-Users] [PATCH] AVR32: Change prototype of memset
by Haavard Skinnemoen 27 Aug '07

27 Aug '07

[Adding u-boot-users to Cc] On Mon, 20 Aug 2007 19:00:01 +0300 Semih Hazar <semih.hazar(a)indefia.com> wrote: > Signed-off-by: Semih Hazar <semih.hazar(a)indefia.com> > --- > > The current top of the git tree doesn't compile. This patch changes > the prototype according to other architectures. Indeed. Wonder why a file compiled for the _host_ starts pulling in avr32-specific include files... Anyway, I've applied your patch since it fixes the build. But I can't help but wonder if using target-specific headers when compiling stuff for the host is a disaster waiting to happen... Here's the error message: gcc -g -Wall -pedantic -idirafter /home/hskinnemoen/git/u-boot/include -idirafter /home/hskinnemoen/git/u-boot/include2 -idirafter /home/hskinnemoen/git/u-boot/include -DTEXT_BASE=0x00000000 -DUSE_HOSTCC -O -c -o sha1.o sha1.c In file included from /home/hskinnemoen/git/u-boot/include/linux/string.h:21, from sha1.c:32: /home/hskinnemoen/git/u-boot/include/asm/string.h:26: error: expected declaration specifiers or ‘...’ before ‘size_t’ sha1.c: In function ‘sha1_hmac’: sha1.c:323: error: too many arguments to function ‘memset’ sha1.c:324: error: too many arguments to function ‘memset’ sha1.c:344: error: too many arguments to function ‘memset’ sha1.c:345: error: too many arguments to function ‘memset’ sha1.c:346: error: too many arguments to function ‘memset’ sha1.c:347: error: too many arguments to function ‘memset’ and below is the fix. Any reason why sha1.c includes <linux/string.h> instead of just <string.h>? Thanks for the patch! Haavard > include/asm-avr32/string.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/asm-avr32/string.h b/include/asm-avr32/string.h > index 8b05d1a..58582a3 100644 > --- a/include/asm-avr32/string.h > +++ b/include/asm-avr32/string.h > @@ -23,6 +23,6 @@ > #define __ASM_AVR32_STRING_H > > #define __HAVE_ARCH_MEMSET > -extern void *memset(void *s, int c, size_t n); > +extern void *memset(void *s, int c, __kernel_size_t n); > > #endif /* __ASM_AVR32_STRING_H */

4 4

[U-Boot-Users] CPM_SPI_BASE and CPM_I2C_BASE conflict in u-boot-1.2.0
by DI BACCO ANTONIO - technolabs 27 Aug '07

27 Aug '07

In include/commproc.h CPM_I2C_BASE is set to 0x820 and CPM_SPI_BASE is set 0x840, but in cpu/mpc8xx/i2c.c 4 TX and 4 RX i2c buffers (each of 8 bytes) are declared. I believe this causes a problem when issueing an SPI command after and I2C one. Someone can confirm that this could be a problem? Bye, Antonio.

2 1

[U-Boot-Users] [PATCH 2/2][MIPS] Add lib_mips/string.c and stop using inline asm functions.
by Shinya Kuribayashi 27 Aug '07

27 Aug '07

[MIPS] Add lib_mips/string.c and stop using inline asm functions. From: Shinya Kuribayashi <shinya.kuribayashi(a)necel.com> We MIPS stop using inline string functions as other ARCHs do so, since the optimized inline asm versions are not small. This change was triggered by a following MIPS build error: common/libcommon.a(exports.o)(.text+0xdc): In function `jumptable_init': common/exports.c:32: undefined reference to `strcmp' make: *** [u-boot] Error 1 Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi(a)necel.com> --- include/asm-mips/string.h | 18 +++++++ lib_mips/Makefile | 2 - lib_mips/string.c | 122 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 141 insertions(+), 1 deletions(-) diff --git a/include/asm-mips/string.h b/include/asm-mips/string.h index 4739c18..b9da3a9 100644 --- a/include/asm-mips/string.h +++ b/include/asm-mips/string.h @@ -10,6 +10,12 @@ #ifndef _ASM_STRING_H #define _ASM_STRING_H +/* + * We don't do inline string functions, since the + * optimised inline asm versions are not small. + * + * All the following inline asm functions are moved to lib_mips/string.c. + */ /* * Most of the inline functions are rather naive implementations so I just @@ -20,6 +26,8 @@ #ifndef IN_STRING_C #define __HAVE_ARCH_STRCPY +extern char *strcpy(char *__dest, __const__ char *__src); +#if 0 static __inline__ char *strcpy(char *__dest, __const__ char *__src) { char *__xdest = __dest; @@ -40,8 +48,11 @@ static __inline__ char *strcpy(char *__dest, __const__ char *__src) return __xdest; } +#endif #define __HAVE_ARCH_STRNCPY +extern char *strncpy(char *__dest, __const__ char *__src, size_t __n); +#if 0 static __inline__ char *strncpy(char *__dest, __const__ char *__src, size_t __n) { char *__xdest = __dest; @@ -68,8 +79,11 @@ static __inline__ char *strncpy(char *__dest, __const__ char *__src, size_t __n) return __xdest; } +#endif #define __HAVE_ARCH_STRCMP +extern int strcmp(__const__ char *__cs, __const__ char *__ct); +#if 0 static __inline__ int strcmp(__const__ char *__cs, __const__ char *__ct) { int __res; @@ -96,10 +110,13 @@ static __inline__ int strcmp(__const__ char *__cs, __const__ char *__ct) return __res; } +#endif #endif /* !defined(IN_STRING_C) */ #define __HAVE_ARCH_STRNCMP +extern int strncmp(__const__ char *__cs, __const__ char *__ct, size_t __count); +#if 0 static __inline__ int strncmp(__const__ char *__cs, __const__ char *__ct, size_t __count) { @@ -129,6 +146,7 @@ strncmp(__const__ char *__cs, __const__ char *__ct, size_t __count) return __res; } +#endif #endif /* CONFIG_32BIT */ /* diff --git a/lib_mips/Makefile b/lib_mips/Makefile index 3163f00..7a004b4 100644 --- a/lib_mips/Makefile +++ b/lib_mips/Makefile @@ -27,7 +27,7 @@ LIB = $(obj)lib$(ARCH).a SOBJS = -COBJS = board.o time.o mips_linux.o +COBJS = board.o string.o time.o mips_linux.o SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) diff --git a/lib_mips/string.c b/lib_mips/string.c new file mode 100644 index 0000000..2e1d33f --- /dev/null +++ b/lib_mips/string.c @@ -0,0 +1,122 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (c) 1994, 95, 96, 97, 98, 2000, 01 Ralf Baechle + * Copyright (c) 2000 by Silicon Graphics, Inc. + * Copyright (c) 2001 MIPS Technologies, Inc. + */ +#include <linux/string.h> + +#ifdef __HAVE_ARCH_STRCPY +char *strcpy(char *__dest, __const__ char *__src) +{ + char *__xdest = __dest; + + __asm__ __volatile__( + ".set\tnoreorder\n\t" + ".set\tnoat\n" + "1:\tlbu\t$1,(%1)\n\t" + "addiu\t%1,1\n\t" + "sb\t$1,(%0)\n\t" + "bnez\t$1,1b\n\t" + "addiu\t%0,1\n\t" + ".set\tat\n\t" + ".set\treorder" + : "=r" (__dest), "=r" (__src) + : "0" (__dest), "1" (__src) + : "memory"); + + return __xdest; +} +#endif /* __HAVE_ARCH_STRCPY */ + +#ifdef __HAVE_ARCH_STRNCPY +char *strncpy(char *__dest, __const__ char *__src, size_t __n) +{ + char *__xdest = __dest; + + if (__n == 0) + return __xdest; + + __asm__ __volatile__( + ".set\tnoreorder\n\t" + ".set\tnoat\n" + "1:\tlbu\t$1,(%1)\n\t" + "subu\t%2,1\n\t" + "sb\t$1,(%0)\n\t" + "beqz\t$1,2f\n\t" + "addiu\t%0,1\n\t" + "bnez\t%2,1b\n\t" + "addiu\t%1,1\n" + "2:\n\t" + ".set\tat\n\t" + ".set\treorder" + : "=r" (__dest), "=r" (__src), "=r" (__n) + : "0" (__dest), "1" (__src), "2" (__n) + : "memory"); + + return __xdest; +} +#endif /* __HAVE_ARCH_STRNCPY */ + +#ifdef __HAVE_ARCH_STRCMP +int strcmp(__const__ char *__cs, __const__ char *__ct) +{ + int __res; + + __asm__ __volatile__( + ".set\tnoreorder\n\t" + ".set\tnoat\n\t" + "lbu\t%2,(%0)\n" + "1:\tlbu\t$1,(%1)\n\t" + "addiu\t%0,1\n\t" + "bne\t$1,%2,2f\n\t" + "addiu\t%1,1\n\t" + "bnez\t%2,1b\n\t" + "lbu\t%2,(%0)\n\t" +#if defined(CONFIG_CPU_R3000) + "nop\n\t" +#endif + "move\t%2,$1\n" + "2:\tsubu\t%2,$1\n" + "3:\t.set\tat\n\t" + ".set\treorder" + : "=r" (__cs), "=r" (__ct), "=r" (__res) + : "0" (__cs), "1" (__ct)); + + return __res; +} +#endif /* __HAVE_ARCH_STRCMP */ + +#ifdef __HAVE_ARCH_STRNCMP +int strncmp(__const__ char *__cs, __const__ char *__ct, size_t __count) +{ + int __res; + + __asm__ __volatile__( + ".set\tnoreorder\n\t" + ".set\tnoat\n" + "1:\tlbu\t%3,(%0)\n\t" + "beqz\t%2,2f\n\t" + "lbu\t$1,(%1)\n\t" + "subu\t%2,1\n\t" + "bne\t$1,%3,3f\n\t" + "addiu\t%0,1\n\t" + "bnez\t%3,1b\n\t" + "addiu\t%1,1\n" + "2:\n\t" +#if defined(CONFIG_CPU_R3000) + "nop\n\t" +#endif + "move\t%3,$1\n" + "3:\tsubu\t%3,$1\n\t" + ".set\tat\n\t" + ".set\treorder" + : "=r" (__cs), "=r" (__ct), "=r" (__count), "=r" (__res) + : "0" (__cs), "1" (__ct), "2" (__count)); + + return __res; +} +#endif /* __HAVE_ARCH_STRNCMP */

2 1

[U-Boot-Users] Protect an area in RAM
by Markus Malmgren 24 Aug '07

24 Aug '07

Hi, Many hardware manufactures provide their development platform with u-boot. I was wondering if there is a feature (did not find anything) in u-boot to protect a specific area in the RAM from being overwritten when u-boot boots a microcontroller? The reason for this is that we store debug information between restarts from our software and using u-boot this is destroyed. If this feature does not exist, one general solution would be to add a system parameter in which areas that are not to be destroyed could be added as a default feature of u-boot. Would this be a feature that others need as well? If so I will start to investigate what could be done. Regards, Markus

3 6

[U-Boot-Users] 85xx and flash.c
by robert lazarski 24 Aug '07

24 Aug '07

Hi all, I'm reading the docs and it says that when porting a new board - mine is a custom 8548 - a flash.c is needed. Indeed, most boards have a flash.c but I don't see one for the cds 85xx boards nor the mpc8544ds . I was planning on using CFI for my flash - the spansion S29GL01GP . Do I need a flash.c and if so what reference should I use to get started? Thanks! Robert

2 1

Re: [U-Boot-Users] Problems using UART1 instead of UART0
by Bob Grimes 24 Aug '07

24 Aug '07

Hi TsiChung, First, thanks! And second, sorry about the last ramble; it was late, and after nearly 16 hours at it, I needed a break! Third, I'm on vacation for a week starting tomorrow, and on another project today, so things will have to wait a bit. But I do owe you an explanation of where things sit. This is a bit long, and not time-critical, so feel free to set it aside for when you need a bit of comic relief! After emailing last, I tried a few experiments, and in thinking about the results this morning on the train, I am almost entirely certain the problem is somewhere in my hack to attempt to run out of RAM. What threw me on a long detour was an apparent flaky serial port. Late yesterday I realized that swap I mentioned in my first post, and what had appeared to be working software and flaky hardware actually was non-working software and working, though deceptive, hardware. What I had thought was the board responding to keyboard input via the serial port was in fact, a reflection of the received data on uart 0 being transmitted out the unused uart 1. Specifically, my theory is that because the uart 1 transmit pin was not being set as an output, and thus were left presumably floating, the received data arriving at the shared transceiver chip was strong enough to influence the input to the transceiver to case phantom transmission on the idle port - hence, the board, and more specifically, the software, seemed to be working. Hence also the timing seemed right! When I changed to the correct port, nothing happened, and attempting to break out of GDB caused it to report several errors, all to the effect that the CPU had run away. So ultimately I thought there was an issue with uart 1 programming. Investigation of the code, which isn't always easy with all the configuration, macros, include and source files in vastly different areas of the tree (e.g. ./board, ./cpu, ./drivers, ./lib_m68k) made it terribly difficult to convince myself the software was okay or not. Finally, I tried more carefully to debug what I thought was the working uart 0 version, and I finally noticed that breaking out from gdb wasn't working there either. Thinking about it this morning, I've realized that that version never was working to begin with! What I really understand now is that the problem lies in changing the clock near the beginning of startup, where uboot assumes it is running from flash - sdram gets corrupted, bam! The real problem is either (or both) my erroneous assumption that CFFlasher would work to program my flash, or that the flash is bad. Because we have a different flash part, unless CFFlasher is using CFI, the first assumption is wrong - is that correct? Also, I got an algorithm for programming the flash with the P&E Micro tools, but that didn't work. So I figured I would use uboot, running out of RAM. So I'm a bit stuck. My plan is to try a new algorithm with the P&E Micro tools; if that works, great! If not, I'm going to hack uboot to skip the clock change, adjust the baud rate calculation, and possibly skip the relocation; this last step is not necessary, IIRC. Once I get the hacked uboot-ram running from sdram, I'll use it to program the real uboot. Again, there _is_ a reason to run uboot from ram only! Thanks for all your help, and sorry if I've been too much of a pain - no excuse save a panic rush to get something positive done before a much needed, if not necessarily deserved, vacation! Take care, -Bob On 8/24/07, Liew Tsi Chung-r5aahp <Tsi-chung.Liew(a)freescale.com> wrote: > Bob, > > I'll get back on Monday to assist you. > > Regards, > TsiChung > > -----Original Message----- > From: Bob Grimes [mailto:rsg.uboot@gmail.com] > Sent: Thursday, August 23, 2007 10:05 PM > To: Liew Tsi Chung-r5aahp > Subject: Re: Problems using UART1 instead of UART0 > > On 8/23/07, Liew Tsi Chung-r5aahp <Tsi-chung.Liew(a)freescale.com> wrote: > > Bob, > > > > To try the extra uart on M5329EVB, connect pin 78 uart1 rx and pin 77 > uart1 tx, or pin 73 uart2 tx and pin 74 uar2 rx at J38. The signal is > only TTL, you will need a transceiver to have it working. > > I'll have to look into that, but I've been focusing on the customer's > board... ;-) > > > > > As for your custom board, you might need to check your RCON > configuration. It could have the RCON set at default value or other than > value specified in M5329EVB.h. Try to use oscope to check on the pin 24 > of BDM header first to find out the CPU clock speed. Then use that freq > to calculate your bus clock. The uart baud rate is based on the bus > clock. If the bus freq increase or descrease ~4Mhz, it will affect the > baudrate output. > > Okay, now I am really confused. > > 1. The RCON signal is not being used - it is pulled high with a 10k > resister to 3.3 V. > 2. RCON register reads 0x0001, which indicates "normal" operation - > right? > 3. When uboot is configured for uart0 and I run it, I get bit widths > about 8.5 us, which is close to 115,200 as expected. Not exactly, but I > think there's significant measurement error. Anyway, this isn't the > problem. > 4. When running, I see a nice, solid 2 MHz on pin 24 of BDM header. > 5. Oddly, FB_CLOCK is 1.333 MHz when running, pretty solid though. > When I power up the board without the BDM, this is solid 60 MHz, as > advertised. > > So, don't know about much of this. Are these signals normal? > > I don't know... I'm not sure if the processor is running or not, > though. At this point, I think it's software and/or hardware. ;-) My > current thinking is that there my attempt to run uboot only within ram > is not working right, actually. Unfortunately, while I have BDM > working, I can't program the Flash. I once got an old version > (1.1.6?) working from RAM, but abandoned that for your 1.2 port, but > that was on the m5329evb, so I could program that board's flash using > CFFlasher, then debug using BDM. Now, what can I do? By the way, this > is why one might want to run uboot from ram - to program the flash in > the first place!!! > > There doesn't seem to be any way to use CFFlasher with my board, even > though it is very similar to the m5329evb - probably because we're using > an 8 MB Atmel NOR flash chip.. > > Okay, I'm rambling, and best check out... > > -Disgruntled Bob > > > > Regards, > > TsiChung > > > > -----Original Message----- > > From: Bob Grimes [mailto:rsg.uboot@gmail.com] > > Sent: Thursday, August 23, 2007 7:21 PM > > To: Das U-Boot Mailing List; Liew Tsi Chung-r5aahp > > Subject: Problems using UART1 instead of UART0 > > > > Hi, > > > > I finally got our custom board, and unfortunately, the hardware guy > > seemed to have missed the message, and he's assigned the second > > mcf5329 uart to the console! Argh! > > > > So I've tried changing CFG_UART_PORT from (0) to (1), but nothing > seems to happen. I've traced into some of the code, and have confirmed > that the associated pins have been properly assigned to UART1. I'm > having trouble determining anything more than that; specifically, I've > yet to find the serial init code, as it seems to hang when setting the > cpu clock speed. Probably not too surprising I can't debug through that > code, but it doesn't seem to make it through. > > > > Tsi Chung, have you tried this? > > > > Back to the debugger, and code inspecting... > > > > Thanks, > > -Bob > > >

1 0

[U-Boot-Users] Ping command problem
by Prakash Palanisamy, TLS-Chennai 24 Aug '07

24 Aug '07

Hi All, I am using u-Boot with Lite5200 board for my project. I enabled "ping" command in u-Boot, but it is not working, giving Timeout error. But tftp is working fine. I don't find any hardware or network problem, because I am able to ping other machines from "DEBUG" monitor program shipped with Lite5200. The "PingHandler" function returns error , because the return value of "NetReadIP" function and the value of NetPingIP variable doesn't match. I have tracked the pkt structure assigned to volatile IP_t *ip . The value of ip_p(protocol), ip_src(Source IP address) , ip_dst( Destination IP address) are keep on changing. Is the problem because the pkt value has been corrupted ? Can any one suggest me the solution to fix this problem? Thanks & Regards, P.Prakash DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. -----------------------------------------------------------------------------------------------------------------------

1 0

[U-Boot-Users] Problems using UART1 instead of UART0
by Bob Grimes 24 Aug '07

24 Aug '07

Hi, I finally got our custom board, and unfortunately, the hardware guy seemed to have missed the message, and he's assigned the second mcf5329 uart to the console! Argh! So I've tried changing CFG_UART_PORT from (0) to (1), but nothing seems to happen. I've traced into some of the code, and have confirmed that the associated pins have been properly assigned to UART1. I'm having trouble determining anything more than that; specifically, I've yet to find the serial init code, as it seems to hang when setting the cpu clock speed. Probably not too surprising I can't debug through that code, but it doesn't seem to make it through. Tsi Chung, have you tried this? Back to the debugger, and code inspecting... Thanks, -Bob

2 1

[U-Boot-Users] AT91RM9200 Timer Interrupts
by Balajee Premraj 23 Aug '07

23 Aug '07

Hi , We are using the reference design board from ATMEL AT91RM9200EK. I currently see the u-boot for the at91rm9200, doesn't use the timer interrupts (cpu/arm920t/at91rm9200/interrupts.c) Although the hardware timer is being configured to run freely, the timestamp value doesn't get updated unless the get_timer() function is explicitly being called. We would like to know is there any specific reason why the timer interrupts are being disabled Thanks,Balajee

3 2