hi,
I am trying to compile u-boot-1.3.2 for beagleboard but getting
following errors
It is asking about version NUMBER confliction..
-Map u-boot.map -o u-boot
arm-none-linux-gnueabi-ld: ERROR: Source object /usr/bin/arm-tc/
arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/
libgcc.a(_muldi3.o) has EABI version 4, but target u-boot has EABI
version 0
arm-none-linux-gnueabi-ld: failed to merge target specific data of
file /usr/bin/arm-tc/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/
4.2.0/libgcc.a(_muldi3.o)
make: *** [u-boot] Error 1
please help me to find out it's solution..
thank you.
Normally U-Boot doesn't use any library code from the tool chain. If I
remember correctly, U-Boot should be totally independent from
libraries coming with tool chain. The error message above sounds like
you used some multiplication/division in your code (not sure what
_muldi3.o exactly does, though). Scan you code for multiply/divide
operations and try to avoid them. And if you can't avoid them, have a
look to U-Boot's lib_arm directory and try to use only math available
there.
Can you share them? Are they against git u-boot-1.3.2? Reviewing
patches here early before sending them to U-Boot ML could be helpful.
I would also like to see the patches.
and when I tried it on board it goes as following.
Texas Instruments X-Loader 1.41
Starting on with MMC
Reading boot sector
143272 Bytes Read from MMC
Starting OS Bootloader from MMC...
U-Boot 1.3.2-dirty (Mar 25 2008 - 16:38:58)
OMAP3430-GP rev 2, CPU-OPP2 L3-133MHz
TI 3430Beagle 2.0 Version + mDDR (Boot ONND)
DRAM: 128 MB
Sorry, as I don't know the board, is this good or bad?
Dirk
Looks like X-Loader ran fine. You might want to change the "TI 3430Beagle 2.0 Version" string. Perhaps to something like "OMAP3 Beagle Board revision 2.0 (LPDDR + NAND)". OneNAND is not used on revision 2.0, but I believe that the U-Boot should support both the NAND and the OneNAND.
They fix namespace collision and remove some assumptions from the
makefiles. These patches come from the openmoko project based on some
hacks I sent them.
> and when I tried it on board it goes as following.
> Texas Instruments X-Loader 1.41
> Starting on with MMC
> Reading boot sector
> 143272 Bytes Read from MMC
> Starting OS Bootloader from MMC...
> U-Boot 1.3.2-dirty (Mar 25 2008 - 16:38:58)
> OMAP3430-GP rev 2, CPU-OPP2 L3-133MHz
> TI 3430Beagle 2.0 Version + mDDR (Boot ONND)
> DRAM: 128 MB
Sorry, as I don't know the board, is this good or bad?
After including these patches I could compile u-boot-1.3.2 for
beagleboard and as I mentioned before it is running on board. some
errors are there regarding i2c and nand which I am trying to
remove .
I then tried to apply them to recent U-Boot git and had a look to
them. And, hmmh, I wonder why they should be useful for beagle board?
Any hints are appreciated, most probably I missed anything
- uboot-eabi-fix-HACK.patch doesn't apply to recent U-Boot git, as in
git there are no
uboot shouldn't care about being EABI or not (it's bare-metal), but
the uboot dudes hardcode the old ABI *and* have namespace clash with
libgcc.recent due to them using gcc 2.ancient and gcc 3.ancient. So
with any recent (gcc >=4.x) softfloat capable toolchain you run into
problems.
So the arm920t patch does nothing for cortex, but it is probably
needed for the cortex uboot stuff.
The situation is actually more complicated as *some* boards have a
sane makefile, without hardcoding apcs32, while others do.
hi all,
we are trying to make competable git.u-boot to omap3530beagle. as
per regarding of the changes i.e patch to upload. it could be
possiable only in next week.
still we have some stuff to surpass .
what did we get till now is following.
Texas Instruments X-Loader 1.41
Starting on with MMC
Reading boot sector
127488 Bytes Read from MMC
Starting OS Bootloader from MMC...
U-Boot 1.3.2-dirty (Mar 25 2008 - 20:09:21)
OMAP3430-GP rev 2, CPU-OPP2 L3-133MHz
TI 3430Beagle 2.0 Version + mDDR (Boot ONND)
DRAM: 128 MB /* upto this portion we get earlier */
NAND: 0 MiB
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
actually we r trying to resolve the
I2C and NAND issue..
let's what happens next...
hi all,
we are trying to make competable git.u-boot to omap3530beagle. as
per regarding of the changes i.e patch to upload. it could be
possiable only in next week.
still we have some stuff to surpass .
I think it would be better for all if you shared the small patches
that you've made to get it to go as far as you have, rather than
waiting for you to debug I2C and NAND. By sharing early, you get
feedback early and complete sooner.
hi all,
we are trying to make competable git.u-boot to omap3530beagle. as
per regarding of the changes i.e patch to upload. it could be
possiable only in next week.
still we have some stuff to surpass .
I think it would be better for all if you shared the small patches
that you've made to get it to go as far as you have, rather than
waiting for you to debug I2C and NAND. By sharing early, you get
feedback early and complete sooner.
YES! Thanks for this!
I think there is some difference between doing some closed source SW a
customer wants "perfect" SW at a dedicated release date and open
source SW programming.
Open source follows more "Release Early, Release Often". Even if there
are still issues. As Jason mentioned above: People then can early see
what you are doing, can help and review.
See attachment for restulting patch. Any hints why this is
beagle/cortex related?
- fix-arm920t-eabi.patch applies mainly clean (some offsets). See
update in attachment.
Here I wonder why changing cpu/arm920t/config.mk should be helpful for
Cortex-A8 CPU?
- Any hints why *any* changes for EABI are necessary for U-Boot at
all? Why does U-Boot care about EABI?
uboot shouldn't care about being EABI or not (it's bare-metal),
Yes, this is my understanding, too.
but
the uboot dudes hardcode the old ABI *and* have namespace clash with
libgcc.recent due to them using gcc 2.ancient and gcc 3.ancient. So
with any recent (gcc >=4.x) softfloat capable toolchain you run into
problems.
The patches are toolchain dependent then. Right?
So the arm920t patch does nothing for cortex, but it is probably
needed for the cortex uboot stuff.
The situation is actually more complicated as *some* boards have a
sane makefile, without hardcoding apcs32, while others do.
I then understand the two patches we talk about here not as "100% beagle/cortex patches", but as hints "if you have trouble building beagle/cortex uboot, have a look to these patches and do sth similar in your configuration as well"?
>>See attachment for restulting patch. Any hints why this is
>>beagle/cortex related?
>>- fix-arm920t-eabi.patch applies mainly clean (some offsets). See
>>update in attachment.
>>Here I wonder why changing cpu/arm920t/config.mk should be helpful for
>>Cortex-A8 CPU?
>>- Any hints why *any* changes for EABI are necessary for U-Boot at
>>all? Why does U-Boot care about EABI?
> uboot shouldn't care about being EABI or not (it's bare-metal),
Yes, this is my understanding, too.
> but
> the uboot dudes hardcode the old ABI *and* have namespace clash with
> libgcc.recent due to them using gcc 2.ancient and gcc 3.ancient. So
> with any recent (gcc >=4.x) softfloat capable toolchain you run into
> problems.
The patches are toolchain dependent then. Right?
Their essence is to remove hardcodes, which get triggered with modern
toolchains, but shouldn't break 'old' toolchains. I don't know what
the uboot people think of them, so let's say they are toolchain
dependant
> So the arm920t patch does nothing for cortex, but it is probably
> needed for the cortex uboot stuff.
> The situation is actually more complicated as *some* boards have a
> sane makefile, without hardcoding apcs32, while others do.
I then understand the two patches we talk about here not as "100%
beagle/cortex patches", but as hints "if you have trouble building
beagle/cortex uboot, have a look to these patches and do sth similar
in your configuration as well"?
That is indeed the idea. Maybe they should be in the uboot faq (is
such a thing exists).
Are the current beagleboard binaries and patches online somewhere
already?
