February 2004 - U-Boot

[U-Boot-Users] 答复: [U-Boot-Users] U-Boot and IOP80321
by kelphon.Tang (唐天兵) 24 Feb '04

24 Feb '04

Dear wolfgang, I think there are many people need such function, and I want to setup a team to porting iop80321 for u-boot. Dear all, any suggests will be a good think. and I need your help. > Happy Work, Happy Life ;) > ------------------------------------------- > Kelphon Tang > SW2, DSBU > MiTAC Research(shanghai) LTD. > Tel: 86-21-62479332 ext:2238 > Fax: 86-21-62479474 -----原始?件----- ?件人: Wolfgang Denk [mailto:wd@denx.de] ?送??: 2004年2月23日 17:57 收件人: kelphon.Tang (昄毞條) 主?: Re: [U-Boot-Users] U-Boot and IOP80321 In message <2D0FAB2B2342734183F200047F996CF08415F2(a)mrsmail.mitac.com.cn> you wrote: > > I am dev a board base on Intel's 80321 CPU, and I am not sure if the > u-boot can support such board. U-Boot supports XScale processrs, so a port to the 80321 should be pretty straightforward. > have anyone done such work to porting u-boot support this board now? No. > or I can get some document about u-boot and 80321? because I have > review U-Boot's document, I don't find document about this You will have to perform the port yourself. > ------_=_NextPart_001_01C3F9EC.13146E50 > Content-Type: text/html; > charset="big5" > Content-Transfer-Encoding: quoted-printable > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> Please do NOT post HTML!!! Post plain text only! Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de Too many people are ready to carry the stool when the piano needs to be moved.

2 1

[U-Boot-Users] patch to tftp.c
by Josh Fryman 24 Feb '04

24 Feb '04

this patch for "tftp.c" fixes a logical error in the prior implementation supporting direct-tftp-to-flash. this puts in some additional safety checks to make sure you don't cross a flash boundary during the course of a write. this will catch such actions before starting, and complain verbosely about what the actual problem is. -josh

2 1

[U-Boot-Users] patch to net.c
by Josh Fryman 24 Feb '04

24 Feb '04

this patch fixes "DEBUG" information so it's set based on the global DEBUG flag. it also makes the debug printing consistent with other parts of the code tree. -josh

2 1

[U-Boot-Users] patch to common.h
by Josh Fryman 24 Feb '04

24 Feb '04

here's a small patch that permits stringification in an ISO C portable way. eg, you can have #define FOO xyzabc and someplace else call Xstr(FOO) which will literally be replaced with "xyzabc" this was very useful in a couple of key places in some other patches and new-platform support. -josh

2 1

[U-Boot-Users] patch to LUBBOCK files
by Josh Fryman 24 Feb '04

24 Feb '04

with the prior changes in the lan91c96.c files, it requires a very small change in the lubbock header file (configs/lubbock.h). this adds a #define for the attribute address space for the lan chip. -josh

2 1

[U-Boot-Users] patch for SMsC 91C96 ethernet driver
by Josh Fryman 24 Feb '04

24 Feb '04

hi all, attached is a patch for lan91c96.c, a network driver apparently only used by the lubbock board and my platform port. the patch does a variety of things. i'd appreciate feedback, corrections, reports of breakage, etc. i'm also not sure that this is necessarily the "best" solution for some of the problems we had. - support little-endian mode to push MAC address correctly - removal of the hard-coded "attribute space" and replacement with a #define constant - clean up the hardware-init, smc-open, and smc-enable to more closely follow the manual in how to set parameters - a couple of minor cleanups -josh

2 1

[U-Boot-Users] patch for SMsC LAN91C96 driver header
by Josh Fryman 24 Feb '04

24 Feb '04

this is a corresponding patch for the header file, a couple of minor tweaks. -josh

2 1

[U-Boot-Users] patch for dlmalloc.c
by Josh Fryman 24 Feb '04

24 Feb '04

attached is a patch to permit debug info in dlmalloc.c. comments? -josh

2 1

[U-Boot-Users] small AT91RM9200 ethernet patch
by Steven Scholz 24 Feb '04

24 Feb '04

Hi there, please consider the attached patch. * Patch by Steven Scholz, 20 Feb 2004: - Add support for MII commands on AT91RM9200 boards - some cleanup in AT91RM9200 ethernet code -- Steven Scholz imc Measurement & Control imc Meßsysteme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin 13355 Berlin Germany Deutschland Index: cpu/at91rm9200/at91rm9200_ether.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/cpu/at91rm9200/at91rm9200_ether.c,v retrieving revision 1.3 diff -p -u -r1.3 at91rm9200_ether.c --- cpu/at91rm9200/at91rm9200_ether.c 19 Oct 2003 23:22:11 -0000 1.3 +++ cpu/at91rm9200/at91rm9200_ether.c 20 Feb 2004 14:14:05 -0000 @@ -310,8 +310,9 @@ static UCHAR at91rm9200_EmacReadPhy (AT9 unsigned short *pInput) { p_mac->EMAC_MAN = (AT91C_EMAC_HIGH & ~AT91C_EMAC_LOW) | - (AT91C_EMAC_CODE_802_3) | (AT91C_EMAC_RW_R) | - (RegisterAddress << 18); + (AT91C_EMAC_RW_R) | + (RegisterAddress << 18) | + (AT91C_EMAC_CODE_802_3); udelay (10000); @@ -421,8 +422,14 @@ int eth_init (bd_t * bd) p_mac->EMAC_RBQP = (long) (&rbfdt[0]); p_mac->EMAC_RSR &= ~(AT91C_EMAC_RSR_OVR | AT91C_EMAC_REC | AT91C_EMAC_BNA); - p_mac->EMAC_CFG = (p_mac->EMAC_CFG | AT91C_EMAC_CAF | AT91C_EMAC_NBC | AT91C_EMAC_RMII) + + p_mac->EMAC_CFG = (p_mac->EMAC_CFG | AT91C_EMAC_CAF | AT91C_EMAC_NBC) & ~AT91C_EMAC_CLK; + +#ifdef CONFIG_AT91C_USE_RMII + p_mac->EMAC_CFG |= AT91C_EMAC_RMII; +#endif + p_mac->EMAC_CTL |= AT91C_EMAC_TE | AT91C_EMAC_RE; return 0; @@ -462,5 +469,25 @@ int eth_rx (void) void eth_halt (void) { }; + +#if (CONFIG_COMMANDS & CFG_CMD_MII) +int miiphy_read(unsigned char addr, unsigned char reg, unsigned short * value) +{ + at91rm9200_EmacEnableMDIO (p_mac); + at91rm9200_EmacReadPhy (p_mac, reg, value); + at91rm9200_EmacDisableMDIO (p_mac); + return 0; +} + +int miiphy_write(unsigned char addr, unsigned char reg, unsigned short value) +{ + at91rm9200_EmacEnableMDIO (p_mac); + at91rm9200_EmacWritePhy (p_mac, reg, &value); + at91rm9200_EmacDisableMDIO (p_mac); + return 0; +} +#endif /* CONFIG_COMMANDS & CFG_CMD_MII */ + #endif /* CONFIG_COMMANDS & CFG_CMD_NET */ + #endif /* CONFIG_DRIVER_ETHER */ Index: include/configs/at91rm9200dk.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/configs/at91rm9200dk.h,v retrieving revision 1.5 diff -p -u -r1.5 at91rm9200dk.h --- include/configs/at91rm9200dk.h 6 Dec 2003 23:55:11 -0000 1.5 +++ include/configs/at91rm9200dk.h 20 Feb 2004 14:14:05 -0000 @@ -112,6 +116,7 @@ #define CONFIG_DRIVER_ETHER #define CONFIG_NET_RETRY_COUNT 20 +#define CONFIG_AT91C_USE_RMII #define CONFIG_HAS_DATAFLASH 1 #define CFG_SPI_WRITE_TOUT (5*CFG_HZ)

2 1

[U-Boot-Users] Re: [PATCH] New board support for the Xilinx ML300 platform
by Wolfgang Denk 24 Feb '04

24 Feb '04

Dear Peter, in message <40362618.2080806(a)xilinx.com> you wrote: > > in the attachment find the gzipped patch that adds support for the > Xilinx ML300 platform to U-Boot. Some documentation is provided in > doc/README.ml300. > > The CHANGELOG entry is also attached. > > Please apply this patch to the repository. Added. Thanks a lot! Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de No, I'm not going to explain it. If you can't figure it out, you didn't want to know anyway... :-) - Larry Wall in <1991Aug7.180856.2854(a)netlabs.com>

1 0

[U-Boot-Users] [PATCH] Nios: WATCHDOG preparation
by Stephan Linz 24 Feb '04

24 Feb '04

Hi all, attached patch includes the WATCHDOG_RESET() macro at some more points in U-Boot so I can use it in my upcoming new Nios board support. Please, merge it with current CVS tree -- thanks. -- Best regards, Stephan Linz

2 4

[U-Boot-Users] patch for dlmalloc.c and cfi_flash.c
by Josh Fryman 24 Feb '04

24 Feb '04

hi all, attached is a patch for two different quick fixes. dlmalloc: enable the debug data. instead of having #if0 everywhere, replace with #ifdef DEBUG. cfi_flash: i shared this patch with brad, and he asked i send it on. he's going to try to find a better long-term solution. for the CFI interface to support little-endian, it does byte swapping. unfortunately, the byte-swapping was only coded for 16-bit width. this corrects the coding to be more "correct" and adds 32-bit support. comments? -josh

2 1

[U-Boot-Users] SystemACE Patch
by Stephen Williams 24 Feb '04

24 Feb '04

Are there problems with the last iteration of my SystemACE support patch? After the last attempt, I didn't hear any complaints about formatting, so in case I just got lost in the frey, here again is my SystemACE support. -- Steve Williams "The woods are lovely, dark and deep. steve at XXXXXXXXXX But I have promises to keep, http://www.XXXXXXXXXX and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." diff -purN -xEntries -x'*.orig' u-boot.orig/README u-boot/README --- u-boot.orig/README 2004-02-08 14:55:39.000000000 -0800 +++ u-boot/README 2004-02-09 16:06:41.000000000 -0800 @@ -1410,6 +1410,20 @@ The following options need to be configu allows to read/write in Dataflash via the standard commands cp, md... +- SystemACE Support: + CONFIG_SYSTEMACE + + Adding this option adds support for Xilinx SystemACE + chips attached via some sort of local bus. The address + of the chip must alsh be defined in the + CFG_SYSTEMACE_BASE macro. For example: + + #define CONFIG_SYSTEMACE + #define CFG_SYSTEMACE_BASE 0xf0000000 + + When SystemACE support is added, the "ace" device type + becomes available to the fat commands, i.e. fatls. + - Show boot progress: CONFIG_SHOW_BOOT_PROGRESS diff -purN -xEntries -x'*.orig' u-boot.orig/common/Makefile u-boot/common/Makefile --- u-boot.orig/common/Makefile 2004-01-06 14:38:21.000000000 -0800 +++ u-boot/common/Makefile 2004-02-03 17:41:27.000000000 -0800 @@ -28,7 +28,7 @@ LIB = libcommon.a AOBJS = COBJS = main.o ACEX1K.o altera.o bedbug.o \ - cmd_autoscript.o \ + cmd_ace.o cmd_autoscript.o \ cmd_bdinfo.o cmd_bedbug.o cmd_bmp.o cmd_boot.o cmd_bootm.o \ cmd_cache.o cmd_console.o \ cmd_date.o cmd_dcr.o cmd_diag.o cmd_doc.o cmd_dtt.o \ diff -purN -xEntries -x'*.orig' u-boot.orig/common/cmd_ace.c u-boot/common/cmd_ace.c --- u-boot.orig/common/cmd_ace.c 1969-12-31 16:00:00.000000000 -0800 +++ u-boot/common/cmd_ace.c 2004-02-04 18:46:50.000000000 -0800 @@ -0,0 +1,205 @@ +/* + * Copyright (c) 2004 Picture Elements, Inc. + * Stephen Williams (XXXXXXXXXXXXXXXX) + * + * This source code is free software; you can redistribute it + * and/or modify it in source code form under the terms of the GNU + * General Public License as published by the Free Software + * Foundation; either version 2 of the License, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + */ +#ident "$Id:$" + +/* + * The Xilinx SystemACE chip support is activated by defining + * CONFIG_SYSTEMACE to turn on support, and CFG_SYSTEMACE_BASE + * to set the base address of the device. This code currently + * assumes that the chip is connected via a byte-wide bus. + * + * The CONFIG_SYSTEMACE also adds to fat support the device class + * "ace" that allows the user to execute "fatls ace 0" and the + * like. This works by making the systemace_get_dev function + * available to cmd_fat.c:get_dev and filling in a block device + * description that has all the bits needed for FAT support to + * read sectors. + */ + +# include <common.h> +# include <command.h> +# include <systemace.h> +# include <part.h> +# include <asm/io.h> + +#ifdef CONFIG_SYSTEMACE + +/* + * The ace_readw and writew functions read/write 16bit words, but the + * offset value is the BYTE offset as most used in the Xilinx + * datasheet for the SystemACE chip. The CFG_SYSTEMACE_BASE is defined + * to be the base address for the chip, usually in the local + * peripheral bus. + */ +static unsigned ace_readw(unsigned offset) +{ + return readw(CFG_SYSTEMACE_BASE+offset); +} + +static unsigned ace_writew(unsigned val, unsigned offset) +{ + writew(val, CFG_SYSTEMACE_BASE+offset); +} + +/* */ + +static unsigned long systemace_read(int dev, + unsigned long start, + unsigned long blkcnt, + unsigned long *buffer); + +static block_dev_desc_t systemace_dev = {0}; + +static int get_cf_lock(void) +{ + int retry = 10; + + /* CONTROLREG = LOCKREG */ + ace_writew(0x0002, 0x18); + + /* Wait for MPULOCK in STATUSREG[15:0] */ + while (! (ace_readw(0x04) & 0x0002)) { + + if (retry < 0) + return -1; + + udelay(100000); + retry -= 1; + } + + return 0; +} + +static void release_cf_lock(void) +{ + /* CONTROLREG = none */ + ace_writew(0x0000, 0x18); +} + +block_dev_desc_t * systemace_get_dev(int dev) +{ + /* The first time through this, the systemace_dev object is + not yet initialized. In that case, fill it in. */ + if (systemace_dev.blksz == 0) { + systemace_dev.if_type = IF_TYPE_UNKNOWN; + systemace_dev.part_type = PART_TYPE_UNKNOWN; + systemace_dev.type = DEV_TYPE_HARDDISK; + systemace_dev.blksz = 512; + systemace_dev.removable = 1; + systemace_dev.block_read = systemace_read; + } + + return &systemace_dev; +} + +/* + * This function is called (by dereferencing the block_read pointer in + * the dev_desc) to read blocks of data. The return value is the + * number of blocks read. A zero return indicates an error. + */ +static unsigned long systemace_read(int dev, + unsigned long start, + unsigned long blkcnt, + unsigned long *buffer) +{ + unsigned val; + int retry; + unsigned char*dp = (unsigned char*)buffer; + + if (get_cf_lock() < 0) { + unsigned status = ace_readw(0x04); + + /* If CFDETECT is false, card is missing. */ + if (! (status&0x0010)) { + printf("** CompactFlash card not present. **\n"); + return 0; + } + + printf("**** ACE locked away from me (STATUSREG=%04x)\n", status); + return 0; + } + + retry = 2000; + for (;;) { + unsigned val = ace_readw(0x04); + + /* If CFDETECT is false, card is missing. */ + if (! (val & 0x0010)) { + printf("**** ACE CompactFlash not found.\n"); + release_cf_lock(); + return 0; + } + + /* If RDYFORCMD, then we are ready to go. */ + if (val & 0x0100) + break; + + if (retry < 0) { + printf("**** SystemACE not ready.\n"); + release_cf_lock(); + return 0; + } + + udelay(1000); + retry -= 1; + } + + /* Write LBA block address */ + ace_writew(start & 0xffff, 0x10); + start >>= 16; + ace_writew(start & 0xff, 0x12); + + /* Write sector count | ReadMemCardData. */ + ace_writew(blkcnt | 0x0300, 0x14); + + /* CONTROLREG = CFGRESET|LOCKREQ */ + ace_writew(0x0082, 0x18); + + retry = blkcnt * 16; + while (retry > 0) { + int idx; + + /* Wait for buffer to become ready. */ + while (! (ace_readw(0x04) & 0x0020)) { + udelay(1000); + } + + /* Read 16 words of 2bytes from the sector buffer. */ + for (idx = 0 ; idx < 16 ; idx += 1) { + unsigned short val = ace_readw(0x40); + *dp++ = val & 0xff; + *dp++ = (val>>8) & 0xff; + } + + retry -= 1; + } + + release_cf_lock(); + + return blkcnt; +} + + +#endif + +/* + * $Log: $ + */ + diff -purN -xEntries -x'*.orig' u-boot.orig/common/cmd_fat.c u-boot/common/cmd_fat.c --- u-boot.orig/common/cmd_fat.c 2003-10-15 16:53:50.000000000 -0700 +++ u-boot/common/cmd_fat.c 2004-02-03 21:18:51.000000000 -0800 @@ -63,6 +63,12 @@ block_dev_desc_t *get_dev (char* ifname, return(mmc_get_dev(dev)); } #endif +#if defined(CONFIG_SYSTEMACE) + if (strcmp(ifname,"ace")==0) { + extern block_dev_desc_t * systemace_get_dev(int dev); + return(systemace_get_dev(dev)); + } +#endif return NULL; } diff -purN -xEntries -x'*.orig' u-boot.orig/disk/part.c u-boot/disk/part.c --- u-boot.orig/disk/part.c 2004-01-03 11:43:49.000000000 -0800 +++ u-boot/disk/part.c 2004-02-03 18:04:47.000000000 -0800 @@ -36,7 +36,7 @@ #if ((CONFIG_COMMANDS & CFG_CMD_IDE) || \ (CONFIG_COMMANDS & CFG_CMD_SCSI) || \ (CONFIG_COMMANDS & CFG_CMD_USB) || \ - (CONFIG_MMC) ) + (CONFIG_MMC) || (CONFIG_SYSTEMACE) ) /* ------------------------------------------------------------------------- */ /* @@ -107,7 +107,8 @@ void dev_print (block_dev_desc_t *dev_de #if ((CONFIG_COMMANDS & CFG_CMD_IDE) || \ (CONFIG_COMMANDS & CFG_CMD_SCSI) || \ - (CONFIG_COMMANDS & CFG_CMD_USB) ) + (CONFIG_COMMANDS & CFG_CMD_USB) || \ + defined(CONFIG_SYSTEMACE) ) #if defined(CONFIG_MAC_PARTITION) || \ defined(CONFIG_DOS_PARTITION) || \ diff -purN -xEntries -x'*.orig' u-boot.orig/disk/part_dos.c u-boot/disk/part_dos.c --- u-boot.orig/disk/part_dos.c 2003-09-10 15:30:55.000000000 -0700 +++ u-boot/disk/part_dos.c 2004-02-03 18:06:24.000000000 -0800 @@ -37,7 +37,8 @@ #if ((CONFIG_COMMANDS & CFG_CMD_IDE) || \ (CONFIG_COMMANDS & CFG_CMD_SCSI) || \ - (CONFIG_COMMANDS & CFG_CMD_USB) ) && defined(CONFIG_DOS_PARTITION) + (CONFIG_COMMANDS & CFG_CMD_USB) || \ + (CONFIG_SYSTEMACE)) && defined(CONFIG_DOS_PARTITION) /* Convert char[4] in little endian format to the host format integer */ diff -purN -xEntries -x'*.orig' u-boot.orig/include/systemace.h u-boot/include/systemace.h --- u-boot.orig/include/systemace.h 1969-12-31 16:00:00.000000000 -0800 +++ u-boot/include/systemace.h 2004-02-04 18:47:32.000000000 -0800 @@ -0,0 +1,31 @@ +#ifndef __systemace_H +#define __systemace_H +/* + * Copyright (c) 2004 Picture Elements, Inc. + * Stephen Williams (steve(a)picturel.com) + * + * This source code is free software; you can redistribute it + * and/or modify it in source code form under the terms of the GNU + * General Public License as published by the Free Software + * Foundation; either version 2 of the License, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + */ +#ident "$Id:$" + +#ifdef CONFIG_SYSTEMACE + +# include <part.h> + +block_dev_desc_t * systemace_get_dev(int dev); + +#endif +#endif

2 1

[U-Boot-Users] Removing duplicate "FPGA Support" notes from the README file
by Jon Diekema 23 Feb '04

23 Feb '04

Product: - u-boot Version: - 1.0.2 CHANGELOG: * Patch by Jon Diekema, 14 Jeb 2004: - Removing duplicate "FPGA Support" notes from the README file. This section is repeated twice in the README file. CVS Comments: - Removing duplicate "FPGA Support" notes -- -------------------\\----------------------\\---------------------------- Jon Diekema | Custom IDEAS | http://www.cideas.com/ diekema(a)cideas.com | Grand Rapids, MI |

2 1

RE: [U-Boot-Users] [PATCH] Support for OMAP1610 H2 platform
by Woodruff, Richard 23 Feb '04

23 Feb '04

That file happens to have one more minor fix since then. In udelay(): If( (tmo + tmp) < tmp ) /* if setting this for ... */ Should be: If( tmo + tmp + 1) < tmp ) /* if setting this ... */ I found when leaving it set for a long time I could get caught in an infinite loop... the time rolled between get_time() and the and the call to get_timer_masked(). You generally don't hit it unless you let the board sits at the boot prompt for long. I'll submit more patches in the future for this and other fixes.......unless Wolfgang applies them first, as I have recently sent him a snapshot. Regards, Richard W. -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Wolfgang Denk Sent: Monday, February 23, 2004 3:35 PM To: Kamat, Nishant Cc: 'u-boot-users(a)lists.sourceforge.net' Subject: Re: [U-Boot-Users] [PATCH] Support for OMAP1610 H2 platform In message <536A1C579C92D71193CC0008C791B02E02F1551E(a)dlee08.itg.ti.com> you wrote: > > This patch adds support for the OMAP1610 H2 platform. It also adds to > cpu/arm926ejs/interrupt.c the fixes that Richard Woodruff had submitted for > arm925 (see below). Finally, a minor timer related bug in OMAP1610 Innovator > is fixed and support for booting through Flash or ROM is added for both the > OMAP1610 Innovator and H2. Added, thanks. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de If in any problem you find yourself doing an immense amount of work, the answer can be obtained by simple inspection. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ 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] [Patch] correct machine check reason in cpu/mpc5xxx/traps.c
by Reinhard Meyer 23 Feb '04

23 Feb '04

This patch corrects the reason printout on machine check exceptions for the 603e processor in the MPC5200. It is the PowerPC numbered bits 12 to 15 that should be tested, not the bits 2**12 to 2**15. A similiar change could be appropriate for other 603e based MPCs... Changelog: * patch by Reinhard Meyer, 14 Feb 2004 Corrected tested bits in machine check exception in cpu/mpc5xxx/traps.c

2 1

RE: [U-Boot-Users] patch for CFI flash driver
by Brad Kemp 23 Feb '04

23 Feb '04

Josh, I re-ran the test to fast (use mm instead of nm), the results are be => md 0xe8180000 e8180000: ff060708 0ffa8f64 090a0b0c 0d0e0f10 .......d........ e8180010: 11121314 15161718 0000ffff 0ffa8f64 ...............d e8180020: ffffffff ffffffff ffffffff ffffffff ................ e8180030: ffffffff ffffffff ffffffff ffffffff ................ > -----Original Message----- > From: Brad Kemp > Sent: Monday, February 23, 2004 4:42 PM > To: 'Josh Fryman' > Cc: u-boot-users(a)lists.sourceforge.net > Subject: RE: [U-Boot-Users] patch for CFI flash driver > > > Josh, > I think the solution to the 8 bit x8/x16 problem is to > separate the query command matching from the commands that > are written to the flash. Not having an 8bit x8/x16 > implementation has made it hard for me to work this out. > > As for your patch. While it does let me copy odd amounts of > data at unaligned boundaries (something the driver did not > previosly do). The results I get are not correct. Below I > have filled memory with 010203040506... And copied part of it > to a previously erase sector in flash. > > > => nm 0x140000 > 00140000: ffffffff ? 01020304 > 00140000: 01020304 ? 05060708 > 00140000: 05060708 ? 090a0b0c > 00140000: 090a0b0c ? 0d0e0f10 > 00140000: 0d0e0f10 ? 11121314 > 00140000: 11121314 ? 15161718 > 00140000: 15161718 ? 191a1b1c > 00140000: 191a1b1c ? 1d1e1f20 > 00140000: 1d1e1f20 ? 21222324 > 00140000: 21222324 ? 25262728 > 00140000: 25262728 ? 292a2b2c > 00140000: 292a2b2c ? 2d2e2f30 > 00140000: 2d2e2f30 ? . > > => cp.b 0x140005 0xe8180003 0x15 > Copy to Flash... done > => md 0xe8180000 > e8180000: ffffffff 0ffe99cc ffffffff ffffffff ................ > e8180010: ffffffff ffffffff 0000ffff 0ffe99cc ................ > e8180020: ffffffff ffffffff ffffffff ffffffff ................ > e8180030: ffffffff ffffffff ffffffff ffffffff ................ > e8180040: ffffffff ffffffff ffffffff ffffffff ................ > > > -----Original Message----- > > From: Josh Fryman [mailto:fryman@cc.gatech.edu] > > Sent: Monday, February 23, 2004 3:29 PM > > To: Brad Kemp > > Cc: u-boot-users(a)lists.sourceforge.net > > Subject: Re: [U-Boot-Users] patch for CFI flash driver > > > > > > hi brad, > > > > > I think this patch will break 8bit x8/x16 implementions. > > > > not surprising :) i was worried i was breaking things when > i did that > > solution, but wasn't sure how it would break. > > > > > The reports I got back from the field indicated that the > port width > > > had to be halved to get flash writes to work sucessfully on 8bit > > > x8/x16 implementations. I think there is a better solution to the > > > problem than the one that was originally implemented. > > > > i'm almost certain of it. i don't design well after a long day of > > debugging problems. > > > > do you have a nice solution to the problem? or do you just have the > > same "there has to be a better way" feeling about it that i do? i > > can go back and try to actually design a proper solution, but i was > > hoping the "fix" would give you the insight needed that > you'd have an > > elegant solution... > > > > cheers, > > > > -josh > > > > (another idea was to malloc a sufficiently large buffer, read in > > current flash contents, do the update to memory, then call the > > existing -unhacked- routines to write back to flash on nice > > boundaries to kill padding problems and alignment issues... but this > > seemed like an even worse approach.) > > > > >

1 0

RE: [U-Boot-Users] patch for CFI flash driver
by Brad Kemp 23 Feb '04

23 Feb '04

Josh, I think the solution to the 8 bit x8/x16 problem is to separate the query command matching from the commands that are written to the flash. Not having an 8bit x8/x16 implementation has made it hard for me to work this out. As for your patch. While it does let me copy odd amounts of data at unaligned boundaries (something the driver did not previosly do). The results I get are not correct. Below I have filled memory with 010203040506... And copied part of it to a previously erase sector in flash. => nm 0x140000 00140000: ffffffff ? 01020304 00140000: 01020304 ? 05060708 00140000: 05060708 ? 090a0b0c 00140000: 090a0b0c ? 0d0e0f10 00140000: 0d0e0f10 ? 11121314 00140000: 11121314 ? 15161718 00140000: 15161718 ? 191a1b1c 00140000: 191a1b1c ? 1d1e1f20 00140000: 1d1e1f20 ? 21222324 00140000: 21222324 ? 25262728 00140000: 25262728 ? 292a2b2c 00140000: 292a2b2c ? 2d2e2f30 00140000: 2d2e2f30 ? . => cp.b 0x140005 0xe8180003 0x15 Copy to Flash... done => md 0xe8180000 e8180000: ffffffff 0ffe99cc ffffffff ffffffff ................ e8180010: ffffffff ffffffff 0000ffff 0ffe99cc ................ e8180020: ffffffff ffffffff ffffffff ffffffff ................ e8180030: ffffffff ffffffff ffffffff ffffffff ................ e8180040: ffffffff ffffffff ffffffff ffffffff ................ > -----Original Message----- > From: Josh Fryman [mailto:fryman@cc.gatech.edu] > Sent: Monday, February 23, 2004 3:29 PM > To: Brad Kemp > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] patch for CFI flash driver > > > hi brad, > > > I think this patch will break 8bit x8/x16 implementions. > > not surprising :) i was worried i was breaking things when i did that > solution, but wasn't sure how it would break. > > > The reports I got back from the field indicated that the port width > > had to be halved to get flash writes to work sucessfully on 8bit > > x8/x16 implementations. I think there is a better solution to the > > problem than the one that was originally implemented. > > i'm almost certain of it. i don't design well after a long day of > debugging problems. > > do you have a nice solution to the problem? or do you just have the > same "there has to be a better way" feeling about it that i do? i > can go back and try to actually design a proper solution, but i was > hoping the "fix" would give you the insight needed that you'd have an > elegant solution... > > cheers, > > -josh > > (another idea was to malloc a sufficiently large buffer, read in > current flash contents, do the update to memory, then call the > existing -unhacked- routines to write back to flash on nice > boundaries to kill padding problems and alignment issues... but this > seemed like an even worse approach.) > >

1 0

[U-Boot-Users] [Patch] Added EVAL5200 support in rtc/mk48t59.c
by Reinhard Meyer 23 Feb '04

23 Feb '04

This patch enables support of the EVAL5200 board's M48T08 realtime clock Changelog: not worth mentioning adding another #elsif -or- if required: * patch by Reinhard Meyer, 14 Feb 2004 Added support for the M48T08 on the EVAL5200 board in rtc/mk48t59.c

2 1

[U-Boot-Users] Calling show_boot_progress() whenever POST "FAILED" is printed.
by Jon Diekema 23 Feb '04

23 Feb '04

Product: - u-boot Version: - 1.0.2 CHANGELOG: - Calling show_boot_progress() whenever POST "FAILED" is printed. Background: - We ran into a board that is having memory failure. On bootup it reports: ... DRAM: 128MB Memory error at 0700053c, wrote ffffffff, read ffffffdd ! POST memory FAILED FLASH: 2MB Net: FCC2 ETHERNET POST cpu PASSED Autobooting... Then it attempts to boot, gets a kernel panic, and resets after 180 seconds. The problem is the POST memory failure never gets flagged anywhere other than the serial output, so unless you watch the serial output for it, the only indication is a crash and reset. CVS Comments: - Calling show_boot_progress() whenever POST "FAILED" is printed.

2 1

[U-Boot-Users] [PATCH] Support for OMAP1610 H2 platform
by Kamat, Nishant 23 Feb '04

23 Feb '04

Hi all, This patch adds support for the OMAP1610 H2 platform. It also adds to cpu/arm926ejs/interrupt.c the fixes that Richard Woodruff had submitted for arm925 (see below). Finally, a minor timer related bug in OMAP1610 Innovator is fixed and support for booting through Flash or ROM is added for both the OMAP1610 Innovator and H2. Best regards, Nishant > -----Original Message----- > From: Woodruff, Richard > Sent: Thursday, October 16, 2003 12:28 PM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] cpu/arm925 timer fixes. > > > Hello, > > This patch fixes a few bugs which made udelay() not work > properly on 925 based systems. A while back when I increased > my boards clock speed I ran into quite a few problems which > resulted in these fixes. > > I think the Innovator should be switched over to use a real > udelay code instead of its busy spins. They do not scale at > all with clock speed, and do not keep the useful timestamp > properly updating. > > Regards, > > Richard W. > >

2 1

[U-Boot-Users] [PATCH] Nios: timer with variable period; POST preparation
by Stephan Linz 23 Feb '04

23 Feb '04

Hi all, Hi Scott, here are two small patches I need for my upcoming new Nios board support. Scott, could you check-up the patches at your DK1C20 board and note Wolfgang and me so we can put it into CVS ? -- thanks. 1/2 tick timer supports variable (programmable) periods (min. 1 ms tick) 2/2 some small preparation for upcoming POST support for Nios arch -- Best regards, Stephan Linz

2 1

RE: [U-Boot-Users] Adding support for a 'similar to existing' boa rd
by Kamat, Nishant 23 Feb '04

23 Feb '04

Wolfgang, I would like to change the '1610innovator-' like directory and file names to general 'omap1610' to include support for both the boards. Is that okay. If yes, would you like me to send one patch containing changes to existing files, and another containing the re-naming stuff, just so that it is easy for you to identify the changes? Or one single patch is ok? Thanks, Nishant > > > In message > <536A1C579C92D71193CC0008C791B02E02DE106B(a)dlee08.itg.ti.com> > you wrote: > > > > I wish to add support for another TI OMAP1610 board which > is code-wise > > very similar to the OMAP1610 Innovator. Would you please > suggest what > > is better > > - creating another directory structure for that board > (which is probably > > technically correct), or adding changes to the OMAP1610 > Innovator's files > > with #ifdef's? The changes in code would be 10-15 lines at most. > > You probably want to have your own board config file in > include/configs/; if the changes in the board specific > directory are really that small some #ifdef's are OK. > > Best regards, > > Wolfgang Denk >

2 1

[U-Boot-Users] Patch MIP405 Board
by Denis Peter 23 Feb '04

23 Feb '04

Dear Wolfgang, the attached patch against the current CVS adds POST support for the MIP405 Board. CHANGELOG: * Patch by Denis Peter, 11 Feb 2004 add POST support for the MIP405 board With best regards, Denis

2 1

RE: [U-Boot-Users] patch for CFI flash driver
by Brad Kemp 23 Feb '04

23 Feb '04

Josh, I think this patch will break 8bit x8/x16 implementions. The reports I got back from the field indicated that the port width had to be halved to get flash writes to work sucessfully on 8bit x8/x16 implementations. I think there is a better solution to the problem than the one that was originally implemented. Brad > -----Original Message----- > From: Josh Fryman [mailto:fryman@cc.gatech.edu] > Sent: Saturday, February 21, 2004 12:30 AM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] patch for CFI flash driver > > > > attached is a full patch for the CFI flash driver. it tries > to correct > a problem i spent a lot of time examining. i've sent the > patch to brad > (the maintainer) as well, but wanted to post it here for > others to give > feedback on as well. > > if anyone has a better solution, other ideas, etc, i'd > appreciate hearing > them. > > in short, in "write_buff(...)", the platform i'm using needs > to be able to > pass in any mixture of alignments and lengths. ie, the > target flash addr > may not be aligned on a nice boundary, and the > memory-to-write-from may > not be either. > > there was a very rudimentary "check" in the prior version > that would try > to do something for misaligned boundaries, but it just didn't > work. it > wound up writing padding to the beginning or end of the > flash, which would > make things fail (ie, CRC) all over the place. it also wound > up dropping > (!!) bytes under certain conditions, never writing them at all. > > below is my "fix". again, i think this is a hack, albeit a > robust one at > the moment. i think there's a better way to do this, or at least a > cleaner way, but i wanted to get your feedback on it. i'm > not sure what > the "better way" is. > > the first function, flash_write_aligned, is _always_ handed a nicely > aligned block of data to write. the "data" pointer and the > "addr" flash > target location are always on a boundary which is a multiple > of the width. > (ie, 8, 16, 32, or 64-bits.) count is the number of bytes, > but it's also > promised to be an integer multiple of the width. > > the revised version of "write_buff()" uses the "READ_CURR" > macro in two > places... but otherwise is fairly commented by itself. it > does essentially > a pre-alignment set of operations, then does a block-write > via the first > function "write_aligned", and then does any necessary tail > corrections. > > any thoughts? > > -josh >

2 1