From: AJ O. <coo...@gm...> - 2010-08-16 05:13:32
|
This is about the 4th time that I've `rm -rf`-d everything and started from scratch and never yet got a working `bitbake omap3-console-image` Every time I `git pull` it's a different set of problems. It's never the same package twice, but they never all compile for the basic console image anywhere from 4 to 20 hours in. Fortunately, I do have a machine that did build omap3-console-image a few weeks ago at work. But I've never been able to get it on my machine at home (same os) to start playing around with. What needs to happen in order for things to git checked that they work with at least a few common meta-tasks before being pushed out? And is there anything I can do to help? (Donate some machine time to run tests, for example) Obviously, we all have our day jobs and whatnot, but this is becoming really frustrating for me and I'd like to see things improve. AJ ONeal P.S I have been compiling a list of common problems and possible solutions: http://fastr.github.com/articles/Troubleshooting-bitbake.html |
From: msbroadf <msb...@gm...> - 2010-08-16 10:34:58
|
I dont have any problems with bitbake. The only time i had to do a rm -rf tmp was about a week ago when someone changed something way upstream in openembedded and steve sakoman gave us a warning about it. Make sure you use ubuntu 10.04 and all is setup exactly as described in the wiki. Dont forget bitbake is opensource if you see bugs fix them! -- View this message in context: http://old.nabble.com/What-to-do-about-the-poor-bitbake-Quality-Control--tp29446809p29448615.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: ScottEllis <sco...@gm...> - 2010-08-16 12:07:48
|
After working with the gumstix for about a year now, here's how I go about it. I use the gumstix professionally so really can never afford to be broken because of an upstream update. I maintain my own local branches of the org.openembedded.dev repository and work off them. I have several branches for different projects. Periodically I switch back to the 'overo' branch, do a git pull and build and if it works, switch back to locals and merge in the 'overo' branch changes. This costs next to nothing in disk space and is what git was built for. I also maintain multiple OETMP disk partitions that I switch between by modifying the ${OVEROTOP}/build/conf/site.conf:TMPDIR variable. So when I do the test build of the overo pull it's done in an alternate location. If it fails and I don't want to figure out why, just switch back OETMP, switch back to my local branch and I still have a working build system. This costs some disk space, but disks are pretty cheap. As a bigger experiment, I started pushing local OE branches up to a gitorious account that I can use as my own official OE repository. I'll use it for machines not accessible to my main build workstation by pushing tested local branches there. I think that's going to work well and it doesn't cost anything. Granted you need one working build to start, but I also don't usually see build issues and I really do like having the latest, greatest software available. Whether I use the latest is always under my control based on the branch I'm working on. I know some guys working on another linux board for which the mfg's only provide an early 2.6.2x kernel and they are stuck. That wouldn't be any fun. I did a pull this Saturday from the gumstix-oe repository and omap3-console-image built without errors on a clean OETMP. The OE folks shuffled the build directory structure as msbroadf indicated, so a clean OETMP was necessary, but there was nothing gumstix could do about that. For me the user.collections directory idea seems redundant with git and it's ability to do cheap local branches. Since roughly 42% of the web consists of git tutorials, I won't even go there. Just some thoughts. -- View this message in context: http://old.nabble.com/What-to-do-about-the-poor-bitbake-Quality-Control--tp29446809p29449145.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Kai H. [Automatica] <ka...@au...> - 2010-08-16 13:18:25
Attachments:
smime.p7s
|
[snip] long email regarding building OE from source [snip] Sorry to hijack this thread... Just out of interest - what benefit do you gain from using a complied from source image for your Overos, rather than using a pre-built image? I'm looking at a project where I'll be deploying 100-200 of them and I'm genuinely curious if there are advantages to doing so... Thanks, Kai |
From: Alex G. <al...@al...> - 2010-08-17 01:24:37
|
On 16/08/2010 10:12 PM, Kai Howells [Automatica] wrote: > [snip] long email regarding building OE from source [snip] > > Sorry to hijack this thread... Just out of interest - what benefit do you gain from using a complied from source image for your Overos, rather than using a pre-built image? > > I'm looking at a project where I'll be deploying 100-200 of them and I'm genuinely curious if there are advantages to doing so... > > Thanks, > Kai > Having exactly what you need and nothing else. Have all the modules, firmware(wifi etc), packages, libraries and exact setup you need in the image without having to run opkg or doing thing else. Only running 20 for one project(sensor system for smart phone tracking). In the process of getting a remotely accessible lab setup (eventually probably around 10 boards) for students to use for a Real-time operating systems subject to replace the old coldfire rigs. Also having a "vm farm/cluster" for students to do image rebuilds on odvlab.eng.uts.edu.au For our builds I use a mix of vm's on a vmware infrastructure server and a couple of linux desktops (all on fedora 12/13 64 bit) remotelabs/experiments will eventually be at remotelabs.eng.uts.edu.au Alex -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology, Sydney. Before opening any attachments, please check them for viruses and defects. |
From: Scott E. <sco...@gm...> - 2010-08-16 13:41:14
|
For us, primarily a customized kernel (usb networking, mods to the board file) and some tweaking of the pin muxing in u-boot for some custom peripherals. We also minimized the userland because we don't need it and to help speed the boot. We're down around 5 seconds now which we're happy with. On 8/16/10, Kai Howells [Automatica] <ka...@au...> wrote: > [snip] long email regarding building OE from source [snip] > > Sorry to hijack this thread... Just out of interest - what benefit do you > gain from using a complied from source image for your Overos, rather than > using a pre-built image? > > I'm looking at a project where I'll be deploying 100-200 of them and I'm > genuinely curious if there are advantages to doing so... > > Thanks, > Kai |
From: Kai H. [Automatica] <ka...@au...> - 2010-08-16 21:23:33
Attachments:
smime.p7s
|
That's pretty good, 5 second boot times are an excellent reason to go to that amount of trouble! On 16/08/2010, at 11:41 PM, Scott Ellis wrote: > For us, primarily a customized kernel (usb networking, mods to the > board file) and some tweaking of the pin muxing in u-boot for some > custom peripherals. We also minimized the userland because we don't > need it and to help speed the boot. We're down around 5 seconds now > which we're happy with. > > > On 8/16/10, Kai Howells [Automatica] <ka...@au...> wrote: >> [snip] long email regarding building OE from source [snip] >> >> Sorry to hijack this thread... Just out of interest - what benefit do you >> gain from using a complied from source image for your Overos, rather than >> using a pre-built image? >> >> I'm looking at a project where I'll be deploying 100-200 of them and I'm >> genuinely curious if there are advantages to doing so... >> >> Thanks, >> Kai > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Andrew K. (m. l. account) <ak...@mi...> - 2010-08-16 13:47:44
|
On Monday, August 16, 2010 01:13:24 am AJ ONeal wrote: > This is about the 4th time that I've `rm -rf`-d everything and started from > scratch and never yet got a working `bitbake omap3-console-image` > > Every time I `git pull` it's a different set of problems. It's never the > same package twice, but they never all compile for the basic console image > anywhere from 4 to 20 hours in. Personally I never recommend running HEAD of the master branch. It's under constant development. Pick a recent point-in-time release and pull that branch. Far more stable. > Obviously, we all have our day jobs and whatnot, but this is becoming > really frustrating for me and I'd like to see things improve. This is a common complaint in open source. There are those who want to develop the OE environment and push it forward, and they all recommend running the bleeding edge stuff because that's where the action is. Those of us who want to USE OE, on the other hand, prefer stable point-in-time releases so that we can get OUR stuff working, and after we get that done we will happily push our stuff to the bleeding edge. -A. |
From: Andrew K. (m. l. account) <ak...@mi...> - 2010-08-16 13:50:54
|
On Monday, August 16, 2010 08:07:40 am ScottEllis wrote: > I maintain my own local branches of the org.openembedded.dev > repository and work off them. I have several branches for different > projects. Periodically I switch back to the 'overo' branch, do a git > pull and build and if it works, switch back to locals and merge in > the 'overo' branch changes. This costs next to nothing in disk space > and is what git was built for. This is a very good way to do things. > Since roughly 42% of the web consists of git tutorials, I won't even > go there. That is actually part of the problem: too many ways to do things. Do you have a tutorial or two that you found useful? I have worked on and off with git as a very "light" user and I tend to run into trouble whenever I try to do something more complex than simple pull/push and committing to a single branch. -A. |
From: Markus S. <msv...@ae...> - 2010-08-16 14:00:48
|
Hi Scott, On 2010.08.16 9:41, Scott Ellis wrote: > For us, primarily a customized kernel (usb networking, mods to the > board file) and some tweaking of the pin muxing in u-boot for some > custom peripherals. We also minimized the userland because we don't > need it and to help speed the boot. We're down around 5 seconds now > which we're happy with. This is off-topic for this thread, but I am interested to know more about the userland minimization you did to get the boot time down to 5 seconds. I'm going to be shipping some devices with a Gumstix inside to a client, and the long-ish boot time on the pre-built image is something I'd like to change. For me, Bluetooth adds many seconds to boot time; did you disable it? What other changes? Best regards, Markus. > > On 8/16/10, Kai Howells [Automatica]<ka...@au...> wrote: >> [snip] long email regarding building OE from source [snip] >> >> Sorry to hijack this thread... Just out of interest - what benefit do you >> gain from using a complied from source image for your Overos, rather than >> using a pre-built image? >> >> I'm looking at a project where I'll be deploying 100-200 of them and I'm >> genuinely curious if there are advantages to doing so... >> >> Thanks, >> Kai > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Scott E. <sco...@gm...> - 2010-08-17 08:02:16
|
On 8/16/10, Markus Svilans <msv...@ae...> wrote: > This is off-topic for this thread, but I am interested to know more > about the userland minimization you did to get the boot time down to 5 > seconds. I'm going to be shipping some devices with a Gumstix inside to > a client, and the long-ish boot time on the pre-built image is something > I'd like to change. For me, Bluetooth adds many seconds to boot time; > did you disable it? What other changes? > The image we use is pretty minimal, no display, no wireless, probably not useful to you. Here is a sample boot log http://pastebin.com/5bDUwmR4 You can get the modified gumstix-oe/overo branch here http://gitorious.org/~scott-ellis/gumstix-oe/scottellis-gumstix-oe It's the 'minimal' branch that you want. There are only a few changed files from the stock gumstix-oe/overo repository. I think this is it. You can browse them on gitorious. recipes/linux/linux-omap3_2.6.34.bb recipes/linux/linux-omap3-2.6.34/no-lcd-gpio.patch recipes/linux/linux-omap3-2.6.34/overo/defconfig recipes/images/work-image.bb bitbake work-image to get the image that generated that boot log. I also have this fix-up script to remove some init.d entries as part of the MMC copy script I use. It gets run after the untar'ing of the rootfs but before the SD card is unmounted. Someday I should figure how to do this properly in OE so the entries never get added, but it works for now. #!/bin/bash ETCDIR=/media/card/etc echo "Fixing scripts in $ETCDIR/rcS.d" cd ${ETCDIR}/rcS.d sudo rm S02banner sudo rm S03udev sudo rm S12udev-cache sudo rm S45mountnfs.sh echo "Fixing scripts in $ETCDIR/rc5.d" cd ${ETCDIR}/rc5.d echo "Fixing scripts in $ETCDIR/rc6.d" cd ${ETCDIR}/rc6.d sudo rm S25save-rtc.sh echo "Fixing scripts in $ETCDIR/rc0.d" cd ${ETCDIR}/rc0.d sudo rm S25save-rtc.sh |
From: Eric W. <eri...@gm...> - 2010-08-16 14:51:59
|
I agree -- this is the way I am working as well. One thing that I have found troublesome is the new kernel git maintenance methodology. Prior to the 2.6.33 kernels, the recipes had a baseline kernel image and listed all of the necessary patches. Now that the patches are being applied on the sakoman.com repository, it is much more difficult for an end-user to customize patches. For example, one cannot apply the preempt-rt patch to the sakoman repository versions, since there are many overlaps. One can apply the RT patch to a baseline kernel repository and then apply necessary overo patches atop it to get a useable kernel. --Eric On Mon, Aug 16, 2010 at 9:50 AM, Andrew Kohlsmith (mailing lists account) < ak...@mi...> wrote: > On Monday, August 16, 2010 08:07:40 am ScottEllis wrote: > > I maintain my own local branches of the org.openembedded.dev > > repository and work off them. I have several branches for different > > projects. Periodically I switch back to the 'overo' branch, do a git > > pull and build and if it works, switch back to locals and merge in > > the 'overo' branch changes. This costs next to nothing in disk space > > and is what git was built for. > > This is a very good way to do things. > > > Since roughly 42% of the web consists of git tutorials, I won't even > > go there. > > That is actually part of the problem: too many ways to do things. Do you > have > a tutorial or two that you found useful? I have worked on and off with git > as a > very "light" user and I tend to run into trouble whenever I try to do > something more complex than simple pull/push and committing to a single > branch. > > -A. > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: J. L. <vwy...@gm...> - 2010-08-16 18:23:22
|
I dont believe it to be truly bleeding edge as there are to many programs that are one or more versions behind the current programs version, and there are to many recipes that are un-buildable and or to old to even use. Open Source or not, there are plenty of users who may not know enough or are just starting out that may not know how to fix the bugs they run into and most of the time if those bugs are not ones others are interested in then there questions on those bugs go un answered. Then if you go to the OE list and ask them, they do not really want to help as we are not on their branch as they put it on the OE list we "are some random branch". I personally think there should be something different done to enable us to use things more smoothly. Or possibly like how OE does it a stable branch (though its drastically out of date) and the dev. And as suggested earlier in this thread that if we are to make our own trees off the overo branch. Then that should be something that someone whos willing and very knowledgeable should post a wiki how to or gumstix you should add more to your own wiki to help your less experienced users. The documentation still seems to be lacking even compared to say what Beagleboard users have for a documentation base. As another user stated to use Ubuntu 10.04 to get the best results well for my mileage thats not correct I have never been able to do a build using that OS. Now for me Ubuntu 9.10 is what works the best with me, but I see complaints for all the different OS's as well as different issues depending on the OS being used. Here is what Koen from OE says about our branch and AJ asking there: "That recipe isn't in OE, so it seems you're building from what we call "some random tree", which is unsupported. Complain to the people in charge of that tree and tell them to fix things. If people don't care enough to get there stuff upstream, upstream won't care about problems in that tree." So if OE does not take care of our tree and our tree breaks a bunch how can we make it better since its "our" responsibility to help better this for our own good. Also if our tree gets updated from the dev OE branch what testing is done before hand to see if what we will get from our next git pull will break us or not? I know myself could and would benefit drastically from a walk through of how to create our own recipe from a program someone would want to BB into their build. I have been able to do something simple but have yet to have any luck with more complicated programs that I have tried to write recipes for. AJ was kind enough to give me a great jump start with a blog of his, but there is still more I think should be done. Yes I know I personally have not done anything to help better but that is not due to a lack of want its a lack of I dont know how! I would love to help this branch out as well as bring in newer program versions as well as programs. I think a RFC should and needs to be done. My points may not be the best but its from a still excited and willing gumstix user that would like to get further using them as well as help the community get further. I think AJ brings up a great point and hope we all benefit from this. On Mon, Aug 16, 2010 at 7:51 AM, Eric Wenger <eri...@gm...> wrote: > I agree -- this is the way I am working as well. One thing that I have > found troublesome is the new kernel git maintenance methodology. Prior to > the 2.6.33 kernels, the recipes had a baseline kernel image and listed all > of the necessary patches. Now that the patches are being applied on the > sakoman.com repository, it is much more difficult for an end-user to > customize patches. For example, one cannot apply the preempt-rt patch to > the sakoman repository versions, since there are many overlaps. One can > apply the RT patch to a baseline kernel repository and then apply necessary > overo patches atop it to get a useable kernel. > > --Eric > > On Mon, Aug 16, 2010 at 9:50 AM, Andrew Kohlsmith (mailing lists account) > <ak...@mi...> wrote: >> >> On Monday, August 16, 2010 08:07:40 am ScottEllis wrote: >> > I maintain my own local branches of the org.openembedded.dev >> > repository and work off them. I have several branches for different >> > projects. Periodically I switch back to the 'overo' branch, do a git >> > pull and build and if it works, switch back to locals and merge in >> > the 'overo' branch changes. This costs next to nothing in disk space >> > and is what git was built for. >> >> This is a very good way to do things. >> >> > Since roughly 42% of the web consists of git tutorials, I won't even >> > go there. >> >> That is actually part of the problem: too many ways to do things. Do you >> have >> a tutorial or two that you found useful? I have worked on and off with git >> as a >> very "light" user and I tend to run into trouble whenever I try to do >> something more complex than simple pull/push and committing to a single >> branch. >> >> -A. >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Scott E. <sco...@gm...> - 2010-08-17 08:22:22
|
On 8/16/10, Andrew Kohlsmith (mailing lists account) <ak...@mi...> wrote: > > That is actually part of the problem: too many ways to do things. Do you > have > a tutorial or two that you found useful? I have worked on and off with git > as a > very "light" user and I tend to run into trouble whenever I try to do > something more complex than simple pull/push and committing to a single > branch. > I'm no Git expert, but I went with the total immersion approach. I figured it's not really optional if I want to work with free software projects. I started using Github and now Gitorious for all new projects and the flexibility they offer is a strong motivator. I have a paid account with Github so I can use it with private customer projects. And I have both of these books Version Control with Git by Jon Loeliger Pro Git by Scott Chacon. Of the two I'd choose the Pro Git book first, but both are good. |
From: Kai H. [Automatica] <ka...@au...> - 2010-08-18 10:59:31
Attachments:
smime.p7s
|
With an Overo system, the supplied adapters from Gumstix are 5VDC. Will an Overo + Chestnut board + LCD happily run from 4.5VDC (eg. a battery pack with 3x 1.5V cells) or would it prefer 6VDC (4x 1.5V) Also, if I'm using NiMH cells (instead of alkaline cells) that deliver more like 1.1V to 1.4V each, would I need to use three cells or 4 cells? Cheers, Kai |