When building with GCC 11:
../libbase/crt0.o: in function `_start':
litex/soc/cores/cpu/microwatt/crt0.S:54:(.text+0x38): relocation truncated to fit: R_PPC64_GOT16_DS against symbol `_fdata' defined in .data section in bios.elf
litex/soc/cores/cpu/microwatt/crt0.S:55:(.text+0x3c): relocation truncated to fit: R_PPC64_GOT16_DS against symbol `_edata' defined in .data section in bios.elf
litex/soc/cores/cpu/microwatt/crt0.S:56:(.text+0x40): relocation truncated to fit: R_PPC64_GOT16_DS against symbol `_fdata_rom' defined in *ABS* section in bios.elf
litex/soc/cores/cpu/microwatt/crt0.S:68:(.text+0x68): relocation truncated to fit: R_PPC64_GOT16_DS against symbol `_fbss' defined in .bss section in bios.elf
litex/soc/cores/cpu/microwatt/crt0.S:69:(.text+0x6c): relocation truncated to fit: R_PPC64_GOT16_DS against symbol `_ebss' defined in .bss section in bios.elf
litex/soc/cores/cpu/microwatt/crt0.S:80:(.text+0x90): relocation truncated to fit: R_PPC64_GOT16_DS against symbol `_fstack' defined in .bss section in bios.elf
boot.o: in function `copy_file_from_sdcard_to_ram':
litex/soc/software/bios/boot.c:622:(.text+0x18): relocation truncated to fit: R_PPC64_TOC16_DS against `.toc'
litex/soc/software/bios/boot.c:627:(.text+0x5c): relocation truncated to fit: R_PPC64_TOC16_DS against `.toc'+8
litex/soc/software/bios/boot.c:633:(.text+0x8c): relocation truncated to fit: R_PPC64_TOC16_DS against `.toc'+10
litex/soc/software/bios/boot.c:639:(.text+0xdc): relocation truncated to fit: R_PPC64_TOC16_DS against `.toc'+18
litex/soc/software/bios/boot.c:650:(.text+0x128): additional relocation overflows omitted from the output
This is because we pass -mcmodel=small. As the PowerPC ELF ABI
describes, the small code model restricts the relocations to 16-bit
offsets[1]. If we omit the option we get the default, which is the
medium model allowing 32-bit offsets.
http://openpowerfoundation.org/wp-content/uploads/resources/leabi/content/dbdoclet.50655240_19143.html
Signed-off-by: Joel Stanley <joel@jms.id.au>
New version of binutils contain stricter checks for sections that are
not included in the linker script, resulting in this error:
ld: error: no memory region specified for loadable section `.note.gnu.build-id'
Disable this feature as there is no use for it on bare metal systems.
Signed-off-by: Joel Stanley <joel@jms.id.au>
binutils 2.34 contains stricter checks for sections that are not
included in the linker script, resulting in this error:
ld: bios.elf: error: PHDR segment not covered by LOAD segment
From the 2.34 NEWS:
The ld check for "PHDR segment not covered by LOAD segment" is more
effective, catching cases that were wrongly allowed by previous versions of
ld. If you see this error it is likely you are linking with a bad linker
script or the binary you are building is not intended to be loaded by a
dynamic loader. In the latter case --no-dynamic-linker is appropriate.
As the BIOS runs bare metal, we do not need to emit a PHDR segment.
Signed-off-by: Joel Stanley <joel@jms.id.au>
This patch adds the static files needed for the documentation to the
`package_data` field in `setup.py`.
I ran into failures when generating documentation after installing litex
using pipenv which didn't copy these files which in turn caused the
documentation generation to fail.
This change causes all files in the `static` subfolder of the
litex.soc.doc module to be installed as well.
READ_CHECK_TEST_PATTERN_MAX_ERRORS was being computed incorrectly
which could result in integer underflows when computing core via
(max_errors - errors). This could happen e.g. when using
DFIRateConverter, which modifies DFII_PIX_DATA_BYTES. Now we use
DFII_PIX_DATA_BYTES in the equation so this should not happen.
The Linux LiteETH driver parses registers by name. Provide the expected
names for each register: "mac", "mdio", and "buffer", respectively.
For setting up tx and rx slots, the Linux driver expects three pieces
of information: number of tx and rx slots, and slot size. Update
json2dts_linux to provide the appropriate names and values.
When playing with CPUs and variants, users previously had to do a rm -rf build to ensure
a proper software build. Various developers already lost time on it so it's important
to handle it directly in the Builder which is now the case.
-litex_json2dts_linux (previously litex_json2dts).
-litex_json2dts_zephyr (previously litex_zephyr_dts_generator).
-litex_json2renode (previously litex_renode_generator).
litex_json2dts_zephyr and litex_json2renode are now also directly exposed.
- Fix compilation in sdram.c.
- Fix warnings.
- Move Sequential/Random mode printf to memtest.
- Reduce SPI Flash test size (Testing full SPI Flash makes the boot too long, especially in random mode).
Without this change, when `.data` section size wasn't multiple
of word size, `data_loop` in crt0 was jumping over `_edata` and
continued looping. As it works on words and right now 64 bit CPUs
are biggest ones supported - alignment is now 8 bytes.
Also removed `- 4` from stack address, as it needs to be aligned
to 16 bytes on RISC-V.
The current code only works with a memory bus because otherwise
"generate_cluster_name" doesn't get called.
Cluster_name is only needed in the finalize phase.
Therefore, the name will now be generated just before its usage.
Verifiable with:
litex_sim --cpu-type vexriscv_smp (should be broken before this commit)
RISC-V requires stack to be aligned to 16 bytes.
1d5384e669/riscv-elf.md?plain=1#L183
Right now, in bios/linker.ld, `_fstack` is being set to 8 bytes
before the end of sram region.
```
PROVIDE(_fstack = ORIGIN(sram) + LENGTH(sram) - 8);
```
Removing ` - 8` makes it aligned to 16.
Also there are changes in crt0.S for vexriscv,
vexriscv_smp and cv32e40p.
Code that was setting up stack, was adding 4 to its address
for some reason.
Removing it makes it aligned to 8 bytes, and with change in
bios/linker.ld to 16 bytes.
It also fixes `printf` with long long integers on 32bit
CPUs ([relevant issue](https://github.com/riscv/riscv-gcc/issues/63)).
A regular CPU can provides specific mapping constraints and we are overriding provided mapping
with these constraints.
The case of CPUNone is different and we can do the opposite: Give priority to User's mapping.
For the regular CPU case, the override was done silently, it is now logged during the build.
enjoy-digital
Joel Stanley
Pawel Sagan
Andreas Galauner
asadaleem-rs
Jędrzej Boczar
Piotr Binkowski
Michal Sieron
Tim Ansell
Gabriel Somlo
Filip Kokosinski
David Sawatzke
Christian Klarhorst
Mateusz Holenko
Dan Callaghan