On Mon, 11 Aug 2008 18:26:21 +0300
ext Tony Lindgren [EMAIL PROTECTED] wrote:
Hi all,
I've updated our git tree to v2.6.27-rc2, and looks like we still
have a bunch of issues to solve:
- Booting fails early on 3430sdp for some reason
- Alignment error on omap2/3. This seems to happen
* Jarkko Nikula [EMAIL PROTECTED] [080812 10:13]:
On Mon, 11 Aug 2008 18:26:21 +0300
ext Tony Lindgren [EMAIL PROTECTED] wrote:
Hi all,
I've updated our git tree to v2.6.27-rc2, and looks like we still
have a bunch of issues to solve:
- Booting fails early on 3430sdp for some
* Paul Walmsley [EMAIL PROTECTED] [080811 22:58]:
On Mon, 11 Aug 2008, Tony Lindgren wrote:
- Booting fails early on 3430sdp for some reason
This affects all ARMv7 and is due to a bug in the TLB clearing code; patch
coming shortly.
- Alignment error on omap2/3. This seems to happen
happens on 24xx, not on 34xx.
For me reverting 0e5194e1a84c219bebbb78f305b7a8eabc4a3656 fixes this.
Reverting 718fc6cd4db902aa2242a736cc3feb8744a4c71a like Felipe mentioned
does not help for me with gcc version 4.2.3 (Sourcery G++ Lite
2008q1-126).
Tony
5Kernel command line: root=1f03
The omap3_evm_defconfig needs to be updated.
Else, build fails with:
LD init/built-in.o
LD .tmp_vmlinux1
arm-none-linux-gnueabi-ld: no machine record defined
arm-none-linux-gnueabi-ld: no machine record defined
make: *** [.tmp_vmlinux1] Error 1
make oldconfig did not help either
On Tue, Aug 12, 2008 at 05:31:20PM +0300, Tony Lindgren wrote:
For me reverting 0e5194e1a84c219bebbb78f305b7a8eabc4a3656 fixes this.
Reverting 718fc6cd4db902aa2242a736cc3feb8744a4c71a like Felipe mentioned
does not help for me with gcc version 4.2.3 (Sourcery G++ Lite
2008q1-126).
But still
On Mon, 11 Aug 2008, Tony Lindgren wrote:
- Booting fails early on 3430sdp for some reason
This affects all ARMv7 and is due to a bug in the TLB clearing code; patch
coming shortly.
- Alignment error on omap2/3. This seems to happen also with
718fc6cd4db902aa2242a736cc3feb8744a4c71a
On Thu, Apr 10, 2008 at 07:24:50PM +0800, Bryan Wu wrote:
I think this kind of devices maybe should be added to the blacklist of
the musb otg driver.
Do you guys have some idea about that?
overcurrent protection is triggering fine, that's why you're getting
vbus_err. Blacklist shouldn't be
On Tue, Apr 8, 2008 at 3:06 PM, Bryan Wu [EMAIL PROTECTED] wrote:
On Tue, Apr 8, 2008 at 12:05 AM, David Brownell [EMAIL PROTECTED] wrote:
On Monday 07 April 2008, Felipe Balbi wrote:
I recall having some issues on 100mA devices. During enumeration some
current spikes a few mAs above
On Tue, Apr 8, 2008 at 12:05 AM, David Brownell [EMAIL PROTECTED] wrote:
On Monday 07 April 2008, Felipe Balbi wrote:
I recall having some issues on 100mA devices. During enumeration some
current spikes a few mAs above 100mA were occuring and we couldn't
enumerate the device due to
On Mon, 7 Apr 2008 03:44:12 -0700, Bryan Wu [EMAIL PROTECTED] wrote:
On Mon, Apr 7, 2008 at 3:21 AM, Felipe Balbi [EMAIL PROTECTED] wrote:
On Mon, 7 Apr 2008 03:16:31 -0700, Bryan Wu [EMAIL PROTECTED]
wrote:
Hi folks,
Here are our trackers, I think following bugs are the same
On Mon, 7 Apr 2008 03:44:12 -0700, Bryan Wu [EMAIL PROTECTED] wrote:
On Mon, Apr 7, 2008 at 3:21 AM, Felipe Balbi [EMAIL PROTECTED] wrote:
On Mon, 7 Apr 2008 03:16:31 -0700, Bryan Wu [EMAIL PROTECTED]
wrote:
Hi folks,
Here are our trackers, I think following bugs are the same
On Mon, 7 Apr 2008 03:16:31 -0700, Bryan Wu [EMAIL PROTECTED] wrote:
Hi folks,
Here are our trackers, I think following bugs are the same issue:
USB-IDE cable:
https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdittracker_id=141tracker_item_id=3789
MicroSD
My patch is simply skip to start 2cn CSW operation as below:
--
Index: drivers/usb/storage/transport.c
===
--- drivers/usb/storage/transport.c (revision 4075)
+++ drivers/usb/storage/transport.c (working copy)
On Mon, 7 Apr 2008 04:08:33 -0700, Bryan Wu [EMAIL PROTECTED] wrote:
On Mon, Apr 7, 2008 at 3:46 AM, Felipe Balbi [EMAIL PROTECTED] wrote:
On Mon, 7 Apr 2008 03:35:38 -0700, Bryan Wu [EMAIL PROTECTED]
wrote:
On Mon, Apr 7, 2008 at 3:19 AM, Felipe Balbi [EMAIL PROTECTED]
wrote:
On Mon, 7 Apr 2008 04:12:58 -0700, Bryan Wu [EMAIL PROTECTED] wrote:
My patch is simply skip to start 2cn CSW operation as below:
--
Index: drivers/usb/storage/transport.c
===
--- drivers/usb/storage/transport.c
On Monday 07 April 2008, Felipe Balbi wrote:
e) So I hacked the usb-storage driver code, the Linux host on Blackfin
will not wait for the 2nc CSW. Then this bug is gone.
This is just a workaround for that, it should not be the right way.
Does anyone here meet this issue before, on
not to use it the right way and just put the max
possible, e.g. 500mA
For this current source problem, I remember there are some external
VBUS charger IC can help the USB OTG to provide more than 100mA
current.
Do you have it in blackfin ?
--
Best Regards,
Felipe Balbi
[EMAIL PROTECTED]
http
On Tue, Apr 8, 2008 at 12:03 AM, David Brownell [EMAIL PROTECTED] wrote:
On Monday 07 April 2008, Felipe Balbi wrote:
e) So I hacked the usb-storage driver code, the Linux host on Blackfin
will not wait for the 2nc CSW. Then this bug is gone.
This is just a workaround for that, it
301 - 319 of 319 matches
Mail list logo