From: Charles W. <cha...@ha...> - 2009-11-17 00:23:44
|
Can someone suggest how to get bitbake to rebuild the kernel? I am struggling with the right approach to using bitbake to build a system. I recently build omap3-console-image and then removed the kernel and the rootfs. To 'reset' the system, I did a 'bitbake -c clean omap3-console-image' and a bitbake -c clean virtual/kernel' Now, when I do a bitbake -c rebuild omap3-console-image' and 'bitbake - c rebuild virtual/kernel', I get the rootfs rebuilt, but not the kernel. How should I do this? In my build/conf/local.conf, I have: DL_DIR = "${OE_TOP}/sources" TMPDIR= "${OE_TOP}/tmp" So, I think I should be able to rm -rf ${OE_TOP}/tmp to clear *everything*, but that will take a LONG time. Suggestions? Thanks, Charlie |
From: Scott E. <sco...@gm...> - 2009-11-17 01:11:28
|
bitbake -c rebuild linux-omap3-2.6.31 You can change the kernel version number if you are using another. Then you should do a bitbake omap3-console-image afterwards to make sure your kernel and rootfs particularly your /lib/modules are in synch. It won't take long. I don't know what the current default kernel is. You can change the kernel that gets build by modfying build/conf/local.conf Add something like this to force a version PREFERRED_VERSION_linux-omap3="2.6.31" On 11/16/09, Charles Woloszynski <cha...@ha...> wrote: > Can someone suggest how to get bitbake to rebuild the kernel? I am > struggling with the right approach to using bitbake to build a system. > > I recently build omap3-console-image and then removed the kernel and > the rootfs. > > To 'reset' the system, I did a 'bitbake -c clean omap3-console-image' > and a bitbake -c clean virtual/kernel' > > Now, when I do a bitbake -c rebuild omap3-console-image' and 'bitbake - > c rebuild virtual/kernel', I get the rootfs rebuilt, but not the kernel. > > How should I do this? > > In my build/conf/local.conf, I have: > > DL_DIR = "${OE_TOP}/sources" > TMPDIR= "${OE_TOP}/tmp" > > So, I think I should be able to rm -rf ${OE_TOP}/tmp to clear > *everything*, but that will take a LONG time. > > Suggestions? > > Thanks, > > Charlie > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: softwizz <ad...@is...> - 2011-03-09 00:06:39
|
Hi Scott, I've been trying to implement your cut-down 'minimal' build that boots in a few seconds, and I'm having problems getting the rootfs to build at all. Indeed I've not yet found a definitive bitbake command for rebuilding the rootfs, unlike kernel rebuilds which I find very simple. Searching Old Nabble I came on your posting here, and did exactly what you said here, i.e. :- bitbake -c rebuild linux-omap3-2.6.34 followed by bitbake omap3-console-image Unfortunately it *did* take a long time, in fact the second step re-downloaded all the packages. Please advise me - if I follow your instructions for switching to the 'minimal' branch and then after I've bitbaked virtual/kernel and work-image I find that the rootfs has not built, what command(s) can I then use to rebuild the rootfs without causing a ton of stuff to happen? Cheers, Mike ScottEllis wrote: > > bitbake -c rebuild linux-omap3-2.6.31 > > You can change the kernel version number if you are using another. > > Then you should do a > bitbake omap3-console-image > afterwards to make sure your kernel and rootfs particularly your > /lib/modules are in synch. > > It won't take long. > -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31102396.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2011-03-09 02:06:10
|
Hi Mike, This is the tar'd rootfs you should be looking for: work-image-overo.tar.bz2 The line to build it was this: bitbake -c clean virtual/kernel; bitbake virtual/kernel; bitbake work-image If it didn't build, you should have seen errors. As for the downloading of source, the [minimal] branch in my github repo is a little dated. Late January looks like. If your last build was from a more recent overo-oe pull, building from recipes in that [minimal] branch might be pulling some older sources. Or if you are coming from an older overo-oe commit, then that [minimal] branch might be pulling newer stuff. The version of source files that the recipes will be building is one of the main differences between overo-oe commits in the git repo. It's expected that you'll be downloading some new source. There is another branch in there [minimal-2.6.36] last pushed Feb 28. That one should match up to the current gumstix oe repo pretty well. But changing branches shouldn't result in re-downloading ALL the packages. That would indicate that either every recipe changed (unlikely) or that your ${HOME}/overo-oe/sources directory was empty. If you are switching between users while you are doing your testing, then change the DL_DIR in ${HOME}/overo-oe/build/conf/site.conf to some user independent location. For example mine is DL_DIR = /oe-sources If you do that change, make sure you copy the current contents of a good ${HOME}/overo-oe/sources directory into it or you will download everything at least one more time. I have different users for working on Overos and Beagleboards, but they share the same DL_DIR for OE source. Works fine. That's all I can think of without more details. There are prebuilt files for the [minimal-2.6.36] branch in that Downloads/minimal-2.6.36r87/ link. I uploaded those files the same day I pushed the [minimal-2.6.36] branch up to github so I know they are consistent and build okay. You might want to test them out before (or while) building them yourself. Scott -- Sent from my Linux box |
From: softwizz <ad...@is...> - 2011-03-10 09:28:16
|
Hi Scott, Many thanks for all that detail, but in the end I didn't need it. When I restarted from scratch (i.e. my prior build system) and applied your steps one by one, I was able to build a system in which "bitbake work-image" does indeed rebuild the RFS. Not sure what went wrong before, though I do note that the names of the RFS image files are changed from omap3-console-image to work-image. This consequence of using your build was not obvious to me, hence I may have been mixing commands for omap3-console-image with those for your new build. What I have not yet seen, is the expected benefits of your build in terms of boot-up time. When you talk about boot-up in 20 seconds, at what points are you starting and stopping the clock? Cheers, Mike jumpnowdev wrote: > > Hi Mike, > > This is the tar'd rootfs you should be looking for: > > work-image-overo.tar.bz2 > > The line to build it was this: > > bitbake -c clean virtual/kernel; bitbake virtual/kernel; bitbake > work-image > > If it didn't build, you should have seen errors. > > > As for the downloading of source, the [minimal] branch in my github > repo is a little dated. Late January looks like. > > If your last build was from a more recent overo-oe pull, building from > recipes in that [minimal] branch might be pulling some older sources. > > Or if you are coming from an older overo-oe commit, then that [minimal] > branch might be pulling newer stuff. > > The version of source files that the recipes will be building is one > of the main differences between overo-oe commits in the git repo. > It's expected that you'll be downloading some new source. > > There is another branch in there [minimal-2.6.36] last pushed Feb 28. > That one should match up to the current gumstix oe repo pretty well. > > But changing branches shouldn't result in re-downloading ALL the packages. > That would indicate that either every recipe changed (unlikely) or that > your ${HOME}/overo-oe/sources directory was empty. > > If you are switching between users while you are doing your testing, > then change the DL_DIR in ${HOME}/overo-oe/build/conf/site.conf to some > user independent location. For example mine is > > DL_DIR = /oe-sources > > If you do that change, make sure you copy the current contents of a good > ${HOME}/overo-oe/sources directory into it or you will download > everything at least one more time. > > I have different users for working on Overos and Beagleboards, but they > share the same DL_DIR for OE source. Works fine. > > That's all I can think of without more details. > > There are prebuilt files for the [minimal-2.6.36] branch in that > Downloads/minimal-2.6.36r87/ link. I uploaded those files the same > day I pushed the [minimal-2.6.36] branch up to github so I know they > are consistent and build okay. You might want to test them out before > (or while) building them yourself. > > > Scott > > -- > Sent from my Linux box > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31113205.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2011-03-10 11:19:54
|
I'll add something to the instructions. I assumed users would know that root fs images are named after the recipe, but you know how that goes ;-) In my defense, noone ever asked before. I'm measuring boot time from power on to shell prompt in the console. I get times between 10 and 12 seconds, depends some on the type of microSD card. I found a class 6 microSD card can get you another second or two. Others have confirmed similar times. About half that time is in u-boot loading the kernel from the card. Word is that might be improving soon. Of course, don't forget to remove the u-boot delay. That's just wasted time. Getting rid of udev in the Linux startup scripts helps a lot too. Depends on your app whether that is acceptable. I always remove them. The first boot will still be slower because of one time stuff like ssh keys. Scott -- Sent from my Linux box |
From: softwizz <ad...@is...> - 2011-03-10 18:04:40
|
Hi Scott, jumpnowdev wrote: > > I'll add something to the instructions. I assumed users would know that > root fs images are named after the recipe, but you know how that > goes ;-) In my defense, noone ever asked before. > I certainly didn't realize there was a rule saying the RFS image is named after the recipe. Is there a bitbake tutorial from where I would get that and other 'well-known' facts? On another tack, I've been told that our project really needs to run on 2.6.34 r97. Do you have a minimal build based on that release, by any chance? Cheers, Mike -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31118203.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sco...@gm...> - 2011-03-11 01:01:21
|
Not handy. I can build one for you though. I'll get back to you off list when it's done. On 3/10/11, softwizz <ad...@is...> wrote: > > Hi Scott, > > > jumpnowdev wrote: >> >> I'll add something to the instructions. I assumed users would know that >> root fs images are named after the recipe, but you know how that >> goes ;-) In my defense, noone ever asked before. >> > > I certainly didn't realize there was a rule saying the RFS image is named > after the recipe. Is there a bitbake tutorial from where I would get that > and other 'well-known' facts? > > On another tack, I've been told that our project really needs to run on > 2.6.34 r97. Do you have a minimal build based on that release, by any > chance? > > Cheers, > > Mike > > > > > -- > View this message in context: > http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31118203.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Scott E. <sc...@ju...> - 2011-03-11 13:21:30
|
Here you go http://www.jumpnowtek.com/Downloads/minimal-2.6.34r97/ and the overo-oe branch that it was all built with is here https://github.com/scottellis/overo-oe/tree/minimal-2.6.34 On Thu, 2011-03-10 at 10:04 -0800, softwizz wrote: > Hi Scott, > > > jumpnowdev wrote: > > > > I'll add something to the instructions. I assumed users would know that > > root fs images are named after the recipe, but you know how that > > goes ;-) In my defense, noone ever asked before. > > > > I certainly didn't realize there was a rule saying the RFS image is named > after the recipe. Is there a bitbake tutorial from where I would get that > and other 'well-known' facts? > > On another tack, I've been told that our project really needs to run on > 2.6.34 r97. Do you have a minimal build based on that release, by any > chance? > > Cheers, > > Mike > > > > -- Sent from my Linux box |
From: softwizz <ad...@is...> - 2011-03-17 13:56:16
|
Ta for that, but I will definitely need to build my own. How do I check it out? I tried modifying Scott's original command :- git checkout -b minimal-2.6.34r97 se-overo-oe/minimal doesn't work, it fetches r91 again git checkout -b minimal se-overo-oe/minimal-2.6.34r97 doesn't work, not a git repository I'm sure there is a "well-known" syntax for getting the r97 tree that you built from, but it isn't known to me, and I'm still looking for that elusive full-on howto on openembedded. Interestingly, the Gumstix howto and 'software resource' links don't go into anything like enough detail on this sort of thing. Cheers, Mike jumpnowdev wrote: > > Here you go > > http://www.jumpnowtek.com/Downloads/minimal-2.6.34r97/ > > and the overo-oe branch that it was all built with is here > > https://github.com/scottellis/overo-oe/tree/minimal-2.6.34 > > > On Thu, 2011-03-10 at 10:04 -0800, softwizz wrote: >> Hi Scott, >> >> >> jumpnowdev wrote: >> > >> > I'll add something to the instructions. I assumed users would know that >> > root fs images are named after the recipe, but you know how that >> > goes ;-) In my defense, noone ever asked before. >> > >> >> I certainly didn't realize there was a rule saying the RFS image is named >> after the recipe. Is there a bitbake tutorial from where I would get that >> and other 'well-known' facts? >> >> On another tack, I've been told that our project really needs to run on >> 2.6.34 r97. Do you have a minimal build based on that release, by any >> chance? >> >> Cheers, >> >> Mike >> >> >> >> > > -- > Sent from my Linux box > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31172379.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Marshall C. <ma...@gm...> - 2011-03-17 19:00:15
|
On Thu, Mar 17, 2011 at 8:56 AM, softwizz <ad...@is...> wrote: > I'm sure there is a "well-known" syntax for getting the r97 tree that you > built from, but it isn't known to me, and I'm still looking for that elusive > full-on howto on openembedded. Interestingly, the Gumstix howto and > 'software resource' links don't go into anything like enough detail on this > sort of thing. Maybe not what you're looking for but here's the most extensive documentation for OpenEmbedded I've found: http://docs.openembedded.org/usermanual/usermanual.html Marshall |
From: Scott E. <sc...@ju...> - 2011-03-17 15:24:53
|
I added a [minimal-2.6.34] branch to my github overo-oe repository after I built those 2.6.34r97 images. You'll have to pull from my github repo again and then checkout the se-overo-oe/minimal-2.6.34 branch. Something like this if you were following those initial instructions on my site. $ cd $OVEROTOP/org.openembedded.dev $ git remote -v update You should see output something like this with 'github' replaced by 'se-overo-oe' as the remote name in your case. scott@quad:~/overo-oe/org.openembedded.dev$ git remote -v update Fetching origin >From git://gitorious.org/gumstix-oe/mainline = [up to date] org.openembedded.dev -> origin/org.openembedded.dev = [up to date] overo -> origin/overo = [up to date] verdex -> origin/verdex Fetching github >From github.com:scottellis/overo-oe = [up to date] 2.6.32-psp -> github/2.6.32-psp = [up to date] ads127x -> github/ads127x = [up to date] minimal -> github/minimal = [up to date] minimal-2.6.34 -> github/minimal-2.6.34 = [up to date] minimal-2.6.36 -> github/minimal-2.6.36 = [up to date] mt9p001-2.6.34 -> github/mt9p001-2.6.34 = [up to date] overo -> github/overo = [up to date] submersible -> github/submersible Then you should be able to checkout the [se-overo-oe/minimal-2.6.34] branch. $ git checkout -b minimal-2.6.34 se-overo-oe/minimal-2.6.34 There are no doubt other ways to go about this. This is general git stuff though, nothing special about OE or gumstix. And about OE, Linux on OMAP3 and gumstix documentation in general, I agree, hence the attempts on my site. It started and still is primarily notes for my own use ;-) Scott -- Sent from my Linux box |
From: softwizz <ad...@is...> - 2011-03-17 22:32:42
|
I'm sorry, it just won;t work. There seems to be a script error somewhere. The following log is of a complete restart of the process, copying the unmodified tree across from an archive, pulling down what should be your r97 build, and attempting to build it. This was doine after I got exactly the same results when I followed your advised route on my previous 'minimum' tree. Any ideas? Mike >>>>>>>>>>>>> log starts <<<<<<<<<<<<<<>--> cp -r ~/overo-oeSTD/bitbake . localhost.localdomain (mike) /home/mike/overo-oe>>--> cp -r ~/overo-oeSTD/build . localhost.localdomain (mike) /home/mike/overo-oe>>--> cp -r ~/overo-oeSTD/org.openembedded.dev . localhost.localdomain (mike) /home/mike/overo-oe>>--> cp -r ~/overo-oeSTD/sources . localhost.localdomain (mike) /home/mike/overo-oe>>--> cp -r ~/overo-oeSTD/tmp . localhost.localdomain (mike) /home/mike/overo-oe>>--> cd org.openembedded.dev localhost.localdomain (mike) /home/mike/overo-oe/org.openembedded.dev>>--> git remote add -f se-overo-oe git://github.com/scottellis/overo-oe.git Updating se-overo-oe remote: Counting objects: 25060, done. remote: Compressing objects: 100% (6268/6268), done. remote: Total 21051 (delta 15072), reused 20116 (delta 14216) Receiving objects: 100% (21051/21051), 8.92 MiB | 73 KiB/s, done. Resolving deltas: 100% (15072/15072), completed with 2436 local objects. >From git://github.com/scottellis/overo-oe * [new branch] 2.6.32-psp -> se-overo-oe/2.6.32-psp * [new branch] ads127x -> se-overo-oe/ads127x * [new branch] minimal -> se-overo-oe/minimal * [new branch] minimal-2.6.34 -> se-overo-oe/minimal-2.6.34 * [new branch] minimal-2.6.36 -> se-overo-oe/minimal-2.6.36 * [new branch] mt9p001-2.6.34 -> se-overo-oe/mt9p001-2.6.34 * [new branch] overo -> se-overo-oe/overo * [new branch] submersible -> se-overo-oe/submersible localhost.localdomain (mike) /home/mike/overo-oe/org.openembedded.dev>>--> git checkout -b minimal-2.6.34 se-overo-oe/minimal-2.6.34 Checking out files: 100% (7846/7846), done. M conf/machine/overo.conf Branch minimal-2.6.34 set up to track remote branch refs/remotes/se-overo-oe/minimal-2.6.34. Switched to a new branch "minimal-2.6.34" localhost.localdomain (mike) /home/mike/overo-oe/org.openembedded.dev>>--> git branch -a * minimal-2.6.34 org.openembedded.dev overo origin/HEAD origin/org.openembedded.dev origin/overo origin/verdex se-overo-oe/2.6.32-psp se-overo-oe/ads127x se-overo-oe/minimal se-overo-oe/minimal-2.6.34 se-overo-oe/minimal-2.6.36 se-overo-oe/mt9p001-2.6.34 se-overo-oe/overo se-overo-oe/submersible localhost.localdomain (mike) /home/mike/overo-oe/org.openembedded.dev>>--> cd .. localhost.localdomain (mike) /home/mike/overo-oe>>--> bitbake -c clean virtual/kernel NOTE: Psyco JIT Compiler (http://psyco.sf.net) not available. Install it to increase performance. NOTE: Out of date cache found, rebuilding... NOTE: Handling BitBake files: \ (0547/7292) [ 7 %]NOTE: Angstrom DOES NOT support fso-apm because regular apmd is good enough NOTE: Handling BitBake files: \ (2087/7292) [28 %]NOTE: Angstrom DOES NOT support libiconv because the glibc builtin iconv replacement is used NOTE: Angstrom DOES NOT support libiconv because the glibc builtin iconv replacement is used NOTE: Angstrom DOES NOT support libiconv because the glibc builtin iconv replacement is used NOTE: Handling BitBake files: / (3182/7292) [43 %]NOTE: Angstrom DOES NOT support ipkg because ipkg has been superseded by opkg NOTE: Handling BitBake files: | (4858/7292) [66 %]NOTE: Angstrom DOES NOT support bluez-utils because bluez-utils 3.x has been replaced by bluez4 NOTE: Angstrom DOES NOT support bluez-libs because bluez-libs 3.x has been replaced by bluez4 NOTE: Handling BitBake files: \ (4864/7292) [66 %]NOTE: Angstrom DOES NOT support bluez-libs because bluez-libs 3.x has been replaced by bluez4 NOTE: Handling BitBake files: \ (4869/7292) [66 %]NOTE: Angstrom DOES NOT support bluez-utils because bluez-utils 3.x has been replaced by bluez4 NOTE: Handling BitBake files: \ (4881/7292) [66 %]NOTE: Angstrom DOES NOT support bluez-libs because bluez-libs 3.x has been replaced by bluez4 NOTE: Handling BitBake files: | (7292/7292) [100 %] NOTE: Parsing finished. 0 cached, 6981 parsed, 311 skipped, 2 masked. NOTE: build Angstrom ${DISTRO_VERSION}: started Traceback (most recent call last): File "/home/mike/overo-oeR97/bitbake/bin/bitbake", line 143, in <module> main() File "/home/mike/overo-oeR97/bitbake/bin/bitbake", line 140, in main cooker.cook() File "/home/mike/overo-oeR97/bitbake/lib/bb/cooker.py", line 640, in cook return self.buildTargets(pkgs_to_build) File "/home/mike/overo-oeR97/bitbake/lib/bb/cooker.py", line 527, in buildTargets bb.event.fire(bb.event.BuildStarted(buildname, targets, self.configuration.event_data)) File "/home/mike/overo-oeR97/bitbake/lib/bb/event.py", line 67, in fire if tmpHandler(event) == Handled: File "tmpHandler(e)", line 10, in tmpHandler File "/home/mike/overo-oeR97/bitbake/lib/bb/__init__.py", line 100, in plain bb.msg.warn(''.join(args)) TypeError: warn() takes at least 2 arguments (1 given) localhost.localdomain (mike) /home/mike/overo-oe>>--> i>>>>>>>>>> log ends <<<<<<<<<<<<< -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31177031.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: ScottEllis <sco...@gm...> - 2011-03-18 00:36:10
|
Looking at the error, I think you are using an older version of bitbake. I think this will fix it. $ cd $OVEROTOP/bitbake $ git pull $ git checkout 1.10.2 It's from instructions here. http://www.gumstix.org/software-development/open-embedded/61-using-the-open-embedded-build-system.html softwizz wrote: > > Traceback (most recent call last): > File "/home/mike/overo-oeR97/bitbake/bin/bitbake", line 143, in <module> > main() > File "/home/mike/overo-oeR97/bitbake/bin/bitbake", line 140, in main > cooker.cook() > File "/home/mike/overo-oeR97/bitbake/lib/bb/cooker.py", line 640, in > cook > return self.buildTargets(pkgs_to_build) > File "/home/mike/overo-oeR97/bitbake/lib/bb/cooker.py", line 527, in > buildTargets > bb.event.fire(bb.event.BuildStarted(buildname, targets, > self.configuration.event_data)) > File "/home/mike/overo-oeR97/bitbake/lib/bb/event.py", line 67, in fire > if tmpHandler(event) == Handled: > File "tmpHandler(e)", line 10, in tmpHandler > File "/home/mike/overo-oeR97/bitbake/lib/bb/__init__.py", line 100, in > plain > bb.msg.warn(''.join(args)) > TypeError: warn() takes at least 2 arguments (1 given) > localhost.localdomain (mike) /home/mike/overo-oe>>--> > -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31177712.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: softwizz <ad...@is...> - 2011-03-18 01:31:23
|
The 'git pull' comes up with an error :- You asked me to pull without telling me which branch you want to merge with, and 'branch..merge' in your configuration file does not tell me either. Please name which branch you want to merge on the command line and try again (e.g. 'git pull <repository> <refspec>'). See git-pull (1) for details on the refspec. I'm sure this means something to you, but it means nothing to me. There is no reference to 'branch..merge' in bitbake/conf/bitbake.conf Sorry to be a pain, but what should I do? Cheers, Mike ScottEllis wrote: > > Looking at the error, I think you are using an older version of bitbake. > > I think this will fix it. > > $ cd $OVEROTOP/bitbake > $ git pull > $ git checkout 1.10.2 > > It's from instructions here. > > http://www.gumstix.org/software-development/open-embedded/61-using-the-open-embedded-build-system.html > > > softwizz wrote: >> >> Traceback (most recent call last): >> File "/home/mike/overo-oeR97/bitbake/bin/bitbake", line 143, in >> <module> >> main() >> File "/home/mike/overo-oeR97/bitbake/bin/bitbake", line 140, in main >> cooker.cook() >> File "/home/mike/overo-oeR97/bitbake/lib/bb/cooker.py", line 640, in >> cook >> return self.buildTargets(pkgs_to_build) >> File "/home/mike/overo-oeR97/bitbake/lib/bb/cooker.py", line 527, in >> buildTargets >> bb.event.fire(bb.event.BuildStarted(buildname, targets, >> self.configuration.event_data)) >> File "/home/mike/overo-oeR97/bitbake/lib/bb/event.py", line 67, in fire >> if tmpHandler(event) == Handled: >> File "tmpHandler(e)", line 10, in tmpHandler >> File "/home/mike/overo-oeR97/bitbake/lib/bb/__init__.py", line 100, in >> plain >> bb.msg.warn(''.join(args)) >> TypeError: warn() takes at least 2 arguments (1 given) >> localhost.localdomain (mike) /home/mike/overo-oe>>--> >> > > -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31177931.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2011-03-18 08:56:02
|
This is probably the easiest. $ cd ~/overo-oe $ rm -rf bitbake $ git clone git://git.openembedded.net/bitbake bitbake $ cd bitbake $ git checkout 1.10.2 On Thu, 2011-03-17 at 18:31 -0700, softwizz wrote: > The 'git pull' comes up with an error :- > > You asked me to pull without telling me which branch you > want to merge with, and 'branch..merge' in > your configuration file does not tell me either. Please > name which branch you want to merge on the command line and > try again (e.g. 'git pull <repository> <refspec>'). > See git-pull (1) for details on the refspec. > > I'm sure this means something to you, but it means nothing to me. > There is no reference to 'branch..merge' in bitbake/conf/bitbake.conf > > Sorry to be a pain, but what should I do? > > Cheers, > > Mike > > > > ScottEllis wrote: > > > > Looking at the error, I think you are using an older version of bitbake. > > > > I think this will fix it. > > > > $ cd $OVEROTOP/bitbake > > $ git pull > > $ git checkout 1.10.2 > > > > It's from instructions here. > > > > http://www.gumstix.org/software-development/open-embedded/61-using-the-open-embedded-build-system.html > > > > > > softwizz wrote: > >> > >> Traceback (most recent call last): > >> File "/home/mike/overo-oeR97/bitbake/bin/bitbake", line 143, in > >> <module> > >> main() > >> File "/home/mike/overo-oeR97/bitbake/bin/bitbake", line 140, in main > >> cooker.cook() > >> File "/home/mike/overo-oeR97/bitbake/lib/bb/cooker.py", line 640, in > >> cook > >> return self.buildTargets(pkgs_to_build) > >> File "/home/mike/overo-oeR97/bitbake/lib/bb/cooker.py", line 527, in > >> buildTargets > >> bb.event.fire(bb.event.BuildStarted(buildname, targets, > >> self.configuration.event_data)) > >> File "/home/mike/overo-oeR97/bitbake/lib/bb/event.py", line 67, in fire > >> if tmpHandler(event) == Handled: > >> File "tmpHandler(e)", line 10, in tmpHandler > >> File "/home/mike/overo-oeR97/bitbake/lib/bb/__init__.py", line 100, in > >> plain > >> bb.msg.warn(''.join(args)) > >> TypeError: warn() takes at least 2 arguments (1 given) > >> localhost.localdomain (mike) /home/mike/overo-oe>>--> > >> > > > > > -- Sent from my Linux box |
From: softwizz <ad...@is...> - 2011-03-18 16:32:58
|
Hi Scott, many thanks for the continuing assistance. I'm getting closer, but it still isn't getting to the end of the build. The latest problem is that linux-omap3_2.6.34.bb fails because a file it's calling for (spidev-enable.patch) is not present. I've established that this dependency post-dates your earlier r91 minimal build. Is there somewhere I can download this patchfile from, and will I likely hit any other missing dependencies? Cheers, Mike jumpnowdev wrote: > > This is probably the easiest. > > $ cd ~/overo-oe > $ rm -rf bitbake > $ git clone git://git.openembedded.net/bitbake bitbake > $ cd bitbake > $ git checkout 1.10.2 > > > On Thu, 2011-03-17 at 18:31 -0700, softwizz wrote: >> The 'git pull' comes up with an error :- >> >> You asked me to pull without telling me which branch you >> want to merge with, and 'branch..merge' in >> your configuration file does not tell me either. Please >> name which branch you want to merge on the command line and >> try again (e.g. 'git pull <repository> <refspec>'). >> See git-pull (1) for details on the refspec. >> >> I'm sure this means something to you, but it means nothing to me. >> There is no reference to 'branch..merge' in bitbake/conf/bitbake.conf >> >> Sorry to be a pain, but what should I do? >> >> Cheers, >> >> Mike >> >> >> >> ScottEllis wrote: >> > >> > Looking at the error, I think you are using an older version of >> bitbake. >> > >> > I think this will fix it. >> > >> > $ cd $OVEROTOP/bitbake >> > $ git pull >> > $ git checkout 1.10.2 >> > >> > It's from instructions here. >> > >> > >> http://www.gumstix.org/software-development/open-embedded/61-using-the-open-embedded-build-system.html >> > >> > >> > softwizz wrote: >> >> >> >> Traceback (most recent call last): >> >> File "/home/mike/overo-oeR97/bitbake/bin/bitbake", line 143, in >> >> <module> >> >> main() >> >> File "/home/mike/overo-oeR97/bitbake/bin/bitbake", line 140, in main >> >> cooker.cook() >> >> File "/home/mike/overo-oeR97/bitbake/lib/bb/cooker.py", line 640, in >> >> cook >> >> return self.buildTargets(pkgs_to_build) >> >> File "/home/mike/overo-oeR97/bitbake/lib/bb/cooker.py", line 527, in >> >> buildTargets >> >> bb.event.fire(bb.event.BuildStarted(buildname, targets, >> >> self.configuration.event_data)) >> >> File "/home/mike/overo-oeR97/bitbake/lib/bb/event.py", line 67, in >> fire >> >> if tmpHandler(event) == Handled: >> >> File "tmpHandler(e)", line 10, in tmpHandler >> >> File "/home/mike/overo-oeR97/bitbake/lib/bb/__init__.py", line 100, >> in >> >> plain >> >> bb.msg.warn(''.join(args)) >> >> TypeError: warn() takes at least 2 arguments (1 given) >> >> localhost.localdomain (mike) /home/mike/overo-oe>>--> >> >> >> > >> > >> > > -- > Sent from my Linux box > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31182824.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: ScottEllis <sco...@gm...> - 2011-03-18 17:33:41
|
I commited the patch. Do a git pull and you should be fine. That patch was sitting on my machine from another branch, that's why my build didn't catch it. $ cd ~/overo-oe/org.openembedded.dev $ git pull $ cd ~/overo-oe $ bitbake -c clean virtual/kernel $ bitbake virtual/kernel $ bitbake work-image I can't say for sure that you won't get another problem. I only created that branch for you. I am not using it. -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31183361.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: softwizz <ad...@is...> - 2011-03-21 15:41:08
|
Hi Scott, many thanks again. That clears up the build problems, but leaves me with one wrinkle that I didn't expect - "mount -t ubifs" on the target now fails "mount: unknown filesystem type 'ubifs'", and when I put the ubifs RFS in NAND the subsequent boot of course hits "VFS: cannot open root device 'ubi0' or unknown block (0,0)" and then panics. /bin/mount is symlinked to /bin/mount.util-linux-ng but that is the same in my previous r90 build, which supported mounting ubifs. The file /bin/mount.util-linux-ng in the 'r97 minimal' build is 4 bytes larger than the one in the r90 build. I don't have any other clues at this time. ubifs is enabled in image.bbclass of course, but I assume from these results that you have removed ubifs support from the RFS. Where do I go in your build to re-enable it? Cheers, Mike ScottEllis wrote: > > I commited the patch. Do a git pull and you should be fine. > > That patch was sitting on my machine from another branch, that's why > my build didn't catch it. > > $ cd ~/overo-oe/org.openembedded.dev > $ git pull > $ cd ~/overo-oe > $ bitbake -c clean virtual/kernel > $ bitbake virtual/kernel > $ bitbake work-image > > I can't say for sure that you won't get another problem. I only created > that > branch for you. I am not using it. > > -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31201891.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2011-03-21 16:31:22
|
Hi Mike, You want to change this file. $OVEROTOP/org.openembedded.dev/recipes/linux/linux-omap3-2.6.34/overo/defconfig As usual, TIMTOWTDI. Here are two. 1. You could use git to pull out the UBIFS changes to the defconfig in the [minimal-2.6.34] branch and then hand edit the file yourself. This assumes your tree has an [overo] branch to compare against. $ cd $OVEROTOP/org.openembedded.dev/recipes/linux/linux-omap3-2.6.34/overo $ git diff overo:recipes/linux/linux-omap3-2.6.34/overo/defconfig defconfig | grep UBIFS -CONFIG_UBIFS_FS=y -# CONFIG_UBIFS_FS_XATTR is not set -# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set -CONFIG_UBIFS_FS_LZO=y -CONFIG_UBIFS_FS_ZLIB=y -CONFIG_UBIFS_FS_DEBUG=y -CONFIG_UBIFS_FS_DEBUG_MSG_LVL=3 -# CONFIG_UBIFS_FS_DEBUG_CHKS is not set +# CONFIG_UBIFS_FS is not set That right there probably gives you all you need. 2. A more generic way to do it is invoke the kernel menuconfig utility. $ bitbake -c menuconfig virtual/kernel You should get the standard linux ncurses config editor. Make the changes to enable UBIFS and then save it. The UBIFS section is under Filesystems|Miscellaneous filesystems. When you are done it saves a .config file here $OETMP/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r97/git/.config Copy that file to $OVEROTOP/org.openembedded.dev/recipes/linux/linux-omap3-2.6.34/overo/defconfig Whichever way you chose to edit the defconfig, you now want to rebuild the kernel AND rootfs. $ bitbake -c clean virtual/kernel $ bitbake virtual/kernel $ bitbake work-image (or whatever image you are using) Scott -- Sent from my Linux box |
From: softwizz <ad...@is...> - 2011-03-22 10:37:40
|
Again many thanks Scott, you have provided me with the means to address a considerable number of my ongoing tasks. The use of menuconfig was already well understood (though I prefer xconfig), but I had not previously known how to action that systemically under bitbake. One point arises - is "bitbake -c clean virtual/kernel" absolutely essential at that point in the process? It clears down a considerable scope of the build tree, which has unpleasant side-effects for me. I have something like 20 modified kernel files, plus the kernel file-list and indexed database for cscope, plus a build directory for userland code that I normally position under busybox. All of these get wiped and have to be restored after "bitbake -c clean virtual/kernel". If I'm only changing the kernel config, I can I not just do a "bitbake -f -c compile linux-omap3-2.6.34" and "bitbake -f -c deploy linux-omap3-2.6.34"? That would preserve all the files I need to keep safe. If that would not be enough, then is there any more thoroughgoing action that I can take, which at the same time does not remove my modified content from the tree? It may be that I would need to write back my modified content to the archives from which the build is constructed, so that they would be unpacked along with the normal content. I guess there must be a method for doing that, but again I have no clue what it is, and I certainly don't wish to post any of this back to the online repository by mistake! All help appreciated, as always! Cheers, Mike jumpnowdev wrote: > > Hi Mike, > > You want to change this file. > > $OVEROTOP/org.openembedded.dev/recipes/linux/linux-omap3-2.6.34/overo/defconfig > > As usual, TIMTOWTDI. Here are two. > > 1. You could use git to pull out the UBIFS changes to the defconfig in the > [minimal-2.6.34] branch and then hand edit the file yourself. This assumes > your tree has an [overo] branch to compare against. > > $ cd $OVEROTOP/org.openembedded.dev/recipes/linux/linux-omap3-2.6.34/overo > > $ git diff overo:recipes/linux/linux-omap3-2.6.34/overo/defconfig > defconfig | grep UBIFS > > -CONFIG_UBIFS_FS=y > -# CONFIG_UBIFS_FS_XATTR is not set > -# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set > -CONFIG_UBIFS_FS_LZO=y > -CONFIG_UBIFS_FS_ZLIB=y > -CONFIG_UBIFS_FS_DEBUG=y > -CONFIG_UBIFS_FS_DEBUG_MSG_LVL=3 > -# CONFIG_UBIFS_FS_DEBUG_CHKS is not set > +# CONFIG_UBIFS_FS is not set > > That right there probably gives you all you need. > > 2. A more generic way to do it is invoke the kernel menuconfig utility. > > $ bitbake -c menuconfig virtual/kernel > > You should get the standard linux ncurses config editor. Make the changes > to > enable UBIFS and then save it. The UBIFS section is under > Filesystems|Miscellaneous filesystems. > > When you are done it saves a .config file here > > $OETMP/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r97/git/.config > > Copy that file to > > $OVEROTOP/org.openembedded.dev/recipes/linux/linux-omap3-2.6.34/overo/defconfig > > > Whichever way you chose to edit the defconfig, you now want to rebuild > the kernel AND rootfs. > > $ bitbake -c clean virtual/kernel > $ bitbake virtual/kernel > $ bitbake work-image (or whatever image you are using) > > Scott > > -- > Sent from my Linux box > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31208583.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2011-03-22 12:33:32
|
I think the approach you are suggesting would work. That's not how I do things, so I couldn't say for sure. Maybe some OE/bitbake guru on this list has suggestions. When I get to the point where I am making multiple changes to the kernel I switch to working completely outside of bitbake in my own linux git repository. I documented how I work here in the 'Working on the kernel without bitbake' section. http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=46&Itemid=54 At the end of the day, you can generate a patch from that repository to use with bitbake or you can just copy the uImage and modules (after make modules_install INSTALL_MOD_PATH=<some-temp-dir>) No way I could put up with that bitbake stuff all day ;-) Scott -- Sent from my Linux box |
From: softwizz <ad...@is...> - 2011-03-31 10:43:48
|
Hi again Scott, I'm now tasked with enhancing the networking support on the r97 minimal build. I've added vsftpd to the recipe, and it duly builds. Moreover, when I boot it up, sure enough vsftpd is already executing. However, the network is not up, and I need to do it manually :- "ifconfig eth0 <IPv4addr> netmask <IPv4mask>" and the system is then operational and I can ftp in from my devhost. This change is typical of others that I may need to make in the startup scripts, so its a good exercise to get it right. I assumed that it would just be a straightforward step to make this ifconfig happen during the initialization, but it's proving hard to pin down. There seems to be a logical place to put it, which is in /etc/network/interfaces where I would like to replace this :- iface eth0 inet dhcp with this :- iface eth0 inet static address <IPv4addr> netmask <IPv4mask> network <IPv4net> gateway <IPv4addr> However, I cannot establish where the source of this file in the rootfs is coming from. I located what I thought was the correct place at :- org.openembedded.dev/recipes/netbase/netbase/overo/interfaces but when I made my changes and then rebuilt, the file in rootfs failed to reflect my changes. So I assumed that the source must be a different file, and - using a checksum that is quoted in the rootfs file - I identified and removed all instances from tmp (including compressed archives in the images directory), and then traced two and only two other files with the same content :- org.openembedded.dev/recipes/netbase/netbase/beagleboard/interfaces org.openembedded.dev/recipes/netbase/netbase/omap3-multi/interfaces I then made the same change in each of these, and further modified the changes so that the rootfs copy would tell me where it had come from. Guess what - on rebuilding, it still failed to reflect my changes. The rootfs tree is volatile and gets recreated across builds, so this is not simply an unchanged build output. Nor are my changes getting overwritten at source - they are still there. So I've been trying to find the source from which this file is getting reinstated. I've spent quite a few hours on the chase, but I'm continually hampered by the blind nature of the build process. My workaround for this has been to echo messages and information from within the build scripts into a logfile, but now I'm hitting non-intuitive behaviour in the scripts. For example, I believe I've proved that this script :- org.openembedded.dev/classes/rootfs_ipk.bbclass is being executed when /etc/network/interfaces is created, but trying to establish the script that is being run beneath this one at the time, is proving very hard. This is being executed :- opkg-cl $(IPKG_ARGS) install $(PACKAGE_INSTALL) $PACKAGE_INSTALL is a long list of packages which now includes vsftpd, but which script is executed in the case of each package? Taking an obvious candidate, initscripts, I find an obvious candidate recipe :- org.embedded.dev/recipes/initscripts/initscripts_1.0.bb but I can't find what part of that script is being executed, nor can I find another candidate script. I have located a couple of likely origins of the interfaces file, in sources/ifupdown-0.6.10.tar,gz - surely I am not expected to modify those! Is there an easy way to :- (a) insert a simple initialization such as this into the boot sequence? (b) get precise visibility on the sources of rootfs content? Cheers, Mike -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31285177.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2011-03-31 12:35:14
|
Hi Mike, I think you need to add the 'auto' command too. auto eth0 iface eth0 inet static address <IPv4addr> netmask <IPv4mask> network <IPv4net> gateway <IPv4addr> But then you were right the first time ../recipes/netbase/netbase/overo/interfaces is the file to change. You just need to clean the netbase package before rebuilding the image. $ bitbake -c clean netbase $ bitbake work-image That should do it. It did for me on a test here. As for general OE debugging, you are asking the wrong guy ;-) Scott On Thu, 2011-03-31 at 03:43 -0700, softwizz wrote: > Hi again Scott, > > I'm now tasked with enhancing the networking support on the r97 minimal > build. I've added vsftpd to the recipe, and it duly builds. Moreover, when > I boot it up, sure enough vsftpd is already executing. However, the network > is not up, and I need to do it manually :- > > "ifconfig eth0 <IPv4addr> netmask <IPv4mask>" > > and the system is then operational and I can ftp in from my devhost. > > This change is typical of others that I may need to make in the startup > scripts, so its a good exercise to get it right. I assumed that it would > just be a straightforward step to make this ifconfig happen during the > initialization, but it's proving hard to pin down. There seems to be a > logical place to put it, which is in /etc/network/interfaces where I would > like to replace this :- > > iface eth0 inet dhcp > > with this :- > > iface eth0 inet static > address <IPv4addr> > netmask <IPv4mask> > network <IPv4net> > gateway <IPv4addr> > > However, I cannot establish where the source of this file in the rootfs is > coming from. I located what I thought was the correct place at :- > > org.openembedded.dev/recipes/netbase/netbase/overo/interfaces > > but when I made my changes and then rebuilt, the file in rootfs failed to > reflect my changes. So I assumed that the source must be a different file, > and - using a checksum that is quoted in the rootfs file - I identified and > removed all instances from tmp (including compressed archives in the images > directory), and then traced two and only two other files with the same > content :- > > org.openembedded.dev/recipes/netbase/netbase/beagleboard/interfaces > org.openembedded.dev/recipes/netbase/netbase/omap3-multi/interfaces > > I then made the same change in each of these, and further modified the > changes so that the rootfs copy would tell me where it had come from. Guess > what - on rebuilding, it still failed to reflect my changes. The rootfs > tree is volatile and gets recreated across builds, so this is not simply an > unchanged build output. Nor are my changes getting overwritten at source - > they are still there. > > So I've been trying to find the source from which this file is getting > reinstated. I've spent quite a few hours on the chase, but I'm continually > hampered by the blind nature of the build process. My workaround for this > has been to echo messages and information from within the build scripts into > a logfile, but now I'm hitting non-intuitive behaviour in the scripts. For > example, I believe I've proved that this script :- > > org.openembedded.dev/classes/rootfs_ipk.bbclass > > is being executed when /etc/network/interfaces is created, but trying to > establish the script that is being run beneath this one at the time, is > proving very hard. This is being executed :- > > opkg-cl $(IPKG_ARGS) install $(PACKAGE_INSTALL) > > $PACKAGE_INSTALL is a long list of packages which now includes vsftpd, but > which script is executed in the case of each package? Taking an obvious > candidate, initscripts, I find an obvious candidate recipe :- > > org.embedded.dev/recipes/initscripts/initscripts_1.0.bb > > but I can't find what part of that script is being executed, nor can I find > another candidate script. I have located a couple of likely origins of the > interfaces file, in sources/ifupdown-0.6.10.tar,gz - surely I am not > expected to modify those! > > Is there an easy way to :- > > (a) insert a simple initialization such as this into the boot sequence? > (b) get precise visibility on the sources of rootfs content? > > Cheers, > > Mike > -- > View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31285177.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Create and publish websites with WebMatrix > Use the most popular FREE web apps or write code yourself; > WebMatrix provides all the features you need to develop and > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Sent from my Linux box |
From: softwizz <ad...@is...> - 2011-04-11 13:57:32
|
Hi Scott, Your solution was perfect as always, thanx. I'm now debugging two problems that I see when booting from an ubifs NAND. The first is apparently benign but unsightly :- IRQ336: nobody cared [with attendant register dump] This happens on uSD boots as well, and it occurs as soon as the smsc911x ethernet driver requests its IRQ. As far as I can tell, the device is in a state which will trigger the IRQ, so when the latter gets enabled, the IRQ fires off, but the smsc911x driver's ISR is not in a state to process the interrupt at that point. I've tried a little tweaking around the call to request_irq() but without changing the behaviour in the way I want. I can stop the driver from working, or I can accept this cosmetic blemish. The third option would be to do a proper R&D exercise on the driver to fix the problem, but I can't justify the time cost for a purely cosmetic exercise. I've searched for reports of similar problems but there seems to be nothing specific to the ethernet device, just a lot of similar problems on a range of IRQ numbers, and seemingly no generic fix (the 'irqpoll' boot flag is not an option on our system due to the need for speed). My proposal is to modify the threshold level for printk() around the problem, so that the offending error report and reg dump are written silently to /var/log/messages. Have you any suggestions as to the correct place to make this mod? My other problem, I have reported in some detail under the topic name "ubi code broken in 2.6.34'. My first posting described the effect and suggested a possible cause. My second posting rejected the previous suggestion and identified the problem more precisely as being a disconnect between error conditions occurring deep down in the open() code in the ubifs kernel code, and error handling around ubifs open() calls being issued from userland - with a possible additional error in the holding on of a file lock for too long a time. I have now verified that the offending userland program is /sbin/udevadm and I'm adding debug code around the open() and fopen() calls to detect where the problem resides. Unfortunately this has thrown up yet another bitbake problem. When I ran 'bitbake work-image' the modified code modules did not recompile. When I ran 'bitbake -c compile udev-151' the modified code modules did not recompile. When I ran 'bitbake -c clean udev-151' the modified modules were overwritten with freshly unpacked and patched sources. What then is the procedure for rebuilding modified source files which generate binutils executables in the RFS? Cheers, Mike -- View this message in context: http://old.nabble.com/Help-with-rebuilding-using-bitbake-tp26382370p31370497.html Sent from the Gumstix mailing list archive at Nabble.com. |