On 07/17/2013 10:29 AM, Alexander Graf wrote: > > > Am 17.07.2013 um 10:24 schrieb Fabien Chouteau <chout...@adacore.com>: > >> 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: >>>>>>>> + /* 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? > > 8 x 8 = 64, no? :) >
Oups, I was so sure of myself :) -- Fabien Chouteau
