06-21-2019 07:08 AM
In IP integrator a 10G ETH Base-R IP has been customized to 2 cores.
The address editor shows two offset addresses: 0x00_A000_0000 and 0x00_A000_1000.
The file system.hdf includes correctly the two address s_axi_0 and s_axi_1
In the SDK-BSP project, the file xparameters.h shows only: XPAR_XXV_ETHERNET_0_BASEADDR 0xA0001000 but not the base address for 0xA0000000.
Worst, XXxvEthernet_ReadReg(0xA0000000, i) ; reads always zero
while XXxvEthernet_ReadReg(0xA0001000, i) ; reads ok
Please, could someone explain how to write/read the two Ethernet cores?
I'm using Vivado 2019.1 and ZCU102
06-24-2019 08:09 AM
I've mistaken two lines, I re-write:
XXxvEthernet_ReadReg(0xA0000000, i) ; reads ok
while XXxvEthernet_ReadReg(0xA0001000, i) ; reads always zero
07-04-2019 02:23 AM
Yes! I just found the same. Using Vivado 2019.1.
The core uses the lower 16 bit of the address.
INFO: [Synth 8-6157] synthesizing module 'Base_Zynq_MPSoC_xxv_ethernet_0_0_mac_ll_axis_pif_registers' [sources_1/bd/Base_Zynq_MPSoC/ip/Base_Zynq_MPSoC_xxv_ethernet_0_0/xxv_ethernet_v3_0_0/Base_Zynq_MPSoC_xxv_ethernet_0_0_axi4_lite_if_wrapper.v:450] Parameter ADDR_WIDTH bound to: 16 - type: integer
For some reason the automatic address mapper only assigns 4K for it. This seems like a bug and it took me a while to notice that the core did in fact lock to my ethernet signal, and it was the Linux driver which couldn't read that correctly.
As it only read zeroes, the driver reported
XXV MAC block lock not complete! Cross-check the MAC ref clock configuration
Manually assigning a range of 64K fixes the problem!
If you are lucky and the mapper maps the core to a 64K boundary it should work as well, as all the currently implemented registers would fit in 4K. I guess this is why it wasn't spotted sooner.
07-08-2019 03:45 AM
For 10G/25G Ethernet Subsystem IP the accesses to memory map work fine till the address 0x090 that is for all TX_flow_control,
while starting from the address of 0x94 (start: RX_flow_control) read always 0x00000000.
Could you please explain the reason.
07-09-2019 01:50 AM
I have tried writing all RW registers from address 0x0094 to 0x00c4 but I read back always 0x00000000. All these registers belong to RX Configuration.
Regarding TX Configuration, from address 0x0000 to 0x00090 the write&read works fine.
I de-asserted the resets with a VIO in order to try a different sequence but with negative results.
07-12-2019 12:21 PM
This has been a problem since at least 2018.3. I found that the ethernet register space must be on an 0x1_0000 boundary in order for the core to work. If the core is on the default 0x0_1000 boundary, it will not work. The worse problem is that the core completes the transaction, but always responds with zeros to any read. This makes it look like everything's working, but clearly not. Debug was hell. I've confirmed this in chipscope using peek/poke to the assigned address space.
My solution has been to put the cores all on 0x1_0000 boundaries. That has worked. I have not tried expanding the range to 64k, though I expect that results in the same thing.
01-30-2020 06:26 AM - edited 01-30-2020 06:55 AM
I'm working with the 10G/25G ethernet subsystem and I get the same problem, so I changed the offset address, from the auto assigned (0x00A0001000) to 0x00A0090000 and increased the address range from 4KB to 64KB. When I try to read the register at 0x00A0001024 (version register) I get a kernel panic error and also the xilinx driver rise a kernel panic. I tried different addresses, but I get always the same result, petalinux cannot read the registers.
08-03-2020 10:32 AM
Can you send to me your vivado project. I running into this problem, even when i set address boundaries with 0x1_0000.
08-04-2020 08:06 AM
Unfortunately, that design is long gone. It was just the 10/25G ethernet example with an additional core and the modified addresses.