From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz8Wo-0004FA-Gf for qemu-devel@nongnu.org; Tue, 16 Jul 2013 12:55:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uz8Wn-0004b7-NT for qemu-devel@nongnu.org; Tue, 16 Jul 2013 12:55:06 -0400 Date: Tue, 16 Jul 2013 11:54:48 -0500 From: Scott Wood References: <1373476202-11277-1-git-send-email-chouteau@adacore.com> <1373476202-11277-3-git-send-email-chouteau@adacore.com> <20130716020617.GA22542@home.buserror.net> <51E5669C.2080602@adacore.com> <51E568A3.4090503@suse.de> <51E571B7.2060308@adacore.com> In-Reply-To: <51E571B7.2060308@adacore.com> (from chouteau@adacore.com on Tue Jul 16 11:15:51 2013) Message-ID: <1373993688.8183.328@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] Add Enhanced Three-Speed Ethernet Controller (eTSEC) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fabien Chouteau Cc: qemu-ppc@nongnu.org, Alexander Graf , qemu-devel@nongnu.org On 07/16/2013 11:15:51 AM, Fabien Chouteau wrote: > On 07/16/2013 05:37 PM, Alexander Graf wrote: > > On 07/16/2013 05:28 PM, Fabien Chouteau wrote: > >> On 07/16/2013 04:06 AM, Scott Wood wrote: > >>> On 07/10/2013 12:10:02 PM, Fabien Chouteau wrote: > >>>> This implementation doesn't include ring priority, TCP/IP =20 > Off-Load, QoS. > >>>> > >>>> Signed-off-by: Fabien Chouteau > >>> From the code comments I gather this has been tested on =20 > VxWorks. Has it > >>> been tested on Linux, or anywhere else? > >>> > >> You're right, as I said in the cover letter, this has only been =20 > tested on vxWorks. > > > > Could you please give it a try? IIRC eTSEC support should be in =20 > upstream Linux. > > >=20 > I don't have time for that. As I said in the cover letter, I submit =20 > this > patch for those interested in eTSEC, but I won't be able to test/fix =20 > it > for Linux. Could you please at least document more fully the known limitations, =20 such as "I'm only interested in 32bits address spaces"? > >>>> + /* ring_base =3D (etsec->regs[RBASEH].value& 0xF)<< 32; */ > >>>> + ring_base +=3D etsec->regs[RBASE0 + ring_nbr].value& =20 > ~0x7; > >>>> + start_bd_addr =3D bd_addr =3D etsec->regs[RBPTR0 + =20 > ring_nbr].value& ~0x7; > >>> What about RBDBPH (upper bits of physical address)? Likewise for =20 > TX. > >>> > >> I'm only interested in 32bits address spaces, so RBASEH, TBASEH, =20 > RBDBPH or TBDBPH. > > > > Why? I thought e500mc and above can access more than 32bits of =20 > physical address space? >=20 > Yes but this is not emulated by QEMU, right? sizeof (hwaddr) for > qemu-system-ppc is 8... 36bit physical is emulated by QEMU. Currently we put CCSR in a place =20 that would make it difficult to use memory above 4G, but that should =20 change at some point. > > Oh, but they're always DPAA? > > >=20 > I don't understand... It doesn't matter, because it's not true. We do support 36-bit address =20 layouts on mpc85xx and mpc86xx, though we don't make it the only =20 supported config in U-Boot as we do on e500mc+. -Scott=