Beagle board kernel patch
Dirk Behme
I just took
http://www.beagleboard.org/gitweb/?p=linux.git;a=commit;h=7dc52e0ee406b0e5f0759472f3638105ae0a23ab
and updated it against recent OMAP git tree plus some minor cleanup.
Compile tested only result in attachment.
For easier usage, I adapted toolchain prefix for CodeSourcery toolchain
http://www.codesourcery.com/gnu_toolchains/arm
Once we send this to OMAP list for inclusion, we have to remove that
again.
Best regards
Dirk
koen
> and updated it against recent OMAP git tree plus some minor cleanup.
> Compile tested only result in attachment.
> +CONFIG_TWL4030_GPIO=y
> +# CONFIG_TWL4030_USB is not set
Doesn't the above mean that this doesn't work:
> +CONFIG_USB_SUPPORT=y
> +CONFIG_USB_ARCH_HAS_HCD=y
> +CONFIG_USB_ARCH_HAS_OHCI=y
> +CONFIG_USB_ARCH_HAS_EHCI=y
or and I confusing usb OTG and dedicated host again?
regards,
Koen
Dirk Behme
I didn't look into any configuration details. Just tried compilation.
Anybody (from TI?) can answer this?
Thanks
Dirk
Syed Mohammed, Khasim
Many thanks for your effort.
Hi all,
I wanted to put a GIT patch out this weekend but got pulled into some
other personal stuff :(
By next week, I want to complete:
1. OMAPT GIT patch for working Beagle kernel.
2. Get complete source (for u-boot, X-loader and kernel) to you all.
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).
- The GIT can be maintained on beagleboard.org as we are doing today.
Do you think Quilt is better? or only the GIT?
Quilt is better and easier for doing a merge with Tony's GIT tree.
Please give your suggestions.
Thanks for all the effort and support, I look forward to this .... :).
Regards,
Khasim
Jason Kridner
The contents of the GIT tree are old. They are for rev 1 of the
Beagle board, which did not have working USB. Khasim should be
sharing the new patches soon.
Dirk Behme
I don't know X-loader, most probably we need complete source?
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?
It should be our goal to have beagle board u-boot and kernel patches
merged as fast as possible upstream. So possible complete source code
repositories will make sense, if so, only for the limited time while
beagle board support isn't merged upstream yet. When patches are
merged upstream, people will use denx u-boot git and Tonys kernel for
beagle board. Then any additional git trees for these are outdated and
waste of time to maintain them.
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?
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
http://www.beagleboard.org/gitweb/
then?
Or did I miss why beagle board u-boot and kernel git trees are necessary?
Regarding X-loader: Maybe a git repository for this at
http://www.beagleboard.org/gitweb/
makes sense?
Best regards
Dirk
(1) Btw: Any special reason why access to the *archive* of this list
needs login?
Dirk Behme
>
> On Mar 30, 2008, at 9:09 AM, Dirk Behme wrote:
>
>>koen wrote:
>>
>>>On 30 mrt, 15:17, Dirk Behme <dirk.be...@googlemail.com> wrote:
>>>
>>>>+CONFIG_TWL4030_CORE=y
>>>>+CONFIG_TWL4030_GPIO=y
>>>>+# CONFIG_TWL4030_USB is not set
>>>
>>>
>>>Doesn't the above mean that this doesn't work:
>>>
>>>
>>>
>>>>+CONFIG_USB_SUPPORT=y
>>>>+CONFIG_USB_ARCH_HAS_HCD=y
>>>>+CONFIG_USB_ARCH_HAS_OHCI=y
>>>>+CONFIG_USB_ARCH_HAS_EHCI=y
>>>
>>>
>>>or and I confusing usb OTG and dedicated host again?
>>
>>I didn't look into any configuration details. Just tried compilation.
>>
>>Anybody (from TI?) can answer this?
>
>
> The contents of the GIT tree are old.
One reason to *not* have these trees? Instead send most up to date
patches to the list? See my mail I sent some minutes ago, too.
Dirk
Jason Kridner
On Mar 30, 2008, at 12:40 PM, Dirk Behme wrote:
>
> Syed Mohammed, Khasim wrote:
>>
>> Many thanks for your effort.
>>
>> Hi all,
>>
>> I wanted to put a GIT patch out this weekend but got pulled into some
>> other personal stuff :(
>>
>> By next week, I want to complete:
>>
>> 1. OMAPT GIT patch for working Beagle kernel.
>>
>> 2. Get complete source (for u-boot, X-loader and kernel) to you all.
>>
>> 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).
>>
>> - The GIT can be maintained on beagleboard.org as we are doing today.
>>
>> Do you think Quilt is better? or only the GIT?
>>
>> Quilt is better and easier for doing a merge with Tony's GIT tree.
>>
>> Please give your suggestions.
>
> 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.
>
> 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.
>
> It should be our goal to have beagle board u-boot and kernel patches
> merged as fast as possible upstream. So possible complete source code
> repositories will make sense, if so, only for the limited time while
> beagle board support isn't merged upstream yet. When patches are
> merged upstream, people will use denx u-boot git and Tonys kernel for
> beagle board. Then any additional git trees for these are outdated and
> waste of time to maintain them.
>
> 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
patches.
A set of tarballs is still useful for those not looking to participate
and looking for ease of access.
>
>
> 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
>
> http://www.beagleboard.org/gitweb/
>
> then?
>
> Or did I miss why beagle board u-boot and kernel git trees are
> necessary?
I don't think you missed it. They can be removed right away. I never
even meant to really promote them.
> Regarding X-loader: Maybe a git repository for this at
>
> http://www.beagleboard.org/gitweb/
>
> makes sense?
Yes, it makes sense.
>
>
> Best regards
>
> Dirk
>
> (1) Btw: Any special reason why access to the *archive* of this list
> needs login?
This should be fixed now. It was the default. It is nice to know who
is monitoring the list and to get folks to sign up, but it is better
to simply have people monitoring the list!
Dirk Behme
>
> On Mar 30, 2008, at 12:40 PM, Dirk Behme wrote:
>
>>Syed Mohammed, Khasim wrote:
>>
>>>Many thanks for your effort.
>>>
>>>Hi all,
>>>
>>>I wanted to put a GIT patch out this weekend but got pulled into some
>>>other personal stuff :(
>>>
>>>By next week, I want to complete:
>>>
>>>1. OMAPT GIT patch for working Beagle kernel.
>>>
>>>2. Get complete source (for u-boot, X-loader and kernel) to you all.
>>>
>>>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).
>>>
>>>- The GIT can be maintained on beagleboard.org as we are doing today.
>>>
>>>Do you think Quilt is better? or only the GIT?
>>>
>>>Quilt is better and easier for doing a merge with Tony's GIT tree.
>>>
>>>Please give your suggestions.
>>
>>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!
>>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.
Okay ;)
>>It should be our goal to have beagle board u-boot and kernel patches
>>merged as fast as possible upstream. So possible complete source code
>>repositories will make sense, if so, only for the limited time while
>>beagle board support isn't merged upstream yet. When patches are
>>merged upstream, people will use denx u-boot git and Tonys kernel for
>>beagle board. Then any additional git trees for these are outdated and
>>waste of time to maintain them.
>>
>>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
> patches.
>
> 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
http://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?templateId=6123&contentId=4750
http://linux.omap.com/pub/kernel/3430sdp/
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.
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 ;)
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:
http://wiki.davincidsp.com/index.php?title=Linux_patches#Pending_patches
>>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
>>
>>http://www.beagleboard.org/gitweb/
>>
>>then?
>>
>>Or did I miss why beagle board u-boot and kernel git trees are
>>necessary?
>
> I don't think you missed it. They can be removed right away. I never
> even meant to really promote them.
;)
>>Regarding X-loader: Maybe a git repository for this at
>>
>>http://www.beagleboard.org/gitweb/
>>
>>makes sense?
>
> Yes, it makes sense.
>
>>Best regards
>>
>>Dirk
>>
>>(1) Btw: Any special reason why access to the *archive* of this list
>>needs login?
>
> This should be fixed now. It was the default. It is nice to know who
> is monitoring the list and to get folks to sign up, but it is better
> to simply have people monitoring the list!
Many thanks!
This all sounds great!
Dirk
Jadon
available on http://code.google.com/p/beagleboard site under
http://code.google.com/p/beagleboard/wiki/BeagleSourceCode.
On Mar 31, 12:27 am, Dirk Behme <dirk.be...@googlemail.com> wrote:
> Jason Kridner wrote:
> > On Mar 30, 2008, at 12:40 PM, Dirk Behme 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).
>
>
> > 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!
identified.
> >>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.
>
> Okay ;)
seen anyone else post those here or to linux...@vger.kernel.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
be welcome.
> >>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
> > patches.
>
> > 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
>
> http://linux.omap.com/pub/kernel/3430sdp/
>
> 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.
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 ;)
there are features to be added, they should be added against the
public tree. We aren't ready for developers until we have something
upstream.
>
> 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:
>
> http://wiki.davincidsp.com/index.php?title=Linux_patches#Pending_patches
listing.
>
> >>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
>
> >>http://www.beagleboard.org/gitweb/
>
> >>then?
>
> >>Or did I miss why beagle board u-boot and kernel git trees are
> >>necessary?
>
> > I don't think you missed it. They can be removed right away. I never
> > even meant to really promote them.
quite yet.
> >>Regarding X-loader: Maybe a git repository for this at
>
> >>http://www.beagleboard.org/gitweb/
>
> >>makes sense?
>
> > Yes, it makes sense.
>
Dirk Behme
> The sources for the Beagle Linux kernel and boot utilities are now
> available on http://code.google.com/p/beagleboard site under
> http://code.google.com/p/beagleboard/wiki/BeagleSourceCode.
Great! Many thanks!
Not a big thing, but is there a special reason why most stuff on this
page is saved on
http://beagleboard.googlecode.com/files/
but kernel on
http://www.beagleboard.org/uploads/
? Does googlecode has size limitation?
> On Mar 31, 12:27 am, Dirk Behme <dirk.be...@googlemail.com> wrote:
>
>>Jason Kridner wrote:
>>
>>>On Mar 30, 2008, at 12:40 PM, Dirk Behme 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
> identified.
Thanks!
Are there any documents describing the protocol X-loader implements?
>>>>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.
>>
>>Okay ;)
>
> Patches still need to be created against the public tree. I haven't
> seen anyone else post those here or to linux...@vger.kernel.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
> be welcome.
Okay. If I got it right, for kernel patch we have to:
- Download
http://www.beagleboard.org/uploads/2.6_kernel-beagle-rev2.tar.gz
- Diff it against 2.6.22-omap1
- Port resulting patch to recent OMAP git (currently 2.6.25-rc7)
And similiar for U-Boot.
?
What is the difference of the 2.6_kernel-beagle-rev2.tar.gz kernel to
the kernel we had till yesterday in git and I did
http://groups.google.com/group/beagleboard/browse_thread/thread/96a61c7294a6f920
?
Just to get a better understanding, what is the problem with directly
creating a patch?
>>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
> upstream.
Yes.
Seems this is done :)
Many thanks
Dirk
Dirk Behme
> Jadon wrote:
...
>> Patches still need to be created against the public tree. I haven't
>> seen anyone else post those here or to linux...@vger.kernel.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
>> be welcome.
>
>
> Okay. If I got it right, for kernel patch we have to:
>
> - Download
>
> http://www.beagleboard.org/uploads/2.6_kernel-beagle-rev2.tar.gz
>
> - Diff it against 2.6.22-omap1
No. Tried it. It does *not* work. What a kernel is
2.6_kernel-beagle-rev2.tar.gz
??
It tells 2.6.22.1-omap1. But it isn't :(
Stopped diffing a clean 2.6.22.1-omap1 and above
2.6_kernel-beagle-rev2.tar.gz after diff was > 4MB and > 100 files.
Or did I miss anything?
Regards
Dirk
Jason Kridner
On Apr 1, 2008, at 12:46 PM, Dirk Behme wrote:
>
> Jadon wrote:
>> The sources for the Beagle Linux kernel and boot utilities are now
>> available on http://code.google.com/p/beagleboard site under
>> http://code.google.com/p/beagleboard/wiki/BeagleSourceCode.
>
> Great! Many thanks!
>
> Not a big thing, but is there a special reason why most stuff on this
> page is saved on
>
> http://beagleboard.googlecode.com/files/
>
> but kernel on
>
> http://www.beagleboard.org/uploads/
>
> ? Does googlecode has size limitation?
Exactly. I've applied to increase the overall total, but I'm not sure
where to ask for the per-file quota to be increased.
>>
>
> Are there any documents describing the protocol X-loader implements?
>>
I don't know. I thought the code was easy enough to follow. I'll
look into that.
>>>
>>
>> Patches still need to be created against the public tree. I haven't
>> seen anyone else post those here or to linux...@vger.kernel.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
>> be welcome.
>
> Okay. If I got it right, for kernel patch we have to:
>
> - Download
>
> http://www.beagleboard.org/uploads/2.6_kernel-beagle-rev2.tar.gz
>
> - Diff it against 2.6.22-omap1
>
> - Port resulting patch to recent OMAP git (currently 2.6.25-rc7)
>
> And similiar for U-Boot.
>
> ?
Yikes. I suppose so. I thought Khasim had gone back to the git tree
for the latest kernel version, but I suppose not. It must still be
based off of the WTBU kernel. We need to undo that!
>
> What is the difference of the 2.6_kernel-beagle-rev2.tar.gz kernel to
> the kernel we had till yesterday in git and I did
>
> http://groups.google.com/group/beagleboard/browse_thread/thread/96a61c7294a6f920
>
> ?
The big differences I know about between the one that was in the (now
deleted) git and the tar that exists now is support for the rev2 board
with EHCI and MUSB.
>>
>
> Just to get a better understanding, what is the problem with directly
> creating a patch?
For me, it is just free time. Focus has been on board testing (and,
for me, talking to people *about* the board) so far, rather than
making a properly clean code base. As a few boards are starting to go
out, the priority of this is going up quickly.
With the new linux...@vger.kernel.org mailing list, do you know if
it is possible to get a digest subscription?
Khasim, will you post the Beagle patches here before sending them to
the linux-omap mailing list?
Syed Mohammed, Khasim
> What is the difference of the 2.6_kernel-beagle-rev2.tar.gz kernel to
> the kernel we had till yesterday in git and I did
>
> http://groups.google.com/group/beagleboard/browse_thread/thread/96a61c7294a6f920
>
> ?
The big differences I know about between the one that was in the (now
deleted) git and the tar that exists now is support for the rev2 board
with EHCI and MUSB.
>>
>
> Just to get a better understanding, what is the problem with directly
> creating a patch?
For me, it is just free time. Focus has been on board testing (and,
for me, talking to people *about* the board) so far, rather than
making a properly clean code base. As a few boards are starting to go
out, the priority of this is going up quickly.
With the new linux...@vger.kernel.org mailing list, do you know if
it is possible to get a digest subscription?
Khasim, will you post the Beagle patches here before sending them to
the linux-omap mailing list?
Dirk Behme
...
> > http://www.beagleboard.org/uploads/2.6_kernel-beagle-rev2.tar.gz
...
> Yes this is 2.6.22 kernel from kernel.org <http://kernel.org> + Tony's
> 2.6.22 OMAP patch from muru.com <http://muru.com>, then our changes for
>
> I still didnt get enough time to port beagle changes to latest kernel...
> will do this as sson as I can.
I really would help, but I had no luck doing a diff between a clean
2.6.22 + 2.6.22.1 + 2.6.22-omap1 against 2.6_kernel-beagle-rev2.tar.gz.
I stopped when the patch became > 4MB and > 100 changed files. E.g. I
got differences in arch/mips/*...
Anybody else seeing this as well? Or did I anything wrong?
Thanks
Dirk