April 2005 - U-Boot

[U-Boot-Users] Patch for ADSVIX single board computer with PXA27x processor
by Robert Whaley 08 Apr '05

08 Apr '05

This patch adds support for the ADSVIX SBC with PXA27x processor.

2 3

[U-Boot-Users] get_ram_size() returns wrong value
by Daniel Ann 08 Apr '05

08 Apr '05

Hiya folks, Somehow I've missed this before, but just today noticed that u-boot is reporting DRAM: 64 MB (BTW, machine is running with 128MB) So, again, I had peaked inside the u-boot, and after doing some printf statements, I can get it to detect 128MB but I cant seem to get to the root of the problem. This is orginal code with my printf. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- for (cnt = 1; cnt < maxsize / sizeof (long); cnt <<= 1) { printf("*addr(%x)\n",*(addr=base + 0x1000000)); addr = base + cnt; /* pointer arith! */ val = *addr; *addr = save[--i]; if (val != ~cnt) { size = cnt * sizeof (long); /* Restore the original data before leaving the function. */ for (cnt <<= 1; cnt < maxsize / sizeof (long); cnt <<= 1) { addr = base + cnt; *addr = save[--i]; } return (size); } } =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- I can see what the code does. It tries to write ~cnt value (first backingup) then read it in to see if it had written it successfully. But problem lies at (base + 0x1000000). If u-boot detects val != ~cnt, then it will finish the loop right there and return size 64MB. If it succeeds, returns 128MB (which is what I have). So, natually, I wanted to see what exactly does it change it to, and when, hence the printf. But guess WHAT? It reads back perfectly correct and return 128MB. Do you guys think its timing issue ? Having printf natually adds delay factor to the code. Could this be HW problem ? (I can just throw it back to the HW people to get it fixed if so :) ) If I get desperate, I might just leave the dummy printf or hardcode the size, but for now, I wouldnt mind diving at it. -- Daniel

3 7

RE: [U-Boot-Users] JFFS2+U-Boot writing an image that has been "SUMMARY"-patched?
by Dave Ellis 07 Apr '05

07 Apr '05

Martin Egholm Nielsen wrote: > I'm considering patching my Linux kernel JFFS2 code with the "summary" > patch: > http://www.inf.u-szeged.hu/jffs2/mount.php > decreasing mount time severely. In short, this patch requires modifying > some data in the end of each eraseblock - also in the image that should > be written. > > However, I'm planning on using u-boot to write the Linux root-fs - using > "nand write.jffs2" - and was wondering whether this function > (write.jffs2) actually cared about what it was writing? When I added the option all it did was allow skipping of bad blocks (since JFFS2 blocks don't care where they are in the FLASH) and write the oob data properly for JFFS2. It didn't (and I think still doesn't) examine the JFFS2 data at all. As long as the summary data is location independent it should be OK. > I tried writing "giberish" memory data using write.jffs2, and it didn't > complain, though. But still, its name ".jffs2" indicate that some > knowledge of jffs2 is used? I only meant it to indicate that the option is for writing jffs2 images, so if changes or added features would break jffs2 compatibility (and some were proposed a while ago) the changes should not be made to the jffs2 option, they would need a new one. Best regards, 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] DDR II Support: I Lied!
by Jon Loeliger 07 Apr '05

07 Apr '05

> Folks, > > Some of you were waiting on DDR II support in U-Boot. > > Wait no longer! Hmm... In a long standing tradition of sending mail to the wrong list, I have mistakenly announced my check-in of the DDR II support to the _external_, Public U-Boot list instead of the _internal_ U-Boot list. Kinda cool, ja? So, I lied. You _do_ have to wait a bit longer. I'd like to get it tested on our actual Silicon before I release it to the world. Don't check it out of your CVS tree using -r pq3 or -r pq38. It just won't work that way. :-) Waaaaaiit for it.... jdl

1 0

[U-Boot-Users] [PATCH] Add Board MP2USB Board
by Eric BENARD 07 Apr '05

07 Apr '05

Hi, these patches add support for MP2USB board which is based on AT91RM9200 cpu. - diff-mp2usb-1.patch : adds board/mp2usb directory - diff-mp2usb-2.patch : adds include/configs/mp2usb.h - diff-mp2usb-3.patch : modify MAKEALL - diff-mp2usb-4.patch : modify Makefile CHANGELOG * Patch by Eric Benard, 07 Apr 2005: Add support for MP2USB board. Many thanks Best regards Eric

1 0

[U-Boot-Users] DDR II Support
by Jon Loeliger 07 Apr '05

07 Apr '05

Folks, Some of you were waiting on DDR II support in U-Boot. Wait no longer! New and improved! Checked into a CVS repository near you! It dices, it slices, it supports DDR I and DDR II! It even reads the SPD and crocks up 8548 Memory controller registers dynamically! Naturally, this has only been tested on 8540ADS and 8555/41 CDS hardware to date, but will soon be coming to new silicon near you! By all means, feel free to read over my fiction and comment! Don't wait! CVS Repository Servers are standing by now! They are eager to supply your DDR II needs from either the PQ3 or the PQ38 branches using one of your simple invocations: % cvs co -r pq3 -d u-boot-pq3 u-boot or % cvs co -r pq38 -d u-boot-pq38 u-boot But remember, if you want to build for the MPC8548CDS, you must use the pq38 branch! Don't hesitate! Compile now! jdl

1 0

[U-Boot-Users] CONFIG_SYS_CLK_FREQ
by Daniel Ann 07 Apr '05

07 Apr '05

hi all, Quick question on CONFIG_SYS_CLK_FREQ For system running with 33MHz is it correct to define it as 33,333,333 or should it be 33,000,000. It shouldnt concern too much, but seeing that something like 33,333,000 is even used, couldnt help wonder what should it really be.. -- Daniel

3 3

[U-Boot-Users] JFFS2+U-Boot writing an image that has been "SUMMARY"-patched?
by Martin Egholm Nielsen 06 Apr '05

06 Apr '05

Hi there, I'm considering patching my Linux kernel JFFS2 code with the "summary" patch: http://www.inf.u-szeged.hu/jffs2/mount.php decreasing mount time severely. In short, this patch requires modifying some data in the end of each eraseblock - also in the image that should be written. However, I'm planning on using u-boot to write the Linux root-fs - using "nand write.jffs2" - and was wondering whether this function (write.jffs2) actually cared about what it was writing? I tried writing "giberish" memory data using write.jffs2, and it didn't complain, though. But still, its name ".jffs2" indicate that some knowledge of jffs2 is used? BR, Martin Egholm

1 0

[U-Boot-Users] CONFIG_SERIAL_TAG and CONFIG_REVISION_TAG ???
by Steven Scholz 06 Apr '05

06 Apr '05

Hi there, for ARM boards CONFIG_SERIAL_TAG and CONFIG_REVISION_TAG can be used to pass the board's serial nummber and revision to a linux kernel. For now setup_serial_tag() has to be defined in board specific files. But setup_revision_tag() is defined in armlinux.c like void setup_revision_tag(struct tag **in_params) { u32 rev = 0; #ifdef CONFIG_OMAP2420H4 u32 get_board_rev(void); rev = get_board_rev(); #endif params->hdr.tag = ATAG_REVISION; params->hdr.size = tag_size (tag_revision); params->u.revision.rev = rev; params = tag_next (params); } I'd love to make this consistent. So either do it like setup_serial_tag() or like setup_serial_tag() ... Since I don't like board specific defines like "#ifdef CONFIG_OMAP2420H4" in common files we should move that out. So the question is: shell we implement board specific get_board_rev() and get_board_serial() and have the params->hdr.* stuff in armlinux.c? or shell we implement setup_serial_tag() and setup_serial_tag() in board specific files and do the params->hdr.* stuff there? Comments please. Thanks, Steven

1 1

[U-Boot-Users] Patch to update pxa-regs.h for PXA27x chips
by Robert Whaley 06 Apr '05

06 Apr '05

This patch updates the pxa-regs.h file for PXA27x chips

2 1

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)
by llandre 06 Apr '05

06 Apr '05

I have a question about SDRAM detection code (cpu/ppc4xx/sdram.c). I tested it with the following configurations: Configuration #1: 32 MB (2 chips), SDRAM clk = 133 MHz Configuration #2: 32 MB (2 chips), SDRAM clk = 111 MHz and everything worked fine. Then I tried the following: Configuration #3: 64 MB (2 chips), SDRAM clk = 111 MHz and the SDRAM does not work. U-Boot executes fine until it jumps to SDRAM after relocation. In this case, two chips K4S561632E-TI75 have been used. In my understanding the default value (0x07f00000) for the RTR register is wrong because these chips have a 64 ms/8k cycle refresh. Thus this register should be 0x03780000. I tried to change it but SDRAM did not work anyway. I suspect it is necessary to fix the TR register too or that the value for RTR is wrong. Any suggestions/remarks? TIA and best regards, llandre DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2(a)dave-tech.it

5 11

[U-Boot-Users] [PATCH] test command bug.
by Hiroshi Ito 06 Apr '05

06 Apr '05

Hello, I'm new to this list. u-boot-1.1.2 ( cvs version ) # if test -z "" ; then echo true; else echo false; fi false # if test -n "" ; then echo true; else echo false; fi true # The logic is reversed. patch is attached. -------- 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 1

[U-Boot-Users] FWD: SNTP support patch
by Wolfgang Denk 06 Apr '05

06 Apr '05

[Forwarded on behalf of Masami Komiya.] ------- Forwarded Message Date: Wed, 30 Mar 2005 16:42:03 +0900 From: Masami Komiya <mkomiya(a)sonare.it> To: Wolfgang Denk <wd(a)denx.de> cc: "Sonare IT - Komiya" <mkomiya(a)sonare.it> Subject: SNTP support patch Dear Wolfgang, No time see you. I make a patch to add SNTP support and expand time server and time offset fields of DHCP support. (The roundtrip delay is ignored :-) I want to send this patch to ML, but the mail server of SourceForge does not accept from me ;_;) If you think this is useful for U-BOOT, please forward to ML. To use SNTP support, please add the define CFG_CMD_SNTP to CONFIG_COMMANDS in the configuration file of the board. The "sntp" command gets network time from NTP time server and syncronize RTC of the board. This command needs the command line parameter of server's IP address or environment variable "timeserverip". The network time is sent as UTC. So if you want to set local time to RTC, set the offset in second from UTC to the enviroment variable "time offset". If DHCP server provides time server's IP or time offset, you don't need to set the above environment variables yourself. Any advice or comment are wellcome!! Best regards. Masami Komiya ------- End of Forwarded Message

3 5

[U-Boot-Users] OCOTEA get_timer() bug
by Andrew Wozniak 06 Apr '05

06 Apr '05

I found this bug a while ago and have finally gotten around to looking at it because I needed its service. In previous posts to this email list, Wolfgang had mentioned that the "time unit" returned by get_timer() is 1 msec. Close examination of interrupt_init_cpu() at cpu/ppc4xx/interrupts.c suggests a timer interval setup of 10 msec! A quick experiment via u-boot application, shows this to be true: printf("...tic\n"); tic = get_timer(0); udelay(2000000); /* 2sec delay so that I can "see" it */ toc = get_timer(0); printf("...toc\n %d %d\n", tic, toc); run it: ...tic ...toc 1278 1478 therefore: 200 = delta 2sec/200 = 10msec time unit from get_timer() I've tested the following and propose it as a fix, replace this: val = gd->bd->bi_intfreq/100; /* 10 msec */ with: val = gd->bd->bi_intfreq/1000; /* 1 msec */ I've also tested some of the network related functions to insure that no timeout conditions have appeared. I want to post this patch but would prefer a code review from those that are more familiar with get_timer() use within the OCOTEA codebase. Sorry for the long post, Andrew

4 9

Re: Re: [U-Boot-Users] FEC in mcf52x2
by wroberts1＠cox.net 05 Apr '05

05 Apr '05

Yea that fec_t structure works fine. However the FEC driver was setting RCR[MAX_FL] to zero, so it was only getting rx frame length violation. I had to do this: #define OPT_FRAME_SIZE (PKT_MAXBUF_SIZE << 16) fecp->fec_r_cntrl = OPT_FRAME_SIZE | FEC_RCNTRL_MII_MODE | FEC_RCNTRL_DRT; its fast enough. takes under four seconds to transfer this 1.8Mbyte image. > From: Zachary Landau <kapheine(a)gmail.com> > Date: 2005/04/05 Tue PM 12:19:45 EDT > To: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] FEC in mcf52x2 > > On Apr 4, 2005 7:06 PM, wroberts1(a)cox.net <wroberts1(a)cox.net> wrote: > > I was trying to do an tftp transfer from u-boot-1.1.2 on an > > mcf5282. The fec driver in there does not seem to be > > functioning. Is this driver functional on the mcf5272c3? > > The FEC structure in immap_5282.h is wrong. Try this: > > typedef struct fec { > uint res1; > uint fec_ievent; > uint fec_imask; > uint res2; > uint fec_r_des_active; > uint fec_x_des_active; > uint res3[3]; > uint fec_ecntrl; > uint res4[6]; > uint fec_mii_data; > uint fec_mii_speed; > > uint res5[7]; > uint fec_mibc; > uint res6[7]; > uint fec_r_cntrl; > uint res7[15]; > uint fec_x_cntrl; > uint res8[7]; > uint fec_addr_low; uint fec_addr_high; > uint fec_opd; > uint res9[10]; > uint fec_ihash_table_high; > uint fec_ihash_table_low; > > uint fec_ghash_table_high; > uint fec_ghash_table_low; > uint res10[7]; > uint fec_tfwr; > uint res11; > uint fec_r_bound; > uint fec_r_fstart; > uint res12[11]; > uint fec_r_des_start; > uint fec_x_des_start; > uint fec_r_buff_size; > } fec_t; > > > > -- > Zachary P. Landau <kapheine(a)gmail.com> > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users >

3 2

[U-Boot-Users] FEC in mcf52x2
by wroberts1＠cox.net 05 Apr '05

05 Apr '05

I was trying to do an tftp transfer from u-boot-1.1.2 on an mcf5282. The fec driver in there does not seem to be functioning. Is this driver functional on the mcf5272c3? Also keep in mind I had to put in sdram init and other initialization like pin assignment register settings, because this is executing from the end of sdram. The FEC appears to not be running since the transmitter never becomes ready: -> tftp 10000 image.bin Eth Addrs: 00:09:91:1f:b3:44 TFTP from server 10.32.48.37; our IP address is 10.32.48.199 Filename 'image.bin'. Load address: 0x10000 Loading: TX timeout fec.c[124] eth_send: cycles: 100 status: 8c00 retry cnt: 0 T TX timeout fec.c[124] eth_send: cycles: 100 status: ac00 retry cnt: 0

3 2

[U-Boot-Users] Query related to POST of SDRAM
by Vikrant_Basotra 05 Apr '05

05 Apr '05

Hi All, In file post/memeory.c the following comment is there /* * This is 64 bit wide test patterns. Note that they reside in ROM * (which presumably works) and the tests write them to RAM which may * not work. * * The "otherpattern" is written to drive the data bus to values other * than the test pattern. This is for detecting floating bus lines. * */ This comment gives an hint that this code is specifically for the 64 bit wide SDRAM only. I ran the same code on the ep8248 board in which the port size of the RAM is 32 bits it worked there, didn't throw any error. I just want to make it sure that, if the port size of the RAM is 32 bits will this test work with out any modifications or do I have to make some changes. Regards, Vikrant ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. **************************************************************************

3 2

[U-Boot-Users] PCI Bridge on 8272ADS
by Vitaly Bordug 04 Apr '05

04 Apr '05

Hi Wolfgang, I have a small question - do you have any comments/objection on adding support for PCI bridge of 8272ADS to the CVS? It turned out now, that this can solve amount of problems concerning too slow board startup (http://ozlabs.org/pipermail/linuxppc-embedded/2005-March/017447.html) . In short, some PCI cards need the udelay up to (1000000) after deassertion of RST#, which is... slow, at least. While doing all necessary init in the firmware, enough time will almost surely be spent after clearing RST, so that resetting and delay can be eliminated from the kernel code. -- Sincerely, Vitaly

2 1

Re: [U-Boot-Users] CFI driver
by Wolfgang Denk 04 Apr '05

04 Apr '05

In message <1B848D3797CA9841B0A46694F055A67A02FBBA86(a)MW-AUS02.mtwk.sps.mot.com> you wrote: > Here is the patch. ... > --- u-boot-pq3-base/drivers/cfi_flash.c 2004-08-06 13:08:19.000000000 > -0500 > +++ u-boot-pq3-for-release/drivers/cfi_flash.c 2004-10-27 > 16:02:34.028749216 -0500 > @@ -10,6 +10,11 @@ > * Ed Okerson > * Modified to work with little-endian systems. > * > + * Copyright (C) 2004 > + * York Sun > + * Modified to support 8-bit port and 32-bit chip, not verified > + * Modified to support polling DQ7 and DQ6 for AMD flash > + * The patch was corrupted by your mailer; I restored it. Nevetheless, there were a few problems with some boards -- I guess you didn't bother to run the "MAKEALL" script, did you? I tried to fix the problems, but you should have a look at my changes and re-test. My own tests are not so positive - I got a "Timeout writing to Flash" error on the first board I tried (which was working fine before applying the patch). Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de O Staat! Wie tief dir alle Besten fluchen! Du bist kein Ziel. Der Mensch muß weiter suchen. - Christian Morgenstern

2 1

[U-Boot-Users] uboot port issue
by Srivatsan 04 Apr '05

04 Apr '05

Dear all, According to the previous replies I got for this query to check up the memory map, the IMMR is mapped to 0xff000000 and all the other memory maps were also checked up. It looks fine. But When it was tried to access the gd->dp_alloc_base = CPM_DATAONLY_BASE, the system gets a reset. Can anyone clarify a doubt regarding gd? /* Pointer is writable since we allocated a register for it */ gd = (gd_t *) (CFG_INIT_RAM_ADDR + CFG_GBL_DATA_OFFSET); gd pointer seems as though it isn't writable in my case. Have I missed on something. (meaning address of gd doesn't change) FYI, the macros defined are: #define CPM_DATAONLY_BASE ((uint)128) #define CPM_DATAONLY_SIZE ((uint)(16 * 1024) - CPM_DATAONLY_BASE) #define CFG_INIT_RAM_ADDR CFG_IMMR - defined as 0xff000000 #define CFG_RAM_INIT_END 0x4000 (Another doubt, this is the end address of DPRAM1 for MPC8280 processor but in MPC8260ADS (modified for pq2fadsZu) config file this value is defined as 0x2000. Can anyone tell me the correct value to be configured for CFG_RAM_INIT_END for MPC8280 processor?) Please give me a pointer where the problem can be ? My target is a Analogue and Micro Rattler board (MPC8280). Also I have applied the patches by Yuli Barcohen for Analogue and Micro rattler board. With Regards, C.R.Srivatsan

1 0

Re: [U-Boot-Users] Does CFG_CMD_SDRAM only use for SDRAM DIMMs?
by Sam Song 04 Apr '05

04 Apr '05

Frank <frannk_m1(a)yahoo.com> wrote: > isdram... Thanks for this hint. Uh, but my problem came out of lacking the related configuration "CFG_CMD_I2C". From common/cmd_i2c.c, CFG_CMD_SDRAM is included in the body of CFG_CMD_I2C:-) > > Wolfgang Denk <wd(a)denx.de> wrote: > > > You are expected to check the README before > > > posting. > > > > I did:-) Uhmmm, I didn't read the code:-( > > > It says: > > > > > > CFG_CMD_SDRAM * print SDRAM configuration > > > information Well, should we add a note beside it like "Must be used with CFG_CMD_I2C" to show their relationship? Best regards, Sam _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

3 2

[U-Boot-Users] error when compile U-Boot
by Kenton Lau 04 Apr '05

04 Apr '05

Hi,all. I try to compile U-Boot (version u-boot-1.1.2), after #make all and there print mistake as : arm-linux-gcc -Wa,-gstabs -D__ASSEMBLY__ -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0xa3080000 -I/root/download/u-boot-1.1.1/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv5 -mtune=strongarm1100 -c -o cpu/pxa/start.o /root/download/u-boot-1.1.1/cpu/pxa/start.S /root/download/u-boot-1.1.1/cpu/pxa/start.S: Assembler messages: /root/download/u-boot-1.1.1/cpu/pxa/start.S:121: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:122: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:143: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:145: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:360: Error: internal_relocation (type: OFFSET_IMM) not fixed up my arm-linux-gcc's version is 3.2.1 . Is it the problem from? I hear that if using version 2.X.X will work , is it? How can I overcome the problem using arm-linux-gcc(ver 3.2.1)? Thanks ! Kenton Lau

1 0

[U-Boot-Users] error when compile U-Boot
by Kenton Lau 04 Apr '05

04 Apr '05

Hi,all. I try to compile U-Boot (version u-boot-1.1.2), after #make all and there print mistake as : arm-linux-gcc -Wa,-gstabs -D__ASSEMBLY__ -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0xa3080000 -I/root/download/u-boot-1.1.1/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv5 -mtune=strongarm1100 -c -o cpu/pxa/start.o /root/download/u-boot-1.1.1/cpu/pxa/start.S /root/download/u-boot-1.1.1/cpu/pxa/start.S: Assembler messages: /root/download/u-boot-1.1.1/cpu/pxa/start.S:121: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:122: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:143: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:145: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:360: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:361: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:366: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:367: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:372: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:373: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:378: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:379: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:384: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:385: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:408: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:409: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:414: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:415: Error: internal_relocation (type: OFFSET_IMM) not fixed up my arm-linux-gcc's version is 3.2.1 . Is it the problem from? I hear that if using version 2.X.X will work , is it? How can I overcome the problem using arm-linux-gcc(ver 3.2.1)? Thanks ! Kenton Lau

1 0

[U-Boot-Users] error when compile U-Boot
by Kenton Lau 04 Apr '05

04 Apr '05

Hi,all. I try to compile U-Boot (version u-boot-1.1.2), after #make all and there print mistake as : arm-linux-gcc -Wa,-gstabs -D__ASSEMBLY__ -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0xa3080000 -I/root/download/u-boot-1.1.1/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv5 -mtune=strongarm1100 -c -o cpu/pxa/start.o /root/download/u-boot-1.1.1/cpu/pxa/start.S /root/download/u-boot-1.1.1/cpu/pxa/start.S: Assembler messages: /root/download/u-boot-1.1.1/cpu/pxa/start.S:121: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:122: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:143: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:145: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:360: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:361: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:366: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:367: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:372: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:373: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:378: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:379: Error: internal_relocation (type: OFFSET_IMM) not fixed up /root/download/u-boot-1.1.1/cpu/pxa/start.S:384:

1 0

[U-Boot-Users] make: *** [u-boot] Error 139
by Anthony Russello 04 Apr '05

04 Apr '05

Hi, I'm trying to compile u-boot version 1.1.2 unmodifed on an iBook G4 with the following specs: glibc: 2.3.4 gcc: 3.4.3 binutils: 2.15.90.0.3-r3 Here are the steps I'm using, please let me know if I've screwed something up: make Sandpoint8245_config make The build appears to go through fine until near the end, where it is trying to use ld with the option: ...-Map u-boot.map -o u-boot Then I see this every time in the same place: make: *** [u-boot] Error 139 u-boot.map is empty at this point. The exact same thing happens when I try to build u-boot using a cross compiler built on an x86 machine for a powerpc 603e cpu. u-boot.map is also empty Also, I get the exact same error when trying to do the same task on a Pegasos machine running Debian. The only difference on the Pegasos machine is that it actually gets part way through creating u-boot.map.u-boot.map actually contains some data. Any help with this would be greatly appreciated. My attempts to look the issue up through google have yielded results like "check the hardware, bad ram or disk corruption", or, "it's the fault of binutils 2.15". Any assistance would be greatly appreciated, as I've wasted two days changing and rebuilding cross compilers, and testing on different machines. Thanks in advance, Anthony

4 7