Jivin Robert P. J. Day lays it down ...
> On Thu, 25 Oct 2007, David McCullough wrote:
>
> > Jivin Robert P. J. Day lays it down ...
> > >
> > > sorry to pollute the list this much but i forgot to mention one
> > > more thing about my current uclinux nios2 patchset.
> > >
> > > i'm test building this kernel inside the absolutely latest,
> > > CVS-checked out uclinux surrounding infrastructure, so i'm not
> > > patching *anything* outside the kernel tree itself -- that is,
> > > nothing inside the top-level vendors/ directory, etc. in short,
> > > i'm assuming that any patches that used to be applied to the
> > > uclinux infrastructure back in, say, 20070130, are now part of the
> > > CVS repo. (if we're going to go bleeding edge, might as well go
> > > all the way.)
> >
> > For the non-kernel portions of the dist the CVS repo is not bleeding
> > edge. It follows the dist releases and is currently at version
> > uClinux-dist-20070130.
> >
> > If you wanted something more bleeding edge you could use the dist
> > snapshots that Gerg has been doing. Still, using CVS is probably
> > easier to manage at this point and close enough for us to easily
> > merge.
>
> really? that's just weird, having the CVS repo lagging behind tarball
> snapshots. what's the rationale for *that*? it certainly flies in
> the face of standard convention.
People wanted it to reduce downloads, we didn't want to maintain yet
another source tree, so we compromised, and the uClinux-dist CVS just
receives a copy of the latest tarball whenever it is ready, thus the
merges are zero effort for us, and other can benefit from reduce
downloads and between version revisions.
This has been discussed many times over the years and I am sure you can
find a much better response in the archives, somewhere :-)
> > > and my recipe for test building a kernel (i'm not doing anything
> > > with user space stuff yet):
> > >
> > > $ make menuconfig
> > > $ make vendor_hwselect SPSYTF=...
> >
> > Not sure what vendor_hwselect is, unless it's short hand for some
> > interactive process.
>
> these instructions are not being done from within the kernel
> directory, they're being done one level up in the uclinix top-level
> directory. that may be where you're getting confused.
I figured that was the case, it's just been so long since we put the
vendor_* target in, and no one much uses it, so I had completely
forgotten about it ;-)
Sounds a little bit like "make vendor_hwselect" should be part of the
"make menuconfig" somehow. It's generally best to be able to build a
target without having to enter any platform specific settings, like
the SPSYTF=... thing above. Still thats my opinion and what you are
doing is fine for now.
> > Building the dist with a 2.6 kernel is usually:
> >
> > make config/menuconfig/xconfig
> > make
> >
> > Everything else should get done for you.
> >
> > > $ mkdir romfs [manually]
> >
> > Why do you need to "mkdir romfs" ?
>
> because the default uclinux "make" target wants a destination
> directory for INITRAMFS_SOURCE. if that directory doesn't exist, the
> make complains. you can also, AFAICT, run "make romfs", but just
> creating the directory explicitly with "mkdir" seems sufficient.
Most if not all targets in the dist have always been a:
build kernel
build libs
build apps
jpin them together
approach. I realise that INITRAMFS_SOURCE breaks this. Of course, you
can't have your initramfs until you have your apps built, and you
really need you kernel and modules built before that anyway. It's a bit
like putting the cart before that horse ;-)
If you want to persevere with INITRAMFS_SOURCE, I would make your
vendor_hwselect create the romfs dir for now.
If you ever remove that step, perhaps we can look at some way of
automating it for any target that choose to use INITRAMFS_SOURCE.
> > > $ NON_SMP_BUILD=1 make linux
> >
> > Building the kernel is the first step, so the following will do:
> >
> > make NON_SMP_BUILD=1
> >
> > but
> >
> > make NON_SMP_BUILD=1 linux
> >
> > is also ok. On the bleeding edge dists you can run:
> >
> > make single
>
> ok, i'll take your word for it, i've never seen that before.
For reference (and the benefit of others):
make single
make single_linux
make single_lib_only
make single_user_only
make single_user/init_only
make single_user/init_romfs
...
In other words, prefix any build target with "single[_]*" and it
disables the multithreaded build support,
Cheers,
Davidm
--
David McCullough, [EMAIL PROTECTED], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
