October 2004 - U-Boot

RE: [U-Boot-Users] BDI2000 flashing problem
by VanBaren, Gerald (AGRE) 19 Oct '04

19 Oct '04

You need a valid hardware reset configuration word (HRCW) for the processor to come up enough to flash (the CPU PLL clock settings are controlled by the HRCW). The HRCW lives in the first 32 bytes of flash and gets read when power is applied: if you erase all of flash, you will erase your HRCW. This is OK as long as you reprogram it before you cycle power. Ooops, too late ;-) You should have a "RSTCONF*" (reset configuration) jumper/switch connected to the RSTCONF on the processor. When asserted (low), this causes the processor to use a default HRCW which will allow you to reprogram the desired HRCW in flash. Since you have a Mot board, it may have a BCSR-supplied HRCW, check your documentation. The bottom line is, you need a reasonable HRCW (in particular a reasonable clock setting in the HRCW) in order for the processor to be operational enough for JTAG to work. gvb > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf > Of Santoso, Yusdi > Sent: Tuesday, October 19, 2004 12:47 AM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] BDI2000 flashing problem > > Hi all, > > I have a problem using BDI2000 to flash u-boot into my board. > I had it working yesterday, but this morning it just refused to work. > Does the BDI flashing require some boot loader code to be > already available in the flash? > > Thanks, > > > Yusdi ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0

[U-Boot-Users] memory map
by jhoney jhoney 19 Oct '04

19 Oct '04

Hello All, I am new to U-boot. I have one board with u-boot and inturn passes control to Linux . I got a question like whatever the memory map initialization done by the u-boot will be carried out to the linux up on boot up. For example , in my case u-boot configures pci at E0000000 and whatever the data is sent to the address E0000000 is passed to the PCI interface. Up on booting the linux, whether the same address will be mapped to the pci or Linux does the re-initialization again. Thanks in advance Regards Jhoney

1 0

[U-Boot-Users] BDI2000 flashing problem
by Santoso, Yusdi 19 Oct '04

19 Oct '04

Hi all, I have a problem using BDI2000 to flash u-boot into my board. I had it working yesterday, but this morning it just refused to work. Does the BDI flashing require some boot loader code to be already available in the flash? Thanks, Yusdi The BDI telnet log: // Board: Motorola Hidden Dragon, quite similar to Sandpoint // Processor: MPC8241 // Memory: start = 0x00000000 // size = 32 MB // Flash: start = 0xff800000 // size = 2 MB = 1 bank x 16 bits x 1 M // Initialization message - TARGET: waiting for target Vcc - TARGET: waiting for target Vcc - TARGET: processing power-up delay - TARGET: processing user reset request - BDI asserts HRESET - Reset JTAG controller passed - Bypass check: 0x000000001 => 0x00FFFFFF - JTAG exists check failed - Remove HRESET and try again - Bypass check: 0x000000001 => 0x00000001 - JTAG exists check passed - COP status is 0x01 - Check running state passed - BDI scans COP freeze command - BDI removes HRESET - Target PVR is 0x80811014 - COP status is 0x05 - Check stopped state passed - Check LSRL length passed - BDI resumes program execution - COP status is 0x01 - Waiting for target stop failed // Flash is still blank (0xffff) - TARGET: Break at boot vector failed, freeze forced - TARGET: Target PVR is 0x80811014 - TARGET: resetting target passed - TARGET: processing target startup .... - TARGET: processing target startup passed BDI>info Target CPU : MPC82xx (G2H4) Target state : debug mode Debug entry cause : COP freeze (startup) // The reset vector is at 0xfff00100, seems like the processor has executed few bytes // but not sure why stop here. Current PC : 0xfff00800 Current CR : 0x00000000 Current MSR : 0x00000000 Current LR : 0x00000000 BDI>md 0xfff00000 fff00000 : ffffffff ffffffff ffffffff ffffffff ................ fff00010 : ffffffff ffffffff ffffffff ffffffff ................ fff00020 : ffffffff ffffffff ffffffff ffffffff ................ fff00030 : ffffffff ffffffff ffffffff ffffffff ................ fff00040 : ffffffff ffffffff ffffffff ffffffff ................ fff00050 : ffffffff ffffffff ffffffff ffffffff ................ fff00060 : ffffffff ffffffff ffffffff ffffffff ................ fff00070 : ffffffff ffffffff ffffffff ffffffff ................ fff00080 : ffffffff ffffffff ffffffff ffffffff ................ fff00090 : ffffffff ffffffff ffffffff ffffffff ................ fff000a0 : ffffffff ffffffff ffffffff ffffffff ................ fff000b0 : ffffffff ffffffff ffffffff ffffffff ................ fff000c0 : ffffffff ffffffff ffffffff ffffffff ................ fff000d0 : ffffffff ffffffff ffffffff ffffffff ................ fff000e0 : ffffffff ffffffff ffffffff ffffffff ................ fff000f0 : ffffffff ffffffff ffffffff ffffffff ................ // Erasing flash is ok BDI>erase 0xff800000 CHIP Erasing flash at 0xff800000 Erasing flash passed // Program a 65 bytes binary file, failed BDI>prog 0xfff00000 /tftpboot/dummy.bin BIN Programming /tftpboot/dummy.bin , please wait .... # Programming flash memory failed at 0x00000000 // Programming u-boot binary file, failed BDI>prog 0xfff00000 /tftpboot/u-boot.bin BIN Programming /tftpboot/u-boot.bin , please wait .... # Programming flash memory failed at 0x00000000 // Content of RAM at 0x00000000 BDI>md 0x00000000 00000000 : 7ebbfaa6 7e19faae 7c55f2a6 5214a5fe ~...~...|U..R... 00000010 : 7f36f2b6 7d192eae 5e75a43e 7e5cfea6 .6..}...^u.>~\.. 00000020 : 7e77f2a6 7e92c6a6 7eab3aa6 7eddcaa6 ~w..~...~.:.~... 00000030 : 7ef9f2a6 7f13ceae 7fbf5aa6 7f514ea6 ~.........Z..QN. 00000040 : 7f7b4ab6 7f934eae 7fa67526 7fdbdaa6 .{J...N...u&.... 00000050 : 7ffab2a6 bee57f8e 7c5db5bd b882fd49 ........|].....I 00000060 : 7df77d35 6488dcee 7fff7329 60447656 }.}5d.....s)`DvV 00000070 : 6befa062 abababab bbababab abababab k..b............ 00000080 : ebbbabab abababab abababab abababab ................ 00000090 : abebabab abababab abbbabab abababab ................ 000000a0 : bbbbbbab ab88c6ab ed7330ab cd43c9ab .........s0..C.. 000000b0 : edf973ab cd20fdab edbbd2ab cd82bfab ..s.. .......... 000000c0 : cd55adab cdc7cfab eded51ab cd00ddab .U........Q..... 000000d0 : edbf65ab cd8047ab edba9dab cd285eab ..e...G......(^. 000000e0 : edbaf4ab cd406eab cdd6f5ab cdc4adab .....@n......... 000000f0 : edd9bbab cd02fbab fdf422ab cd4577ab .........."..Ew // Load a 65 bytes file to RAM, failed BDI>load 0x00000000 /tftpboot/dummy.bin BIN Loading /tftpboot/dummy.bin , please wait .... # PPC: timeout while waiting for freeze // Load a 63 bytes file to RAM, ok BDI>load 0x00000000 /tftpboot/dummy.bin BIN Loading /tftpboot/dummy.bin , please wait .... Loading program file passed // The content of the file is 0x00 BDI>md 0x00000000 00000000 : 00000000 00000000 00000000 00000000 ................ 00000010 : 00000000 00000000 00000000 00000000 ................ 00000020 : 00000000 00000000 00000000 00000000 ................ 00000030 : 00000000 00000000 00000000 000000a6 ................ 00000040 : 7f7b4ab6 7f934eae 7fa67526 7fdbdaa6 .{J...N...u&.... 00000050 : 7ffab2a6 bee57f8e 7c5db5bd b882fd49 ........|].....I 00000060 : 7df77d35 6488dcee 7fff7329 60447656 }.}5d.....s)`DvV 00000070 : 6befa062 abababab bbababab abababab k..b............ 00000080 : ebbbabab abababab abababab abababab ................ 00000090 : abebabab abababab abbbabab abababab ................ 000000a0 : bbbbbbab ab88c6ab ed7330ab cd43c9ab .........s0..C.. 000000b0 : edf973ab cd20fdab edbbd2ab cd82bfab ..s.. .......... 000000c0 : cd55adab cdc7cfab eded51ab cd00ddab .U........Q..... 000000d0 : edbf65ab cd8047ab edba9dab cd285eab ..e...G......(^. 000000e0 : edbaf4ab cd406eab cdd6f5ab cdc4adab .....@n......... 000000f0 : edd9bbab cd02fbab fdf422ab cd4577ab .........."..Ew // But modifying the RAM address manually is fine BDI>mmb 0x00000000 0xaa 100 //-------------------------------------------------------------- // GDB: no u-boot loaded yet, so I don't think this make any sense //-------------------------------------------------------------- /home/test> ${CROSS_COMPILE}gdb u-boot GNU gdb Yellow Dog Linux (5.2.1-4b_4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux"... (gdb) target remote 192.168.0.5:2001 Remote debugging using 192.168.0.5:2001 FPUnavailable () at /home/yusdi/project/u-boot/cpu/mpc824x/start.S:254 254 STD_EXCEPTION(EXC_OFF_FPUNAVAIL, FPUnavailable, UnknownException) (gdb) ----------------------------------------------------------------- hdragon.cfg: based on Sandpoint 8240 with some modification for memory settings ----------------------------------------------------------------- ;bdiGDB configuration file for Sandpoint 8240 evaluation system ;-------------------------------------------------------------- ; [INIT] ; init core register WREG MSR 0x00000000 ;clear MSR ; init memory controller (based on DINK32) WM32 0xFEC00000 0x80000080 ;select MSAR1 WM32 0xFEE00000 0x00204060 ; WM32 0xFEC00000 0x84000080 ;select MSAR2 WM32 0xFEE00000 0x80a0c0e0 ; WM32 0xFEC00000 0x90000080 ;select MEAR1 WM32 0xFEE00000 0x1f3f5f7f ; WM32 0xFEC00000 0x94000080 ;select MEAR2 WM32 0xFEE00000 0x9fbfdfff ; WM32 0xFEC00000 0xa0000080 ;select MBEN WM8 0xFEE00000 0x03 ; WM32 0xFEC00000 0xa0000080 ;select MPM WM8 0xFEE00003 0x32 ; WM32 0xFEC00000 0xf0000080 ;select MCCR1 WM32 0xFEE00000 0x00006088 ;do not set MEMGO WM32 0xFEC00000 0xf4000080 ;select MCCR2 WM32 0xFEE00000 0x3c020000 ; WM32 0xFEC00000 0xf8000080 ;select MCCR3 WM32 0xFEE00000 0x00004078 ; WM32 0xFEC00000 0xfc000080 ;select MCCR4 WM32 0xFEE00000 0x39323035 ; WM32 0xFEC00000 0xf0000080 ;select MCCR1 WM32 0xFEE00000 0x00006888 ;now set MEMGO ; WM32 0xFEC00000 0x78000080 ;select EUMBBAR WM32 0xFEE00000 0x000000fc ;Embedded utility memory block at 0xFC000000 ; WM32 0xFEC00000 0xa8000080 ;select PICR1 WM32 0xFEE00000 0x901014ff ;enable flash write (Flash on processor bus) ; ; Added to use the high drive strength for the memory selects & addressing ;WM32 0xFEC00000 0x70000080 ; select ODCR ;WM8 0xFEE00003 0xff ; high drive for everything ; ; Added to toggle the DLL_RESET bit WM32 0xFEC00000 0xe0000080 ; select AMBOR WM8 0xFEE00000 0xe0 ; DLL_RESET on WM32 0xFEC00000 0xe0000080 ; select AMBOR WM8 0xFEE00000 0xc0 ; DLL_RESET off ; ; define maximal transfer size ;TSZ1 0xFF800000 0xFFFFFFFF ;ROM space (only for PCI boot ROM) TSZ4 0xFF800000 0xFFFFFFFF ;ROM space (only for Local bus flash) [TARGET] CPUTYPE 8240 ;the CPU type (603EV,750,8240,8260) JTAGCLOCK 0 ;use 16 MHz JTAG clock WORKSPACE 0x00000000 ;workspace in target RAM for fast download BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT | GATEWAY) BREAKMODE SOFT ;SOFT or HARD, HARD uses PPC hardware breakpoint VECTOR CATCH ;catch unhandled exceptions DCACHE NOFLUSH ;data cache flushing (FLUSH | NOFLUSH) STARTUP RESET [HOST] IP 192.168.0.1 ;FILE E:\cygnus\root\usr\demo\sp8240\vxworks FORMAT ELF LOAD MANUAL ;load code MANUAL or AUTO after reset DEBUGPORT 2001 [FLASH] ; Chip = 29LV160TE ; Size = 1x16 bitsx1M ; Am29LV800BB on local processor bus (RCS0) ; set PPMC8240 switch SW2-1 OFF => ROM on Local bus ; enable flash write in PICR1 (see INIT part) ; set maximal transfer size to 4 bytes (see INIT part) CHIPTYPE AM29BX8 ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16) CHIPSIZE 0x200000 ;The size of one flash chip in bytes (e.g. Am29LV800BB = 0x100000) BUSWIDTH 8 ;The width of the flash memory bus in bits (8 | 16 | 32 | 64) WORKSPACE 0x00000000 ;workspace in SDRAM FILE /tftpboot/u-boot.bin ;The file to program ERASE 0xFFF00000 ;erase sector 0 of flash ERASE 0xFFF04000 ;erase sector 1 of flash ERASE 0xFFF06000 ;erase sector 2 of flash ERASE 0xFFF08000 ;erase sector 3 of flash ERASE 0xFFF10000 ;erase sector 4 of flash ERASE 0xFFF20000 ;erase sector 5 of flash ERASE 0xFFF30000 ;erase sector 6 of flash ERASE 0xFFF40000 ;erase sector 7 of flash ERASE 0xFFF50000 ;erase sector 8 of flash ERASE 0xFFF60000 ;erase sector 9 of flash ERASE 0xFFF70000 ;erase sector 10 of flash [REGS] DMM1 0xFC000000 ;Embedded utility memory base address IMM1 0xFEC00000 0xFEE00000 ;configuration registers at byte offset 0 IMM2 0xFEC00000 0xFEE00001 ;configuration registers at byte offset 1 IMM3 0xFEC00000 0xFEE00002 ;configuration registers at byte offset 2 IMM4 0xFEC00000 0xFEE00003 ;configuration registers at byte offset 3 FILE /tftpboot/reg8240.def

1 0

[U-Boot-Users] Re: [U-Boot-CVS] Board port
by Detlev Zundel 19 Oct '04

19 Oct '04

Hi Steven, > I did a u-boot port of the Embedded Planet EP8248. Can someone tell me > where I should send the patch? First off to u-boot-users@ instead of u-boot-cvs(a)lists.sourceforge.net. This list is basically only for the automated cvs notifications. Answer crossposted and f'upto set to u-boot-users. Cheers Detlev -- The structure of a system reflects the structure of the organization that built it. -- Richard E. Fairley

1 0

RE: [U-Boot-Users] USB Console
by Woodruff, Richard 19 Oct '04

19 Oct '04

Here is the write up we used to do this for USB serial with a 1510. You should disregard the 'setslink' comments below. Someone at TI originally had it working in a u-boot variant here. Wolfgang implemented a slightly different version for the SX1. Hope this helps more than confuses. Regards, Richard W. ---------------------------------------------- Software configuration ====================== Host side --------- On the PC host side, you need to configure the kernel to support USB serial devices. Assuming you are using "make menuconfig" or "make xconfig", go to "USB Support" section and enable the options as follows ("M" means "enable as a loadable module"): If, and only if, "Support for USB is set to <N>, then: - Support for USB <M> Also enable the /proc filesystem for USB: - Preliminary USB device filesystem <Y> Then choose a driver for your USB controller and enable it as module, i.e. exactly one of the following: - UHCI (Intel PIIX4, VIA, ...) support <M> or - OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support <M> Then go to "USB Serial Converter support" subsection and enable: - USB Serial Converter support <M> - USB Generic Serial Driver <Y> Next, recompile the kernel and install kernel itself and modules as usual. NOTE: You may want to replace your existing copy of usbserial.c with the version from cvs. This version is fixed to prevent a common segfault. You can find the updated source file at PET/src/os/linux/drivers/usb/serial/usbserial.c. After this, make sure you have the following modules installed: * usbcore.o - the core of host USB subsystem (if "USB Support" above was <Y>, this isn't needed) * [host controller driver].o - driver for the host USB controller * usbserial.o - host-side serial function driver For example, if you are using UHCI host controller and the kernel modules are placed in their default locations, type: find /lib/modules/`uname -r`/kernel/drivers/usb -type f at the shell prompt. You should see something like this: /lib/modules/2.4.19/kernel/drivers/usb/usb-uhci.o /lib/modules/2.4.19/kernel/drivers/usb/serial/usbserial.o If this is true, host configuration is completed. Kermit ------ If you don't already have kermit installed on your linux host machine, do the following: Update your cvs PET/src/os/tools/ directory. Go into PET/src/os/tools/ckermit and run 'make linux' and 'make install'. Now, when you type 'which kermit' you should see '/usr/local/bin/kermit'. This is the program that minicom will run when doing uploads to your device. Copy the file u-boot.kermrc from the PET/src/os/tools/ckermit directory into your home directory. RENAME THIS FILE TO .kermrc. This file contains important setup commands to initialize kermit. Minicom ------- To communicate with the TTY client, you'll need to create a minicom configuration which uses /dev/ttyUSB0. Run minicom, as root, with the -s option and do the following: - Type <Control-A> O (letter o) to get into the configuration menu. - Choose "Filenames and paths". Change the value of "E - Kermit program" to the location of kermit on your host system. 'which kermit' will give you the correct path to use here. Press enter to go back to the previous screen. - Choose "File transfer protocols". You shuld have 2 entries for kermit. Modify the first (has U in the U/D column) so that the "Program" column has the following value: "kermit -i -l %f -s". - Choose "Serial Port Setup". Now change the value of "A - Serial Device" to be /dev/ttyUSB0. - Now press enter to go back to the previous screen and select "Save setup as...". Save this setup as usb. - Exit from minicom. OMAP1510 client side -------------------- On the 1510 client side, you need to configure the kernel to get the latest version of u-boot out of cvs. Build u-boot as usual. Make sure you have a USB "A to mini-B" cable. That's a normal sized host connector on one end and a mini-sized client connector on the other end. Client end goes into the device. Running ======= Setting up TTY-over-USB connectivity --------------------------------------- On the host side, you need to load kernel modules, exactly in the following order, by typing: insmod [host controller driver] insmod usbserial vendor=0x0451 product=0xe003 Then re-plug the USB cable and examine log files (usually somewhere in /var/log, check your /etc/syslog.conf) on the host system. You should see something like the following (date and host name fields are skipped): kernel: hub.c: USB new device connect on bus1/1, assigned device number 9 kernel: usb.c: kmalloc IF c0f74ec0, numif 1 kernel: usb.c: new device strings: Mfr=1, Product=2, SerialNumber=0 kernel: usb.c: USB device number 9 default language ID 0x4e3e kernel: Manufacturer: Texas Instruments kernel: Product: TI PET Bootloader kernel: usbserial.c: Generic converter detected kernel: usbserial.c: Generic converter now attached to ttyUSB0 (or usb/tts/0 for devfs) kernel: usb.c: serial driver claimed interface c0f74ec0 Now you can run minicom with your usb configuration: 'minicom usb'. You should see the first few lines of your u-boot console. Downloading to the device ------------------------- With the modules loaded on the host machine as explained above, set up u-boot for USB downloads using kermit. - At the u-boot prompt type 'setslink usbtty'. This will select the usbtty device as your download link. - Now type 'loadb'. This will pause, waiting for data to be sent from the host. - Now type <Control-A> S in minicom to bring up the "Upload" menu. Choose "kermit" as the upload protocol. Select the file you wish to transfer and then choose "Okay" (notice menu buttons at bottom of screen, you can use the arrow keys to move between these). You should see a kermit upload progress window. When the transfer has completed, u-boot should display a download summary showing the number of bytes transferred. If you don't want to use minicom for a USB TTY device, but still want to be able to use the USB cable to upload files to the device, you can run kermit by hand. - From a serial minicom console, run 'setslink usbtty' to ensure that u-boot uses USB for downloads. - Now set your device in kermit download mode by typing 'loadb'. - Make sure that your USB cable is connected and then run 'kermit -i -l /dev/ttyUSB0 -s fileName' where fileName is the file that you wish to upload to the device. > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users- > admin(a)lists.sourceforge.net] On Behalf Of Jayme Hero > Sent: Monday, October 18, 2004 2:54 PM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] USB Console > > Hi > > I am using U-Boot and want to use the USB console. I am have an OMAP1510 > and > am connecting it as a device to a PC running Suse 9. Linux recognizes that > something has been connected to the USB port, but it loads the acm diver, > starts a modem configuration utility, and I think it sets the device and > /dev/acm0. I cannot connect to this with kermit. How do I need to setup > my > computer to get a console over USB? > Thanks for any help > > jeh > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

[U-Boot-Users] USB Console
by Jayme Hero 18 Oct '04

18 Oct '04

Hi I am using U-Boot and want to use the USB console. I am have an OMAP1510 and am connecting it as a device to a PC running Suse 9. Linux recognizes that something has been connected to the USB port, but it loads the acm diver, starts a modem configuration utility, and I think it sets the device and /dev/acm0. I cannot connect to this with kermit. How do I need to setup my computer to get a console over USB? Thanks for any help jeh

2 1

[U-Boot-Users] PATCH SoC AT91RM9200
by Steven Scholz 18 Oct '04

18 Oct '04

Hallo Herr Denk, CHANGELOG: * Patch by Steven Scholz, 18 Oct 2004: - Move at91rm9200 relevant code into cpu/arm920t/at91rm9200 - Fix linker scripts for AT91RM9200 based boards - If $SOC is passed to ./mkconfig create include/asm-$ARCH/arch-$SOC instead of include/asm-$ARCH/arch-$CPU, so it looks more like the linux kernel tree - Move files out of include/asm-arm/arch-arm920t into appropriate include/asm-arm/arch-$SOC directories Danke. -- Steven Scholz imc Measurement & Control

1 0

[U-Boot-Users] PATCH SoC AT91RM9200
by Steven Scholz 18 Oct '04

18 Oct '04

Hi there, since Atmels AT91RM9200 is an System on a chip based on around an ARM920T core I moved the relevant code into cpu/arm920t/at91rm9200 so it follows the new SoC concept. Due to the size of the patch I'll send it directly to Wolfgang. Thanks. CHANGELOG: * Patch by Steven Scholz, 18 Oct 2004: - Move at91rm9200 relevant code into cpu/arm920t/at91rm9200 - Fix linker scripts for AT91RM9200 based boards - If $SOC is passed to ./mkconfig create include/asm-$ARCH/arch-$SOC instead of include/asm-$ARCH/arch-$CPU, so it looks more like the linux kernel tree - Move files out of include/asm-arm/arch-arm920t into appropriate include/asm-arm/arch-$SOC directories Thanks! -- Steven Scholz imc Measurement & Control

1 0

RE: [U-Boot-Users] TFTP configuration Vs gdb response time !
by VanBaren, Gerald (AGRE) 18 Oct '04

18 Oct '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf > Of George G. Davis > Sent: Saturday, October 16, 2004 11:26 AM > To: ravi.aloor(a)wipro.com > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] TFTP configuration Vs gdb response time ! > > On Sat, Oct 16, 2004 at 07:56:41PM +0530, ravi.aloor(a)wipro.com wrote: > > 4. Now I already have BDI-new.cfg file in my /tftpboot/ > directory on my > > PC. I pinged BDI. Response is OK. Then I made 'telnet' to BDI. The > > following is the brief response. > > > > VERIFY [<offset>] [<file> [<format>]] verify a program file > to target > > memory > > PROG [<offset>] [<file> [<format>]] program flash memory > > <format> : SREC, BIN, AOUT, ELF or COFF > > ERASE [<address> [<mode>]] erase a flash memory sector, > chip or block > > <mode> : CHIP, BLOCK or SECTOR (default > is sector) > > ERASE <addr> <step> <count> erase multiple flash sectors > > UNLOCK <addr> <step> <count> unlock multiple flash sectors > > FLASH <type> <size> <bus> change flash configuration > > FENA <addr> <size> enable autoamtic programming to flash > > memory > > FDIS disable autoamtic programming to flash > > memory > > DELAY <ms> delay for a number of milliseconds > > SELECT <core> change the current core > > len : the number of bits 1..256 > > bx : a data byte, two hex digits > > HOST <ip> change IP address of program file host > > PROMPT <string> defines a new prompt string > > CONFIG display or update BDI configuration > > CONFIG <file> [<hostIP> [<bdiIP> [<gateway> [<mask>]]]] > > HELP display command list > > QUIT terminate the Telnet session > > > > # CONFIG: cannot open BDI-new.cfg > > # CONFIG: cannot open BDI-new.cfg > > Core#0> > > > > Means, it is not getting my BDI-new.cfg file even though > the file is in > > /tftpboot/ directory on my PC while my PC is working as > TFTP server. Why > > it is BDI is not able to read BDI-new.cfg ? > > Try: > > chmod a+r /tftpboot/BDI-new.cfg > > That should fix it assuming tftp is properly configured and > enabled on your > RH8 development host. > > -- > Regards, > George Other potential problem areas and checks: * Can you use tftp to read your BDI-new.cfg file from the tftp server (i.e. tftp localhost)? If so, you have your server basically functioning. Good. * Can you use tftp to read it from _another_ machine? If not, you have a permissions problem likely relating to firewalling (TFTP not allowed to the ethernet). * Depending on your tftp server setup, you may need /tftpboot/BDI-new.cfg or /BDI-new.cfg (the later configuration is strongly recommended). gvb ****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak: ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0

[U-Boot-Users] [PATCH] fix warnings in board/versatile/flash.c
by Steven Scholz 18 Oct '04

18 Oct '04

CHANGELOG: Fix typo and warning in board/versatile/flash.c -- Steven Index: u-boot.work/board/versatile/flash.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/board/versatile/flash.c,v retrieving revision 1.2 diff -u -r1.2 flash.c --- u-boot.work/board/versatile/flash.c 11 Oct 2004 22:51:13 -0000 1.2 +++ u-boot.work/board/versatile/flash.c 16 Oct 2004 19:29:39 -0000 @@ -239,7 +239,7 @@ info->flash_id += FLASH_28F256K3; info->sector_count = 256; info->size = 0x02000000; - printf ("\Intel StrataFlash 28F256K3C device initialized\n"); + printf ("Intel StrataFlash 28F256K3C device initialized\n"); break; default: @@ -477,7 +477,7 @@ /* Check if Flash is (sufficiently) erased */ if ((*addr & data) != data) { - printf ("not erased at %08lx (%x)\n", (ulong) addr, *addr); + printf ("not erased at %08lx (%lx)\n", (ulong) addr, *addr); return (2); }

2 2

[U-Boot-Users] U-boot compile issue with GCC 3.4
by Devraj Mukherjee 18 Oct '04

18 Oct '04

We are users of a Logic PD LH7A400 board. Currently using a Debian host we managed to make ourselves a GCC for arm (Version 3.4). Now when we compile U-Boot 1.1.1 patched for LH7A400 we get the following errors. If anyone can throw some light on them, we would appreciate that. cc1: error: invalid option `short-load-bytes' cc1: error: invalid option `short-load-bytes' make[1]: *** [.depend] Error 1 make[1]: Leaving directory `/home/devraj Dump from GCC 3.4 for arm --version devraj@raphaelle:~/lpd7a400/uboot/u-boot-1.1.1$ arm-linux-gcc --version arm-linux-gcc (GCC) 3.4.1 (Debian 3.4.1-1) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thanks in advance. Devraj

2 1

[U-Boot-Users] Those hello_world compilation problems
by Jon Loeliger 17 Oct '04

17 Oct '04

Folks, I did some digging on our toolchain here on our new Yellowdog 4.0 installed machines. They have a 3.3.2 compiler on them by default, apparently. As someone else discerned, that cause an issue with the dummy() function being static in the stubs.o file for the examples directory. I've found that all appears to be better if the test in the example/stubs.c file is changed from: #if GCC_VERSION < 3004 to #if GCC_VERSION < 3003 (BTW, the GCC_VERSION symbol, google revealed, comes from ansidecl.h. Oh yeah.) I'm not sure of the generality of this fix, so I am reluctant to submit a direct patch for it. Perhaps someone more familiar with the details of either the YDL 4.0 or GCC 3.3 vs 3.4 releases can speak authoritatively on this issue. HTH, jdl

3 3

RE: [U-Boot-Users] TFTP configuration Vs gdb response time !
by Woodruff, Richard 16 Oct '04

16 Oct '04

There is no support for GDB debugging for ARM u-boot. Most jtag debuggers are plenty good for that task anyway. With some work you can use kgdb for the kernel, and gdb for applications. Regards, Richard W. > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users- > admin(a)lists.sourceforge.net] On Behalf Of ravi.aloor(a)wipro.com > Sent: Saturday, October 16, 2004 9:27 AM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] TFTP configuration Vs gdb response time ! > > > Hi All, A brief explanation about my working environment: > - ARM11 based target board, having its own IP address > - My PC running on RedHat Linux-8.0, having its own IP address, > as host machine with only CLI and no GUI-XWindows > - BDI2000, having its own IP address > - PC and BDI2000 are connected to the network independently > - U-boot is already available on target board in the flash > memory > - Firmware is already available on BDI2000 > - BDI2000 is connected to the target board through > - Using gdb-6.1 configured with --target=arm-linux > - Documents referring: README, DULG, bdiGDB maual > - I am not using ELDK as explained in DLUG > - About our network: I am not sure > > I want to debug u-boot and also kernel with good response from gdb. The > following are my doubts. > > 1. I have TFTP server already configured on our network. But the > response time of gdb is too bad, while debugging. I will not come to > know what is happening also. > > So I thought I will make my PC only as TFTP server to get faster > response from gdb. This idea is right / wrong ? > If my idea is wrong, what could be the possible reason for gdb's slow > response ... ? My PC has PIII processor and 128MB RAM. Do you suggest to > increase RAM on my PC ? This anyway I planning to do. Does the response > time of gdb depend on network speed also ? > > 2. In gdbBDI manual, the explanation is given by directly connecting the > target board to the host machine with Ethernet cable. Serial cable > connection is only for initial configuration of BDI. But in my case, > both the target board and my PC are connected separately to the network. > Is it ok ? > > 3. I started to make my PC itself as TFTP server. I followed DLUG > document for this purpose and I configured BDI accordingly as shown > below: > > [root@localhost BDISetUp]# ./bdisetup -c -p/dev/ttyS0 -b115 > -i192.168.226.-h192.168.226.168 -m255.255.255.128 -g192.168.226.129 > -fBDI-new.cfg > Connecting to BDI loader > Writing network configuration > Configuration passed > [root@localhost BDISetUp]# ./bdisetup -v -p/dev/ttyS0 -b115 -s > BDI Type : BDI2000 Rev.C (SN: 95590442) > Loader : V1.05 > Firmware : V0.99 bdiGDB for ARM11 > Logic : V1.06 ARM > MAC : 00-0c-01-95-59-04 > IP Addr : 192.168.226.159 > Subnet : 255.255.255.128 > Gateway : 192.168.226.129 > Host IP : 192.168.226.168 > Config : BDI-new.cfg > > 4. Now I already have BDI-new.cfg file in my /tftpboot/ directory on my > PC. I pinged BDI. Response is OK. Then I made 'telnet' to BDI. The > following is the brief response. > > VERIFY [<offset>] [<file> [<format>]] verify a program file to target > memory > PROG [<offset>] [<file> [<format>]] program flash memory > <format> : SREC, BIN, AOUT, ELF or COFF > ERASE [<address> [<mode>]] erase a flash memory sector, chip or block > <mode> : CHIP, BLOCK or SECTOR (default is sector) > ERASE <addr> <step> <count> erase multiple flash sectors > UNLOCK <addr> <step> <count> unlock multiple flash sectors > FLASH <type> <size> <bus> change flash configuration > FENA <addr> <size> enable autoamtic programming to flash > memory > FDIS disable autoamtic programming to flash > memory > DELAY <ms> delay for a number of milliseconds > SELECT <core> change the current core > len : the number of bits 1..256 > bx : a data byte, two hex digits > HOST <ip> change IP address of program file host > PROMPT <string> defines a new prompt string > CONFIG display or update BDI configuration > CONFIG <file> [<hostIP> [<bdiIP> [<gateway> [<mask>]]]] > HELP display command list > QUIT terminate the Telnet session > > # CONFIG: cannot open BDI-new.cfg > # CONFIG: cannot open BDI-new.cfg > Core#0> > > Means, it is not getting my BDI-new.cfg file even though the file is in > /tftpboot/ directory on my PC while my PC is working as TFTP server. Why > it is BDI is not able to read BDI-new.cfg ? > > Thank you, > Ravi > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > 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] TFTP configuration Vs gdb response time !
by ravi.aloor＠wipro.com 16 Oct '04

16 Oct '04

Hi All, A brief explanation about my working environment: - ARM11 based target board, having its own IP address - My PC running on RedHat Linux-8.0, having its own IP address, as host machine with only CLI and no GUI-XWindows - BDI2000, having its own IP address - PC and BDI2000 are connected to the network independently - U-boot is already available on target board in the flash memory - Firmware is already available on BDI2000 - BDI2000 is connected to the target board through - Using gdb-6.1 configured with --target=arm-linux - Documents referring: README, DULG, bdiGDB maual - I am not using ELDK as explained in DLUG - About our network: I am not sure I want to debug u-boot and also kernel with good response from gdb. The following are my doubts. 1. I have TFTP server already configured on our network. But the response time of gdb is too bad, while debugging. I will not come to know what is happening also. So I thought I will make my PC only as TFTP server to get faster response from gdb. This idea is right / wrong ? If my idea is wrong, what could be the possible reason for gdb's slow response ... ? My PC has PIII processor and 128MB RAM. Do you suggest to increase RAM on my PC ? This anyway I planning to do. Does the response time of gdb depend on network speed also ? 2. In gdbBDI manual, the explanation is given by directly connecting the target board to the host machine with Ethernet cable. Serial cable connection is only for initial configuration of BDI. But in my case, both the target board and my PC are connected separately to the network. Is it ok ? 3. I started to make my PC itself as TFTP server. I followed DLUG document for this purpose and I configured BDI accordingly as shown below: [root@localhost BDISetUp]# ./bdisetup -c -p/dev/ttyS0 -b115 -i192.168.226.-h192.168.226.168 -m255.255.255.128 -g192.168.226.129 -fBDI-new.cfg Connecting to BDI loader Writing network configuration Configuration passed [root@localhost BDISetUp]# ./bdisetup -v -p/dev/ttyS0 -b115 -s BDI Type : BDI2000 Rev.C (SN: 95590442) Loader : V1.05 Firmware : V0.99 bdiGDB for ARM11 Logic : V1.06 ARM MAC : 00-0c-01-95-59-04 IP Addr : 192.168.226.159 Subnet : 255.255.255.128 Gateway : 192.168.226.129 Host IP : 192.168.226.168 Config : BDI-new.cfg 4. Now I already have BDI-new.cfg file in my /tftpboot/ directory on my PC. I pinged BDI. Response is OK. Then I made 'telnet' to BDI. The following is the brief response. VERIFY [<offset>] [<file> [<format>]] verify a program file to target memory PROG [<offset>] [<file> [<format>]] program flash memory <format> : SREC, BIN, AOUT, ELF or COFF ERASE [<address> [<mode>]] erase a flash memory sector, chip or block <mode> : CHIP, BLOCK or SECTOR (default is sector) ERASE <addr> <step> <count> erase multiple flash sectors UNLOCK <addr> <step> <count> unlock multiple flash sectors FLASH <type> <size> <bus> change flash configuration FENA <addr> <size> enable autoamtic programming to flash memory FDIS disable autoamtic programming to flash memory DELAY <ms> delay for a number of milliseconds SELECT <core> change the current core len : the number of bits 1..256 bx : a data byte, two hex digits HOST <ip> change IP address of program file host PROMPT <string> defines a new prompt string CONFIG display or update BDI configuration CONFIG <file> [<hostIP> [<bdiIP> [<gateway> [<mask>]]]] HELP display command list QUIT terminate the Telnet session # CONFIG: cannot open BDI-new.cfg # CONFIG: cannot open BDI-new.cfg Core#0> Means, it is not getting my BDI-new.cfg file even though the file is in /tftpboot/ directory on my PC while my PC is working as TFTP server. Why it is BDI is not able to read BDI-new.cfg ? Thank you, Ravi

3 2

[U-Boot-Users] u-boot for atmel at91rm9200 QI-002 board
by Shakthi Kannan 16 Oct '04

16 Oct '04

Greetings! We have an atmel at91rm9200 qi-002 board from a vendor having vendor's monitor image, ramdisk image, and kernel image 2.4.19-rmk7 in flash. I tried to use u-boot 1.1.1 with the configuration of at91rm2900dk_config: $cd u-boot-1.1.1 $make CROSS_COMPILE=arm-linux- at91rm2900dk_config $make CROSS_COMPILE=arm-linux- all (Using cross-toolchain 2.95.3 from http://ftp.arm.linux.org.uk/pub/armlinux/toolchain/) This generated the requried u-boot, u-boot.bin, u-boot.srec files. I tried to run it from the target ARM SDRAM, but, nothing happened. No output at all. Do I have to rewrite the entire configuration files for the new target board for u-boot to work on the new board? Any suggestions? Thanks, Shaks _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

2 2

RE: [U-Boot-Users] Doubts about usage of BDI2000 !
by ravi.aloor＠wipro.com 16 Oct '04

16 Oct '04

Thanks everybody, 'DEBUGPORT 2001' was missing in my BDI config file. So that's why I could not work with BDI. Now I am able to work with BDI.

1 0

[U-Boot-Users] Doubts about usage of BDI2000 !
by ravi.aloor＠wipro.com 16 Oct '04

16 Oct '04

Hi, I am new to u-boot. I have few doubts. A brief explanation about my working environment: - ARM11 based target board, having its own IP address - PC running on RedHat Linux-8.0, having its own IP address - BDI2000, having its own IP address - PC and BDI2000 are connected to the network (IP address for BDI2000 is 192.168.226.159) - U-boot is already available on target board in the flash memory - Firmware is already available on BDI2000 - BDI2000 is connected to the target board through - Using gdb-6.1 configured with --target=arm-linux The following are my doubts: 1. I want to debug u-boot. So to start debugging u-boot, Do I need to use bare target board that does not contain u-boot already ? 2. I could not start debugging u-boot. So I started debugging kernel with the target board that already contains u-boot. Please check the following: [ravi@localhost 2.6_kernel]$ /home/ravi/gdb-6.1/temp/gdb/gdb vmlinux GNU gdb 6.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux"... (gdb) (gdb) target remote 192.168.226.159:2001 192.168.226.159:2001: Connection refused. (gdb) target remote bdi:2001 bdi:2001: Connection refused. (gdb) quit [ravi@localhost 2.6_kernel]$ Please help me ... Thanks A Lot In Advance, Ravi

4 4

[U-Boot-Users] how to program a bootloader
by Mildred Frisco 15 Oct '04

15 Oct '04

Hi, This might not be the exact list for this but hope some here would be able to help me. Is there a step-by-step guide on how to program a bootloader? The u-boot bootloader (or other linux bootloader) is a very big program to study. I would like to know how to program the basics and concepts. Thanks. Mildred

3 2

RE: [U-Boot-Users] help> on 8260 board, linux hangs
by 김형기 15 Oct '04

15 Oct '04

Hi No , my reference board is made by a local company, i forget the name the board has SDRAM and Flash and one ethernet...just basic items... -----Original Message----- From: Nghiem, Tien [mailto:TNghiem@oerlikon.ca] Sent: Thursday, October 14, 2004 11:45 PM To: ??? Subject: RE: [U-Boot-Users] help> on 8260 board, linux hangs Hi, What is your reference board? is it a MPC8260ADS? -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of hkkim(a)sanesys.com Sent: Monday, October 11, 2004 6:58 AM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] help> on 8260 board, linux hangs i ported uboot-1.0.0 with success on my board , it works fine ( i think ) i can download kernel image and no problem with mtest but when i enter "bootm" "Uncompressing kernel...OK" and no more message but i tested it with a reference board , uboot-1.0.0 and kernel 2.4.4 from (www.denx.de) on reference board it wokrs find ( i searched mailing-list and found "Uncompress...." problem because of HZ issue or bd_t type error i think that is not my case ) i have no reference board circuit but i tried to designe my board with same momery ( type and size) , just they differs in CPU version ( reference is A.1 1K22A-XC , my board is C.2 6K23A could it cause a problem ? ) i use the same uboot in both boards i have no idea what is wrong ? SW or HW ? give me some ideas or hints thanks in advance NHY��X��u�L???�L?��vR?�v�)?��z?Y???��?�g�N�g�h??q ��)rK~)?��?v??+jvz��?W��׮��jP�K?�X�X?��z��˲�q�zض ��X�˺�~�zw?�ϊ˝��

2 1

RE: [U-Boot-Users] Doubts about usage of BDI2000 !
by Woodruff, Richard 14 Oct '04

14 Oct '04

BDI does support ARM11. I know people who have used it in TI, You might need to get some updated drivers though. I'll attach what should work on the OMAP2420. I've not tried it as I've been using Lauterbach. Regards, Richard W. > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users- > admin(a)lists.sourceforge.net] On Behalf Of George G. Davis > Sent: Thursday, October 14, 2004 3:17 PM > To: ravi.aloor(a)wipro.com > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] Doubts about usage of BDI2000 ! > > On Thu, Oct 14, 2004 at 08:46:16PM +0530, ravi.aloor(a)wipro.com wrote: > > > > Hi, I am new to u-boot. I have few doubts. A brief explanation about my > > working environment: > > - ARM11 based target board, having its own IP address > > - PC running on RedHat Linux-8.0, having its own IP address > > - BDI2000, having its own IP address > > - PC and BDI2000 are connected to the network > > (IP address for BDI2000 is 192.168.226.159) > > - U-boot is already available on target board in the flash > > memory > > - Firmware is already available on BDI2000 > > - BDI2000 is connected to the target board through > > - Using gdb-6.1 configured with --target=arm-linux > > > > The following are my doubts: > > 1. I want to debug u-boot. So to start debugging u-boot, Do I need to > > use bare target board that does not contain u-boot already ? > > > > 2. I could not start debugging u-boot. So I started debugging kernel > > with the target board that already contains u-boot. Please check the > > following: > > > > [ravi@localhost 2.6_kernel]$ /home/ravi/gdb-6.1/temp/gdb/gdb vmlinux > > GNU gdb 6.1 > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you > > are > > welcome to change it and/or distribute copies of it under certain > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > > details. > > This GDB was configured as "--host=i686-pc-linux-gnu > > --target=arm-linux"... > > (gdb) > > (gdb) target remote 192.168.226.159:2001 > > 192.168.226.159:2001: Connection refused. > > (gdb) target remote bdi:2001 > > bdi:2001: Connection refused. > > Based on that response, I would guess that your BDI2000 is not yet > configured and connected to the target yet, i.e. the BDI2000 has > not successfully detected any target CPU on the JTAG chain. Try > using `telnet 192.168.226.159` to see what's going on with the > BDI2000. Also, try referring to the BDI manual for help configuring > the BDI and, of course, talk to your processor/board vendor to > resolve BDI setup/config details. Does the BDI2000 even support ARM11 > based processors yet? > > -- > Regards, > George > > > (gdb) quit > > [ravi@localhost 2.6_kernel]$ > > > > Please help me ... Thanks A Lot In Advance, > > Ravi > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > > Use IT products in your business? Tell us what you think of them. Give > us > > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > > http://productguide.itmanagersjournal.com/guidepromo.tmpl > > _______________________________________________ > > U-Boot-Users mailing list > > U-Boot-Users(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

RE: [U-Boot-Users] bootargs
by Barbier, Renaud (GE Infrastructure) 14 Oct '04

14 Oct '04

thanks I figured it out. -----Original Message----- From: George G. Davis [mailto:gdavis@mvista.com] Sent: Thursday, October 14, 2004 9:08 PM To: Barbier, Renaud (GE Infrastructure) Cc: U-Boot-Users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] bootargs On Thu, Oct 14, 2004 at 10:20:29AM -0500, Barbier, Renaud (GE Infrastructure) wrote: > I am not sure that I understand how to pick up the bootargs variables in Linux (ocotea) PPC. Sorry, my comments earlier in this thread were relevant for ARM targets only. I have no idea how this works for PPC or other archs. -- Regards, George > I looked at codes of different machine but I do not know which one fit fro my 440GX based-machine. > > I am still looking into these bd_t and bi_record structure to see if I can find the answer. > > Any help welcome? > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

RE: [U-Boot-Users] bootargs
by Barbier, Renaud (GE Infrastructure) 14 Oct '04

14 Oct '04

I am not sure that I understand how to pick up the bootargs variables in Linux (ocotea) PPC. I looked at codes of different machine but I do not know which one fit fro my 440GX based-machine. I am still looking into these bd_t and bi_record structure to see if I can find the answer. Any help welcome?

2 1

RE: [U-Boot-Users] Doubts about usage of BDI2000 !
by VanBaren, Gerald (AGRE) 14 Oct '04

14 Oct '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf > Of ravi.aloor(a)wipro.com > Sent: Thursday, October 14, 2004 11:16 AM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] Doubts about usage of BDI2000 ! > > > Hi, I am new to u-boot. I have few doubts. A brief > explanation about my > working environment: > - ARM11 based target board, having its own IP address > - PC running on RedHat Linux-8.0, having its own IP address > - BDI2000, having its own IP address > - PC and BDI2000 are connected to the network > (IP address for BDI2000 is 192.168.226.159) > - U-boot is already available on target board in the flash > memory > - Firmware is already available on BDI2000 > - BDI2000 is connected to the target board through > - Using gdb-6.1 configured with --target=arm-linux > > The following are my doubts: > 1. I want to debug u-boot. So to start debugging u-boot, Do I need to > use bare target board that does not contain u-boot already ? > > 2. I could not start debugging u-boot. So I started debugging kernel > with the target board that already contains u-boot. Please check the > following: > > [ravi@localhost 2.6_kernel]$ /home/ravi/gdb-6.1/temp/gdb/gdb vmlinux > GNU gdb 6.1 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public > License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "--host=i686-pc-linux-gnu > --target=arm-linux"... > (gdb) > (gdb) target remote 192.168.226.159:2001 > 192.168.226.159:2001: Connection refused. > (gdb) target remote bdi:2001 > bdi:2001: Connection refused. > (gdb) quit > [ravi@localhost 2.6_kernel]$ > > Please help me ... Thanks A Lot In Advance, > Ravi I'm not an expert in the questions you ask, especially since I have not used an ARM but... #1 (using the BDI to debug u-boot) * See DULG FAQ section <http://www.denx.de/twiki/bin/view/DULG/WrongDebugSymbolsAfterRelocation > WRT #2 (using gdb and the BDI) * Is your IP address for the BDI correct? Can you ping it? Can you telnet to it? * Do you have a DEBUGPORT defined in your BDI config file (that is where port 2001 is defined) gvb ****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak: ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0

[U-Boot-Users] MIPS32 24K processor support by u-boot ?
by ch S 14 Oct '04

14 Oct '04

Hi, Does anyone know wether U-Boot support the MIPS32 24K processor or not ? If yes, where can I find it ? Thanks a lot. Charles __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

1 0

RE: [U-Boot-Users] Support for ZBT SRAM in MPC8560ADS?
by Fillod Stephane 14 Oct '04

14 Oct '04

Hi Scott, >> Is there any plan for support of the ZBT SRAM found in MPC8560ADS ? >> Can someone at Freescale share the CS and clock setup? > We have our own 8540 board which has ZBT SRAM on the local bus very similar to > the ADS board. The chip is MT55L512L18PF Indeed, the chips on the ADS are 2xMT55L512L18P. > If you are interested I can send the code. Please be warned that we are still > bringing our board up and I have several work a rounds for other problems so > it is very ugly. Don't worry, we're used to these stages :) Can you please send me (or to the list) your patch for the ZBT SRAM? Also a question for folks at freescale, according to u-boot/doc/README.mpc85xxads, where in the memory mapping the ZBT is supposed to be mapped (2MiB)? Thanks a lot, -- Stephane

3 2