Re: H1940 Boot Issues -> Executable Build Problems?

Re: H1940 Boot Issues -> Executable Build Problems?

[Russell Morris]

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.

 

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?

- 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"

- 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).

 

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" }  */


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!

 

... Russell

 

 


On Wed, Jan 5, 2011 11:45  AM, Khem Raj <raj.khem@gmail.com> wrote:


> 
On Wed, Jan 5, 2011 at 7:11 AM, Phil Blundell <philb@gnu.org> 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
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
From gcho-openembedded-devel@m.gmane.org Wed Jan 05 21:09:11 2011
Received: from lo.gmane.org ([80.91.229.12])
	by linuxtogo.org with esmtp (Exim 4.72)
	(envelope-from <gcho-openembedded-devel@m.gmane.org>)
	id 1PaZfT-0000sz-Nl for openembedded-devel@lists.openembedded.org;
	Wed, 05 Jan 2011 21:09:11 +0100
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <gcho-openembedded-devel@m.gmane.org>)
	id 1PaZf5-00071c-KC for openembedded-devel@lists.openembedded.org;
	Wed, 05 Jan 2011 21:08:47 +0100
Received: from ip545070eb.adsl-surfen.hetnet.nl ([84.80.112.235])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00 for <openembedded-devel@lists.openembedded.org>;
	Wed, 05 Jan 2011 21:08:47 +0100
Received: from k.kooi by ip545070eb.adsl-surfen.hetnet.nl with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <openembedded-devel@lists.openembedded.org>;
	Wed, 05 Jan 2011 21:08:47 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: openembedded-devel@lists.openembedded.org
From: Koen Kooi <k.kooi@student.utwente.nl>
Date: Wed, 05 Jan 2011 21:08:33 +0100
Lines: 24
Message-ID: <ig2j41$65t$1@dough.gmane.org>
References: <1294253374472299500@rkmorris.us>
Mime-Version: 1.0
Content-Type: text/plain; charset

Re: H1940 Boot Issues -> Executable Build Problems?

[Khem Raj]

On Wed, Jan 5, 2011 at 10:49 AM, Russell Morris
<openembedded@rkmorris.us> 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

>
>
>
> 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

>
> - 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

> - 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.

>
>
>
> 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
>
>
> 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.

>
>
>
> ... Russell
>
>
>
>
>
>
> On Wed, Jan 5, 2011 11:45  AM, Khem Raj <raj.khem@gmail.com> wrote:
>
>
>>
> On Wed, Jan 5, 2011 at 7:11 AM, Phil Blundell <philb@gnu.org> 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
>> > Openembedded-devel@lists.openembedded.org
>> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>> >
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: H1940 Boot Issues -> Executable Build Problems?

[Russell Morris]

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 <raj.khem@gmail.com> wrote:


> 
On Wed, Jan 5, 2011 at 10:49 AM, Russell Morris
> <openembedded@rkmorris.us> 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 <raj.khem@gmail.com> wrote:
> >
> >
> >>
> > On Wed, Jan 5, 2011 at 7:11 AM, Phil Blundell <philb@gnu.org> 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
> >> > Openembedded-devel@lists.openembedded.org
> >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >> >
> >>
> >> _______________________________________________
> >> Openembedded-devel mailing list
> >> Openembedded-devel@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >>
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
From openembedded@rkmorris.us Thu Jan 06 05:38:34 2011
Received: from vms173005pub.verizon.net ([206.46.173.5])
	by linuxtogo.org with esmtp (Exim 4.72)
	(envelope-from <openembedded@rkmorris.us>) id 1PahcQ-0007mo-86
	for openembedded-devel@lists.openembedded.org;
	Thu, 06 Jan 2011 05:38:34 +0100
Received: from server ([unknown] [71.164.183.134]) by vms173005.mailsrvcs.net
	(Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16
	2009)) with ESMTPA id <0LEL00LQZ3J4PJA0@vms173005.mailsrvcs.net> for
	openembedded-devel@lists.openembedded.org; Wed,
	05 Jan 2011 22:37:52 -0600 (CST)
Received: from server (127.0.0.1) by server (Axigen)
	with ESMTPSA id 105A1C; Wed, 05 Jan 2011 22:37:43 -0600
Received: from [192.168.1.10] by rkmorris.us with HTTP; Wed,
	05 Jan 2011 22:37:41 -0600
From: Russell Morris <openembedded@rkmorris.us>
Date: Wed, 05 Jan 2011 22:37:41 -0600
X-Mailer: Axigen WebMail
To: openembedded-devel@lists.openembedded.org
Message-id: <1294288661406628500@rkmorris.us>
In-reply-to: <1294268823607761500@rkmorris.us>
References: <1294253374472299500@rkmorris.us>
	<AANLkTikeER27XKSAJQ_A+ujdKAqtuowqZBD0jsG0ZoES@mail.gmail.com>
	<1294268823607761500@rkmorris.us>
Importance: Normal
MIME-version: 1.0
X-AxigenVirus-Level: 1
X-AxigenSpam-Level: 5
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Content-Filtered-By: Mailman/MimeDel 2.1.11
Subject: Re: [oe] H1940 Boot Issues -> Executable Build Problems?
X-BeenThere: openembedded-devel@lists.openembedded.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: openembedded-devel@lists.openembedded.org
List-Id: Using the OpenEmbedded metadata to build Distributions
	<openembedded-devel.lists.openembedded.org>
List-Unsubscribe: <http://lists.linuxtogo.org/cgi-bin/mailman/options/openembedded-devel>,
	<mailto:openembedded-devel-request@lists.openembedded.org?subject

Re: H1940 Boot Issues -> Executable Build Problems?

[Khem Raj]

On Wed, Jan 5, 2011 at 8:37 PM, Russell Morris <openembedded@rkmorris.us> wrote:
> Hi,
>
> OK, a few more updates ...
> - I built using the angstrom-2008.1 distro, but I have the same issue. I also ran the helloworld application on the target as well, getting the error message "Illegal instruction" (the same as qemu, which I guess is good).


If you can reproduce the issue on target then I would suggest that run
the helloworld under gdb or gdbserver on target and see where its
happening.

> - I found the .config file that you are referring to, and made this change. I built and ran the debug kernel, but no more information is provided (other than "Illegal instruction").
> - as a side note, I have to edit sumversion.c to fix a "known" issue (http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg08279.html). You may want to update this in the master branch.
>
> Any other ideas?
>
> Thanks,
> ... Russell
>
>
>
>
> On Wed, Jan 5, 2011 05:07  PM, Russell Morris <openembedded@rkmorris.us> wrote:
>> 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 <raj.khem@gmail.com> wrote:
>>
>>
>> >
>> On Wed, Jan 5, 2011 at 10:49 AM, Russell Morris
>> > <openembedded@rkmorris.us> 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 <raj.khem@gmail.com> wrote:
>> > >
>> > >
>> > >>
>> > > On Wed, Jan 5, 2011 at 7:11 AM, Phil Blundell <philb@gnu.org> 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
>> > >> > Openembedded-devel@lists.openembedded.org
>> > >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>> > >> >
>> > >>
>> > >> _______________________________________________
>> > >> Openembedded-devel mailing list
>> > >> Openembedded-devel@lists.openembedded.org
>> > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>> > >>
>> > > _______________________________________________
>> > > Openembedded-devel mailing list
>> > > Openembedded-devel@lists.openembedded.org
>> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>> > >
>> >
>> > _______________________________________________
>> > Openembedded-devel mailing list
>> > Openembedded-devel@lists.openembedded.org
>> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>> >
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: H1940 Boot Issues -> Executable Build Problems?

[Russell Morris]

Hi,

 

Unfortunately I can't really do much on the target - as I can't get to the point where I can log in (no ssh connection, no local keyboard, etc.) ... :-(. I may be able to try to debug it when run through qemu-arm ... have you ever tried that?

 

I'll do some poking around to see if this is possible.

 

Thanks,

... Russell

 


On Thu, Jan 6, 2011 00:15  AM, Khem Raj <raj.khem@gmail.com> wrote:


> 
On Wed, Jan 5, 2011 at 8:37 PM, Russell Morris <openembedded@rkmorris.us> wrote:
> > Hi,
> >
> > OK, a few more updates ...
> > - I built using the angstrom-2008.1 distro, but I have the same issue. I also ran the helloworld application on the target as well, getting the error message "Illegal instruction" (the same as qemu, which I guess is good).
> 
> 
> If you can reproduce the issue on target then I would suggest that run
> the helloworld under gdb or gdbserver on target and see where its
> happening.
> 
> > - I found the .config file that you are referring to, and made this change. I built and ran the debug kernel, but no more information is provided (other than "Illegal instruction").
> > - as a side note, I have to edit sumversion.c to fix a "known" issue (http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg08279.html). You may want to update this in the master branch.
> >
> > Any other ideas?
> >
> > Thanks,
> > ... Russell
> >
> >
> >
> >
> > On Wed, Jan 5, 2011 05:07  PM, Russell Morris <openembedded@rkmorris.us> wrote:
> >> 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 <raj.khem@gmail.com> wrote:
> >>
> >>
> >> >
> >> On Wed, Jan 5, 2011 at 10:49 AM, Russell Morris
> >> > <openembedded@rkmorris.us> 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 <raj.khem@gmail.com> wrote:
> >> > >
> >> > >
> >> > >>
> >> > > On Wed, Jan 5, 2011 at 7:11 AM, Phil Blundell <philb@gnu.org> 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
> >> > >> > Openembedded-devel@lists.openembedded.org
> >> > >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >> > >> >
> >> > >>
> >> > >> _______________________________________________
> >> > >> Openembedded-devel mailing list
> >> > >> Openembedded-devel@lists.openembedded.org
> >> > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >> > >>
> >> > > _______________________________________________
> >> > > Openembedded-devel mailing list
> >> > > Openembedded-devel@lists.openembedded.org
> >> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >> > >
> >> >
> >> > _______________________________________________
> >> > Openembedded-devel mailing list
> >> > Openembedded-devel@lists.openembedded.org
> >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >> >
> >> _______________________________________________
> >> Openembedded-devel mailing list
> >> Openembedded-devel@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >>
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
From openembedded@rkmorris.us Thu Jan 06 15:38:29 2011
Received: from vms173009pub.verizon.net ([206.46.173.9])
	by linuxtogo.org with esmtp (Exim 4.72)
	(envelope-from <openembedded@rkmorris.us>) id 1Paqyz-00080R-46
	for openembedded-devel@lists.openembedded.org;
	Thu, 06 Jan 2011 15:38:29 +0100
Received: from server ([unknown] [71.164.183.134]) by vms173009.mailsrvcs.net
	(Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16
	2009)) with ESMTPA id <0LEL0059GVBACFA0@vms173009.mailsrvcs.net> for
	openembedded-devel@lists.openembedded.org; Thu,
	06 Jan 2011 08:37:58 -0600 (CST)
Received: from server (127.0.0.1) by server (Axigen)
	with ESMTPSA id 1BE82C; Thu, 06 Jan 2011 08:37:51 -0600
Received: from [192.168.1.12] by rkmorris.us with HTTP; Thu,
	06 Jan 2011 08:37:48 -0600
From: Russell Morris <openembedded@rkmorris.us>
Date: Thu, 06 Jan 2011 08:37:48 -0600
X-Mailer: Axigen WebMail
To: openembedded-devel@lists.openembedded.org
Message-id: <1294324668746829500@rkmorris.us>
In-reply-to: <ig3sgf$f5j$1@dough.gmane.org>
References: <1294253374472299500@rkmorris.us>
	<AANLkTikeER27XKSAJQ_A+ujdKAqtuowqZBD0jsG0ZoES@mail.gmail.com>
	<1294268823607761500@rkmorris.us>	<1294288661406628500@rkmorris.us>
	<ig3sgf$f5j$1@dough.gmane.org>
Importance: Normal
MIME-version: 1.0
X-AxigenVirus-Level: 1
X-AxigenSpam-Level: 5
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Content-Filtered-By: Mailman/MimeDel 2.1.11
Subject: Re: [oe] H1940 Boot Issues -> Executable Build Problems?
X-BeenThere: openembedded-devel@lists.openembedded.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: openembedded-devel@lists.openembedded.org
List-Id: Using the OpenEmbedded metadata to build Distributions
	<openembedded-devel.lists.openembedded.org>
List-Unsubscribe: <http://lists.linuxtogo.org/cgi-bin/mailman/options/openembedded-devel>,
	<mailto:openembedded-devel-request@lists.openembedded.org?subject

Re: H1940 Boot Issues -> Executable Build Problems?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06-01-11 05:37, Russell Morris wrote:
> Hi,
> 
> OK, a few more updates ...
> - I built using the angstrom-2008.1 distro, but I have the same issue. I also ran the helloworld application on the target as well, getting the error message "Illegal instruction" (the same as qemu, which I guess is good).
> - I found the .config file that you are referring to, and made this change. I built and ran the debug kernel, but no more information is provided (other than "Illegal instruction").
> - as a side note, I have to edit sumversion.c to fix a "known" issue (http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg08279.html). You may want to update this in the master branch.

Does your kernel have EABI turned on? If it's built using linux.inc in
OE it will, but if it isn't using linux.inc, double check. Or add
'require linux.inc' to the recipe, that usually helps a lot.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNJXVPMkyGM64RGpERAn1YAJ0ZDBCI50yTboMvzrKs6l5Upb3kGACgiN9J
XlKDkdcTtrk74k7QmIhVlQs=
=pSaG
-----END PGP SIGNATURE-----

Re: H1940 Boot Issues -> Executable Build Problems?

[Russell Morris]

[-- Attachment #1: Type: text/plain, Size: 8509 bytes --]

You bet - attached!

 

Also, just to make it clear - I'm not booting in to this executable. Rather, I'm using the (old, Familiar Linux) rootfs that I have found seems to work (together with my OE kernel), and trying to run this once I get to runlevel 5 (i.e. via a script in rc5.d that calls this). I could be wrong, but I don't think this is the problem though - as I get the same issue when running the executable using qemu-arm (with an armv4t as the target ... it works fine for armv5te).

 

Does the attached work for you? This could definitely still be operator error (i.e. me)!

 

Thanks,

... Russell


On Thu, Jan 6, 2011 00:05  AM, Khem Raj <raj.khem@gmail.com> wrote:


> 
On Wed, Jan 5, 2011 at 8:37 PM, Russell Morris <openembedded@rkmorris.us> wrote:
> > Hi,
> >
> > OK, a few more updates ...
> > - I built using the angstrom-2008.1 distro, but I have the same issue. I also ran the helloworld application on the target as well, getting the error message "Illegal instruction" (the same as qemu, which I guess is good).
> > - I found the .config file that you are referring to, and made this change. I built and ran the debug kernel, but no more information is provided (other than "Illegal instruction").
> > - as a side note, I have to edit sumversion.c to fix a "known" issue (http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg08279.html). You may want to update this in the master branch.
> >
> > Any other ideas?
> 
> Please post the helloworld binary which you are booting into. I think
> the seems to be some other issue
> 
> >
> > Thanks,
> > ... Russell
> >
> >
> >
> >
> > On Wed, Jan 5, 2011 05:07  PM, Russell Morris <openembedded@rkmorris.us> wrote:
> >> 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 <raj.khem@gmail.com> wrote:
> >>
> >>
> >> >
> >> On Wed, Jan 5, 2011 at 10:49 AM, Russell Morris
> >> > <openembedded@rkmorris.us> 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 <raj.khem@gmail.com> wrote:
> >> > >
> >> > >
> >> > >>
> >> > > On Wed, Jan 5, 2011 at 7:11 AM, Phil Blundell <philb@gnu.org> 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
> >> > >> > Openembedded-devel@lists.openembedded.org
> >> > >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >> > >> >
> >> > >>
> >> > >> _______________________________________________
> >> > >> Openembedded-devel mailing list
> >> > >> Openembedded-devel@lists.openembedded.org
> >> > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >> > >>
> >> > > _______________________________________________
> >> > > Openembedded-devel mailing list
> >> > > Openembedded-devel@lists.openembedded.org
> >> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >> > >
> >> >
> >> > _______________________________________________
> >> > Openembedded-devel mailing list
> >> > Openembedded-devel@lists.openembedded.org
> >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >> >
> >> _______________________________________________
> >> Openembedded-devel mailing list
> >> Openembedded-devel@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >>
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

[-- Attachment #2: helloworld.gz --]
[-- Type: application/octet-stream, Size: 269093 bytes --]

Re: H1940 Boot Issues -> Executable Build Problems?

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 684 bytes --]

On Thursday 06 January 2011 18:14:08 Russell Morris wrote:
> Hi Vasily,
> 
> Absolutely! I'm very glad to hear that you have it working on an h1940. I
> think I'm likely the problem ... :-(.
> 
> The file is attached. Do you have any suggestions? If you don't mind, could
> you share your local.conf file for me to try also?
> 
> Thanks!!!

Here it is, however it's not for minimal distro, and machine is rx1950 (seems 
I lost one for rx1950, but I'm sure that it differs only in machine name)

What kernel do you use on your h1940? One built via OE?

Regards
Vasily

P.S. Your mailer inserts too much empty lines in message, could you fix it 
somehow please? :)

[-- Attachment #2: local.conf --]
[-- Type: text/plain, Size: 8546 bytes --]

#
# OpenEmbedded local configuration file (sample)
#
# Please visit the Wiki at http://openembedded.org/ for more info.
#
#
# Be SURE to read this file in its entirety and the GettingStarted page on the
# wiki before proceeding.
#
# Once you have done that, remove the line at the end of this
# file and build away.
# 
# WARNING: lines starting with a space (' ') will result in parse failures.
# Remove '# ' from commented lines to activate them.
#
# NOTE: Do NOT use $HOME in your paths, BitBake does NOT expand ~ for you.  If you
# must have paths relative to your homedir use ${HOME} (note the {}'s there
# you MUST have them for the variable expansion to be done by BitBake).  Your
# paths should all be absolute paths (They should all start with a / after
# expansion.  Stuff like starting with ${HOME} or ${TOPDIR} is ok).

# Use this to specify where BitBake should place the downloaded sources into
DL_DIR = "/home/distfiles"

# Delete the line below. Then specify which .bb files to consider for
# your build. Typically this will be something like BBFILES = "/path/to/openembedded/recipes/*/*.bb"
BBFILES = "/home/anarsoul/work/openembedded/openembedded/recipes/*/*.bb"

# Use the BBMASK below to instruct BitBake to _NOT_ consider some .bb files
# This is a regulary expression, so be sure to get your parenthesis balanced.
BBMASK = ""

# Uncomment this if your host distribution has recent enough Linux
# Kernel header files.  Utilities we use to generate certain types of
# target filesystems need somewhat recent header files.
# ASSUME_PROVIDED += "linux-libc-headers-native"

# Uncomment this if you want to use a prebuilt toolchain. You will need to
# provide packages for toolchain and additional libraries yourself. You also
# have to set PATH in your environment to make sure BitBake finds additional binaries.
# ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}gcc virtual/libc"

# Uncomment this if you are building Linux 2.4 Embedix kernels.
# i.e. openzaurus-sa-2.4.18 and openzaurus-pxa-2.4.18 - and don't forget
# to rename the binaries as instructed in the Wiki.
# Most users do not need this anymore thankfully!
# ASSUME_PROVIDED += "virtual/arm-linux-gcc-2.95"

# Select between multiple alternative providers, if more than one is eligible.
PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"
PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-intermediate:gcc-cross-intermediate"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}g++:gcc-cross"
PREFERRED_VERSION_mupdf = "0.6"

# Uncomment this to specify where BitBake should create its temporary files.
# Note that a full build of everything in OpenEmbedded will take GigaBytes of hard
# disk space, so make sure to free enough space. The default TMPDIR is
# <build directory>/tmp
# Don't use symlinks in in the path to avoid problems
# TMPDIR = /usr/local/projects/oetmp

# Uncomment this to specify a machine to build for. See the conf directory
# for machines currently known to OpenEmbedded. This will automatically take care
# of TARGET_ARCH
MACHINE = "rx1950"

# Use this to specify the target architecture. Note that this is only
# needed when building for a machine not known to OpenEmbedded. Better use
# the MACHINE attribute (see above)
# TARGET_ARCH = "arm"

# Use this to specify the target operating system.  The default is "linux",
# for a normal linux system with glibc. Set this to "linux-uclibc" if you want
# to build a uclibc based system.
# Normally the DISTRO of your choosing will take care of this 
# TARGET_OS = "linux"
# TARGET_OS = "linux-uclibc"

# Uncomment this to select a distribution policy. See the conf directory
# for distributions currently known to OpenEmbedded.
# Although it no longer contain version number in the (file-)name
# openzaurus-unstable is a so called "versioned"  distro, i.e. they 
# explicitely select specific versions of various packages.
# Stay away from unversioned distros unless you really know what you are doing
DISTRO = "jlime-2010.1"

# So far, angstrom.conf sets ENABLE_BINARY_LOCALE_GENERATION
# to generate binary locale packages at build time using qemu-native and
# thereby guarantee i18n support on all devices. If your build breaks on 
# qemu-native consider disabling ENABLE_BINARY_LOCALE_GENERATION (note that
# this breaks i18n on devices with less than 128MB RAM) or installing
# a working third-party qemu (e.g. provided by your distribution) and
# adding qemu-native to ASSUME_PROVIDED. Caveat emptor, since third-party
# qemus lack patches needed to work with various OE targets.
# ENABLE_BINARY_LOCALE_GENERATION = "0"
# ASSUME_PROVIDED += "qemu-native"

# If ENABLE_BINARY_LOCALE_GENERATION is set to "1", you can limit locales
# generated to the list provided by GLIBC_GENERATE_LOCALES. This is huge
# time-savior for developmental builds. Format: list of locale.encoding pairs
# with spaces as separators.
GLIBC_GENERATE_LOCALES = "en_US.UTF-8 en_GB.UTF-8 ru_RU.UTF-8"

# Uncomment this to select a particular major kernel version if the MACHINE setting
# supports more than one major kernel version. Currently this is suported by the
# following MACHINE types: poodle, tosa and simpad.
# MACHINE_KERNEL_VERSION = "2.6"

# Uncomment one of these to build packages during the build process.
# This is done automatically if you set DISTRO (see above)
# INHERIT = "package_ipk"
# INHERIT = "package_tar"

#INHERIT += "rm_work"
INHERIT += "shr-mirrors"

# Add the required image file system types below. Valid are 
# jffs2, tar(.gz|bz2), cpio(.gz), cramfs, ext2(.gz), ext3(.gz)
# squashfs, squashfs-lzma
IMAGE_FSTYPES = "tar"

# Uncomment this if you want to keep the temporary rootfs
# diretory, this can be useful during development.
# (Note that this rootfs is NOT usuable as NFS export.)
# IMAGE_KEEPROOTFS = "1"

# Uncomment this to enable the use of ccache when building.  Due to
# the nature of our builds this is only helpful in cases when one
# is rebuilding a recipe or set of recipes, repeatedly.
# CCACHE = "${@bb.which(bb.data.getVar('PATH', d, 1), 'ccache') and 'ccache '}"

# Uncomment this to disable the parse cache (not recommended).
# CACHE = ""

# Uncomment this if you want BitBake to emit debugging output
# BBDEBUG = "yes"

# Use DEBUG_BUILD to build packages with DEBUG_OPTIMIZATION instead of
# FULL_OPTIMIZATION.
#
# DEBUG_BUILD = "1"

# If you want to have unstripped ready-to-debug binaries, set this to "no",
# although for debugging you can use automatically produced -dbg packages.
# If you need to have completely undebuggable builds, set this to "full",
# by default gnu.debuglink section is left in the binaries after stripping, so
# this might be useful if you want to have checksum-level binary consistency
# across successive builds.
# PACKAGE_STRIP = "no"

# Uncomment these to build a package such that you can use gprof to profile it.
# NOTE: This will only work with 'linux' targets, not
# 'linux-uclibc', as uClibc doesn't provide the necessary
# object files.  Also, don't build glibc itself with these
# flags, or it'll fail to build.
#
# PROFILE_OPTIMIZATION = "-pg"
# SELECTED_OPTIMIZATION = "${PROFILE_OPTIMIZATION}"
# LDFLAGS =+ "-pg"

# Uncomment this to enable parallel make.
# This allows make to spawn mutliple processes to take advantage of multiple 
# processors. Useful on SMP machines. This may break some packages - we're
# in the process of marking these so let us know if you find any.
PARALLEL_MAKE = "-j4"

# Uncomment to run multiple bitbake threads in parallel.
# Bitbake can do multiple jobs in parallel: Its a good idea make use of 
# all available resources: e.g. to download sources while some other
# piece of software is compiled.
# BB_NUMBER_THREADS = "2"

# Uncomment this if you want BitBake to emit the log if a build fails.
BBINCLUDELOGS = "yes"

# Specifies a location to search for pre-generated tarballs when fetching
# a cvs:// URI. Outcomment this, if you always want to pull directly from CVS.
#CVS_TARBALL_STASH = ""

# Uncomment this if you want to install shared libraries directly under their SONAME,
# rather than installing as the full version and symlinking to the SONAME.
# PACKAGE_SNAP_LIB_SYMLINKS = "1"

Re: H1940 Boot Issues -> Executable Build Problems?

[Russell Morris]

Hi,

 

Well, let me try this. The only real difference that I see is the distro - agreed? I'll give that a shot though!

 

The kernel I used is from OE (targeting the h1940). 

 

Thanks,

... Russell

 

 

PS: Sorry, not sure what the mailer is doing ... :-(.


On Thu, Jan 6, 2011 10:32  AM, Vasily Khoruzhick <anarsoul@gmail.com> wrote:


> 
On Thursday 06 January 2011 18:14:08 Russell Morris wrote:
> > Hi Vasily,
> > 
> > Absolutely! I'm very glad to hear that you have it working on an h1940. I
> > think I'm likely the problem ... :-(.
> > 
> > The file is attached. Do you have any suggestions? If you don't mind, could
> > you share your local.conf file for me to try also?
> > 
> > Thanks!!!
> 
> Here it is, however it's not for minimal distro, and machine is rx1950 (seems 
> I lost one for rx1950, but I'm sure that it differs only in machine name)
> 
> What kernel do you use on your h1940? One built via OE?
> 
> Regards
> Vasily
> 
> P.S. Your mailer inserts too much empty lines in message, could you fix it 
> somehow please? :)
>
From anarsoul@gmail.com Thu Jan 06 19:42:03 2011
Received: from mail-ey0-f175.google.com ([209.85.215.175])
	by linuxtogo.org with esmtp (Exim 4.72)
	(envelope-from <anarsoul@gmail.com>) id 1Paumh-0006Xm-1J
	for openembedded-devel@lists.openembedded.org;
	Thu, 06 Jan 2011 19:42:03 +0100
Received: by eya28 with SMTP id 28so7301262eya.6
	for <openembedded-devel@lists.openembedded.org>;
	Thu, 06 Jan 2011 10:41:38 -0800 (PST)
DKIM-Signature: v

Re: H1940 Boot Issues -> Executable Build Problems?

[Khem Raj]

On Thu, Jan 6, 2011 at 10:40 AM, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> On Thursday 06 January 2011 18:50:28 Russell Morris wrote:
>
>> The kernel I used is from OE (targeting the h1940).
>
> AFAIK it's pretty old. I'm using self-built kernel, linux-next tree with some
> extra patches. I can share it, so you can test if kernel is guilty :)
>

yeah that would be nice. May be the way aux vectors are passed to
application could mean
that libc tried to use wrong AT_HWCAPS which could mean that it tries
to access cp15 which is absent on this
processor can result in illegal instrs or it enables things like VFP
which again is absent so many things
can cause this problem. So I think finding if auxiliary vector is
passed correctly is important.

> Regards
> Vasily
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: H1940 Boot Issues -> Executable Build Problems?

[Russell Morris]

Hi,

 

Some updates on this - to keep everyone in the loop. First of all though - thanks very much for all the ideas and suggestions, they are very much appreciated. A special thanks to Vasily, who took the time to get me a copy of his kernel (and helped a lot with debugging)!

 

I have now been able to get my OE builds up and running on my h1940 - both console-image and opie-image are working as expected. While I admit I was sidetracked by qemu-arm not running (and it still doesn't, perhaps an armv4t bug there also?), the root cause of this is the OE generated kernel. With the kernel that Vasily provided I am able to run with the two rootfs' noted above.

 

If anyone has any things they would like me to try related to the kernel, so we can get that working in OE as well, please let me know. I would like to help out here if possible, to try to give back to OE (and try to "repay" all the help folks gave me).

 

Thanks again,

... Russell

 

 

 

PS: I was able to get gdb to attach to qemu-arm running helloworld, but was not able to get any symbol table / code to load with it ... :-(.

 

 

 


On Thu, Jan 6, 2011 08:30  AM, Russell Morris <openembedded@rkmorris.us> wrote:


> 
Hi,
> 
> 
> 
> Unfortunately I can't really do much on the target - as I can't get to the point where I can log in (no ssh connection, no local keyboard, etc.) ... :-(. I may be able to try to debug it when run through qemu-arm ... have you ever tried that?
> 
> 
> 
> I'll do some poking around to see if this is possible.
> 
> 
> 
> Thanks,
> 
> ... Russell
> 
> 
> 
> 
> On Thu, Jan 6, 2011 00:15 AM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> 
> > 
> On Wed, Jan 5, 2011 at 8:37 PM, Russell Morris <openembedded@rkmorris.us> wrote:
> > > Hi,
> > >
> > > OK, a few more updates ...
> > > - I built using the angstrom-2008.1 distro, but I have the same issue. I also ran the helloworld application on the target as well, getting the error message "Illegal instruction" (the same as qemu, which I guess is good).
> > 
> > 
> > If you can reproduce the issue on target then I would suggest that run
> > the helloworld under gdb or gdbserver on target and see where its
> > happening.
> > 
> > > - I found the .config file that you are referring to, and made this change. I built and ran the debug kernel, but no more information is provided (other than "Illegal instruction").
> > > - as a side note, I have to edit sumversion.c to fix a "known" issue (http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg08279.html). You may want to update this in the master branch.
> > >
> > > Any other ideas?
> > >
> > > Thanks,
> > > ... Russell
> > >
> > >
> > >
> > >
> > > On Wed, Jan 5, 2011 05:07 PM, Russell Morris <openembedded@rkmorris.us> wrote:
> > >> 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 <raj.khem@gmail.com> wrote:
> > >>
> > >>
> > >> >
> > >> On Wed, Jan 5, 2011 at 10:49 AM, Russell Morris
> > >> > <openembedded@rkmorris.us> 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 <raj.khem@gmail.com> wrote:
> > >> > >
> > >> > >
> > >> > >>
> > >> > > On Wed, Jan 5, 2011 at 7:11 AM, Phil Blundell <philb@gnu.org> 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
> > >> > >> > Openembedded-devel@lists.openembedded.org
> > >> > >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >> > >> >
> > >> > >>
> > >> > >> _______________________________________________
> > >> > >> Openembedded-devel mailing list
> > >> > >> Openembedded-devel@lists.openembedded.org
> > >> > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >> > >>
> > >> > > _______________________________________________
> > >> > > Openembedded-devel mailing list
> > >> > > Openembedded-devel@lists.openembedded.org
> > >> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >> > >
> > >> >
> > >> > _______________________________________________
> > >> > Openembedded-devel mailing list
> > >> > Openembedded-devel@lists.openembedded.org
> > >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >> >
> > >> _______________________________________________
> > >> Openembedded-devel mailing list
> > >> Openembedded-devel@lists.openembedded.org
> > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >>
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >
> > 
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
From jefflance01@gmail.com Sat Jan 08 20:04:45 2011
Received: from mail-gy0-f175.google.com ([209.85.160.175])
	by linuxtogo.org with esmtp (Exim 4.72)
	(envelope-from <jefflance01@gmail.com>) id 1Pbe5k-000837-Ni
	for openembedded-devel@lists.openembedded.org;
	Sat, 08 Jan 2011 20:04:45 +0100
Received: by gyh20 with SMTP id 20so7249821gyh.6
	for <openembedded-devel@lists.openembedded.org>;
	Sat, 08 Jan 2011 11:04:13 -0800 (PST)
DKIM-Signature: v

Re: H1940 Boot Issues -> Executable Build Problems?

[Russell Morris]

Hi,

 

A bit more info to try and help out here - as I'm fighting with this as best I can, but it's still kicking my butt ... :-).

 

It really does look like the executable that is being created is not build for the arm920t (armv4t). I have tried to run the executable on the target, and also with a modified version of qemu - and neither one works. If I tell qemu that the target is an arm920t the executable will not run, but if I let it be the default qemu-arm it runs just fine.

 

Has anyone else been able to get an OE build to run on an arm920t (armv4t) processor?

 

Thanks,

... Russell

 




On Sun, Jan 2, 2011 06:34  AM, <openembedded@rkmorris.us> wrote:

> 
My sincere apologies - as I never got that earlier email (but was having issues with Norton filtering my email, so I'm sure it was on my side .. :-().
> 
> To answer your question though - the MACHINE is h1940, and I have tried two different DISTRO's ... minimal and angstrom-2008.1. I am using the master branch of OpenEmbedded, and last updated it ~ 30 days ago.
> 
> Thoughts?
> 
> Thanks!
> 
> ... Russell
> 
> 
> On Sun, Jan 2, 2011 00:44 AM, Khem Raj <raj.khem@gmail.com> wrote:
> > On Sat, Jan 1, 2011 at 10:34 AM, <openembedded@rkmorris.us> wrote:
> > > Hi,
> > >
> > >
> > >
> > > As I have been debugging this it's looking more like a build issue - so let me try the developer group, in case someone here has seen this before.
> > >
> > >
> > >
> > > Copying over the key point from below ... I (successfully) built the helloworld-image,
> > 
> > 
> > what was MACHINE and DISTRO and OpenEmbedded revision you used ? I
> > think I asked same qestion when you posted this to oe-users ml. If you
> > are not going to provide information then I am afraid not many can
> > help you here
> > 
> > but cannot run the resulting helloworld binary on the target machine -
> > it does execute under QEMU, which doesn't provide support this CPU
> > (arm920t - armv4t). However, a functioning binary from the target
> > (armv4t) machine runs on the target, but not on QEMU (as expected). So
> > it seems that OpenEmbedded is not building for the right machine
> > (which is strange, as the OpenEmbedded built kernel works!).
> > >
> > >
> > >
> > > Any thoughts on this? It seems that OpenEmbedded / bitbake may be using QEMU to create the binary for the target ... is that right (as it's what I have seen in a bit of poking around)? This would be a problem, as QEMU doesn't support the arm920t processor. Perhaps I have to apply the QEMU patch that adds this support to QEMU, or change my config to somehow create the executable in a different way?
> > >
> > >
> > >
> > > Any suggestions would be greatly appreciated - as my current built (actually, rootfs) is not functioning on the target machine.
> > >
> > >
> > >
> > > Thanks!
> > >
> > >
> > >
> > > ... Russell
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Subject: Re: [Openembedded-users] H1940 Boot Issues
> > > From: <openembedded@rkmorris.us>
> > > Date: Thu, Dec 30, 2010 11:36 PM
> > > To: Openembedded-users@lists.openembedded.org
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi,
> > >
> > >
> > >
> > > OK, I haven't given up on this - and now it gets more interesting ... :-). It seems that OpenEmbedded is not properly building a binary for the ARM920T CPU (arm4t) - has anyone else seen this?
> > >
> > >
> > >
> > > I built the helloworld-image, and cannot run the resulting helloworld binary on the target machine - but can run it under QEMU, which doesn't even support this CPU. However, a functioning binary from the target (arm4t) machine runs on the target, but not on QEMU (as expected). So it seems that OpenEmbedded is not building for the right machine (which is strange, as the OpenEmbedded built kernel works!).
> > >
> > >
> > >
> > > The config files seem to be set up for the right target machine, but the binary is not being built right for some reason. Does anyone have any ideas?
> > >
> > >
> > >
> > > Thanks!
> > >
> > >
> > >
> > > ... Russell
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Dec 24, 2010 09:20 AM, <openembedded@rkmorris.us> wrote:
> > >
> > >
> > >>
> > >
> > >
> > >
> > > Hi,
> > >
> > >
> > >
> > > I have tried quite a few more things here, still with no luck. It really does seem that OpenEmbedded does not properly / fully build an image that works on (real?) embedded systems ... :-(. I am out of things to try, but let me pass this info along in the hope that it will save others some time / grief if they try to do similar things.
> > >
> > >
> > >
> > > I have tried several different formats / approaches to the rootfs, none of which work (except for the legacy Familiar Linux file system that I found). I cannot load the OpenEmbedded rootfs as an initrd, or when extracted to an SD card (as a "normal" file system, either copied from the ext2 file, or extracted from tar.gz). While this seems to be a rootfs issue, it still could be the build of init, as replacing the Familiar Linux init.sysvinit with the one generated by OpenEmbedded does in fact break the working file system. I tried reducing the size of generated rootfs (by setting IMAGE_ROOTFS_SIZE), but that doesn't seem to be working either (so I cannot use the OpenEmbedded rootfs as an initrd, as it is 64 MB, which seems to cause problems on the target system). BTW, the OpenEmbedded generated linuxrc file is just a link to /bin/busybox, which seems a bit strange - so perhaps this is the issue?
> > >
> > >
> > >
> > > Hopefully this helps other folks - by not trying these same things.
> > >
> > >
> > >
> > > ... Russell
> > >
> > >
> > >
> > >
> > >
> > >>
> > >> On Wed, Dec 22, 2010 11:28 PM, <openembedded@rkmorris.us> wrote:
> > >>
> > >
> > >>
> > > Hi,
> > >>
> > >> I have been strugging with this for quite some now, and really am stuck - so I really would appreciate any thoughts or pointers anyone has! Let me try to explain my problem.
> > >>
> > >> I have been able to build OpenEmbedded on my machine, with a target of either h1940 or qemuarm - and for the console-image both build just fine. I can use the kernel for both of these (on the appropriate target), but my issue is with the rootfs. If I use the OpenEmbedded built rootfs in qemuarm, targeted for either qemuarm or the h1940 (but always using the qemuarm kernel) everything works just fine.
> > >>
> > >> My issue arises when trying to use the rootfs on the h1940 - I cannot get my system to boot, and actually INIT is never launched (but the kernel seems fine). If I take an old file system that I was able to find (from Familiar Linux, ~ 2004-2005 vintage), it works fine on my h1940 (with the kernel from OpenEmbedded!) ... so the issue seems to be the rootfs. If I just replace /sbin/init.sysvinit in the Familiar Linux file system with the one from OpenEmbedded - then I get kernel panic (and no init found it says ... :-(). Oddly enough, if I use the Familiar LInux file system with qemuarm - it doesn't work, I have file system errors (and kernel panic), but the OpenEmbedded built file system (even for the h1940) works just great).
> > >>
> > >> So it seems that I have some sort of filesystem incompatibility ... or am I wrong? BTW, I can load the above mentioned filesystems as ext2 or ext3 in (OpenSUSE) Linux, no issues there.
> > >>
> > >> Again, any suggestions of how to fix this would be greatly appreciated!
> > >>
> > >> Thanks!
> > >>
> > >> ... Russell
> > >>
> > >>
> > >> _______________________________________________
> > >> Openembedded-users mailing list
> > >> Openembedded-users@linuxtogo.org
> > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
> > >> _______________________________________________
> > > Openembedded-users mailing list
> > > Openembedded-users@linuxtogo.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >
> > 
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
From raj.khem@gmail.com Wed Jan 05 07:47:18 2011
Received: from mail-yx0-f175.google.com ([209.85.213.175])
	by linuxtogo.org with esmtp (Exim 4.72)
	(envelope-from <raj.khem@gmail.com>) id 1PaN9S-0005ew-GI
	for openembedded-devel@lists.openembedded.org;
	Wed, 05 Jan 2011 07:47:18 +0100
Received: by yxd5 with SMTP id 5so6229548yxd.6
	for <openembedded-devel@lists.openembedded.org>;
	Tue, 04 Jan 2011 22:46:54 -0800 (PST)
DKIM-Signature: v

Re: H1940 Boot Issues -> Executable Build Problems?

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

here is updated patch



On Tue, Jan 4, 2011 at 10:46 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Jan 4, 2011 at 7:32 PM, Russell Morris <openembedded@rkmorris.us> wrote:
>> Hi,
>>
>>
>>
>> A bit more info to try and help out here - as I'm fighting with this as best I can, but it's still kicking my butt ... :-).
>>
>>
>>
>> It really does look like the executable that is being created is not build for the arm920t (armv4t). I have tried to run the executable on the target, and also with a modified version of qemu - and neither one works. If I tell qemu that the target is an arm920t the executable will not run, but if I let it be the default qemu-arm it runs just fine.
>>
>>
>>
>> Has anyone else been able to get an OE build to run on an arm920t (armv4t) processor?
>>
>>
>
> OK you seem to be one patient guy :) Here is totally untested patch
> for gcc. Please apply it on top of your openembedded. Then use
> DISTRO=minimal
> or any other distro that uses gcc 4.5 and build OE from scratch again
> and see if that helps and report back.
>
> Thanks
> -Khem
>

[-- Attachment #2: v4t.patch --]
[-- Type: application/octet-stream, Size: 1358 bytes --]

diff --git a/recipes/gcc/gcc-4.5.inc b/recipes/gcc/gcc-4.5.inc
index bac15ef..3e6fb75 100644
--- a/recipes/gcc/gcc-4.5.inc
+++ b/recipes/gcc/gcc-4.5.inc
@@ -32,6 +32,7 @@ SRC_URI = "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH} \
 	   file://arm-bswapsi2.patch \
 	   file://Makefile.in.patch \
 	   file://gcc-armv4-pass-fix-v4bx-to-ld.patch \
+	   file://arm-default-to-armv4t.patch \
 	   file://linaro/gcc-4.5-linaro-r99297.patch \
 	   file://linaro/gcc-4.5-linaro-r99298.patch \
 	   file://linaro/gcc-4.5-linaro-r99299.patch \
diff --git a/recipes/gcc/gcc-4.5/arm-default-to-armv4t.patch b/recipes/gcc/gcc-4.5/arm-default-to-armv4t.patch
new file mode 100644
index 0000000..580fccb
--- /dev/null
+++ b/recipes/gcc/gcc-4.5/arm-default-to-armv4t.patch
@@ -0,0 +1,13 @@
+Index: gcc-4_5-branch/gcc/config/arm/linux-eabi.h
+===================================================================
+--- gcc-4_5-branch.orig/gcc/config/arm/linux-eabi.h
++++ gcc-4_5-branch/gcc/config/arm/linux-eabi.h
+@@ -44,7 +44,7 @@
+    The ARM10TDMI core is the default for armv5t, so set
+    SUBTARGET_CPU_DEFAULT to achieve this.  */
+ #undef  SUBTARGET_CPU_DEFAULT
+-#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm10tdmi
++#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm9tdmi
+ 
+ /* TARGET_BIG_ENDIAN_DEFAULT is set in
+    config.gcc for big endian configurations.  */

Re: H1940 Boot Issues -> Executable Build Problems?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That looks suspiciously like
http://www.flickr.com/photos/quimgil/478715643/ :)

On 05-01-11 08:42, Khem Raj wrote:
> here is updated patch
> 
> 
> 
> On Tue, Jan 4, 2011 at 10:46 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Tue, Jan 4, 2011 at 7:32 PM, Russell Morris <openembedded@rkmorris.us> wrote:
>>> Hi,
>>>
>>>
>>>
>>> A bit more info to try and help out here - as I'm fighting with this as best I can, but it's still kicking my butt ... :-).
>>>
>>>
>>>
>>> It really does look like the executable that is being created is not build for the arm920t (armv4t). I have tried to run the executable on the target, and also with a modified version of qemu - and neither one works. If I tell qemu that the target is an arm920t the executable will not run, but if I let it be the default qemu-arm it runs just fine.
>>>
>>>
>>>
>>> Has anyone else been able to get an OE build to run on an arm920t (armv4t) processor?
>>>
>>>
>>
>> OK you seem to be one patient guy :) Here is totally untested patch
>> for gcc. Please apply it on top of your openembedded. Then use
>> DISTRO=minimal
>> or any other distro that uses gcc 4.5 and build OE from scratch again
>> and see if that helps and report back.
>>
>> Thanks
>> -Khem
>>
>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNJCzCMkyGM64RGpERAvW/AKCTiQztYmWbEMLOvxHWtP0TrfGSwgCgnIdQ
Df+XY7rjrMPTZKaMxfAXwRg=
=JXQ8
-----END PGP SIGNATURE-----

Re: H1940 Boot Issues -> Executable Build Problems?

[Khem Raj]

On Wed, Jan 5, 2011 at 12:33 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> That looks suspiciously like
> http://www.flickr.com/photos/quimgil/478715643/ :)
>

heh yes indeed no suspicion. I am just making sure that he is not
getting bitten by potential clz instructions from libgcc because now
it defaults to armv5te. If thats the case then we have to use
--with-arch=${BASE_PACKAGE_ARCH} while configuring gcc and then it
will compile the gcc runtime libraries with proper options for an arch.

> On 05-01-11 08:42, Khem Raj wrote:
>> here is updated patch
>>
>>
>>
>> On Tue, Jan 4, 2011 at 10:46 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Tue, Jan 4, 2011 at 7:32 PM, Russell Morris <openembedded@rkmorris.us> wrote:
>>>> Hi,
>>>>
>>>>
>>>>
>>>> A bit more info to try and help out here - as I'm fighting with this as best I can, but it's still kicking my butt ... :-).
>>>>
>>>>
>>>>
>>>> It really does look like the executable that is being created is not build for the arm920t (armv4t). I have tried to run the executable on the target, and also with a modified version of qemu - and neither one works. If I tell qemu that the target is an arm920t the executable will not run, but if I let it be the default qemu-arm it runs just fine.
>>>>
>>>>
>>>>
>>>> Has anyone else been able to get an OE build to run on an arm920t (armv4t) processor?
>>>>
>>>>
>>>
>>> OK you seem to be one patient guy :) Here is totally untested patch
>>> for gcc. Please apply it on top of your openembedded. Then use
>>> DISTRO=minimal
>>> or any other distro that uses gcc 4.5 and build OE from scratch again
>>> and see if that helps and report back.
>>>
>>> Thanks
>>> -Khem
>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFNJCzCMkyGM64RGpERAvW/AKCTiQztYmWbEMLOvxHWtP0TrfGSwgCgnIdQ
> Df+XY7rjrMPTZKaMxfAXwRg=
> =JXQ8
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: H1940 Boot Issues -> Executable Build Problems?

[Russell Morris]

Hi,

 

As I don't know you that well, not sure if you're joking or not - but in any case my apologies if I seem impatient ... that's not my intention at least! Just trying to debug here, and keeping folks in the loop as I progress. If the armv4t builds don't really work I'm likely not the only person impacted, so I'd like to help others avoid the issue if possible.

 

I have applied the patch, and have started the build from scratch. Fingers crossed ... :-).

 

FYI - I did look in the old TMPDIR, and found that inside gcc-cross-initial (and intermediate), the test directory seemed to call out an armv5te, so I'm hopeful that this is the issue.

 

Thanks for all your help!

 

... Russell


On Wed, Jan 5, 2011 01:42  AM, Khem Raj <raj.khem@gmail.com> wrote:


> 
here is updated patch
> 
> 
> 
> On Tue, Jan 4, 2011 at 10:46 PM, Khem Raj <raj.khem@gmail.com> wrote:
> > On Tue, Jan 4, 2011 at 7:32 PM, Russell Morris <openembedded@rkmorris.us> wrote:
> >> Hi,
> >>
> >>
> >>
> >> A bit more info to try and help out here - as I'm fighting with this as best I can, but it's still kicking my butt ... :-).
> >>
> >>
> >>
> >> It really does look like the executable that is being created is not build for the arm920t (armv4t). I have tried to run the executable on the target, and also with a modified version of qemu - and neither one works. If I tell qemu that the target is an arm920t the executable will not run, but if I let it be the default qemu-arm it runs just fine.
> >>
> >>
> >>
> >> Has anyone else been able to get an OE build to run on an arm920t (armv4t) processor?
> >>
> >>
> >
> > OK you seem to be one patient guy :) Here is totally untested patch
> > for gcc. Please apply it on top of your openembedded. Then use
> > DISTRO=minimal
> > or any other distro that uses gcc 4.5 and build OE from scratch again
> > and see if that helps and report back.
> >
> > Thanks
> > -Khem
> >
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
From openembedded@rkmorris.us Wed Jan 05 15:49:08 2011
Received: from vms173011pub.verizon.net ([206.46.173.11])
	by linuxtogo.org with esmtp (Exim 4.72)
	(envelope-from <openembedded@rkmorris.us>) id 1PaUfk-0005d1-F0
	for openembedded-devel@lists.openembedded.org;
	Wed, 05 Jan 2011 15:49:08 +0100
Received: from server ([unknown] [71.164.183.134]) by vms173011.mailsrvcs.net
	(Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16
	2009)) with ESMTPA id <0LEK00MDH157YI90@vms173011.mailsrvcs.net> for
	openembedded-devel@lists.openembedded.org; Wed,
	05 Jan 2011 08:48:44 -0600 (CST)
Received: from server (127.0.0.1) by server (Axigen)
	with ESMTPSA id 393506; Wed, 05 Jan 2011 08:48:38 -0600
Received: from [192.168.1.12] by rkmorris.us with HTTP; Wed,
	05 Jan 2011 08:48:36 -0600
From: Russell Morris <openembedded@rkmorris.us>
Date: Wed, 05 Jan 2011 08:48:36 -0600
X-Mailer: Axigen WebMail
To: openembedded-devel@lists.openembedded.org
Message-id: <1294238916100625500@rkmorris.us>
In-reply-to: <ig1b7c$j8n$1@dough.gmane.org>
References: <1294198349769396500@rkmorris.us> <ig1b7c$j8n$1@dough.gmane.org>
Importance: Normal
MIME-version: 1.0
X-AxigenVirus-Level: 1
X-AxigenSpam-Level: 6
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Content-Filtered-By: Mailman/MimeDel 2.1.11
Subject: Re: [oe] H1940 Boot Issues -> Executable Build Problems?
X-BeenThere: openembedded-devel@lists.openembedded.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: openembedded-devel@lists.openembedded.org
List-Id: Using the OpenEmbedded metadata to build Distributions
	<openembedded-devel.lists.openembedded.org>
List-Unsubscribe: <http://lists.linuxtogo.org/cgi-bin/mailman/options/openembedded-devel>,
	<mailto:openembedded-devel-request@lists.openembedded.org?subject

Re: H1940 Boot Issues -> Executable Build Problems?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05-01-11 04:32, Russell Morris wrote:
> Hi,
> 
>  
> 
> A bit more info to try and help out here - as I'm fighting with this as best I can, but it's still kicking my butt ... :-).
> 
> It really does look like the executable that is being created is not build for the arm920t (armv4t). I have tried to run the executable on the target, and also with a modified version of qemu - and neither one works. If I tell qemu that the target is an arm920t the executable will not run, but if I let it be the default qemu-arm it runs just fine.
> 
> Has anyone else been able to get an OE build to run on an arm920t (armv4t) processor?

DISTRO=angstrom-2008.1 generates armv4t binaries just fine over here.

regards,

Koen


> 
>  
> 
> Thanks,
> 
> ... Russell
> 
>  
> 
> 
> 
> 
> On Sun, Jan 2, 2011 06:34  AM, <openembedded@rkmorris.us> wrote:
> 
>>
> My sincere apologies - as I never got that earlier email (but was having issues with Norton filtering my email, so I'm sure it was on my side .. :-().
>>
>> To answer your question though - the MACHINE is h1940, and I have tried two different DISTRO's ... minimal and angstrom-2008.1. I am using the master branch of OpenEmbedded, and last updated it ~ 30 days ago.
>>
>> Thoughts?
>>
>> Thanks!
>>
>> ... Russell
>>
>>
>> On Sun, Jan 2, 2011 00:44 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Sat, Jan 1, 2011 at 10:34 AM, <openembedded@rkmorris.us> wrote:
>>>> Hi,
>>>>
>>>>
>>>>
>>>> As I have been debugging this it's looking more like a build issue - so let me try the developer group, in case someone here has seen this before.
>>>>
>>>>
>>>>
>>>> Copying over the key point from below ... I (successfully) built the helloworld-image,
>>>
>>>
>>> what was MACHINE and DISTRO and OpenEmbedded revision you used ? I
>>> think I asked same qestion when you posted this to oe-users ml. If you
>>> are not going to provide information then I am afraid not many can
>>> help you here
>>>
>>> but cannot run the resulting helloworld binary on the target machine -
>>> it does execute under QEMU, which doesn't provide support this CPU
>>> (arm920t - armv4t). However, a functioning binary from the target
>>> (armv4t) machine runs on the target, but not on QEMU (as expected). So
>>> it seems that OpenEmbedded is not building for the right machine
>>> (which is strange, as the OpenEmbedded built kernel works!).
>>>>
>>>>
>>>>
>>>> Any thoughts on this? It seems that OpenEmbedded / bitbake may be using QEMU to create the binary for the target ... is that right (as it's what I have seen in a bit of poking around)? This would be a problem, as QEMU doesn't support the arm920t processor. Perhaps I have to apply the QEMU patch that adds this support to QEMU, or change my config to somehow create the executable in a different way?
>>>>
>>>>
>>>>
>>>> Any suggestions would be greatly appreciated - as my current built (actually, rootfs) is not functioning on the target machine.
>>>>
>>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> ... Russell
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Subject: Re: [Openembedded-users] H1940 Boot Issues
>>>> From: <openembedded@rkmorris.us>
>>>> Date: Thu, Dec 30, 2010 11:36 PM
>>>> To: Openembedded-users@lists.openembedded.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> OK, I haven't given up on this - and now it gets more interesting ... :-). It seems that OpenEmbedded is not properly building a binary for the ARM920T CPU (arm4t) - has anyone else seen this?
>>>>
>>>>
>>>>
>>>> I built the helloworld-image, and cannot run the resulting helloworld binary on the target machine - but can run it under QEMU, which doesn't even support this CPU. However, a functioning binary from the target (arm4t) machine runs on the target, but not on QEMU (as expected). So it seems that OpenEmbedded is not building for the right machine (which is strange, as the OpenEmbedded built kernel works!).
>>>>
>>>>
>>>>
>>>> The config files seem to be set up for the right target machine, but the binary is not being built right for some reason. Does anyone have any ideas?
>>>>
>>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> ... Russell
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Dec 24, 2010 09:20 AM, <openembedded@rkmorris.us> wrote:
>>>>
>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I have tried quite a few more things here, still with no luck. It really does seem that OpenEmbedded does not properly / fully build an image that works on (real?) embedded systems ... :-(. I am out of things to try, but let me pass this info along in the hope that it will save others some time / grief if they try to do similar things.
>>>>
>>>>
>>>>
>>>> I have tried several different formats / approaches to the rootfs, none of which work (except for the legacy Familiar Linux file system that I found). I cannot load the OpenEmbedded rootfs as an initrd, or when extracted to an SD card (as a "normal" file system, either copied from the ext2 file, or extracted from tar.gz). While this seems to be a rootfs issue, it still could be the build of init, as replacing the Familiar Linux init.sysvinit with the one generated by OpenEmbedded does in fact break the working file system. I tried reducing the size of generated rootfs (by setting IMAGE_ROOTFS_SIZE), but that doesn't seem to be working either (so I cannot use the OpenEmbedded rootfs as an initrd, as it is 64 MB, which seems to cause problems on the target system). BTW, the OpenEmbedde
>  d generated linuxrc file is just a link to /bin/busybox, which seems a bit strange - so perhaps this is the issue?
>>>>
>>>>
>>>>
>>>> Hopefully this helps other folks - by not trying these same things.
>>>>
>>>>
>>>>
>>>> ... Russell
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> On Wed, Dec 22, 2010 11:28 PM, <openembedded@rkmorris.us> wrote:
>>>>>
>>>>
>>>>>
>>>> Hi,
>>>>>
>>>>> I have been strugging with this for quite some now, and really am stuck - so I really would appreciate any thoughts or pointers anyone has! Let me try to explain my problem.
>>>>>
>>>>> I have been able to build OpenEmbedded on my machine, with a target of either h1940 or qemuarm - and for the console-image both build just fine. I can use the kernel for both of these (on the appropriate target), but my issue is with the rootfs. If I use the OpenEmbedded built rootfs in qemuarm, targeted for either qemuarm or the h1940 (but always using the qemuarm kernel) everything works just fine.
>>>>>
>>>>> My issue arises when trying to use the rootfs on the h1940 - I cannot get my system to boot, and actually INIT is never launched (but the kernel seems fine). If I take an old file system that I was able to find (from Familiar Linux, ~ 2004-2005 vintage), it works fine on my h1940 (with the kernel from OpenEmbedded!) ... so the issue seems to be the rootfs. If I just replace /sbin/init.sysvinit in the Familiar Linux file system with the one from OpenEmbedded - then I get kernel panic (and no init found it says ... :-(). Oddly enough, if I use the Familiar LInux file system with qemuarm - it doesn't work, I have file system errors (and kernel panic), but the OpenEmbedded built file system (even for the h1940) works just great).
>>>>>
>>>>> So it seems that I have some sort of filesystem incompatibility ... or am I wrong? BTW, I can load the above mentioned filesystems as ext2 or ext3 in (OpenSUSE) Linux, no issues there.
>>>>>
>>>>> Again, any suggestions of how to fix this would be greatly appreciated!
>>>>>
>>>>> Thanks!
>>>>>
>>>>> ... Russell
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Openembedded-users mailing list
>>>>> Openembedded-users@linuxtogo.org
>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
>>>>> _______________________________________________
>>>> Openembedded-users mailing list
>>>> Openembedded-users@linuxtogo.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
>>>> _______________________________________________
>>>> Openembedded-devel mailing list
>>>> Openembedded-devel@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>>
>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNJDAsMkyGM64RGpERAnXbAJ4nw3gu1JA47X0xUMOHFJ1sA31aTACdFw1K
mJcYeEnaLSmo0XaY0eXokUU=
=HU+c
-----END PGP SIGNATURE-----

Re: H1940 Boot Issues -> Executable Build Problems?

[Phil Blundell]

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.

Re: H1940 Boot Issues -> Executable Build Problems?

[Khem Raj]

On Wed, Jan 5, 2011 at 7:11 AM, Phil Blundell <philb@gnu.org> 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
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: H1940 Boot Issues -> Executable Build Problems?

[Khem Raj]

On Wed, Jan 5, 2011 at 12:47 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05-01-11 04:32, Russell Morris wrote:
>> Hi,
>>
>>
>>
>> A bit more info to try and help out here - as I'm fighting with this as best I can, but it's still kicking my butt ... :-).
>>
>> It really does look like the executable that is being created is not build for the arm920t (armv4t). I have tried to run the executable on the target, and also with a modified version of qemu - and neither one works. If I tell qemu that the target is an arm920t the executable will not run, but if I let it be the default qemu-arm it runs just fine.
>>
>> Has anyone else been able to get an OE build to run on an arm920t (armv4t) processor?
>
> DISTRO=angstrom-2008.1 generates armv4t binaries just fine over here.

hmmm one of distro he tried was angstrom-2008.1. so this ay not be the
issue then

>
> regards,
>
> Koen
>
>
>>
>>
>>
>> Thanks,
>>
>> ... Russell
>>
>>
>>
>>
>>
>>
>> On Sun, Jan 2, 2011 06:34  AM, <openembedded@rkmorris.us> wrote:
>>
>>>
>> My sincere apologies - as I never got that earlier email (but was having issues with Norton filtering my email, so I'm sure it was on my side .. :-().
>>>
>>> To answer your question though - the MACHINE is h1940, and I have tried two different DISTRO's ... minimal and angstrom-2008.1. I am using the master branch of OpenEmbedded, and last updated it ~ 30 days ago.
>>>
>>> Thoughts?
>>>
>>> Thanks!
>>>
>>> ... Russell
>>>
>>>
>>> On Sun, Jan 2, 2011 00:44 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> On Sat, Jan 1, 2011 at 10:34 AM, <openembedded@rkmorris.us> wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> As I have been debugging this it's looking more like a build issue - so let me try the developer group, in case someone here has seen this before.
>>>>>
>>>>>
>>>>>
>>>>> Copying over the key point from below ... I (successfully) built the helloworld-image,
>>>>
>>>>
>>>> what was MACHINE and DISTRO and OpenEmbedded revision you used ? I
>>>> think I asked same qestion when you posted this to oe-users ml. If you
>>>> are not going to provide information then I am afraid not many can
>>>> help you here
>>>>
>>>> but cannot run the resulting helloworld binary on the target machine -
>>>> it does execute under QEMU, which doesn't provide support this CPU
>>>> (arm920t - armv4t). However, a functioning binary from the target
>>>> (armv4t) machine runs on the target, but not on QEMU (as expected). So
>>>> it seems that OpenEmbedded is not building for the right machine
>>>> (which is strange, as the OpenEmbedded built kernel works!).
>>>>>
>>>>>
>>>>>
>>>>> Any thoughts on this? It seems that OpenEmbedded / bitbake may be using QEMU to create the binary for the target ... is that right (as it's what I have seen in a bit of poking around)? This would be a problem, as QEMU doesn't support the arm920t processor. Perhaps I have to apply the QEMU patch that adds this support to QEMU, or change my config to somehow create the executable in a different way?
>>>>>
>>>>>
>>>>>
>>>>> Any suggestions would be greatly appreciated - as my current built (actually, rootfs) is not functioning on the target machine.
>>>>>
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>> ... Russell
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Subject: Re: [Openembedded-users] H1940 Boot Issues
>>>>> From: <openembedded@rkmorris.us>
>>>>> Date: Thu, Dec 30, 2010 11:36 PM
>>>>> To: Openembedded-users@lists.openembedded.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> OK, I haven't given up on this - and now it gets more interesting ... :-). It seems that OpenEmbedded is not properly building a binary for the ARM920T CPU (arm4t) - has anyone else seen this?
>>>>>
>>>>>
>>>>>
>>>>> I built the helloworld-image, and cannot run the resulting helloworld binary on the target machine - but can run it under QEMU, which doesn't even support this CPU. However, a functioning binary from the target (arm4t) machine runs on the target, but not on QEMU (as expected). So it seems that OpenEmbedded is not building for the right machine (which is strange, as the OpenEmbedded built kernel works!).
>>>>>
>>>>>
>>>>>
>>>>> The config files seem to be set up for the right target machine, but the binary is not being built right for some reason. Does anyone have any ideas?
>>>>>
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>> ... Russell
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Dec 24, 2010 09:20 AM, <openembedded@rkmorris.us> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> I have tried quite a few more things here, still with no luck. It really does seem that OpenEmbedded does not properly / fully build an image that works on (real?) embedded systems ... :-(. I am out of things to try, but let me pass this info along in the hope that it will save others some time / grief if they try to do similar things.
>>>>>
>>>>>
>>>>>
>>>>> I have tried several different formats / approaches to the rootfs, none of which work (except for the legacy Familiar Linux file system that I found). I cannot load the OpenEmbedded rootfs as an initrd, or when extracted to an SD card (as a "normal" file system, either copied from the ext2 file, or extracted from tar.gz). While this seems to be a rootfs issue, it still could be the build of init, as replacing the Familiar Linux init.sysvinit with the one generated by OpenEmbedded does in fact break the working file system. I tried reducing the size of generated rootfs (by setting IMAGE_ROOTFS_SIZE), but that doesn't seem to be working either (so I cannot use the OpenEmbedded rootfs as an initrd, as it is 64 MB, which seems to cause problems on the target system). BTW, the OpenEmbedde
>>  d generated linuxrc file is just a link to /bin/busybox, which seems a bit strange - so perhaps this is the issue?
>>>>>
>>>>>
>>>>>
>>>>> Hopefully this helps other folks - by not trying these same things.
>>>>>
>>>>>
>>>>>
>>>>> ... Russell
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, Dec 22, 2010 11:28 PM, <openembedded@rkmorris.us> wrote:
>>>>>>
>>>>>
>>>>>>
>>>>> Hi,
>>>>>>
>>>>>> I have been strugging with this for quite some now, and really am stuck - so I really would appreciate any thoughts or pointers anyone has! Let me try to explain my problem.
>>>>>>
>>>>>> I have been able to build OpenEmbedded on my machine, with a target of either h1940 or qemuarm - and for the console-image both build just fine. I can use the kernel for both of these (on the appropriate target), but my issue is with the rootfs. If I use the OpenEmbedded built rootfs in qemuarm, targeted for either qemuarm or the h1940 (but always using the qemuarm kernel) everything works just fine.
>>>>>>
>>>>>> My issue arises when trying to use the rootfs on the h1940 - I cannot get my system to boot, and actually INIT is never launched (but the kernel seems fine). If I take an old file system that I was able to find (from Familiar Linux, ~ 2004-2005 vintage), it works fine on my h1940 (with the kernel from OpenEmbedded!) ... so the issue seems to be the rootfs. If I just replace /sbin/init.sysvinit in the Familiar Linux file system with the one from OpenEmbedded - then I get kernel panic (and no init found it says ... :-(). Oddly enough, if I use the Familiar LInux file system with qemuarm - it doesn't work, I have file system errors (and kernel panic), but the OpenEmbedded built file system (even for the h1940) works just great).
>>>>>>
>>>>>> So it seems that I have some sort of filesystem incompatibility ... or am I wrong? BTW, I can load the above mentioned filesystems as ext2 or ext3 in (OpenSUSE) Linux, no issues there.
>>>>>>
>>>>>> Again, any suggestions of how to fix this would be greatly appreciated!
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> ... Russell
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Openembedded-users mailing list
>>>>>> Openembedded-users@linuxtogo.org
>>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
>>>>>> _______________________________________________
>>>>> Openembedded-users mailing list
>>>>> Openembedded-users@linuxtogo.org
>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
>>>>> _______________________________________________
>>>>> Openembedded-devel mailing list
>>>>> Openembedded-devel@lists.openembedded.org
>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-devel mailing list
>>>> Openembedded-devel@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFNJDAsMkyGM64RGpERAnXbAJ4nw3gu1JA47X0xUMOHFJ1sA31aTACdFw1K
> mJcYeEnaLSmo0XaY0eXokUU=
> =HU+c
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

H1940 Boot Issues -> Executable Build Problems?

[openembedded]

Hi,

 

As I have been debugging this it's looking more like a build issue - so let me try the developer group, in case someone here has seen this before.

 

Copying over the key point from below ... I (successfully) built the helloworld-image, but cannot run the resulting helloworld binary on the target machine - it does execute under QEMU, which doesn't provide support this CPU (arm920t - armv4t). However, a functioning binary from the target (armv4t) machine runs on the target, but not on QEMU (as expected). So it seems that OpenEmbedded is not building for the right machine (which is strange, as the OpenEmbedded built kernel works!).

 

Any thoughts on this? It seems that OpenEmbedded / bitbake may be using QEMU to create the binary for the target ... is that right (as it's what I have seen in a bit of poking around)? This would be a problem, as QEMU doesn't support the arm920t processor. Perhaps I have to apply the QEMU patch that adds this support to QEMU, or change my config to somehow create the executable in a different way?

 

Any suggestions would be greatly appreciated - as my current built (actually, rootfs) is not functioning on the target machine.

 

Thanks!

 

... Russell

 

 


 



Subject: Re: [Openembedded-users] H1940 Boot Issues
From: <openembedded@rkmorris.us>
Date: Thu, Dec 30, 2010 11:36 PM
To: Openembedded-users@lists.openembedded.org






Hi,

 

OK, I haven't given up on this - and now it gets more interesting ... :-). It seems that OpenEmbedded is not properly building a binary for the ARM920T CPU (arm4t) - has anyone else seen this?

 

I built the helloworld-image, and cannot run the resulting helloworld binary on the target machine - but can run it under QEMU, which doesn't even support this CPU. However, a functioning binary from the target (arm4t) machine runs on the target, but not on QEMU (as expected). So it seems that OpenEmbedded is not building for the right machine (which is strange, as the OpenEmbedded built kernel works!).

 

The config files seem to be set up for the right target machine, but the binary is not being built right for some reason. Does anyone have any ideas?

 

Thanks!

 

... Russell

 

 


On Fri, Dec 24, 2010 09:20  AM, <openembedded@rkmorris.us> wrote:


> 



Hi,

 

I have tried quite a few more things here, still with no luck. It really does seem that OpenEmbedded does not properly / fully build an image that works on (real?) embedded systems ... :-(. I am out of things to try, but let me pass this info along in the hope that it will save others some time / grief if they try to do similar things.

 

I have tried several different formats / approaches to the rootfs, none of which work (except for the legacy Familiar Linux file system that I found). I cannot load the OpenEmbedded rootfs as an initrd, or when extracted to an SD card (as a "normal" file system, either copied from the ext2 file, or extracted from tar.gz). While this seems to be a rootfs issue, it still could be the build of init, as replacing the Familiar Linux init.sysvinit with the one generated by OpenEmbedded does in fact break the working file system. I tried reducing the size of generated rootfs (by setting IMAGE_ROOTFS_SIZE), but that doesn't seem to be working either (so I cannot use the OpenEmbedded rootfs as an initrd, as it is 64 MB, which seems to cause problems on the target system). BTW, the OpenEmbedded generated linuxrc file is just a link to /bin/busybox, which seems a bit strange - so perhaps this is the issue?

 

Hopefully this helps other folks - by not trying these same things.

 

... Russell

 

 

> 
> On Wed, Dec 22, 2010 11:28  PM, <openembedded@rkmorris.us> wrote:
> 

> 
Hi,
> 
> I have been strugging with this for quite some now, and really am stuck - so I really would appreciate any thoughts or pointers anyone has! Let me try to explain my problem.
> 
> I have been able to build OpenEmbedded on my machine, with a target of either h1940 or qemuarm - and for the console-image both build just fine. I can use the kernel for both of these (on the appropriate target), but my issue is with the rootfs. If I use the OpenEmbedded built rootfs in qemuarm, targeted for either qemuarm or the h1940 (but always using the qemuarm kernel) everything works just fine.
> 
> My issue arises when trying to use the rootfs on the h1940 - I cannot get my system to boot, and actually INIT is never launched (but the kernel seems fine). If I take an old file system that I was able to find (from Familiar Linux, ~ 2004-2005 vintage), it works fine on my h1940 (with the kernel from OpenEmbedded!) ... so the issue seems to be the rootfs. If I just replace /sbin/init.sysvinit in the Familiar Linux file system with the one from OpenEmbedded - then I get kernel panic (and no init found it says ... :-(). Oddly enough, if I use the Familiar LInux file system with qemuarm - it doesn't work, I have file system errors (and kernel panic), but the OpenEmbedded built file system (even for the h1940) works just great).
> 
> So it seems that I have some sort of filesystem incompatibility ... or am I wrong? BTW, I can load the above mentioned filesystems as ext2 or ext3 in (OpenSUSE) Linux, no issues there.
> 
> Again, any suggestions of how to fix this would be greatly appreciated!
> 
> Thanks!
> 
> ... Russell
> 
> 
> _______________________________________________
> Openembedded-users mailing list
> Openembedded-users@linuxtogo.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
> _______________________________________________
Openembedded-users mailing list
Openembedded-users@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users

Re: H1940 Boot Issues -> Executable Build Problems?

[Khem Raj]

On Sat, Jan 1, 2011 at 10:34 AM,  <openembedded@rkmorris.us> wrote:
> Hi,
>
>
>
> As I have been debugging this it's looking more like a build issue - so let me try the developer group, in case someone here has seen this before.
>
>
>
> Copying over the key point from below ... I (successfully) built the helloworld-image,


what was MACHINE and DISTRO and OpenEmbedded revision you used ? I
think I asked same qestion when you posted this to oe-users ml. If you
are not going to provide information then I am afraid not many can
help you here

but cannot run the resulting helloworld binary on the target machine -
it does execute under QEMU, which doesn't provide support this CPU
(arm920t - armv4t). However, a functioning binary from the target
(armv4t) machine runs on the target, but not on QEMU (as expected). So
it seems that OpenEmbedded is not building for the right machine
(which is strange, as the OpenEmbedded built kernel works!).
>
>
>
> Any thoughts on this? It seems that OpenEmbedded / bitbake may be using QEMU to create the binary for the target ... is that right (as it's what I have seen in a bit of poking around)? This would be a problem, as QEMU doesn't support the arm920t processor. Perhaps I have to apply the QEMU patch that adds this support to QEMU, or change my config to somehow create the executable in a different way?
>
>
>
> Any suggestions would be greatly appreciated - as my current built (actually, rootfs) is not functioning on the target machine.
>
>
>
> Thanks!
>
>
>
> ... Russell
>
>
>
>
>
>
>
>
>
>
> Subject: Re: [Openembedded-users] H1940 Boot Issues
> From: <openembedded@rkmorris.us>
> Date: Thu, Dec 30, 2010 11:36 PM
> To: Openembedded-users@lists.openembedded.org
>
>
>
>
>
>
> Hi,
>
>
>
> OK, I haven't given up on this - and now it gets more interesting ... :-). It seems that OpenEmbedded is not properly building a binary for the ARM920T CPU (arm4t) - has anyone else seen this?
>
>
>
> I built the helloworld-image, and cannot run the resulting helloworld binary on the target machine - but can run it under QEMU, which doesn't even support this CPU. However, a functioning binary from the target (arm4t) machine runs on the target, but not on QEMU (as expected). So it seems that OpenEmbedded is not building for the right machine (which is strange, as the OpenEmbedded built kernel works!).
>
>
>
> The config files seem to be set up for the right target machine, but the binary is not being built right for some reason. Does anyone have any ideas?
>
>
>
> Thanks!
>
>
>
> ... Russell
>
>
>
>
>
>
> On Fri, Dec 24, 2010 09:20  AM, <openembedded@rkmorris.us> wrote:
>
>
>>
>
>
>
> Hi,
>
>
>
> I have tried quite a few more things here, still with no luck. It really does seem that OpenEmbedded does not properly / fully build an image that works on (real?) embedded systems ... :-(. I am out of things to try, but let me pass this info along in the hope that it will save others some time / grief if they try to do similar things.
>
>
>
> I have tried several different formats / approaches to the rootfs, none of which work (except for the legacy Familiar Linux file system that I found). I cannot load the OpenEmbedded rootfs as an initrd, or when extracted to an SD card (as a "normal" file system, either copied from the ext2 file, or extracted from tar.gz). While this seems to be a rootfs issue, it still could be the build of init, as replacing the Familiar Linux init.sysvinit with the one generated by OpenEmbedded does in fact break the working file system. I tried reducing the size of generated rootfs (by setting IMAGE_ROOTFS_SIZE), but that doesn't seem to be working either (so I cannot use the OpenEmbedded rootfs as an initrd, as it is 64 MB, which seems to cause problems on the target system). BTW, the OpenEmbedded generated linuxrc file is just a link to /bin/busybox, which seems a bit strange - so perhaps this is the issue?
>
>
>
> Hopefully this helps other folks - by not trying these same things.
>
>
>
> ... Russell
>
>
>
>
>
>>
>> On Wed, Dec 22, 2010 11:28  PM, <openembedded@rkmorris.us> wrote:
>>
>
>>
> Hi,
>>
>> I have been strugging with this for quite some now, and really am stuck - so I really would appreciate any thoughts or pointers anyone has! Let me try to explain my problem.
>>
>> I have been able to build OpenEmbedded on my machine, with a target of either h1940 or qemuarm - and for the console-image both build just fine. I can use the kernel for both of these (on the appropriate target), but my issue is with the rootfs. If I use the OpenEmbedded built rootfs in qemuarm, targeted for either qemuarm or the h1940 (but always using the qemuarm kernel) everything works just fine.
>>
>> My issue arises when trying to use the rootfs on the h1940 - I cannot get my system to boot, and actually INIT is never launched (but the kernel seems fine). If I take an old file system that I was able to find (from Familiar Linux, ~ 2004-2005 vintage), it works fine on my h1940 (with the kernel from OpenEmbedded!) ... so the issue seems to be the rootfs. If I just replace /sbin/init.sysvinit in the Familiar Linux file system with the one from OpenEmbedded - then I get kernel panic (and no init found it says ... :-(). Oddly enough, if I use the Familiar LInux file system with qemuarm - it doesn't work, I have file system errors (and kernel panic), but the OpenEmbedded built file system (even for the h1940) works just great).
>>
>> So it seems that I have some sort of filesystem incompatibility ... or am I wrong? BTW, I can load the above mentioned filesystems as ext2 or ext3 in (OpenSUSE) Linux, no issues there.
>>
>> Again, any suggestions of how to fix this would be greatly appreciated!
>>
>> Thanks!
>>
>> ... Russell
>>
>>
>> _______________________________________________
>> Openembedded-users mailing list
>> Openembedded-users@linuxtogo.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
>> _______________________________________________
> Openembedded-users mailing list
> Openembedded-users@linuxtogo.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: H1940 Boot Issues -> Executable Build Problems?

[openembedded]

My sincere apologies - as I never got that earlier email (but was having issues with Norton filtering my email, so I'm sure it was on my side .. :-().

To answer your question though - the MACHINE is h1940, and I have tried two different DISTRO's ... minimal and angstrom-2008.1. I am using the master branch of OpenEmbedded, and last updated it ~ 30 days ago.

Thoughts?

Thanks!

... Russell


On Sun, Jan 2, 2011 00:44  AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Sat, Jan 1, 2011 at 10:34 AM,  <openembedded@rkmorris.us> wrote:
> > Hi,
> >
> >
> >
> > As I have been debugging this it's looking more like a build issue - so let me try the developer group, in case someone here has seen this before.
> >
> >
> >
> > Copying over the key point from below ... I (successfully) built the helloworld-image,
> 
> 
> what was MACHINE and DISTRO and OpenEmbedded revision you used ? I
> think I asked same qestion when you posted this to oe-users ml. If you
> are not going to provide information then I am afraid not many can
> help you here
> 
> but cannot run the resulting helloworld binary on the target machine -
> it does execute under QEMU, which doesn't provide support this CPU
> (arm920t - armv4t). However, a functioning binary from the target
> (armv4t) machine runs on the target, but not on QEMU (as expected). So
> it seems that OpenEmbedded is not building for the right machine
> (which is strange, as the OpenEmbedded built kernel works!).
> >
> >
> >
> > Any thoughts on this? It seems that OpenEmbedded / bitbake may be using QEMU to create the binary for the target ... is that right (as it's what I have seen in a bit of poking around)? This would be a problem, as QEMU doesn't support the arm920t processor. Perhaps I have to apply the QEMU patch that adds this support to QEMU, or change my config to somehow create the executable in a different way?
> >
> >
> >
> > Any suggestions would be greatly appreciated - as my current built (actually, rootfs) is not functioning on the target machine.
> >
> >
> >
> > Thanks!
> >
> >
> >
> > ... Russell
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Subject: Re: [Openembedded-users] H1940 Boot Issues
> > From: <openembedded@rkmorris.us>
> > Date: Thu, Dec 30, 2010 11:36 PM
> > To: Openembedded-users@lists.openembedded.org
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> >
> >
> > OK, I haven't given up on this - and now it gets more interesting ... :-). It seems that OpenEmbedded is not properly building a binary for the ARM920T CPU (arm4t) - has anyone else seen this?
> >
> >
> >
> > I built the helloworld-image, and cannot run the resulting helloworld binary on the target machine - but can run it under QEMU, which doesn't even support this CPU. However, a functioning binary from the target (arm4t) machine runs on the target, but not on QEMU (as expected). So it seems that OpenEmbedded is not building for the right machine (which is strange, as the OpenEmbedded built kernel works!).
> >
> >
> >
> > The config files seem to be set up for the right target machine, but the binary is not being built right for some reason. Does anyone have any ideas?
> >
> >
> >
> > Thanks!
> >
> >
> >
> > ... Russell
> >
> >
> >
> >
> >
> >
> > On Fri, Dec 24, 2010 09:20  AM, <openembedded@rkmorris.us> wrote:
> >
> >
> >>
> >
> >
> >
> > Hi,
> >
> >
> >
> > I have tried quite a few more things here, still with no luck. It really does seem that OpenEmbedded does not properly / fully build an image that works on (real?) embedded systems ... :-(. I am out of things to try, but let me pass this info along in the hope that it will save others some time / grief if they try to do similar things.
> >
> >
> >
> > I have tried several different formats / approaches to the rootfs, none of which work (except for the legacy Familiar Linux file system that I found). I cannot load the OpenEmbedded rootfs as an initrd, or when extracted to an SD card (as a "normal" file system, either copied from the ext2 file, or extracted from tar.gz). While this seems to be a rootfs issue, it still could be the build of init, as replacing the Familiar Linux init.sysvinit with the one generated by OpenEmbedded does in fact break the working file system. I tried reducing the size of generated rootfs (by setting IMAGE_ROOTFS_SIZE), but that doesn't seem to be working either (so I cannot use the OpenEmbedded rootfs as an initrd, as it is 64 MB, which seems to cause problems on the target system). BTW, the OpenEmbedded generated linuxrc file is just a link to /bin/busybox, which seems a bit strange - so perhaps this is the issue?
> >
> >
> >
> > Hopefully this helps other folks - by not trying these same things.
> >
> >
> >
> > ... Russell
> >
> >
> >
> >
> >
> >>
> >> On Wed, Dec 22, 2010 11:28  PM, <openembedded@rkmorris.us> wrote:
> >>
> >
> >>
> > Hi,
> >>
> >> I have been strugging with this for quite some now, and really am stuck - so I really would appreciate any thoughts or pointers anyone has! Let me try to explain my problem.
> >>
> >> I have been able to build OpenEmbedded on my machine, with a target of either h1940 or qemuarm - and for the console-image both build just fine. I can use the kernel for both of these (on the appropriate target), but my issue is with the rootfs. If I use the OpenEmbedded built rootfs in qemuarm, targeted for either qemuarm or the h1940 (but always using the qemuarm kernel) everything works just fine.
> >>
> >> My issue arises when trying to use the rootfs on the h1940 - I cannot get my system to boot, and actually INIT is never launched (but the kernel seems fine). If I take an old file system that I was able to find (from Familiar Linux, ~ 2004-2005 vintage), it works fine on my h1940 (with the kernel from OpenEmbedded!) ... so the issue seems to be the rootfs. If I just replace /sbin/init.sysvinit in the Familiar Linux file system with the one from OpenEmbedded - then I get kernel panic (and no init found it says ... :-(). Oddly enough, if I use the Familiar LInux file system with qemuarm - it doesn't work, I have file system errors (and kernel panic), but the OpenEmbedded built file system (even for the h1940) works just great).
> >>
> >> So it seems that I have some sort of filesystem incompatibility ... or am I wrong? BTW, I can load the above mentioned filesystems as ext2 or ext3 in (OpenSUSE) Linux, no issues there.
> >>
> >> Again, any suggestions of how to fix this would be greatly appreciated!
> >>
> >> Thanks!
> >>
> >> ... Russell
> >>
> >>
> >> _______________________________________________
> >> Openembedded-users mailing list
> >> Openembedded-users@linuxtogo.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
> >> _______________________________________________
> > Openembedded-users mailing list
> > Openembedded-users@linuxtogo.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
From mike@mwester.net Sun Jan 02 16:22:34 2011
Received: from p3plsmtpa01-08.prod.phx3.secureserver.net ([72.167.82.88])
	by linuxtogo.org with smtp (Exim 4.72)
	(envelope-from <mike@mwester.net>) id 1PZPlS-0000CP-0N
	for openembedded-devel@lists.openembedded.org;
	Sun, 02 Jan 2011 16:22:34 +0100
Received: (qmail 11844 invoked from network); 2 Jan 2011 15:15:32 -0000
Received: from unknown (209.242.7.132)
	by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP;
	02 Jan 2011 15:15:31 -0000
Message-ID: <4D20968B.4030004@mwester.net>
Date: Sun, 02 Jan 2011 09:15:23 -0600
From: Mike Westerhof <mike@mwester.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: openembedded-devel@lists.openembedded.org
Content-Type: text/plain; charset