[Buildroot] Beaglebone Black support

[Buildroot] Beaglebone Black support

[Frank Hunleth]

I just got a Beaglebone Black and wanted to try out Buildroot with it.
The 3.8 kernel from TI that was referenced in beaglebone_defconfig
didn't boot all the way for me. I could probably do a better job of
getting it to work since it looked close, but I was interested in some
of the cape and PRU code that was in the beaglebone.org kernel
patches. The good news was that as soon as I applied all of the
beaglebone.org kernel patches to a plain 3.8.13 kernel, the
buildroot-built images started booting with the peripherals of
interest working (minor issues, but it looks promising.)

I'd like to get things in a form that I could contribute upstream and
I'm not sure how to deal with the kernel. Both "kernels" referenced by
people on the beageboard mailing lists, the beaglebone.org kernel and
the Robert J. Nelson kernel, are really a list of patches (100s of
them) and a shell script to download the 3.8.13 kernel and apply them.
See here for an example:

https://github.com/beagleboard/kernel/tree/3.8

Angstrom deals with this by having a copy of the patches in
meta-beagleboard and referencing them in the .bb file. See:

https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/recipes-kernel/linux/linux-mainline_3.8.bb

However, copying the patches over to buildroot seems wrong and painful
to maintain, but as far as I can tell, there's no official/maintained
git repo with the beaglebone.org kernel patches.

I was wondering if there were any thoughts about a nice way to handle
this... or has anyone already done this, but not submitted their
patches?

Thanks,
Frank

[Buildroot] Beaglebone Black support

[Stefan Peter]

Hi Frank

On 23.06.2013 21:21, Frank Hunleth wrote:
> I just got a Beaglebone Black and wanted to try out Buildroot with it.
> The 3.8 kernel from TI that was referenced in beaglebone_defconfig
> didn't boot all the way for me. I could probably do a better job of
> getting it to work since it looked close, but I was interested in some
> of the cape and PRU code that was in the beaglebone.org kernel
> patches. The good news was that as soon as I applied all of the
> beaglebone.org kernel patches to a plain 3.8.13 kernel, the
> buildroot-built images started booting with the peripherals of
> interest working (minor issues, but it looks promising.)
> 
> I'd like to get things in a form that I could contribute upstream and
> I'm not sure how to deal with the kernel. Both "kernels" referenced by
> people on the beageboard mailing lists, the beaglebone.org kernel and
> the Robert J. Nelson kernel, are really a list of patches (100s of
> them) and a shell script to download the 3.8.13 kernel and apply them.
> See here for an example:
> 
> https://github.com/beagleboard/kernel/tree/3.8

Getting these patches upstream into Linus kernel is the final solution.
Customers like you putting pressure to do so on TI (or whoever provides
these patches) are the key to reach this target.

Regards

Stefan Peter

[Buildroot] Beaglebone Black support

[Charles Krinke]

In the case of the Linux kernel, official means kernel.org and nothing TI
or any other group or organization does is "official".

If TI wishes their patches accepted into the kernel along with everyone
else, they must play by the same rules.

Charles
On Jun 23, 2013 4:20 PM, "rh" <richard_hubbe11@lavabit.com> wrote:

> On Sun, 23 Jun 2013 15:21:04 -0400
> Frank Hunleth
> <fhunleth@troodon-software.com> wrote:
>
> --8<--
>
> > However, copying the patches over to buildroot seems wrong and painful
> > to maintain, but as far as I can tell, there's no official/maintained
> > git repo with the beaglebone.org kernel patches.
>
> This seems official to me but not sure what you mean by official.
> Do you mean kernel.org-official?  TI-official? Circuitco?
>
> https://github.com/beagleboard
>
> > I was wondering if there were any thoughts about a nice way to handle
> > this... or has anyone already done this, but not submitted their
> > patches?
>
> Far as I can tell the ARM community has embarked on using device tree
> and I think that work's underway. But I'm new to the BBBlack and
> ARM hardware.  From what I've gleaned here and there, using the device
> tree is a prereq for getting upstream with the BBB code.
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130623/aed4c7ed/attachment.html>

[Buildroot] Beaglebone Black support

[Frank Hunleth]

On Sun, Jun 23, 2013 at 7:13 PM, rh <richard_hubbe11@lavabit.com> wrote:
> On Sun, 23 Jun 2013 15:21:04 -0400
> Frank Hunleth
> <fhunleth@troodon-software.com> wrote:
>
> --8<--
>
>> However, copying the patches over to buildroot seems wrong and painful
>> to maintain, but as far as I can tell, there's no official/maintained
>> git repo with the beaglebone.org kernel patches.
>
> This seems official to me but not sure what you mean by official.
> Do you mean kernel.org-official?  TI-official? Circuitco?

I'd just like to point to a kernel that is maintained and has the
features that I need. The one at github.com/beagleboard/kernel is the
obvious choice since that's what's shipped on the Beaglebone Black.

The point of my email is just that the github.com/beagleboard/kernel
repository is not in a form that nicely integrates with buildroot due
to it just containing patches for a Linux kernel. I'm just looking for
pointers on how best to handle this.

For the time being, I just ran the github.com/beaglebone/kernel script
to create a patched kernel, tarred it up and posted it on a server for
buildroot to download. It will become annoying after a few updates to
the patch set, and I may consider automating it, but for now it keeps
me moving forward. I'll happily change what I'm doing should a better
way come up.

Frank

[Buildroot] Beaglebone Black support

[Baruch Siach]

Hi Frank,

On Sun, Jun 23, 2013 at 11:30:12PM -0400, Frank Hunleth wrote:
> On Sun, Jun 23, 2013 at 7:13 PM, rh <richard_hubbe11@lavabit.com> wrote:
> > On Sun, 23 Jun 2013 15:21:04 -0400
> > Frank Hunleth
> > <fhunleth@troodon-software.com> wrote:
> >
> > --8<--
> >
> >> However, copying the patches over to buildroot seems wrong and painful
> >> to maintain, but as far as I can tell, there's no official/maintained
> >> git repo with the beaglebone.org kernel patches.
> >
> > This seems official to me but not sure what you mean by official.
> > Do you mean kernel.org-official?  TI-official? Circuitco?
> 
> I'd just like to point to a kernel that is maintained and has the
> features that I need. The one at github.com/beagleboard/kernel is the
> obvious choice since that's what's shipped on the Beaglebone Black.
> 
> The point of my email is just that the github.com/beagleboard/kernel
> repository is not in a form that nicely integrates with buildroot due
> to it just containing patches for a Linux kernel. I'm just looking for
> pointers on how best to handle this.

git integrates quite nicely with Buildroot, and a lot of packages fetch their 
sources from git repos. See the 'LIBFOO_SITE_METHOD' description in the 
Buildroot manual (http://buildroot.net/downloads/manual/manual.html). Also 
look for a github specific tip under 'Tips and tricks'.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] Beaglebone Black support

[Frank Hunleth]

Hi Baruch,

On Mon, Jun 24, 2013 at 12:28 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Frank,
>
> On Sun, Jun 23, 2013 at 11:30:12PM -0400, Frank Hunleth wrote:
>> On Sun, Jun 23, 2013 at 7:13 PM, rh <richard_hubbe11@lavabit.com> wrote:
>> > On Sun, 23 Jun 2013 15:21:04 -0400
>> > Frank Hunleth
>> > <fhunleth@troodon-software.com> wrote:
>> >
>> > --8<--
>> >
>> >> However, copying the patches over to buildroot seems wrong and painful
>> >> to maintain, but as far as I can tell, there's no official/maintained
>> >> git repo with the beaglebone.org kernel patches.
>> >
>> > This seems official to me but not sure what you mean by official.
>> > Do you mean kernel.org-official?  TI-official? Circuitco?
>>
>> I'd just like to point to a kernel that is maintained and has the
>> features that I need. The one at github.com/beagleboard/kernel is the
>> obvious choice since that's what's shipped on the Beaglebone Black.
>>
>> The point of my email is just that the github.com/beagleboard/kernel
>> repository is not in a form that nicely integrates with buildroot due
>> to it just containing patches for a Linux kernel. I'm just looking for
>> pointers on how best to handle this.
>
> git integrates quite nicely with Buildroot, and a lot of packages fetch their
> sources from git repos. See the 'LIBFOO_SITE_METHOD' description in the
> Buildroot manual (http://buildroot.net/downloads/manual/manual.html). Also
> look for a github specific tip under 'Tips and tricks'.
>

Let me try asking my question again, since some of the details from
the original email have been trimmed.

Here's what root directory of the Beaglebone "kernel" git repo (3.8
branch) looks like:

configs/
hacks/
patches/
    6lowpan/
        0001-6lowpan-...
        <lots of patches>
    PG2
        0001-beaglebone-black-1ghz-hack.patch
    <lots of other directories with patches>
recipies/
patch.sh

The patch.sh script clones the Linus kernel and patches it when you run it.

Now, regarding Buildroot, there's an option for specifying the Linux
kernel via a git reference, but the expectation is that you'll be
getting Linux source code. There are also ways of applying patches to
a Linus kernel. The problem that I am trying to ask about is how best
to deal with the 600+ patches that are contained in beagleboard/kernel
patch tree.

Does this make more sense now?

Thanks,
Frank

[Buildroot] Beaglebone Black support

[Frank Hunleth]

Hi Richard,

On Mon, Jun 24, 2013 at 12:41 AM, rh <richard_hubbe11@lavabit.com> wrote:
> On Sun, 23 Jun 2013 23:30:12 -0400
> Frank Hunleth
> <fhunleth@troodon-software.com> wrote:
>
> --8<--
>
>> I'd just like to point to a kernel that is maintained and has the
>> features that I need. The one at github.com/beagleboard/kernel is the
>> obvious choice since that's what's shipped on the Beaglebone Black.
>
> I was asking since I just started trying buildroot myself.

If you'd like to try out my repository for the BBB, feel free to look at:

https://github.com/fhunleth/buildroot-bbb

I don't have much in the line of instructions right now, but it should
build for you. Check out the bbb branch and run "make
beagleboneblack_defconfig" and make. I can run the images from both a
microSD card and eMMC, and things seem to be coming up.

Also, I just put in the PRU's PASM assembler and interface libraries.
I haven't checked it out yet except that it builds and can assemble
the examples.

>
>>
>> The point of my email is just that the github.com/beagleboard/kernel
>> repository is not in a form that nicely integrates with buildroot due
>> to it just containing patches for a Linux kernel. I'm just looking for
>> pointers on how best to handle this.
>
> I think the answer is in the other reply, but I'm not sure yet. From the
> brief time I've used buildroot it seems flexible enough to allow pulling
> stuff from lots of places.

Despite using br for the past few years on a handful of projects, it
seems like every time I update my tree that I learn about a few new
features.

>
>>
>> For the time being, I just ran the github.com/beaglebone/kernel script
>> to create a patched kernel, tarred it up and posted it on a server for
>> buildroot to download. It will become annoying after a few updates to
>> the patch set, and I may consider automating it, but for now it keeps
>> me moving forward. I'll happily change what I'm doing should a better
>> way come up.
>
> I think the ARM stuff needs more work before it's accepted upstream but
> don't know for sure.

Agreed.

[Buildroot] Beaglebone Black support

[Zoltan Gyarmati]

On 06/24/2013 09:49 PM, rh wrote:
> On Mon, 24 Jun 2013 08:22:56 -0400
> Frank Hunleth
> <fhunleth@troodon-software.com> wrote:
>
>> If you'd like to try out my repository for the BBB, feel free to look
>> at:
>>
>> https://github.com/fhunleth/buildroot-bbb
>>
>> I don't have much in the line of instructions right now, but it should
>> build for you. Check out the bbb branch and run "make
>> beagleboneblack_defconfig" and make. I can run the images from both a
>> microSD card and eMMC, and things seem to be coming up.
> Thanks for sharing!  You're way more organized than I am.
> Mine is not ready for prime-time, I'm not sure if it even boots.
> I don't have a working serial cable yet.
>
>> Also, I just put in the PRU's PASM assembler and interface libraries.
>> I haven't checked it out yet except that it builds and can assemble
>> the examples.
>>
>>>> The point of my email is just that the
>>>> github.com/beagleboard/kernel repository is not in a form that
>>>> nicely integrates with buildroot due to it just containing patches
>>>> for a Linux kernel. I'm just looking for pointers on how best to
>>>> handle this.
>>> I think the answer is in the other reply, but I'm not sure yet.
>>> From the brief time I've used buildroot it seems flexible enough to
>>> allow pulling stuff from lots of places.
>> Despite using br for the past few years on a handful of projects, it
>> seems like every time I update my tree that I learn about a few new
>> features.
> Buildroot has lots of possibilities for sure. I'm used to building kernels
> but the BBB and buildroot adds a new level of complexity for me.
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot


Hello,

checked the linked config from fhunleth, it seems in the used kernel
tree (
http://files.troodon-software.com/br/beagleboard-kernel-b37928553c8de3598d8a259d7ce5c4be713c2908.tar.xz
), the usb and the ethernet support is broken (or, as it always
possible, i failed something).
 So to get a working kernel, i used the patchset from
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8 ,
( which patches are extracted from the Angstrom build tree ), applied
them manually on the mainline tree, created a tarball, and used that to
build with Buildroot.
So far everything works well (UART,USB host/gadget, ethernet, GPIO
tested). I wondering, would it be possible to apply those subdir-style (
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8/patches )
patches automatically in Buildroot on an elegant way? Or better to
create a git tree with applied patches somewhere online and use that in
Buildroot?

Thanks, best regards,
zgyarmati



-- 
br, 
Zoltan Gyarmati
mail: mr.zoltan.gyarmati at gmail.com
freenode nick: zgyarmati

[Buildroot] Beaglebone Black support

[Frank Hunleth]

Hi Zoltan,


On Mon, Jul 1, 2013 at 6:10 AM, Zoltan Gyarmati
<mr.zoltan.gyarmati@gmail.com> wrote:
> Hello,
>
> checked the linked config from fhunleth, it seems in the used kernel
> tree (
> http://files.troodon-software.com/br/beagleboard-kernel-b37928553c8de3598d8a259d7ce5c4be713c2908.tar.xz
> ), the usb and the ethernet support is broken (or, as it always
> possible, i failed something).
>  So to get a working kernel, i used the patchset from
> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8 ,
> ( which patches are extracted from the Angstrom build tree ), applied
> them manually on the mainline tree, created a tarball, and used that to
> build with Buildroot.
> So far everything works well (UART,USB host/gadget, ethernet, GPIO
> tested). I wondering, would it be possible to apply those subdir-style (
> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8/patches )
> patches automatically in Buildroot on an elegant way? Or better to
> create a git tree with applied patches somewhere online and use that in
> Buildroot?

I had wanted to do the same thing and haven't found a way. However, I
did find that Robert Nelson maintains a super patch that combines all
of the patches that he puts into his kernel. When I compared his super
patch to what I had built from Angstrom, it looked nearly identical.
He had a couple modifications that looked minor.

His patch can be found at paths similar to:

http://rcn-ee.net/deb/sid-armhf/v3.8.13-bone22/patch-3.8.13-bone22.diff.gz

I just updated my Github repository to use the kernel.org 3.8.13
kernel and patch it with this patch. The board boots, but I've been so
busy the past week with work that I haven't had a chance to verify
that other things work.

FWIW, I found out about this patch by looking at how Arch Linux
handles the Beaglebone Black. They might have other insights.

Hope this helps,
Frank

[Buildroot] Beaglebone Black support

[Arnout Vandecappelle]

On 07/01/13 12:10, Zoltan Gyarmati wrote:
> checked the linked config from fhunleth, it seems in the used kernel
> tree (
> http://files.troodon-software.com/br/beagleboard-kernel-b37928553c8de3598d8a259d7ce5c4be713c2908.tar.xz
> ), the usb and the ethernet support is broken (or, as it always
> possible, i failed something).
>   So to get a working kernel, i used the patchset from
> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8  ,
> ( which patches are extracted from the Angstrom build tree ), applied
> them manually on the mainline tree, created a tarball, and used that to
> build with Buildroot.
> So far everything works well (UART,USB host/gadget, ethernet, GPIO
> tested). I wondering, would it be possible to apply those subdir-style (
> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8/patches  )
> patches automatically in Buildroot on an elegant way? Or better to
> create a git tree with applied patches somewhere online and use that in
> Buildroot?

  I guess you can download the patches as a tarball, right? Then you 
should just be able to use the tarball's URL in BR2_LINUX_KERNEL_PATCH 
and buildroot will extract them from the tarball and apply them all in 
directory order (or according to the series file, if present). Or does 
that not work for some reason?

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Beaglebone Black support

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Tue, 02 Jul 2013 08:07:37 +0200, Arnout Vandecappelle wrote:

>   I guess you can download the patches as a tarball, right? Then you 
> should just be able to use the tarball's URL in BR2_LINUX_KERNEL_PATCH 
> and buildroot will extract them from the tarball and apply them all in 
> directory order (or according to the series file, if present). Or does 
> that not work for some reason?

If you look at
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8/patches,
you'll see that patches are organized in a set of sub-directories, and
the patch order is defined in a shell script,
https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patch.sh,
that has to be executed over a Git kernel tree.

To handle such a bizarre stuff, I don't see any other option that
adding a new kconfig option to specify a shell script to be executed at
"patch" time of the kernel, so that one can do whatever funky things
(s)he wants. That's ugly, but I don't see a nice and generic way of
handling such a bizarre distribution of kernel code.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Beaglebone Black support

[Arnout Vandecappelle]

On 07/02/13 09:34, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Tue, 02 Jul 2013 08:07:37 +0200, Arnout Vandecappelle wrote:
>
>>    I guess you can download the patches as a tarball, right? Then you
>> should just be able to use the tarball's URL in BR2_LINUX_KERNEL_PATCH
>> and buildroot will extract them from the tarball and apply them all in
>> directory order (or according to the series file, if present). Or does
>> that not work for some reason?
>
> If you look at
> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8/patches,
> you'll see that patches are organized in a set of sub-directories, and
> the patch order is defined in a shell script,
> https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patch.sh,
> that has to be executed over a Git kernel tree.
>
> To handle such a bizarre stuff, I don't see any other option that
> adding a new kconfig option to specify a shell script to be executed at
> "patch" time of the kernel, so that one can do whatever funky things
> (s)he wants. That's ugly, but I don't see a nice and generic way of
> handling such a bizarre distribution of kernel code.

  Actually, Xenomai and RTAI are similar. So we could add a config option 
that allows the user to add something to the LINUX_PRE_PATCH_HOOK. But I 
admit, it is getting pretty awkward.

  I think it is easier if someone who cares just forks a linux tree on 
github and applies the patches there.

  Regards,
  Arnout

>
> Best regards,
>
> Thomas
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Beaglebone Black support

[Peter Korsgaard]

>>>>> "rh" == rh  <richard_hubbe11@lavabit.com> writes:

 rh> On Tue, 2 Jul 2013 09:34:15 +0200
 rh> Thomas Petazzoni <thomas.petazzoni-wi1
 rh> +55ScJUtKEb57/3fJTNBPR1lH4CV8 at public.gmane.org> wrote:

 rh> --8<--

 >> To handle such a bizarre stuff, I don't see any other option that
 >> adding a new kconfig option to specify a shell script to be executed
 >> at "patch" time of the kernel, so that one can do whatever funky
 >> things (s)he wants. That's ugly, but I don't see a nice and generic
 >> way of handling such a bizarre distribution of kernel code.

 rh> It's not a good situation. 3.8 kernel is EOL and it seems that TI
 rh> has no resources to get the code upstream.

Well, things are moving - Just not always as fast as you could hope. TI
is certainly not the worst vendor, but we're not there yet for am335x.

I think the best way forward in the short term would be if somebody
would maintain a git tree containing the kernel sources and Koen's patch
set applied on top, and once in a while sync / send a patch to buildroot
to update the git revision the bbb config uses.

-- 
Bye, Peter Korsgaard

[Buildroot] Beaglebone Black support

[Frank Hunleth]

On Tue, Jul 2, 2013 at 5:43 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "rh" == rh  <richard_hubbe11@lavabit.com> writes:
>
> I think the best way forward in the short term would be if somebody
> would maintain a git tree containing the kernel sources and Koen's patch
> set applied on top, and once in a while sync / send a patch to buildroot
> to update the git revision the bbb config uses.
>

FWIW, Robert Nelson (Ubuntu and Debian maintainer for Beaglebone)
regularly posts a summarized version of Koen's patch set. Here's what
I'm currently using for the BBB:

BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.8.13"
BR2_LINUX_KERNEL_PATCH="http://rcn-ee.net/deb/sid-armhf/v3.8.13-bone22/patch-3.8.13-bone22.diff.gz"

It seems to work, but I haven't tested all that much yet.

[Buildroot] Beaglebone Black support

[Peter Korsgaard]

>>>>> "Frank" == Frank Hunleth <fhunleth@troodon-software.com> writes:

 >> I think the best way forward in the short term would be if somebody
 >> would maintain a git tree containing the kernel sources and Koen's patch
 >> set applied on top, and once in a while sync / send a patch to buildroot
 >> to update the git revision the bbb config uses.
 >> 

 Frank> FWIW, Robert Nelson (Ubuntu and Debian maintainer for Beaglebone)
 Frank> regularly posts a summarized version of Koen's patch set. Here's what
 Frank> I'm currently using for the BBB:

 Frank> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
 Frank> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.8.13"
 Frank> BR2_LINUX_KERNEL_PATCH="http://rcn-ee.net/deb/sid-armhf/v3.8.13-bone22/patch-3.8.13-bone22.diff.gz"

 Frank> It seems to work, but I haven't tested all that much yet.

Ok, great - That will also work.

-- 
Bye, Peter Korsgaard

[Buildroot] Beaglebone Black support

[Zoltan Gyarmati]

On 07/03/2013 03:45 PM, Peter Korsgaard wrote:
>>>>>> "Frank" == Frank Hunleth <fhunleth@troodon-software.com> writes:
>  >> I think the best way forward in the short term would be if somebody
>  >> would maintain a git tree containing the kernel sources and Koen's patch
>  >> set applied on top, and once in a while sync / send a patch to buildroot
>  >> to update the git revision the bbb config uses.
>  >> 
>
>  Frank> FWIW, Robert Nelson (Ubuntu and Debian maintainer for Beaglebone)
>  Frank> regularly posts a summarized version of Koen's patch set. Here's what
>  Frank> I'm currently using for the BBB:
>
>  Frank> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
>  Frank> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.8.13"
>  Frank> BR2_LINUX_KERNEL_PATCH="http://rcn-ee.net/deb/sid-armhf/v3.8.13-bone22/patch-3.8.13-bone22.diff.gz"
>
>  Frank> It seems to work, but I haven't tested all that much yet.
>
> Ok, great - That will also work.
>
Hello,

I'm also going to check this overall patch ( i don't know how i didn't
find it earlier, thanks for the hint), and let the community know about
my results.


-- 
br, 
Zoltan Gyarmati
mail: mr.zoltan.gyarmati at gmail.com
freenode nick: zgyarmati

[Buildroot] Beaglebone Black support

[Frank Hunleth]

On Thu, Jul 4, 2013 at 4:16 AM, Zoltan Gyarmati
<mr.zoltan.gyarmati@gmail.com> wrote:
> Hello,
>
> I'm also going to check this overall patch ( i don't know how i didn't
> find it earlier, thanks for the hint), and let the community know about
> my results.
>

The overall patch is missing a Makefile fix for passing flags to the
device tree compiler. This causes the am335x-boneblack.dtb file to be
incorrect and prevents capes (notably the eMMC virtual cape) from
coming up on boot.

Apply this patch (after the overall one) to fix:

https://github.com/fhunleth/buildroot-bbb/blob/bbb/board/beagleboneblack/linux-0001-Add-missing-DTC-flags.patch

Ethernet and other basic functionality is looking good so far...

Frank

[Buildroot] Beaglebone Black support

[Arnout Vandecappelle]

On 23/06/13 21:21, Frank Hunleth wrote:
> I'd like to get things in a form that I could contribute upstream and
> I'm not sure how to deal with the kernel. Both "kernels" referenced by
> people on the beageboard mailing lists, the beaglebone.org kernel and
> the Robert J. Nelson kernel, are really a list of patches (100s of
> them) and a shell script to download the 3.8.13 kernel and apply them.
> See here for an example:
>
> https://github.com/beagleboard/kernel/tree/3.8
>
> Angstrom deals with this by having a copy of the patches in
> meta-beagleboard and referencing them in the .bb file. See:
>
> https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/recipes-kernel/linux/linux-mainline_3.8.bb
>
> However, copying the patches over to buildroot seems wrong and painful
> to maintain, but as far as I can tell, there's no official/maintained
> git repo with the beaglebone.org kernel patches.

  I'm not sure if it is already possible in buildroot to use a git URL 
for the patches, but if so, you could point that one to the Angstrom 
tree. At least, on condition that they are either numbered or have a 
series file.

  The kernel/tree/3.8 URL won't work of course because the patches are 
not all in the same directory.

  You can also check if one of the beaglebone repos (e.g. koenkooi) just 
works for bbb.

  Regards,
  Arnout
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F