[Buildroot] Target support for Atmel ARM/AVR32

[Buildroot] Target support for Atmel ARM/AVR32

[Ulf Samuelsson]

I am hoping to add Target support for a number of Atmel Development board,
but before I do that, I would like to discuss how this is done.

Would like to separate building the root file system from other utilities,
since the "build_<arch>" directory is overcrowded.

Currently I am using a "target_build_<arch>" directory.
In this directory, I create a subdirectory for each target_board.

I.E:
buildroot/target_build_arm
        at91rm9200dk
        at91rm9200df
        at91rm9200ek
        at91sam9260ek
        at91sam9261ek
        at91sam9262ek
or 
buildroot/target_build_avr32
        atstk1002

In the target_build_<arch>/<target_board> directory
I download patches for Linux/U-Boot before I apply them
and then build 
* Bootstrap
* U-Boot
* Linux
* Other Utitlties 
in that directory.

The results are renamed to show <target_board> and date.

Would like to move "buildroot/build_<arch>/root" to
"buildroot/target_build_<arch>/<target_board>/root" as well,
but have not yet gotten this to work.
(This will allow me to have different contents for different boards)

At the end, the result is moved to "buildroot/binaries/<target_board>"
so that I have easy way to create a delivery by just compressing
that directory into a tarball.

Does this seem to be a reasonable approach?

Best Regards,
Ulf Samuelsson
ulf at atmel.com
GSM:  +46 (706) 22 44 57
Tel:     +46  (8) 441 54 22
Fax:     +46 (8) 441 54 29
Mail: Box 2033  174 02 Sundbyberg
Visit: Kavalleriv?gen 24
          174 58 Sundbyberg'
Sweden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20070124/edc5a8b4/attachment.html 

[Buildroot] Target support for Atmel ARM/AVR32

[Bernhard Fischer]

On Wed, Jan 24, 2007 at 12:06:31PM +0100, Ulf Samuelsson wrote:
>I am hoping to add Target support for a number of Atmel Development board,
>but before I do that, I would like to discuss how this is done.
>
>Would like to separate building the root file system from other utilities,
>since the "build_<arch>" directory is overcrowded.
>
>Currently I am using a "target_build_<arch>" directory.
>In this directory, I create a subdirectory for each target_board.
>
>I.E:
>buildroot/target_build_arm
>        at91rm9200dk
>        at91rm9200df
>        at91rm9200ek
>        at91sam9260ek
>        at91sam9261ek
>        at91sam9262ek
>or 
>buildroot/target_build_avr32
>        atstk1002
>
>In the target_build_<arch>/<target_board> directory
>I download patches for Linux/U-Boot before I apply them
>and then build 
>* Bootstrap
>* U-Boot
>* Linux
>* Other Utitlties 
>in that directory.
>
>The results are renamed to show <target_board> and date.
>
>Would like to move "buildroot/build_<arch>/root" to
>"buildroot/target_build_<arch>/<target_board>/root" as well,
>but have not yet gotten this to work.
>(This will allow me to have different contents for different boards)
>
>At the end, the result is moved to "buildroot/binaries/<target_board>"
>so that I have easy way to create a delivery by just compressing
>that directory into a tarball.
>
>Does this seem to be a reasonable approach?

Building out of tree would make this alot easier and less complicated,
IMO.

$ svn co proto://buildroot /space/src/buildroot
$ mkdir -p /space/obj/board{1,2,3}
$ cd /space/obj/board1
$ make -f ../../src/buildroot HOSTCC="my-gcc" DL_DIR=/space/down

where picking up the DL_DIR from the user is not currently supported.
Not sure if we want that.
Index: package/Makefile.in
===================================================================
--- package/Makefile.in	(revision 17510)
+++ package/Makefile.in	(working copy)
@@ -33,8 +33,12 @@
 TOPDIR_SUFFIX:=
 endif
 
+ifndef DL_DIR
 DL_DIR=$(strip $(subst ",, $(BR2_DL_DIR)))
 #"))
+else
+$(warning "Using DL_DIR from environment and not from .config")
+endif
 ifeq ($(DL_DIR),)
 DL_DIR:=$(BASE_DIR)/dl
 endif

[Buildroot] Target support for Atmel ARM/AVR32

[Ulf Samuelsson]

Bernhard Fischer wrote:
> On Wed, Jan 24, 2007 at 12:06:31PM +0100, Ulf Samuelsson wrote:
>> I am hoping to add Target support for a number of Atmel Development
>> board, but before I do that, I would like to discuss how this is
>> done.
>>
>> Would like to separate building the root file system from other
>> utilities, since the "build_<arch>" directory is overcrowded.
>>
>> Currently I am using a "target_build_<arch>" directory.
>> In this directory, I create a subdirectory for each target_board.
>>
>> I.E:
>> buildroot/target_build_arm
>>        at91rm9200dk
>>        at91rm9200df
>>        at91rm9200ek
>>        at91sam9260ek
>>        at91sam9261ek
>>        at91sam9262ek
>> or
>> buildroot/target_build_avr32
>>        atstk1002
>>
>> In the target_build_<arch>/<target_board> directory
>> I download patches for Linux/U-Boot before I apply them
>> and then build
>> * Bootstrap
>> * U-Boot
>> * Linux
>> * Other Utitlties
>> in that directory.
>>
>> The results are renamed to show <target_board> and date.
>>
>> Would like to move "buildroot/build_<arch>/root" to
>> "buildroot/target_build_<arch>/<target_board>/root" as well,
>> but have not yet gotten this to work.
>> (This will allow me to have different contents for different boards)
>>
>> At the end, the result is moved to
>> "buildroot/binaries/<target_board>"
>> so that I have easy way to create a delivery by just compressing
>> that directory into a tarball.
>>
>> Does this seem to be a reasonable approach?
>
> Building out of tree would make this alot easier and less complicated,
> IMO.
>

No, I already have it working except for building the build_<arch>/root 
inside.

My goal is to have people download the buildroot source,
then copy a .config file to the topdir and type "make".
Then everything should work without surprises.

"Grand-Ma" should be able to do it!

Many people that will uses this will be complete new to Linux and
the thing below looks dangerous if you want to avoid support phone calls.

The question is really, will a patch be rejected if it is built up as above?


> $ svn co proto://buildroot /space/src/buildroot
> $ mkdir -p /space/obj/board{1,2,3}
> $ cd /space/obj/board1
> $ make -f ../../src/buildroot HOSTCC="my-gcc" DL_DIR=/space/down
>
> where picking up the DL_DIR from the user is not currently supported.
> Not sure if we want that.
> Index: package/Makefile.in
> ===================================================================
> --- package/Makefile.in (revision 17510)
> +++ package/Makefile.in (working copy)
> @@ -33,8 +33,12 @@
> TOPDIR_SUFFIX:=
> endif
>
> +ifndef DL_DIR
> DL_DIR=$(strip $(subst ",, $(BR2_DL_DIR)))
> #"))
> +else
> +$(warning "Using DL_DIR from environment and not from .config")
> +endif
> ifeq ($(DL_DIR),)
> DL_DIR:=$(BASE_DIR)/dl
> endif
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

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

[Buildroot] Target support for Atmel ARM/AVR32

[Bernhard Fischer]

On Thu, Jan 25, 2007 at 12:58:57AM +0100, Ulf Samuelsson wrote:
>Bernhard Fischer wrote:
>>On Wed, Jan 24, 2007 at 12:06:31PM +0100, Ulf Samuelsson wrote:
>>>I am hoping to add Target support for a number of Atmel Development
>>>board, but before I do that, I would like to discuss how this is
>>>done.
>>>
>>>Would like to separate building the root file system from other
>>>utilities, since the "build_<arch>" directory is overcrowded.
>>>
>>>Currently I am using a "target_build_<arch>" directory.
>>>In this directory, I create a subdirectory for each target_board.
>>>
>>>I.E:
>>>buildroot/target_build_arm
>>>       at91rm9200dk
>>>       at91rm9200df
>>>       at91rm9200ek
>>>       at91sam9260ek
>>>       at91sam9261ek
>>>       at91sam9262ek
>>>or
>>>buildroot/target_build_avr32
>>>       atstk1002
>>>
>>>In the target_build_<arch>/<target_board> directory
>>>I download patches for Linux/U-Boot before I apply them
>>>and then build
>>>* Bootstrap
>>>* U-Boot
>>>* Linux
>>>* Other Utitlties
>>>in that directory.
>>>
>>>The results are renamed to show <target_board> and date.
>>>
>>>Would like to move "buildroot/build_<arch>/root" to
>>>"buildroot/target_build_<arch>/<target_board>/root" as well,
>>>but have not yet gotten this to work.
>>>(This will allow me to have different contents for different boards)
>>>
>>>At the end, the result is moved to
>>>"buildroot/binaries/<target_board>"
>>>so that I have easy way to create a delivery by just compressing
>>>that directory into a tarball.
>>>
>>>Does this seem to be a reasonable approach?
[snip]
>My goal is to have people download the buildroot source,
>then copy a .config file to the topdir and type "make".
>Then everything should work without surprises.
>
>"Grand-Ma" should be able to do it!
>
>Many people that will uses this will be complete new to Linux and
>the thing below looks dangerous if you want to avoid support phone calls.
>
>The question is really, will a patch be rejected if it is built up as above?

If the TODO that is mentioned in r17516 would be fixed, would that help
that problem in any way? I, personally, don't use the concept of a board
in the context of buildroot. Put that aside, what about this layout:
-) toolchain_<arch>_<subarch>_<cpu>
-) same for build_
-) board_<device> as default COPY_TO

where
	$device is target/device/*
	$arch would be generic arch e.g. i386, arm
	$subarch is the real -march=
	$cpu is the real -mtune=

Opinions?

PS: r17516 was, for your convenience:
http://uclibc.org/cgi-bin/viewcvs.cgi?rev=17516&view=rev

[Buildroot] Target support for Atmel ARM/AVR32

[Ulf Samuelsson]

Bernhard Fischer wrote:
> On Thu, Jan 25, 2007 at 12:58:57AM +0100, Ulf Samuelsson wrote:
>> Bernhard Fischer wrote:
>>> On Wed, Jan 24, 2007 at 12:06:31PM +0100, Ulf Samuelsson wrote:
>>>> I am hoping to add Target support for a number of Atmel Development
>>>> board, but before I do that, I would like to discuss how this is
>>>> done.
>>>>
>>>> Would like to separate building the root file system from other
>>>> utilities, since the "build_<arch>" directory is overcrowded.
>>>>
>>>> Currently I am using a "target_build_<arch>" directory.
>>>> In this directory, I create a subdirectory for each target_board.
>>>>
>>>> I.E:
>>>> buildroot/target_build_arm
>>>>       at91rm9200dk
>>>>       at91rm9200df
>>>>       at91rm9200ek
>>>>       at91sam9260ek
>>>>       at91sam9261ek
>>>>       at91sam9262ek
>>>> or
>>>> buildroot/target_build_avr32
>>>>       atstk1002
>>>>
>>>> In the target_build_<arch>/<target_board> directory
>>>> I download patches for Linux/U-Boot before I apply them
>>>> and then build
>>>> * Bootstrap
>>>> * U-Boot
>>>> * Linux
>>>> * Other Utitlties
>>>> in that directory.
>>>>
>>>> The results are renamed to show <target_board> and date.
>>>>
>>>> Would like to move "buildroot/build_<arch>/root" to
>>>> "buildroot/target_build_<arch>/<target_board>/root" as well,
>>>> but have not yet gotten this to work.
>>>> (This will allow me to have different contents for different
>>>> boards)
>>>>
>>>> At the end, the result is moved to
>>>> "buildroot/binaries/<target_board>"
>>>> so that I have easy way to create a delivery by just compressing
>>>> that directory into a tarball.
>>>>
>>>> Does this seem to be a reasonable approach?
> [snip]
>> My goal is to have people download the buildroot source,
>> then copy a .config file to the topdir and type "make".
>> Then everything should work without surprises.
>>
>> "Grand-Ma" should be able to do it!
>>
>> Many people that will uses this will be complete new to Linux and
>> the thing below looks dangerous if you want to avoid support phone
>> calls.
>>
>> The question is really, will a patch be rejected if it is built up
>> as above?
>
> If the TODO that is mentioned in r17516 would be fixed, would that
> help that problem in any way? I, personally, don't use the concept of
> a board in the context of buildroot. Put that aside, what about this
> layout:
> -) toolchain_<arch>_<subarch>_<cpu>
> -) same for build_
> -) board_<device> as default COPY_TO
>
> where
> $device is target/device/*
> $arch would be generic arch e.g. i386, arm
> $subarch is the real -march=
> $cpu is the real -mtune=
>
> Opinions?

That is a different problem.
I can either build an ARM based buildroot or an AVR32 based buildroot.
They will build in: build_arm and build_avr32, same for toolchain.

My problem is that I want to build for
AT91RM9200DK    -ARM920T
AT91RM9200DF     -ARM920T
AT91RM9200EK     -ARM920T
AT91SAM9260EK  -ARM926EJS
AT91SAM9261EK  -ARM926EJS
AT91SAM9263EK  -ARM926EJS
AT91SAM9XEEK   -ARM926EJS
using a common toolchain
(The toolchain is generic arm, even though I use different CPU cores)
and maybe a common root file system (today it is).

This means that
* 7 different Linux versions,
* 7 different U-boot
* 7 different bootstraps.
Possibly, the root file system should be populated differently.

When I have built a board, I want to have all binaries stored
in one place which can be easily compressed into a tarball.

Your suggestion is more for building different toolchains for different 
boards
but this is not the case.

It is a big bonus, If I do not have to recompile the root file system
packages, just because I build support for a new board.

>
> PS: r17516 was, for your convenience:
> http://uclibc.org/cgi-bin/viewcvs.cgi?rev=17516&view=rev
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

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

[Buildroot] Target support for Atmel ARM/AVR32

[Bernhard Fischer]

On Thu, Jan 25, 2007 at 01:42:20PM +0100, Ulf Samuelsson wrote:
>Bernhard Fischer wrote:

>>If the TODO that is mentioned in r17516 would be fixed, would that
>>help that problem in any way? I, personally, don't use the concept of
>>a board in the context of buildroot. Put that aside, what about this
>>layout:
>>-) toolchain_<arch>_<subarch>_<cpu>
>>-) same for build_
>>-) board_<device> as default COPY_TO
>>
>>where
>>$device is target/device/*
>>$arch would be generic arch e.g. i386, arm
>>$subarch is the real -march=
>>$cpu is the real -mtune=
>>
>>Opinions?
>
>That is a different problem.
>I can either build an ARM based buildroot or an AVR32 based buildroot.
>They will build in: build_arm and build_avr32, same for toolchain.
>
>My problem is that I want to build for
>AT91RM9200DK    -ARM920T
>AT91RM9200DF     -ARM920T
>AT91RM9200EK     -ARM920T
>AT91SAM9260EK  -ARM926EJS
>AT91SAM9261EK  -ARM926EJS
>AT91SAM9263EK  -ARM926EJS
>AT91SAM9XEEK   -ARM926EJS
>using a common toolchain
>(The toolchain is generic arm, even though I use different CPU cores)
>and maybe a common root file system (today it is).
>
>This means that
>* 7 different Linux versions,
>* 7 different U-boot
>* 7 different bootstraps.
>Possibly, the root file system should be populated differently.
>
>When I have built a board, I want to have all binaries stored
>in one place which can be easily compressed into a tarball.
>
>Your suggestion is more for building different toolchains for different 
>boards
>but this is not the case.

My suggestion is to build two toolchains (assuming that ARM920T !=
ARM926EJS, if it is the same, then it's only one toolchain) and use that
to populate the board_{AT91*} dirs
>
>It is a big bonus, If I do not have to recompile the root file system
>packages, just because I build support for a new board.

What i wrote above did not suggest this.

[Buildroot] Target support for Atmel ARM/AVR32

[Bernhard Fischer]

On Thu, Jan 25, 2007 at 02:47:07PM +0100, Bernhard Fischer wrote:
>On Thu, Jan 25, 2007 at 01:42:20PM +0100, Ulf Samuelsson wrote:
>>Bernhard Fischer wrote:
>
>>>If the TODO that is mentioned in r17516 would be fixed, would that
>>>help that problem in any way? I, personally, don't use the concept of
>>>a board in the context of buildroot. Put that aside, what about this
>>>layout:
>>>-) toolchain_<arch>_<subarch>_<cpu>
>>>-) same for build_
>>>-) board_<device> as default COPY_TO
>>>
>>>where
>>>$device is target/device/*
>>>$arch would be generic arch e.g. i386, arm
>>>$subarch is the real -march=
>>>$cpu is the real -mtune=
>>>
>>>Opinions?
>>
>>That is a different problem.
>>I can either build an ARM based buildroot or an AVR32 based buildroot.
>>They will build in: build_arm and build_avr32, same for toolchain.
>>
>>My problem is that I want to build for
>>AT91RM9200DK    -ARM920T
>>AT91RM9200DF     -ARM920T
>>AT91RM9200EK     -ARM920T
>>AT91SAM9260EK  -ARM926EJS
>>AT91SAM9261EK  -ARM926EJS
>>AT91SAM9263EK  -ARM926EJS
>>AT91SAM9XEEK   -ARM926EJS
>>using a common toolchain
>>(The toolchain is generic arm, even though I use different CPU cores)
>>and maybe a common root file system (today it is).
>>
>>This means that
>>* 7 different Linux versions,
>>* 7 different U-boot
>>* 7 different bootstraps.
>>Possibly, the root file system should be populated differently.
>>
>>When I have built a board, I want to have all binaries stored
>>in one place which can be easily compressed into a tarball.
>>
>>Your suggestion is more for building different toolchains for different 
>>boards
>>but this is not the case.
>
>My suggestion is to build two toolchains (assuming that ARM920T !=
>ARM926EJS, if it is the same, then it's only one toolchain) and use that
>to populate the board_{AT91*} dirs

Just to clarify. If your subarch is nil -- i.e. generic $arch -- then
you have only one toolchain in your abovementioned example.
One toolchain, N board_AT91*/{bin,sbin,etc,...}

See?
>>
>>It is a big bonus, If I do not have to recompile the root file system
>>packages, just because I build support for a new board.
>
>What i wrote above did not suggest this.

[Buildroot] Target support for Atmel ARM/AVR32

[Ulf Samuelsson]

Bernhard Fischer wrote:
> On Thu, Jan 25, 2007 at 01:42:20PM +0100, Ulf Samuelsson wrote:
>> Bernhard Fischer wrote:
>
>>> If the TODO that is mentioned in r17516 would be fixed, would that
>>> help that problem in any way? I, personally, don't use the concept
>>> of a board in the context of buildroot. Put that aside, what about
>>> this layout:
>>> -) toolchain_<arch>_<subarch>_<cpu>
>>> -) same for build_
>>> -) board_<device> as default COPY_TO
>>>
>>> where
>>> $device is target/device/*
>>> $arch would be generic arch e.g. i386, arm
>>> $subarch is the real -march=
>>> $cpu is the real -mtune=
>>>
>>> Opinions?
>>
>> That is a different problem.
>> I can either build an ARM based buildroot or an AVR32 based
>> buildroot. They will build in: build_arm and build_avr32, same for
>> toolchain.
>>
>> My problem is that I want to build for
>> AT91RM9200DK    -ARM920T
>> AT91RM9200DF     -ARM920T
>> AT91RM9200EK     -ARM920T
>> AT91SAM9260EK  -ARM926EJS
>> AT91SAM9261EK  -ARM926EJS
>> AT91SAM9263EK  -ARM926EJS
>> AT91SAM9XEEK   -ARM926EJS
>> using a common toolchain
>> (The toolchain is generic arm, even though I use different CPU cores)
>> and maybe a common root file system (today it is).
>>
>> This means that
>> * 7 different Linux versions,
>> * 7 different U-boot
>> * 7 different bootstraps.
>> Possibly, the root file system should be populated differently.
>>
>> When I have built a board, I want to have all binaries stored
>> in one place which can be easily compressed into a tarball.
>>
>> Your suggestion is more for building different toolchains for
>> different boards
>> but this is not the case.
>
> My suggestion is to build two toolchains (assuming that ARM920T !=
> ARM926EJS, if it is the same, then it's only one toolchain) and use
> that to populate the board_{AT91*} dirs
>>

There will be only a single toolchain which will be generic-arm.
This will be ok for novices, and if they start to care, then
it is easily changed in the .config file.

In order to avoid cluttering the top directory, I have
put in an extra directory level so instead of your suggestion:

>>> -) toolchain_<arch>_<subarch>_<cpu>
>>> -) same for build_
>>> -) board_<device> as default COPY_TO
>>>

board_<device>
becomes
board/<device>

although I call it

target_build_<arch>/<boardname>

Also I put all binaries in a single directory

binaries/<boardname>

This means that you get two extra directories in the top level
compared to seven extra directories at the top level.

It is also easy to create a tarball of all the binaries
when they are all located in a single place.

Today, the binaries are created in the top directory,
so you have to spend more time to select which files should
go into the binaries tarball.

Having the binaries spread out in different board_<device>
directories is also costing more in matinenace than
a single "binaries" directory.


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