February 2004 - U-Boot

[U-Boot-Users] (no subject)
by listmember＠orkun.us 11 Feb '04

11 Feb '04

Wolfgang, I am attaching the gzip compressed patch for Cogent CSB272 board. This is based on CVS version of u-boot (checked out today: Feb 10) Best regards, Tolunay Orkun

1 0

[U-Boot-Users] Adding support for a 'similar to existing' board
by Kamat, Nishant 10 Feb '04

10 Feb '04

Wolfgang, 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. Thanks, Nishant

2 1

[U-Boot-Users] (no subject)
by uboot＠sundmangroup.com 10 Feb '04

10 Feb '04

Greetings! I built u-boot 1.0.1 with the new MontaVista Professional Edition 3.1, Dev Rocket Environment. It went well and I succeeded to flash the code to a Motorola Evaluation board ( PQ2FADS-VR ). However, when I tried to debug the code I started in start.S but after the the first jump bl in start.S I ended up in a C file that is handling U-boot CLI commands... I think that the GDB in BDI2000 is a 5.x version and GDB in the MontaVista Professional Edition 3.1 is a 6.0 version ( Gcc 3.3.2 ). Do you think that this could be a possible issue or is it only me doing some configuration faults? Cheers // Matias ( Former matias.sundman(a)ericsson.com :))

2 1

RE: [U-Boot-Users] SystemACE support for u-boot via fat
by Demke, Torsten 10 Feb '04

10 Feb '04

Hello Steve, I would recommed: "diff -purN --exclude=CVS your_local_CVS_dir clean_checkout_CVS_dir" Regards, Torsten > -----Original Message----- > From: Stephen Williams [mailto:gfi8d1h02@sneakemail.com] > Sent: Dienstag, 10. Februar 2004 18:52 > To: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] SystemACE support for u-boot via fat > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stephan Linz linz-at-mazet.de |u-boot-users| wrote: > | Am Dienstag, 10. Februar 2004 01:29 schrieb Stephen Williams: > | > |>--snipp-- > |> > |>"cvs diff -puRN" does not include new files, the -N flag is > |>useless in that context as cvs does not know of those files > |>so does not even try to diff them. You will need to accept > | > | > | Are you realy right ? The CVS short help 'cvs --help diff' says: > | > | " -N include diffs for added and removed files." > | > | The man page of GNU diff says: > | > | " -N > | --new-file > | In directory comparison, if a file is found in only one > directory, > treat > | it as present but empty in the other directory." > | > | > > If I had write access to the repository, then I could > "cvs add" the files and then use "cvs diff -N" to get > the desired patch. But then, if I had write acces to the > repository, I could just add it without patches flying > about:-) > > - -- > 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." > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFAKRpZrPt1Sc2b3ikRAnErAJ9jH0wizSsSNCkdpiuWUbjXlmFxSwCgteaz > JXz0u6EOw0SSG3CH8IwB6CM= > =yYki > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > 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] serial download of uImage
by himbA 10 Feb '04

10 Feb '04

Hi I'm a newbie to u-boot and pretty much to embedded systems. I have a pxa255 board running 2.4.19 kernel with appropriate patches for ARM and xscale and u-boot 1.0.1 as bootloader already installed by somebody else (I just got the stuff). Now, ethernet link is not working yet, due to some issues with SMSC LAN91c111 driver for linux, so I would like to use serial link to download new kernel image. I've built the kernel and I have uImage ready to go. I also have kermit setup according to DULG wiki. I can connect to serial port of my board just fine, issue 'loadb offset' and then hit ctrl-\c, issue 'send uImage'. this the response i get: ************************* SEND-class command failed. Packets sent: 2 Retransmissions: 11 Timeouts: 7 Damaged packets: 5 Fatal Kermit Protocol Error: Too many retries Is there a cure for this? Let me also mention thet I'm using USB-rs232 adapter on /dev/ttyUSB0 #l /dev/ttyUSB0 crw-rw---- 1 root uucp 188, 0 2004-02-09 00:14 /dev/ttyUSB0 I'm member of uucp. Also is it possible to use SMSC LAN91c111 from u-boot to get dhcp+tftp+nfs boot working? regards, himba

3 4

[U-Boot-Users] Loading u-boot to mpc5200 flash with bdi2000
by Kate Alhola 10 Feb '04

10 Feb '04

I have been trying to load u-bood into flash of brand new board but found some problems. I have bdi2000, lite5200 and my own board ( itipower5200 ). I noticed that when i boot either board up. I can't read access flash with bdi2000 untill i have executed some amount of initial code that exists in lite5200 but of cource i can do this with my board because there is no code in flash yet. It looks a like that cpu in lite5200 can read instructions from flash at beginning but bdi2000 displays only zeroes when i try to use md command. Both boards, lite5200 and itipower5200 displays zeroes and i have checked with osciloscope that least my board access flash and gives out 0xff I have tried look the bdi2000 sample configuration files from denx but i have not yet find out what i have missed. I also traced the motorola dBug from reset with lite5200 board to see what changed the behavior but least i did not get sensible result that should affect the behavior. The bdi2000 has all the time read access to the internal memory space of mpc5200 and i can accress config redisters or internal ram at beginning but just reading external flash gives zeroes even i have initializeg cs controll registers. So, simply, the problem is that what i should tell to bdi2000 that i can access flash in empty board ? Kate ------------------------------------------------------------------------------------------------- ; bdiGDB configuration file for 603ei (Zeppo) evaluation system ; ------------------------------------------------------------- ; ; DINK is used to setup the target. ; ; ; bdiGDB configuration file for the IceCube5200 evaluation board ; -------------------------------------------------------------- ; [INIT] ; init core register WREG MSR 0x00001002 ;MSR : ME,RI WM32 0x80000000 0x0000f000 ;MBAR : internal registers at 0xf0000000 WSPR 311 0xf0000000 ;MBAR : save internal register offset WSPR 279 0xf0000000 ;SPRG7: save internal memory offsetReg: 279 ; ; init memory controller WM32 0xf0000004 0x0000ff80 ;CS0 start = 0xff800000 WM32 0xf0000008 0x0000ffff ;CS0 stop = 0xffffffff WM32 0xf0000054 0x00010001 ;CSE: enable CS0, disable CSBOOT WM32 0xf0000300 0x00047800 ;BOOT ctrl ; init SDRAM CS for 16/16 Micron Type WM32 0xf0000034 0x00000019 ;SDRAM CS0, 64 MByte physical, can use all 64MByte WM32 0xf0000038 0x04000019 ;SDRAM CS1, 64 MByte physical, can use all 64MByte WM32 0xf0000204 0x10000000 ;SDRAM Set tap delay to 0x10 TSZ4 0x00000000 0x07FFFFFF ;SDRAM CS0,1, 128 MByte MMAP 0x00000000 0x07FFFFFF ;SDRAM CS0,1, 128 MByte WM32 0x80000B00 0x80000000 ;GPIO Enable CS1 ; init SDRAM controller for DDR 132MHz, CL=2.5 WM32 0x80000108 0x73722930 ;SDRAM Config 1 single read2readwrite delay cl=2.5, swt2rp =3 for DDR, read CAS = 7 (cl=2,5), act2rd= 2,66 -> 3, pre2act=2,66 -> 3, refresh to no read delay=0xA, Write latency for DDR =3 WM32 0x8000010C 0x47770000 ;SDRAM Config 2 WM32 0x80000104 0xF15F0F00 ;SDRAM Control: Mode register write enable mode reg=0, clk enable=1, DDR mode, auto refresh enabled, hi_addr set, use A10 for precharge, drive rule=1, refresh interval=d15, dqs_oe=b1111 WM32 0x80000104 0xF15F0F02 ;SDRAM Control: Mode register write enable, precharge all WM32 0x80000100 0x40090000 ;SDRAM Extended Mode DLL enabled, drive strength reduced, QFC disabled WM32 0x80000100 0x058D0000 ;SDRAM Mode, reset DLL burst 8, sequential, CAS latency 2.5 WM32 0x80000104 0xF15F0F02 ;SDRAM Control: precharge all WM32 0x80000104 0xF15F0F04 ;SDRAM Control: refresh WM32 0x80000100 0x018D0000 ;SDRAM Mode, normal DLL operation WM32 0x80000104 0x715F0F00 ;SDRAM Control, lock Mode register ; define maximal transfer size TSZ4 0xFF800000 0xFFFFFFFF ;ROM space TSZ4 0xF0000000 0xF0003FFF ;internal registers ; ; define the valid memory map MMAP 0x00000000 0x03FFFFFF ;Memory range for SDRAM MMAP 0xF0000000 0xF0003FFF ;Memory map for Internal Register MMAP 0xF0008000 0xF000BFFF ;Memory map for On-chip SRAM MMAP 0xFF800000 0xFFFFFFFF ;ROM space [TARGET] CPUTYPE 5200 ;the CPU type JTAGCLOCK 0 ;use 16 MHz JTAG clock BREAK HARD ;SOFT or HARD, HARD uses PPC hardware breakpoint POWERUP 500 ;start delay after power-up detected in ms BOOTADDR 0xFFF00100 ;Boot High MMU XLAT DCACHE NOFLUSH [FLASH] CHIPTYPE AM29F ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16) CHIPSIZE 0x800000 ;The size of one flash chip in bytes BUSWIDTH 8 ;The width of the flash memory bus in bits (8 | 16 | 32) WORKSPACE 0xF0008000 ;workspace in internal SRAM FILE u-boot.bin FORMAT BIN 0xFF800000 ERASE 0xFF800000 ;erase sector 0 ERASE 0xFF810000 ;erase sector 1 ERASE 0xFF820000 ;erase sector 2

2 2

[U-Boot-Users] Flash write problem on CSB226
by Rolf Peukert 10 Feb '04

10 Feb '04

Hi, we have installed U-boot on a CSB226 board with a PXA255 CPU and a bank of 2 Intel 28F128J3 flash chips (8M x 16bit each). There appeared to be a problem with the flash write function. It would stop after a few words, claiming "flash not erased". Closer inspection revealed, only one of the flashes was in read mode, the other was still in status mode. So I suspected the write_buff function in boards/csb226/flash.c (which wrote the two chips sequentially as two 16-bit words) and modified it to access both chips in parallel as 32 bit (the flash_erase function already works this way). The flash write problem seems to be gone now. Did anyone else experience such problems, or is just our board equipped with particularly unequal or pernickety flash chips? In the attached patch, the old functions are just #ifdef'd out and could be easily reactivated. There's one more thing I'm unsure about: Which is the right place to set the CPU clock? In boards/csb226/memsetup.S it is set to a default value. In cpu/pxa/start.S it is set to the configured CFG_CPUSPEED value, but memsetup is called after this. Regards, Rolf

3 3

Re: [U-Boot-Users] SystemACE support for u-boot via fat
by Stephen Williams 10 Feb '04

10 Feb '04

Wolfgang Denk wd-at-denx.de |u-boot-users| wrote: > In message <27598-21055(a)sneakemail.com> you wrote: > >>I've made a patch relative the current CVS (at sourceforge) >>that adds support for a Xilinx SystemACE chip directly >>attached to the PPC. (Well, conceivably any CPU type.) >> >>I've made the bundle of diffs and new files available for >>ftp download here: > > > It doesn't work this way. Please you submit your patches to the list > (or to me). > > Best regards, > > Wolfgang Denk > I hope this survives all the mailers. This is the patch itself. The new files in the next messages. Changelog here: * Add support for Xilinx SystemACE chip: New file common/cmd_ace.c New file include/systemace.h Hook systemace support into cmd_fat and the partition manager. ? disk/.depend Index: common/Makefile =================================================================== RCS file: /cvsroot/u-boot/u-boot/common/Makefile,v retrieving revision 1.14 diff -p -u -r1.14 Makefile --- common/Makefile 6 Jan 2004 22:38:21 -0000 1.14 +++ common/Makefile 5 Feb 2004 02:29:51 -0000 @@ -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 \ Index: common/cmd_fat.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/common/cmd_fat.c,v retrieving revision 1.7 diff -p -u -r1.7 cmd_fat.c --- common/cmd_fat.c 15 Oct 2003 23:53:50 -0000 1.7 +++ common/cmd_fat.c 5 Feb 2004 02:29:51 -0000 @@ -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; } Index: disk/part.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/disk/part.c,v retrieving revision 1.6 diff -p -u -r1.6 part.c --- disk/part.c 3 Jan 2004 19:43:49 -0000 1.6 +++ disk/part.c 5 Feb 2004 02:29:51 -0000 @@ -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) || \ Index: disk/part_dos.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/disk/part_dos.c,v retrieving revision 1.6 diff -p -u -r1.6 part_dos.c --- disk/part_dos.c 10 Sep 2003 22:30:55 -0000 1.6 +++ disk/part_dos.c 5 Feb 2004 02:29:52 -0000 @@ -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 */ -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."

2 1

[U-Boot-Users] usb.c patch
by Laurent Mohin 10 Feb '04

10 Feb '04

Hello, Please find a little patch which corrects a buffer overflow in usb.c Best regards CHANGELOG: Patch by Laurent MOHIN, 05 Feb 2004 - common/usb.c: buffer overflow correction --- work/u-boot-1.0.0/common/usb.c Thu Sep 18 11:21:35 2003 +++ work-lm/u-boot-1.0.0/common/usb.c Thu Feb 5 17:07:38 2004 @@ -46,6 +46,7 @@ #include <405gp_pci.h> #endif +#define BUFFER_MAX_SIZE 512 #undef USB_DEBUG @@ -386,7 +387,12 @@ return -1; } tmp=swap_16(config->wTotalLength); - + + if (tmp > BUFFER_MAX_SIZE) { + USB_PRINTF("usb_get_configuration_no: failed to get descriptor - length too long %d\n",tmp); + return -1; + } + result = usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, buffer, tmp); USB_PRINTF("get_conf_no %d Result %d, wLength %d\n",cfgno,result,tmp); return result; @@ -516,8 +522,8 @@ */ int usb_string(struct usb_device *dev, int index, char *buf, size_t size) { - - unsigned char mybuf[256]; + + unsigned char mybuf[BUFFER_MAX_SIZE]; unsigned char *tbuf; int err; unsigned int u, idx; @@ -550,9 +556,15 @@ if (err < 0) return err; u=tbuf[0]; USB_PRINTF("Strn Len %d, index %d\n",u,index); + + if (u > BUFFER_MAX_SIZE) { + USB_PRINTF("usb_string : failed to get string - length too long %d\n",u); + return -1; + } + err = usb_get_string(dev, dev->string_langid, index, tbuf, u); @@ -619,8 +631,8 @@ { int addr, err; int tmp; - unsigned char tmpbuf[256]; - + unsigned char tmpbuf[BUFFER_MAX_SIZE]; + dev->descriptor.bMaxPacketSize0 = 8; /* Start off at 8 bytes */ dev->maxpacketsize = 0; /* Default to 8 byte max packet size */ dev->epmaxpacketin [0] = 8; @@ -895,7 +907,7 @@ int usb_hub_configure(struct usb_device *dev) { - unsigned char buffer[256], *bitmap; + unsigned char buffer[BUFFER_MAX_SIZE], *bitmap; struct usb_hub_descriptor *descriptor; struct usb_hub_status *hubsts; int i; @@ -912,7 +924,13 @@ return -1; } descriptor = (struct usb_hub_descriptor *)buffer; - if (usb_get_hub_descriptor(dev, buffer, descriptor->bLength) < 0) { + + if (descriptor->bLength > BUFFER_MAX_SIZE) { + USB_HUB_PRINTF("usb_hub_configure: failed to get hub descriptor - length too long %d\n",descriptor->bLength); + return -1; + } + + if (usb_get_hub_descriptor(dev, buffer, descriptor->bLength) < 0) { USB_HUB_PRINTF("usb_hub_configure: failed to get hub descriptor 2nd giving up %lX\n",dev->status); return -1; } @@ -968,7 +986,13 @@ for (i = 0; i < dev->maxchild; i++) USB_HUB_PRINTF("port %d is%s removable\n", i + 1, hub->desc.DeviceRemovable[(i + 1)/8] & (1 << ((i + 1)%8)) ? " not" : ""); - if (usb_get_hub_status(dev, buffer) < 0) { + + if (sizeof(struct usb_hub_status) > BUFFER_MAX_SIZE) { + USB_HUB_PRINTF("usb_hub_configure: failed to get Status - length too long %d\n",descriptor->bLength); + return -1; + } + + if (usb_get_hub_status(dev, buffer) < 0) { USB_HUB_PRINTF("usb_hub_configure: failed to get Status %lX\n",dev->status); return -1; }

2 1

[U-Boot-Users] [PATCH] bug fixes for fat.h
by Zhang, Jian 10 Feb '04

10 Feb '04

This patch fixed two bugs found in fat.h. It is a diff with U-Boot-1.0.0 (10/29/2003). 1. The number of FAT12 entries in FAT12 buffer was calculated incorrectly. As a result, you are not able to read any big file using more 2048 FAT12 entries. 2. data_begin in fsdata struct can be negative depending on the FAT system layout. If it happens, wrong sectors are requested by fat code. Best Regards, Jian Zhang

2 1

[U-Boot-Users] [PATCH] 7/7 Common: DS1306 with external SPI transfer
by Stephan Linz 09 Feb '04

09 Feb '04

------------------ THIS IS PATCH 7/7 ------------------ * Patch by Stephan Linz, 01 Feb 2004 - Add support for the common U-Boot SPI framework at RTC driver DS1306

2 1

[U-Boot-Users] [PATCH] 6/7 Nios: Nios SPI Master support
by Stephan Linz 09 Feb '04

09 Feb '04

------------------ THIS IS PATCH 6/7 ------------------ * Patch by Stephan Linz, 01 Feb 2004 - Add support for the Nios Serial Peripharel Interface (SPI) (master only)

2 1

[U-Boot-Users] [PATCH] 5/7 Nios: new documentation for DK1S10
by Stephan Linz 09 Feb '04

09 Feb '04

------------------ THIS IS PATCH 5/7 ------------------ * Patch by Stephan Linz, 30 Jan 2004 - Add documentation for the Altera Nios Development Kit, Stratix Edition (DK-1S10)

2 1

[U-Boot-Users] [PATCH] 3/7 Nios: split board configuration of DK1S10
by Stephan Linz 09 Feb '04

09 Feb '04

------------------ THIS IS PATCH 3/7 ------------------ * Patch by Stephan Linz, 30 Jan 2004 - split DK1S10 configuration into several header files: o two new files for each NIOS CPU description o U-Boot related part is remaining in DK1S10.h

2 1

[U-Boot-Users] [PATCH] 2/7 Nios: split board configuration of DK1C20
by Stephan Linz 09 Feb '04

09 Feb '04

------------------ THIS IS PATCH 2/7 ------------------ * Patch by Stephan Linz, 30 Jan 2004 - split DK1C20 configuration into several header files: o two new files for each NIOS CPU description o U-Boot related part is remaining in DK1C20.h

2 1

[U-Boot-Users] [PATCH] 1/7 Nios: bugfixes
by Stephan Linz 09 Feb '04

09 Feb '04

Hi all, Hi Scott, last week I've made some bugfixes, structure changes and expansion of the U-Boot NIOS port: 1/7 bugfixes 2/7 split board configuration of DK1C20 3/7 split board configuration of DK1S10 4/7 new CPU configuration / support at DK1S10 (Microtronix LDK 2.0) 5/7 new documentation for DK1S10 6/7 Nios SPI Master support 7/7 DS1306 with external SPI transfer These pathes are realy important for my upcoming new Nios board support. Scott, could you check-up the pathes at your DK1C20 board and note me and Wolfgang so we can put it into CVS ? -- thanks. Best Regards, Stephan Linz ------------------ THIS IS PATCH 1/7 ------------------ * Patch by Stephan Linz, 30 Jan 2004 - board/altera/common/flash.c:flash_erase(): o allow interrupts befor get_timer() call o check-up each erased sector and avoid unexpected timeouts - board/altera/common/sevenseg.c: o avoid 'unused' warning - board/altera/dk1c20/dk1c20.c:board_early_init_f(): - board/altera/dk1c20/dk1s10.c:board_early_init_f(): o enclose sevenseg_set() in cpp condition - makes the ASMI configuration of DK1C20 more conform to documentation - remove the ASMI configuration for DK1S10_standard_32 (never present) - fix some typed in mistakes in the NIOS documentation

2 1

[U-Boot-Users] [Patch] MPC5200 PSC Baud rate calculation
by Jonas Mark-r50740 09 Feb '04

09 Feb '04

Hello, attached is a patch against 1.0.2 (checked out 2004-01-14) that fixes a bug in MPC5200 PSC Baud rate calculation. The patch modifies cpu/mpc5xxx/serial.c. The problem was that not the proper rounding was applied which resulted in slightly off Baud rates. The formula to calculate the Baud rate is: Divider = (f_IPBI / 32) / Baudrate Hence, the formula using integer should be: Divider = (((f_IPBI + 16) / 32) + Baudrate/2) / Baudrate Regards Mark Jonas

2 1

[U-Boot-Users] [Patch] MPC5200 CFG_LOWBOOT incompatible with CFG_RAMBOOT
by Jonas Mark-r50740 09 Feb '04

09 Feb '04

Hello, attached is a patch against 1.0.2 (checked out 2004-01-14) that fixes a flaw in the MPC5200 startup code. The flaw is that the user is not informed that the CFG_LOWBOOT code is incompatible with the CFG_RAMBOOT option. The patch stops compilation with an #error message in case CFG_LOWBOOT and CFG_RAMBOOT are enabled both. The patch modifies cpu/mpc5xxx/start.S. Regards Mark Jonas

2 1

RE: [U-Boot-Users] RE: CFI conformant flash driver available
by Brad Kemp 09 Feb '04

09 Feb '04

Here is a patch to the cfi flash driver with all the current fixes. It contains support for x8/x16 bit mode, support for little endean implementations, improved throughput for parallel Intel implementations. All Intel implementation are now reporting no problems, there remains an issue with an AMD implementation. TODO: There may be room for performance improvements in the x8/x16 support. Other flash vendor support. Brad > -----Original Message----- > From: Wolfgang Denk [mailto:wd@denx.de] > Sent: Monday, February 09, 2004 11:31 AM > To: Sam Song > Cc: Brad Kemp; Ed Okerson; listmember(a)orkun.us; > u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] RE: CFI conformant flash driver available > > > Dear Sam, > > in message > <20040209022249.66473.qmail(a)web15214.mail.bjs.yahoo.com> you wrote: > > > > Do you really want to release the patch on > > It's not "released", just added to the top-of-tree version of the CVS. > > > u-boot?There are still on the way to test it on two or > > more devices.At least,it didn't work in 4x8bit mode on > > LITE_DW. > > Having the patch checked in on the CVS server gives us all a common > base to submit any further corrections or updates. > > > I'm looking forward to seeing your fixes. > > Best regards, > > Wolfgang Denk > > -- > See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440 > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de > Never put off until tomorrow what you can put off indefinitely. >

1 0

[U-Boot-Users] Multi Image
by Matias Sundman (AL/EAB) 09 Feb '04

09 Feb '04

Hi all, I am thinking of using the Multi Image format for our Linux Kernel + RootfileSystem. Now, I have noticed that the 'mkimage' image has a header which contains useful info, but I have not figured out how Linux gets hold of the RootFileSystem address in a Multi image...can someone describe how this is done? Regards // Matias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

2 1

Re: [U-Boot-Users] malloc problem
by Wolfgang Denk 09 Feb '04

09 Feb '04

In message <20040209045324.CD0D642FA7(a)denx.de> you wrote: > > I am porting PPCBoot 2.0.0 to the Xilinx ML300. I know > PPCBoot is deprecated in favor of U-Boot, but the nearest port > for our board was a PPCBoot port that I got from someone > who never submitted their changes. Shame on the unnamed third party! > Everything works fine until the call from board_init_r() in > lib_ppc/board.c to devices_init(). Then somewhere in devices_init() > there is a call to malloc() which never returns and overwrites > much of system memory. You can be pretty sure that the malloc() code is NOT the culprit for your problem. > Has anyone else had problems like this? I compared the > malloc code from U-Boot 1.0.0 to PPCBoot 2.0.0 and except > for spacing they look the same. I then built PPCBoot with > the dlmalloc.c from U-Boot and the problem is still there. It may be anything, but malloc is most certainly innocent here. Sorry, the information you provided is not sufficient for an educated guess, but here is a wild speculation - are you 100% sure that your SDRAM is working reliably? Best regards, Wolfgang Denk -- See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440 Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de To the systems programmer, users and applications serve only to provide a test load.

2 2

[U-Boot-Users] U boot scripting / stand alone program capabilities
by Gerrit Van de Velde 09 Feb '04

09 Feb '04

Dear U boot users, I've read the DULG manual about the U boot scripting capabilities and successfully run the hello_world.srec example, but now i want to replace the hello world program with one of my own programs. How can I compile my own program ? No info is available in the manuals I've read. I've already tried with the Makefile that's included with the examples and set ARCH to ppc and TOPDIR to ../u-boot/ (for config.mk) but that fails. (I am using the MPC5200 Lite - Icecube) Any pointers are welcome..

2 1

[U-Boot-Users] -- fix the ARM memory layout -- couple errors.
by Woodruff, Richard 09 Feb '04

09 Feb '04

Anders, After tracing though the code I found a couple bugs in the patch. I think I corrected them and included the version of start.S for the ARM925 which I am using. I now get the expected register dump (or alternative function I've defined). -- The 3 reserved words for abort info is carved out at the top of the stack (high addr). The converted macro's treated this info as if it were at the "bottom" of the stack by subtracting off CONFIG_STACKSIZE. This is not correct or consistent with the previous def's which happened just above. The CONFIG_STACKSIZE should not be used at all. It has little meaning at present, perhaps more with irq's are enabled. -- I noticed that get_bad_stack() actually was not correct for SWI's and would crash my board in an unexpected way. The reason is that the SWI enters the system in SVC mode and the get_bad_stack() macro assumes a banked SP (R13)...ie it destroys the SVC mode SP, then switches to SVC mode (its already there) and there it tries to write on the bad stack. I added a new macro to my build which I think fixed the problem (assuming the svc stack is good). -- the introduction of CFG_GBL_DATA_SIZE is sort of a hollow gesture. It is perhaps a good seg way, but at present doesn't do much other than waist some space. Lib_arm/board.c currently sets the global area to a stack allocated object which happens to be on the top of the stack as it's the first definition. Carving out space for it is just fine, however this space never used. ... It might be nice to have a separate section for this object which the loader could initialize at some other spot, say, sram...later perhaps. Other than those few bits everything else seems to be working. Thanks for the effort. Your work is forcing me to switch to the preferred memory setup. Regards/thanks, Richard W. -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Woodruff, Richard Sent: Monday, January 19, 2004 12:08 PM To: 'Anders Larsen' Cc: u-boot-users(a)lists.sourceforge.net Subject: RE: [U-Boot-Users] [PATCH] fix the ARM memory layout Anders, I just applied this patch to my ARM board, and it seems to mostly work. Prior to the memory change I would get stack dumps on aborts, since applying the patch I am unable to get on to print. Have you been able to generate one? I hook up the JTAG and do a little tracing... One other comment... I have some test code which does a crc32 over the rom portion of u-boot to help validate the image, this code used armboot_end. In your patch you removed that symbol. Bss_start seems to be an "almost" proper substitution. I say almost as an ALIGN 4 is done before it. If the cmd size ended on a byte or half word boundary this would mess up the crc32 from what I might expect...In practice it might be that GCC generates things such that it pads to this anyway). Adding another symbol is easy, just thought I'd point out that it "might" not be strictly equivalent the way you did it... 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 Anders Larsen Sent: Friday, January 09, 2004 5:14 AM To: Wolfgang Denk Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] [PATCH] fix the ARM memory layout Wolfgang Denk <wd(a)denx.de> schreibt: >In message <fc.004c4e48001e6497004c4e48001e6497.1e64ae(a)rea.de> you wrote: >> >> here's a fresh version of my rather intrusive patch from the 17.th sept. >> to rearrange the ARM memory layout to bring it in line with the README. > >Sorry, I'm working through my backlog sequentially, and I already >added the other patch. Can you please check your current version >against current top-of-tree in CVS and provide a new diff? Hi Wolfgang, the attached patch (against CVS 2004-01-08) fixes the rest of the ARM stuff I had in the pipe. In particular, the abort-stack is now set up in the correct RAM area (which I had neglected in my previous patches), and the BSS is zeroed out as it should be (which most previous ARM implementations had neglected). Furthermore, the magic variables 'armboot_end' and 'armboot_end_data' of the linker scripts are replaced by '__bss_start' and '_end', resp., which is a further step to eliminate unnecessary differences between the implementation of the CPU architectures. Compilation tested with MAKEALL arm, functionality only tested on my PXA-based board. CHANGELOG: Fix the ARM memory layout. Cheers Anders (Patch gzipped due to size constraints on the list) ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

3 4

[U-Boot-Users] malloc problem
by Mike Wellington 08 Feb '04

08 Feb '04

I am porting PPCBoot 2.0.0 to the Xilinx ML300. I know PPCBoot is deprecated in favor of U-Boot, but the nearest port for our board was a PPCBoot port that I got from someone who never submitted their changes. Everything works fine until the call from board_init_r() in lib_ppc/board.c to devices_init(). Then somewhere in devices_init() there is a call to malloc() which never returns and overwrites much of system memory. I put some printf's in the dlmalloc.c code to try to figure out what is going on. I am seeing some really large values for victim->size: 0x22fc0, 0x22cb0, 0x7ff2cd0, 0x3d747478, 0x626f6f74 these are strange values for victim->size because TOTAL_MALLOC_LEN is only 0x20000. How can the remaining size for an allocation victim be larger than the total amount of heap space? When I go and look at memory it looks like it has been overwritten by the runaway malloc routine. Memory is overwritten by a sequence of incrementing values. Has anyone else had problems like this? I compared the malloc code from U-Boot 1.0.0 to PPCBoot 2.0.0 and except for spacing they look the same. I then built PPCBoot with the dlmalloc.c from U-Boot and the problem is still there. ---- mike wellington be_a_fanatic(a)yahoo.com mike(a)lo-ex.com wellington(a)lucent.com 720.434.7559

1 0

[U-Boot-Users] Patch for NAND Booting on SMDK2410
by Markus Pietrek 08 Feb '04

08 Feb '04

Hi folks, here is a patch to enable U-Boot 1.0 to boot from NAND/SmartMedia cards. smdk2410.h must include the line '#define CONFIG_BOOT_NAND 1" and the resulting u-boot.bin must be copied to the first SmartMedia sectors (with a JTAG tool for example). The first sector of the SmartMedia card should also be marked as "Defect". With J33 and J34 closed the board should then boot from SmartMedia. This first version is very simple as U-Boot is linear on the SmartMedia and don't allows a filesystem. Later version may include placing U-Boot on a filesystem. This patch also includes code for clearing the BSS segment. This is not the same code Larsen submitted this morning :-( Bye, -- Markus Pietrek FS Forth-Systeme GmbH Phone: +49 (7667) 908 145, FAX +49 (7667) 908 221

4 5