From: Bernhard Fischer <rep.dot.nop@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] Target support for Atmel ARM/AVR32
Date: Thu, 25 Jan 2007 14:47:07 +0100 [thread overview]
Message-ID: <20070125134707.GA17985@aon.at> (raw)
In-Reply-To: <00bd01c7407f$a8c4c300$01c4af0a@atmel.com>
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.
next prev parent reply other threads:[~2007-01-25 13:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-24 11:06 [Buildroot] Target support for Atmel ARM/AVR32 Ulf Samuelsson
2007-01-24 23:37 ` Bernhard Fischer
2007-01-24 23:58 ` Ulf Samuelsson
2007-01-25 9:04 ` Bernhard Fischer
2007-01-25 12:42 ` Ulf Samuelsson
2007-01-25 13:47 ` Bernhard Fischer [this message]
2007-01-25 14:07 ` Bernhard Fischer
2007-01-25 15:28 ` Ulf Samuelsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070125134707.GA17985@aon.at \
--to=rep.dot.nop@gmail.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.