On Wed, Jan 5, 2011 at 12:47 AM, Koen Kooi <[email protected]> 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, <[email protected]> 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 <[email protected]> wrote:
>>>> On Sat, Jan 1, 2011 at 10:34 AM, <[email protected]> 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: <[email protected]>
>>>>> Date: Thu, Dec 30, 2010 11:36 PM
>>>>> To: [email protected]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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, <[email protected]> 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, <[email protected]> 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
>>>>>> [email protected]
>>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
>>>>>> _______________________________________________
>>>>> Openembedded-users mailing list
>>>>> [email protected]
>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
>>>>> _______________________________________________
>>>>> Openembedded-devel mailing list
>>>>> [email protected]
>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-devel mailing list
>>>> [email protected]
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> [email protected]
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFNJDAsMkyGM64RGpERAnXbAJ4nw3gu1JA47X0xUMOHFJ1sA31aTACdFw1K
> mJcYeEnaLSmo0XaY0eXokUU=
> =HU+c
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> [email protected]
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Reply via email to