[Buildroot] (no subject)

[Buildroot] (no subject)

[Ulf Samuelsson]

Author:	Ulf Samuelsson
Date:	2007-01-25

Log:
	Here is my suggestion for supporting different BSP's
	in the same buildroot structure
	Add BINARIES_DIR directory, 
	where resulting binaries can be stored
	Typically this directory contains a subdirectory for each BSP.

	Add TARGET_BUILD_DIR directory, where BSP for different
	boards can be built without destroying results of previous
	builds. Typically each BSP would build in a subdirectory of 
	TARGET_BUILD_DIR

Modified:
	Config.in
	Makefile
	package/Makefile.in

Changeset
	Config.in
	Makefile
	package/Makefile.in

-------------- next part --------------
A non-text attachment was scrubbed...
Name: BSP_Support.patch
Type: text/x-patch
Size: 3404 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20070125/ac5ae11f/attachment.bin 

[Buildroot] (no subject)

[Bernhard Fischer]

On Thu, Jan 25, 2007 at 11:44:36PM +0100, Ulf Samuelsson wrote:
>Author:	Ulf Samuelsson
>Date:	2007-01-25
>
>Log:
>	Here is my suggestion for supporting different BSP's
>	in the same buildroot structure
>	Add BINARIES_DIR directory, 
>	where resulting binaries can be stored
>	Typically this directory contains a subdirectory for each BSP.
>
>	Add TARGET_BUILD_DIR directory, where BSP for different
>	boards can be built without destroying results of previous
>	builds. Typically each BSP would build in a subdirectory of 
>	TARGET_BUILD_DIR
>
>Modified:
>	Config.in
>	Makefile
>	package/Makefile.in
>
>Changeset
>	Config.in
>	Makefile
>	package/Makefile.in
>

>Author:	Ulf Samuelsson
>Date:	2007-01-25
>
>Log:
>	Here is my suggestion for supporting different BSP's
>	in the same buildroot structure
>	Add BINARIES_DIR directory, 
>	where resulting binaries can be stored
>	Typically this directory contains a subdirectory for each BSP.
>
>	Add TARGET_BUILD_DIR directory, where BSP for different
>	boards can be built without destroying results of previous builds.
>	Typically each BSP would build in a subdirectory of TARGET_BUILD_DIR
>
>Modified:
>	Config.in
>	Makefile
>	package/Makefile.in
>
>Changeset
>	Config.in
>	Makefile
>	package/Makefile.in
>
>diff -urN buildroot/Config.in buildroot-atmel/Config.in
>--- buildroot/Config.in	2007-01-25 21:58:40.000000000 +0100
>+++ buildroot-atmel/Config.in	2007-01-25 23:34:50.000000000 +0100
>@@ -2,6 +2,17 @@
> 
> mainmenu "Buildroot2 Configuration"
> 
>+config BR2_BOARDNAME
>+	string "Boardname"
>+	default "board"

That default should be ""
and specific target/*/* should set this, no?

Also, please move below HAVE_DOT_CONFIG.

>+	help
>+	  Name is used to define subdirectories
>+	  * where the Board Support Packages are built
>+	    (Linux,Root fs Bootmonitor,Utilities etc.)
>+	  * where the resulting binaries are stored.
>+	  Older target may still build in the build_<arch>
>+	  and store binaries in the top directory.
>+
> config BR2_HAVE_DOT_CONFIG
> 	bool
> 	default y
>@@ -266,6 +277,7 @@
> 	depends BR2_arm
> 	string "Atmel AT91 Linux Patch download site"
> 	default "http://maxim.org.za/AT91RM9200/2.6/"
>+	help
> 	    Patches for the AT91 generated by the Linux community
> 	    usually ends up here, courtesy of Andrew Victor
> 	    
hunk not needed anymore.

>diff -urN buildroot/Makefile buildroot-atmel/Makefile
>--- buildroot/Makefile	2007-01-25 21:05:25.000000000 +0100
>+++ buildroot-atmel/Makefile	2007-01-25 23:36:12.000000000 +0100
>@@ -76,12 +76,16 @@
> TARGETS_SOURCE:=$(patsubst %,%-source,$(TARGETS))
> TARGETS_DIRCLEAN:=$(patsubst %,%-dirclean,$(TARGETS))
> 
>-world: $(DL_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) $(TARGETS)
>+world: $(DL_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
>+	$(TARGET_BUILD_DIR) $(BINARIES_DIR) \
>+	$(TARGETS)
>+
> dirs: $(DL_DIR) $(BUILD_DIR) $(STAGING_DIR)
> 
> .PHONY: all world dirs clean dirclean distclean source $(TARGETS) \
> 	$(TARGETS_CLEAN) $(TARGETS_DIRCLEAN) $(TARGETS_SOURCE) \
>-	$(DL_DIR) $(BUILD_DIR) $(TOOL_BUILD_DIR) $(STAGING_DIR)
>+	$(DL_DIR) $(BUILD_DIR) $(TOOL_BUILD_DIR) $(STAGING_DIR) \
>+	$(TARGET_BUILD_DIR) $(BINARIES_DIR)
> 
> #############################################################
> #
>@@ -115,6 +119,12 @@
> 	-find $(TARGET_DIR) -type d -name CVS | xargs rm -rf
> 	-find $(TARGET_DIR) -type d -name .svn | xargs rm -rf
> 
>+$(TARGET_BUILD_DIR):
>+	mkdir -p $(TARGET_BUILD_DIR)
>+
>+$(BINARIES_DIR):
>+	mkdir -p $(BINARIES_DIR)
>+

an
$(DL_DIR) $(BUILD_DIR) $(TOOL_BUILD_DIR) $(STAGING_DIR) \
$(TARGET_BUILD_DIR) $(BINARIES_DIR):
	mkdir -p $@

should do, too, i'd say. We could delete the other superfluous rules
then.

> source: $(TARGETS_SOURCE)
> 
> #############################################################
>diff -urN buildroot/package/Makefile.in buildroot-atmel/package/Makefile.in
>--- buildroot/package/Makefile.in	2007-01-25 21:05:25.000000000 +0100
>+++ buildroot-atmel/package/Makefile.in	2007-01-25 23:19:11.000000000 +0100
>@@ -42,6 +42,8 @@
> BUILD_DIR:=$(BASE_DIR)/$(TOPDIR_PREFIX)build_$(ARCH)$(ARCH_FPU_SUFFIX)$(TOPDIR_SUFFIX)
> TARGET_DIR:=$(BUILD_DIR)/root
> TOOL_BUILD_DIR=$(BASE_DIR)/$(TOPDIR_PREFIX)toolchain_build_$(ARCH)$(ARCH_FPU_SUFFIX)$(TOPDIR_SUFFIX)
>+TARGET_BUILD_DIR:=$(BASE_DIR)/$(TOPDIR_PREFIX)target_build_$(ARCH)$(ARCH_FPU_SUFFIX)$(TOPDIR_SUFFIX)/$(BR2_BOARDNAME)
>+BINARIES_DIR:=$(BASE_DIR)/binaries/$(BR2_BOARDNAME)

shouldn't the BINARIES_DIR rather be only visible in targets/MAkefile.in
and below?  Just curious..

[Buildroot] BSP patch

[Ulf Samuelsson]

> On Thu, Jan 25, 2007 at 11:44:36PM +0100, Ulf Samuelsson wrote:
>>Author: Ulf Samuelsson
>>Date: 2007-01-25
>>

Bernard, Thanks for taking your time (on a Sunday)
I really appreciate it.

>>Log:
>> Here is my suggestion for supporting different BSP's
>> in the same buildroot structure
>> Add BINARIES_DIR directory, 
>> where resulting binaries can be stored
>> Typically this directory contains a subdirectory for each BSP.
>>
>> Add TARGET_BUILD_DIR directory, where BSP for different
>> boards can be built without destroying results of previous
>> builds. Typically each BSP would build in a subdirectory of 
>> TARGET_BUILD_DIR
>>
>>Modified:
>> Config.in
>> Makefile
>> package/Makefile.in
>>
>>Changeset
>> Config.in
>> Makefile
>> package/Makefile.in
>>
> 
>>Author: Ulf Samuelsson
>>Date: 2007-01-25
>>
>>Log:
>> Here is my suggestion for supporting different BSP's
>> in the same buildroot structure
>> Add BINARIES_DIR directory, 
>> where resulting binaries can be stored
>> Typically this directory contains a subdirectory for each BSP.
>>
>> Add TARGET_BUILD_DIR directory, where BSP for different
>> boards can be built without destroying results of previous builds.
>> Typically each BSP would build in a subdirectory of TARGET_BUILD_DIR
>>
>>Modified:
>> Config.in
>> Makefile
>> package/Makefile.in
>>
>>Changeset
>> Config.in
>> Makefile
>> package/Makefile.in
>>
>>diff -urN buildroot/Config.in buildroot-atmel/Config.in
>>--- buildroot/Config.in 2007-01-25 21:58:40.000000000 +0100
>>+++ buildroot-atmel/Config.in 2007-01-25 23:34:50.000000000 +0100
>>@@ -2,6 +2,17 @@
>> 
>> mainmenu "Buildroot2 Configuration"
>> 
>>+config BR2_BOARDNAME
>>+ string "Boardname"
>>+ default "board"
> 
> That default should be ""

I create a subdirectory under target_build named $(BR2_BOARDNAME)
so having it empty will try to create "target_build//<target_packages/"
which will be wrong.

I think it would be cool to set /etc/hostname to $(BR2_BOARDNAME)
(Part of the "local" patch)
so to be compatible, maybe it should default to "uclibc"?

> and specific target/*/* should set this, no?

Other way around, you define your board at the beginning
and target/$(BR2_BOARDNAME)/* is set.

This way, you can have two targets of the same type
for different customers.
I.E: you can build 

TARGET_BUILD_ARM/customer1/...
TARGET_BUILD_ARM/customer2/...

They are both using the same target information,
but you use the .config to select different options.
(maybe different Linux Kernels)

> 
> Also, please move below HAVE_DOT_CONFIG.
> 

OK.

>>+ help
>>+   Name is used to define subdirectories
>>+   * where the Board Support Packages are built
>>+     (Linux,Root fs Bootmonitor,Utilities etc.)
>>+   * where the resulting binaries are stored.
>>+   Older target may still build in the build_<arch>
>>+   and store binaries in the top directory.
>>+
>> config BR2_HAVE_DOT_CONFIG
>> bool
>> default y
>>@@ -266,6 +277,7 @@
>> depends BR2_arm
>> string "Atmel AT91 Linux Patch download site"
>> default "http://maxim.org.za/AT91RM9200/2.6/"
>>+ help
>>     Patches for the AT91 generated by the Linux community
>>     usually ends up here, courtesy of Andrew Victor
>>     
> hunk not needed anymore.
> 
>>diff -urN buildroot/Makefile buildroot-atmel/Makefile
>>--- buildroot/Makefile 2007-01-25 21:05:25.000000000 +0100
>>+++ buildroot-atmel/Makefile 2007-01-25 23:36:12.000000000 +0100
>>@@ -76,12 +76,16 @@
>> TARGETS_SOURCE:=$(patsubst %,%-source,$(TARGETS))
>> TARGETS_DIRCLEAN:=$(patsubst %,%-dirclean,$(TARGETS))
>> 
>>-world: $(DL_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) $(TARGETS)
>>+world: $(DL_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
>>+ $(TARGET_BUILD_DIR) $(BINARIES_DIR) \
>>+ $(TARGETS)
>>+
>> dirs: $(DL_DIR) $(BUILD_DIR) $(STAGING_DIR)
>> 
>> .PHONY: all world dirs clean dirclean distclean source $(TARGETS) \
>> $(TARGETS_CLEAN) $(TARGETS_DIRCLEAN) $(TARGETS_SOURCE) \
>>- $(DL_DIR) $(BUILD_DIR) $(TOOL_BUILD_DIR) $(STAGING_DIR)
>>+ $(DL_DIR) $(BUILD_DIR) $(TOOL_BUILD_DIR) $(STAGING_DIR) \
>>+ $(TARGET_BUILD_DIR) $(BINARIES_DIR)
>> 
>> #############################################################
>> #
>>@@ -115,6 +119,12 @@
>> -find $(TARGET_DIR) -type d -name CVS | xargs rm -rf
>> -find $(TARGET_DIR) -type d -name .svn | xargs rm -rf
>> 
>>+$(TARGET_BUILD_DIR):
>>+ mkdir -p $(TARGET_BUILD_DIR)
>>+
>>+$(BINARIES_DIR):
>>+ mkdir -p $(BINARIES_DIR)
>>+
> 
> an
> $(DL_DIR) $(BUILD_DIR) $(TOOL_BUILD_DIR) $(STAGING_DIR) \
> $(TARGET_BUILD_DIR) $(BINARIES_DIR):
> mkdir -p $@
> 
> should do, too, i'd say. We could delete the other superfluous rules
> then.

Yes, that makes sense!

> 
>> source: $(TARGETS_SOURCE)
>> 
>> #############################################################
>>diff -urN buildroot/package/Makefile.in buildroot-atmel/package/Makefile.in
>>--- buildroot/package/Makefile.in 2007-01-25 21:05:25.000000000 +0100
>>+++ buildroot-atmel/package/Makefile.in 2007-01-25 23:19:11.000000000 +0100
>>@@ -42,6 +42,8 @@
>> BUILD_DIR:=$(BASE_DIR)/$(TOPDIR_PREFIX)build_$(ARCH)$(ARCH_FPU_SUFFIX)$(TOPDIR_SUFFIX)
>> TARGET_DIR:=$(BUILD_DIR)/root
>> TOOL_BUILD_DIR=$(BASE_DIR)/$(TOPDIR_PREFIX)toolchain_build_$(ARCH)$(ARCH_FPU_SUFFIX)$(TOPDIR_SUFFIX)
>>+TARGET_BUILD_DIR:=$(BASE_DIR)/$(TOPDIR_PREFIX)target_build_$(ARCH)$(ARCH_FPU_SUFFIX)$(TOPDIR_SUFFIX)/$(BR2_BOARDNAME)
>>+BINARIES_DIR:=$(BASE_DIR)/binaries/$(BR2_BOARDNAME)
> 
> shouldn't the BINARIES_DIR rather be only visible in targets/Makefile.in
> and below?  Just curious..
>

BINARIES_DIR will store
linux        - built by target
u-boot     - built by target
utilities     - built by target
rootfs      - built by target

so you are right, but then I dont understand how the Makefile system works
I thought the makefile includes everything and sets all the variables
before the rules are applied.

I put in the package/Makefile.in directory , because there is where the 
other similar stuff is, and it gives you a better overview but
If you want it in the target/Makefile.in, that is no big problem.

Best Regards
Ulf Samuelsson

[Buildroot] difference between this list and gmane?

[Daniel Ng]

An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20070215/85214a79/attachment.html 

[Buildroot] difference between this list and gmane?

[Bernhard Fischer]

On Thu, Feb 15, 2007 at 07:25:23PM -0500, Daniel Ng wrote:
>Hi,
><br>

brrr. Don't send html mail.

><br>What is the difference between this list and gmane.comp.lib.uclibc.buildroot?
><br>
><br>They seem like different lists because posting my question on the gmane list did
><br>not result in the same post going to this list- I had to post to each manually.

Read gmane.com/ and
http://dir.gmane.org/gmane.comp.lib.uclibc.buildroot

><br>
><br>Also the gmane list traffic looks very one-way: lots of updates and questions, but not many answers.
><br>
><br>-whereas this list seems to have as many answers as questions....
><br>
><br>Cheers,
><br>Daniel<br/>
><div>
><hr style="width:85%;margin-left:0px;text-align:left"/><br/>
><a href="http://cinema.lycos.com/?if_Event=mail" target="_blank"><u>Free
>Movies</u></a>&nbsp;100's of Free Feature Length Films - Meet Friends, Watch
>Movies & Win!
></div>
>

[Buildroot] BSP patch

[Ulf Samuelsson]

Any chance of having the new version reviewed soon?

Best Regards
Ulf Samuelsson

[Buildroot] BSP patch

[Ulf Samuelsson]

Any chance of having this reviewed soon?
I am kinda stuck on AVR32 before that is applied.


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
link: www.avrfreaks.net 

[Buildroot] BSP patch

[Bernhard Fischer]

On Wed, Mar 21, 2007 at 11:24:32PM +0100, Ulf Samuelsson wrote:
>Any chance of having this reviewed soon?
>I am kinda stuck on AVR32 before that is applied.

There was someone on irc that had an alternative approach. He said that
he'd be in contact with you to discuss both approaches. Unfortunately
this discussion didn't end up on the list.. What was the outcome of that
discussion?

[Buildroot] BSP patch

[Ulf Samuelsson]

> On Wed, Mar 21, 2007 at 11:24:32PM +0100, Ulf Samuelsson wrote:
>>Any chance of having this reviewed soon?
>>I am kinda stuck on AVR32 before that is applied.
>
> There was someone on irc that had an alternative approach. He said that
> he'd be in contact with you to discuss both approaches. Unfortunately
> this discussion didn't end up on the list.. What was the outcome of that
> discussion?
>

I think you refer to the discussions I had with S?ren Straarup
It is actually not two approaches.

He wants an easy way to configure buildroot by having a set
of ".config" files and a way to select  *which* config file
by doing

$ make <board>-defconfig

where the defconfig files are stored in the "configs" directory.

I actually have a "configs" directory as well in my private buildroot
but I copy stuff manually to the top level.
I think that S?ren's patch is orthogonal to my work.


The BSP patch is really there to allow two different configurations
to be built within the same buildroot directory so they can share:

* toolchain
* root file system build directory.
but have different configurations for linux kernel and busybox
and eventually you may want to have different content of the root file 
system.

The solution is to create a new directory structure
target_build_<arch>/<board> where everything is built.
The patch allows pre/postfixes to this directory name.

The BSP patch also put some structure on where the result ends up.
Today everything is stored in the top directory, but if you
want to build multiple boards, then you are going to get a lot of clutter.

The BSP patch will put bootloaders, kernel and root file systems in
binaries/<board>

S?ren also would like to separate the target build from the build
of the root file system, so I think he supports this patch.


So in short, I think there is really no reason to delay either of the 
patches.

Best Regards
Ulf Samuelsson

[Buildroot] BSP patch

[Bernhard Fischer]

On Thu, Mar 22, 2007 at 12:13:59AM +0100, Ulf Samuelsson wrote:
>>On Wed, Mar 21, 2007 at 11:24:32PM +0100, Ulf Samuelsson wrote:
>>>Any chance of having this reviewed soon?
>>>I am kinda stuck on AVR32 before that is applied.
>>
>>There was someone on irc that had an alternative approach. He said that
>>he'd be in contact with you to discuss both approaches. Unfortunately
>>this discussion didn't end up on the list.. What was the outcome of that
>>discussion?
>>
>
>I think you refer to the discussions I had with S?ren Straarup
>It is actually not two approaches.

[snip]

>I actually have a "configs" directory as well in my private buildroot
>but I copy stuff manually to the top level.
>I think that S?ren's patch is orthogonal to my work.

ok.
>
>The BSP patch is really there to allow two different configurations
>to be built within the same buildroot directory so they can share:
>
>* toolchain
>* root file system build directory.
>but have different configurations for linux kernel and busybox
>and eventually you may want to have different content of the root file 
>system.
>
>The solution is to create a new directory structure
>target_build_<arch>/<board> where everything is built.
>The patch allows pre/postfixes to this directory name.
>
>The BSP patch also put some structure on where the result ends up.
>Today everything is stored in the top directory, but if you
>want to build multiple boards, then you are going to get a lot of clutter.

We need to better differentiate between arch and cpu (generally, not in
your board support patch).

Applying your patch now locally. Let's see..

[Buildroot] BSP patch

[Ulf Samuelsson]

>>The BSP patch also put some structure on where the result ends up.
>>Today everything is stored in the top directory, but if you
>>want to build multiple boards, then you are going to get a lot of clutter.
>
> We need to better differentiate between arch and cpu (generally, not in
> your board support patch).
>
> Applying your patch now locally. Let's see..
>

Thank You,

So far the patch does not create anything, only defines locations.

The beef is in the patches that follows
but I plan to submit the AVR32 toolset patches first.

The idea is to avoid keeping the toolset patches
inside the buildroot,and instead download the patches
before they are applied.

Best Regards
Ulf Samuelsson

[Buildroot] BSP patch

[Erik Andersen]

On Thu Mar 22, 2007 at 02:53:12PM +0100, Ulf Samuelsson wrote:
> 
> >>The BSP patch also put some structure on where the result ends up.
> >>Today everything is stored in the top directory, but if you
> >>want to build multiple boards, then you are going to get a lot of clutter.
> >
> > We need to better differentiate between arch and cpu (generally, not in
> > your board support patch).
> >
> > Applying your patch now locally. Let's see..
> >
> 
> Thank You,
> 
> So far the patch does not create anything, only defines locations.
> 
> The beef is in the patches that follows
> but I plan to submit the AVR32 toolset patches first.
> 
> The idea is to avoid keeping the toolset patches
> inside the buildroot,and instead download the patches
> before they are applied.

Mind sharing the the next patchset with us, so we can see where
you are going with this?  I do like the general idea and I
recognize the need to make changes such as you describe.  But I
would like to have a chance to review the actual changes you plan
to implement should this be applied...

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

[Buildroot] BSP patch

[Ulf Samuelsson]

----- Original Message ----- 
From: "Erik Andersen" <andersen@codepoet.org>
To: "Ulf Samuelsson" <ulf@atmel.com>
Cc: "Bernhard Fischer" <rep.dot.nop@gmail.com>; <buildroot@uclibc.org>
Sent: Thursday, March 22, 2007 5:40 PM
Subject: Re: [Buildroot] BSP patch


> On Thu Mar 22, 2007 at 02:53:12PM +0100, Ulf Samuelsson wrote:
>>
>> >>The BSP patch also put some structure on where the result ends up.
>> >>Today everything is stored in the top directory, but if you
>> >>want to build multiple boards, then you are going to get a lot of 
>> >>clutter.
>> >
>> > We need to better differentiate between arch and cpu (generally, not in
>> > your board support patch).
>> >
>> > Applying your patch now locally. Let's see..
>> >
>>
>> Thank You,
>>
>> So far the patch does not create anything, only defines locations.
>>
>> The beef is in the patches that follows
>> but I plan to submit the AVR32 toolset patches first.
>>
>> The idea is to avoid keeping the toolset patches
>> inside the buildroot,and instead download the patches
>> before they are applied.
>
> Mind sharing the the next patchset with us, so we can see where
> you are going with this?  I do like the general idea and I
> recognize the need to make changes such as you describe.  But I
> would like to have a chance to review the actual changes you plan
> to implement should this be applied...
>
> -Erik
>
> --


Once the structure is available in the main buildroot,
I want to add the
target/device/Atmel/<board> directories

The Atmel directory will support building board support for
AT91 (ARM9) and AVR32 chips.

I also can build
* linux
* U-Boot
* at91-bootstrap
* dataflashboot.bin
* various download utilities

My final directory structiure, after patches, would look like

configs
toolchain
target
packages
local
doc

After configuring and running "make"
the following directories will be added:

toolchain_build_arm
toolchain_build_avr32
build_arm
build_avr32

as usual but also:

target_build_dir/<board1>
target_build_dir/<board2>
binaries/<board1>
binaries/<board2>

where <board1>, <board2> is defined as contents of   $(BR2_BOARDNAME)
Note that this is separate from the board type.
If you have an AT91SAM9260EK, you should be able to build
a number of <boards> based on this platform.
Imagine a consultant which has designed a board and sells this
to 10 customers, and each customer wants to have a customized
linux kernel/u-boot/file system.
Still you want to use a common toolchain, and you do not want to
rebuild all the packages, just because you have a new configuration.
build_<arch>/packages should be reused as much as possible.

The "target_build_dir/<board>" should contain the builds of all packages
which are configurable.
Currently this is linux, u-boot and the low level boot utilities.

If it is acceptable I would like to extend that to more things.

First by moving "build_<arch>/root" to "target_build_<arch>/<board>/root.
This would allow you to have two different file systems for different 
configurations.
I am not sure buildroot of today likes that you just delete the root 
directory
and then start from scratch.
Ideally this should result in binaries in the build_<arch>/<package> 
directories
just beeing copied to the new file system.

I do not see why I should rebuild packages over and over again.
It would be better if I could build the package only once and then
reuse it for each board.

Having a unique "root" directory, is key to better functionality.

It would be good to build busybox in target_build_<arch>/<board> as well.

Lets say you have designed a board, and then you want to try out
busybox with two different configuration files.
Today you have to build the first root file system, and then after you have 
to
start from scratch. It would be much easier if you could build the busybox
separaterly for each configuration.

Basically all packages that can be configured should be in the 
target_build_<arch>/<board>

Another thing I would like to add is version support.
Just because a new fancy version is available on internet
does not mean that it is really working together with
everything else in a certain file system.
Without version support, buildroot is really a toy to get started.

What you want, as a support organisation is to have supported "releases"
This means that you want to provide info allowing someone else
to follow your exact steps to build something.
This means that you want a certain version of  "fileutils" etc.
If buildroot is in a continuos flux, then there is a big risk that
suddenly things do not work any longer.
As well as you have stable releases of busybox, support
organisations will have a need to provide a configuration file
which shows what they have tested.

This does not mean that it is bugfree, just that this is
what has been tested and can be supported by that organisation.

As for the question of sharing the patchset, I will need to update it,
The introduction of "linux.mk" really wrought havoc on by BSP.

I think next step (after supplying BSP) is really to make "linux.mk"
useful in a multiboard environment.

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
link: www.avrfreaks.net 

[Buildroot] BSP patch

[Ulf Samuelsson]

> On Thu Mar 22, 2007 at 02:53:12PM +0100, Ulf Samuelsson wrote:
>> 
>> >>The BSP patch also put some structure on where the result ends up.
>> >>Today everything is stored in the top directory, but if you
>> >>want to build multiple boards, then you are going to get a lot of clutter.
>> >
>> > We need to better differentiate between arch and cpu (generally, not in
>> > your board support patch).
>> >
>> > Applying your patch now locally. Let's see..
>> >
>> 
>> Thank You,
>> 
>> So far the patch does not create anything, only defines locations.
>> 
>> The beef is in the patches that follows
>> but I plan to submit the AVR32 toolset patches first.
>> 
>> The idea is to avoid keeping the toolset patches
>> inside the buildroot,and instead download the patches
>> before they are applied.
> 
> Mind sharing the the next patchset with us, so we can see where
> you are going with this?  I do like the general idea and I
> recognize the need to make changes such as you describe.  But I
> would like to have a chance to review the actual changes you plan
> to implement should this be applied...
> 
> -Erik

I did send you my preliminary buildroot quite some time ago,
and published a script which downloads and build buildroot 
one week ago.

This new script will build the following board:
* at91rm9200df,  at91sam9260dfc, at91sam9261ek, at91sam9263ek
(Fragments of avr32 support is there but not tested lately)

Except for the root file system (in ext2/jffs2) it also builds:

* linux-2.6.20.4    now defined in target/linux/Config.in; Makefile.in
* u-boot-1.2.0
* at91bootstrap-2.3
* datflashboot-1.05

everything "configurable" or board dependent builds in the 

target_build_$BR2_ARCH)/$(BR2_HOSTNAME)

(Linux/U-boot/Busybox/root/at91bootstrap/dataflashboot)

and results are published in

binaries/$(BR2_HOSTNAME)

Note that BR2_HOSTNAME is used instead of BR2_BOARD_NAME
since they refer to two different things.
You can build several versions of the same board so 
you can have several .config files with a common BR2_BOARD_NAME
but BR2_HOSTNAME differs.

What else is required to move on ?


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                ftp://at91dist:distrib at 81.80.104.162/

[Buildroot] BSP patch

[Ulf Samuelsson]

[snip]

>>The BSP patch is really there to allow two different configurations
>>to be built within the same buildroot directory so they can share:
>>
>>* toolchain
>>* root file system build directory.
>>but have different configurations for linux kernel and busybox
>>and eventually you may want to have different content of the root file
>>system.
>>
>>The solution is to create a new directory structure
>>target_build_<arch>/<board> where everything is built.
>>The patch allows pre/postfixes to this directory name.
>>
>>The BSP patch also put some structure on where the result ends up.
>>Today everything is stored in the top directory, but if you
>>want to build multiple boards, then you are going to get a lot of clutter.
>
> We need to better differentiate between arch and cpu (generally, not in
> your board support patch).
>
> Applying your patch now locally. Let's see..
>

Any progress?


Best Regards
Ulf Samuelsson

[Buildroot] BSP patch

[Bernhard Fischer]

On Thu, Mar 29, 2007 at 12:30:43PM +0200, Ulf Samuelsson wrote:
>[snip]
>
>>>The BSP patch is really there to allow two different configurations
>>>to be built within the same buildroot directory so they can share:
>>>
>>>* toolchain
>>>* root file system build directory.
>>>but have different configurations for linux kernel and busybox
>>>and eventually you may want to have different content of the root file
>>>system.
>>>
>>>The solution is to create a new directory structure
>>>target_build_<arch>/<board> where everything is built.
>>>The patch allows pre/postfixes to this directory name.
>>>
>>>The BSP patch also put some structure on where the result ends up.
>>>Today everything is stored in the top directory, but if you
>>>want to build multiple boards, then you are going to get a lot of clutter.
>>
>>We need to better differentiate between arch and cpu (generally, not in
>>your board support patch).
>>
>>Applying your patch now locally. Let's see..
>>
>
>Any progress?

[I've just replied to you to a privately sent message, fwiw]

random remarks:
avr32_binutils/toolchain_binutils_binutils.mk.patch
There is already a BR2_ATMEL_MIRROR in the toplevel Config.in, use that
instead.


avr32_binutils/toolchain_binutils_Config.in.patch
I won't comment on you using a deprecated version of binutils (current
release is 2.17).
Please put the !avr32 next to !nios, i.e. before the DEPRECATED.


avr32_kernel_headers/toolchain_kernel-headers_Config.in.patch
I won't comment on you using an old kernel.
Please put the !avr32 before the DEPRECATED


avr32_gcc/toolchain_gcc_Config.in.patch
Please put the !avr32 before the DEPRECATED


avr32_gcc/toolchain_gcc_4.0.2_gcc-4.0.2-atmel.0.99.2.patch.patch
4.0.2 is deprecated. The current stable release is 4.1.2, 4.0.4 was the
last release of 4.0 so far.
There are lots of changes due to RCS IDs in this patch, please drop those
parts.

[Buildroot] BSP patch

[Ulf Samuelsson]

----- Original Message ----- 
From: "Bernhard Fischer" <rep.dot.nop@gmail.com>
To: "Ulf Samuelsson" <ulf@atmel.com>
Cc: <buildroot@uclibc.org>
Sent: Tuesday, April 10, 2007 2:18 PM
Subject: Re: [Buildroot] BSP patch


> On Thu, Mar 29, 2007 at 12:30:43PM +0200, Ulf Samuelsson wrote:
>>[snip]
>>
>>>>The BSP patch is really there to allow two different configurations
>>>>to be built within the same buildroot directory so they can share:
>>>>
>>>>* toolchain
>>>>* root file system build directory.
>>>>but have different configurations for linux kernel and busybox
>>>>and eventually you may want to have different content of the root file
>>>>system.
>>>>
>>>>The solution is to create a new directory structure
>>>>target_build_<arch>/<board> where everything is built.
>>>>The patch allows pre/postfixes to this directory name.
>>>>
>>>>The BSP patch also put some structure on where the result ends up.
>>>>Today everything is stored in the top directory, but if you
>>>>want to build multiple boards, then you are going to get a lot of clutter.
>>>
>>>We need to better differentiate between arch and cpu (generally, not in
>>>your board support patch).
>>>
>>>Applying your patch now locally. Let's see..
>>>
>>
>>Any progress?
> 
> [I've just replied to you to a privately sent message, fwiw]
> 
> random remarks:
> avr32_binutils/toolchain_binutils_binutils.mk.patch
> There is already a BR2_ATMEL_MIRROR in the toplevel Config.in, use that
> instead.

OK.

> 
> avr32_binutils/toolchain_binutils_Config.in.patch
> I won't comment on you using a deprecated version of binutils (current
> release is 2.17).
> Please put the !avr32 next to !nios, i.e. before the DEPRECATED.
> 
> 
> avr32_kernel_headers/toolchain_kernel-headers_Config.in.patch
> I won't comment on you using an old kernel.
> Please put the !avr32 before the DEPRECATED
> 
> 
> avr32_gcc/toolchain_gcc_Config.in.patch
> Please put the !avr32 before the DEPRECATED
> 
> 
> avr32_gcc/toolchain_gcc_4.0.2_gcc-4.0.2-atmel.0.99.2.patch.patch
> 4.0.2 is deprecated. The current stable release is 4.1.2, 4.0.4 was the
> last release of 4.0 so far.

I know, you told me before.
And does not contain any AVR32 patches.
Everyone using the AVR32 will have to live with the 4.0.1 release
until the AVR32 team provides an updated compiler.
The only viable alternative is to not provide AVR32 support at all in buildroot.

> There are lots of changes due to RCS IDs in this patch, please drop those
> parts.

The main drwaback of that is Size, I guess.
My plan is to let buildroot download the patches instead of storing them
inside the mainstream buildroot tarball.
I have not generated those patches, and will not be able to test any modifications.

> 
> 

As mentioned in the other mail.
These things are just for your reference to show where I am going
and not official patch submissions.
Need to establish the framework first with the BSP patch and then
I will send in "clean" patches for submission later.

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

[Buildroot] BSP patch

[Haavard Skinnemoen]

On Tue, 10 Apr 2007 15:22:38 +0200
"Ulf Samuelsson" <ulf@atmel.com> wrote:

> > avr32_gcc/toolchain_gcc_4.0.2_gcc-4.0.2-atmel.0.99.2.patch.patch
> > 4.0.2 is deprecated. The current stable release is 4.1.2, 4.0.4 was the
> > last release of 4.0 so far.  
> 
> I know, you told me before.
> And does not contain any AVR32 patches.
> Everyone using the AVR32 will have to live with the 4.0.1 release
> until the AVR32 team provides an updated compiler.
> The only viable alternative is to not provide AVR32 support at all in buildroot.

We're currently testing binutils-2.17 and gcc-4.1.2 on avr32. I'll let
you know when we're confident that it's working properly, but at least
binutils seems to be working fine (I haven't gotten around to test gcc
myself yet.)

In the long term, we want to get support for avr32 upstream, but it
will probably take a while before we get everything sorted out.

In the mean time, you might want to check out the patches I've put up
at http://avr32linux.org/twiki/bin/view/Main/DevelopmentTools for
binutils 2.17 and gcc 4.0.4. Those are the patches I used to generate
the filesystem I'm currently using on my test system (using buildroot.)

Haavard

[Buildroot] BSP patch

[Ulf Samuelsson]

> On Wed, Mar 21, 2007 at 11:24:32PM +0100, Ulf Samuelsson wrote:
>>Any chance of having this reviewed soon?
>>I am kinda stuck on AVR32 before that is applied.
>
> There was someone on irc that had an alternative approach. He said that
> he'd be in contact with you to discuss both approaches. Unfortunately
> this discussion didn't end up on the list.. What was the outcome of that
> discussion?
>

I think you refer to the discussions I had with S?ren Straarup
It is actually not two approaches.

He wants an easy way to configure buildroot by having a set
of ".config" files and a way to select  *which* config file
by doing

$ make <board>-defconfig

where the defconfig files are stored in the "configs" directory.

I actually have a "configs" directory as well in my private buildroot
but I copy stuff manually to the top level.
I think that S?ren's patch is orthogonal to my work.


The BSP patch is really there to allow two different configurations
to be built within the same buildroot directory so they can share:

* toolchain
* root file system build directory.
but have different configurations for linux kernel and busybox
and eventually you may want to have different content of the root file
system.

The solution is to create a new directory structure
target_build_<arch>/<board> where everything is built.
The patch allows pre/postfixes to this directory name.

When I have time, I would like to be able to download kernel patches
to this directory instead of storing the patch in the target directory.

The current linux.mk is very limited in functionality and forces
duplication of the linux patch for each board.
I do not see why the same patch (size > 1 MB) should be stored 10 times
just because I have 10 boards.

The BSP patch also put some structure on where the result ends up.
Today everything is stored in the top directory, but if you
want to build multiple boards, then you are going to get a lot of clutter.

The BSP patch will put bootloaders, kernel and root file systems in
binaries/<board>

S?ren also would like to separate the target build from the build
of the root file system, so I think he supports this patch.



So in short, I think there is really no reason to delay either of the
patches.



Best Regards
Ulf Samuelsson

[Buildroot] BSP patch

[Erik Andersen]

On Thu Mar 22, 2007 at 12:16:51AM +0100, Ulf Samuelsson wrote:
> He wants an easy way to configure buildroot by having a set
> of ".config" files and a way to select  *which* config file
> by doing
> 
> $ make <board>-defconfig
> 
> where the defconfig files are stored in the "configs" directory.

A reasonable thing I suppose.

> I actually have a "configs" directory as well in my private buildroot
> but I copy stuff manually to the top level.
> I think that S?ren's patch is orthogonal to my work.
> 
> 
> The BSP patch is really there to allow two different configurations
> to be built within the same buildroot directory so they can share:
> 
> * toolchain
> * root file system build directory.
> but have different configurations for linux kernel and busybox
> and eventually you may want to have different content of the root file
> system.

I agree this is a desirable thing for many situations.

> The solution is to create a new directory structure
> target_build_<arch>/<board> where everything is built.
> The patch allows pre/postfixes to this directory name.

Ok

> When I have time, I would like to be able to download kernel patches
> to this directory instead of storing the patch in the target directory.
> 
> The current linux.mk is very limited in functionality and forces
> duplication of the linux patch for each board.

I agree.  It works, but this is a rather annoying limitation.
When a company has i.e. PRODUCT20, PRODUCT21, PRODUCT22, etc,
there is no easy way to build for all of them without doing a
lot of needless duplication.

> I do not see why the same patch (size > 1 MB) should be stored 10 times
> just because I have 10 boards.

Yes, this is a weakness that should be addressed.

> The BSP patch also put some structure on where the result ends up.
> Today everything is stored in the top directory, but if you
> want to build multiple boards, then you are going to get a lot of clutter.
> 
> The BSP patch will put bootloaders, kernel and root file systems in
> binaries/<board>
> 
> S?ren also would like to separate the target build from the build
> of the root file system, so I think he supports this patch.
> 
> 
> 
> So in short, I think there is really no reason to delay either of the
> patches.

Ok.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

[Buildroot] BSP patch

[Ulf Samuelsson]

Any one able to comment
on the latest reincarnation?.


Best Regards,
Ulf Samuelsson