Please stop smoking crack
Very funny.
If you have tried to build OS, tools or applications in Linux, you will know
that this is not always so simple. Inevitably you find that your system
isn't setup correctly, or you have missing tools, or you have the wrong
versions or something or other; then you need to find appropriate patches
and apply only those patches that are proven; so in the end this just leads
to a big headache.
Koen and his buddies have done an amazing job of simplifying all this for
you. OpenEmbedded builds everything you need by installing the correct
version of the tools you will need, downloads the all the files you will
need from several reliable sources, checks to see if the downloads are error
free, does some quality assurance, stages each build, applies only proven
patches, and then does a build to give you a reliable result that you can be
confident will work almost every time. OE does this for hundreds of recipes
to give you everything you need without having to understand how it does
this.
Learn more about OE and you will find that you have all the control you will
need.
Kind Regards,
John
From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Koen Kooi
Sent: Friday, May 29, 2009 10:51 AM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Re: how to create root file system?> But it seems a better approach for my specific project to manually
> compile the kernel first then build the file system, instead of the
> totally automatic process of "bitbake console-image", in this way I
> have more control.Please stop smoking crack
Very funny.
Is it? chuqdd has described exactly my needs, and the ones of
countless of developers at linux-omap, Nokia, and Texas Instruments.
Are we all crazy?
If you have tried to build OS, tools or applications in Linux, you will know
that this is not always so simple. Inevitably you find that your system
isn't setup correctly, or you have missing tools, or you have the wrong
versions or something or other; then you need to find appropriate patches
and apply only those patches that are proven; so in the end this just leads
to a big headache.Koen and his buddies have done an amazing job of simplifying all this for
you. OpenEmbedded builds everything you need by installing the correct
version of the tools you will need, downloads the all the files you will
need from several reliable sources, checks to see if the downloads are error
free, does some quality assurance, stages each build, applies only proven
patches, and then does a build to give you a reliable result that you can be
confident will work almost every time. OE does this for hundreds of recipes
to give you everything you need without having to understand how it does
this.
Just because someone somewhere had spent a lot of time making
something easy doesn't mean I should use it. The solution should fit
to my needs, no the other way around.
Learn more about OE and you will find that you have all the control you will
need.
Well, he is asking to be in control of his kernel and leave OE out of
that, and just use it to build the rootfs. Can OE do that?
Personally the only solution that has given me enough control is
ALIP[1]. I compile my own kernel and ALIP builds the rootfs exactly
how I want it (almost).
Cheers.
It usually goes something like this:
developer: "I want more control! I'll compile my own kernel!"
some time passes...
developer: "The standard kernel doesn't work!"
beagle veteran: "Use tmlind git tree"
developer: "git? tmlind?"
some time passes...
developer: "The tmlind tree doesn't work, I have no s-video"
beagel veteran: "Then you need to patch in DSS2"
developer: "DSS2? What does 'patch in' mean?"
some more time passes....
developer: "I patched in DSS2, but it gives all kinds or sync errors"
beagle veteran: "You need to upgrade uboot to something like 2009.0X"
some more time passes...
developer: "DSS2 works, but usb is broken"
beagle veteran: "grab the musb patches from the internet"
And that conversation pretty much continues till the 'developer' has a kernel that is virtually identical to the one OE builds. So he wasted a few weeks with being stubborn instead of just adding the patch/defconfig option/bootlogo he needed to the OE kernel.
Get something working first, then see if you can patch in your changes. In the fringe case that you can't do that, roll your own. Just ask Robert Nelson how much time he saved by grabbing the patches and defconfig from OE to build the debian kernels.
regards,
Koen
Your definition of "developer" is pretty short-sighted. I'm a
developer, and I was able to set up a kernel exactly for my needs, and
I know many people capable of doing that.
Also, as a distro package maintainer every patch that you are not
pushing upstream is a disservice you are doing to the Linux community.
Personally I see the OE patches being used as a hook for inexperienced
users; don't know how to compile your own kernel? Don't worry! Use OE,
we have all the nice patches that nobody else has 
I'd say to chuqdd and other developers in similar situation; build
your own kernel, and make sure that the patches you need get pushed
upstream so that everyone (including OE users) benefit.
Cheers.
That's correct, without Koen's 2.6.26 kernel Debian wouldn't never had
been brought up as quickly. I think the beagleboard forum logs show
me pulling my hair out for a week or two with TI's 2.6.22 reference
kernel last august.
It's always best to start with something that works (Koen's patchset
in this case) and use it to your needs.
Regards,
From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Felipe Contreras
Sent: Friday, May 29, 2009 11:43 AM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Re: how to create root file system?>
>> From: beagleboard@googlegroups.com
>> [mailto:beagleboard@googlegroups.com] On Behalf Of Koen Kooi
>> Sent: Friday, May 29, 2009 10:51 AM
>> To: beagleboard@googlegroups.com
>> Subject: [beagleboard] Re: how to create root file system?
>>
>>
>>
>> > But it seems a better approach for my specific project to manually
>> > compile the kernel first then build the file system, instead of the
>> > totally automatic process of "bitbake console-image", in this way I
>> > have more control.
>>
>>
>> Please stop smoking crack
> Very funny.Is it? chuqdd has described exactly my needs, and the ones of
countless of developers at linux-omap, Nokia, and Texas Instruments.
Are we all crazy?> If you have tried to build OS, tools or applications in Linux, you will know
> that this is not always so simple. Inevitably you find that your system
> isn't setup correctly, or you have missing tools, or you have the wrong
> versions or something or other; then you need to find appropriate patches
> and apply only those patches that are proven; so in the end this just leads
> to a big headache.
>
> Koen and his buddies have done an amazing job of simplifying all this for
> you. OpenEmbedded builds everything you need by installing the correct
> version of the tools you will need, downloads the all the files you will
> need from several reliable sources, checks to see if the downloads are error
> free, does some quality assurance, stages each build, applies only proven
> patches, and then does a build to give you a reliable result that you can be
> confident will work almost every time. OE does this for hundreds of recipes
> to give you everything you need without having to understand how it does
> this.Just because someone somewhere had spent a lot of time making
something easy doesn't mean I should use it. The solution should fit
to my needs, no the other way around.> Learn more about OE and you will find that you have all the control you will
> need.Well, he is asking to be in control of his kernel and leave OE out of
that, and just use it to build the rootfs. Can OE do that?Personally the only solution that has given me enough control is
ALIP[1]. I compile my own kernel and ALIP builds the rootfs exactly
how I want it (almost).
This is a healthy discussion, which is always helpful. It all depends on your experience level and just how much you need to do. If you are comfortable building your Linux Kernel and know what patches are required, great; you don't need OE. If you know how to build your own filesystem, like Robert Nelson does, great; you don't need OE. If however you are new to Linux Embedded development and want a no brainer way to get this done, then OE is what you need. If you want to build any of the hundreds of applications/modules available in OE, you may want to use OE as thousands of hours of engineering time has gone into making sure these build without many problems.
Now I would agree with you Felipe if you are modifying Linux code. The way OE works with GIT is just plain stupid and I have spoken about this before. The OE developers are aware of this problem and they are looking for ways to address this limitation. I do all my Linux development outside OE, using the rich benefits GIT provides.
But, as Koen says, if you are an inexperienced developer, OE is your best and only way to get up and running before you even understand what it is that you are doing.
Kind Regards,
John
From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Felipe Contreras
Sent: Friday, May 29, 2009 11:43 AM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Re: how to create root file system?>
>> From: beagleboard@googlegroups.com
>> [mailto:beagleboard@googlegroups.com] On Behalf Of Koen Kooi
>> Sent: Friday, May 29, 2009 10:51 AM
>> To: beagleboard@googlegroups.com
>> Subject: [beagleboard] Re: how to create root file system?
>>
>>
>>
>> > But it seems a better approach for my specific project to manually
>> > compile the kernel first then build the file system, instead of the
>> > totally automatic process of "bitbake console-image", in this way I
>> > have more control.
>>
>>
>> Please stop smoking crack
> Very funny.Is it? chuqdd has described exactly my needs, and the ones of
countless of developers at linux-omap, Nokia, and Texas Instruments.
Are we all crazy?> If you have tried to build OS, tools or applications in Linux, you will know
> that this is not always so simple. Inevitably you find that your system
> isn't setup correctly, or you have missing tools, or you have the wrong
> versions or something or other; then you need to find appropriate patches
> and apply only those patches that are proven; so in the end this just leads
> to a big headache.
>
> Koen and his buddies have done an amazing job of simplifying all this for
> you. OpenEmbedded builds everything you need by installing the correct
> version of the tools you will need, downloads the all the files you will
> need from several reliable sources, checks to see if the downloads are error
> free, does some quality assurance, stages each build, applies only proven
> patches, and then does a build to give you a reliable result that you can be
> confident will work almost every time. OE does this for hundreds of recipes
> to give you everything you need without having to understand how it does
> this.Just because someone somewhere had spent a lot of time making
something easy doesn't mean I should use it. The solution should fit
to my needs, no the other way around.> Learn more about OE and you will find that you have all the control you will
> need.Well, he is asking to be in control of his kernel and leave OE out of
that, and just use it to build the rootfs. Can OE do that?Personally the only solution that has given me enough control is
ALIP[1]. I compile my own kernel and ALIP builds the rootfs exactly
how I want it (almost).This is a healthy discussion, which is always helpful. It all depends on your experience level and just how much you need to do. If you are comfortable building your Linux Kernel and know what patches are required, great; you don't need OE. If you know how to build your own filesystem, like Robert Nelson does, great; you don't need OE. If however you are new to Linux Embedded development and want a no brainer way to get this done, then OE is what you need. If you want to build any of the hundreds of applications/modules available in OE, you may want to use OE as thousands of hours of engineering time has gone into making sure these build without many problems.
This thread is about chuqdd's question, which is; how to build a
rootfs separately from the kernel, for which OE is simply not
suitable.
Now I would agree with you Felipe if you are modifying Linux code. The way OE works with GIT is just plain stupid and I have spoken about this before. The OE developers are aware of this problem and they are looking for ways to address this limitation. I do all my Linux development outside OE, using the rich benefits GIT provides.
But, as Koen says, if you are an inexperienced developer, OE is your best and only way to get up and running before you even understand what it is that you are doing.
That's the theory, in practice I, as an "experienced" developer (or at
least experienced enough to build rootfss and kernels from scratch),
was not able to setup OE.
In summary instead of telling people to stop smoking drugs, OE guys
should simple say; OE is not suitable for your use-case.
That's the theory, in practice I, as an "experienced" developer (or at
least experienced enough to build rootfss and kernels from scratch),
was not able to setup OE.In summary instead of telling people to stop smoking drugs, OE guys
should simple say; OE is not suitable for your use-case.
I think it's possible to build images with no kernel stuff with OE.
Just paste it:
ASSUME_PROVIDED += "virtual/linux"
into your local.conf.
Felipe,
Really appreciate your understanding and words.
Chuqdd
since i just went through something related to this, i'd like to
clarify how OE handles git content.
my "bitbake base-image" just finished git checking out the linux
omap kernel source, and what i have in my downloads directory are the
tarballs:
-rw-rw-r-- 1 rpjday rpjday 401593062 May 29 19:43
git_git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-2.6.git.tar.gz
-rw-rw-r-- 1 rpjday rpjday 74417503 May 29 19:44
git_git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-2.6.git_58cf2f1425abfd3a449f9fe985e48be2d2555022.tar.gz
plus there's a "git/" directory which contains the actual checkout
"git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-2.6.git".
and, finally, there's the recipes file "linux-omap_2.6.29.bb", which
contains the line
SRCREV = "58cf2f1425abfd3a449f9fe985e48be2d2555022"
so, as a wild guess, i'm assuming that the recipes file defines the
specific checkout, which is then checked out into the downloads/git/
directory, after which the tarballs are created (one with the .git
directory, one without?). is that about right?
rday
That's the theory, in practice I, as an "experienced" developer (or at
least experienced enough to build rootfss and kernels from scratch),
was not able to setup OE.
Ah, now I see the source of your frustration. I also had some difficulty getting OE to work at first, but once it was up and running, it seems the best way to get most of what I need done well. The confusing part is that there are multiple OE wiki's that setup OE differently, but I used a combination of the following two wikis:
http://elinux.org/BeagleBoardAndOpenEmbeddedGit
http://wiki.openembedded.net/index.php/Getting_started
The first has almost everything you need, except that it is missing the installation of bitbake, which I got from the second wiki.
Kind Regards,
John
for my own benefit, i did my own:
http://www.crashcourse.ca/wiki/index.php/Angstrom
which has only a couple issues, the first being the
"module-init-tools" build error i mentioned earlier, the second
involving "bitbake" itself which i might post on shortly.
rday
From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Robert P. J. Day
Sent: Friday, May 29, 2009 5:10 PM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Re: how to create root file system?> The way OE works with GIT is just plain stupid and I have spoken
> about this before. The OE developers are aware of this problem and
> they are looking for ways to address this limitation. I do all my
> Linux development outside OE, using the rich benefits GIT provides.since i just went through something related to this, i'd like to
clarify how OE handles git content.my "bitbake base-image" just finished git checking out the linux
omap kernel source, and what i have in my downloads directory are the
tarballs:-rw-rw-r-- 1 rpjday rpjday 401593062 May 29 19:43
git_git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-2.6.git.tar.gz
-rw-rw-r-- 1 rpjday rpjday 74417503 May 29 19:44
git_git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-
2.6.git_58cf2f1425abfd3a449f9fe985e48be2d2555022.tar.gzplus there's a "git/" directory which contains the actual checkout
"git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-2.6.git".
and, finally, there's the recipes file "linux-omap_2.6.29.bb", which
contains the lineSRCREV = "58cf2f1425abfd3a449f9fe985e48be2d2555022"
so, as a wild guess, i'm assuming that the recipes file defines the
specific checkout, which is then checked out into the downloads/git/
directory, after which the tarballs are created (one with the .git
directory, one without?). is that about right?
Actually no. Here is what OE does:
1) Downloads a tarball of the kernel GIT repository
2) Unpacks the GIT repository into
tmp/downloads/git/git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-
2.6.git/.git
3) Checkouts the shar1 58cf2f142
4) Creates an archive for 58cf2f142
5) Unpacks this archive to
tmp/work/beagleboard-angstrom-linux-gnueabi/linux-omap-2.6.29-r36+58cf2f142.
....
Hence the reason why I don't like the way OE works with GIT. You lose the
benefit of GIT since the source code you will modify is no longer under GIT
control. I would prefer that OE use GIT just like everyone uses GIT. Have a
repository and use git pull to update it. OE should create a separate
version branch and apply patches to that branch only. Later on, when OE is
updated, it simply does a git pull again and creates a new version branch so
the previous patches do not conflict with the new patches. Developers will
be able to make their own experimental branches and can merge those branches
with new updates to the kernel GIT. At least, I think this would be a better
way forward.
Kind Regards,
John
ok, i'm going to have to drink heavily to understand that, but can i
at least assume that, if i clean my bitbake build and start it over
just to verify it, that any "git" downloads will not have to be
downloaded again? regular tarballs in the download directory will
obviously be re-used, but will git checkouts also be re-used? thanks.
rday
From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Robert P. J. Day
Sent: Friday, May 29, 2009 8:31 PM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Re: how to create root file system?> Actually no. Here is what OE does:
> 1) Downloads a tarball of the kernel GIT repository
> 2) Unpacks the GIT repository into
>
tmp/downloads/git/git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-
> 2.6.git/.git
> 3) Checkouts the shar1 58cf2f142
> 4) Creates an archive for 58cf2f142
> 5) Unpacks this archive to
>
tmp/work/beagleboard-angstrom-linux-gnueabi/linux-omap-2.6.29-r36+58cf2f142.
> ....
ok, i'm going to have to drink heavily to understand that, but can i
at least assume that, if i clean my bitbake build and start it over
just to verify it, that any "git" downloads will not have to be
downloaded again? regular tarballs in the download directory will
obviously be re-used, but will git checkouts also be re-used? thanks.
If you want to understand what OE is doing, redirect the output to a file
and then review the file in an editor. If you want to see more details, add
-D to your bitbake command. Add additional -D to see more detail. For
example, if you do the following, it will help you understand how OE builds
the kernel.
bitbake -c clean linux-omap
bitbake -D -D -c build linux-omap |tee bitbake_linux.log
Kind Regards,
John
good thinking. i'll try the above for building base-image, except
that i'm also going to cut the make parallel value from 4 to 1 to keep
the output from going into the log file jumbled. then i'll start from
scratch and report on that module-init-tools issue.
build started, looking for coffee.
rday
p.s. i also added "2>&1" to grab stderr as well and stuff it in the
log file.
OE is suitable for that, it's exactly how TI is building their PSPs nowadays. My point was that the way chuqdd (real people have real names, not only 1337 nicks) phrased his email showed that he simply is not suitable for such a scenario, like many before him.
Just check the mailinglist archives and IRC logs for people stubbornly going the 'advanced' route while sometimes not even knowing how to apply a patch or pull a git tree. I have no problem with people doing their own stuff, but I do have a problem with people ignoring my advice and later on pestering me to solve the problems associated with their ignorance.
PSPs?
One thing is how TI builds official releases, and another is how
developers work on the Linux kernel.
If OE can build a rootfs without ever caring about the kernel, then
don't call people names, just point to the information about how that
can be done.
Hello!
If OE can build a rootfs without ever caring about the kernel, then
don't call people names, just point to the information about how that
can be done.
Looks like you just need to say that ASSUME_PROVIDED +=
"virtual/kernel" to your distro:
-----8<----------8<----------8<-----
$ git diff | cat
diff --git a/conf/distro/tilinux.conf b/conf/distro/tilinux.conf
index f2fd653..fa3b042 100644
--- a/conf/distro/tilinux.conf
+++ b/conf/distro/tilinux.conf
@@ -52,6 +52,7 @@ METADATA_REVISION = "${@base_get_metadata_svn_revision(d)}"