September 2005 - U-Boot

[U-Boot-Users] [PATCH] cramfs support for m68k
by Zachary Landau 25 Sep '05

25 Sep '05

Hello, The attached patch provides a couple simple changes necessary to get CRAMFS support working on the M68K. -- Zachary P. Landau <kapheine(a)gmail.com>

2 1

[U-Boot-Users] [PATCH]: Fix EP8260 H2 flash timeouts
by Jeff Angielski 25 Sep '05

25 Sep '05

Very small patch to ep8260.h to fix the flash timeouts and to improve the clock accuracy for faster UARTs by reducing the BRG divisor in the SCCR. CHANGELOG: * Patch by Jeff Angielski 21 Feb 2005 Fix flash write/erase timeouts. Improve clock resolution for faster UARTs. Jeff Angielski

2 1

[U-Boot-Users] [patch] MIPS: AMD Alchemy au1x00 ethernet initialization in cpu/mips/au1x00_eth.c
by Joseph Chiu 25 Sep '05

25 Sep '05

Hi, On u-boot bootloader 1.1.2 on AMD Alchemy Au1x00: The au1x00_mac.c assumes that ethernet transmit always starts with transmit buffer 0. This is not necessarily true (in the event of a warm reboot). This little patch fixes that and prevents (reduces?) transmit timeouts that you might see when you're repeatedly warm-rebooting your board during development. Cheers, Joseph Chiu www.omnilux.net LC_ALL=C TZ=UTC0 diff -Naur u-boot-1.1.2.orig/cpu/mips/au1x00_eth.c u-boot-1.1.2.new/cpu/mips/au1x00_eth.c --- u-boot-1.1.2.orig/cpu/mips/au1x00_eth.c Fri Jan 2 15:01:32 2004 +++ u-boot-1.1.2.new/cpu/mips/au1x00_eth.c Wed Feb 16 02:10:27 2005 @@ -167,9 +167,6 @@ (volatile mac_fifo_t*)(MAC0_RX_DMA_ADDR+MAC_RX_BUFF0_STATUS); int i; - next_tx = 0; - next_rx = 0; - /* We have to enable clocks before releasing reset */ *macen = MAC_EN_CLOCK_ENABLE; udelay(10); @@ -186,6 +183,9 @@ fifo_rx[i].addr = (virt_to_phys(NetRxPackets[i]))|RX_DMA_ENABLE; } + next_tx = (fifo_tx[0].addr & 0x0c )>>2; + next_rx = (fifo_rx[0].addr & 0x0c )>>2; + /* Put mac addr in little endian */ #define ea eth_get_dev()->enetaddr *mac_addr_high = (ea[5] << 8) | (ea[4] ) ;

3 2

[U-Boot-Users] [patch] au1x00_serial.c fix baud rate computation
by Andrew Dyer 25 Sep '05

25 Sep '05

CHANGELOG: * Patch by Andrew Dyer, 15 February 2005: fix au1x00_serial to remove hardcoded cpu clock divisor and use register instead. change baud rate calculation to round up instead of truncate in cases where fractional part would have been > 0.5 -- Hardware, n.: The parts of a computer system that can be kicked.

2 1

[U-Boot-Users] [PATCH] Spartan3 family support
by Kurt Stremerch 25 Sep '05

25 Sep '05

Hi all. This small patch, against current cvs, adds Xilinx Spartan3 support. Only the bitstream size differs from the Spartan2 family, the configuration method stays the same. Regards Kurt CHANGELOG: * Patch by Kurt Stremerch, 14 February 2005: Add Xilinx Spartan3 family fpga support

4 5

[U-Boot-Users] [PATCH] Use info->reset_cmd instead of FLASH_CMD_RESET
by Zachary Landau 25 Sep '05

25 Sep '05

Hello, This patch makes cfi_flash.c use info->cmd_reset. It was being set by flash_get_size() but not being used, which kept the Flash on my board from properly being reset. It looks like there are a lot of switch cases for different flash types that could probably probably be removed by setting up some function pointers, but that is a project for another time. -- Zachary P. Landau <kapheine(a)gmail.com>

2 1

[U-Boot-Users] [Patch] MPC8272ADS PCI bridge support
by Vitaly Bordug 25 Sep '05

25 Sep '05

Hi, Attached a patch which adds support of the MPC8272ADS PCI bridge. This stuff is based on mpc8266ads, and has been tested with a Freescale MPC8272ADS board. Also attached a patch to README file which describes CFG_PCI_INT config entry (used in the 8266 but not documented yet). Patch made against CVS checkout of Feb 9 2005 CHANGELOG: * Patch by Vitaly Bordug, Feb 9 2005 Added support for PCI bridge on MPC8272ADS -- Sincerely, Vitaly

2 1

[U-Boot-Users] [Patch] ARM Integrator/AP multicore patch
by jean-paul.saman＠philips.com 25 Sep '05

25 Sep '05

The patch is created against the multicore patch from Peter Pearse 02-02-2005 CHANGELOG: * Patch by Jean-Paul Saman, 8 Feb 2005 - Patch based on multicore patch from Peter Pearse 02-02-2005 - multicore CM9XX support for ARM Integrator AP defining CONFIG_CM_INIT and CONFIG_CM_REMAP allows to booting u-boot directly from flash Kind greetings, Jean-Paul Saman Philips Semiconductors CTO/RTG Philips HighTech Campus, building WDB 3.29 Professor van den Holstlaan 4 5655 AA Eindhoven tel: +31 (0)40 27 45131

2 1

[U-Boot-Users] [patch] fix lib_generic version of strswab()
by Andrew Dyer 25 Sep '05

25 Sep '05

This patch changes the behavior of strswab() to end the byte swapping when either of the two candidate bytes is null. The old behavior was to only abort when the second byte was null. It looks like this is only used for little endian machines running with CONFIG_IDE. I noticed this because the ide serial number was not printing out - the reason was strswab() was running past the end of the previous string in memory and swapping a null into the first byte of my serial number string. -- Hardware, n.: The parts of a computer system that can be kicked.

2 1

[U-Boot-Users] Patch: Typos in include/ppc440.h
by Andrew E Mileski 25 Sep '05

25 Sep '05

This is in CVS as well as u-boot-1.1.2.tar.bz2 and as far back as at least u-boot-0.2.0.tar.bz2 File: include/ppc440.h Line:235 Context: #define pbear 0x20 /* periph bus error addr reg */ #define pbesr 0x21 /* periph bus error status reg */ #define xbcfg 0x23 /* external bus configuration reg */ #define xbcid 0x23 /* external bus core id reg */ ^^^^ According to the 440GX user manual (mine's dated Nov 21, 2003) table 4-13 on page 186, EBC0_CID the "EBCO Peripheral Core ID Register" is located at offset 0x24. This register is not currently referenced by any code in the u-boot-1.1.2.tar.bz2 release, which explains why it has survied so long. Also note that the header comment for this section has a typo, which is also corrected in the attached patch. -- Andrew E. Mileski diff -urN include/ppc440.h.orig include/ppc440.h --- include/ppc440.h.orig 2005-02-04 15:55:53.000000000 -0500 +++ include/ppc440.h 2005-02-04 16:13:20.000000000 -0500 @@ -207,7 +207,7 @@ #define mem_eccesr 0x0098 /* ECC error status */ /*----------------------------------------------------------------------------- - | Extrnal Bus Controller + | External Bus Controller +----------------------------------------------------------------------------*/ #define EBC_DCR_BASE 0x12 #define ebccfga (EBC_DCR_BASE+0x0) /* External bus controller addr reg */ @@ -232,7 +232,7 @@ #define pbear 0x20 /* periph bus error addr reg */ #define pbesr 0x21 /* periph bus error status reg */ #define xbcfg 0x23 /* external bus configuration reg */ -#define xbcid 0x23 /* external bus core id reg */ +#define xbcid 0x24 /* external bus core id reg */ /*----------------------------------------------------------------------------- | Internal SRAM

2 1

RE: [U-Boot-Users] [Patch]IntegratorAP & CP multi core module support
by Peter Pearse 25 Sep '05

25 Sep '05

Shawn Jin wrote: > This target does't follow the format integrator<type>_CM<id>_config. > It's annoying if there are too many underscores in target names. It's > good to follow uboot convention of target names, i.e., Shawn Just trying to keep to the official ARM ids, until I was defeated by gnumake's distaste for '-'. As long as each CM is unique.... Altho I dislike having to remember several (slighly different) names for the same thing - long live Occam's razor. Regards Peter

2 1

[U-Boot-Users] [patch] tools/bmp_logo.c using incorrect offset to pixel data
by Andrew Dyer 25 Sep '05

25 Sep '05

The attached patch makes bmp_logo.c use the header information about the start of pixel data in the bmp file instead of trying to find the start itself. If someone wants a test case bmp file that will produce incorrect output with the current code e-mail me and I can send it along. The bug was seen with the tool compiled/running under redhat 7.3 on x86 arch. The visual indication was that the bitmap was shifted to the right with a section of garbage displayed in the lower left corner. The source bmp displays fine with Win2000. I would suggest it's worth noting in the somewhere in docs that include/bmp_logo.h is overwritten by the default build environment (with the Denx logo :-( ). I added a line like this to my board config.mk file to override this behavior. #logo bitmap LOGO_BMP = ../board/eldorado/rht_small_logo.bmp -- Hardware, n.: The parts of a computer system that can be kicked.

2 1

Re: [U-Boot-Users] [Patch]IntegratorAP & CP multi core module support
by Wolfgang Denk 25 Sep '05

25 Sep '05

In message <89A528FE6DB0FA44877BB2F05B84671801C12D3C(a)ZIPPY.Emea.Arm.com> you wrote: > > Please inform me of any defects found. Build for the following boards is broken: integratorap_CM920T: cpu/arm920t/start.o(.text+0xf0):/.automount/castor-vlab/root/home/wd/git/u-boot/work/cpu/arm920t/start.S:265: undefined reference to `lowlevel_init' integratorcp_CM920T: cpu/arm920t/start.o(.text+0xf0):/.automount/castor-vlab/root/home/wd/git/u-boot/work/cpu/arm920t/start.S:265: undefined reference to `lowlevel_init' > > CHANGELOG: > > * Patch by Peter Pearse, 2 Feb 2005 > > - add core module targets > > - add ARM946E cpu support > > - remap memory to 0x00000000 Please provide (incremental) patch. 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 A day without sunshine is like night.

1 1

[U-Boot-Users] [Patch]IntegratorAP & CP multi core module support
by Peter Pearse 25 Sep '05

25 Sep '05

Hi Attached a patch to allow users to specify the core module fitted to their integrator board. Please inform me of any defects found. CHANGELOG: * Patch by Peter Pearse, 2 Feb 2005 - add core module targets - add ARM946E cpu support - remap memory to 0x00000000 Notes ----- a) Provides targets for all supported Core Modules - targets are of the form integrator<type>_CM<id>_config Examples make integratorap_CM946E_S make integratorcp_CM920T_config b) Previous targets integegratorcp, integratorap retained. c) Tested to build with MAKEALL arm (trab & omap2420h fail) integratorcp integratorcp_CM926EJ_S_config integratorcp_CM966E_S_config d) Tested to boot linux & save environment on Integrator/CP CM926EJ-S in all three boot combinations Run ARM Boot Monitor then manually run U-Boot from user flash Run ARM Boot Monitor, auto-switch to U-Boot from user flash Run U-Boot direct from user flash i.e. NO ARM Boot Monitor e) Patched against head at 2 Feb 2005 f) Based on the patches submitted by:: - Shawn Jin (arm946e) - Jean-Paul Saman (remap) Regards Peter ------------------------ Peter.Pearse(a)arm.com -------------------------

2 2

[U-Boot-Users] Re: [patch]:Resubmitting malta support added for U-boot
by Wolfgang Denk 25 Sep '05

25 Sep '05

In message <20050201125802.28721.qmail(a)web54405.mail.yahoo.com> you wrote: > > Here is a cleaner patch incorporating your > suggestions. Ummm... I'm afraid it is not cleaner in any way. Sorry, but there are so many issues with your patch that I have to reject it. You really have to *check* your patch and inspect what it's doing to the source code. Here are a few examples: > diff -p -u -r1.165 Makefile > --- Makefile 9 Jan 2005 23:48:14 -0000 1.165 > +++ Makefile 1 Feb 2005 12:35:26 -0000 > @@ -42,10 +42,16 @@ VENDOR= ... > ifeq (include/config.mk,$(wildcard include/config.mk)) > # load ARCH, BOARD, and CPU configuration > include include/config.mk > -export ARCH CPU BOARD VENDOR SOC > +export ARCH CPU BOARD VENDOR Here you kill SOC support. > @@ -64,6 +70,7 @@ ifeq ($(HOSTARCH),i386) > CROSS_COMPILE = > else > CROSS_COMPILE = i386-linux- > + > endif > endif > ifeq ($(ARCH),mips) > @@ -84,12 +91,14 @@ endif > endif > endif > > +CROSS_COMPILE = sde- > export CROSS_COMPILE > - Arbitrary white space changes. > ######################################################################### > # U-Boot objects....order is important (i.e. start must be first) > > OBJS = cpu/$(CPU)/start.o > + > +OBJS = cpu/$(CPU)/start.o Duplicate entry of "cpu/$(CPU)/start.o" > LIBS += fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a \ > - fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a > + fs/reiserfs/libreiserfs.a Here you kiss ext2 file system support. > all: $(ALL) > > -u-boot.hex: u-boot > - $(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@ > - You remove a build target. > -u-boot: depend $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT) > +u-boot: $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT) You kill the build system by not building the dependencies. > etags: > etags -a `find $(SUBDIRS) include \ > - lib_generic board/$(BOARDDIR) cpu/$(CPU) lib_$(ARCH) \ > - fs/cramfs fs/fat fs/fdos fs/jffs2 \ > - net disk rtc dtt drivers drivers/sk98lin common \ > $ -name CVS -prune $ -o $ -name '*.[ch]' -print $` You killt he etags target. > -incaip_100MHz_config \ > -incaip_133MHz_config \ > -incaip_150MHz_config \ > incaip_config: unconfig You corrupt the INKAIP board. > - rm -f tools/mpc86x_clk tools/ncb > + rm -f tools/mpc86x_clk You leave garbage hanging around. And so on. Sorry, but this is simply not acceptable. Please clean up (and I really mean: clean up) and resubmit. 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 I don't know if it's what you want, but it's what you get. :-) - Larry Wall in <10502(a)jpl-devvax.JPL.NASA.GOV>

1 0

[U-Boot-Users] MIPS build environment
by Dan Malek 25 Sep '05

25 Sep '05

Hello all MIPS u-booters. I'd like to discuss how we can make the MIPS build environment a little bit easier to use. For example, the cpu/mips/config.mk assumes big endian, and although I'll be the first to stand up and say that's the only proper and useful byte ordering, there are people willing to pay me to assist with the alternative :-) I'd like it if we can just find a way to invoke 'mipseb-*' or 'mipsel-*' based upon the configuration chosen and let it go at that. I'd also like us to agree to use up to date tools. Again, the config.mk with the test and hard coded flags depending upon tools seems unnecessary since the newer tools have been around for a while and proven to work. Unless I'm doing something wrong, I also have to use binutils with the 'allow_branch_to_undefined' patch. Comments? Other concerns? Thanks. -- Dan

4 14

[U-Boot-Users] [Patch] MPC5xxx PSC baudrate calculation
by Sebastian Schau 25 Sep '05

25 Sep '05

Hi, attached is a patch, that fixes a bug in MPC5200 PSC Baud rate calculation. The Problem was, that proper rounding was not applied to baudrate calculation in serial_setbrg(). The formula from serial_init() should be used. Best regards Sebastian Schau --- serial.c 9 Feb 2004 20:51:26 -0000 1.1.1.1 +++ serial.c 27 Jan 2005 15:21:26 -0000 @@ -152,14 +152,14 @@ unsigned long baseclk, div; #if defined(CONFIG_MGT5100) - baseclk = CFG_MPC5XXX_CLKIN / 32; + baseclk = (CFG_MPC5XXX_CLKIN + 16) / 32; #elif defined(CONFIG_MPC5200) - baseclk = gd->ipb_clk / 32; + baseclk = (gd->ipb_clk + 16) / 32; #endif /* set up UART divisor */ - div = baseclk / gd->baudrate; - psc->ctur = div >> 8; + div = (baseclk + (gd->baudrate/2)) / gd->baudrate; + psc->ctur = (div >> 8) & 0xff; psc->ctlr = div & 0xff; } #endif /* CONFIG_PSC_CONSOLE */

2 1

[U-Boot-Users] PATCH: omap5912osk uses CFI driver, (RO) text output of cfi_flash .c
by Michael Bendzick 25 Sep '05

25 Sep '05

* Patches by Michael Bendzick, 14 Jan 2005: - Configure omap5912osk board to use drivers/cfi_flash.c - Remove hardcoded personalized settings from omap5912osk.h - Fix spacing with (RO) marks in 'flinfo' output in drivers/cfi_flash.c The attached patch converts the omap5912osk board to use the main CFI driver, including for buffered writes, improving write throughput by about 10x. Consequently, the board/omap5912osk/flash.c file is removed with this patch. The drivers/cfi_flash.c file is adjusted slightly to make the columns line up better (see example below). Old: 00000000 (RO) 00020000 (RO) 00040000 00060000 00080000 000A0000 000C0000 000E0000 00100000 00120000 New: 00000000 (RO) 00020000 (RO) 00040000 00060000 00080000 000A0000 000C0000 000E0000 00100000 00120000 -Michael Bendzick Logic Product Development michaelb at logicpd dot com

2 1

[U-Boot-Users] Lowering memory footprint
by Ladislav Michl 24 Sep '05

24 Sep '05

Hi Wolfgang et all, I ported U-Boot to OMAP5910 based board and before submiting patch I'd like to discuss few issues. Board has 64M RAM and 32M bit mirror flash, which is quite sufficient to run U-Boot under normal circumstancies. During production of prototypes I met few boards with bad printed circuit board or bad soldering. Therefore I decided to run U-Boot from OMAP's 192kB internal RAM located at 2000'0000-2002'ffff with TEXT_BASE set to 2001'2000. That way I have 64kB heap and 8kB stack, which I found is sufficient for my needs. Such setup helps a lot while debugging hardware problems, despite I know it could be done different way, but it would be pity not to use U-Boot's power :) Because CFG_MALLOC_LEN is 64k-128 something like this is needed to startup code: Index: cpu/arm925t/start.S =================================================================== RCS file: /cvsroot/u-boot/u-boot/cpu/arm925t/start.S,v retrieving revision 1.8 diff -u -r1.8 start.S --- cpu/arm925t/start.S 9 Jan 2005 17:12:29 -0000 1.8 +++ cpu/arm925t/start.S 12 Jan 2005 12:45:27 -0000 @@ -83,6 +83,10 @@ _TEXT_BASE: .word TEXT_BASE +_STACK_OFS: + .word CFG_MALLOC_LEN + CFG_GBL_DATA_SIZE +_BAD_STACK_OFS: + .word CFG_MALLOC_LEN + CFG_GBL_DATA_SIZE + CONFIG_STACKSIZE + 8 .globl _armboot_start _armboot_start: @@ -188,8 +192,8 @@ /* Set up the stack */ stack_setup: ldr r0, _TEXT_BASE /* upper 128 KiB: relocated uboot */ - sub r0, r0, #CFG_MALLOC_LEN /* malloc area */ - sub r0, r0, #CFG_GBL_DATA_SIZE /* bdinfo */ + ldr r1, _STACK_OFS + sub r0, r0, r1 /* malloc area and bdinfo */ #ifdef CONFIG_USE_IRQ sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif @@ -293,8 +297,8 @@ stmia sp, {r0 - r12} @ Save user registers (now in svc mode) r0-r12 ldr r2, _armboot_start - sub r2, r2, #(CONFIG_STACKSIZE+CFG_MALLOC_LEN) - sub r2, r2, #(CFG_GBL_DATA_SIZE+8) @ set base 2 words into abort stack + ldr r13, _BAD_STACK_OFS + sub r2, r2, r13 ldmia r2, {r2 - r3} @ get values for "aborted" pc and cpsr (into parm regs) add r0, sp, #S_FRAME_SIZE @ grab pointer to old stack @@ -326,8 +330,8 @@ .macro get_bad_stack ldr r13, _armboot_start @ setup our mode stack - sub r13, r13, #(CONFIG_STACKSIZE+CFG_MALLOC_LEN) - sub r13, r13, #(CFG_GBL_DATA_SIZE+8) @ reserved a couple spots in abort stack + ldr r2, _BAD_STACK_OFS + sub r13, r13, r2 str lr, [r13] @ save caller lr in position 0 of saved stack mrs lr, spsr @ get the spsr Flash is partitioned this way: 128k - U-Boot 128k - env 16256k - data1 16256k - data2 Kernel is loaded directly from jffs2 partition to ease firmware upgrating. New firmware is unpacked into other partion (after user data are backed out) and if it boots sucessfuly U-Boot env is changed permanetly. Otherwise watchdog resets board and old firmware is used again. Although only following commands are enabled: CFG_CMD_BDI, CFG_CMD_LOADB, CFG_CMD_IMI, CFG_CMD_FLASH, CFG_CMD_MEMORY, CFG_CMD_NET, CFG_CMD_ENV, CFG_CMD_BOOTD, CFG_CMD_DHCP, CFG_CMD_PING, CFG_CMD_JFFS2, there is not enough space to fit U-Boot into 120kB without ripping out CramFS support. My question is whenever I should make only CramFS selectable or allow choice between JFFS2 and/or CramFS and how should be such configuration handled (you know it's quite hard for me to come with some nice short descriptive names :)) And finally ~64k heap is not sufficient for zlib to decompress kernel after it is loaded from jffs2 partition, because node structures are still allocated. I hope it is reasonable to expect, that once file is loaded it is intended to execute it and free memory used by jffs2 private structures. Index: fs/jffs2/jffs2_1pass.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/fs/jffs2/jffs2_1pass.c,v retrieving revision 1.15 diff -u -p -r1.15 jffs2_1pass.c --- fs/jffs2/jffs2_1pass.c 12 May 2004 22:54:39 -0000 1.15 +++ fs/jffs2/jffs2_1pass.c 12 Jan 2005 13:17:58 -0000 @@ -467,8 +467,8 @@ jffs2_scan_empty(u32 start_offset, struc return offset - part->offset; } -static u32 -jffs_init_1pass_list(struct part_info *part) +static void +jffs_1pass_free_nodes(struct part_info *part) { struct b_lists *pL; @@ -478,6 +478,16 @@ jffs_init_1pass_list(struct part_info *p free_nodes(&pL->dir); free(pL); } + part->jffs2_priv = NULL; +} + +static u32 +jffs_init_1pass_list(struct part_info *part) +{ + struct b_lists *pL; + + jffs_1pass_free_nodes(part); + if (NULL != (part->jffs2_priv = malloc(sizeof(struct b_lists)))) { pL = (struct b_lists *)part->jffs2_priv; @@ -1267,6 +1277,9 @@ jffs2_1pass_load(char *dest, struct part DEBUGF ("load: loaded '%s' to 0x%lx (%ld bytes)\n", fname, (unsigned long) dest, ret); + + jffs_1pass_free_nodes(part); + return ret; } Comments and suggestions are welcome (even those which suggest to use completely different solution ;)). I'll eventually send final patches based on eventual discussion. Best regards, ladis

2 6

[U-Boot-Users] [patch]virtex2 fix for bogus download error messages
by Andrew Dyer 24 Sep '05

24 Sep '05

the virtex2 fpga download code watches for init going active during a download of config data as an error condition. init also goes active after a configuration is finished in concert with the done signal. The code in cvs doesn't check for done active until all of the configuration data is sent. On our board the done signal would go active "early" as the configuration data has a few extra pad bytes at the end, but the code would print an error message even though the download had suceeded. The patch adds a check for done going active before checking init. If done is seen active the byte loading is cut short. If debugging is on it will print the count where it finished (8 bytes early for us). It also changes the printf string to indicate the counts it prints are in ticks and not mS. I only have a system with 'slave parallel' style config interface, so I've only patched that download version. The virtex2 slave serial and spartan2 versions may have the same problem, I didn't have time to look. -- Hardware, n.: The parts of a computer system that can be kicked.

2 1

[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

RE: [U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash??? ?
by Eisenhut, Daniel (GE Healthcare) 24 Sep '05

24 Sep '05

> > The code at the entry point needs to be small, reliable and never require an > > upgrade in the field. This code would run a CRC on the primary U-boot image > > THe code at the entry point that is small, reliable and never > requires an upgrade in the field is U-Boot. Just don't touch it. You > don't have to. ...insert bullet, spin cylinder, point at foot, pull trigger... Hopefully, we will never need to update. But if we do, it'd be nice to be able to reduce the risk of updating as much as possible. > What you typically do (assuming the hardware supports it) is to have > two banks of flash memory that can be swapped using some jumper or > switch or so. When it costs a grand just to have a service tech walk in the door, this becomes an unacceptable option.

2 1