[yocto] yocto Digest, Vol 20, Issue 82
Emir Elkholy
emirelkholy at gmail.com
Tue May 22 11:08:26 PDT 2012
Re: sending ioctl 5310 to a partition! (jfabernathy)
Thanks for the response. I'm trying to use an image that was provided
to me that has debugging support for the atom processor. My current
version of Yocto on my CRB works fine, but without debugging support.
I was provided with the following file which has the debugging
support:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/cedartrail/cedartrail-edison-6.0.1.tar.bz2
After I unpack the tarball it has the three images that can be used, I
am trying to use the sdk image :
(/meta-intel/meta-cedartrail/binary/core-image-sato-sdk-cedartrail.hddimg).
This 2GB image is what I preloaded on the usb drive which allowed me
to run yocto from the usb. Is there a way to follow the instructions
provided with the image that was given to me? Should I just bitbake
the image that was given to me and follow the instructions? Just want
to make sure I'm understanding the solution.
Thanks,
Emir
On Tue, May 22, 2012 at 1:28 PM, <yocto-request at yoctoproject.org> wrote:
> Send yocto mailing list submissions to
> yocto at yoctoproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.yoctoproject.org/listinfo/yocto
> or, via email, send a message with subject or body 'help' to
> yocto-request at yoctoproject.org
>
> You can reach the person managing the list at
> yocto-owner at yoctoproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of yocto digest..."
>
>
> Today's Topics:
>
> 1. Re: [PATCH] Fix X server on emenlow when built with gcc 4.7.x
> (Tom Zanussi)
> 2. Re: runqemu qemux86 (Scott Garman)
> 3. Re: runqemu qemux86 (James Abernathy)
> 4. Re: sending ioctl 5310 to a partition! (jfabernathy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 22 May 2012 10:31:25 -0500
> From: Tom Zanussi <tom.zanussi at intel.com>
> To: Christopher Hallinan <challinan at gmail.com>
> Cc: yocto at yoctoproject.org
> Subject: Re: [yocto] [PATCH] Fix X server on emenlow when built with
> gcc 4.7.x
> Message-ID: <1337700685.32464.16.camel at elmorro>
> Content-Type: text/plain; charset="UTF-8"
>
> On Mon, 2012-05-21 at 21:56 -0500, Christopher Hallinan wrote:
>> On Mon, May 21, 2012 at 2:30 PM, Tom Zanussi <tom.zanussi at intel.com> wrote:
>> > On Fri, 2012-05-18 at 23:02 -0400, Chris Hallinan wrote:
>> >> On Fri, May 18, 2012 at 6:25 PM, Tom Zanussi <tom.zanussi at intel.com> wrote:
>> >> > On Fri, 2012-05-18 at 17:38 -0400, Chris Hallinan wrote:
>> >> >> Note: this patch has already been submitted against other BSPs,
>> >> >> originally submitted to oe-core by Gary Thomas. I ran into this same
>> >> >> issue building MACHINE=emenlow on my own Z530 platform. There are
>> >> >> likely others as well where this needs to be applied.
>> >> >>
>> >> >> Upstream is here:
>> >> >> https://bugs.freedesktop.org/show_bug.cgi?id=18451
>> >> >>
>> >> >> PR has been bumped.
>> >> >>
>> >> >
>> >> > Hi, thanks for the patch - I see the problem and will pull this in as
>> >> > soon as I can build and test it, but am getting a patch failure in the
>> >> > build after pulling it in for testing. I'll fix it up, but just
>> >> > mentioning it in case you had any ideas why it might work for you but
>> >> > fail here...
>> >> >
>> >>
>> >> Sorry, Tom.
>> >> Odd, I generated the patch using git diff, but didn't actually try to
>> >> apply it to an unpatched tree. Looking at it, it isn't obvious why it
>> >> fails. Someone with more git/patch foo than me could probably explain
>> >> it ;)
>> >>
>> >> This one works (for me) against current top of tree:
>> >>
>> >
>> > It must be a whitespace problem - I still couldn't apply it, so manually
>> > fixed it up here, patch below.
>> >
>> > I also added an Upstream-status: section to the patch.
>> >
>> > Also, before pulling it in, I'll need to have you send me your
>> > Signed-off-by: line.
>> >
>> > Unfortunately, the problem now is that although I am getting a sato
>> > desktop, it has no icons or mouse/keyboard and I see this in the
>> > Xorg.0.log:
>> >
>> > Backtrace:
>> > 0: /usr/bin/Xorg (xorg_backtrace+0x37) [0x80e2e37]
>> > 1: /usr/bin/Xorg (0x8047000+0x5bda6) [0x80a2da6]
>> > 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xffffe40c]
>> > 3: /usr/lib/xorg/modules/drivers/psb_drv.so (0xb769b000+0x690c)
>> > [0xb76a190c]
>> > 4: /usr/lib/xorg/modules/libexa.so (0xb71ab000+0xcd0a) [0xb71b7d0a]
>> > 5: /usr/lib/xorg/modules/libexa.so (0xb71ab000+0xd300) [0xb71b8300]
>> > 6: /usr/lib/xorg/modules/libexa.so (0xb71ab000+0xb5fd) [0xb71b65fd]
>> > 7: /usr/bin/Xorg (0x8047000+0xc60c0) [0x810d0c0]
>> > 8: /usr/bin/Xorg (CompositeGlyphs+0xb1) [0x819f131]
>> > 9: /usr/bin/Xorg (0x8047000+0xc2e1e) [0x8109e1e]
>> > 10: /usr/bin/Xorg (0x8047000+0xbdb2e) [0x8104b2e]
>> > 11: /usr/bin/Xorg (0x8047000+0x286cf) [0x806f6cf]
>> > 12: /usr/bin/Xorg (0x8047000+0x1bbca) [0x8062bca]
>> > 13: /lib/libc.so.6 (__libc_start_main+0xf5) [0x42892ba5]
>> > 14: /usr/bin/Xorg (0x8047000+0x1bea1) [0x8062ea1]
>> > Segmentation fault at address 0xc
>> >
>> > Fatal server error:
>> > Caught signal 11 (Segmentation fault). Server aborting
>> >
>> >
>> > Can you tell me which poky commit you're using?
>>
>> I haven't sync'd lately. I'm using
>> poky: f39ba520d6f2477c99839a92049b1bb279f092cf
>> meta-intel: bde31fd7e66faea865d24ff0858a9006b89e4e54
>>
>> Third time should be a charm. With kergoth's help, I think I got this patch format correct!
>>
>> Signed-off-by: Christopher Hallinan <challinan at gmail.com>
>
> Yep, third time was the charm - applied cleanly and booted into sato
> without problem...
>
> Pulled into meta-intel/master.
>
> Thanks!
>
> Tom
>
>> ---
>> .../files/fix-bogus-stack-variables.patch | 204 ++++++++++++++++++++
>> .../xorg-xserver/xserver-psb-1.7.99.2.inc | 5 +-
>> 2 files changed, 207 insertions(+), 2 deletions(-)
>> create mode 100644 meta-emenlow/recipes-graphics/xorg-xserver/files/fix-bogus-stack-variables.patch
>>
>> diff --git a/meta-emenlow/recipes-graphics/xorg-xserver/files/fix-bogus-stack-variables.patch b/meta-emenlow/recipes-graphics/xorg-xserver/files/fix-bogus-stack-variables.patch
>> new file mode 100644
>> index 0000000..5c9581a
>> --- /dev/null
>> +++ b/meta-emenlow/recipes-graphics/xorg-xserver/files/fix-bogus-stack-variables.patch
>> @@ -0,0 +1,204 @@
>> +diff --git a/Xext/xace.c b/Xext/xace.c
>> +index e10d837..c757cad 100644
>> +--- a/Xext/xace.c
>> ++++ b/Xext/xace.c
>> +@@ -87,7 +87,18 @@ void XaceHookAuditEnd(ClientPtr ptr, int result)
>> + */
>> + int XaceHook(int hook, ...)
>> + {
>> +- pointer calldata; /* data passed to callback */
>> ++ union {
>> ++ XaceResourceAccessRec res;
>> ++ XaceDeviceAccessRec dev;
>> ++ XaceSendAccessRec send;
>> ++ XaceReceiveAccessRec recv;
>> ++ XaceClientAccessRec client;
>> ++ XaceExtAccessRec ext;
>> ++ XaceServerAccessRec server;
>> ++ XaceScreenAccessRec screen;
>> ++ XaceAuthAvailRec auth;
>> ++ XaceKeyAvailRec key;
>> ++ } u;
>> + int *prv = NULL; /* points to return value from callback */
>> + va_list ap; /* argument list */
>> + va_start(ap, hook);
>> +@@ -99,117 +110,86 @@ int XaceHook(int hook, ...)
>> + */
>> + switch (hook)
>> + {
>> +- case XACE_RESOURCE_ACCESS: {
>> +- XaceResourceAccessRec rec;
>> +- rec.client = va_arg(ap, ClientPtr);
>> +- rec.id = va_arg(ap, XID);
>> +- rec.rtype = va_arg(ap, RESTYPE);
>> +- rec.res = va_arg(ap, pointer);
>> +- rec.ptype = va_arg(ap, RESTYPE);
>> +- rec.parent = va_arg(ap, pointer);
>> +- rec.access_mode = va_arg(ap, Mask);
>> +- rec.status = Success; /* default allow */
>> +- calldata = &rec;
>> +- prv = &rec.status;
>> ++ case XACE_RESOURCE_ACCESS:
>> ++ u.res.client = va_arg(ap, ClientPtr);
>> ++ u.res.id = va_arg(ap, XID);
>> ++ u.res.rtype = va_arg(ap, RESTYPE);
>> ++ u.res.res = va_arg(ap, pointer);
>> ++ u.res.ptype = va_arg(ap, RESTYPE);
>> ++ u.res.parent = va_arg(ap, pointer);
>> ++ u.res.access_mode = va_arg(ap, Mask);
>> ++ u.res.status = Success; /* default allow */
>> ++ prv = &u.res.status;
>> + break;
>> +- }
>> +- case XACE_DEVICE_ACCESS: {
>> +- XaceDeviceAccessRec rec;
>> +- rec.client = va_arg(ap, ClientPtr);
>> +- rec.dev = va_arg(ap, DeviceIntPtr);
>> +- rec.access_mode = va_arg(ap, Mask);
>> +- rec.status = Success; /* default allow */
>> +- calldata = &rec;
>> +- prv = &rec.status;
>> ++ case XACE_DEVICE_ACCESS:
>> ++ u.dev.client = va_arg(ap, ClientPtr);
>> ++ u.dev.dev = va_arg(ap, DeviceIntPtr);
>> ++ u.dev.access_mode = va_arg(ap, Mask);
>> ++ u.dev.status = Success; /* default allow */
>> ++ prv = &u.dev.status;
>> + break;
>> +- }
>> +- case XACE_SEND_ACCESS: {
>> +- XaceSendAccessRec rec;
>> +- rec.client = va_arg(ap, ClientPtr);
>> +- rec.dev = va_arg(ap, DeviceIntPtr);
>> +- rec.pWin = va_arg(ap, WindowPtr);
>> +- rec.events = va_arg(ap, xEventPtr);
>> +- rec.count = va_arg(ap, int);
>> +- rec.status = Success; /* default allow */
>> +- calldata = &rec;
>> +- prv = &rec.status;
>> ++ case XACE_SEND_ACCESS:
>> ++ u.send.client = va_arg(ap, ClientPtr);
>> ++ u.send.dev = va_arg(ap, DeviceIntPtr);
>> ++ u.send.pWin = va_arg(ap, WindowPtr);
>> ++ u.send.events = va_arg(ap, xEventPtr);
>> ++ u.send.count = va_arg(ap, int);
>> ++ u.send.status = Success; /* default allow */
>> ++ prv = &u.send.status;
>> + break;
>> +- }
>> +- case XACE_RECEIVE_ACCESS: {
>> +- XaceReceiveAccessRec rec;
>> +- rec.client = va_arg(ap, ClientPtr);
>> +- rec.pWin = va_arg(ap, WindowPtr);
>> +- rec.events = va_arg(ap, xEventPtr);
>> +- rec.count = va_arg(ap, int);
>> +- rec.status = Success; /* default allow */
>> +- calldata = &rec;
>> +- prv = &rec.status;
>> ++ case XACE_RECEIVE_ACCESS:
>> ++ u.recv.client = va_arg(ap, ClientPtr);
>> ++ u.recv.pWin = va_arg(ap, WindowPtr);
>> ++ u.recv.events = va_arg(ap, xEventPtr);
>> ++ u.recv.count = va_arg(ap, int);
>> ++ u.recv.status = Success; /* default allow */
>> ++ prv = &u.recv.status;
>> + break;
>> +- }
>> +- case XACE_CLIENT_ACCESS: {
>> +- XaceClientAccessRec rec;
>> +- rec.client = va_arg(ap, ClientPtr);
>> +- rec.target = va_arg(ap, ClientPtr);
>> +- rec.access_mode = va_arg(ap, Mask);
>> +- rec.status = Success; /* default allow */
>> +- calldata = &rec;
>> +- prv = &rec.status;
>> ++ case XACE_CLIENT_ACCESS:
>> ++ u.client.client = va_arg(ap, ClientPtr);
>> ++ u.client.target = va_arg(ap, ClientPtr);
>> ++ u.client.access_mode = va_arg(ap, Mask);
>> ++ u.client.status = Success; /* default allow */
>> ++ prv = &u.client.status;
>> + break;
>> +- }
>> +- case XACE_EXT_ACCESS: {
>> +- XaceExtAccessRec rec;
>> +- rec.client = va_arg(ap, ClientPtr);
>> +- rec.ext = va_arg(ap, ExtensionEntry*);
>> +- rec.access_mode = DixGetAttrAccess;
>> +- rec.status = Success; /* default allow */
>> +- calldata = &rec;
>> +- prv = &rec.status;
>> ++ case XACE_EXT_ACCESS:
>> ++ u.ext.client = va_arg(ap, ClientPtr);
>> ++ u.ext.ext = va_arg(ap, ExtensionEntry*);
>> ++ u.ext.access_mode = DixGetAttrAccess;
>> ++ u.ext.status = Success; /* default allow */
>> ++ prv = &u.ext.status;
>> + break;
>> +- }
>> +- case XACE_SERVER_ACCESS: {
>> +- XaceServerAccessRec rec;
>> +- rec.client = va_arg(ap, ClientPtr);
>> +- rec.access_mode = va_arg(ap, Mask);
>> +- rec.status = Success; /* default allow */
>> +- calldata = &rec;
>> +- prv = &rec.status;
>> ++ case XACE_SERVER_ACCESS:
>> ++ u.server.client = va_arg(ap, ClientPtr);
>> ++ u.server.access_mode = va_arg(ap, Mask);
>> ++ u.server.status = Success; /* default allow */
>> ++ prv = &u.server.status;
>> + break;
>> +- }
>> + case XACE_SCREEN_ACCESS:
>> +- case XACE_SCREENSAVER_ACCESS: {
>> +- XaceScreenAccessRec rec;
>> +- rec.client = va_arg(ap, ClientPtr);
>> +- rec.screen = va_arg(ap, ScreenPtr);
>> +- rec.access_mode = va_arg(ap, Mask);
>> +- rec.status = Success; /* default allow */
>> +- calldata = &rec;
>> +- prv = &rec.status;
>> ++ case XACE_SCREENSAVER_ACCESS:
>> ++ u.screen.client = va_arg(ap, ClientPtr);
>> ++ u.screen.screen = va_arg(ap, ScreenPtr);
>> ++ u.screen.access_mode = va_arg(ap, Mask);
>> ++ u.screen.status = Success; /* default allow */
>> ++ prv = &u.screen.status;
>> + break;
>> +- }
>> +- case XACE_AUTH_AVAIL: {
>> +- XaceAuthAvailRec rec;
>> +- rec.client = va_arg(ap, ClientPtr);
>> +- rec.authId = va_arg(ap, XID);
>> +- calldata = &rec;
>> ++ case XACE_AUTH_AVAIL:
>> ++ u.auth.client = va_arg(ap, ClientPtr);
>> ++ u.auth.authId = va_arg(ap, XID);
>> + break;
>> +- }
>> +- case XACE_KEY_AVAIL: {
>> +- XaceKeyAvailRec rec;
>> +- rec.event = va_arg(ap, xEventPtr);
>> +- rec.keybd = va_arg(ap, DeviceIntPtr);
>> +- rec.count = va_arg(ap, int);
>> +- calldata = &rec;
>> ++ case XACE_KEY_AVAIL:
>> ++ u.key.event = va_arg(ap, xEventPtr);
>> ++ u.key.keybd = va_arg(ap, DeviceIntPtr);
>> ++ u.key.count = va_arg(ap, int);
>> + break;
>> +- }
>> +- default: {
>> ++ default:
>> + va_end(ap);
>> + return 0; /* unimplemented hook number */
>> +- }
>> + }
>> + va_end(ap);
>> +
>> + /* call callbacks and return result, if any. */
>> +- CallCallbacks(&XaceHooks[hook], calldata);
>> ++ CallCallbacks(&XaceHooks[hook], &u);
>> + return prv ? *prv : Success;
>> + }
>> diff --git a/meta-emenlow/recipes-graphics/xorg-xserver/xserver-psb-1.7.99.2.inc b/meta-emenlow/recipes-graphics/xorg-xserver/xserver-psb-1.7.99.2.inc
>> index 9ee9c97..1fe962b 100644
>> --- a/meta-emenlow/recipes-graphics/xorg-xserver/xserver-psb-1.7.99.2.inc
>> +++ b/meta-emenlow/recipes-graphics/xorg-xserver/xserver-psb-1.7.99.2.inc
>> @@ -1,4 +1,4 @@
>> -PR = "r5"
>> +PR = "r6"
>>
>> PROTO_DEPS += "xf86driproto dri2proto"
>>
>> @@ -8,7 +8,8 @@ SRC_URI += "file://nodolt.patch \
>> file://crosscompile.patch \
>> file://libdrm-poulsbo.patch \
>> file://werror-address-fix.patch \
>> - file://ptr-to-int-cast-fix.patch"
>> + file://ptr-to-int-cast-fix.patch \
>> + file://fix-bogus-stack-variables.patch"
>>
>> # Misc build failure for master HEAD
>> SRC_URI += "file://fix_open_max_preprocessor_error.patch"
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 22 May 2012 10:04:18 -0700
> From: Scott Garman <scott.a.garman at intel.com>
> To: yocto at yoctoproject.org
> Subject: Re: [yocto] runqemu qemux86
> Message-ID: <4FBBC712.404 at intel.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 05/22/2012 08:15 AM, James Abernathy wrote:
>>
>>
>> On Tue, May 22, 2012 at 10:45 AM, Autif Khan <autif.mlist at gmail.com
>> <mailto:autif.mlist at gmail.com>> wrote:
>>
>> On Tue, May 22, 2012 at 7:43 AM, jfabernathy <jfabernathy at gmail.com
>> <mailto:jfabernathy at gmail.com>> wrote:
>> > when testing an image using runqemu qemux86, can you get
>> networking to
>> > work?? mine comes up disabled. I want to test an application
>> that requires
>> > Internet access.
>>
>> Yes, I am able to get networking to work out of the box (bitbake
>> core-image-sato, etc.) Internetworking does not work out of the box.
>>
>> This is accomplished over tun/tap devices - I do not know much about
>> these virtual networking devices - they have never failed for me :-)
>>
>> The IP address of the emulated machine is 192.168.7.2 - The IP address
>> of host machine is 192.168.7.1
>>
>> You can not (out of the box) communicate with machines other than the
>> host machine - so that would included internet etc.
>>
>> So, if you have an ssh server or a web-server running on the host
>> machine - you can ssh to the host machine or browse a webpage using
>> the browser. Alternatively, you can run a proxy server on the build
>> machine and use it to get to the internet.
>>
>> You can run ifconfig to see if the network is configured properly on
>> the emulated machine in the terminal. It should show 192.168.7.2 - if
>> you do not see this - you do not have networking working.
>>
>>
>> I can see the tap0 interface on my host at 192.168.7.1 by using ifconfig.
>> I can also see the eth0 on the qemu machine at 192.168.7.2
>> However, my host has an ip of 10.0.1.54 with a AP gateway at 10.0.1.1.
>> Somehow I need to connect the networks and I'm not sure exactly how to
>> do that so that DNS servers get used and the traffic all flows.
>> Jim A
>
> There is some sort of routing or IP forwarding bug in the sato images
> that is due to be fixed soon. One thing I've found is you can actually
> get out to the internet for about 30 seconds or so immediately after the
> image boots. My suspicion is that some conman script is killing the
> route after boot. core-image-minimal works consistently, and since
> minimal doesn't use conman, I'm guessing that is the culprit.
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2329
>
> Scott
>
> --
> Scott Garman
> Embedded Linux Engineer - Yocto Project
> Intel Open Source Technology Center
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 22 May 2012 13:26:15 -0400
> From: James Abernathy <jfabernathy at gmail.com>
> To: Scott Garman <scott.a.garman at intel.com>
> Cc: yocto at yoctoproject.org
> Subject: Re: [yocto] runqemu qemux86
> Message-ID:
> <CANFv2EnvW6E_MfQ7FM8gOEo19qz1ACA57brMTMedUqkxo-DcLQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 22, 2012 at 1:04 PM, Scott Garman <scott.a.garman at intel.com>wrote:
>
>> On 05/22/2012 08:15 AM, James Abernathy wrote:
>>
>>>
>>>
>>> On Tue, May 22, 2012 at 10:45 AM, Autif Khan <autif.mlist at gmail.com
>>> <mailto:autif.mlist at gmail.com>**> wrote:
>>>
>>> On Tue, May 22, 2012 at 7:43 AM, jfabernathy <jfabernathy at gmail.com
>>> <mailto:jfabernathy at gmail.com>**> wrote:
>>> > when testing an image using runqemu qemux86, can you get
>>> networking to
>>> > work?? mine comes up disabled. I want to test an application
>>> that requires
>>> > Internet access.
>>>
>>> Yes, I am able to get networking to work out of the box (bitbake
>>> core-image-sato, etc.) Internetworking does not work out of the box.
>>>
>>> This is accomplished over tun/tap devices - I do not know much about
>>> these virtual networking devices - they have never failed for me :-)
>>>
>>> The IP address of the emulated machine is 192.168.7.2 - The IP address
>>> of host machine is 192.168.7.1
>>>
>>> You can not (out of the box) communicate with machines other than the
>>> host machine - so that would included internet etc.
>>>
>>> So, if you have an ssh server or a web-server running on the host
>>> machine - you can ssh to the host machine or browse a webpage using
>>> the browser. Alternatively, you can run a proxy server on the build
>>> machine and use it to get to the internet.
>>>
>>> You can run ifconfig to see if the network is configured properly on
>>> the emulated machine in the terminal. It should show 192.168.7.2 - if
>>> you do not see this - you do not have networking working.
>>>
>>>
>>> I can see the tap0 interface on my host at 192.168.7.1 by using ifconfig.
>>> I can also see the eth0 on the qemu machine at 192.168.7.2
>>> However, my host has an ip of 10.0.1.54 with a AP gateway at 10.0.1.1.
>>> Somehow I need to connect the networks and I'm not sure exactly how to
>>> do that so that DNS servers get used and the traffic all flows.
>>> Jim A
>>>
>>
>> There is some sort of routing or IP forwarding bug in the sato images that
>> is due to be fixed soon. One thing I've found is you can actually get out
>> to the internet for about 30 seconds or so immediately after the image
>> boots. My suspicion is that some conman script is killing the route after
>> boot. core-image-minimal works consistently, and since minimal doesn't use
>> conman, I'm guessing that is the culprit.
>>
>> https://bugzilla.yoctoproject.**org/show_bug.cgi?id=2329<https://bugzilla.yoctoproject.org/show_bug.cgi?id=2329>
>>
>> Scott
>>
> So if I read this right, I don't need any route or bridge commands to make
> this work. If the bug gets fixed runqemu qemux86 should setup the
> environment correctly so the web-webkit should get out to the internet via
> the host machine connection?
>
> JIm A
>
>
>> --
>> Scott Garman
>> Embedded Linux Engineer - Yocto Project
>> Intel Open Source Technology Center
>> ______________________________**_________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20120522/4728bb55/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 22 May 2012 13:28:51 -0400
> From: jfabernathy <jfabernathy at gmail.com>
> To: yocto at yoctoproject.org
> Subject: Re: [yocto] sending ioctl 5310 to a partition!
> Message-ID: <4FBBCCD3.4010601 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 05/21/2012 05:18 PM, Emir Elkholy wrote:
>> Hello,
>>
>> I am trying to install an image of Yocto to my CRB (cedartrail). After
>> creating the bootable usb with the new image on it as a usb-zip
>> (because it is too large for the hdd method of install), I insert it
>> into one of the usb slots of my CRB. After turning the CRB on the
>> prompt says "boot". At this point if you don't type anything it just
>> runs the image off of the USB. This worked with no problem. What
>> didn't work was trying to install the new image on my CRB. When the
>> CRB starts with the USB attached, it prompts the user with "boot"
>> which at this stage i typed "install". It seemed as if it was
>> installing because it was outputting various text, but then it just
>> stopped after outputting to the screen "sending ioctl 5310 to a
>> partition!". Hopefully someone on the mailing list has seen this
>> before. Any advise would help.
>
> If you want to put the image on a hard drive use the .ext3 image and
> follow the "how do I" on the wiki at:
>
> https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_put_Yocto_on_a_hard_drive.3F
>
> Jim A
>
>> Thanks
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> ------------------------------
>
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
> End of yocto Digest, Vol 20, Issue 82
> *************************************
More information about the yocto
mailing list