Fix endianness #176
Fix endianness #176
Conversation
mateusz-holenko
force-pushed
the
fix_endianness
branch
from
fd1d5c6
to
0bbd67b
Compare
| @@ -31,7 +31,7 @@ def __init__(self, platform, *args, **kwargs): | |||
| platform.request("eth_clocks"), | |||
| platform.request("eth")) | |||
| self.submodules.ethmac = LiteEthMAC( | |||
There was a problem hiding this comment.
I don't quite understand why LiteEthMAC needs to understand the cpu endianness? However it looks like that is something from upstream, not something you invented?
There was a problem hiding this comment.
The MAC converts 32-bit writes/reads to/from 8-bit streams so needs to know the endiannness to know in which order reading/storing the streams.
There was a problem hiding this comment.
I have detected the problems when testing the firmware on HW. Without setting the proper endianess, data read from liteeth buffers had each 4-byte chunk reverted, causing the software to fail to detect the proper type of packet and drop it in a process.
After realising what was going on, I tested the pure LiteX platform and it worked fine. Diffing them pointed to the endianness property (not set in LiteX-BuildEnv).
mateusz-holenko
force-pushed
the
fix_endianness
branch
from
0bbd67b
to
2836f89
Compare
This PR fixes two problems with endianness for little endian CPUs (like VexRiscv):