From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzN4C-0001Jm-Na for qemu-devel@nongnu.org; Wed, 17 Jul 2013 04:26:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzN48-0006VU-0S for qemu-devel@nongnu.org; Wed, 17 Jul 2013 04:26:32 -0400 Message-ID: <51E654B0.2060400@adacore.com> Date: Wed, 17 Jul 2013 10:24:16 +0200 From: Fabien Chouteau MIME-Version: 1.0 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> <1373993688.8183.328@snotra> In-Reply-To: <1373993688.8183.328@snotra> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Scott Wood Cc: qemu-ppc@nongnu.org, Alexander Graf , qemu-devel@nongnu.org On 07/16/2013 06:54 PM, Scott Wood wrote: > 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 Off-Load, QoS. >> >>>> >> >>>> Signed-off-by: Fabien Chouteau >> >>> From the code comments I gather this has been tested on VxWorks. Has it >> >>> been tested on Linux, or anywhere else? >> >>> >> >> You're right, as I said in the cover letter, this has only been tested on vxWorks. >> > >> > Could you please give it a try? IIRC eTSEC support should be in upstream Linux. >> > >> >> I don't have time for that. As I said in the cover letter, I submit this >> patch for those interested in eTSEC, but I won't be able to test/fix it >> for Linux. > > Could you please at least document more fully the known limitations, such as "I'm only interested in 32bits address spaces"? > I will, but this device is very complex and I don't even know all the limitation of my implementation ;) >> >>>> + /* ring_base = (etsec->regs[RBASEH].value& 0xF)<< 32; */ >> >>>> + ring_base += etsec->regs[RBASE0 + ring_nbr].value& ~0x7; >> >>>> + start_bd_addr = bd_addr = etsec->regs[RBPTR0 + ring_nbr].value& ~0x7; >> >>> What about RBDBPH (upper bits of physical address)? Likewise for TX. >> >>> >> >> I'm only interested in 32bits address spaces, so RBASEH, TBASEH, RBDBPH or TBDBPH. >> > >> > Why? I thought e500mc and above can access more than 32bits of physical address space? >> >> 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 that would make it difficult to use memory above 4G, but that should change at some point. But hwaddr is 32 bits, how could you call cpu_physical_memory_read()? to a 36bits address? Regards, -- Fabien Chouteau