Uboot DDR4 mapping Maaxboard 2gb #1
Comments
paul-embest
pushed a commit
that referenced
this issue
Oct 25, 2022
Add support for the SERDES #1 protocol 13 which enables 2 100G MACs (dpmac.1 and dpmac.2). For this to work, a new DTS file which describes how 2 mezzanine M8 cards can be connected on the LX2160AQDS board. Signed-off-by: Ioana Ciornei <[email protected]>
paul-embest
pushed a commit
that referenced
this issue
Oct 25, 2022
Add support for the SERDES #1 protocol 14 which enables a 100G MAC (dpmac.1). For this to work, a new DTS file which describes how the M8 mezzanine card is connected on the LX2160AQDS board. Signed-off-by: Ioana Ciornei <[email protected]>
paul-embest
pushed a commit
that referenced
this issue
Oct 25, 2022
* origin/ls_v2021.04: (6 commits) net: phy: inphi: change dev_err to pr_err board: freescale: lx2160aqds: include the lx2160a.h header board: lx2160aqds: add support for SERDES #1 protocol 14 board: lx2160aqds: add support for SERDES #1 protocol 13 net: ldpaa_eth: connect to multiple PHYs/retimers ...
david-fuu
pushed a commit
that referenced
this issue
Jun 28, 2024
The driver exists two issues: 1. For RX buffer, current driver release the buffer too early, should wait until free_pkt callback is called. Otherwise, the released buffer will put into rx bd ring again and may be used by enetc when uboot is processing the packet. 2. The RX BD size is only 16 bytes, but cache line is 64 bytes on iMX95, so when flush a free RX BD to submit it ring, the flush may write adjacent BDs which locate in same cache line into memory. It has the possibility that netc has used (filled) this adjacent BD before uboot processes it. So the BD content is overwritten. It will cause polling Ready bit of this BD always failed. We already observed such issue in 1000Mbps network. The patch added the free_pkt call back implementation for issue #1. And for issue #2, it adjusts to submit BDs in cache line size to ring. For example, on iMX95, we submit 4 RX BDs which are in one cache line. The cache operations are also re-fined in the patch with clean codes. Signed-off-by: Ye Li <[email protected]> Reviewed-by: Peng Fan <[email protected]> Acked-by: Wei Fang <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I recently bought the Maaxboard and I noticed the below lines in maxxboard.dts
memory@40000000 {
device_type = "memory";
reg = <0x00000000 0x40000000 0 0xc0000000>;
};
Which i feel the 0xc0000000 is wrong for Maaxboard , this could be 0x80000000 address becuase of 2gb mapping.
Please correct me if i am wrong on this
Best Regards
Prakash
The text was updated successfully, but these errors were encountered: