Re: [yocto] beta bug? MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS doesn't seem to work right...
On Tuesday 03 April 2012 23:49:20 Bob Cochran wrote: > I set MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "bogus" in my local.conf. > > This var is used in core-image-minimal; it's assigned to > RRECOMMENDS_task-core-boot inside task-core-boot.bb. > > Per the yocto glossary: "... the image will build if a file in this list > is not found. " > > But it doesn't build: > > ** > > NOTE: Resolving any missing task queue dependencies > ERROR: Nothing RPROVIDES 'bogus' (but > /opt/beta/yp-beta/meta/recipes-core/tasks/task-core-boot.bb RDEPENDS on > or otherwise requires it) > NOTE: Runtime target 'bogus' is unbuildable, removing... > Missing or unbuildable dependency chain was: ['bogus'] > NOTE: Runtime target 'task-core-boot' is unbuildable, removing... > Missing or unbuildable dependency chain was: ['task-core-boot', 'bogus'] > ERROR: Required build target 'core-image-minimal' has no buildable > providers. > Missing or unbuildable dependency chain was: ['core-image-minimal', > 'task-core-boot', 'bogus'] > > > > > Seems like a bug? No, this is not how the RRECOMMENDS mechanism works. There must be at least a possibility that the item in there exists (i.e., there must be a recipe that has it in its RPROVIDES, PACKAGES or an expression that would match it in PACKAGES_DYNAMIC). However, if a package corresponding to that item doesn't actually get produced, that is the situation that is ignored. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Porting of specific Kernel/Driver into yocto.
Hi, I want to build my local kernel/Driver code, not the default one. please help how can i do it ?. any wiki/docs on this?. Best Regards, Om Prakash Pal ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] should the dev docs match the dev yocto source?
just noticed that BSP guide suggests 3.0 is the preferred linux kernel, while the source itself is now up to 3.2. should those match? this is for *development* streams of both. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to change the startup application
Just an observation. the FAQ link that Autif did looks like a How Do I, which is the section in the Wiki right after the FAQ. Does that matter to anyone? Jim A On Tue, Apr 3, 2012 at 5:58 PM, Liu, Song wrote: > Thanks, Autif. I guess I missed the last word for the link, but it's > strange that the page was there. Anyway, I deleted mine. > > Song > > -Original Message- > From: Autif Khan [mailto:autif.ml...@gmail.com] > Sent: Tuesday, April 03, 2012 2:23 PM > To: Liu, Song > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] How to change the startup application > > Hi Song, > > I thought that I already updated the wiki. It seems like you created an > extra page. "_scripts" is missing from the link. It should be there. > > Source: > https://wiki.yoctoproject.org/wiki/Category:FAQ > > What I added days ago: > > https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup_scripts > > What you added (which I think should be deleted): > https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup > > Agree? > > On Tue, Apr 3, 2012 at 4:34 PM, Liu, Song wrote: > > Hi Autif, thanks a lot for providing the answer here. Since no one is > showing any objections here, I updated the wiki page with your answer ( > https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup). > Please let me know if there is any suggestions or concerns. > > > > Song > > > > -Original Message- > > From: Autif Khan [mailto:autif.ml...@gmail.com] > > Sent: Thursday, March 29, 2012 4:56 PM > > To: Liu, Song > > Cc: yocto@yoctoproject.org > > Subject: Re: [yocto] How to change the startup application > > > >> I got a question about how to change the startup application with Yocto > for images generated with Yocto. > >> And I googled it and landed on this page: > >> https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startu > >> p _scripts. Pretty good, someone was thinking about the same thing. > >> But this page turns out to be empty. It seems that we need to get > >> better than this. > >> > >> I'm wondering if someone could update this wiki page or if the > information is somewhere else... > > > > I do not know of if the information is elsewhere - I had to find this > > information for my project > > > > Here is my stab at it (already updated the wiki): > > > > Q: How do I change and add startup scripts? > > > > A: Edit meta/recipes-sato/matchbox-sato/matchbox-session-sato/session. > > Of course, if you have your own meta-layer, append the > matchbox-session-sato_0.1.bb recipe. > > > > Disable 'matchbox-desktop' and 'matchbox-panel', however, do not disable > 'exec matchbox-window-manager ...' > > > > Don't forget to run your app as a background process > > > > For example, the following code will start the fifteen game: > > > > #matchbox-desktop & > > > > # Lines containing feature-[foo] are removed at build time if the > machine # doesn't have the feature "foo". > > > > #START_APPLETS=showdesktop,windowselector > > #END_APPLETS=clock,battery,systray,startup-notify,notify > > #END_APPLETS=openmoko-panel-gsm,$END_APPLETS # feature-phone > > > > #matchbox-panel --titlebar --start-applets $START_APPLETS > > --end-applets $END_APPLETS & > > > > /usr/games/fifteen & > > > > exec matchbox-window-manager -theme Sato -use_desktop_mode decorated > > -use_cursor $SHOWCURSOR $@ > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Not booting on BeagleBoard xM 0x2
Hi, I am trying to get Yocto image built from yesterday's master (Linux-3.0.23-yocto-standard) to boot on the NAND-less version of BeagleBoard xM, but the kernel panics with: - console log start Waiting for root device /dev/mmcblk0p2... mmc0: new SDHC card at address 1234 mmcblk0: mmc0:1234 SA04G 3.67 GiB (ro) mmcblk0: p1 p2 VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2) Please append a correct "root=" boot option; here are the available partitions: b300 3858432 mmcblk0 driver: mmcblk b301 120456 mmcblk0p1 ----0mmcblk0p1 b302 3445942 mmcblk0p2 ----0mmcblk0p2 VFS: Unable to mount root fs on unknown-block(179,2) User configuration error - no valid root filesystem found Kernel panic - not syncing: Invalid configuration from end user prevents continuing -- console log end My guess would be the problem is the card being detected as 'ro' (line 3), but I do not know why that is (there is no lock switch on mmc cards). The card itself is fine, it's the original card that came with the board, the original Angstrom demo boots fine from it, and yocto kernel 2.6.37 also used to boot. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
Hi Tomas, On Wed, Apr 4, 2012 at 12:14 PM, Tomas Frydrych wrote: > Hi, > > I am trying to get Yocto image built from yesterday's master > (Linux-3.0.23-yocto-standard) to boot on the NAND-less version of > BeagleBoard xM, but the kernel panics with: > > - console log start > > Waiting for root device /dev/mmcblk0p2... > mmc0: new SDHC card at address 1234 > mmcblk0: mmc0:1234 SA04G 3.67 GiB (ro) > mmcblk0: p1 p2 > > VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2) > Please append a correct "root=" boot option; here are the available > partitions: > > b300 3858432 mmcblk0 driver: mmcblk > b301 120456 mmcblk0p1 ----0mmcblk0p1 > b302 3445942 mmcblk0p2 ----0mmcblk0p2 > > VFS: Unable to mount root fs on unknown-block(179,2) > User configuration error - no valid root filesystem found > Kernel panic - not syncing: Invalid configuration from end user prevents > continuing > > -- console log end > > My guess would be the problem is the card being detected as 'ro' (line > 3), but I do not know why that is (there is no lock switch on mmc cards). > > The card itself is fine, it's the original card that came with the > board, the original Angstrom demo boots fine from it, and yocto kernel > 2.6.37 also used to boot. > > Tomas Looks related to the comment I wrote here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1892 I have a slightly different failure with yocto 1.2 beta snapshot (same kernel) but seems related. Needs more investigation. Anyone else having problem booting on beagleboard xM? Seems something wrong happened after 1.1 release... Andrea ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] should the dev docs match the dev yocto source?
On 12-04-04 05:29 AM, Robert P. J. Day wrote: just noticed that BSP guide suggests 3.0 is the preferred linux kernel, while the source itself is now up to 3.2. should those match? this is for *development* streams of both. Not necessarily. It depends on the target. We haven't moved everything to 3.2 yet. It should probably say something more generic that choosing one of the last two yocto validated kernels is the preferred starting point. Cheers, Bruce rday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Porting of specific Kernel/Driver into yocto.
On 12-04-04 04:46 AM, Om Prakash PAL wrote: Hi, I want to build my local kernel/Driver code, not the default one. please help how can i do it ?. any wiki/docs on this?. The BSP developer guides show how to extend the yocto kernels, and also have sections on custom/different kernel versions. Have you seen that doc yet ? Or have you seen it, and have specific questions ? Bruce Best Regards, Om Prakash Pal ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
On 12-04-04 08:04 AM, Andrea Galbusera wrote: Hi Tomas, On Wed, Apr 4, 2012 at 12:14 PM, Tomas Frydrych wrote: Hi, I am trying to get Yocto image built from yesterday's master (Linux-3.0.23-yocto-standard) to boot on the NAND-less version of BeagleBoard xM, but the kernel panics with: - console log start Waiting for root device /dev/mmcblk0p2... mmc0: new SDHC card at address 1234 mmcblk0: mmc0:1234 SA04G 3.67 GiB (ro) mmcblk0: p1 p2 VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2) Please append a correct "root=" boot option; here are the available partitions: b300 3858432 mmcblk0 driver: mmcblk b301 120456 mmcblk0p1 ----0mmcblk0p1 b302 3445942 mmcblk0p2 ----0mmcblk0p2 VFS: Unable to mount root fs on unknown-block(179,2) User configuration error - no valid root filesystem found Kernel panic - not syncing: Invalid configuration from end user prevents continuing -- console log end My guess would be the problem is the card being detected as 'ro' (line 3), but I do not know why that is (there is no lock switch on mmc cards). The card itself is fine, it's the original card that came with the board, the original Angstrom demo boots fine from it, and yocto kernel 2.6.37 also used to boot. Tomas Looks related to the comment I wrote here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1892 I have a slightly different failure with yocto 1.2 beta snapshot (same kernel) but seems related. Needs more investigation. Anyone else having problem booting on beagleboard xM? Seems something wrong happened after 1.1 release... We are working on several bugs on our reference beagleboard. The problem is that my beagleboard died (a horrible painful death) and the other boards that are directly available to are RevC and they are booting. So things are slowed down a bit .. but we are trying to get to the bottom of it, as fast as possible. Cheers, Bruce Andrea ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] should the dev docs match the dev yocto source?
On Wed, 4 Apr 2012, Bruce Ashfield wrote: > On 12-04-04 05:29 AM, Robert P. J. Day wrote: > > > >just noticed that BSP guide suggests 3.0 is the preferred linux > > kernel, while the source itself is now up to 3.2. should those match? > > this is for *development* streams of both. > > Not necessarily. It depends on the target. We haven't moved everything > to 3.2 yet. > > It should probably say something more generic that choosing one of the > last two yocto validated kernels is the preferred starting point. understood. i was just looking at the part of the BSP guide using meta-crownbay as an example, and it kept referring to 3.0 when the development version is already up to 3.2. someone else can decide if that's worth syncing up, given that the 3.0 content is still there. not a big deal. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] 1.2 changelog
Hi all, I've examined all of the changes in the git log for 1.2 and prepared a very preliminary changelog of "significant" changes. However the following are still missing: * Changes with a bug number associated * Package upgrades * Kernel changes I can probably take care of adding the first two unless anyone else wants to volunteer, but will need some help on the third. Some of the items may need clarification as well. Here is the list as it stands: https://wiki.yoctoproject.org/wiki/Release_1.2_Changes (Note that changes in 1.1.1 have been separated out and should probably just be deleted, hopefully I didn't miss any). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.2 changelog
> Here is the list as it stands: > > https://wiki.yoctoproject.org/wiki/Release_1.2_Changes > > (Note that changes in 1.1.1 have been separated out and should probably just > be deleted, hopefully I didn't miss any). I was pleasantly surprised when unionfs showed up in the kernel - it is not in the list though. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
On 2012-04-04 06:50, Bruce Ashfield wrote: On 12-04-04 08:04 AM, Andrea Galbusera wrote: Hi Tomas, On Wed, Apr 4, 2012 at 12:14 PM, Tomas Frydrych wrote: Hi, I am trying to get Yocto image built from yesterday's master (Linux-3.0.23-yocto-standard) to boot on the NAND-less version of BeagleBoard xM, but the kernel panics with: - console log start Waiting for root device /dev/mmcblk0p2... mmc0: new SDHC card at address 1234 mmcblk0: mmc0:1234 SA04G 3.67 GiB (ro) mmcblk0: p1 p2 VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2) Please append a correct "root=" boot option; here are the available partitions: b300 3858432 mmcblk0 driver: mmcblk b301 120456 mmcblk0p1 ----0mmcblk0p1 b302 3445942 mmcblk0p2 ----0mmcblk0p2 VFS: Unable to mount root fs on unknown-block(179,2) User configuration error - no valid root filesystem found Kernel panic - not syncing: Invalid configuration from end user prevents continuing -- console log end My guess would be the problem is the card being detected as 'ro' (line 3), but I do not know why that is (there is no lock switch on mmc cards). The card itself is fine, it's the original card that came with the board, the original Angstrom demo boots fine from it, and yocto kernel 2.6.37 also used to boot. Tomas Looks related to the comment I wrote here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1892 I have a slightly different failure with yocto 1.2 beta snapshot (same kernel) but seems related. Needs more investigation. Anyone else having problem booting on beagleboard xM? Seems something wrong happened after 1.1 release... We are working on several bugs on our reference beagleboard. The problem is that my beagleboard died (a horrible painful death) and the other boards that are directly available to are RevC and they are booting. So things are slowed down a bit .. but we are trying to get to the bottom of it, as fast as possible. Just FYI, it also doesn't boot on my rev-C3 (not xM), albeit with a different error pattern. It hangs at this point: Waiting for root device /dev/mmcblk0p2... mmc0: error -110 whilst initialising SD card Looks like you might need the attached patch? -- Gary Thomas | Consulting for the MLB Associates |Embedded world >From 47be8c9046c22715ce646091dd9e98fa87fc86e1 Mon Sep 17 00:00:00 2001 From: Steve Sakoman Date: Mon, 18 Jul 2011 23:13:41 -0500 Subject: [PATCH 07/10] omap_hsmmc: Set dto to max value of 14 to avoid SD Card timeouts This fixes MMC errors due to timeouts on certain SD Cards following suggestions to set dto to 14 by Jason Kridner and Steven Kipisz Details of the issue: http://talk.maemo.org/showthread.php?p=1000707#post1000707 This fix was originally proposed by Sukumar Ghoral of TI. --- drivers/mmc/host/omap_hsmmc.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index dedf3da..a8a60d4 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1441,6 +1441,9 @@ static void set_data_timeout(struct omap_hsmmc_host *host, dto = 14; } + /* Set dto to max value of 14 to avoid SD Card timeouts */ + dto = 14; + reg &= ~DTO_MASK; reg |= dto << DTO_SHIFT; OMAP_HSMMC_WRITE(host->base, SYSCTL, reg); -- 1.7.2.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
Hi Gary, On Wed, Apr 4, 2012 at 4:10 PM, Gary Thomas wrote: > On 2012-04-04 06:50, Bruce Ashfield wrote: >> >> On 12-04-04 08:04 AM, Andrea Galbusera wrote: >>> >>> Hi Tomas, >>> >>> On Wed, Apr 4, 2012 at 12:14 PM, Tomas Frydrych >>> wrote: Hi, I am trying to get Yocto image built from yesterday's master (Linux-3.0.23-yocto-standard) to boot on the NAND-less version of BeagleBoard xM, but the kernel panics with: - console log start Waiting for root device /dev/mmcblk0p2... mmc0: new SDHC card at address 1234 mmcblk0: mmc0:1234 SA04G 3.67 GiB (ro) mmcblk0: p1 p2 VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2) Please append a correct "root=" boot option; here are the available partitions: b300 3858432 mmcblk0 driver: mmcblk b301 120456 mmcblk0p1 ----0mmcblk0p1 b302 3445942 mmcblk0p2 ----0mmcblk0p2 VFS: Unable to mount root fs on unknown-block(179,2) User configuration error - no valid root filesystem found Kernel panic - not syncing: Invalid configuration from end user prevents continuing -- console log end My guess would be the problem is the card being detected as 'ro' (line 3), but I do not know why that is (there is no lock switch on mmc cards). The card itself is fine, it's the original card that came with the board, the original Angstrom demo boots fine from it, and yocto kernel 2.6.37 also used to boot. Tomas >>> >>> >>> Looks related to the comment I wrote here: >>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1892 >>> I have a slightly different failure with yocto 1.2 beta snapshot (same >>> kernel) but seems related. Needs more investigation. >>> Anyone else having problem booting on beagleboard xM? Seems something >>> wrong happened after 1.1 release... >> >> >> We are working on several bugs on our reference beagleboard. The problem >> is that my beagleboard died (a horrible painful death) and the other >> boards >> that are directly available to are RevC and they are booting. So things >> are slowed down a bit .. but we are trying to get to the bottom of it, >> as fast as possible. > > > Just FYI, it also doesn't boot on my rev-C3 (not xM), albeit with a > different > error pattern. It hangs at this point: > > Waiting for root device /dev/mmcblk0p2... > mmc0: error -110 whilst initialising SD card That's exactly the same error I see! Happy to know am not alone... > Looks like you might need the attached patch? I'm going to give it a try as soon as I can. Did you already submit it somewhere? Andrea ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Experience survey of using Yocto 1.2
Experience survey of using Yocto 1.2 Q: Which architecture did you choose to build? A: qemu x86 and beagleboard Q: How easily were you able to build an image and boot an image? A: very simple. The format of the local.conf is straight forward Q: Is there any surprise to you in the process of doing this Beta testing? If so, would you please describe it and tell us how you expected it to work? A: It took long to build than I expected. Not sure if the parallel build on my machine was working properly. Q: How do you like our HOB interface? Please provide us with your thoughts and suggestions on HOB interface and functionality. A: I had trouble using hob for the beagleboard. I only got to play with it for qemu. I had trouble with package selection. When I tried to build a package list, it often didn't come back with a list. I also saw a number of errors reported in the background terminal when hob was launched. It just reported building packages list ... for a long time. Not sure what it was doing. Since I haven't seen this work to completion, not sure where to file a defect. Q: Was it easy to find the support you needed to build and boot an image? A: yes Q: Which Bugzilla reports did you submit? A: Bug 2232 - hob fails to configure project for beagleboard Q: Did you try anything else with Yocto 1.2? A: I am still in the process of setting up a gdbserver test with beagleboard. I would like to have a easier way to select to create a debug filesystem. I think you can do this with hob, but I had troubles above. Q: What would you like to have in Yocto Project for future releases? A: In the next beta phase, it would be good to get a kick off meeting to got over new features for that release. We could go over suggestion to "divide and conquer" what we should focus on. Also a primer on hob might be a good discussion. I only got to work with it for a few days, since I was on vacation all last week. Considering the short amount of time spent, it went fairly well. Howard Alyne Sr. Engineering Specialist WIND RIVER | ph 847-658-7040 | cell 847-302-5610 howard.al...@windriver.commailto:k...@windriver.com> |www.windriver.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
On 2012-04-04 08:58, Andrea Galbusera wrote: Hi Gary, On Wed, Apr 4, 2012 at 4:10 PM, Gary Thomas wrote: On 2012-04-04 06:50, Bruce Ashfield wrote: On 12-04-04 08:04 AM, Andrea Galbusera wrote: Hi Tomas, On Wed, Apr 4, 2012 at 12:14 PM, Tomas Frydrych wrote: Hi, I am trying to get Yocto image built from yesterday's master (Linux-3.0.23-yocto-standard) to boot on the NAND-less version of BeagleBoard xM, but the kernel panics with: - console log start Waiting for root device /dev/mmcblk0p2... mmc0: new SDHC card at address 1234 mmcblk0: mmc0:1234 SA04G 3.67 GiB (ro) mmcblk0: p1 p2 VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2) Please append a correct "root=" boot option; here are the available partitions: b300 3858432 mmcblk0 driver: mmcblk b301 120456 mmcblk0p1 ----0mmcblk0p1 b302 3445942 mmcblk0p2 ----0mmcblk0p2 VFS: Unable to mount root fs on unknown-block(179,2) User configuration error - no valid root filesystem found Kernel panic - not syncing: Invalid configuration from end user prevents continuing -- console log end My guess would be the problem is the card being detected as 'ro' (line 3), but I do not know why that is (there is no lock switch on mmc cards). The card itself is fine, it's the original card that came with the board, the original Angstrom demo boots fine from it, and yocto kernel 2.6.37 also used to boot. Tomas Looks related to the comment I wrote here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1892 I have a slightly different failure with yocto 1.2 beta snapshot (same kernel) but seems related. Needs more investigation. Anyone else having problem booting on beagleboard xM? Seems something wrong happened after 1.1 release... We are working on several bugs on our reference beagleboard. The problem is that my beagleboard died (a horrible painful death) and the other boards that are directly available to are RevC and they are booting. So things are slowed down a bit .. but we are trying to get to the bottom of it, as fast as possible. Just FYI, it also doesn't boot on my rev-C3 (not xM), albeit with a different error pattern. It hangs at this point: Waiting for root device /dev/mmcblk0p2... mmc0: error -110 whilst initialising SD card That's exactly the same error I see! Happy to know am not alone... Looks like you might need the attached patch? I'm going to give it a try as soon as I can. Did you already submit it somewhere? I haven't had a chance to try it yet. I got it from the meta-ti layer. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project 1.2 Beta testing instructions
Can someone help answer the following question? This happens during Boon Pin's beta testing using the build at: http://git.yoctoproject.org/cgit/cgit.cgi/poky/snapshot/poky-8e9f6fc77ac4763f4ed1f6e7b720420c220ba6e2.tar.bz2 . Song From: Khor, Boon Pin Sent: Tuesday, April 03, 2012 6:32 PM To: Liu, Song Subject: RE: Yocto Project 1.2 Beta testing instructions Hi Song On my ubuntu 11 .10 64bits machine I run till | Processing task-core-boot... | Manifest: /home/nemo/yp-beta-build/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/rootfs/install/install.manifest | local: 1: -Uhv: bad variable name NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Failed ERROR: Task 8 (/home/nemo/yp-beta/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 1329 tasks of which 287 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/nemo/yp-beta/meta/recipes-core/images/core-image-minimal.bb, do_rootfs Summary: There were 12 WARNING messages shown. Summary: There was 1 ERROR message shown, returning a non-zero exit code. # Install manifest /home/nemo/yp-beta-build/tmp/deploy/rpm/qemux86/task-core-boot-1.0-r9.qemux86.rpm Maybe I am missing rpm packages in ubuntu ? Thanks Boon Pin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
Garry/Andrea, I am currently giving a training based on the Beagle-XM an this error happened at the same time on 5 boards with a 3.1 kernel. > error pattern. It hangs at this point: > Waiting for root device /dev/mmcblk0p2... > mmc0: error -110 whilst initialising SD card > The fix was to change the SD cards and use cards from a different manufacturer, so yes, it seems to be related to some funny SD card timings. I did not try to patch yet. Regards, Robert ..."To assert that the earth revolves around the sun is as erroneous as to claim that Jesus was not born of a virgin." - Cardinal Bellarmine 1615, during the trial of Galileo My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
On 4 Apr 2012, at 19:49, Robert Berger wrote: > Garry/Andrea, > > I am currently giving a training based on the Beagle-XM an this error > happened at the same time on 5 boards with a 3.1 kernel. > > >> error pattern. It hangs at this point: >> Waiting for root device /dev/mmcblk0p2... >> mmc0: error -110 whilst initialising SD card >> > > The fix was to change the SD cards and use cards from a different > manufacturer, so yes, it seems to be related to some funny SD card timings. Not sure if it help, but the Raspberry Pi team have been having problems with SD cards as well. Some work, some don't - even when they have the same part numbers. Seems as if some silicon / firmware revision along the way has changed something somewhere... Chris ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] are there more yocto-bsp commands other than "create" and "list"?
help for yocto-bsp reads:
The most commonly used 'yocto-bsp' commands are:
createCreate a new Yocto BSP
list List available values for options and BSP properties
but from the script:
subcommands = {
"create": [yocto_bsp_create_subcommand,
yocto_bsp_create_usage,
yocto_bsp_create_help],
"list": [yocto_bsp_list_subcommand,
yocto_bsp_list_usage,
yocto_bsp_list_help],
}
so it's not so much they're the most common commands, aren't they
the *only* commands? or am i misreading something?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1][1.2] syslinux: Avoid using linux.ext2_fs.h if possible
Please apply to poky for 1.2. Should also be applied to oe-core. The following changes since commit cd4d346c0e83fc9bf5497dd0424368e9244b6e08: documentation/yocto-project-qs/yocto-project-qs.xml: Added CentOS distro (2012-04-04 00:34:03 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dvhart/syslinux http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dvhart/syslinux Darren Hart (1): syslinux: Avoid using linux.ext2_fs.h if possible .../libinstaller-Avoid-using-linux-ext2_fs.h.patch | 975 meta/recipes-devtools/syslinux/syslinux_4.03.bb|5 +- 2 files changed, 978 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch -- 1.7.6.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] syslinux: Avoid using linux.ext2_fs.h if possible
Fixes [YOCTO 2236] With recent Linux kernel headers, such as 3.3 in Fedora 16, the linux/ext2_fs.h header has been removed. This causes compile failures for syslinux-native. Backport a fix to address this from syslinux-4.06-pre3. Signed-off-by: Darren Hart CC: Ross Burton CC: Joshua Lock --- .../libinstaller-Avoid-using-linux-ext2_fs.h.patch | 975 meta/recipes-devtools/syslinux/syslinux_4.03.bb|5 +- 2 files changed, 978 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch diff --git a/meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch b/meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch new file mode 100644 index 000..77d7a5d --- /dev/null +++ b/meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch @@ -0,0 +1,975 @@ +From a1006762fa6f98750bb77d76dd992cb8ea9f9c99 Mon Sep 17 00:00:00 2001 +Message-Id: +From: "H. Peter Anvin" +Date: Mon, 26 Mar 2012 22:51:09 -0700 +Subject: [PATCH] libinstaller: Avoid using + +Don't use if we can avoid it. + +Upstream-Status: Available in syslinux-4.06-pre3 + +The ioctl constants have been globalized and moved to . +Use a private copy of ext2_fs.h from e2fsprogs with the ioctl +constants removed for the data structures. + +Do at least attempt backward compatibility for old kernel headers, but +no real hope of proper operation there... + +Signed-off-by: H. Peter Anvin + +Massaged into 4.03. + +Integrated-by: Darren Hart +--- + libinstaller/ext2fs/ext2_fs.h | 856 + + libinstaller/linuxioctl.h | 29 ++- + libinstaller/syslxcom.c | 12 +- + 3 files changed, 886 insertions(+), 11 deletions(-) + create mode 100644 libinstaller/ext2fs/ext2_fs.h + +Index: syslinux-4.03/libinstaller/ext2fs/ext2_fs.h +=== +--- /dev/null syslinux-4.03/libinstaller/ext2fs/ext2_fs.h +@@ -0,0 +1,856 @@ ++/* ++ * linux/include/linux/ext2_fs.h ++ * ++ * Copyright (C) 1992, 1993, 1994, 1995 ++ * Remy Card (c...@masi.ibp.fr) ++ * Laboratoire MASI - Institut Blaise Pascal ++ * Universite Pierre et Marie Curie (Paris VI) ++ * ++ * from ++ * ++ * linux/include/linux/minix_fs.h ++ * ++ * Copyright (C) 1991, 1992 Linus Torvalds ++ */ ++ ++#ifndef _EXT2FS_EXT2_FS_H ++#define _EXT2FS_EXT2_FS_H ++ ++#include ++ ++/* ++ * The second extended filesystem constants/structures ++ */ ++ ++/* ++ * Define EXT2FS_DEBUG to produce debug messages ++ */ ++#undef EXT2FS_DEBUG ++ ++/* ++ * Define EXT2_PREALLOCATE to preallocate data blocks for expanding files ++ */ ++#define EXT2_PREALLOCATE ++#define EXT2_DEFAULT_PREALLOC_BLOCKS 8 ++ ++/* ++ * The second extended file system version ++ */ ++#define EXT2FS_DATE "95/08/09" ++#define EXT2FS_VERSION"0.5b" ++ ++/* ++ * Special inode numbers ++ */ ++#define EXT2_BAD_INO 1 /* Bad blocks inode */ ++#define EXT2_ROOT_INO 2 /* Root inode */ ++#define EXT4_USR_QUOTA_INO 3 /* User quota inode */ ++#define EXT4_GRP_QUOTA_INO 4 /* Group quota inode */ ++#define EXT2_BOOT_LOADER_INO 5 /* Boot loader inode */ ++#define EXT2_UNDEL_DIR_INO 6 /* Undelete directory inode */ ++#define EXT2_RESIZE_INO7 /* Reserved group descriptors inode */ ++#define EXT2_JOURNAL_INO 8 /* Journal inode */ ++#define EXT2_EXCLUDE_INO 9 /* The "exclude" inode, for snapshots */ ++#define EXT4_REPLICA_INO 10 /* Used by non-upstream feature */ ++ ++/* First non-reserved inode for old ext2 filesystems */ ++#define EXT2_GOOD_OLD_FIRST_INO 11 ++ ++/* ++ * The second extended file system magic number ++ */ ++#define EXT2_SUPER_MAGIC 0xEF53 ++ ++#ifdef __KERNEL__ ++#define EXT2_SB(sb) (&((sb)->u.ext2_sb)) ++#else ++/* Assume that user mode programs are passing in an ext2fs superblock, not ++ * a kernel struct super_block. This will allow us to call the feature-test ++ * macros from user land. */ ++#define EXT2_SB(sb) (sb) ++#endif ++ ++/* ++ * Maximal count of links to a file ++ */ ++#define EXT2_LINK_MAX 65000 ++ ++/* ++ * Macro-instructions used to manage several block sizes ++ */ ++#define EXT2_MIN_BLOCK_LOG_SIZE 10 /* 1024 */ ++#define EXT2_MAX_BLOCK_LOG_SIZE 16 /* 65536 */ ++#define EXT2_MIN_BLOCK_SIZE (1 << EXT2_MIN_BLOCK_LOG_SIZE) ++#define EXT2_MAX_BLOCK_SIZE (1 << EXT2_MAX_BLOCK_LOG_SIZE) ++#ifdef __KERNEL__ ++#define EXT2_BLOCK_SIZE(s)((s)->s_blocksize) ++#define EXT2_BLOCK_SIZE_BITS(s) ((s)->s_blocksize_bits) ++#define EXT2_ADDR_PER_BLOCK_BITS(s) (EXT2_SB(s)->addr_per_block_bits) ++#define EXT2_INODE_SIZE(s)(EXT2_SB(s)->s_inode_size) ++#define EXT2_FIRST_INO(s) (EXT2_SB(s)->s_first_ino) ++#else ++#define EXT2_BLOCK_SIZE(s)(EXT2_MIN_BLOC
[yocto] [PATCH 0/1][1.1.2] syslinux: Avoid using linux.ext2_fs.h if possible
Please apply to poky/edison branch for 1.1.2 release. A corresponding patch has been sent for oe-core and poky/master for the 1.2 release. The following changes since commit 0fbd6a161576b2cafa8583adde0ffb15347c884a: poky.conf: Bumping SKD_VERSION (2012-03-14 15:49:33 -0700) are available in the git repository at: git://git.pokylinux.org/poky-contrib dvhart/bug2236 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dvhart/bug/2036 Darren Hart (1): syslinux: Avoid using linux.ext2_fs.h if possible .../libinstaller-Avoid-using-linux-ext2_fs.h.patch | 975 meta/recipes-devtools/syslinux/syslinux_4.03.bb|5 +- 2 files changed, 978 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch -- 1.7.6.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] syslinux: Avoid using linux.ext2_fs.h if possible
Fixes [YOCTO 2236] With recent Linux kernel headers, such as 3.3 in Fedora 16, the linux/ext2_fs.h header has been removed. This causes compile failures for syslinux-native. Backport a fix to address this from syslinux-4.06-pre3. Signed-off-by: Darren Hart CC: Ross Burton CC: Joshua Lock Signed-off-by: Darren Hart --- .../libinstaller-Avoid-using-linux-ext2_fs.h.patch | 975 meta/recipes-devtools/syslinux/syslinux_4.03.bb|5 +- 2 files changed, 978 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch diff --git a/meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch b/meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch new file mode 100644 index 000..77d7a5d --- /dev/null +++ b/meta/recipes-devtools/syslinux/files/libinstaller-Avoid-using-linux-ext2_fs.h.patch @@ -0,0 +1,975 @@ +From a1006762fa6f98750bb77d76dd992cb8ea9f9c99 Mon Sep 17 00:00:00 2001 +Message-Id: +From: "H. Peter Anvin" +Date: Mon, 26 Mar 2012 22:51:09 -0700 +Subject: [PATCH] libinstaller: Avoid using + +Don't use if we can avoid it. + +Upstream-Status: Available in syslinux-4.06-pre3 + +The ioctl constants have been globalized and moved to . +Use a private copy of ext2_fs.h from e2fsprogs with the ioctl +constants removed for the data structures. + +Do at least attempt backward compatibility for old kernel headers, but +no real hope of proper operation there... + +Signed-off-by: H. Peter Anvin + +Massaged into 4.03. + +Integrated-by: Darren Hart +--- + libinstaller/ext2fs/ext2_fs.h | 856 + + libinstaller/linuxioctl.h | 29 ++- + libinstaller/syslxcom.c | 12 +- + 3 files changed, 886 insertions(+), 11 deletions(-) + create mode 100644 libinstaller/ext2fs/ext2_fs.h + +Index: syslinux-4.03/libinstaller/ext2fs/ext2_fs.h +=== +--- /dev/null syslinux-4.03/libinstaller/ext2fs/ext2_fs.h +@@ -0,0 +1,856 @@ ++/* ++ * linux/include/linux/ext2_fs.h ++ * ++ * Copyright (C) 1992, 1993, 1994, 1995 ++ * Remy Card (c...@masi.ibp.fr) ++ * Laboratoire MASI - Institut Blaise Pascal ++ * Universite Pierre et Marie Curie (Paris VI) ++ * ++ * from ++ * ++ * linux/include/linux/minix_fs.h ++ * ++ * Copyright (C) 1991, 1992 Linus Torvalds ++ */ ++ ++#ifndef _EXT2FS_EXT2_FS_H ++#define _EXT2FS_EXT2_FS_H ++ ++#include ++ ++/* ++ * The second extended filesystem constants/structures ++ */ ++ ++/* ++ * Define EXT2FS_DEBUG to produce debug messages ++ */ ++#undef EXT2FS_DEBUG ++ ++/* ++ * Define EXT2_PREALLOCATE to preallocate data blocks for expanding files ++ */ ++#define EXT2_PREALLOCATE ++#define EXT2_DEFAULT_PREALLOC_BLOCKS 8 ++ ++/* ++ * The second extended file system version ++ */ ++#define EXT2FS_DATE "95/08/09" ++#define EXT2FS_VERSION"0.5b" ++ ++/* ++ * Special inode numbers ++ */ ++#define EXT2_BAD_INO 1 /* Bad blocks inode */ ++#define EXT2_ROOT_INO 2 /* Root inode */ ++#define EXT4_USR_QUOTA_INO 3 /* User quota inode */ ++#define EXT4_GRP_QUOTA_INO 4 /* Group quota inode */ ++#define EXT2_BOOT_LOADER_INO 5 /* Boot loader inode */ ++#define EXT2_UNDEL_DIR_INO 6 /* Undelete directory inode */ ++#define EXT2_RESIZE_INO7 /* Reserved group descriptors inode */ ++#define EXT2_JOURNAL_INO 8 /* Journal inode */ ++#define EXT2_EXCLUDE_INO 9 /* The "exclude" inode, for snapshots */ ++#define EXT4_REPLICA_INO 10 /* Used by non-upstream feature */ ++ ++/* First non-reserved inode for old ext2 filesystems */ ++#define EXT2_GOOD_OLD_FIRST_INO 11 ++ ++/* ++ * The second extended file system magic number ++ */ ++#define EXT2_SUPER_MAGIC 0xEF53 ++ ++#ifdef __KERNEL__ ++#define EXT2_SB(sb) (&((sb)->u.ext2_sb)) ++#else ++/* Assume that user mode programs are passing in an ext2fs superblock, not ++ * a kernel struct super_block. This will allow us to call the feature-test ++ * macros from user land. */ ++#define EXT2_SB(sb) (sb) ++#endif ++ ++/* ++ * Maximal count of links to a file ++ */ ++#define EXT2_LINK_MAX 65000 ++ ++/* ++ * Macro-instructions used to manage several block sizes ++ */ ++#define EXT2_MIN_BLOCK_LOG_SIZE 10 /* 1024 */ ++#define EXT2_MAX_BLOCK_LOG_SIZE 16 /* 65536 */ ++#define EXT2_MIN_BLOCK_SIZE (1 << EXT2_MIN_BLOCK_LOG_SIZE) ++#define EXT2_MAX_BLOCK_SIZE (1 << EXT2_MAX_BLOCK_LOG_SIZE) ++#ifdef __KERNEL__ ++#define EXT2_BLOCK_SIZE(s)((s)->s_blocksize) ++#define EXT2_BLOCK_SIZE_BITS(s) ((s)->s_blocksize_bits) ++#define EXT2_ADDR_PER_BLOCK_BITS(s) (EXT2_SB(s)->addr_per_block_bits) ++#define EXT2_INODE_SIZE(s)(EXT2_SB(s)->s_inode_size) ++#define EXT2_FIRST_INO(s) (EXT2_SB(s)->s_first_ino) ++#else ++#define EXT2_BLO
Re: [yocto] are there more yocto-bsp commands other than "create" and "list"?
On Wed, 2012-04-04 at 16:16 -0400, Robert P. J. Day wrote:
> help for yocto-bsp reads:
>
> The most commonly used 'yocto-bsp' commands are:
> createCreate a new Yocto BSP
> list List available values for options and BSP properties
>
> but from the script:
>
> subcommands = {
> "create": [yocto_bsp_create_subcommand,
>yocto_bsp_create_usage,
>yocto_bsp_create_help],
> "list": [yocto_bsp_list_subcommand,
>yocto_bsp_list_usage,
>yocto_bsp_list_help],
> }
>
> so it's not so much they're the most common commands, aren't they
> the *only* commands? or am i misreading something?
>
At the moment, they are the only commands, and I guess therefore also
the most commonly used.
The interface is modeled after git and perf, which both use the same
text. I suppose that to avoid being misleading, we should replace 'most
commonly' with 'available', also since I also don't envision adding any
'rare' commands...
Tom
> rday
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] are there more yocto-bsp commands other than "create" and "list"?
On Wed, 4 Apr 2012, Tom Zanussi wrote:
> On Wed, 2012-04-04 at 16:16 -0400, Robert P. J. Day wrote:
> > help for yocto-bsp reads:
> >
> > The most commonly used 'yocto-bsp' commands are:
> > createCreate a new Yocto BSP
> > list List available values for options and BSP properties
> >
> > but from the script:
> >
> > subcommands = {
> > "create": [yocto_bsp_create_subcommand,
> >yocto_bsp_create_usage,
> >yocto_bsp_create_help],
> > "list": [yocto_bsp_list_subcommand,
> >yocto_bsp_list_usage,
> >yocto_bsp_list_help],
> > }
> >
> > so it's not so much they're the most common commands, aren't they
> > the *only* commands? or am i misreading something?
> >
>
> At the moment, they are the only commands, and I guess therefore also
> the most commonly used.
>
> The interface is modeled after git and perf, which both use the same
> text. I suppose that to avoid being misleading, we should replace 'most
> commonly' with 'available', also since I also don't envision adding any
> 'rare' commands...
that's pretty much the observation i was making. the same holds for
yocto-kernel. i can submit a patch shortly, perhaps:
Current yocto- commands are:
does that work for you?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] scripts: Clarify "help" info for yocto-bsp and yocto-kernel
Tweak the help info for both "yocto-bsp" and "yocto-kernel" to emphasize that those are the *complete* lists of commands, not just the most commonly used ones. Signed-off-by: Robert P. J. Day --- diff --git a/scripts/lib/bsp/help.py b/scripts/lib/bsp/help.py index 200a4f8..f78b09b 100644 --- a/scripts/lib/bsp/help.py +++ b/scripts/lib/bsp/help.py @@ -83,7 +83,7 @@ yocto_bsp_usage = """ usage: yocto-bsp [--version] [--help] COMMAND [ARGS] - The most commonly used 'yocto-bsp' commands are: + Current 'yocto-bsp' commands are: createCreate a new Yocto BSP list List available values for options and BSP properties @@ -336,7 +336,7 @@ yocto_kernel_usage = """ usage: yocto-kernel [--version] [--help] COMMAND [ARGS] - The most commonly used 'yocto-kernel' commands are: + Current 'yocto-kernel' commands are: config list List the modifiable set of bare kernel config options for a BSP config addAdd or modify bare kernel config options for a BSP config rm Remove bare kernel config options from a BSP -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Fix small number of misspellings of "subsequent".
Signed-off-by: Robert P. J. Day
---
diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index 14a7197..548048f 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -877,7 +877,7 @@
...
NOTE: Once created, you should add your new layer to your
- bblayers.conf file in order for it to be subsquently seen and
+ bblayers.conf file in order for it to be subsequently seen and
modified by the yocto-kernel tool.
NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index 997dcd1..0bd81bd 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -26,7 +26,7 @@ do_rm_work () {
rm -rf $dir
fi
done
-# Need to add pseudo back or subsqeuent work in this workdir
+# Need to add pseudo back or subsequent work in this workdir
# might fail since setscene may not rerun to recreate it
mkdir ${WORKDIR}/pseudo/
diff --git a/scripts/lib/bsp/help.py b/scripts/lib/bsp/help.py
index 200a4f8..54501d8 100644
--- a/scripts/lib/bsp/help.py
+++ b/scripts/lib/bsp/help.py
@@ -156,7 +156,7 @@ DESCRIPTION
current directory, and is useful for debugging.
NOTE: Once created, you should add your new layer to your
-bblayers.conf file in order for it to be subsquently seen and
+bblayers.conf file in order for it to be subsequently seen and
modified by the yocto-kernel tool.
NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using vendo kernel with Yocto
Hello, I have this situation: My vendor device provides a kernel (2.6.22.19) with a patch to its device. The device is a arm920t. And the vendor is Mindspeed. I want to use Yocto to build the kernel and userland. In the past the vendor provided a very old debian-like userland. I am trying the following: - create a recipe to build the kernel 2.6.22.19 with patch to the device supplied by vendor - build a image using core-image-minimal only to boot the device - I think that linux-libc-headers should be 2.6.22.19, but I am trying with linux-libc-headers-yocto - the device boots with kernel compiled with Yocto but I have some sort of problems with boot scripts. I am investigating. Questions: With Yocto (1.2M3), I can use a kernel 2.6.22.19 with userland provide by Yocto project? What is the minimal version of the kernel supported by Yocto? I have other way to choice like port the vendor patch to a newer kernel. But I prefer trying these way for now. Thanks. -- --- João Henrique Freitas - joaohf_at_gmail.com Campinas-SP-Brasil BSD051283 LPI 1 http://www.joaohfreitas.eti.br ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] Fix small number of misspellings of "subsequent".
Robert,
Can you create a patch just for the documentation? I don't apply patches for
other parts of the system. If you don't want to do that I can just fix the
misspellings in the bsp guide.
Scott
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Robert P. J. Day
Sent: Wednesday, April 04, 2012 3:43 PM
To: Yocto discussion list
Subject: [yocto] [PATCH] Fix small number of misspellings of "subsequent".
Signed-off-by: Robert P. J. Day
---
diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index 14a7197..548048f 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -877,7 +877,7 @@
...
NOTE: Once created, you should add your new layer to your
- bblayers.conf file in order for it to be subsquently seen and
+ bblayers.conf file in order for it to be subsequently seen and
modified by the yocto-kernel tool.
NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index 997dcd1..0bd81bd 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -26,7 +26,7 @@ do_rm_work () {
rm -rf $dir
fi
done
-# Need to add pseudo back or subsqeuent work in this workdir
+# Need to add pseudo back or subsequent work in this workdir
# might fail since setscene may not rerun to recreate it
mkdir ${WORKDIR}/pseudo/
diff --git a/scripts/lib/bsp/help.py b/scripts/lib/bsp/help.py
index 200a4f8..54501d8 100644
--- a/scripts/lib/bsp/help.py
+++ b/scripts/lib/bsp/help.py
@@ -156,7 +156,7 @@ DESCRIPTION
current directory, and is useful for debugging.
NOTE: Once created, you should add your new layer to your
-bblayers.conf file in order for it to be subsquently seen and
+bblayers.conf file in order for it to be subsequently seen and
modified by the yocto-kernel tool.
NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] [meta-intel] Switching romley to 3.2 kernel
From: Kishore Bodke Adding bbappend files to switch Romley BSP to 3.2 kernel. Thanks Kishore. The following changes since commit f89405e115d73426c8a6450b6e795b5885d6bdf3: MAINTAINERS: Add FRI2 maintainer (2012-03-23 09:46:15 -0700) are available in the git repository at: git://git.pokylinux.org/meta-intel-contrib kishore/romley-switch-1.2 http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=kishore/romley-switch-1.2 Kishore Bodke (1): Romley: Add new bbappend file for 3.2 kernel meta-romley/conf/machine/romley.conf |3 +++ .../linux/linux-yocto-rt_3.2.bbappend |8 .../recipes-kernel/linux/linux-yocto_3.2.bbappend |9 + 3 files changed, 20 insertions(+), 0 deletions(-) create mode 100644 meta-romley/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend create mode 100644 meta-romley/recipes-kernel/linux/linux-yocto_3.2.bbappend -- 1.7.5.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] [meta-intel] Romley: Add new bbappend file for 3.2 kernel
From: Kishore Bodke
Switching Romley to 3.2 kernel.
Signed-off-by: Kishore Bodke
---
meta-romley/conf/machine/romley.conf |3 +++
.../linux/linux-yocto-rt_3.2.bbappend |8
.../recipes-kernel/linux/linux-yocto_3.2.bbappend |9 +
3 files changed, 20 insertions(+), 0 deletions(-)
create mode 100644 meta-romley/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
create mode 100644 meta-romley/recipes-kernel/linux/linux-yocto_3.2.bbappend
diff --git a/meta-romley/conf/machine/romley.conf
b/meta-romley/conf/machine/romley.conf
index aa334c0..e6a755b 100644
--- a/meta-romley/conf/machine/romley.conf
+++ b/meta-romley/conf/machine/romley.conf
@@ -4,6 +4,9 @@
#@DESCRIPTION: Machine configuration for Romley systems
# i.e. Sandy Bridge + Patsburg Chipset
+
+PREFERRED_VERSION_linux-yocto ?= "3.2%"
+
require conf/machine/include/tune-x86_64.inc
require conf/machine/include/ia32-base.inc
diff --git a/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
b/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
new file mode 100644
index 000..7a61749
--- /dev/null
+++ b/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
@@ -0,0 +1,8 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+COMPATIBLE_MACHINE_romley = "romley"
+KMACHINE_romley = "romley"
+
+# Update the following to use a different BSP branch or meta SRCREV
+#KBRANCH_romley = "standard/preempt-rt/base"
+#SRCREV_machine_pn-linux-yocto-rt_romley ?=
+#SRCREV_meta_pn-linux-yocto-rt_romley ?=
diff --git a/meta-romley/recipes-kernel/linux/linux-yocto_3.2.bbappend
b/meta-romley/recipes-kernel/linux/linux-yocto_3.2.bbappend
new file mode 100644
index 000..803e772
--- /dev/null
+++ b/meta-romley/recipes-kernel/linux/linux-yocto_3.2.bbappend
@@ -0,0 +1,9 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+COMPATIBLE_MACHINE_romley = "romley"
+
+KMACHINE_romley = "romley"
+KBRANCH_romley = "standard/default/common-pc-64/romley"
+
+SRCREV_machine_pn-linux-yocto_romley ?=
"5c7f1c53b5b367858ae6a86c1d4de36d8c71bedb"
+SRCREV_meta_pn-linux-yocto_romley ?= "59f350ec3794e19fa806c1b73749d851f8ebf364"
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Edison BSP SRCREV
I've been following the "BSP Development Example" section of the "Yocto Project Development Manual" for a new BSP called "mybsp". This results in the following in linux-yocto_3.0.bbappend: COMPATIBLE_MACHINE_mybsp = "mybsp" KMACHINE_mybsp = "yocto/standard/common-pc/base" KERNEL_FEATURES_append_mybsp += " cfg/smp.scc" SRCREV_machine_pn-linux-yocto_mybsp ?= "f153b0eb8264dc1e69f59d4c9173619feb4d5bd9" SRCREV_meta_pn-linux-yocto_mybsp ?= "a4ac64fe873f08ef718e2849b88914725dc99c1c" as I'm trying to base the BSP on common-pc/base. However, when I build I get an error telling me that the machine SRCREV is not valid: Log data follows: | ERROR f153b0eb8264dc1e69f59d4c9173619feb4d5bd9 is not a valid commit ID. | The kernel source tree may be out of sync | ERROR: Function 'do_validate_branches' failed (see ... The value is the commit tag I get at http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/commit/?h=yocto/standard/common-pc/base I'm guessing I've got the wrong commit ID here ;-) What should I be using? Do I need the commit ID for the 3.0.18 tagged commit at http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/tag/?h=yocto/standard/common-pc/base&id=v3.0.18 or something else ? I'm using the tarball method described in the example, not local git. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] who are using archlinux?
On Mon, 2012-04-02 at 02:10 +0800, Giannis Damigos wrote: > On 03/30/2012 10:34 AM, Ni Qingliang wrote: > > On Fri, 2012-03-30 at 15:23 +0800, Giannis Damigos wrote: > > > On Fri, Mar 30, 2012 at 9:30 AM, Ni Qingliang > > > wrote: > > > > maybe we should report the two bugs? > > > > > > > > On Thu, 2012-03-29 at 17:12 +0800, 倪庆亮 wrote: > > > > > yes, you are right. > > > > > > > > > > the 32 bit lib and gconf is TWO problem, but maybe the reason is same, > > > > > the 'ld' search path. > > > > > > > > > > the 32 bit lib is only occured on NOT pure 64 bit arch. if you are > > > > > using > > > > > 64 bit arch, and with this problem, maybe you have installed some 32 > > > > > bit > > > > > libs. (my VM is a pure 64 bit arch, no this problem, and my host is > > > > > using multilib, with this problem) > > > > > > > > > > but the gconf problem is occured both on pure/NOT-pure 64 bit arch. > > > > > > > > > > > > > > > the former is focused on the arch (is 64 bit or 32 bit) of libs. and > > > > > the > > > > > other one is focused on the dependency of libs. > > > > > > > > > > the gconf need libgtk/libgdk (found in the sysroot), and libgtk/libgdk > > > > > depends on libXrandr (found in host's rootfs), and libXrandr need > > > > > glibc > > > > > 2.14 (not found in the sysroot, only glibc 2.13). > > > > > > > > > > so the search path is switch between the sysroot and host's rootfs > > > > > back > > > > > and forth. > > > > > > > > > > On Thu, 2012-03-29 at 16:54 +0800, Giannis Damigos wrote: > > > > > > Installing package lib32-libxrandr, cleaning gconf and building it > > > > > > again does not solved the problem. > > > > > > Such problems on OE were solved by fixing the library path. > > > > > > Now gconf is looking for libXrandr in archlinux libraries and not in > > > > > > yocto's libraries in build directory. > > > > > > > > > > > > > > > > > > On Thu, Mar 29, 2012 at 10:48 AM, Ni Qingliang > > > > > > wrote: > > > > > > > give you my hands. I have waited you so long time.:) > > > > > > > > > > > > > > indeed, I have the gcc-multilib problem also. > > > > > > > the ati driver catalyst-total need some 32 bit libs, once you > > > > > > > installed > > > > > > > that, the poky compile fail, and then we need install other 32 > > > > > > > bit libs > > > > > > > (like gcc-multilib you said). (with a pure 64 bit archlinux, all > > > > > > > are OK) > > > > > > > > > > > > > > the only reason I doubt the 'ld', only because if I remove > > > > > > > libXrandr.so.2 in host's rootfs, the error info changed, the > > > > > > > libXrandr > > > > > > > become another lib's name (maybe libXext, I can't remember > > > > > > > clearly). > > > > > > > > > > > > > > and after several days experiments, I can ensure the problem is > > > > > > > focused > > > > > > > on the 'ld' (belongs to binutils). > > > > > > > > > > > > > > On Thu, 2012-03-29 at 15:40 +0800, Giannis Damigos wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I had similar errors building an OE image for my Micro2440 > > > > > > > > board under > > > > > > > > archlinux x86-64. I solved the problem by installing gcc-multlib > > > > > > > > (https://wiki.archlinux.org/index.php/Arch64_FAQ#Multilib_Repository_-_Multilib_Project). > > > > > > > > > > > > > > > > But, I tried to bake gconf with yocto just adding MACHINE and > > > > > > > > DISTRO > > > > > > > > to my local.conf: > > > > > > > > MACHINE ?= "qemux86-64" > > > > > > > > DISTRO ?= "poky-lsb" > > > > > > > > > > > > > > > > and I had the same error. > > > > > > > > > > > > > > > > On Thu, Mar 29, 2012 at 5:05 AM, Ni Qingliang > > > > > > > > wrote: > > > > > > > > > Oh, I lost something, before running the testgconf.sh, you > > > > > > > > > should > > > > > > > > > cleanall gconf, and build gconf. If not, you can't run it. > > > > > > > > > > > > > > > > > > On Thu, 2012-03-29 at 09:52 +0800, 倪庆亮 wrote: > > > > > > > > > > what the custom script has done is only adding the build > > > > > > > > > > dir (which > > > > > > > > > > include the 'python' symlink) into the 'PATH', only that. > > > > > > > > > > AND: integrate the oe-init-build-env and bitbake together. > > > > > > > > > > indeed, no modification. > > > > > > > > > > > > > > > > > > > > using it, I can build anything with one command (call the > > > > > > > > > > script), > > > > > > > > > > without it, I must call init env script manually. > > > > > > > > > > > > > > > > > > > > archlinux: latest > > > > > > > > > > poky: latest > > > > > > > > > > build: clean (> 4times) > > > > > > > > > > > > > > > > > > > > indeed, the possibility you mentioned has been excluded by > > > > > > > > > > my test. > > > > > > > > > > you can build it succcessfully. what arch of arch you are > > > > > > > > > > using? x86 or > > > > > > > > > > x86-64? what about the local.conf? are you using the same > > > > > > > > > > as mine?. > > > > > > > > > > > > > > > > > > > > both of them from my side is x
Re: [yocto] Edison BSP SRCREV
On 12-04-04 6:36 PM, Chris Tapp wrote: I've been following the "BSP Development Example" section of the "Yocto Project Development Manual" for a new BSP called "mybsp". This results in the following in linux-yocto_3.0.bbappend: COMPATIBLE_MACHINE_mybsp = "mybsp" KMACHINE_mybsp = "yocto/standard/common-pc/base" KERNEL_FEATURES_append_mybsp += " cfg/smp.scc" SRCREV_machine_pn-linux-yocto_mybsp ?= "f153b0eb8264dc1e69f59d4c9173619feb4d5bd9" SRCREV_meta_pn-linux-yocto_mybsp ?= "a4ac64fe873f08ef718e2849b88914725dc99c1c" as I'm trying to base the BSP on common-pc/base. However, when I build I get an error telling me that the machine SRCREV is not valid: Log data follows: | ERROR f153b0eb8264dc1e69f59d4c9173619feb4d5bd9 is not a valid commit ID. | The kernel source tree may be out of sync | ERROR: Function 'do_validate_branches' failed (see ... The value is the commit tag I get at http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/commit/?h=yocto/standard/common-pc/base I'm guessing I've got the wrong commit ID here ;-) What should I be using? Do I need the commit ID for the 3.0.18 tagged commit at http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/tag/?h=yocto/standard/common-pc/base&id=v3.0.18 or something else ? I'm using the tarball method described in the example, not local git. It's like that in edison we switched to a kernel repo that only takes -stable updates (not unlike the upstream -stable). So look for the commit IDs here: git://git.yoctoproject.org/linux-yocto-3.0-1.1.x.git Sounds like a doc might need a tweak. Cheers, Bruce Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] The problem of using the external toolchain
Hi all,
Did anyone help me to resolve this problem , it block me a long time
,Thank you very much
I have a toolchain that is big endian ARM, so I want to use the
toolchain with the binary, not the source code , can we have some method to
finish this work in yocto ? I still have no clue about this .
I have done the below steps:
1.modify MACHINE=qemux86 to MACHINE=qemuarm
2.modify the file " external-csl-toolchain_2008q3-72.bb" add a
line " SRC_URI = "file://gcc-4.4.1.tar.bz2"", the gcc-4.4.1.tar.bz2 is the
source code of the arm big endian toolchain
3.then I face the some problem like this website
"https://lists.yoctoproject.org/pipermail/poky/2011-February/003809.html";
,then I add a line " LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"" ,in
file
external-csl-toolchain_2008q3-72.bb to fix this problem
4.now I got the below log :
NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for virtual/arm-none-linux-gnueabi-g++
(external-csl-toolchain, gcc-cross)
NOTE: consider defining a PREFERRED_PROVIDER entry to match
virtual/arm-none-linux-gnueabi-g++
NOTE: multiple providers are available for runtime linux-libc-headers-dev
(linux-libc-headers, linux-libc-headers-yocto,
linux-libc-headers-yocto-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match
linux-libc-headers-dev
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 206 of 1360 (ID: 455,
/home/kyle/poky-edison-6.0/meta/recipes-core/meta/external-csl-toolchain_2008q3-72.bb,
do_install)
NOTE: package external-csl-toolchain-2008q3-72-r1: task do_install: Started
ERROR: Function 'do_install' failed (see
/home/kyle/ccc/tmp/work/armv5te-none-linux-gnueabi/external-csl-toolchain-2008q3-72-r1/temp/log.do_install.9579
for further information)
ERROR: Logfile of failure stored in:
/home/kyle/ccc/tmp/work/armv5te-none-linux-gnueabi/external-csl-toolchain-2008q3-72-r1/temp/log.do_install.9579
Log data follows:
| NOTE: make -e MAKEFLAGS=
| install_root=/home/kyle/ccc/tmp/work/armv5te-none-linux-gnueabi/extern
| al-csl-toolchain-2008q3-72-r1/image install
| make: *** No rule to make target `install'. Stop.
| ERROR: oe_runmake failed
| ERROR: Function 'do_install' failed (see
| /home/kyle/ccc/tmp/work/armv5te-none-linux-gnueabi/external-csl-toolch
| ain-2008q3-72-r1/temp/log.do_install.9579 for further information)
NOTE: package external-csl-toolchain-2008q3-72-r1: task do_install: Failed
ERROR: Task 455
(/home/kyle/poky-edison-6.0/meta/recipes-core/meta/external-csl-toolchain_2008q3-72.bb,
do_install) failed with exit code '1'
ERROR:
'/home/kyle/poky-edison-6.0/meta/recipes-core/meta/external-csl-toolchain_2008q3-72.bb'
failed kyle@ubuntu:~/ccc$
After I comment the line "#inherit libc-common" and "#inherit libc-package"
the error become the below :
Log data follows:
| DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64',
'x86_64-linux', 'common']
| NOTE: Running
/home/ccc/poky/edison-6.0-build/tmp/work-shared/gcc-4.6.2+svnr175454-r17/gcc-4_6-branch/configure
--build=x86_64-linux --host=x86_64-linux
--target=arm-none-linux-gnueabi
--prefix=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/usr
--exec_prefix=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/usr
--bindir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/usr/bin/armv5te-none-linux-gnueabi.gcc-cross-initial
--sbindir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/usr/bin/armv5te-none-linux-gnueabi.gcc-cross-initial
--libexecdir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/usr/libexec/armv5te-none-linux-gnueabi.gcc-cross-initial
--datadir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/usr/share
--sysconfdir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/etc
--sharedstatedir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/com
--localstatedir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/var
--libdir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/usr/lib/armv5te-none-linux-gnueabi.gcc-cross-initial
--includedir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/usr/include
--oldincludedir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/usr/include
--infodir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/usr/share/info
--mandir=/home/ccc/poky/edison-6.0-build/tmp/sysroots/x86_64-linux/usr/share/man
--disable-silent-rules
--with-libtool-sysroot=/home/ccc/poky/edison-6.0-b
Re: [yocto] [poky] The problem of using the external toolchain
On Wed, Apr 4, 2012 at 8:15 PM, Wangdawei (Sivan) wrote:
> Did anyone help me to resolve this problem , it block me a long time ,Thank
> you very much
>
> I have a toolchain that is big endian ARM, so I want to use the
> toolchain with the binary, not the source code , can we have some method to
> finish this work in yocto ? I still have no clue about this .
> I have done the below steps:
> 1.modify MACHINE=qemux86 to MACHINE=qemuarm
> 2.modify the file " external-csl-toolchain_2008q3-72.bb" add a
> line " SRC_URI = "file://gcc-4.4.1.tar.bz2"", the gcc-4.4.1.tar.bz2 is the
> source code of the arm big endian toolchain
> 3.then I face the some problem like this website
> "https://lists.yoctoproject.org/pipermail/poky/2011-February/003809.html";
> ,then I add a line " LIC_FILES_CHKSUM =
> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"" ,in
> file
> external-csl-toolchain_2008q3-72.bb to fix this problem
> 4.now I got the below log :
I assume this is with the edison branch?
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [poky] The problem of using the external toolchain
Yes , edison-6.0 , is it some problem ?
-Original Message-
From: kerg...@gmail.com [mailto:kerg...@gmail.com] On Behalf Of Chris Larson
Sent: 2012年4月5日 11:24
To: Wangdawei (Sivan)
Cc: p...@yoctoproject.org; yocto@yoctoproject.org
Subject: Re: [poky] The problem of using the external toolchain
On Wed, Apr 4, 2012 at 8:15 PM, Wangdawei (Sivan) wrote:
> Did anyone help me to resolve this problem , it block me a long time ,Thank
> you very much
>
> I have a toolchain that is big endian ARM, so I want to use the
> toolchain with the binary, not the source code , can we have some method to
> finish this work in yocto ? I still have no clue about this .
> I have done the below steps:
> 1.modify MACHINE=qemux86 to MACHINE=qemuarm
> 2.modify the file " external-csl-toolchain_2008q3-72.bb" add a
> line " SRC_URI = "file://gcc-4.4.1.tar.bz2"", the gcc-4.4.1.tar.bz2 is the
> source code of the arm big endian toolchain
> 3.then I face the some problem like this website
> "https://lists.yoctoproject.org/pipermail/poky/2011-February/003809.html";
> ,then I add a line " LIC_FILES_CHKSUM =
> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"" ,in
> file
> external-csl-toolchain_2008q3-72.bb to fix this problem
> 4.now I got the below log :
I assume this is with the edison branch?
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
On 04/04/12 15:10, Gary Thomas wrote: > On 2012-04-04 06:50, Bruce Ashfield wrote: >> On 12-04-04 08:04 AM, Andrea Galbusera wrote: >>> Hi Tomas, >>> >>> On Wed, Apr 4, 2012 at 12:14 PM, Tomas Frydrych >>> wrote: Hi, I am trying to get Yocto image built from yesterday's master (Linux-3.0.23-yocto-standard) to boot on the NAND-less version of BeagleBoard xM, but the kernel panics with: - console log start Waiting for root device /dev/mmcblk0p2... mmc0: new SDHC card at address 1234 mmcblk0: mmc0:1234 SA04G 3.67 GiB (ro) mmcblk0: p1 p2 VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2) Please append a correct "root=" boot option; here are the available partitions: b300 3858432 mmcblk0 driver: mmcblk b301 120456 mmcblk0p1 ----0mmcblk0p1 b302 3445942 mmcblk0p2 ----0mmcblk0p2 VFS: Unable to mount root fs on unknown-block(179,2) User configuration error - no valid root filesystem found Kernel panic - not syncing: Invalid configuration from end user prevents continuing -- console log end My guess would be the problem is the card being detected as 'ro' (line 3), but I do not know why that is (there is no lock switch on mmc cards). The card itself is fine, it's the original card that came with the board, the original Angstrom demo boots fine from it, and yocto kernel 2.6.37 also used to boot. Tomas >>> >>> Looks related to the comment I wrote here: >>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1892 >>> I have a slightly different failure with yocto 1.2 beta snapshot (same >>> kernel) but seems related. Needs more investigation. >>> Anyone else having problem booting on beagleboard xM? Seems something >>> wrong happened after 1.1 release... >> >> We are working on several bugs on our reference beagleboard. The problem >> is that my beagleboard died (a horrible painful death) and the other >> boards >> that are directly available to are RevC and they are booting. So things >> are slowed down a bit .. but we are trying to get to the bottom of it, >> as fast as possible. > > Just FYI, it also doesn't boot on my rev-C3 (not xM), albeit with a > different > error pattern. It hangs at this point: > Waiting for root device /dev/mmcblk0p2... > mmc0: error -110 whilst initialising SD card > > Looks like you might need the attached patch? This is a different issue. I get this too with one particular MMC card, but with 2.6.37 kernel, if I unplug this card and plug it back in the boot resumes and completes successfully. If I do this with the 3.0.2 kernel, the bug I described with the associated kernel panic then kicks in. Tomas > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
