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
omap3_beagleboard_patch.txt (27.7 KB)
I just took
http://www.beagleboard.org/gitweb/?p=linux.git;a=commit;h=7dc52e0ee40…
and updated it against recent OMAP git tree plus some minor cleanup.
Great!
Compile tested only result in attachment.
+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?
regards,
Koen
koen wrote:
I just took
http://www.beagleboard.org/gitweb/?p=linux.git;a=commit;h=7dc52e0ee40…
and updated it against recent OMAP git tree plus some minor cleanup.
Great!
Compile tested only result in attachment.
+CONFIG_TWL4030_CORE=y
+CONFIG_TWL4030_GPIO=y
+# CONFIG_TWL4030_USB is not setDoesn'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=yor 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?
Thanks
Dirk
Hi Dirk / Koen,
koen wrote:
>
>
>
>>I just took
>>
>>http://www.beagleboard.org/gitweb/?p=linux.git;a=commit;h=7dc52e0ee40…
>>
>>and updated it against recent OMAP git tree plus some minor cleanup.
>
>
> Great!
>
>
>>Compile tested only result in attachment.
>
>
>>+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?
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
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.
Syed Mohammed, Khasim wrote:
Hi Dirk / Koen,
koen wrote:
I just took
http://www.beagleboard.org/gitweb/?p=linux.git;a=commit;h=7dc52e0ee40…
and updated it against recent OMAP git tree plus some minor cleanup.
Great!
Compile tested only result in attachment.
+CONFIG_TWL4030_CORE=y
+CONFIG_TWL4030_GPIO=y
+# CONFIG_TWL4030_USB is not setDoesn'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=yor 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?
Many thanks for your effort.
Hi all,
I wanted to put a GIT patch out this weekend but got pulled into some
other personal stuffBy 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?
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?
Jason Kridner wrote:
koen wrote:
+CONFIG_TWL4030_CORE=y
+CONFIG_TWL4030_GPIO=y
+# CONFIG_TWL4030_USB is not setDoesn'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=yor 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
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 stuffBy 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 fromhttp://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!
Jason Kridner 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 stuffBy 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 fromhttp://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
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.
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
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
Patches still need to be created against the public tree. I haven't
seen anyone else post those here or to linux-omap@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://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?templateI…
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.
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
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
I still need to read this and learn how your are doing this link-
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.
I'll remove them later today, even though we still don't have patches
quite yet.
>>Regarding X-loader: Maybe a git repository for this at
>>http://www.beagleboard.org/gitweb/
>>makes sense?
> Yes, it makes sense.
Will add that when I delete the others.
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?
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
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-omap@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
?
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?templateI…
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.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.
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.
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
I still need to read this and learn how your are doing this link-
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 fromthen?
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.I'll remove them later today, even though we still don't have patches
quite yet.Regarding X-loader: Maybe a git repository for this at
makes sense?
Yes, it makes sense.
Will add that when I delete the others.
Seems this is done 
Many thanks
Dirk
Dirk Behme wrote:
Jadon wrote:
...
Patches still need to be created against the public tree. I haven't
seen anyone else post those here or to linux-omap@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
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 onhttp://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-omap@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 didhttp://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-omap@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?
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 onhttp://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-omap@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!
Yes this is 2.6.22 kernel from kernel.org + Tony’s 2.6.22 OMAP patch from muru.com, then our changes for Beagle and 3430SDP.
I still didnt get enough time to port beagle changes to latest kernel… will do this as sson as I can.
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 didhttp://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-omap@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?
I think we can directly post kernel patches to OMAP vger list, it gives more audience for review instead of blocking here. May be we can discuss design and other issues here.
I will keep this list in CC though.
Syed Mohammed, Khasim wrote:
...
> 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 Beagle and 3430SDP.
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
