August 2005 - U-Boot

RE: [U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)
by Martin Krause 24 Aug '05

24 Aug '05

Hi Steven, Steven Scholz wrote on : > Martin, > > > A clock rate > 180 MHz could be problematic. According errata 42 > > (AC Characteristics: PLL Frequency Limitation), in AT91RM9200 errata > > sheet (doc6015) the PLL is limited to 180 MHz. We already had > > problems with this bug (with about 10%-15% of the CPUs). After > > configuring the PLL for 179 MHz no errors occour any mor (before we > > used 207 MHz). > > Which errors and problems did you encounter? The Linux kernel (2.4.27 linuxarm tree from Denx) did not run stable on the affected boards. We see sporadic failures and core dumps. Regards, Martin

1 0

Re: [U-Boot-Users] Re: MIPS LE build problems
by Wolfgang Denk 24 Aug '05

24 Aug '05

In message <4304D3FD.7080107(a)smiths-aerospace.com> you wrote: > > As noted in other email in this thread, executing the above code won't > work. What about simply compiling a file containing: > > constant int data = 0x01234567; > > objdumping the data section, and looking (grepping) to see if the data > section has 0x12345678 or 0x78563412? Doesn't work as objdump will be user friendly and always print the "correct" value, i. e. 0x01234567. But the idea is good. The attached test script works with the tool chains available to me. Can others please test this, too? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de Many aligators will be slain, but the swamp will remain.

4 6

RE: [U-Boot-Users] AT91RM9200 Errata (Was: CSB637 support - big bug..)
by Martin Krause 24 Aug '05

24 Aug '05

Hi, Anders Larsen wrote on : > "Patrick .." <oc3an(a)gmx.net> schreibt: > > Also, it is safe to use a divisor of 3 for the Master Clock, this > > gives > > 61.44MHz from a core of 184.32Mhz which is fine for the CSB637 > > (master clock limit is 80MHz), users should see a decent > > improvement in performance by doing this as it will increase the > > SDRAM bandwidth by a substantial amount. > > Well, I got the clock values from linux 2.6.12 board-csb637.c; > does Linux still boot correctly with your change? I already posted this on the list, but a little reminder won't hurt :) A clock rate > 180 MHz could be problematic. According errata 42 (AC Characteristics: PLL Frequency Limitation), in AT91RM9200 errata sheet (doc6015) the PLL is limited to 180 MHz. We already had problems with this bug (with about 10%-15% of the CPUs). After configuring the PLL for 179 MHz no errors occour any mor (before we used 207 MHz). Regards, Martin

3 2

[U-Boot-Users] RFC: U-Boot Environment support in SystemAce Compact FLASH
by Keith J Outwater 23 Aug '05

23 Aug '05

Hello all - I have completed the initial port of U-Boot to a custom PPC405/VirtexII Pro FPGA board and I am starting to look at ways to store the U-Boot environment in the CF card used for FPGA configuration by the Xilinx SystemAce. As it stands now, there is DOS FAT read support in U-Boot but no write support, so that would have to be added if the environment was to be stored as a DOS file on the CF card. Another option might be to partition the CF card so as to leave a few sectors unused and use low-level sector read/write routines to store the environment directly to the CF card. This solution seems straightforward, but seems somehow inelegant. I am leaning toward the approach of adding DOS FAT write support and adjusting the initial U-Boot environment to provide sufficient stack space to run the DOS filesystem code during initial boot. Does this seem reasonable? Does anyone know where the original DOS filesystem code came from? Keith

4 5

[U-Boot-Users] CSB637 support
by Patrick .. 23 Aug '05

23 Aug '05

Hi, I have searched long and hard on the lists and have found much discussion about csb637 support, but i am unable to find the actual patch. Is someone able to point me in the right direction please? Thanks, -Patrick -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse f�r Mail, Message, More +++

3 3

RE: [U-Boot-Users] [PATCH] cfi_flash.c patches
by Woodruff, Richard 23 Aug '05

23 Aug '05

Tolunay, Several Intel chips do provide hardware level protection locks which get cleared at reset. It is useful to use this hardware feature at boot to help protect flash sectors from upper level code during normal operation. The u-boot software lock is nice, but doesn't extend beyond u-boot code while the hardware lock does. The difference in behavior between chips is the issue here. Perhaps it is better to add another compile time flag which allows the hardware features to be used on such chips. Your point is one _hardware_ features behavior should be valued over another's. Having them both via flags is probably the way to go. Regards, Richard W. > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users- > admin(a)lists.sourceforge.net] On Behalf Of Tolunay Orkun > Sent: Friday, August 19, 2005 1:37 PM > To: Sangmoon Kim > Cc: u-boot; Wolfgang Denk > Subject: Re: [U-Boot-Users] [PATCH] cfi_flash.c patches > > Dear Sangmoon, > > I've examined your patch for clearing the protection of flash sectors > automatically during flash init. As a matter of fact a similar patch was > also proposed by someone else and I had commented on it as well. > > I think this is wrong approach. These sectors are protected for a reason > (to prevent accidental writes - forgetting to enable protection). > > You should enable CFG_FLASH_PROTECTION in your board config file. If you > don't do this U-Boot will do software protection of sectors (which is > really for those flash chips with no hardware protection capability) and > "protect off" will not issue unlock commands as you may have witnessed. > > CFG_FLASH_PROTECTION will enable the "protect off" command to disable > protection properly on these sectors as it should. > > IMHO, No patch is needed here! Perhaps we need to add a couple of > comment lines in README (DULG?) for documentation purposes. Wolfgang, > can you comment here. > > Best regards, > Tolunay > > Sangmoon Kim wrote: > > Hi, > > The two patches attached are for drivers/cfi_flash.c. > > > > cfi_flash-protect.patch adds CFG_FLASH_PROTECT_CLEAR > > because for some flash memories(such as 28F320C3) > > all banks are protected after reset. > > > > cfi_flash-buffer.patch makes write_buff not to call > > flash_write_cfibuffer if buffer_size is1. > > Because for flash memories with buffer_size 1, > > buffer write is not supported. > > > > Regards, > > Sangmoon Kim > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users

3 2

[U-Boot-Users] fatload problems with CF
by Keith J Outwater 23 Aug '05

23 Aug '05

Hello all - I am having a strange problem with the fatload command. I am able to do a 'fatls' on a CD card connected to a SystemACE controller but when I try to load a file on any partition using 'fatload', the FAT code is calling the SystemACE specific sector read routine with a block count of zero. I am using a U-Boot snapshot from CVS that is about a month old. Thanks! Keith

1 0

[U-Boot-Users] About CS8900A's MAC address
by mail2jarod 23 Aug '05

23 Aug '05

Hi all, I am porting u-boot-1.1.3 to a Samsung S3C44B0X based board that I bought several months ago. It consists of a CS8900A as its ethernet controller. When I write a configuration header file (include/configs/jx44b0.h) for the board, I find that I don't know the CS8900A's MAC address. I wonder how to figure it out. Sorry for my poor English. Any advice should be appreciated. Regards, Jarod Wang

1 0

[U-Boot-Users] Using "cu" for tranferring files
by Swapnil Ashok Narkhede 23 Aug '05

23 Aug '05

I did try to use "cu" for tranferring the files. But i can see the monitor command prompt and not enter any input. This problem is related to the flow control, i reckon, and so i try to figure out how do i set it. I have used the settings as mentioned in the DULG manual for setting up "cu". hardflow is set to false. but still i cannot input any values. Is there any other way of setting the hardware and software flow control to none. How do i get this working. Regards, Swapnil Narkhede Mob:- 0432025023 Email:- s3092131(a)student.rmit.edu.au School of Computer Science and Information Technology RMIT University, Melbourne

1 0

[U-Boot-Users] regarding uboot
by prabha.j＠tcs.com 23 Aug '05

23 Aug '05

Sir, My name is prabha. I have some questions regarding the uboot. I hope u will help me in this regard. 1.Actually i have a target as intel board with P4 machine and having 830 as intel chip set. I searched whether uboot supports this architecture. I came to know that uboot supports very few intel boards. Now the question is how to bring up this board using uboot and how to get the toolchain for this board. Will uboot supports this architecture or not. 2. I am using p4 as my host m/c and untarred uboot1.1.3 and when i gave make sc520_cdp_config it gives Configuring for sc520_cdp board... and after this if i give make it gives error as make 'make[1]: Entering directory `/root/praba/u-boot-1.1.3/tools' make[1]: `.depend' is up to date. make[1]: Leaving directory `/root/praba/u-boot-1.1.3/tools' make[1]: Entering directory `/root/praba/u-boot-1.1.3/examples' make[1]: `.depend' is up to date. make[1]: Leaving directory `/root/praba/u-boot-1.1.3/examples' make[1]: Entering directory `/root/praba/u-boot-1.1.3/post' make[1]: `.depend' is up to date. make[1]: Leaving directory `/root/praba/u-boot-1.1.3/post' make[1]: Entering directory `/root/praba/u-boot-1.1.3/post/cpu' make[1]: `.depend' is up to date. make[1]: Leaving directory `/root/praba/u-boot-1.1.3/post/cpu' make -C tools all make[1]: Entering directory `/root/praba/u-boot-1.1.3/tools' gcc -g -Wall -pedantic -idirafter ../include -DTEXT_BASE=0x387c0000 -DUSE_HOSTCC -O -c envcrc.c gcc -g -idirafter ../include -DTEXT_BASE=0x387c0000 -DUSE_HOSTCC -c environment.c gcc -Wall -pedantic -idirafter ../include -DTEXT_BASE=0x387c0000 -DUSE_HOSTCC -O -o envcrc envcrc.o crc32.o environment.o make[1]: Leaving directory `/root/praba/u-boot-1.1.3/tools' make -C examples all make[1]: Entering directory `/root/praba/u-boot-1.1.3/examples' gcc -g -Os -D__KERNEL__ -DTEXT_BASE=0x387c0000 -I/root/praba/u-boot-1.1.3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/i386-redhat-linux/3.4.2/include -pipe -DCONFIG_I386 -D__I386__ -march=i386 -Werror -Wall -Wstrict-prototypes -c -o 82559_eeprom.o 82559_eeprom.c 82559_eeprom.c: In function `memcpy': 82559_eeprom.c:57: warning: use of cast expressions as lvalues is deprecated 82559_eeprom.c:57: warning: use of cast expressions as lvalues is deprecated make[1]: *** [82559_eeprom.o] Error 1 make[1]: Leaving directory `/root/praba/u-boot-1.1.3/examples' make: *** [examples] Error 2 Now the question is that should i have to build toolchain for this or not. Since this is a intel board i thought it will take the same gcc which host machine have and do the necessary steps. But i think it is not the case. I didn't do any changes in the Makefile. Please help me in this regard. Regards Prabha J. Tata Consultancy Services Limited Mailto: prabha.j(a)tcs.com Website: http://www.tcs.com Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

1 0