RobertCNelson Tree

Hi,

Theses patchs from RobertCNelson tree will be in Linus tree ?
I mean this "tree" https://github.com/RobertCNelson/stable-kernel

Thanks

It depends...

Most of the "branches" in that repo support arm "board" files that
have thus been removed from kernel.org.

Some branches, include 'features' posted to l-o/l-a/l-k but never made
it to kernel.org, due to any number of random situations..

Other patches are backports of features that hit kernel.org

But....

If you are "relying" on any branch in that repo today, your doing it
wrong. Every branch is now eol and in maintenance only mode. I only
use the "master" branch for updating the build scripts.

If you have an armv7 device, use:
https://github.com/RobertCNelson/armv7-multiplatform

If you have an armv7-lpae device, use:
https://github.com/RobertCNelson/armv7-lpae-multiplatform

If you have a bbw/bbb use:
https://github.com/RobertCNelson/bb-kernel

Or if your nuts like me, my personal staging for next:
https://github.com/RobertCNelson/linux-next

Regards,

Robert,

I have a BBB and I wrote http://elinux.org/Building_for_BeagleBone.
So, I’m looking for something to do when I finish the eudyptula challenge.
I’m thinking in work for BBB be better supported in mainline.

I was thinking if I can run mainline in BBB what Robert has in his tree that should be in mainline in order to better support BBB.

Thanks
Tanure

The BBB runs just fine on mainline. In fact Debian's Jessie "3.14.x
kernel" boots just fine on the BBB. We know they don't take very many
external patches..

The three biggest subsystems missing on mainline are:

PRU:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267588.html

"capemgr":
Waiting for overlays/etc...
https://lkml.org/lkml/2014/7/23/756

PM: Beg/borrow/steal from:
http://git.ti.com/ti-linux-kernel/ti-linux-kernel/commits/ti-linux-3.12.y
http://git.ti.com/ti-linux-kernel/ti-linux-kernel/commits/ti-linux-3.14.y

Regards,

Robert,

I have a BBB and I wrote Building for BeagleBone - eLinux.org.
So, I'm looking for something to do when I finish the eudyptula challenge.
I'm thinking in work for BBB be better supported in mainline.

I was thinking if I can run mainline in BBB what Robert has in his tree
that should be in mainline in order to better support BBB.

Thanks
Tanure

Hi Lucas,

the part about crosstool-ng is pretty weak. You also need to
have kernel header files to build a cross tool chain with
crosstool-ng.

It's not weak, It's empty. But, my focus was using a easier
cross-compiler rather than building my own.
I will get crosstool-ng when I have more time to test before I publish.

Building your own kernel for BeagleBone is no easy trick,
getting the kernel header files exported from RCN's tree
has been a bothersome pain for the 3.8 tree.
reference: http://ttylinux.net/dloadBBN.html

Why I need to do that ? I think that 3.15 runs in BBB just fine, right ?
I just need more time to build my rootfs and I'm good to go.

If you like, I can give you information to make that page
you wrote on elinux.org to be more useful.

Cheers...

Yes, of course, send me what you think that can improve or go there and edit.
We can talk a lot and improve, so anyone can benefit.

Thanks
Lucas Tanure

It’s not weak, It’s empty. But, my focus was using a easier

No, not a problem at all. I didn't know they existed.
I use arch, and there isn't a package for that. I search for ubuntu
package and didn't found as well.
For me the main point in this tutorial is easier to install, because
the user just wants to build the lasted kernel. But in another page we
can enumerate the toolchains options.

Thanks

I'm not saying to be snide or sarcastic, really, but anyone
can play that nonsense game: You have a problem with a
crosstool-ng tool chain? And to the next statement: which
uboot and kernel? *The* uboot and kernel? Not mine:
http://ttylinux.net/dloadBBN.html

The Linux-targeted cross tool chain has an associated glibc
and kernel interface; I build versions of those of my own
preference to suit my ttylinux distribution. That is why
I build my cross tool chain from sources with crosstool-ng.
With this approach I have commonality to make ttylinux
for mac-g4, beaglebone, i486, i686, x8_64 of the same versions
of glibc and Linux kernel, each built with a crosstool-ng
produced cross tool chain constructed with the proper glibc
and kernel interfaces.
https://github.com/djerome/crosslinux

The world does not revolve around what you happen to
use. Just most of it. :slight_smile:

Lucas,

In that case perhaps crosstool-ng may be the way to go. I mean you could also run a Debian VM just as a support system for the BBB. But that adds complexity, which may / may not outweigh just building your own toolchain. It depends on how much you know about what, and what you do / do not like to do. Some people, myself included just do not feel like building their own tools chains . . .

Douglas, obviously you do not use the prebuilt images that come shipped with the BBB. I do not either, I build my own custom images based on RCN’s instructions / scripts. Why ? Because I have too many other things going on in my life to learn / worry about yet_another_thing. I have a project in mind, for which I have many things to learn. I really do not want to add to that pile any more than I have to. So, this is not a game this is called getting something done with the least amount of resistance as possible. It almost sounds like you took my last post personal. Also remember your last statement works both ways.

Jerome,

Sorry I didn't understand what you want, or complain about that page.
Feel free to edit and add what you think is important.
I can only write about things I know, and understand. That tip about
Linaro toolchain was very good thanks, I will take a look.
The wiki is for anyone, from anyone. So add your way, so people can know of.

Willian,

I feel the same way, I just want to build my kernel, boot and use. I'm
not a expert, I'm a newbie, so I need first a easier and faster way to
get where I want.
For me, what I know about crosstool-ng is that you can choose many
variables and build a perfect compiler for you, using uLibc, gLibc
what ever you need. And I don't see yet why "In that case perhaps
crosstool-ng may be the way to go." . What I'm missing in this case ?
What crosstool-ng is so much better than a preconfigured gcc from
ubuntu servers ?

I really want to write about crosstool-ng, but I need more time. That
page was a result of LFD411 - Embedded Linux Development, that was
awesome.
And now that I know of Linaro toolchain I will this information there
too, but I need time to try myself and write a good tutorial.

Thanks!

Lucas, I started pretty much the same as you last year around may. I did a lot of research / reading early on, and have had a bit of experience with different gcc toolchains for different platforms. Previous to this I did a lot of reading about the gcc port for the MSP430, so I really did not want to spend a lot of time figuring out how to build my own toolchain using crosstool-ng ( even though I did a bunch of reading on the subject ).

Also, as far as I know, you can setup / link to other libc’s by configuring the Linaro toolchain. I did a little reading on the subject to think I know it is possible, but I’m no expert either. Since then I have started thinking differently, about my own projects, and shifted more towards using Nodejs( when possible ) versus using only natively compiled executables.

http://eewiki.net/display/linuxonarm/BeagleBone+Black This link may be a good resource for you in how everything is setup. I’ve used this myself to build my own custom images that are relatively very small. One such image has standard tools such as openssh-server, ntpdate, Nodejs with express, and socket.io installed in as little as 191M space.

Anyway, it seems to me that you’ll probably want to at least eventually be running ARCH on your BBB. Aside from letting you know that it has been done by others already, I can offer very little assistance with that.

errr, natively compiled executable implies not using a cross compiler. What I meant was executables compiled for the specific platform. Not necessarily compiled natively. sorry.

Jerome,

Sorry I didn't understand what you want, or complain about that page.
Feel free to edit and add what you think is important.
I can only write about things I know, and understand. That tip about
Linaro toolchain was very good thanks, I will take a look.
The wiki is for anyone, from anyone. So add your way, so people can know of.

Whoa, I really don't mean to sound cross about anything.
For that page, my critique is: from the terseness of the
crosstool-ng part it lacks usefulness and I'm willing to
help.
My first name is Douglas, not Jerome.

Willian,

I feel the same way, I just want to build my kernel, boot and use. I'm
not a expert, I'm a newbie, so I need first a easier and faster way to
get where I want.
For me, what I know about crosstool-ng is that you can choose many
variables and build a perfect compiler for you, using uLibc, gLibc
what ever you need. And I don't see yet why "In that case perhaps
crosstool-ng may be the way to go." . What I'm missing in this case ?
What crosstool-ng is so much better than a preconfigured gcc from
ubuntu servers ?

For what it's worth, from someone who uses crosstool-ng but not
a pre-built cross tool chain, I don't think it's fair to say
crosstool-ng is so much better in an open ended way.

When you build code for a Linux system the tool chain supplies
the glibc interface (header files and library files) which has
the Linux kernel system call interface; if you want some
particular version of those, then building your own cross-tool
chain with those versions can be so much better than using a
pre-built cross tool chain. If you use a pre-built cross tool
chain, what versions of glibc and Linuc kernel is your
cross-built code targeted to? I am being glibc-centric
here, I know.

Cheers.

Everything being equal I think crosstool-ng is the way to go. There are a few things I do not like about the Linaro toolchain, and the prepackaged libc is the main one on my mind.

Personally, for various things, I prefer building things from scratch. This is the side of me that also loves this concept of Gentoo. But the practicalities of every day business almost always get in the way. Now, I have a time investment spent learning about the Linaro toolchain. Which admitedly is not a huge amount. Not like Debian versus Gentoo ( for me ), where I’ve been using Debian since the mid 90’s.

Everything being equal I think crosstool-ng is the way to go. There are a few things I do not like about the Linaro toolchain, and the prepackaged libc is the main one on my mind.

If you dig into linaro’s build script for those binaries, it is actually crosstool-ng… Its just tied with a later ubunutu/Linaro specific libc.

It just works, is why I use it exclusively now. Some of us remember the code soucery days when they’d magically break stuff between releases. Thankfully Angstroms cross compiler was around back then. Eventually those guys went to Linaro and fixed GCC.

Robert,

I use the Linaro toolchain for exactly the same reasons as you. Aside from the fact that I follow your guide as closely as possible, and deviating from that would cause more headaches than it is worth. All one has to do is read all the half fast copied blog postings out there to realize this . . . that lead to “HALP ITS BROKED” posts on these groups . . .heh.

As far as the crosstool-ng aspect. I just mean that you get eaxctly what you want when you build your own toolchain. On the other side of that coin. For me personally, I probably do not know everything I need to know to build a proper toolchain for the BBB. After that, failed attempts would get old fast, or worse yet seemingly good attempts that could turn “tragic” in a hurry.

Hi,

I will add a page only for toolchains, so the user can know about the options.
The wiki needs more information on how build root filesystem,
toolchain options, yocto, etc. So, I still have a lot of stuff to dig
and writ about it.

@Robert/William,
Could explain me what is the problems that you run into with others
toolchains rather than linaro toolchain ?
So I can put this info in the new page.

@Willian,

My goal is understand how it's done, and after that, I move to Arch Linux.

Thanks

Lucas, it's more of the old saying:

Fool me once, shame on you; fool me twice, shame on me.

http://elinux.org/ARMCompilers#Limitations

Otherwise, you should use the search feature of this list, it goes back 6 years.

Anywho, ever since Linaro started putting resources into fixing gcc
for arm/arm64, like 3-4 years ago. GCC mostly just works now days.

Why a new page? At this point mainline gcc-4.9 is fine. (and really
everything after gcc-4.6).. You'd just be creating a revisionist
history of gcc page.

Regards,

Oh, sorry, I didn't know.
Linus found a bug in 4.9, so I think that 4.8 is the better.

Thanks

Nothing. But similar to what Robert said. Linaro is a “known quantity”. Just like picking a name brand when buying hardware based on prior experience. I have experience with various aspects of Debian dating back to the 90’s. From then until now I have experienced a lot of grief trying to set many thing up. So, when I find something that works, and works well enough. I tend to stick with it. This is one aspect of why I refused to use Angstrom.

When I first started with the BBB last year, which coincidentally is when I first started learning about embedded Linux and had zero experience writing code on the same. I had a lot to learn all at the same time, and I still have a lot to learn. So this is not about zealotry for me, but a very fine balancing act of what works, and what I can live with to achieve my own end goals. In this same context, there are many things which I may prefer to do / use, but have a very steep learning curve. This is the only real problem I have with crosstool-ng. Not that it is bad, or would take too long to learn how to use. I just do not have the time to mess with it. Not while getting the other things done which I hold higher in priority. Enter Linaro . . .

I started using Robert’s build guide a week after we got our BBB’s. I was reading about various toolchains at the time trying to decide which one was best for me, when I had a sudden realization. “Hey, I already have a tool chain here . . .” 15 minutes later I wrote a very simple CPU load test - test application and had it loading my CPU at 60%. Knowing hardly anything about the toolchain, writing C for Linux, or the prepackaged libc. Granted, I did bring some prior experience with gcc with me.