Skip to contentSkip to conversation

version bumps needed for few packages

Buildroot Hebbar 3 participants 5 messages Dec 5, 2007

lore
Share & tools
lore

Hebbar

author
#0 lore raw

Hi all,

Below are the latest version that i tried and which are working fine at my end on arm926ejs eabi toolchain

udev
UDEV_VERSION:=117
UDEV_VOLUME_ID_AGE:=81

usbutils
USBUTILS_VERSION:=0.73

Also just a small request. is it possible to add/enable ts_test util inside ts_lib package

             cp -dpf $(STAGING_DIR)/usr/bin/ts_test $(TARGET_DIR)/usr/bin/
	-$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/bin/ts_test

Regards
Gururaja

Signature · 2 lines
View this message in context: http://www.nabble.com/version-bumps-needed-for-few-packages-tf4947498.html#a14165382
Sent from the BuildRoot mailing list archive at Nabble.com.
#1 lore raw

[Buildroot] Placement of custom module-building in buildroot procedure

Hello -

I've searched the archives for this last year and
couldn't find an answer so I appeal to your good humor in guiding me... I'm using buildroot/busybox 1.01/linux 2.6.18 ported for MIPS provided by PMC-Sierra.

I'm trying to add another module (dev driver
specifically) to the build. Do I need to specifically add my module into a config file under the linux tree, or is it good enough to call the "make M=$(MYSRCDIR) -C $(KERNELDIR) modules" on my own, within my own Makefile, (i.e. along with the build of my applications/libraries) that is included as a separate package in the buildroot process?

I presume perhaps I can't call 'modules' on my own
[during the kernel build] since it needs to be called following all the other modules being built in the linux kernel build - is this correct? If this is true, what't the authoratative buildroot file I add reference to my module so it gets built as the last module?

My module need not start-up at boot, I was going to
insmod-it in the rc.local script - is this conventional?

Thanks
Sean Parker

P.S. Does anyone know of a resource I could look at to learn the fundamentals of how the Linux build runs, especially the use of the "obj-y obj-m" stuff? I'm a relative Make novice, and would like to understand that better.

God Bless

    Sean Parker 





      ____________________________________________________________________________________

Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

#2 lore raw

[Buildroot] Placement of custom module-building in buildroot procedure

OK - I' starting to answer my own question:

Quoted 7 lines

P.S. Does anyone know of a resource I could look at to learn the fundamentals of how the Linux build runs, especially the use of the "obj-y obj-m" stuff? I'm a relative Make novice, and would like to understand that better.

.. by looking in Documentation/kbuild/makefiles.txt ...

Any help with conventions of when to insmod a module in an
embedded system would be appreciated...

Thanks

    Sean Parker


      ____________________________________________________________________________________

Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

#3 lore raw

[Buildroot] Placement of custom module-building in buildrootprocedure

In reply to Sean Parker
Quoted 8 lines

Hello -

I've searched the archives for this last year and
couldn't find an answer so I appeal to your good humor in guiding me... I'm using buildroot/busybox 1.01/linux 2.6.18 ported for MIPS provided by PMC-Sierra.

Quoted 8 lines

I'm trying to add another module (dev driver
specifically) to the build. Do I need to specifically add my module into a config file under the linux tree, or is it good enough to call the "make M=$(MYSRCDIR) -C $(KERNELDIR) modules" on my own, within my own Makefile, (i.e. along with the build of my applications/libraries) that is included as a separate package in the buildroot process?

You should develop your linux driver separate from buildroot, and then generate a patch.
By using the advanced linux configuration you can supply a path to the patch, and when linux is decompressed, your patch will be applied to the linux source tree.

By giving the command:

$ make configured

you will stop the build before anything is compiled.
Go into the linux source directory in $(PROJECT_BUILD_DIR) and do

$ make ARCH=mips xconfig.

Save the configuration and ensure that the .config is available somewhere in the buildroot tree and that LINUX26_KCONFIG is the path to the file.

One way of doing this automatically is to do

make saveconfig

This will store your configuration files under "local/<project>".

Quoted 23 lines

I presume perhaps I can't call 'modules' on my own
[during the kernel build] since it needs to be called following all the other modules being built in the linux kernel build - is this correct? If this is true, what't the authoratative buildroot file I add reference to my module so it gets built as the last module?

My module need not start-up at boot, I was going to
insmod-it in the rc.local script - is this conventional?

Thanks
Sean Parker

P.S. Does anyone know of a resource I could look at to learn the fundamentals of how the Linux build runs, especially the use of the "obj-y obj-m" stuff? I'm a relative Make novice, and would like to understand that better.

Quoted 3 lines

God Bless
Sean Parker

Best Regards
Ulf Samuelsson

#4 lore raw

[Buildroot] Placement of custom module-building in buildrootprocedure

Ulf -

Thanks so much for your reply.

It's difficult moving from the application-development
world
to the embedded world where kernel issues become prevalant -
please bear with my ignorance...

Quoted 2 lines

You should develop your linux driver separate from
buildroot, and then generate a patch.

I've started by moving my code to the linux tree, say under:

$(KDIR)/drivers/mymod
|
+ mymod.c
|
+ Makefile <- includes obj-m+=mymod.o

Of course then I do have to edit $(KDIR)/drivers/Makefile to include "mymod/" as a subdir

Quoted 3 lines

By using the advanced linux configuration you can supply a path to the patch, and when linux is decompressed, your patch will be applied to the linux source tree.

How do I make a patch to the linux kernel? (I thought the patch
process needed some reference tree in order to know "what's different")

However, I do see how a patch is the best solution to leaving the distro-linux package untouched. At what point in the
buildroot process/structure do I indicate I have a patch? I do have other application code I'm including in my project
as a separate package to the buildroot structure - can I put the
patch reference in my <my_proj>.mk file? (the one placed under
buildroot/packages/<my_proj>)

Quoted 6 lines

By giving the command:

$ make configured

you will stop the build before anything is compiled. Go into the linux source directory in

$(PROJECT_BUILD_DIR)

Quoted 7 lines

and do

$ make ARCH=mips xconfig.

Save the configuration and ensure that the .config is available somewhere in the buildroot tree and that LINUX26_KCONFIG is the path to the file.

I'm just leaving $(KDIR)/.config alone for now - if I make mymod "always" I shouldn't need to mees with this should I?

Otherwise, I'm saving the various buildroot/busybox config files
off in my own location, and overwriting the vendor versions when I do a clean build, that way I preserve my own copies while
being able to reinstall the vender version cleanly also (without the
extra make menuconfig step every time).

Quoted 4 lines

One way of doing this automatically is to do
make saveconfig

This will store your configuration files under

"local/<project>".

Quoted 1 line

How does it know, unless I tell it to save it somewhere else? It sounds like
you're saying it'll know about my project just by doing the

make xconfig, but I don't understand how it gets in there without
me editing a config file otherwise...

<snip my stuff>

Quoted 2 lines

Best Regards
Ulf Samuelsson

I guess the main confusion here [with me] is the distinction between
"kernel-" vs. "external-" modules, and the orthogonal ideas of
"cross-compiling" and "adding modules to a local running kernel."

for example:

            X-compile             pre-built
                                   kernel
         -----------------------------------------
         |                     |
 kernel  |  use obj-y          | compile a module
  mod    |  in kbuild file     | and re-make linux 
         |  within buildroot   | kernel
         |  context            |
         |                     |
         -----------------------------------------
         |                     |
 external|  as buildroot pkg   |
  mod    |  refer to code      |
         |  outside of context | compile a module and
         |  of linux tree ??? -| do insmod straight-away
         |  or do a patch to   | to load it for this 
         |  hack it in         | session only
         |                     |
         -----------------------------------------

Does this make sense? Please correct my understanding...

The documentation I suppose takes for granted that these are clearly
defined contexts in anyone's discussion of the issues - and thus the need
for newbies to constantly ask the same questions - i.e. "how do I add a module?"

Thanks for your time and effort
Sean Parker

God Bless

    Sean Parker 





      ____________________________________________________________________________________

Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping