[uClinux-dev] one more note about my nios2 patches for git kernel

[Robert P. J. Day]

On Fri, 26 Oct 2007, David McCullough wrote:

>
> Jivin Robert P. J. Day lays it down ...
> >
> > 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 :-)

ok, fair enough.

> > > > $ 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.

i agree completely, but i can see how the out-of-tree build structure
is doing a fair bit of work, at least in the case of nios2.  ideally,
it would be nice to fold that work into the basic in-tree config
process.  from a very brief perusal, it looks like it could be done
but it's definitely not a high priority item on my list.  :-)

> > > 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.

the culprit here is the file
vendors/Altera/nios2nommu/config.linux-2.6.x, which contains the
config line:

CONFIG_INITRAMFS_SOURCE="../romfs ../vendors/Altera/nios2nommu/romfs_list"

AFAICT, that forces the kernel build to *require* that romfs
directory, even if nothing is placed in it.  that's kind of annoying,
and i'll see if i can fix that.

> > > > $ 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,

i just tried that with my CVS checked out uclinux, and it knows
nothing about "single_"-prefixed targets.  how curious.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================