u-boot, kernel, patches and mailing list

Dirk · April 6, 2008, 7:45am

I read IRC log from yesterday

http://www.beagleboard.org/irclogs/index.php?date=2008-04-05

Some comments

As discussed already in

http://groups.google.com/group/beagleboard/browse_thread/thread/96a61c7294a6f920

we shouldn't have additional beagle specific git repositories for uboot and kernel. The plan is to discuss uboot and kernel patches (against recent upstream git) on this list. Anybody then can grep them from this list and apply them until they are in upstream git. If we think that uboot and kernel patches discussed on this list are ready for upstream, we send them to uboot and omap vger list. If people help with bringing them upstream, this would be hopefully soon. With uboot we already started and are now waiting for the second patch series incorporating the first comments. kernel will follow hopefully soon.

In parallel, we will have complete "validated" source packages people not wanting to work with patches/git can download. Already there at

http://code.google.com/p/beagleboard/wiki/BeagleSourceCode

xloader git is okay and already there, though.

http://www.beagleboard.org/gitweb/

For uboot we should use uboot git as it is (still?) mainstream and the version supported by denx/Wolfgang. And not u-boot-v2.

Regarding mailing list: Okay, maybe googlegroups is not perfect But let us stay here as we already started with it. Switching mailing lists is a pain, on OMAP there are still people posting to the old list Let us add a rule "this list needs patches as attachments and not inlined" and everything should be okay.

Dirk

Bill_Gatliff · April 7, 2008, 1:58am

Dirk Behme wrote:

I read IRC log from yesterday

http://www.beagleboard.org/irclogs/index.php?date=2008-04-05

Some comments

As discussed already in

http://groups.google.com/group/beagleboard/browse_thread/thread/96a61c7294a6f920

I skimmed these, have a few comments-- but admittedly, I didn't read
them in-depth so take that fwiw...

we shouldn't have additional beagle specific git repositories for
uboot and kernel. The plan is to discuss uboot and kernel patches
(against recent upstream git) on this list. Anybody then can grep them
from this list and apply them until they are in upstream git. If we
think that uboot and kernel patches discussed on this list are ready
for upstream, we send them to uboot and omap vger list. If people help
with bringing them upstream, this would be hopefully soon. With uboot
we already started and are now waiting for the second patch series
incorporating the first comments. kernel will follow hopefully soon.

Disagree. If the "upstream git" you're referring to is Linus's git or
the OMAP git, then you want a branch off of them for beagleboard.
That's the easiest way for people to stay as closely in sync as possible.

In parallel with that, you could have a quilt/patch against OMAP or
Linus for those who aren't using git. But I've been working with git
now for a few weeks (came over from bzr, and svn before that), and it's
definitely the best way to keep everyone running with the latest stuff.

If someone submits a patch to beagleboard, all I have to do is git pull
to get it. And I can merge it in with my ongoing development efforts,
create sane patches back to the list, etc.

I'm not saying that you shouldn't do patch reviews on mailing lists,
etc. I just think that using git as the primary means of distributing
the accepted patches will prevent a lot of headaches for users, and a
lot of effort for maintainers.

b.g.

jkridner · April 7, 2008, 3:08am

I think the question is if the OMAP git will be updated enough to
avoid having a Beagle Board git. I guess if Tony isn't looking at
commits against the Beagle Board, then there could be a reason for us
to have our own. I at least want to hear 1 other person (not employed
by TI) explain why they think it is a good idea for us to have our own
git tree for Beagle.

If it creates any additional fragmentation, I'll think it is a bad
idea. Hopefully we all agree that the point is to get support
upstream in the fastest, easiest, and highest quality way possible.

Bill_Gatliff · April 7, 2008, 3:22am

Jadon wrote:

I think the question is if the OMAP git will be updated enough to
avoid having a Beagle Board git. I guess if Tony isn't looking at
commits against the Beagle Board, then there could be a reason for us
to have our own. I at least want to hear 1 other person (not employed
by TI) explain why they think it is a good idea for us to have our own
git tree for Beagle.

If it creates any additional fragmentation, I'll think it is a bad
idea. Hopefully we all agree that the point is to get support
upstream in the fastest, easiest, and highest quality way possible.

If we work as a branch from OMAP git, then there's no fragmentation and
our patches are automatically based on a tree that we ultimately want to
commit to. Doing otherwise seems to add to Tony's workload.

I propose that we maintain our own beagleboard git branch from OMAP, for
the volatile development. We also have a for-tony branch that Tony
pulls from when we ask him (nicely) to, which contains the stuff that we
want to proffer for mainline. We pull frequently from OMAP git to make
sure we stay in sync with that tree.

If Tony for some reason can't keep up with the latest CPUs, then our
branch will have the very latest stuff and he'll be more than grateful
to pull from our for-tony tree--- more toys for him, less work than
having to create them himself.

AFAICT, having a branch off of OMAP git seems to help prevent
fragmentation, because it's easier for us to stay in lockstep with Tony.
Seems like the smartest way to go about it.

What's your objection, again? Sorry I'm late to this conversation...

b.g.

jkridner · April 7, 2008, 4:35am

My only objection is that I want to listen to what the most active people on this list have to say. If Dirk thinks it is a bad idea, by default I think it is a bad idea. (Sorry to put you on the spot Dirk.) Further, I don't have a lot of experience running a git tree. I was able to set one up and have been able to continue making updates to my beagleboard.org.git (source to the website), but I haven't done fancier things like keeping branches or bringing in patches. My experience isn't sufficient to know which approach is best--they both seem workable to me.

If it will help to have our own git and to maintain the "for-tony" branch, then I will support it and make it happen. I have a lot of respect for both you and Dirk and would like to hear a non-TI tie-breaker. I'm primarily here to learn more than dictate--and to offer fun hardware and support.

-Jason

P.S. Bill, I currently have the group set to moderate any e-mail addresses not on the mailing list to avoid spam. You will continue to see a delay between your e-mail and the post based as long as you send from a different e-mail address than you used to register with Google Groups. No big deal, but I thought you should be aware.

Syed_Mohammed_Khasi1 · April 7, 2008, 5:18am

Hi Dirk, Bill,

Many thanks for this discussion, I just thought of bringout my views:

Beagle foundation is not just for kernel and u-boot, its also meant for application developers and many others who do not know the GIT usage so well. For them giving a complete source to start with will be a decent solution. So we need a complete kernel + u-boot + x-loader package.
It might not be good to direct these app developers to GIT kernel as major chunk of Display, camera and audio stuff is not on GIT.
Getting our display, audio, camera drivers on GIT will take some time, till then we can’t hold other users of Beagle.
So complete beagle source is good, but we have to decide on how we give this support to app developers and how we make our lifes easier for maintaining and pushing this content to Tony’s tree / upstream.
Giving complete source as a tar package makes our (kernel developer’s) life difficult as we cannot take a diff everytime a new change is done, we cannot pull in community’s changes easily.
Maintaining source on a GIT is also complex as we need a maintainer who actively works with Beagle and OMAP community and takes and maintains chagnes.
How about just giving quilt patches (for beagle) against latest Tony’s OMAP GIT tree on code.google.com. If some one has a fix we can just add that patch to the Series file and patch folder. These patches can be separated based on functionality and bug fixes, we can just maintain these patch set. This is easier for kernel developers and to app developers.

Any suggestions.

Regards,
Khasim

Dirk · April 7, 2008, 7:23pm

Syed Mohammed, Khasim wrote:

Hi Dirk, Bill,

Many thanks for this discussion,

Yes, having this discussion is quite good!

I just thought of bringout my views:

1) Beagle foundation is not just for kernel and u-boot, its also meant
for application developers and many others who do not know the GIT usage
so well.

Yes. And "...maybe beagle developers/administrators don't want to
maintain a git repository"

For them giving a complete source to start with will be a
decent solution. So we need a complete kernel + u-boot + x-loader package.

Agree. This is already there.

2) It might not be good to direct these app developers to GIT kernel as
major chunk of Display, camera and audio stuff is not on GIT.

Yes. This was what I meant with "give them a 'validated' complete
kernel for download". And this is already there.

3) Getting our display, audio, camera drivers on GIT will take some
time,

but I can understand this

till then we can't hold other users of Beagle.

Agree.

4) So complete beagle source is good, but we have to decide on how we
give this support to app developers and how we make our lifes easier for
maintaining and pushing this content to Tony's tree / upstream.

"... pushing this content to Tony's tree / upstream": Yes, I think
this is the key point of the discussion:

Do we want to push our patches as fast as possible / as easy as
possible *upstream* with goal "Tony's OMAP kernel git == BeagleKernel
git" (*)? Or do we want to pull Tony's tree regularly into our own
Beagle kernel git and *maybe* sometime push beagle patches upstream?

For me, we should focus our (limited!?) resources on upstream pushing,
and not "wasting" them with maintaining a local git repository and
never having resources for upstream patches.

(*) Sorry but from kernel git point of view BeagleBoard is just one
additional board to the > 10 OMAP based boards already maintained in
Tony's tree. Why should we handle this board other than the way the
other boards are gone into Tony's tree?

5) Giving complete source as a tar package makes our (kernel
developer's) life difficult as we cannot take a diff everytime a new
change is done, we cannot pull in community's changes easily.

6) Maintaining source on a GIT is also complex as we need a maintainer
who actively works with Beagle and OMAP community and takes and
maintains chagnes.

Yes. Dirk says "don't waste time for this complex task" Let us use
existing upstream resources for this.

Sorry, but e.g. learning from DaVinci, it's my feeling that for a lot
of people even sending a more or less clean patch to a ML isn't an
easy job. So concentrate on getting patches, improve them, support
patch review cylces and then send them upstream etc.

7) How about just giving quilt patches (for beagle) against latest
Tony's OMAP GIT tree on code.google.com <http://code.google.com>.

Sorry, which git tree on http://code.google.com? Tony's tree is hosted
by MV mirrored to kernel.org.

If
some one has a fix we can just add that patch to the Series file and
patch folder. These patches can be separated based on functionality and
bug fixes, we can just maintain these patch set. This is easier for
kernel developers and to app developers.

Yes, I think this is a good idea. The exact way we technically handle
this depends on the number of patches we expect. E.g. for DaVinci, it
works quite well to have a up to date list which patches are still not
in git

http://wiki.davincidsp.com/index.php?title=Linux_patches#Pending_patches

With <= 10 patches per week this should work. If we need to improve
this, we can provide patch series.

Any suggestions.

Two additional thoughts:

- Timeframe: How many patches do we expect? Hopefully in the next 2-3
month we should have basic BeagleBoard support patches. Once these are
in upstream (== Tony's git), we can send additional patches to Tony as
all other people do for all other boards. I don't think we really need
a git for this.

- Laziness: With not having a beagle kernel/uboot git tree we force
people (TI? ) to care about upstream sending. If we use a local
git repository our "customers" are happy and there is not really the
need (time?) to care about upstream sending. But if upstream git
repository is the only repository we have, people are "forced" to care
that their stuff will be in there. And, before complaining that it is
hard to get something upstream, remember that Tony is not RMK and
pushes patches more or less in a good shape quite fast.

I'd like to avoid what happend with (TI) OMAP kernels e.g. on

http://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?templateId=6123&contentId=4750

From time to time there are new kernels. Nobody notices changes.
There might be quite nice features and bug fixes in them. But nobody
cares getting them into Tony's git. Sometimes a developer from OMAP ML
takes one kernel, picks some fixes from it and sends them to OMAP
list. But this is a pain and really rare.

Many thanks for this discussion!

Dirk

Dirk · April 7, 2008, 7:33pm

This thread fragmented, so I tried to answer some points in my previous post. Some add ons:

Bill Gatliff wrote:

Jadon wrote:

I think the question is if the OMAP git will be updated enough to
avoid having a Beagle Board git. I guess if Tony isn't looking at
commits against the Beagle Board, then there could be a reason for us
to have our own. I at least want to hear 1 other person (not employed
by TI) explain why they think it is a good idea for us to have our own
git tree for Beagle.

If it creates any additional fragmentation, I'll think it is a bad
idea. Hopefully we all agree that the point is to get support
upstream in the fastest, easiest, and highest quality way possible.

If we work as a branch from OMAP git, then there's no fragmentation and our patches are automatically based on a tree that we ultimately want to commit to. Doing otherwise seems to add to Tony's workload.

I propose that we maintain our own beagleboard git branch from OMAP, for the volatile development. We also have a for-tony branch that Tony pulls from when we ask him (nicely) to, which contains the stuff that we want to proffer for mainline. We pull frequently from OMAP git to make sure we stay in sync with that tree.

I see it the other way around: We push frequently patches to OMAP git to make sure that OMAP git stays in sync with our work.

If Tony for some reason can't keep up with the latest CPUs,

... then we should help him to get the patches he need to keep up with latest CPUs.

> then our

branch will have the very latest stuff and he'll be more than grateful to pull from our for-tony tree--- more toys for him, less work than having to create them himself.

AFAICT, having a branch off of OMAP git seems to help prevent fragmentation,

For me, having two gits (Tony's OMAP git and a beagle git) is the biggest fragmentation we can have.

because it's easier for us to stay in lockstep with Tony. Seems like the smartest way to go about it.

What's your objection, again? Sorry I'm late to this conversation...

Sorry, but regarding kernel (and uboot) I can't really understand why we need an additional git for "just an other OMAP based board", while all other people live fine with sending their board patches to OMAP ML.

Anyway, thanks for the discussion,

Dirk

Dirk · April 7, 2008, 7:42pm

Dirk Behme wrote:

AFAICT, having a branch off of OMAP git seems to help prevent fragmentation,

For me, having two gits (Tony's OMAP git and a beagle git) is the biggest fragmentation we can have.

Ah, just in this second a quite good example came in:

http://linux.omap.com/pipermail/davinci-linux-open-source/2008-April/006076.html

Do you think creating a special git repository for this was a good idea? Will anybody ever look into his changes *and* push them back to TI/DaVinci Gstreamer main? Or even official Gstream upstream main? Or would it have been a better idea to create some patches and send them to DaVinci list, Z3 and Gstreamer upstream and ask for inclusion?

Dirk

Bill_Gatliff · April 7, 2008, 8:29pm

Dirk:

Dirk Behme wrote:

Dirk Behme wrote:

AFAICT, having a branch off of OMAP git seems to help prevent
fragmentation,

For me, having two gits (Tony's OMAP git and a beagle git) is the
biggest fragmentation we can have.

Ah, just in this second a quite good example came in:

http://linux.omap.com/pipermail/davinci-linux-open-source/2008-April/006076.html

Do you think creating a special git repository for this was a good
idea? Will anybody ever look into his changes *and* push them back to
TI/DaVinci Gstreamer main? Or even official Gstream upstream main? Or
would it have been a better idea to create some patches and send them
to DaVinci list, Z3 and Gstreamer upstream and ask for inclusion?

Set up a system that works for you.

Since Jason hasn't even sent me any Beagle hardware, my input is quite
theoretical at this point. Them with the hardware calls the shots.

b.g.

Trilok_Soni · April 8, 2008, 8:31am

Hi Dirk,

This thread fragmented, so I tried to answer some points in my
previous post. Some add ons:

Bill Gatliff wrote:
> Jadon wrote:
>
>>I think the question is if the OMAP git will be updated enough to
>>avoid having a Beagle Board git. I guess if Tony isn't looking at
>>commits against the Beagle Board, then there could be a reason for us
>>to have our own. I at least want to hear 1 other person (not employed
>>by TI) explain why they think it is a good idea for us to have our own
>>git tree for Beagle.
>>
>>If it creates any additional fragmentation, I'll think it is a bad
>>idea. Hopefully we all agree that the point is to get support
>>upstream in the fastest, easiest, and highest quality way possible.
>
>
> If we work as a branch from OMAP git, then there's no fragmentation and
> our patches are automatically based on a tree that we ultimately want to
> commit to. Doing otherwise seems to add to Tony's workload.
>
> I propose that we maintain our own beagleboard git branch from OMAP, for
> the volatile development. We also have a for-tony branch that Tony
> pulls from when we ask him (nicely) to, which contains the stuff that we
> want to proffer for mainline. We pull frequently from OMAP git to make
> sure we stay in sync with that tree.

I see it the other way around: We push frequently patches to OMAP git
to make sure that OMAP git stays in sync with our work.

I agree with this. We will have additional burden of maintenance of
kernel and bootloader git tree specific for beagle, and non-board
specific changes like new drivers would be tough to push, first to
OMAP GIT and then taking it to upstream. It would be better if we
directly
submit patches related to beagle for kernel and bootloader to OMAP GIT
and u-boot ML directly. We have done this in past for OMAP5910 OSK
kernel.

> If Tony for some reason can't keep up with the latest CPUs,

... then we should help him to get the patches he need to keep up with

latest CPUs.

> then our
> branch will have the very latest stuff and he'll be more than grateful
> to pull from our for-tony tree--- more toys for him, less work than
> having to create them himself.
>
> AFAICT, having a branch off of OMAP git seems to help prevent
> fragmentation,

For me, having two gits (Tony's OMAP git and a beagle git) is the
biggest fragmentation we can have.

I agree.

> because it's easier for us to stay in lockstep with Tony.
> Seems like the smartest way to go about it.
>
> What's your objection, again? Sorry I'm late to this conversation...

Sorry, but regarding kernel (and uboot) I can't really understand why
we need an additional git for "just an other OMAP based board", while
all other people live fine with sending their board patches to OMAP ML.

One of the point raised by Syed for video and audio related drivers
were out of sync with OMAP GIT, but in this case we have to work with
OMAP GIT or upstream subsystem in-order to resolve this issue and just
for this issue we don't need to setup new GIT trees for kernel and
bootloader. Also x-loader tree exists at source.mvista.com and
Kyungmin Park maintains this tree for various boards.

Syed_Mohammed_Khasi1 · April 8, 2008, 2:22pm

Even I am against hosting / maintaining a separate GIT tree for Beagle :).

But my interest is in supporting APP developers. It is not just me I mean “WE”. Example: If Dirk fixes a DVI bug tomorrow how does an app guy get this? how and where should he apply.

Please NOTE: our current drop is 2.6.22 and not in sync with Tony’s OMAP tree. Till we have our complete code base in Tony’s tree we also have to keep supporting our APP friends other wise we will end up beagle with a board for kernel developers only (me included).

So my approach was :

Lets port complete driver set to latest tony’s OMAP tree (by cloning it locally)
Give our changes as a quilt patch set on code.google.com.
code.google.com will have a directory and a series file,
Developers should clone a OMAP GIT tree, copy the patches directory and series file to their copy and do a quilt push.
They will get code for Beagle.
We can start pushing patches to OMAP GIT, also keep adding/deleting the patches from directory on code.google.com.
Once a patch is accepted in Tony’s tree, we will delete from code.google.com (quilt patch directory).
A new bug fix or enhancement will be added against OMAP GIT tree and a patch will be placed in quilt patch directory and series file will be updated, also will be submitted to Tony’s tree.

This way we will address concerns of both kernel and app developers. Do you see any issues with the same?

Regards,
Khasim

Trilok_Soni · April 8, 2008, 4:11pm

Hi Syed,

Dirk · April 8, 2008, 6:48pm

Trilok Soni wrote:

Also x-loader tree exists at source.mvista.com and
Kyungmin Park maintains this tree for various boards.

Actually, it seems it isn't there any more:

http://source.mvista.com/git/

But you are right, I remember that it *was* there.

Dirk

Dirk · April 8, 2008, 7:01pm

Syed Mohammed, Khasim wrote:

    Hi Dirk,

     >
     > This thread fragmented, so I tried to answer some points in my
     > previous post. Some add ons:
     >
     > Bill Gatliff wrote:
     > > Jadon wrote:
     > >
     > >>I think the question is if the OMAP git will be updated enough to
     > >>avoid having a Beagle Board git. I guess if Tony isn't looking at
     > >>commits against the Beagle Board, then there could be a reason
    for us
     > >>to have our own. I at least want to hear 1 other person (not
    employed
     > >>by TI) explain why they think it is a good idea for us to have
    our own
     > >>git tree for Beagle.
     > >>
     > >>If it creates any additional fragmentation, I'll think it is a bad
     > >>idea. Hopefully we all agree that the point is to get support
     > >>upstream in the fastest, easiest, and highest quality way
    possible.
     > >
     > > If we work as a branch from OMAP git, then there's no
    fragmentation and
     > > our patches are automatically based on a tree that we
    ultimately want to
     > > commit to. Doing otherwise seems to add to Tony's workload.
     > >
     > > I propose that we maintain our own beagleboard git branch from
    OMAP, for
     > > the volatile development. We also have a for-tony branch that
    Tony
     > > pulls from when we ask him (nicely) to, which contains the
    stuff that we
     > > want to proffer for mainline. We pull frequently from OMAP
    git to make
     > > sure we stay in sync with that tree.
     >
     > I see it the other way around: We push frequently patches to
    OMAP git
     > to make sure that OMAP git stays in sync with our work.

    I agree with this. We will have additional burden of maintenance of
    kernel and bootloader git tree specific for beagle, and non-board
    specific changes like new drivers would be tough to push, first to
    OMAP GIT and then taking it to upstream. It would be better if we
    directly
    submit patches related to beagle for kernel and bootloader to OMAP GIT
    and u-boot ML directly. We have done this in past for OMAP5910 OSK
    kernel.

     >
     > > If Tony for some reason can't keep up with the latest CPUs,
     >
     > ... then we should help him to get the patches he need to keep
    up with
     >
     > latest CPUs.
     >
     > > then our
     > > branch will have the very latest stuff and he'll be more than
    grateful
     > > to pull from our for-tony tree--- more toys for him, less work
    than
     > > having to create them himself.
     > >
     > > AFAICT, having a branch off of OMAP git seems to help prevent
     > > fragmentation,
     >
     > For me, having two gits (Tony's OMAP git and a beagle git) is the
     > biggest fragmentation we can have.
     >

    I agree.

     >
     > > because it's easier for us to stay in lockstep with Tony.
     > > Seems like the smartest way to go about it.
     > >
     > > What's your objection, again? Sorry I'm late to this
    conversation...
     >
     > Sorry, but regarding kernel (and uboot) I can't really
    understand why
     > we need an additional git for "just an other OMAP based board",
    while
     > all other people live fine with sending their board patches to
    OMAP ML.
     >

    One of the point raised by Syed for video and audio related drivers
    were out of sync with OMAP GIT, but in this case we have to work with
    OMAP GIT or upstream subsystem in-order to resolve this issue and just
    for this issue we don't need to setup new GIT trees for kernel and
    bootloader. Also x-loader tree exists at source.mvista.com
    <http://source.mvista.com> and
    Kyungmin Park maintains this tree for various boards.

Even I am against hosting / maintaining a separate GIT tree for Beagle :).
But my interest is in supporting APP developers. It is not just me I mean "WE". Example: If Dirk fixes a DVI bug tomorrow how does an app guy get this? how and where should he apply.
Please NOTE: our current drop is 2.6.22 and not in sync with Tony's OMAP tree. Till we have our complete code base in Tony's tree we also have to keep supporting our APP friends other wise we will end up beagle with a board for kernel developers only (me included).
So my approach was :
1. Lets port complete driver set to latest tony's OMAP tree (by cloning it locally)

Just to align our understanding: "cloning locally" means on "my" local harddisk, not visible to anybody else, just to create a (quilt) patch against it. And the quilt patch (+series) will then be publically available?

2. Give our changes as a quilt patch set on code.google.com <http://code.google.com>.
3. code.google.com <http://code.google.com> will have a directory and a series file,
4. Developers should clone a OMAP GIT tree, copy the patches directory and series file to their copy and do a quilt push.
5. They will get code for Beagle.
6. We can start pushing patches to OMAP GIT, also keep adding/deleting the patches from directory on code.google.com <http://code.google.com>.
7. Once a patch is accepted in Tony's tree, we will delete from code.google.com <http://code.google.com> (quilt patch directory).
8. A new bug fix or enhancement will be added against OMAP GIT tree and a patch will be placed in quilt patch directory and series file will be updated, also will be submitted to Tony's tree.
This way we will address concerns of both kernel and app developers. Do you see any issues with the same?

No, I like this! Thanks!

Technically, this is a *improved* version (quilt etc.) from what we are doing currently with DaVinci (simply linking to patches on ML).

Seems to me that we agreed now to this (?).

Then, the next steps would be:

- Write this down somewhere. beagleboard.org page "how you can contribute and beagle board (kernel) patches are handled"?

- Let us create patches now!

Thanks, was a good discussion!

Dirk

Syed_Mohammed_Khasi1 · April 10, 2008, 11:48am

This way we will address concerns of both kernel and app developers. Do
you see any issues with the same?

No, I like this! Thanks!

Technically, this is a improved version (quilt etc.) from what we
are doing currently with DaVinci (simply linking to patches on ML).

Seems to me that we agreed now to this (?).

Thanks that we agreed on this.

Then, the next steps would be:

Write this down somewhere. beagleboard.org page “how you can
contribute and beagle board (kernel) patches are handled”?

Yes will do this.

Let us create patches now!

Will generate a quick one for OMAP3530 EVM as others are waiting for this and do similar stuff for Beagle as well.

Thanks, was a good discussion!

Thanks again.

Regards,
Khasim

Dirk · April 10, 2008, 3:22pm

Syed Mohammed, Khasim wrote:

     > This way we will address concerns of both kernel and app
    developers. Do
     > you see any issues with the same?

    No, I like this! Thanks!

    Technically, this is a *improved* version (quilt etc.) from what we
    are doing currently with DaVinci (simply linking to patches on ML).

    Seems to me that we agreed now to this (?).

Thanks that we agreed on this.

    Then, the next steps would be:

    - Write this down somewhere. beagleboard.org
    <http://beagleboard.org> page "how you can
    contribute and beagle board (kernel) patches are handled"?

Yes will do this.

    - Let us create patches now!

Do you like to take the uboot patches I sent yesterday and put them on the beagle google page? I'd like an example how you think we should do it

Will generate a quick one for OMAP3530 EVM as others are waiting for this and do similar stuff for Beagle as well.

Do you track beagle IRC?

If I understand

http://www.beagleboard.org/irclogs/index.php?date=2008-04-09#T18:04:45

correctly, "sakoman" has EVM patches against OMAP git.

Best regards

Dirk

Koen_Kooi2 · April 10, 2008, 5:25pm

Steve has his own wikipedia page: http://en.wikipedia.org/wiki/Steve_Sakoman

regards,

Koen

Syed_Mohammed_Khasi1 · April 13, 2008, 2:39pm

Thanks, will check this out.

Regards,
Khasim