|BeagleBone: Maintaining Sub-repository to ease upstream effort||Hiremath, Vaibhav||2/6/12 9:12 AM|
With addition to AM335x device in TI's portfolio, and various boards
including community + development boards around it; it becomes more and more
important and critical to get support for the device/boards in the mainline.
We are working on it and fully committed to get all the patches to the
But when we say upstream it takes its own course of journey, and depends on
various aspects, majorly -
- Acceptance for huge code changes:-
After recent discussion in the ARM community, it is unlikely that, huge
number of code addition would get merged so easily.
In case of AM335x, we have almost ~7K lines of new code, we have already
submitted RFC version of all baseport patches. And, we will keep making
attempts to submit the patches, get it reviewed and try to get accepted;
and that’s continuous process.
- New framework changes:-
As we know, whole omap support in the kernel is built and dependent on
HWMOD approach, it applies to all omap family of devices
(including all AM parts).
And, slowly we are moving towards adding DT support, and will take some
time to shape up.
Now as BeagleBone (based on AM335x) is picking up very fast and wide, we
will definitely have huge community base and hobbyist working on various
daughterboard's (aka capes) for the board. So it is required to maintain the
patches which will eventually make its way to mainline.
There is a strong felt need to maintain a kernel repository which closely
tracks Linux-omap and also provides a holding area for patches which cannot
be pushed upstream for various reasons (see below)"
1) We will host separate repository in github, maintaining various patches
for AM335x based BeagleBone -
Repo: g...@github.com:hvaibhav/am335x-linux.git (Still yet push the code)
- All required patches to get BeagleBone boot to the Linux prompt.
(Baseport: Voltage + Power + Clock + HWMOD + more)
- Device Tree patches
- Patches which are submitted to the respective maintainer or
This may include driver patches, platform hook up patch,
bug fixes, etc...
- Patches which can not be submitted to maintainer/sub-maintainer list
due to various known reasons, like, patches dependent on
baseport/driver which is not upstream yet.
As an example of how submissions will be accepted,
If someone would like to add support for SPI based LCD support,
then he will have spi client driver patch and platform hookup patch.
Client driver patch MUST be submitted to the subsystem
maintainer/list and I can/will merge it only after ack from
maintainer. Just send me a pull request once you have obtained
The platform hookup patch may be dependent on baseport, and can
not be submitted to the list; all such patches I will be queuing
it in my repo after review on the beagl...@googlegroups.com
2) The plan is to follow Linux-omap/master very closely and as and when it
is updated. I will try to rebase this bi-weekly.
3) We will use existing beagleboard mailing list
(beagl...@googlegroups.com) for both, discussion and for Patch
4) As part of rebasing process, I will apply TAG before re-writing history,
so that we retain commit-ids.
Please note that, this is not replacement for any external existing
The ONLY goal here is to, enable community to use latest and greatest kernel
from mainline with BeagleBone for their development.
|Re: [beagleboard] BeagleBone: Maintaining Sub-repository to ease upstream effort||Jason Kridner||2/6/12 9:53 AM|
On Monday, February 6, 2012, Hiremath, Vaibhav wrote:
Please inform us once you have pushed the code. Also, if you could inform the BeagleBoard community regarding the status on some on-going basis, you might solicit some community contributions to the effort. Robert Nelson in particular has done some useful work for his Ubuntu/Debian kernels and Koen on the Angstrom kernels. Folks looking for 1-wire, DT, PWM, pin ctrl and other support might also provide some useful contributions now that they are aware of this contribution path.
Thanks very much for volunteering to take on this important work while you are also focused on improving support for Sitara devices in the Linux mainline. I hope it is very synergistic work.
The code pushed to this tree should be also submitted to subsystem maintainer trees and followed-through on individually, so don't use this as a dumping grounds. That said, for people making add-on daughterboards (ie. "capes"), this is a place for us to collaborate together to clean-up support to push all cape support to mainline, especially cleaning up device tree and enabling device tree fragments in EEPROMs such that kernel modifications are not required for new capes where drivers for the various components already exist.
As this tree comes on-line, I'll either eliminate the github.com/beagleboard kernel, clone this tree into it or give vaibhav commit rights to it to keep it in sync. I'm open to community feedback on that.
BeagleBoard/BeagleBoard-xM cannot be abandoned, so we still need to solve any gaps in supporting staging of patches for that platform if mainline isn't there yet. It would be nice to have some feedback on the status of BeagleBoard/BeagleBoard-xM support in the mainline kernel today.
|RE: [beagleboard] BeagleBone: Maintaining Sub-repository to ease upstream effort||Hiremath, Vaibhav||2/6/12 10:16 AM|
Its already done...you can visit the repository and build the v3.3-rc1 kernel to get Linux prompt on BeagleBone.
> Also, if you could
Any contribution to get our code to mainline would be really helpful and
- Baseport: Clock and HWMOD
> Thanks very much for volunteering to take on this important work whileLets see how it works and shapes up in the future. My main focus still would
be to get all our code into mainline, and without everybody's help it would
be very hard for me.
> All,> --
> To join: http://beagleboard.org/discuss
> To unsubscribe from this group, send email to:
> Frequently asked questions: http://beagleboard.org/faq