April 2005 - U-Boot

[U-Boot-Users] Patch: allow a fixed port for TFTP (take 3)
by Jerry Van Baren 24 Sep '05

24 Sep '05

Hi Wolfgang, try three on the patch attached. The change here is to rename the env variable per Tolunay Orkun's recommendation. * Patch by Jerry Van Baren 11 January 2005 - Add a configuration option CONFIG_TFTP_PORT and optional env variable tftpsourceport to force TFTP to use a fixed UDP port. gvb Index: README =================================================================== RCS file: /cvsroot/u-boot/u-boot/README,v retrieving revision 1.117 diff -p -u -r1.117 README --- README 9 Jan 2005 23:16:42 -0000 1.117 +++ README 10 Jan 2005 04:13:50 -0000 @@ -1480,6 +1480,22 @@ The following options need to be configu When SystemACE support is added, the "ace" device type becomes available to the fat commands, i.e. fatls. +- TFTP Fixed UDP Port: + CONFIG_TFTP_PORT + + If this is defined, the environment variable tftpsourceport + is used to supply the TFTP UDP source port value. + If tftpsourceport isn't defined, the normal pseudo-random port + number generator is used. + + The purpose for this is to allow a TFTP server to + blindly start the TFTP transfer using the pre-configured + target IP address and UDP port. This has the effect of + "punching through" the (Windows XP) firewall, allowing + the remainder of the TFTP transfer to proceed normally. + A better solution is to properly configure the firewall, + but sometimes that is not allowed. + - Show boot progress: CONFIG_SHOW_BOOT_PROGRESS @@ -2432,6 +2448,9 @@ Some configuration options can be set us Useful on scripts which control the retry operation themselves. + tftpsourceport - If this is set, the value is used for TFTP's + UDP source port. + vlan - When set to a value < 4095 the traffic over ethernet is encapsulated/received over 802.1q VLAN tagged frames. Index: net/tftp.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/net/tftp.c,v retrieving revision 1.9 diff -p -u -r1.9 tftp.c --- net/tftp.c 15 Apr 2004 21:48:55 -0000 1.9 +++ net/tftp.c 10 Jan 2005 04:13:51 -0000 @@ -301,6 +301,10 @@ TftpTimeout (void) void TftpStart (void) { +#ifdef CONFIG_TFTP_PORT + char *ep; /* Environment pointer */ +#endif + if (BootFile[0] == '\0') { IPaddr_t OurIP = ntohl(NetOurIP); @@ -354,7 +358,13 @@ TftpStart (void) TftpServerPort = WELL_KNOWN_PORT; TftpTimeoutCount = 0; TftpState = STATE_RRQ; + /* Use a pseudo-random port unless a specific port is set */ TftpOurPort = 1024 + (get_timer(0) % 3072); +#ifdef CONFIG_TFTP_PORT + if ((ep = getenv("tftpsourceport")) != NULL) { + TftpOurPort= simple_strtol(ep, NULL, 10); + } +#endif TftpBlock = 0; /* zero out server ether in case the server ip has changed */

3 10

[U-Boot-Users] Patch: allow a fixed port for TFTP
by Jerry Van Baren 24 Sep '05

24 Sep '05

Hi Wolfgang, try two on the patch attached. * Patch by Jerry Van Baren 10 January 2005 - Add a configuration option CONFIG_TFTP_PORT and optional env variable tftpport to force TFTP to use a fixed UDP port. gvb Index: README =================================================================== RCS file: /cvsroot/u-boot/u-boot/README,v retrieving revision 1.117 diff -p -u -r1.117 README --- README 9 Jan 2005 23:16:42 -0000 1.117 +++ README 10 Jan 2005 04:13:50 -0000 @@ -1480,6 +1480,22 @@ The following options need to be configu When SystemACE support is added, the "ace" device type becomes available to the fat commands, i.e. fatls. +- TFTP Fixed UDP Port: + CONFIG_TFTP_PORT + + If this is defined, the environment variable tftpport + is used to supply the TFTP UDP source port value. + If tftpport isn't defined, the normal pseudo-random port + number generator is used. + + The purpose for this is to allow a TFTP server to + blindly start the TFTP transfer using the pre-configured + target IP address and UDP port. This has the effect of + "punching through" the (Windows XP) firewall, allowing + the remainder of the TFTP transfer to proceed normally. + A better solution is to properly configure the firewall, + but sometimes that is not allowed. + - Show boot progress: CONFIG_SHOW_BOOT_PROGRESS @@ -2432,6 +2448,9 @@ Some configuration options can be set us Useful on scripts which control the retry operation themselves. + tftpport - If this is set, the value is used for TFTP's + UDP source port. + vlan - When set to a value < 4095 the traffic over ethernet is encapsulated/received over 802.1q VLAN tagged frames. Index: net/tftp.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/net/tftp.c,v retrieving revision 1.9 diff -p -u -r1.9 tftp.c --- net/tftp.c 15 Apr 2004 21:48:55 -0000 1.9 +++ net/tftp.c 10 Jan 2005 04:13:51 -0000 @@ -301,6 +301,10 @@ TftpTimeout (void) void TftpStart (void) { +#ifdef CONFIG_TFTP_PORT + char *ep; /* Environment pointer */ +#endif + if (BootFile[0] == '\0') { IPaddr_t OurIP = ntohl(NetOurIP); @@ -354,7 +358,13 @@ TftpStart (void) TftpServerPort = WELL_KNOWN_PORT; TftpTimeoutCount = 0; TftpState = STATE_RRQ; + /* Use a pseudo-random port unless a specific port is set */ TftpOurPort = 1024 + (get_timer(0) % 3072); +#ifdef CONFIG_TFTP_PORT + if ((ep = getenv("tftpport")) != NULL) { + TftpOurPort= simple_strtol(ep, NULL, 10); + } +#endif TftpBlock = 0; /* zero out server ether in case the server ip has changed */

3 4

[U-Boot-Users] dbau1550 patch
by Andrew Dyer 24 Sep '05

24 Sep '05

A while back (Sep 23, 2004) someone named Leif posted a note about a patch to add support for the AMD DbAU1550 board to u-boot here https://sourceforge.net/mailarchive/forum.php?thread_id=5624545&forum_id=12… I can't seem to find the patch he referred to and I would like to get a hold of it. -- Hardware, n.: The parts of a computer system that can be kicked.

4 6

[U-Boot-Users] common/cmd_mii.c bug and patch
by Andrew Dyer 24 Sep '05

24 Sep '05

The mii info command (the !CONFIG_TERSE_MII version) has a bug in current cvs. If the phy address is passed to the command the code assigns the variable addr to start, instead of the values of addrlo which is extracted from the command line. At that point in the code addr is always 0. to demonstrate find a board with a phy at a non-zero address, compare the results of 'mii info' and mii info 1' (substitute the phy address on the test board for 1). Also in this file on lines 55 and 418 there are two places where a call to mii_init() is conditionally compiled in, but one condition includes defined(CONFIG_MCF52x2) and the other doesn't. Is this intentional? -- Hardware, n.: The parts of a computer system that can be kicked.

2 1

[U-Boot-Users] PATCH: Fix ppc 440 timer freq.
by Travis B. Sawyer 15 Aug '05

15 Aug '05

This patch fixes 440 timer frequency (move from 10ms to 1 ms), as found by Andrew Wozniak. Changelog * Patch by Travis Sawyer, 05 Apr 2005: - Change timer frequency for ppc 440 from 10 ms to 1 ms. Problem found by Andrew Wozniak. Andy, thank you for pointing this out. Best Regards, Travis diff -purN u-boot/cpu/ppc4xx/interrupts.c u-boot_modified/cpu/ppc4xx/interrupts.c --- u-boot/cpu/ppc4xx/interrupts.c 2004-03-14 10:20:56.000000000 -0500 +++ u-boot_modified/cpu/ppc4xx/interrupts.c 2005-04-05 19:56:27.793079640 -0400 @@ -134,7 +134,7 @@ int interrupt_init_cpu (unsigned *decrem mtspr( dec, 0 ); /* Prevent exception after TSR clear*/ mtspr( decar, 0 ); /* clear reload */ mtspr( tsr, 0x08000000 ); /* clear DEC status */ - val = gd->bd->bi_intfreq/100; /* 10 msec */ + val = gd->bd->bi_intfreq/1000; /* 1 msec */ mtspr( decar, val ); /* Set auto-reload value */ mtspr( dec, val ); /* Set inital val */ #else

2 1

[U-Boot-Users] [PATCH] support for CF/IDE on PCMCIA for PXA25X
by Christian Pell 13 Aug '05

13 Aug '05

Hi, I tried this with some different CFs with FAT file-systems on them. There is a README in the patch itself that goes in documentation directory. Bye, -- Christian Pellegrin <chri(a)ascensit.com>, <c.pellegrin(a)eurotech.it>, <chri(a)infis.univ.ts.it>, <c.pellegrin(a)exadron.com>

4 8

[U-Boot-Users] Patches for ARM IntegratorCP, ARM926EJS, and ARM946ES
by Shawn Jin 12 Aug '05

12 Aug '05

Hi, The patches were developed on an ARM IntegratorCP board with ARM946ES. Since the majority code of ARM946ES cpu was copied from ARM926EJS and there was bug about CFG_HZ found in ARM946ES later, I also fixed this CFG_HZ error on ARM926EJS. The major changes are 1. Mulitple core modules support (u-boot.multicm.patch) Following OMAP boards' methodology, I added mulitple core module configuration. For example, integratorcp_946es_config is for IntegratorCP board with ARM946ES, integratorcp_config is for IntegratorCP board with ARM926EJS by default, integratorap_946es_config is for IntegratorAP board with ARM946ES, and integratorap_config is for IntegratorAP with ARM926EJS. Now only two core modules are supported, ARM946ES and ARM926EJS. 2. ARM946ES support (u-boot.arm946es.patch) 3. ARM926EJS bug fix (u-boot.arm926ejs.patch) Fixed CFG_HZ problem. Set CFG_HZ to 1000. The solution is from AT91RM9200. 4. IntegratorCP bug fixes (u-boot.integratorcp.patch) Added SDRAM size information and FLASH support. Philippe, I don't have an ARM926EJS core module. Would you please test the CFG_HZ fix on your system? Thanks. Regards, -Shawn.

3 6

[U-Boot-Users] Minor cleanup
by Anders Larsen 12 Aug '05

12 Aug '05

Hi, Rick Bronson and the AT91RM9200DK is listed under PPC Systems. Since the AT91RM9200 is an ARM SoC, the attached patch against current top of CVS moves the entry to the appropriate position. Changelog: Move the AT91RM9200DK to the ARM Systems list. Cheers Anders

2 1

[U-Boot-Users] Eliminate calls of _divsi3 on ARM
by Anders Larsen 12 Aug '05

12 Aug '05

Hi, the enclosed patch agains current top of CVS eliminates two calls of the libgcc helper function _divsi3 and _modsi3. Rationale: Certain commercially available tool-chains provides b0rken libgcc.a (compiled with hardware FP) making these helper functions unusable (U-Boot already provides the unsigned counterparts in lib_arm/libarm.a). Changelog: Eliminate calls of ARM libgcc.a helper functions _divsi3 and _modsi3 Cheers Anders

3 4

[U-Boot-Users] UBoot cvs compile error.
by Bryan O'Donoghue 12 Aug '05

12 Aug '05

make Adder_config edit config.mk uncomment -DDEBUG fails to resolve measure_gclk Changing cpu/mpc8xx/speed.c #if !defined(CONFIG_8xx_CPUCLK_DEFAULT) || defined(CFG_MEASURE_CPUCLK) to #if !defined(CONFIG_8xx_CPUCLK_DEFAULT) || defined(CFG_MEASURE_CPUCLK)\ || defined(DEBUG) fixes. -- Best regards Bryan

2 1

[U-Boot-Users] Switch between PlanetCore and U-Boot freely
by Sam Song 08 Aug '05

08 Aug '05

Hi all, Well, somebody was trying to pull the cat out of my bag. Here it is:-) ------------------------------------------------- After several heart-struck failure, I got one workable way to program each other in FLASH between PlanetCore and U-Boot. Hardware Platform : RPXlite DW(EP 823 H1 DW) 1. From U-Boot to PlanetCore Utilities : PlanetCore Boot Loader - PCL200.mot [root@sam tftpboot]# ppc_8xx-objcopy -O ppcboot PCL200.mot pcl200.bin [Target Operation] u-boot>t 100000 pcl200.bin u-boot>go 0x100000 ## Starting application at 0x00100000 ... MPC8xx PlanetCore Flash Burner v2.00 Copyright 2001 Embedded Planet. All rights reserved. Construct Flash Device.....done. Program MPC8xx PlanetCore Boot Loader v2.00 Built Sep 19, 2001 at 14:34:42 Image located from FC000000 to FC01B5D1. (Skipping an image, only loading low boot image) Low boot board detected, skipping high boot image. Erasing, programming and verifying will start in 20 seconds Press P to start immediately or ESC to cancel Press Space or Enter for more options. .............. Erasing Programming FLASH programmed successfully! Press R to induce a hard reset MPC8xx PlanetCore Boot Loader v2.00 Copyright 2001 Embedded Planet. All rights reserved. DRAM available size = 64 MB wvCV DRAM OK > 2. From PlanetCore to U-Boot Utilities : PlanetCore FLASH Burner - PCB200.mot Use Flash Burner to finish the work: First, TFTP the U-Boot image file to RAM; For example, RPXlite_DW.bin to 0x400000 Second, TFTP FLASH Burner to RAM; For example, 0x100000 Third, run the FLASH Burner and Program the U-Boot image into the correct location in FLASH. [Target Operation] MPC8xx PlanetCore Boot Loader v2.00 Copyright 2001 Embedded Planet. All rights reserved. DRAM available size = 64 MB wvCV DRAM OK >t Load using tftp via Ethernet Enter server IP address <172.16.115.6> : Enter server filename <PCL200.mot> : RPXlite_DW.bin Enter (B)inary or (S)record input mode <S> : B Enter address offset : <00400000 hex> : Total bytes = 120096 in 232184 uSecs Loaded addresses 00400000 through 0041D51F. Start address = 00400000 >t Load using tftp via Ethernet Enter server IP address <172.16.115.6> : Enter server filename <RPXlite_DW.bin> : PCB200.mot Enter (B)inary or (S)record input mode <B> : S Enter address offset : <00000000 hex> : .512.1024..2048....4096..... Total bytes = 326280 in 2570249 uSecs Loaded addresses 00100000 through 0011BB51. Start address = 00100000 >go [Go 00100000] MPC8xx PlanetCore Flash Burner v2.00 Copyright 2001 Embedded Planet. All rights reserved. Construct Flash Device.....done. Bad start address Start = 0xFFFFFFFF, target = 0xFFFFFFFF, length = 0xFFFFFFFF Forcing Menu Interface h[elp] Show commands. c[ode] Show information on code to be loaded. di[splay] Display all flash sections. du[mp] Dump memory. d ? for more info. e[rase] Erase flash sections. f[ill] Fill flash sections. im[age] Toggle load high, low, or both flash images. in[fo] Show flash information. ma[p] Show memory map. mo[dify] Modify memory. m ? for more info. p[rogram] Erase, program, and verify now. reset Restart the loader. s[how] Show flash sections to erase and program. t[est] Test flash sections. q[uit] Quit without programming. #program 400000 ff000000 1D51F doProgram( 400000 ff000000 1D51F ) Start = 0x00400000, target = 0xFF000000, length = 0x0001D51F Erasing sector 0xFF000000, length 0x008000. Erasing sector 0xFF008000, length 0x008000. Erasing sector 0xFF010000, length 0x008000. Erasing sector 0xFF018000, length 0x008000. Programming FF000000 through FF01D51E FLASH programmed successfully! Press R to induce a hard reset Forcing Hard Reset by MachineCheck and ResetOnCheckstop... U-Boot 1.1.2 (Aug 29 2004 - 15:11:27) CPU: PPC823EZTnnB2 at 48 MHz: 16 kB I-Cache 8 kB D-Cache Board: RPXlite_DW DRAM: 64 MB FLASH: 16 MB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: SCC ETHERNET u-boot> ------------------------------------------------- Well, sometimes network function of PlanetCore couldn't work when switching from U-Boot to PlanetCore. For example, you couldn't download a file from HOST PC via TFTP. Don't worry, just restart your HOST PC and everything would work as smooth as clockwork. I don't know the reason WHY:-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Merry Christmas and Happy New Year! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ===== Best regards, Sam _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

2 3

[U-Boot-Users] [patch]fixes for cmd_fpga.c
by Andrew Dyer 08 Aug '05

08 Aug '05

The attached patch: 1) fixes a bug with the 'fpga loadb' command The bug is in calculating the config data size - 4 bytes of length info were being read as signed chars, casted to long, shifted and added. The cast to long was doing sign extension and causing an incorrect result if a byte was greater than 0x80. For me this caused the fpga load to end early and time out waiting for the hardware completion. 2) removes compilation warnings about using __FUNCTION__ concatenated with strings 3) changes the fpga loadb to always print the file header info during a load. I realize this patch is a mishmash - hopefully it's helpful to someone. -- Hardware, n.: The parts of a computer system that can be kicked.

2 1

[U-Boot-Users] [PATCH] Fix SystemACE CF access errors
by Jeff Angielski 07 Aug '05

07 Aug '05

Attached is a patch that fixes the configuration controller errors that sometimes occur when accessing the SystemACE CF. The patch also fixes the locking routines so that they do not stomp on the other bits in the controller register. Finally, the patch will auto detect the partition type to prevent "Partition x not valid on device y" error messages. CHANGELONG: * Patch by Jeff Angielski 09 Jan 2005 Fix errors that occur when accessing SystemACE CF.

2 1

[U-Boot-Users] [PATCH] fix PowerQUICC II masks detection
by Eugene Surovegin 06 Aug '05

06 Aug '05

Hi! This trivial patch fixes typos in cpu/mpc8260/cpu.c:checkcpu(). * Patch by Eugene Surovegin, 20 Dec 2004: Fix PowerQUICC II mask detection.

2 1

[U-Boot-Users] Patch: Add support for Embedded Planet EP8248 board
by Yuli Barcohen 06 Aug '05

06 Aug '05

Hi, The attached patch adds support for Embedded Planet EP8248 board. It was tested on EP8248E revision 1.0. CHANGELOG: Add support for Embedded Planet EP8248 board -- ======================================================================== Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader yuli(a)arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel ========================================================================

2 1

[U-Boot-Users] [PATCH] BUGFIX: serial setting for kgdb
by HoJin 06 Aug '05

06 Aug '05

Hi, KGDB_SMC_INDEX must be used as the index for brg_map, but it is used direclty. (compared with function serial_init) So it does not work properly. I have tested it and it works fine. I noticed the same problem with 'serial_scc.c', but I could not test it yet. Patch for only for 'serial_smc.c' is attached. Index: cpu/mpc8260/serial_smc.c =================================================================== --- cpu/mpc8260/serial_smc.c (revision 65) +++ cpu/mpc8260/serial_smc.c (working copy) @@ -360,10 +360,10 @@ /* Set up the baud rate generator. */ #if defined(CONFIG_KGDB_USE_EXTC) - m8260_cpm_extcbrg(KGDB_SMC_INDEX, speed, + m8260_cpm_extcbrg(brg_map[KGDB_SMC_INDEX], speed, CONFIG_KGDB_EXTC_RATE, CONFIG_KGDB_EXTC_PINSEL); #else - m8260_cpm_setbrg(KGDB_SMC_INDEX, speed); + m8260_cpm_setbrg(brg_map[KGDB_SMC_INDEX], speed); #endif /* Make the first buffer the only buffer. -- Hojin

2 1

[U-Boot-Users] [PATCH] MII help text formatting fix
by Cory Tusar 06 Aug '05

06 Aug '05

Attached is a patch fixing a minor glitch in the 'mii help' text formatting. Picky, picky, I know... Patch was generated against current CVS sources. CHANGELOG: * Patch by Cory Tusar, 10 Dec 2004: Fixed 'mii help' text formatting. -Cory -- Cory T. Tusar Embedded Systems Engineer Videon Central, Inc. 2171 Sandy Drive State College, PA 16801 (814) 235-1111 x316 (814) 235-1118 fax "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian W. Kernighan Index: common/cmd_mii.c =================================================================== RCS file: /home/cvs/u-boot/common/cmd_mii.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- common/cmd_mii.c 7 Dec 2004 14:49:03 -0000 1.1.1.1 +++ common/cmd_mii.c 8 Dec 2004 17:42:39 -0000 1.2 @@ -549,7 +549,7 @@ U_BOOT_CMD( mii, 5, 1, do_mii, "mii - MII utility commands\n", - "info <addr> - display MII PHY info\n" + "info <addr> - display MII PHY info\n" "mii read <addr> <reg> - read MII PHY <addr> register <reg>\n" "mii write <addr> <reg> <data> - write MII PHY <addr> register <reg>\n" "mii dump <addr> <reg> - pretty-print <addr> <reg> (0-5 only)\n"

2 1

[U-Boot-Users] [Patch] bugfix:return value of NFS command
by Hiroshi Ito 06 Aug '05

06 Aug '05

Hello, 1.nfs command return code is depend on umount-all, but not state of downloading. 2.When fail to write flash, it doesn't change state to umount example1: ---nfs server--- [mldbox]# ls -l u-boot.bin ---------- 1 root root 204048 Dec 11 02:06 u-boot.bin --- u-boot --- # if nfs 80400000 192.168.3.98:/usr/src/mldbox/u-boot.bin; then echo ok; else echo error; fi Trying i82559#0 Using i82559#0 device File transfer via NFS from server 192.168.3.98; our IP address is 192.168.3.200 Filename '/usr/src/mldbox/u-boot.bin'. Load address: 0x80400000 Loading: * done ok <= Wrong!! example2: [root@tv mldbox]# rm u-boot.bin rm: remove regular file `u-boot.bin'? y [root@tv mldbox]# # if nfs 80400000 192.168.3.98:/usr/src/mldbox/u-boot.bin; then echo ok; else echo error; fi Trying i82559#0 Using i82559#0 device File transfer via NFS from server 192.168.3.98; our IP address is 192.168.3.200 Filename '/usr/src/mldbox/u-boot.bin'. Load address: 0x80400000 Loading: *** ERROR: File lookup fail done ok <= Wrong!! # attached patch fixes these problems. patch is for current CVS. -------- Hiroshi Ito Media Lab. Inc., URL http://www.mlb.co.jp ( Sorry, Japanese only. ) TEL +81-3-5294-7255 FAX +81-3-5294-7256

3 2

[U-Boot-Users] SCSI support for MIB405 board
by Wolfgang Denk 04 Aug '05

04 Aug '05

Dear Denis, can you tell me something about the SCSI support in the current versions of U-Boot? It seems the MIB405 board (maintained by you) has SCSI support enabled, but the whole code in common/cmd_scsi.c seemd to be unused - for example, there is no caller of do_scsi() or do_scsiboot() anywhere in the whole source tree? 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 In general, they do what you want, unless you want consistency. - Larry Wall in the perl man page

2 4

[U-Boot-Users] [Patch] default filename of tftp and nfs
by Hiroshi Ito 04 Aug '05

04 Aug '05

Hello, default filename of tftp and nfs has different value between little endian machine and big one. This patch fixes endian problem. Patch is for current cvs. -------- Hiroshi Ito Media Lab. Inc., URL http://www.mlb.co.jp ( Sorry, Japanese only. ) TEL +81-3-5294-7255 FAX +81-3-5294-7256

2 2

[U-Boot-Users] u-boot 1.1.1 and USB mass storage devices
by Shannon Holland 03 Aug '05

03 Aug '05

Hello, We are using u-boot on a Samsung S3C2410 based board and have USB mostly working using the arm920t USB driver. I say mostly working as some mass storage devices work fine, but most do not. Typically the behavior we see when they don't work is a "usb reset" reports the correct number of devices, a "usb tree" will return the correct device tree but "usb scan" will typically return a lot of CLI:TIMEOUT errors and seemingly never return. Sometimes it is able to find the storage device, but reading from it (it has a FAT16 filesystem) will return similar errors. I'm curious if these are known problems or likely to be something in the way we have (or have not) set up usb? Might anyone have some recommendations as to where to start looking? Thanks for any help! Shannon

5 8

[U-Boot-Users] Loading FPGA from an mkimage created image?
by Steven Scholz 10 Jun '05

10 Jun '05

Hi there, I know that fpga load [device number] [image address] [image size] can be used to init an FPGA. Now I want to compress and wrap the FPGA data with mkimage. Is there a way to pass the address of an Image to "fpga load". Or do I have to umcompress it first using "bootm" or something and then pass the address and size to "fpga load"? Thanks! -- Steven Scholz

2 7

[U-Boot-Users] mkimage for DOS
by Dave Westwood 10 Jun '05

10 Jun '05

long shot really, but does anyone have a working executable mkimage for DOS or a dos window in windows (don't flame me for using windows !!)

2 1

Re: [U-Boot-Users] Support for Samsung 1Giga bit NAND device
by Laurent Mohin 01 Jun '05

01 Jun '05

Andy, U-boot 1.1.0 doesn't provide support for NAND flash with a page size of 2K-byte instead of 512 byte (and you're right, theses devices require special handling). Pantelis Antoniou submitted a patch on 2004-04-30 which seems to manage these new chips, but I don't think it has been added to the latest CVS tree. By the way, Samsung also offer 1 Giga bit devices with a 512 byte page size (K9K1G08UOM - Manufacturer ID : 0xEC, Chip ID: 0x79). Hope this helps, Laurent Andy Hawkins <a.hawkins(a)cabletime.com> Sent by: u-boot-users-admin(a)lists.sourceforge.net 14/06/04 13:40 To: u-boot-users(a)lists.sourceforge.net cc: Subject: [U-Boot-Users] Support for Samsung 1Giga bit NAND device Hi, Can anyone tell me if U-Boot has support for the Samsung 1 Giga Bit NAND devices (Manufacturer ID: 0xec, Chip ID: 0xf1)? I understand these devices have an unusually large block size, that needs special handling. Is this correct? Thanks. Andy ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

4 8

RE: [U-Boot-Users] Re: [PATCH] !CFG_MEMTEST_SCRATCH - do not dereference NULL ptr
by VanBaren, Gerald (AGRE) 30 May '05

30 May '05

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf > Of Ladislav Michl > Sent: Thursday, November 25, 2004 6:22 AM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] Re: [PATCH] !CFG_MEMTEST_SCRATCH - do > not dereference NULL ptr > > On Mon, Nov 22, 2004 at 12:07:18PM +0100, Wolfgang Denk wrote: > > There is no explanation what it does or which problem it is > supposed > > to fix. > > When CFG_MEMTEST_SCRATCH is undefined alternate memory test > in do_mem_mtest (with CFG_ALT_MEMTEST defined) dereferences > null pointer. It defines: > vu_long *dummy = NULL; > and later does: > *dummy = ~val; > > > There is also no CHANGELOG entry. > > CHANGELOG > * Patch by Ladislav Michl, 22 November 2004 > - Fix NULL pointer dereference in alternate memory test > (CFG_ALT_MEMTEST) > when if no CFG_MEMTEST_SCRATCH area defined > > Index: common/cmd_mem.c > =================================================================== > RCS file: /cvsroot/u-boot/u-boot/common/cmd_mem.c,v > retrieving revision 1.19 > diff -p -u -r1.19 cmd_mem.c > --- common/cmd_mem.c 10 Oct 2004 23:27:33 -0000 1.19 > +++ common/cmd_mem.c 22 Nov 2004 11:21:43 -0000 > @@ -646,8 +646,9 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int > vu_long num_words; > #if defined(CFG_MEMTEST_SCRATCH) > vu_long *dummy = (vu_long*)CFG_MEMTEST_SCRATCH; > +#define write_dummy(val) do { *dummy = ~val; } while (0) > #else > - vu_long *dummy = NULL; > +#define write_dummy(val) do { } while (0) > #endif > int j; > int iterations = 1; > @@ -723,7 +724,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int > val = bitpattern[j]; > for(; val != 0; val <<= 1) { > *addr = val; > - *dummy = ~val; /* clear the test data > off of the bus */ > + write_dummy(~val); /* clear the test > data off of the bus */ > readback = *addr; > if(readback != val) { > printf ("FAILURE (data line): " > @@ -731,11 +732,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int > val, readback); > } > *addr = ~val; > - *dummy = val; > + write_dummy(val); > readback = *addr; > if(readback != ~val) { > printf ("FAILURE (data line): " > - "Is %08lx, should be %08lx\n", > + "is %08lx, should be %08lx\n", > readback, ~val); > } > } Ladislav: You are fixing the problem in the wrong way. You should point "dummy" at a location in RAM that is writable rather than "fixing" the code by suppressing the dummy write. Being pedantic here, dummy isn't NULL, it is a pointer to the RAM location 0x00000000 (which just happens to be the same as NULL ;-). Strictly speaking, the assignment should have been written "vu_long *dummy = 0x00000000;". The problem here is that the code assumes 0x00000000 is writable and apparently this isn't the case on your board. It obviously is a good assumption on the other boards supported by u-boot (at least the ones that use this POST code :-). The proper fix is, for your board, change the assignment "vu_long *dummy = 0x00000000;" to point to writable RAM on your board. Suppressing the write to 0x00000000 will make the memory test ineffective on all boards (bad, really bad). The purpose of the "*dummy = ~val" statement is to discharge the data bus lines. The problem this is addressing is when the previous line "*addr = val" is executed, the data bus has on it the value "val". Since there is inherent capacitance on the bus lines, that value will persist (float) on the bus for a finite time, longer than it takes for a processor to do the "readback = *addr". The result is that, if the memory doesn't respond and the bus drivers remain tristated, you will think the memory responded properly because you read the residual charge on the bus. The write of "~val" to dummy is a throw-away operation whose purpose is to put something other than "val" on the bus so that a read of the target location won't give a false positive if the memory isn't working properly. Where "dummy" points is immaterial as long as "~val" gets out on the data bus. Normally you would point it in your RAM space, but you actually could point it anywhere that causes a valid write cycle on the data bus. Regards, gvb ****************************************** 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] A question on ELDK PATH Setting
by Sam Song 03 May '05

03 May '05

Wolfgang Denk <wd(a)denx.de> wrote: > If you have a look at the contrents of the ELDK's > bin directories you will see that you will be missing the > ${CROSS_COMPILE}rpm tool if you omit Well, no wander I haven't met any trouble on compiling kernel. Actually, I have no idea on ${CROSS_COMPILE} rpm. > But actually this is completely off topic here... Ummm, if so, where could we discuss something about DULG? I noticed there is one charming words below the DULG linkage, says "You are invited to contribute". The doc benfits me a lot. And has been updating frequently. Really wanna to see it better:) Btw, I reported one typo for you about MTD part on OLD linuxppc maillist. But you still haven't corrected it yet. I don't know why:) http://www.denx.de/twiki/bin/view/DULG/FlashFilesystemsMTD "xd" should be replaced by "xxd". At least for RED HAT 7.3/9.0. Thanks for your reply, Sam _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

3 2

[U-Boot-Users] wlan driver
by Dan Malek 01 May '05

01 May '05

Hello everyone. Has anyone worked on a 802.11 wireless driver for u-boot? I'm faced with a board that has mini-PCI, adapters aren't working for standard cards, and it looks like the only solution may be a 3.3V wireless LAN card. There are some "standard" 3.3V mini-PCI cards for laptops, but I don't know how the connectors attach or if the magnetics are on the cards. If anyone knows, that would be useful information too. Thanks for any suggestions (I suspect Wolfgang will respond with a URL to an archive I couldn't find) :-) -- Dan

2 1

[U-Boot-Users] Checksum test for UDP packets
by Reinhard Arlt 30 Apr '05

30 Apr '05

Hello, here is a patch, that verify the checksum of incomming UDP packets. Tested on PowerPC only. To enable this patch, define CONFIG_UDP_CHECKSUM. Reinhard Changelog: * patch by Reinhard Arlt, 2005-04-30 Verfy checksum of incomming UDP packets. Drops the packet and print a message for a packet with a wrong checksum. --- u-boot-1.1.2/net/net.c 2004-10-12 00:51:14.000000000 +0200 +++ u-boot_20050226/net/net.c 2005-04-30 23:18:48.000000000 +0200 @@ -1292,6 +1292,7 @@ NetReceive(volatile uchar * inpkt, int l #endif return; } + break; case PROT_RARP: #ifdef ET_DEBUG @@ -1393,6 +1394,45 @@ NetReceive(volatile uchar * inpkt, int l return; } +#ifdef CONFIG_UDP_CHECKSUM + if (ip->udp_xsum != 0) { + ulong xsum; + ushort *sumptr; + ushort sumlen; + + xsum = ip->ip_p; + xsum += (ntohs(ip->udp_len)); + xsum += (ntohl(ip->ip_src) >> 16) & 0x0000ffff; + xsum += (ntohl(ip->ip_src) >> 0) & 0x0000ffff; + xsum += (ntohl(ip->ip_dst) >> 16) & 0x0000ffff; + xsum += (ntohl(ip->ip_dst) >> 0) & 0x0000ffff; + + sumlen = ntohs(ip->udp_len); + sumptr = (ushort *) &(ip->udp_src); + + while (sumlen > 1) { + ushort sumdata; + + sumdata = *sumptr++; + xsum += ntohs(sumdata); + sumlen -= 2; + } + if (sumlen > 0) { + ushort sumdata; + + sumdata = *(unsigned char *) sumptr; + sumdata = (sumdata << 8) & 0xff00; + xsum += sumdata; + } + while ((xsum >> 16) != 0) { + xsum = (xsum & 0x0000ffff) + ((xsum >> 16) & 0x0000ffff); + } + if ((xsum != 0x00000000) && (xsum != 0x0000ffff)){ + printf(" UDP wrong checksum %08x %08x\n", xsum, ntohs(ip->udp_xsum)); + return; + } + } +#endif #ifdef CONFIG_NETCONSOLE nc_input_packet((uchar *)ip +IP_HDR_SIZE, ntohs(ip->udp_dst),

1 0

[U-Boot-Users] Re: Write buffer programming for AMD flash chips
by Alex BASTOS 29 Apr '05

29 Apr '05

Hi Thomas, > I had a look at your patch and I believe that it does almost the same than > mine. From a point of readability and extendability I would prefer it, > whereas my patch would save some memory. So on, IMHO memory saving may be preferable in this case. However, maybe someone else in the list (Wolfgang?) has anything to say. If this is the way we decide to go, I can apply your patch and make changes for 8 bit support. > A missing part in your patch is checking whether data to be written are > aligned with the flash chips write buffer. This is done with the following > hunk for the write_buff function: > > buffered_size = (info->portwidth / info->chipwidth); > buffered_size *= info->buffer_size; > while (cnt >= info->portwidth) { > - i = buffered_size > cnt ? cnt : buffered_size; > + /* write buffer until next buffered_size aligned boundary */ > + i = buffered_size - (wp % buffered_size); > + if (i>cnt) > + i = cnt; > if ((rc = flash_write_cfibuffer (info, wp, src, i)) != ERR_OK) > return rc; > i -= (i % info->portwidth); > > In our case, the lack of this code lead to errors when writing the > environment to flash. The reason is that environment writing is done in 3 > steps and this results in not buffer-aligned write cycles. The code above > calculates the correct buffer size (i) depending on the first address (wp) to > be written OK. I will change this. Best Regards, Alex

1 0

Re: [U-Boot-Users] PPC: How to access RAM location 0x0 (unmapped) ?
by KokHow Teh 28 Apr '05

28 Apr '05

The reason of the crash was because I put get_ram_size() before the sdram controller was initialized. I don't know how it works in sbc8240 but this is what I get in tqm8260: /* We must be able to test a location outsize the maximum legal size * to find out THAT we are outside; but this address still has to be * mapped by the controller. That means, that the initial mapping has * to be (at least) twice as large as the maximum expected size. */ Now it works. Thanks. Wolfgang Denk <wd(a)denx.de>@denx.de on 04/28/2005 01:55:16 PM Sent by: wd(a)denx.de To: "KokHow Teh" <KokHow.Teh(a)marconi.com> cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] PPC: How to access RAM location 0x0 (unmapped) ? In message <OF5DF9F216.6A5D85BA-ON48256FF1.0012D4AD(a)uk.marconicomms.com> you wrote: > > board/sbc8240.c initdram() calls get_ram_size() with CFG_SDRAM_BASE > = 0. Put it into board/mpc8260ads/mpc8260ads.c. and it crashes.... Then either don't do that, or fix it. There are many, many PPC boards using get_ram_size() with CFG_SDRAM_BASE==0 which just work fine. There is no reason why this should be any problem. 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 That was the thing about deserts. They had their own gravity. They sucked you into the centre. - Terry Pratchett, _Small Gods_

2 1

[U-Boot-Users] Write buffer programming for AMD flash chips
by Thomas Schäfer 28 Apr '05

28 Apr '05

Hi Alex, I had a look at your patch and I believe that it does almost the same than mine. From a point of readability and extendability I would prefer it, whereas my patch would save some memory. A missing part in your patch is checking whether data to be written are aligned with the flash chips write buffer. This is done with the following hunk for the write_buff function: buffered_size = (info->portwidth / info->chipwidth); buffered_size *= info->buffer_size; while (cnt >= info->portwidth) { - i = buffered_size > cnt ? cnt : buffered_size; + /* write buffer until next buffered_size aligned boundary */ + i = buffered_size - (wp % buffered_size); + if (i>cnt) + i = cnt; if ((rc = flash_write_cfibuffer (info, wp, src, i)) != ERR_OK) return rc; i -= (i % info->portwidth); In our case, the lack of this code lead to errors when writing the environment to flash. The reason is that environment writing is done in 3 steps and this results in not buffer-aligned write cycles. The code above calculates the correct buffer size (i) depending on the first address (wp) to be written Best regards, Thomas Schäfer E-mail: thomas.schaefer(a)kontron.com

1 0

[U-Boot-Users] SPI in mpc8260
by hui zhao 28 Apr '05

28 Apr '05

Can some tell me how to write data to spi tx-buffer.

1 0

[U-Boot-Users] Query re patch acceptability
by Peter Pearse 28 Apr '05

28 Apr '05

Wolfgang Was the patch "CFI flash for ARM supplied & supported development boards" submitted 2005-04-12 05:19 acceptable? (I am under pressure to have it accepted into CVS......) Peter ------------------------ Peter.Pearse(a)arm.com -------------------------

3 3

Re: [U-Boot-Users] PPC: How to access RAM location 0x0 (unmapped) ?
by KokHow Teh 28 Apr '05

28 Apr '05

Hi; board/sbc8240.c initdram() calls get_ram_size() with CFG_SDRAM_BASE = 0. Put it into board/mpc8260ads/mpc8260ads.c. and it crashes.... Regards. "KokHow Teh" <KokHow.Teh(a)marconi.com>@lists.sourceforge.net on 04/28/2005 10:42:07 AM Sent by: u-boot-users-admin(a)lists.sourceforge.net To: u-boot-users(a)lists.sourceforge.net cc: Subject: [U-Boot-Users] PPC: How to access RAM location 0x0 (unmapped) ? Hi; In MIPS I can access RAM localtion 0x0 unmapped with 0x8000_0000 (cached) and 0xA000_0000(uncached). I guess this is not possible in PPC? I ask because I would like to call get_ram_size() during the bootup to determine the size of my SDRAM before it is mapped. Anyway, I need to know the size of SDRAM in order to map it. Thanks & Regards, TEH ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

2 1

[U-Boot-Users] PPC: How to access RAM location 0x0 (unmapped) ?
by KokHow Teh 28 Apr '05

28 Apr '05

Hi; In MIPS I can access RAM localtion 0x0 unmapped with 0x8000_0000 (cached) and 0xA000_0000(uncached). I guess this is not possible in PPC? I ask because I would like to call get_ram_size() during the bootup to determine the size of my SDRAM before it is mapped. Anyway, I need to know the size of SDRAM in order to map it. Thanks & Regards, TEH

1 0

[U-Boot-Users] resetting compact flash card in u-boot
by Tom Otermans 27 Apr '05

27 Apr '05

Hello List, I have a question about resetting compact flash cards. We are currently working on an pxa-255 system. From u-boot (1.0.0) a kernel image is loaded (on a fat partition) and booted. The problem starts after reading this image. The linux kernel (2.4.26) is started and tries to couple the root filesystem from the cf (parition 2, ext2). With industrial grade cf cards from sandisk, this process works fine, but non industrial grade cards can't read the data from the cf. If I do an ide reset, and load the image from the device via the fatload command, _remove_ the cf and than bootm the image, the cf card can be read in the kernel. So reseting the cf card somehow is what I have to do. Thus I tried to reset it by lowering the reset pin of the cf (lower pin 41 in true ide mode). But the problem still appears. Does anyone had these same problems with non industrial grade cf cards? Or any idea of how to reset the card in the bootloader to a same state as from inserting the card? Thanks in advance, Tom --

2 1

[U-Boot-Users] Re: Download U-Boot in RAM on Memec Board
by Pierre Kestener 27 Apr '05

27 Apr '05

>Subject: [U-Boot-Users] Download U-Boot in RAM on Memec Board > >Hei at all > >I have comiled u-boot and want to download the u-boot in RAM on Memec Evaluation Board. >The board has 64K RAM and address is 0x00000000 to 0x03FFFFFF. > >When i use the commands described in examples e.g. >xmd> ppcconnect >xmd> dow uboot.elf >xmd> run >the xmd begins to download at address 0x04000000 !!! and at the console I get information >on which addresses the sectors were placed. > > > You have to change TEXT_BASE (see "board/xilinx/ml300/config.mk" file, default is 0x04000000) to some address inside RAM (for example 0x100000) and change accordingly CFG_MONITOR_BASE in file "include/configs/ml300.h" (see README at top of u-boot sources). It should be sufficient to run u-boot this way on a Memec board via xmd. Pierre Kestener.

1 0

Re: [U-Boot-Users] what is the purpose of "serial_tstc()"?
by Frank 27 Apr '05

27 Apr '05

It returns a true if there is a char in the serial input buffer. I usually use it when I'm in an inifinit loop and want to break out if some hits the keyboard. Similar to "?key" in Forth.:-) --- wnlee1109(a)gmail.com wrote: > > Hello, u-boot community, > > When I wrote the hardware dependent parts of serial functions, > > I cannot understand what should I write for "serial_tstc()". > > What is the purpose of "serial_tstc()"? > Does anyone know? > > Thanks > Wayne > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Tell us your software > development plans! > Take this survey and enter to win a one-year sub to > SourceForge.net > Plus IDC's 2005 look-ahead and a copy of this survey > Click here to start! > http://www.idcswdc.com/cgi-bin/survey?id=105hix > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

[U-Boot-Users] patch for memec board
by andreas_schmidt＠ifm-electronic.com 27 Apr '05

27 Apr '05

Hallo at All Have perhaps somebody a u-boot patch for memec evaluation board? Since one week I try to implement it itself but i don't get it. It will very helpfull when at less I get something on UART Interface on memec board. When there are possibility I would very gratefully! thanks best regards, Andreas Schmidt

1 0

[U-Boot-Users] how to add CR to printf message automatically?
by wnlee1109＠gmail.com 27 Apr '05

27 Apr '05

Dear u-boot community, I am now porting u-boot to my own evaluation board. The UART functions now. However, the printed messages on hyper-terminal are lacks of "CR" character. Most messages in u-boot is only ends with "\n". How to let printf() automatically add "\r" at the end of messages? Thanks. Wayne

2 1

[U-Boot-Users] what is the purpose of "serial_tstc()"?
by wnlee1109＠gmail.com 27 Apr '05

27 Apr '05

Hello, u-boot community, When I wrote the hardware dependent parts of serial functions, I cannot understand what should I write for "serial_tstc()". What is the purpose of "serial_tstc()"? Does anyone know? Thanks Wayne

1 0

[U-Boot-Users] Baudrate of UART in U-Boot
by andreas_schmidt＠ifm-electronic.com 27 Apr '05

27 Apr '05

Hallo at all I'm jaust porting the u-boot at memec Board. After I adjust some thing(from ML300 Board), then compile u-boot and download it tn SDRAM. Now my Problem: At Hyperterminal a can only see that the blang blink not regulary and so a signal is on RS232. Than I measure the Baudrate with oszi and compare it with standalone application from XILINX EDK. The Signal from U-Boot UART differs on factor 1000 to signal from standalone application on RS232. Then i treid to change the Baudrate in U-Boot. I modifay the CFG_Baudrate ml300.h then i tried modifay it in xparameters.h but nothing have happens. Can me somebody say how I modifay the Baudrate in u-boot? thanks best regards, Andreas Schmidt

1 0

[U-Boot-Users] boot uncompressed uImage
by 朱成 27 Apr '05

27 Apr '05

hello,all i builded compressed image using montavista's tools : 1. /bin/sh /usr/src/linux-2.4.20_mvlcee31/scripts/mkuboot.sh -A arm -O linux -T kernel \ -C none -a 0x10008000 -e 0x10008000 \ -n 'Linux-2.4.20_mvlcee31-omap730_gsm_gprs' \ -d /usr/src/linux-2.4.20_mvlcee31/arch/arm/boot/zImage uImage 2. tftp 0x10000000 uImage (i used u-boot-1.1.2, 0x10000000 is physical address) 3. bootm and kernel could boot successfully. but i want to install uncompressed image, so i do: 1. /bin/sh /usr/src/linux-2.4.20_mvlcee31/scripts/mkuboot.sh -A arm -O linux -T kernel \ -C none -a 0x10008000 -e 0x10008000 \ -n 'Linux-2.4.20_mvlcee31-omap730_gsm_gprs' \ -d /usr/src/linux-2.4.20_mvlcee31/vmlinux uImage 2. tftp 0x10000000 uImage 3. bootm but kernel booting failed, and u-boot rebooted! shall i change 0x10008000 to sth. and do something else? thanks!

3 3

RE: [U-Boot-Users] U-boot 1.1.2 on SMDK2410
by Tehn-Yit Chin 27 Apr '05

27 Apr '05

> Thisis only to be expected. Please install U-Boot in > flash as required, and then simply reset the board to start it. > Actually, the other reason why I though that u-boot for the SMDK2410 may execute out of RAM is that the resulting elf file is linked to reside at address 0x33F80000. The SDRAM on the SMDK2410 lives at address 0x30000000, so I made the logical assumption that u-boot was to be executed out of RAM. Below is an objdump of the elf file. If u-boot is to be executed from FLASH, would it be fair to think that <_start> should be at 0x0 (where boot FLASH is living). [tehn-yit.chin@riesling u-boot-1.1.2]$ arm-linux-objdump -D u-boot | more u-boot: file format elf32-littlearm Disassembly of section .text: 33f80000 <_start>: 33f80000: ea000012 b 33f80050 <reset> 33f80004: e59ff014 ldr pc, [pc, #20] ; 33f80020 <_undefined_instruction> 33f80008: e59ff014 ldr pc, [pc, #20] ; 33f80024 <_software_interrupt> 33f8000c: e59ff014 ldr pc, [pc, #20] ; 33f80028 <_prefetch_abort> 33f80010: e59ff014 ldr pc, [pc, #20] ; 33f8002c <_data_abort> 33f80014: e59ff014 ldr pc, [pc, #20] ; 33f80030 <_not_used> 33f80018: e59ff014 ldr pc, [pc, #20] ; 33f80034 <_irq> 33f8001c: e59ff014 ldr pc, [pc, #20] ; 33f80038 <_fiq> 33f80020 <_undefined_instruction>: 33f80020: 33f80140 mvnccs r0, #16 ; 0x10 33f80024 <_software_interrupt>: 33f80024: 33f801a0 mvnccs r0, #40 ; 0x28 33f80028 <_prefetch_abort>: 33f80028: 33f80200 mvnccs r0, #0 ; 0x0 33f8002c <_data_abort>: 33f8002c: 33f80260 mvnccs r0, #6 ; 0x6 33f80030 <_not_used>: 33f80030: 33f802c0 mvnccs r0, #12 ; 0xc 33f80034 <_irq>: 33f80034: 33f80320 mvnccs r0, #-2147483648 ; 0x80000000 33f80038 <_fiq>: 33f80038: 33f80380 mvnccs r0, #2 ; 0x2 33f8003c: deadbeef cdple 14, 10, cr11, cr13, cr15, {7} 33f80040 <_TEXT_BASE>: 33f80040: 33f80000 mvnccs r0, #0 ; 0x0 33f80044 <_armboot_start>: 33f80044: 33f80000 mvnccs r0, #0 ; 0x0 33f80048 <_bss_start>: 33f80048: 33f965a4 mvnccs r6, #687865856 ; 0x29000000 33f8004c <_bss_end>: ------------ cut ------------------------------------------------------ If u-boot is to be burned in FLASH, the first branch instruction will cause it jump into uninitialise code in the SDRAM. Should I change the linker configuration to link it to execute at 0x0? Many thanks, Tehn Yit Chin Software Engineer, Grey Innovation Pty. Ltd.

2 1

RE: [U-Boot-Users] U-boot 1.1.2 on SMDK2410
by Tehn-Yit Chin 27 Apr '05

27 Apr '05

Reading through the source code, it indicated that it may possibly execute out of RAM at address 0x33F80000 out of the box. However, I was mistaken. Thanks for your advice. Tehn Yit Chin Software Engineer, Grey Innovation Pty. Ltd. -----Original Message----- From: wd(a)denx.de [mailto:wd@denx.de] Sent: Tuesday, 26 April 2005 10:45 PM To: Tehn-Yit Chin Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] U-boot 1.1.2 on SMDK2410 In message <9AEDBAA573BBD346BCF9637D80097D910FEE41(a)greysvr02.GreyInnovation.com> you wrote: > > We attempting to bring u-boot 1.1.2 up on a SMDK2410 board and are ... > Using a ARM RealView ICE, I downloaded the resulting u-boot.bin to > address 0x33F80000. Set the PC at 0x33F8000, and start the code What makes you think this should work? > execution. I was hoping that the serial port would come alive but > nothing came out. No signs of life was showing from the board. Thisis only to be expected. Please install U-Boot in flash as required, and then simply reset the board to start it. Best regards, Wolfgang Denk -- "The greatest warriors are the ones who fight for peace." - Holly Near

1 0

[U-Boot-Users] struct NS16550 {...} __attribute__ ((packed)) at ns16550.h
by Woojung.Huh＠smsc.com 26 Apr '05

26 Apr '05

Hi All, I'm newbie to u-boot. We are using u-boot for proprietary ARM board with NS16550 compatible serial controller. It is configured as 4bytes access to serial controller, so set CFG_NS16550_REG_SIZE to 4. But, because of "__attribute__ ((packed))" of struct NS16550, all register accesses to NS16550 are generated to byte access (LDRB, STRB in ARM). I think it should NOT have __attribute__ ((packed)) if NS16550 is configured as 4bytes access. Am I missed something? Thanks, Woojung

6 12

RE: [U-Boot-Users] U-boot Port issue on MPC8280 board
by Muhammad Sarwar 26 Apr '05

26 Apr '05

As Wolf mentioned, this is the expected bahvior. U-boot can only initiate network requests. You can only ping/tftp etc FROM a target running U-boot. However U-boot is single threaded and does not run a TCP/IP stack to respond to any network requests (broadcast or unicast). Hope it helps. Muhammad Sarwar Mangrove Systems Inc -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net on behalf of Srivatsan Sent: Mon 4/25/2005 8:40 AM To: wd(a)denx.de Cc: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] U-boot Port issue on MPC8280 board Hi all, The porting of U-boot 1.1.2 onto the Rattler MPC8280 board is done but for the following problem: When I try to ping from Target (Rattler MPC8280), it says the host (PC running TFTP server) is alive. But when the target (MPc8280) is pinged from host, then it says "request timed out". I am using the ETHERNET_ON_FCC. Hope somebody can help me out of this problem. With Regards, C.R.Srivatsan ***************************NOTE*********************************************** Deccanet Designs Ltd is now Flextronics Design Ltd, India ****************************************************************************** *************************DISCLAIMER******************************************* This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege of Flextronics Design Ltd. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, altering or disclosing the contents of this message. ****************************************************************************** ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

[U-Boot-Users] Redundant environment and saveenv
by Ara Avanesyan 26 Apr '05

26 Apr '05

hi all, I have enabled a redundant environment and my two environments reside in two different sectors in flash. Everything works perfectly, except seems there is a problem in saveenv command: in file common/env_flash.c line 205: if ((rc = flash_write(env_ptr->data, (ulong)&(flash_addr_new->data), sizeof(env_ptr->data))) || (rc = flash_write((char *)&(env_ptr-crc), (ulong)&(flash_addr_new->crc), sizeof(env_ptr->crc))) || (rc = flash_write(&flag, (ulong)&(flash_addr->flags), sizeof(flash_addr->flags))) || (rc = flash_write(&new_flag, (ulong)&(flash_addr_new->flags), sizeof(flash_addr_new->flags)))) it writes a char to (ulong)&(flash_addr->flags), but this sector was never erased. am i missing something here? flash is STM M29W040, connected with 8 bit bus. Thanks, Ara

2 1

[U-Boot-Users] U-boot 1.1.2 on SMDK2410
by Tehn-Yit Chin 26 Apr '05

26 Apr '05

Hi, We attempting to bring u-boot 1.1.2 up on a SMDK2410 board and are having a few problems. I have search through the mailing list and googled the net for some information but was not able to find. I build u-boot 1.1.2 as the following make smdk2410_config make I am using gcc 3.3.2 and the build went through without any errors. Using a ARM RealView ICE, I downloaded the resulting u-boot.bin to address 0x33F80000. Set the PC at 0x33F8000, and start the code execution. I was hoping that the serial port would come alive but nothing came out. No signs of life was showing from the board. I have configured smdk2410 to non-NAND boot. All the other configuration are left as default. Any advice on which areas to look at or any suggestions would be greatly appreciated. Many thanks, Tehn Yit Chin Software Engineer, Grey Innovation Pty. Ltd.

2 1

[U-Boot-Users] RE: Write buffer programming for AMD flash chips
by Bastos Fernandez Alexandre 26 Apr '05

26 Apr '05

Thomas, What about the patch I have submitted some days ago? I proposed there some changes for the same issue? Have you considered/tested it against your Flash? Best regards, Alex Bastos > -----Original Message----- > Date: Tue, 26 Apr 2005 09:21:11 +0200 > From: =?iso-8859-1?Q?Thomas_Sch=E4fer?= <thomas.schaefer(a)kontron.com> > To: <wd(a)denx.de>, > <yuli(a)arabellasw.com>, > <Brad.Kemp(a)Seranoa.com> > Cc: <u-boot-users(a)lists.sourceforge.net> > Subject: [U-Boot-Users] Write buffer programming for AMD flash chips > > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01C54A30.86E79890 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Sorry, wrong patch file, this is the right one... > > Best regards, > > Thomas Sch=E4fer > >

1 0