The sources for the Beagle Linux kernel and boot utilities are now
available on http://code.google.com/p/beagleboard site under
Jason Kridner wrote:
>>Syed Mohammed, Khasim wrote:
>>>I prefer a code snap shot and GIT both available to Beagle users.
>>>- The code snap shot will be on our beagleboard.org and
>>>code.google.com (this has size limitations).
>>I don't know X-loader, most probably we need complete source?
> X-loader can be used across other OMAP boards, but it probably makes
> sense to maintain it on beagleboard.org until there is some other
> public maintainer.
Yes, sounds good!
X-loader source is there. A public maintainer still needs to be
>>But for kernel and u-boot, it would be sufficent to have patches
>>against recent upstream git (Tonys OMAP git and denx uboot git). Why
>>having additional complete source code repositries wasting disk space
>>somewhere if patches are sufficent?
> When I first created the repositories, my thought was that it would
> provide a staging area for the patches and allow those folks
> interested in the board to have patches for it right away. Neither of
> those two thoughts turn out to make sense.
Patches still need to be created against the public tree. I haven't
seen anyone else post those here or to firstname.lastname@example.org
yet. It is on the task list. If anyone wants to perform the diff and
share it here if it is a reasonably small diff right now, that would
>>I propose to first send initial beagle board u-boot and kernel patches
>>against recent upstream git to this list. Then we can discuss, review
>>(and people with a board) test them until we think they are ready for
>>u-boot and OMAP list. People wanting to play with the patches can grep
>>them from ML archive (1). So I propose to send to this list what is
>>available. Then we iterate as long as everybody is happy with the
>>patches. As known from OMAP or u-boot list. And then we send them to
>>u-boot and OMAP list for upstream merge.
>>How the patches are created, with git or quilt, doesn't matter.
>>Does this make sense?
> Yes, and I agree. Whoever can decide how they'd like to present the
> A set of tarballs is still useful for those not looking to participate
> and looking for ease of access.
Yes, putting the patches (tarballs) somewhere can help. Something like
Tony does with the OMAP patches at muru.com.
But we should avoid anything like (from TI?) e.g. on
If you there click on a "kernel" link, you get a > 50MB tarball
*only*. This would be helpful if there would be *additionally* a
patch, where you can see what is different to upstream kernel. But
with this, if you only need the differences, you have to download >
50MB, get the kernel version, get the clean upstream kernel, diff them
and then you know what is different.
I agree this is a problem. Hopefully the current diff is small. I
agree it should happen at TI and not be pushed off to the outside, but
I'm hopeful the diff is small right now.
If I remember correctly, on OMAP list there are from time to time some
patches "I took the TI kernel (from above links), had a look to them,
they do really nice bugfixes there, extracted them and here are the
patches". A lot of pain somebody has to do just because there are no
easy to use patches (and nobody cares about sending them upstream?).
Let us avoid this
Agreed. All development should happen against the public tree. If
there are features to be added, they should be added against the
public tree. We aren't ready for developers until we have something
So best would be to have only patches. Or if you like to put complete
kernel/u-boot tar balls somewhere, add the differences in an
additional patch file to the same place.
Regarding patches, I think the easiest way is what we do e.g. with
DaVinci patches. They are sent to DaVinci list (and not put
additionally somewhere else) and we then maintain a link list with
"latest DaVinci patches" pointing to mailing list archive:
I still need to read this and learn how your are doing this link-
>>If this makes sense: Once we have the recent patches on this list,
>>will it make sense to remove linux.git and u-boot.git from
>>Or did I miss why beagle board u-boot and kernel git trees are
> I don't think you missed it. They can be removed right away. I never
> even meant to really promote them.
I'll remove them later today, even though we still don't have patches
>>Regarding X-loader: Maybe a git repository for this at
> Yes, it makes sense.
Will add that when I delete the others.