From: <openembedded@rkmorris.us>
To: openembedded-devel@lists.openembedded.org
Subject: H1940 Boot Issues -> Executable Build Problems?
Date: Sat, 01 Jan 2011 12:34:28 -0600 [thread overview]
Message-ID: <1293906868062803500@rkmorris.us> (raw)
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
next reply other threads:[~2011-01-01 19:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-01 18:34 openembedded [this message]
2011-01-02 6:44 ` H1940 Boot Issues -> Executable Build Problems? Khem Raj
2011-01-02 12:34 ` openembedded
-- strict thread matches above, loose matches on Subject: below --
2011-01-05 3:32 Russell Morris
[not found] ` <AANLkTim22AbOed09n1Ez6A2gtJhnjUDm3Ksv+tRDnn=8@mail.gmail.com>
2011-01-05 7:42 ` Khem Raj
2011-01-05 8:33 ` Koen Kooi
2011-01-05 8:49 ` Khem Raj
2011-01-05 14:47 ` Russell Morris
2011-01-05 8:47 ` Koen Kooi
[not found] ` <1294238916100625500@rkmorris.us>
2011-01-05 15:11 ` Phil Blundell
2011-01-05 17:45 ` Khem Raj
2011-01-05 17:20 ` Khem Raj
2011-01-05 18:49 Russell Morris
2011-01-05 20:23 ` Khem Raj
2011-01-05 23:07 ` Russell Morris
[not found] ` <1294288661406628500@rkmorris.us>
2011-01-06 6:15 ` Khem Raj
2011-01-06 14:30 ` Russell Morris
2011-01-06 7:54 ` Koen Kooi
[not found] ` <AANLkTimaX4kPer1-+UFRq-80PBFrcT8oxorC=SHwHWFU@mail.gmail.com>
2011-01-06 14:28 ` Russell Morris
[not found] ` <201101061721.30643.anarsoul@gmail.com>
[not found] ` <1294330448552193500@rkmorris.us>
2011-01-06 16:32 ` Vasily Khoruzhick
2011-01-06 16:50 ` Russell Morris
[not found] ` <201101062040.16993.anarsoul@gmail.com>
2011-01-06 23:41 ` Khem Raj
2011-01-08 14:52 Russell Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1293906868062803500@rkmorris.us \
--to=openembedded@rkmorris.us \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.