Hi,
A few answers / thoughts, below (marked with RMo). Thanks for all the help and suggestions! ... Russell On Wed, Jan 5, 2011 02:23 PM, Khem Raj <[email protected]> wrote: > On Wed, Jan 5, 2011 at 10:49 AM, Russell Morris > <[email protected]> wrote: > > Hi, > > > > > > > > Let me try to answer a few questions in one email ... :-). First of all, I > > tried the patch - unfortunately no joy. It does the same thing as earlier > > builds - let me try to explain, which will hopefully also answer the > > questions below. > > > > > > > > I applied the patch, and rebuilt from scratch with the minimal distro > > (deleted the TMPDIR completely before building). I built the > > helloworld-image, to get a statically linked executable, and also because > > it's a pretty small (=faster) build. > > OK thats bad. Now can you recompile the kernel with user debugging > enabled ? and reboot then it will dump lot more info on console on > error you need to turn on CONFIG_DEBUG_USER in .config [RMo] Sorry, a dumb question here - but how do I do this? I can see .config in the temp directory - is this where you want me to modify it? > > > > > > > > > I then looked at the helloworld executable, and a few interesting notes, > > > > - if I readelf -h helloworld, it reports "Version5 EABI" ... so I assume > > arm5te still? > > thats EABI version it has nothing to do with ARM architecture versions [RMo] OK, thanks! > > > > > - if I try to run helloworld using qemu-arm, it runs fine ... with no cpu > > selected (but I did some checking, and the default cpu for qemu-arm is the > > arm5te). If I try to run with a -cpu arm920t option I get the error message > > "qemu: uncaught target signal 4 (Illegal instruction) - core dumped" > > > > OK good so it seems there is still some intructions generated which > are not supported in armv4t [RMo] That's what it seems like. To confirm - what is the best way to test this ... with qemu-arm, and/or on the target? Just trying to make sure I test it in a way that makes sense! > > > - I was not able to run this on the target right now, as I'm not near it > > ... but when I did before I either got a core dump (illegal instruction), > > or it said basically that the file was not found (depending on the > > executable I tried to run). > > Yes it wont change I think. [RMo] Definitely agreed. > > > > > > > > > One more interesting fact - if I go inside TMPDIR, and then inside > > work/armv4t-oe-linux-gnueabi/gcc-cross-4.5-r28.0+svnr167948/gcc-4_5-branch/testsuite/gcc.target/arm, > > there is some sort of test file, with a filename of pr42235.c. Oddly > > enough the first line in this file says ... /* { dg-options "-mthumb -O2 > > -march=armv5te" } */ > > > thats just a gcc dejaGNU regression testcase it does not mean anything > for compiling the root file system [RMo] Ok, thanks! > > > > > > Hopefully this all makes sense. I think this says that the executable is > > still targeting an armv5te ... but I could be wrong! Unfortunately it > > wouldn't be the first time I was off base, and certaintly it won't be the > > last ... :-(. > > > > > > > > Thanks for all your help! > > as koen suggested try it with angstrom-2008 and see if that helps too. [RMo] Absolutely - started already. I thought you were looking for the minimal distro, but I may have misunderstood. In any case, trying this now ... :-). > > > > > > > > > ... Russell > > > > > > > > > > > > > > On Wed, Jan 5, 2011 11:45 AM, Khem Raj <[email protected]> wrote: > > > > > >> > > On Wed, Jan 5, 2011 at 7:11 AM, Phil Blundell <[email protected]> wrote: > >> > On Wed, 2011-01-05 at 08:48 -0600, Russell Morris wrote: > >> >> Just to confirm - have you run these on an armv4t target? Only asking > >> >> because my build completes fine, but the executables don't seem to run > >> >> on the target. > >> > > >> > What exactly happens when you try to run those executables? Have you > >> > inspected them to see if they look like the right kind of thing, and/or > >> > compared them to working ones? > >> > > >> > p. > >> > > >> > > >> > >> > >> yes as Phil asked you should try to localize the offending code in the > >> faulty binary. So try to enable > >> kernel debugging messages so it tells you where its faulting. > >> Secondly if you can take a working system > >> and see if the new binary faults in same way ? if not then link the > >> binary statically and run it again on working > >> system and see if it faults again. If it does then you can debug it > >> > > >> > _______________________________________________ > >> > Openembedded-devel mailing list > >> > [email protected] > >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > >> > > >> > >> _______________________________________________ > >> Openembedded-devel mailing list > >> [email protected] > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > >> > > _______________________________________________ > > Openembedded-devel mailing list > > [email protected] > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > > > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
