That's what I'm trying to do. If I don't select xscale (marked specifically as for Gumstix basix/connex) and use the default generic-arm, then the build croaks immediately. The eabi default selection encounters unclean build scripts which are hard to clean up (and so I assume eabi was not what most people are using). Perhaps the eabi build issues got cleaner by rev 1491, so I'm trying to build it again.
I'll check the libdl as you indicate...
On 8/2/07, Peter Lu <email@example.com > wrote:
> The xscale option is present in the 1161 build as well (since my hardware
> apparently has an xscale DSP coprocessor). The oabi option was chosen
> because the eabi (default) option ends up with a faulty build environment,
> where I had to fix too many things in ways that could cause more problems
> than cure. For rev 1491, with oabi option, the only fix-up I needed to do
> to the source was clean the typo in build_arm_nofpu/wpa_supplicant-
> 0.5.7/Makefile, changing the "==" to "=".
> Of course in 1161, there was no oabi/eabi choice.
> In 14xx, run_init_process calls kernel_execve while in 1161, it calls
> execve, in file sys_arm.c. But the actual code in the exec subroutines are
> the same. A lot other code changed, however. I really don't understand how
> the 14xx builds work for others if there are issues with core kernel code.
> The exec stuff depends a lot on stack arrangement, so perhaps oabi verses
> eabi use different stack frames. I will now try to build a 14xx kernel
> using eabi, if the fixups don't stop me in my track first.
Wouldn't it make sense to just do a default build, install the u-boot,
rootfs and uImage that goes with it and then try to figure out what's
different between the "stock" 14xx build and your 14xx customized
I know when I first started using arm, I had to build busybox
statically in order to get init to run.
It requires that the dynamic loader (/lib/libdl-0.9.29.so) match up
with the uClibc that you're using. That was one of the things that
burned me in the early days - forgetting to ensure that libdl was
Vancouver, BC, Canada
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
gumstix-users mailing list