September 2005 - U-Boot

[U-Boot-Users] Wrong CFG_BSTOPRE encoding in cpu/mpc824x/cpu_init.c
by Peter Hanson 14 Sep '05

14 Sep '05

I'm trying to define CFG_BSTOPRE = 121, or about 1/8 of nominal REFINT. But when I read MCCR1-4 back with the BDI2000, the value looks like 604, not 121. The encoding of BSTOPRE is complex. It is split into 3 subfields, and spread over MCCR2 and MCCR4. The discrepency seems to be due to different assumptions about how the subfields are ordered in the composite value. The code in cpu/mpc824x/cpu_init.c extracts the pieces as ( BSTOPRE[6-9] || BSTOPRE[2-5] || BSTOPRE[0-1] ) Per Freescale technical support, these three fields are to be assembled as ( BSTOPRE[0-1] || BSTOPRE[2-5] || BSTOPRE[6-9] ) The Sandpoint 8240 configuration file confirms this view [http://www.ultsol.com/config/Motorola/SP8240.cfg] Regards, Peter Hanson

2 1

[U-Boot-Users] CSB637
by Farrah Rashid 14 Sep '05

14 Sep '05

My problem is that u-boot hangs - here's the relevant info: I'm using a csb637 developement board and serial dataflash. When the board is powered up, the boot loader on the serial dataflash is run. I use the boot loader to save u-boot into dataflash and then run u-boot by copying u-boot into sdram (0x21f00000) and jumping to that location. I should mention that before the boot loader jumps to sdram, it resets all registers and re-initiliazes the PLL. Is this how u-boot is supposed to be run? If the above is correct, I believe that the problem may be the u-boot build that I'm using. I started off with u-boot-1.1.3 and applied all the patches found on the newsgroup. Is this what others did? Thanks, Farrah

3 4

[U-Boot-Users] Reset doesn't work on the 440EP Bamboo reference board
by Youngchul Bang (방영철) 14 Sep '05

14 Sep '05

Hi, I have been trying to get U-Boot and Linux running on the AMCC 440EP "Bamboo" reference board. Most U-Boot commands are working. However, I've got problems about reset command and switch. First, reset command does not work except after cp.b command performed (i.e. cp.b 100000 fff80000 80000). I don't know why it works well after cp.b command. Reboot command in Linux doesn't work neither. U-Boot version is 1.1.3 and Linux kernel is 2.6.13. Is it related to the same reason? Second, the reset switch does not work. I've been confirmed that SYSTEM_RESET line is getting pulled down when I push the reset switch. When I try to get PIBS instead of U-Boot on the same board, the above problems haven't happened. Had the problems been discussed before in this list? I can't find any of conversations about them. If so, give me the url please. Let me know how to fix them up. Thanks in advance, Youngchul Bang

2 2

[U-Boot-Users] Bug in tools/fw_env.c ?
by Robin Gilks 14 Sep '05

14 Sep '05

Greetings Just a quick arm wave to see if I have the logic right. In a redundant environment when both sets are corrupt, the env_init function sets the environment data pointer to the default data. If this is then added to by the fw_setenv function, the memory overwritten is not the calloc'ed space that is big enough to hold the extra data but the initialised memory of the program that contains the defaults! Methinks that the defaults should be memcpy'ed into the calloc'ed space. I've not looked at the non-redundant env case. -- 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] improvement to setenv handling
by Ranger, Jean-Marc 13 Sep '05

13 Sep '05

Hi, While setting-up an OMAP 5912 OSK, I experienced funny behavior with U-Boot's setenv command. The cause was that I was using an invalid syntax with an equal sign, i.e. setenv variable=value instead of setenv variable value Apparently, nothing in U-Boot's code prevents from defining a variable with an equal in its name, but this cause strange behavious - see the examples below. In particular, pay attention to the fact that defining variable "a=b" cause existing variable "a" to be erased. The opposite is true also. Would it be a fair limitation to impose that variable names can't contain an equal sign, and either accept my invalid syntax or report an error ? Please note that this was tested with a binary image of U-Boot 1.1.1 as supplied by TI/Spectrum. I'd guess it also true on a stock 1.1.3, but I didn't test. Any comments ? Jean-Marc Ranger Ingénieur logiciel / Software Engineer SMIS R&D inc. 3100 Industriel Sherbrooke, Québec Canada J1L 1V8 Tel (819) 829-5120 ext 4242 Fax (819) 829-1133 U-Boot 1.1.1 (Jul 11 2005 - 15:47:28) U-Boot code: 11080000 -> 11095D78 BSS: -> 1109A548 RAM Configuration: Bank #0: 10000000 32 MB Micron StrataFlash MT28F128J3 device initialized Flash: 32 MB In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 OMAP5912 OSK # setenv a b OMAP5912 OSK # printenv baudrate=115200 ipaddr=156.117.97.156 serverip=156.117.97.139 netmask=255.255.254.0 bootargs=console=ttyS0,115200n8 noinitrd rw ip=off root=/dev/mtdblock4 mem=30M bootcmd=bootm 0x100000 bootfile=uImage bootdelay=10 stdin=serial stdout=serial stderr=serial a=b Environment size: 260/131068 bytes OMAP5912 OSK # setenv a b=c OMAP5912 OSK # printenv baudrate=115200 ipaddr=156.117.97.156 serverip=156.117.97.139 netmask=255.255.254.0 bootargs=console=ttyS0,115200n8 noinitrd rw ip=off root=/dev/mtdblock4 mem=30M bootcmd=bootm 0x100000 bootfile=uImage bootdelay=10 stdin=serial stdout=serial stderr=serial a=b=c Environment size: 262/131068 bytes OMAP5912 OSK # setenv a=b d OMAP5912 OSK # printenv baudrate=115200 ipaddr=156.117.97.156 serverip=156.117.97.139 netmask=255.255.254.0 bootargs=console=ttyS0,115200n8 noinitrd rw ip=off root=/dev/mtdblock4 mem=30M bootcmd=bootm 0x100000 bootfile=uImage bootdelay=10 stdin=serial stdout=serial stderr=serial a=b=d Environment size: 262/131068 bytes OMAP5912 OSK # setenv a=b OMAP5912 OSK # printenv baudrate=115200 ipaddr=156.117.97.156 serverip=156.117.97.139 netmask=255.255.254.0 bootargs=console=ttyS0,115200n8 noinitrd rw ip=off root=/dev/mtdblock4 mem=30M bootcmd=bootm 0x100000 bootfile=uImage bootdelay=10 stdin=serial stdout=serial stderr=serial Environment size: 256/131068 bytes OMAP5912 OSK # setenv a=b e OMAP5912 OSK # printenv baudrate=115200 ipaddr=156.117.97.156 serverip=156.117.97.139 netmask=255.255.254.0 bootargs=console=ttyS0,115200n8 noinitrd rw ip=off root=/dev/mtdblock4 mem=30M bootcmd=bootm 0x100000 bootfile=uImage bootdelay=10 stdin=serial stdout=serial stderr=serial a=b=e Environment size: 262/131068 bytes OMAP5912 OSK # setenv a b=f OMAP5912 OSK # printenv baudrate=115200 ipaddr=156.117.97.156 serverip=156.117.97.139 netmask=255.255.254.0 bootargs=console=ttyS0,115200n8 noinitrd rw ip=off root=/dev/mtdblock4 mem=30M bootcmd=bootm 0x100000 bootfile=uImage bootdelay=10 stdin=serial stdout=serial stderr=serial a=b=f Environment size: 262/131068 bytes OMAP5912 OSK #

2 1

[U-Boot-Users] MPC8560 DDR controller
by Murray.Jensen＠csiro.au 13 Sep '05

13 Sep '05

Hi U-Boot Users, I noticed a patch go through CVS a few days ago which updated the DDR DLL workaround for the tqm8560 and tqm8540 boards and it piqued my interest - mainly because we are having trouble with the DDR memory on our MPC8560 board. I am interested in other people's experiences with the DDR controller on their MPC8560 based boards - either positive or negative. Here is our tail ... It appears that noise internal to the processor is corrupting reads from DDR memory (by causing the DDR DLL to drop out). We have played extensively with the DDR configuration, following instructions in AN2583 (rev 2) and the DDR11 errata, with some success - but I don't think we have ever been able to completely eliminate the problem, only greatly reduce its frequency. The things that seemed to help the most were setting the Reduced Drive Strength extended operating mode in the DDR memory chips themselves, and slowing the bus rate from 166MHz to 150Mhz. i.e. both of these really have nothing to do with the processor's DDR controller, or any errata workarounds, they obviously just combine to reduce noise on the bus. Our processors are marked "PPC8560..." rather than "MPC8560.." and are dated 0412 (week 12 of 2004 I believe ??). We were thinking that maybe these were pre-production chips and it might help things if we replaced them with "younger chips". By the way, I believe our chips are version 2.0.2. The board is currently usable for development, but would be unacceptable for production use - but even in development, if you get a crash, you can't really be sure if there was a real problem or whether the memory read simply failed. Does anyone have any experiences and/or advise they could share with us? Thank you for listening. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 4

[U-Boot-Users] How to get start with u-boot for MPC83xx?
by yang simon 13 Sep '05

13 Sep '05

I am a newbie on u-boot, Can anyone give me some suggestions on this?

2 1

[U-Boot-Users] dead cfi strataflash
by David Updegraff 13 Sep '05

13 Sep '05

Hi. I think I inadvertently scribbled junk to my strataflash chip cfg. since I can no longer read any reg. except the STATUS register from it; which simply sits there saying 'READY'. Everything else says 0xff, except for offset :0x04 which is oddly 0xfe. Anyone know of any tricks that can be used to try recover? Or am I down to coaster/re-solder job? Advice -- or just consolation -- appreciated. -dbu.

1 0

[U-Boot-Users] flash_info structure and large Flash chips
by Alexander Perkalskite 12 Sep '05

12 Sep '05

Dear users, I'm porting the u-boot 1.1.2 to our hardware which has two banks of AM29LV256 chips (32M, 512 sectors x 64K each). So I have the following #defines: CFG_MAX_FLASH_BANKS 2 CFG_MAX_FLASH_SECT 512 Now I'm crashing in function flash_init() before calling flash_get_size(). My assumption is that the data structure flash_info[] has become too big, in disassembly I see the following: 0xfff38258 <flash_info+3664>: .long 0x0 0xfff3825c <flash_info+3668>: .long 0x0 0xfff38260 <flash_info+3672>: .long 0x0 0xfff38264 <flash_info+3676>: .long 0x0 0xfff38268 <flash_info+3680>: .long 0x0 0xfff3826c <flash_info+3684>: .long 0x0 0xfff38270 <flash_info+3688>: .long 0x0 0xfff38274 <flash_info+3692>: .long 0x0 0xfff38278 <flash_info+3696>: .long 0x0 0xfff3827c <flash_info+3700>: .long 0x0 0xfff38280 <flash_info+3704>: .long 0x0 0xfff38284 <_SDA_BASE_>: .long 0x0 0xfff38288 <_SDA_BASE_+4>: .long 0x0 0xfff3828c <_SDA_BASE_+8>: .long 0x0 0xfff38290 <_SDA_BASE_+12>: .long 0x0 0xfff38294 <_SDA_BASE_+16>: .long 0x0 0xfff38298 <_SDA_BASE_+20>: .long 0x0 0xfff3829c <_SDA_BASE_+24>: .long 0x0 0xfff382a0 <_SDA_BASE_+28>: .long 0x0 0xfff382a4 <_SDA_BASE_+32>: .long 0x0 0xfff382a8 <_SDA_BASE_+36>: .long 0x0 0xfff382ac <_SDA_BASE_+40>: .long 0x0 0xfff382b0 <_SDA_BASE_+44>: .long 0x0 0xfff382b4 <_SDA2_BASE_>: .long 0x0 0xfff382b8 <_SDA2_BASE_+4>: .long 0x0 0xfff382bc <_SDA2_BASE_+8>: .long 0x0 Does it look as an overlap? How can I overcome this? Thanks in advance, Alexander Perkalskite. --------------------------------- Yahoo! for Good Click here to donate to the Hurricane Katrina relief effort.

2 1

[U-Boot-Users] env tools & dataflash
by Sergei Sharonov 12 Sep '05

12 Sep '05

Hi, When using Linux tools to read/write u-boot environment in Dataflash there seems to be a problem. In fw_env.c / flash_io(): resid = DEVESIZE (otherdev) - CFG_ENV_SIZE; If I understand correctly DEVESIZE (otherdev) is an erase block size which 0x210 for Dataflash and is smaller than CFG_ENV_SIZE. Then malloc in if ((data = malloc (resid)) == NULL) { fails because of negative size. Sergei

1 0