June 2005 - U-Boot

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

06 Aug '05

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

2 1

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

06 Aug '05

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

2 1

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

06 Aug '05

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

3 2

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

04 Aug '05

Dear Denis, can you tell me something about the SCSI support in the current versions of U-Boot? It seems the MIB405 board (maintained by you) has SCSI support enabled, but the whole code in common/cmd_scsi.c seemd to be unused - for example, there is no caller of do_scsi() or do_scsiboot() anywhere in the whole source tree? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de In general, they do what you want, unless you want consistency. - Larry Wall in the perl man page

2 4

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

04 Aug '05

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

2 2

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

03 Aug '05

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

5 8

[U-Boot-Users] [PATCH] sinclude board specific make fragment
by Murray.Jensen＠csiro.au 14 Jul '05

14 Jul '05

This patch "sinclude"s (i.e. it is allowed not to exist) a make fragment from the board specific subdirectory, to allow a port to have board or platform specific targets (which may or may not be added to ALL var - see previous patch). for example - install, or in the case of my 8560 based board, I build a separate file image of the "boot page". Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 6

[U-Boot-Users] EMAC2 & EMAC3 operation on PPC 440GX
by David Grab 12 Jul '05

12 Jul '05

Hello, as mentioned before i´m using two Marvel 88E1111 PHY on my PPC440GX Board. They are configured as a RGMII to copper interface for use with EMAC 2 & 3. So now i´m in trouble with the configuration of the network. After booting i set with "setenv ethact ppc_440x_eth2" EMAC2 for networking. After that i try a "ping" to know if network is working. Reading the speed and duplex from PHY works, but after that i got in an endless loop. I figured out, that no interrupt is recognized and in 440gx_enet.c in ppc_440x_eth_init the default configuration of the interrupt handler is for ETH0: irq_install_handler (VECNUM_EWU0 + (hw_p->devnum * 2), (interrupt_handler_t *) enetInt, dev); irq_install_handler (VECNUM_ETH0 + (hw_p->devnum * 2), (interrupt_handler_t *) enetInt, dev); so i changed it as following... irq_install_handler (VECNUM_EWU2 + (hw_p->devnum * 2), (interrupt_handler_t *) enetInt, dev); irq_install_handler (VECNUM_ETH2 + (hw_p->devnum * 2), (interrupt_handler_t *) enetInt, dev); and added in vecnum.h these lines: #define VECNUM_ETH2 (64 + 0) /* Ethernet 0 interrupt status */ #define VECNUM_EWU2 (64 + 1) /* Ethernet 0 wakeup */ But this didn´t solve the problem. Actually i also couldn´t get the TxCLK work on my RGMII Bridge and i don´t know why. The devices are configured as 100 MBit RGMII and receiving packets from network seems to be functioning (EMAC_OCRX Register increments rapidly). I would be appreciated if someone could give me a tip, what i have forgot to do. Greets, David

4 5

[U-Boot-Users] cfi_flash is now working with 64 bit port width
by Yusuf Ibrahim Ozkok 02 Jul '05

02 Jul '05

Hi, I have resolved my problem with cfi_flash driver. I would like to share what I have learned during my struggle with cfi_flash driver. The posts for that problem; http://sourceforge.net/mailarchive/message.php?msg_id=11994639 http://sourceforge.net/mailarchive/message.php?msg_id=12058552 What caused the problem and how is it solved: Flash chips in my board are connected to 64 bit data bus. And the problem is simply about writing 64 bit data at once. cfi_flash driver used "unsigned long long" variables for 64 bit data and write them to the bus simply using long long pointers (For me that is a bug. And I would like to release a patch for it). Any integer definition (like int, long, long long etc.) makes gcc to use 32 bit registers of the cpu (for 32 bit ppc's). Long long is 64 bit on the memory that is true, but transfering a long long requires two cycles. To write a 64 bit data at once we have to use floating point registers. A way of using these registers in C is to define the variables as "double". But somehow defining double didn't work in u-boot or with my ppc_82xx-gcc compiler (eldk's compiler). An other way is to use assembly floating point instructions but double precision forms. Such as "lfd" and "strfd" commands for ppc have to be used. Jerry Van Baren had warned me previously but I couldn't make sense with his suggestions at the moment. What make me confused that writing flash commands from u-boot shell by using mw.l command was working for protect and erase operations. Since mw.l makes 32 bit bus transaction, for example a 0x60606060 command was beeing recognized by all the four flash chips. On the other way a 0x00600060 command is caused failure (I had expected that it will work two out of four flash chips). Now when I solved the problem by using floating point registers, I understood Jerry's suggestions exactly! You can reach his post by the link. (http://sourceforge.net/mailarchive/message.php?msg_id=11994640) But I still can not solve the magic that while sending 0x60606060 by mw.l command works but 0x00600060 not! Lessons: So lesson-1: if hardware people gives you a 64 bit bus, use double or directly asm floating point instructions. I think cfi_driver works with the boards that the flash chips are selected by chip select signals for each 32 bit portion of the data bus. In our board all the flash chips are connected to the same chip select signal that caused the problem. Lesson-2: first of all examine your hardware well and be aware of your hardware. Thanks for your help: Jerry Van Baren, Yuli Barcohen, Richard Woodruff. The patch (unformatted): 1. The following function is added. static void write_via_fpu (vu_long * addr, ulong * data) { __asm__ __volatile__ ("lfd 1, 0(%0)"::"r" (data)); __asm__ __volatile__ ("stfd 1, 0(%0)"::"r" (addr)); } 2. in /drivers/cfi_flash.c line 850; - *addr.llp = cword.ll; + write_via_fpu((vu_long*)addr.llp, (ulong*)&cword.ll); line 1159; - cptr.llp[0] = cword.ll; + write_via_fpu((vu_long*)cptr.llp, (ulong*)&cword.ll); P.S. this function will work if fpu is enabled. If not it may be enabled by setting the fpu bit in msr as follows; unsigned long msr; msr = get_msr(); set_msr(msr | MSR_FP); *_msr functions may be found by grepping the uboot directory. 3. The patch is not tested when CFG_FLASH_USE_BUFFER_WRITE is defined. Same changes as in 2 should be done for that case. If those changes are accepted, I can arrange a formal patch. Finally, I would like to ask about the Tolunay Orkun's patch about tout in flash_status_check function. what is the last thought for that patch Is it planned to be released? Because it's really a bug! (Last post for the thread; http://sourceforge.net/mailarchive/message.php?msg_id=11936556) Best Wishes. Yusuf. ###################################################################### Dikkat: Bu elektronik posta mesaji kisisel ve ozeldir. Eger size gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz. Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte, guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi gorusu olmak zorunda degildir. ###################################################################### Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. E-mails to and from the company are monitored for operational reasons and in accordance with lawful business practices. Any views or opinions presented are solely those of the author and do not necessarily represent the views of the company. ######################################################################

5 8

RE: [U-Boot-Users] silent console, nulldev and CONFIG_AUTOBOOT_KEYED
by Dave Ellis 30 Jun '05

30 Jun '05

Ladislav Michl wrote: > If "silent" env variable is set GD_FLG_SILENT is added to gd->flags > (in console_init_f). That effectively causes all console output to be > suppresed. That flag also causes nulldev to become outputdev > (in console_init_r). Btw, shouldn't CONFIG_SILENT_CONSOLE depend on > CFG_DEVICE_NULLDEV in this case? The current implementation of CONFIG_SILENT_CONSOLE needs CFG_DEVICE_NULLDEV. I suppose a check could be added to flag the error at build time if CFG_DEVICE_NULLDEV is not defined. > Now we are entering into abortboot > (CONFIG_AUTOBOOT_KEYED) and because "silent" env variable is set and > also CONFIG_SILENT_CONSOLE defined console_assign (stdout, "serial"); is > called, doing basicaly nothing, because GD_FLG_SILENT which is still > set prevents any console output. In abortboot the "silent" operation is suspended by setting the console back to serial so you can use the console to abort the boot. If the boot is aborted GD_FLG_SILENT is cleared, and the serial console works. If the boot is not aborted the console is set back to "nulldev" and the boot continues silently. > There are various solutions from this situation, but I'd like first > understand what is CFG_DEVICE_NULLDEV good for when we have GD_FLG_SILENT? > Or better, how should all these three things in question behave? You can boot silently (if "silent" is set), you can decide to see the output (by removing "silent" from the environment) and in either case if you abort the boot the console works. Isn't that exactly what the feature should do? Dave Ellis ~~~~~~~~~~~~~~~~~~~~~~~~~~ SIXNET - "Leading the Industrial Ethernet Revolution" 331 Ushers Road, P.O. Box 767, Clifton Park, NY 12065 USA Tel +1 (518) 877-5173 Fax +1 (518) 877-8346 Email me at: dge(a)sixnetio.com Detailed product info: www.sixnetio.com ~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2

[U-Boot-Users] Erase in UBoot
by Bharathi Subramanian 30 Jun '05

30 Jun '05

Hello All, We are using UBoot 1.0.0, During continuous 2nd erase operation, the no .of DOT is increased. I like to know whether this is something do with UBoot or flash chip or is it normal behavior ?? ROM # erase B0100000 B07FFFFF .............................................. done Erased 111 sectors ROM # erase B0100000 B07FFFFF ..................................................... done Erased 111 sectors ROM # Thanks, -- Bharathi S

3 2

[U-Boot-Users] [PATCH] - OMAP242x/ARM1136 + H4 board (30-Jun-2005)
by Woodruff, Richard 30 Jun '05

30 Jun '05

Hello Wolfgang, Hopefully, this is the last update for a while. As they are slow to enter the tree I've been refreshing the patch. Please discard previous ones and use this one. This patch is against a 30 Jun 05 CVS head. I look forward to you getting time to actually working some of the backlog. Additional updates in this patch include ability to run the DDR in lock or unlock mode, and a fix to make all newer 2422 chips work. * Patch by Richard Woodruff, 30 Jun 2005: OMAP242x H4 board update, 30 June 05 - fix for ES2(.05,.1) differences. - switch to using the cfi_flash driver. - fix SRAM build address - fix for GP device operation - unlock SRAM for GP devices. - display more device information at startup. - fix potential deadlock in omap24xx_i2c driver. - fix DLL load values to match dpllout*1 operation. - fix 2nd chip select init for combo DDR device. - fix for 2422 rev > ES2 mono DDR. - add conditional DDR lock/unlock usage. drivers/serial.c,ns16550.c - remove obsolete APTIX conditionals. cfi_flash.c - add support for CFI Intel 28F256L18 on H4 board. Regards, Richard W. > -----Original Message----- > From: Woodruff, Richard > Sent: Tuesday, May 31, 2005 3:56 PM > To: u-boot-users(a)lists.sourceforge.net; 'Wolfgang Denk' > Subject: [PATCH] - OMAP242x/ARM1136 + H4 board. > > Hello Wolfgang, > > Here is an updated patch for the OMAP242x against the CVS as of 31 May 05. > This code runs against all current versions of the OMAP242x chip on the H4 > reference platform. > > All updates are confined to 242x specific directories except for a small > change to the CFI driver. The CFI driver makes some small incorrect > assumptions when it comes to Intel parts which have partitioning in > addition to sectoring. > > I sent out a now somewhat stale patch a couple months back in which I have > _not_ heard any comment on. Please discard that one and apply this > instead. If there any problems with this please let me know. > > OMAP242x H4 board update, 31 May 05 > - fix for ES2(.05,.1) differences. > - switch to using the cfi_flash driver. > - fix SRAM build address > - fix for GP device operation > - unlock SRAM for GP devices. > - display more device information at startup. > - fix potential deadlock in omap24xx_i2c driver. > - fix DLL load values to match dpllout*1 operation. > - fix 2nd chip select init for combo DDR device. > cfi_flash.c > - add support for CFI Intel 28F256L18 on H4 board. > > Regards, > Richard W.

1 0

RE: RE: [U-Boot-Users] Does u-boot relocate absolute symbols?
by Rune Torgersen 30 Jun '05

30 Jun '05

Wow.... This surprises me... I have alwayts thought that *test and test[] would be the same thing. Only solutionI can see is to change the definition in common.c to be *test, this will still get the address of test[] defined elsewhere. (See attached files) > Sure, I've tried this. This is the point, where my problem > arose. Attached you find two > small files, you can easily compile under linux (gcc -o > arrtest -I ./ ./common.c > ./array.c). The file "common.c" represents the code I can't > (don't want to) touch. > "array.c" represents my project dependent code. If you run > arrtest it will show to you,

2 1

[U-Boot-Users] 8540 and L1 cache mapping
by Charles J Gillan 30 Jun '05

30 Jun '05

Recently I have been studying the boot sequence for the 8540 based boards in U-Boot. I have a question on the location of the initial C stack. As I understand it, cpu/mpc85xx/start.S uses L1 data cache as the location for the C stack prior to the relocation into RAM. CFG_INIT_RAM_ADDR is defined within the relevant config file for each 6540 based board. I see in the 8540 User Manual that there is a register which can be used to position L2 cache in physical address space but there does not appear to be a similar register for L1 cache. However, I see that in the init.S files, for each board, entries are placed into TLB0 for memory at address CFG_INIT_RAM_ADDR. This is declared as cacheable and non-garded. Am I correct in thinking that this is all that is required to position the C run-time stack in L1 D-cache ? Thanks, Charles. -------------------------------------------------------------------------- Dr Charles J Gillan The Institute of Electronics, Communications and Information Technology (ECIT), Queen's University Belfast, Titanic Quarter Queens Road, Queens Island, Belfast, BT3 9DT Northern Ireland, UK Tel: +44 (0) 2890 971847 Fax: +44 (0) 2890 971702 ---------------------------------------------------------------------------

2 1

[U-Boot-Users] [PATCH] expand macros in bootargs env var for bootm command
by Murray.Jensen＠csiro.au 30 Jun '05

30 Jun '05

This patch expands $(...) macros present in the bootargs environment variable for the bootm command. Same code could be (and probably should be, for consistencies sake) used in other boot commands. Required exposing the "process_macros()" function in common/main.c. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 5

[U-Boot-Users] [PATCH] limit length of kernel command line in bootm
by Murray.Jensen＠csiro.au 30 Jun '05

30 Jun '05

This patch limits the length of the command line that the bootm command will pass to the kernel. Note that as it stands, it uses CFG_BARGSIZE which must be <= the size of the command line array used in the kernel (most boards have this set to CFG_CBSIZE, which in turn is usually 256 - which is usually ok). I use 1024 for both, and have a kernel patch which increases the command line aray to 1024. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 4

[U-Boot-Users] [PATCH] allow flash "ranges" to default to end of flash
by Murray.Jensen＠csiro.au 30 Jun '05

30 Jun '05

This patch modifies the flash "range" code slightly to allow a range to "default" to the "end of the bank". Currently, you must specify "<first>-<last>" where <first> and <last> are sector numbers (zero based) within the "bank". This code allows you to say "<first>-" and <last> will default to the sector number of the last sector in the "bank". I thought I needed this - but now I don't use it anymore. However, the code might still be useful to someone. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 4

[U-Boot-Users] [PATCH] fix build without CONFIG_NET_MULTI
by Murray.Jensen＠csiro.au 30 Jun '05

30 Jun '05

This is an older patch which fixed building without CONFIG_NET_MULTI. I'm not sure if its still required or not, since I now use CONFIG_NET_MULTI when building for my boards. I guess it might help someone if they search the list after striking a similar problem. I would think this would need some testing before it gets applied to the central repository. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 2

RE: [U-Boot-Users] Does u-boot relocate absolute symbols?
by Rune Torgersen 30 Jun '05

30 Jun '05

I just have to comment on this. > It does not work (because it's simply wrong) to declare > fpgadata as follows in pf5200.c > (although looking good in the first place, if you think about > it, the compiler needs to > handle both declarations differently): > > const unsigned char *fpgadata = 0x400000; /* (with 0x400000 > being the address to store > the image with TFTP at) */ > Have you tried to do this? Because it should work (even if one is declared char [] and the other char *) I use something similar to access a FPGA binary image stored in flash (after U-Boot relocation) and it works.

4 7

[U-Boot-Users] EP8248 as a PCI card
by Nishant Galange 30 Jun '05

30 Jun '05

Thanks, Yuli Got the patch, u-boot 1.1.2 installed and running on my ep8248 board. In standalone mode. When I try to use the EP8248 (with u-boot 1.1.2) as a PCI card in my PC (desktop), the PC doesn't even power up. But when the same card, with PlanetCore bootloader (the bootloader that came with the card), is inserted in the same PCI slot, the PC powers on, Windows XP starts up and even detects the card as a "Other PCI bridge" device. What change(s) do I have to make in the u-boot code to make it work as a PCI card in my PC? I have already tried the following: #define CONFIG_PCI in include/configs/EP8248.h Because of the above #define, I had to write a pci_init_board() function in board/ep8248/ep8248.c This function simply creates a pci_controller 'hose' and calls pci_mpc8250_init(&hose); With all this, now my PC boots up with the EP8248 + u-boot, but Windows can't detect the card. How do I proceed? What changes should I make? Waiting, Nishant -----Original Message----- From: Yuli Barcohen <yuli(a)arabellasw.com> To: "Nishant Galange" <nishant.subs(a)myrealbox.com> Date: Wed, 29 Jun 2005 11:42:55 +0300 Subject: Re: where is the EP8248 patch? >>>>> Nishant Galange writes: Nishant> Hi Yuli On 12 Dec 2004, You posted a patch for the Embedded Nishant> Planet EP8248 board. How do I download this patch? >From the GMANE archive which was mentioned many times on this list. Nishant> Is it already included in u-boot 1.1.2? No AFAIK. It's probably on Wolfgang's list. Nishant> Once I have all the necessary source code (with the patch Nishant> incorporated), what command(s) do I give to compile u-boot Nishant> 1.1.2 for the EP8248 board? Nishant> Will the following work: Should be OK. Nishant> $ export CROSS_COMPILE=ppc_82xx- Nishant> $ export PATH=[path_to_ELDK]:$PATH Nishant> $ make EP8248_config Nishant> $ make -- ======================================================================== Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader yuli(a)arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel ========================================================================

2 1

[U-Boot-Users] EP8248 as a PCI card
by Nishant Galange 30 Jun '05

30 Jun '05

Thanks, Yuli Got the patch, u-boot 1.1.2 installed and running on my ep8248 board. In standalone mode. When I try to use the EP8248 (with u-boot 1.1.2) as a PCI card in my PC (desktop), the PC doesn't even power up. But when the same card, with PlanetCore bootloader (the bootloader that came with the card), is inserted in the same PCI slot, the PC powers on, Windows XP starts up and even detects the card as a "Other PCI bridge" device. What change(s) do I have to make in the u-boot code to make it work as a PCI card in my PC? I have already tried the following: #define CONFIG_PCI in include/configs/EP8248.h Because of the above #define, I had to write a pci_init_board() function in board/ep8248/ep8248.c This function simply creates a pci_controller 'hose' and calls pci_mpc8250_init(&hose); With all this, now my PC boots up with the EP8248 + u-boot, but Windows can't detect the card. How do I proceed? What changes should I make? Waiting, Nishant -----Original Message----- From: Yuli Barcohen <yuli(a)arabellasw.com> To: "Nishant Galange" <nishant.subs(a)myrealbox.com> Date: Wed, 29 Jun 2005 11:42:55 +0300 Subject: Re: where is the EP8248 patch? >>>>> Nishant Galange writes: Nishant> Hi Yuli On 12 Dec 2004, You posted a patch for the Embedded Nishant> Planet EP8248 board. How do I download this patch? >From the GMANE archive which was mentioned many times on this list. Nishant> Is it already included in u-boot 1.1.2? No AFAIK. It's probably on Wolfgang's list. Nishant> Once I have all the necessary source code (with the patch Nishant> incorporated), what command(s) do I give to compile u-boot Nishant> 1.1.2 for the EP8248 board? Nishant> Will the following work: Should be OK. Nishant> $ export CROSS_COMPILE=ppc_82xx- Nishant> $ export PATH=[path_to_ELDK]:$PATH Nishant> $ make EP8248_config Nishant> $ make -- ======================================================================== Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader yuli(a)arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel ========================================================================

2 1

[U-Boot-Users] [PATCH] Differing gcc version ARM options
by Peter Pearse 30 Jun '05

30 Jun '05

Hi Attached a patch to fix the problems with different ARM options in different gcc versions. Thanks to Catalin Marinas for suggesting use of the cc-option shell function from the kernel make files - makes it neater than my last try..... Patched against head 30th June 2005. Tested with MAKEALL arm. CHANGELOG: * Patch by Peter Pearse, 30th June 2005 - Import cc-option shell function from kernel - Use it to get the correct ARM gcc options - Supply recommended flags for ARM supplied & supported development boards. ------------------------------------------------------------------------- Peter Pearse ARM Ltd

2 1

[U-Boot-Users] Relocation of symbols?
by Andreas Block 30 Jun '05

30 Jun '05

Hi, I've posted another question regarding this topic on 14th June 2005. Since I haven't received any answers, I'm unsure, if I'm in the correct mailinglist or if my problem was that trivial. In case of the latter one, please, give me a hint, where to post my questions instead. So here's my new question: I've declared a global array: char *walter[] = { "ABC", "DEF" }; The u-boot boots from flash and relocates itself into RAM. After relocation the array is relocated into RAM and so is its content (the pointers to strings). But the actual strings are still located in flash. "walter" is a global symbol located in ".data" section of the compiled object. Is this the behaviour I should expect, or is it a problem with u-boots relocation code? Best regards, Andreas Block

4 18

[U-Boot-Users] [PATCH] fix read-only "include/bmp_logo.h" after cvs checkout
by Murray.Jensen＠csiro.au 30 Jun '05

30 Jun '05

The file "include/bmp_logo.h" is automatically generated during u-boot build, but it is also present in the central CVS repository, and when this file gets checked-out it is read-only. When the build reaches the tools directory and trys to overwrite "include/bmp_logo.h" it fails, and you have to change the write permissions and restart the build. This patch removes any existing "include/bmp_logo.h" file before generating the new one. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

1 0

[U-Boot-Users] Error on u-boot-1.1.3 : Bus Fault
by daoudi＠fiupso.u-psud.fr 30 Jun '05

30 Jun '05

Hello! I've encountered a problem while downloading u-boot-1.1.3 into a FPGA Xilinx Virtex 2 Pro. I managed to download and use u-boot a week ago but suddenly this problem appeared. I haven't changed anything since the last downloading and the FPGA still does work. Here is an echo of the problem : U-Boot 1.1.3 (Jun 23 2005 - 16:12:29) ### No HW ID - assuming ML300 DRAM: 16 MB Bus Fault @ 0x00002b5c, fixup 0x00000000 Machine check in kernel mode. Caused by (from msr): regs 00801d50 Unknown values in msr NIP: 00002B5C XER: 20000000 LR: 0000227C REGS: 00801d50 TRAP: 0200 DAR: 55552A23 MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 00000000 00801E40 FFFF9308 00801E50 0000000A 0000000A 00000000 FFFFFFFF GPR08: FFFFFFFF FC02283C 0001BE85 04FBCB50 00000020 FFFF962C 00024400 00000000 GPR16: 00000000 00000000 00000000 00000000 00001000 00801E40 00000000 0000227C GPR24: 00002B5C 00000000 04FDD000 04FBD000 04FBCB90 00801F80 0002448C 04FBCB4C Call backtrace: machine check The compiling of u-boot was successful but I think that there is a problem with the address of TEXT_BASE or the sections. I've tried to find an answer to this problem on the forum but I didn't manage to. Can you please help me because I really don't know where the problem comes from. Here is the Address Map for Processor ppc405_0 (0x00000000-0x00ffffff) SDRAM_MT48LC4M32B2TG plb (0x16000000-0x17ffffff) FLASH_16MX16 plb->plb2opb->opb (0x24800000-0x24801fff) iocm_cntlr iocm (0x40000000-0x4000ffff) LEDs_2Bit plb->plb2opb->opb (0x40400000-0x4040ffff) RS232_Uart_1 plb->plb2opb->opb (0x40800000-0x4080ffff) IIC_Bus plb->plb2opb->opb (0x41200000-0x4120ffff) opb_intc_0 plb->plb2opb->opb (0x80400000-0x8040ffff) Ethernet_MAC plb (0xe4800000-0xe4801fff) docm_cntlr docm (0xfffe0000-0xffffffff) plb_bram_if_cntlr_1 plb Thank you in advance.

1 0