Emir Elkholy <emirelkholy@...>
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.bz2After 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@...> wrote: Send yocto mailing list submissions to
yocto@...
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@...
You can reach the person managing the list at
yocto-owner@...
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@...>
To: Christopher Hallinan <challinan@...>
Cc: yocto@...
Subject: Re: [yocto] [PATCH] Fix X server on emenlow when built with
gcc 4.7.x
Message-ID: <1337700685.32464.16.camel@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@...> 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@...> 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@...> 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@...>
To: yocto@...
Subject: Re: [yocto] runqemu qemux86
Message-ID: <4FBBC712.404@...>
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@...
<mailto:autif.mlist@...>> wrote:
On Tue, May 22, 2012 at 7:43 AM, jfabernathy <jfabernathy@...
<mailto:jfabernathy@...>> 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@...>
To: Scott Garman <scott.a.garman@...>
Cc: yocto@...
Subject: Re: [yocto] runqemu qemux86
Message-ID:
<CANFv2EnvW6E_MfQ7FM8gOEo19qz1ACA57brMTMedUqkxo-DcLQ@...>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, May 22, 2012 at 1:04 PM, Scott Garman <scott.a.garman@...>wrote:
On 05/22/2012 08:15 AM, James Abernathy wrote:
On Tue, May 22, 2012 at 10:45 AM, Autif Khan <autif.mlist@...
<mailto:autif.mlist@...>**> wrote:
On Tue, May 22, 2012 at 7:43 AM, jfabernathy <jfabernathy@...
<mailto:jfabernathy@...>**> 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@...
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@...>
To: yocto@...
Subject: Re: [yocto] sending ioctl 5310 to a partition!
Message-ID: <4FBBCCD3.4010601@...>
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@...
https://lists.yoctoproject.org/listinfo/yocto
------------------------------
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
End of yocto Digest, Vol 20, Issue 82
*************************************
|
