From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Sun, 15 Mar 2015 19:20:32 +0100
Subject: [U-Boot] [RFC PATCH] usb: dwc2: handle bcm2835 phys->virt
	address translations
In-Reply-To: <5505B88E.4070301@wwwdotorg.org>
References: <1426227189-30488-1-git-send-email-swarren@wwwdotorg.org>
 <5505B88E.4070301@wwwdotorg.org>
Message-ID: <201503151920.33069.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Sunday, March 15, 2015 at 05:51:26 PM, Stephen Warren wrote:
> On 03/13/2015 12:13 AM, Stephen Warren wrote:
> > BCM2835 bus addresses use the top 2 bits to determine whether peripherals
> > use or bypass the GPU L1 and L2 cache. BCM2835-ARM-Peripherals.pdf states
> > that:
> > 
> > 0: L1 & L2 cached
> > 4: L2 cache coherent (non allocaing)
> > 8: L2 cached only
> > c: Direct uncached.
> > 
> > That document also states that "Software accessing RAM using the DMA
> > engines must use bus addresses (base at 0xc0000000). However, this
> > appears to be incorrect since it does not work in practice on the
> > bcm2835 (although it does on bcm2836). "usb start" causes some EABI
> > function to call raise(8), presumably due to corrupted USB IN data (the
> > converse is true on bcm2836; a value of 4 causes signals). However, I
> > haven't investigated the cause.
> 
> I've confirmed that the raise(8) calls are due to corrupted USB IN data;
> the maxpacketsize field in the device descriptor is getting corrupted to
> 0, which in turn surely causes division by zero when calculating the
> number of packets in a transfer, for example.

Nice progress :)

Best regards,
Marek Vasut