[Clfs-dev] GIT-0.0.1-20120922-arm: Tracker Request

[Andrew Bradford]

On Wed, 20 Mar 2013 08:29:35 +0100
Eric Herman <eric at freesa.org> wrote:

> On 03/20/2013 03:27 AM, Kirk Terrell wrote:
> > On 03/19/2013 06:16 PM, Andrew Bradford wrote:
> >> On Tue, 19 Feb 2013 19:35:23 -0800
> >> Kirk Terrell <knjterrell at mybluelight.com> wrote:
> 
> >> Is it worth keeping ARM big endian around in the embedded book?
> >>
> >> If not, then that easily begs the question of if it's worth
> >> keeping the wrt "arch" around since it's just MIPS but with a few
> >> tweaks to support the WRT routers.
> >>
> >> I don't want to rip out useful things, but due to low developer
> >> time for the embedded book, reducing the number of
> >> configurations / archs supported seems like a reasonable thing to
> >> do. Based on memory, most of the people building the embedded book
> >> are doing so on ARM little endian armv5 or armv7-a with a few here
> >> and there doing x86 or MIPS.
> >>
> >> What do you, and the list, think?
> 
> The "arch" is still useful for several routers, e.g.: I have a
> WL-700gE which is MIPS ... but personally, I follow the regular CLFS
> book, not the embedded book.

Thanks for that info.  Since late 2010, when I started paying attention
to the embedded book, I'm not sure I've actually seen any questions
about MIPS for embedded.  A reasonable number of people write to
-support or -dev asking about x86 and ARM, though.

> I have no idea if anyone does anything with ARM following the
> embedded book. I have a RaspberryPi, but when I get around to it,
> I'll probably be CLFSing it from the regular book.

ARM's not in the normal CLFS book, it's only currently in the (quite
outdated) sysroot and (only somewhat outdated) embedded books.

Realistically, adding ARM to normal CLFS shouldn't be hard, it just
hasn't been done, yet.

> Since the books are not executable, and it's not simply a matter of 
> getting some hardware donated and pressing the "go" button, it
> requires someone to invest non-trivial time and effort.

I agree.  QEMU can help here but it's not quite the same.

> While it may be a bit disappointing, unless someone offers to invest
> the time to maintain the various architectures for the embedded book,
> I think it is very reasonable to remove them -- perhaps replace them
> with a note that other architectures have been supported in the past.
<snip>
> P.S.: Too much do I see that I fall victim to letting the pursuit of 
> perfection undermine my ability to deliver something of value. 
> Generally, I think it is better to have progress on something small
> than have something bigger and better which never delivers.

I was thinking that maybe it makes the most sense to take the embedded
book in a direction where it targets a few different very popular
boards, like the Beagles, Panda, Raspberry Pi, etc.  That way the book
can be much more specific about what options to choose based on what
board you have and there's probably a much higher likelihood of success
for people just trying the embedded book out the first time.  This is
especially true for bootloaders and kernel builds if mainline doesn't
yet support a popular board (which happens often).

What do you think of that idea?

-Andrew