64-bit support was added for 64-bit CPU because of limitation of the hardware
on CSR accesses. Now that the Wihhbone2CSR bus handles wishbone.sel, this is no
longer required.
The additional (17th) byte returned via the response register was
ignored by software (bios and kernel), so LiteSDCard was updated
to only return the (original, useful) 128 bits.
This patch updates the LiteSDCard code in the LiteX bios to only
expect those 128 bits, and to do so in a manner that's portable
across CSR data widths and alignments.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
CSR write is only done if wishbone.sel != 0. This should avoid the need for 64-bit
CSR alignment on 64-bit CPUs since a 64-bit Wishbone write access targeting only the
32-bit LSB or MSB will be splitted in 2x32-bit accesses: one with sel=0xf, one with sel=0.
MMPTR should always follow CSR alignment, NOT CSR data width.
(the latter merely indicates how many bits within a MMPTR are
actually populated).
Fixup for commit #4a5072a.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
CSR_BASE is currently defined twice. Once in mem.h as the base
of the CSR region in the SoC address space, and once in csr.h
as the base address for all CSRs.
This fixes two issues with those definitions:
- The mem.h one is unconditional which prevents an external
redefinition (which is useful under some circumstances such as
when using an address decoder outside of LiteX with a standalone
core).
- The csr.h one is actually the origin of the first CSR region
rather than the origin of the CSR region in the SoC space. They
are usually the same ... unless you don't have CSR bank 0 in
which case the csr.h one becomes different. This causes conflicts
with the mem.h definition and breaks projects using a standalone
cores.
The first one is fixed by adding the #ifndef/#endif around the
definition of the memory regions, the second one by passing the
csr_base to use to get_csr_header()
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
When running in sim, those delays can take a *long* time, which
isn't always necessary with the simulated litedram PHY.
This allows system.h to optionally set CONFIG_SIM_DISABLE_DELAYS
which causes cdelay to do nothing.
This is especially useful when using a verilated litedram inside
a bigger/slower simulated design as to not spend a huge amount
of time going through the initializations.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Having common cpu variants/extensions has no real additional value since we are supporting
very various CPUs where minimal/standard/full have different meanings. Checking against
common variants/extensions has also cause more issues recently when adding new CPUs than
the additional value it was supported to provide.
So let's just simplify things: a CPU provide the supported variants and we just check
against that.
Florent Kermarrec
Gabriel Somlo
Jędrzej Boczar
Benjamin Herrenschmidt