On 07/16/2013 03:06 AM, Peter Crosthwaite wrote:
>>>> +>>>> + memory_region_init_io(&etsec->io_area, OBJECT(etsec), &etsec_ops, etsec,>>>> + "eTSEC", 0x1000);>>>>>> Constant size memory_region_init_io should be migrated to the Object::Init fm.>>>>>>> What is Object::Init()? Do you have an example?>>> > hw/dma/xilinx_axidma.c - xilinx_axidma_init() and> xilinx_axidma_realize() has an example of splitting init task between> early and late. Note the memory_region_init_io is in the _init.>
OK thanks,

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<chouteau@adacore.com>>>> 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.
>>>>> + /* 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...
> Oh, but they're always DPAA?>
I don't understand...
Regards,

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<chouteau@adacore.com>> >>> 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"?
> >>>> + /* 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.
> > Oh, but they're always DPAA?> >> > I don't understand...
It doesn't matter, because it's not true. We do support 36-bit address
layouts on mpc85xx and mpc86xx, though we don't make it the only
supported config in U-Boot as we do on e500mc+.
-Scott

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<chouteau@adacore.com>>> >>> 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,

Am 17.07.2013 um 10:24 schrieb Fabien Chouteau <chouteau@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:>>>>>>> This implementation doesn't include ring priority, TCP/IP Off-Load, QoS.>>>>>>> >>>>>>> Signed-off-by: Fabien Chouteau<chouteau@adacore.com>>>>>>> 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?
8 x 8 = 64, no? :)
Alex
> > Regards,> > -- > Fabien Chouteau