search

enjoy-digital / litex

Build your hardware, easily!
Other
2.97k stars 565 forks source link

issues with the picolibc switch?: Use this issue to share issues/get information/help #1045

Closed bunnie closed 2 years ago

bunnie commented 3 years ago

My CI just broke on the latest litex, and there's a new note that this library seems to be required:

Traceback (most recent call last):
  File "/home/bunnie/code/betrusted-soc/betrusted_soc.py", line 1974, in <module>
    ret = main()
  File "/home/bunnie/code/betrusted-soc/betrusted_soc.py", line 1901, in main
    vns = builder.build(run=False)
  File "/home/bunnie/code/betrusted-soc/deps/litex/litex/soc/integration/builder.py", line 276, in build
    new_variables_contents = self._get_variables_contents()
  File "/home/bunnie/code/betrusted-soc/deps/litex/litex/soc/integration/builder.py", line 143, in _get_variables_contents
    picolibc_directory = get_data_mod("software", "picolibc").data_location
  File "/home/bunnie/code/betrusted-soc/deps/litex/litex/__init__.py", line 14, in get_data_mod
    raise ImportError("""\
ImportError: pythondata-software-picolibc module not installed! Unable to use picolibc software.
No module named 'pythondata_software_picolibc'

You can install this by running;
 pip install git+https://github.com/litex-hub/pythondata-software-picolibc.git

However, at least in my view of litex-hub, I don't see a pythondata-software-picolibc:

image

(In the image above, I'm only finding software-compiler-rt in litex-hub, and that is the only search result)

I have a feeling I'm missing something really obvious -- could someone please give me a clue on where to find this new dependency?

david-sawatzke commented 3 years ago

FYI: picolibc was introduced with #976, maybe there's some helpful information there

bunnie commented 3 years ago

Ok reading the issue, and then looking in the litex_setup.py, it looks like the real location is at

https://github.com/antmicro/pythondata-software-picolibc

I've changed the issue title to reflect the problem, which is that the help message put out by the build system is incorrect. It indicates that I should find the library in litex-hub, but in fact, it is on antmicro.

enjoy-digital commented 3 years ago

Thanks @bunnie, @david-sawatzke for the feedback, the repo is still here: https://github.com/enjoy-digital/litex/blob/master/litex_setup.py#L26 and will work with the litex_setup.py but I'm going to push it to litex-hub.

enjoy-digital commented 3 years ago

@bunnie: This should be good now:

enjoy-digital commented 3 years ago

@bunnie: I just pinned the issue since you'll probably won't be the only one to have troubles with this change.

To get this new dependency, users usinglitex_setup.py can do a ./litex_setup.py init update install.

It's also possible to install it with pip3 install git+https://github.com/litex-hub/pythondata-software-picolibc.git

Since picolibc use Meson for the build, you also have to install meson: pip3 install meson (picolibc requires a recent meson package, so prefer the pip3 install vs the apt install).

mithro commented 3 years ago

I'll work on getting pythondata-software-picolibc onto PyPi too.

bunnie commented 3 years ago

thanks, adding that to our build fixes the problem in CI now. Issue is resolved for me, but I don't know if closing it causes trouble for the pin, so I'll leave it open. Feel free to close it anytime that's convenient for you.

tcal-x commented 3 years ago

There's a related issue -- pythondata-software-picolibc has a main branch, not a master, so updating will give an error, unless I'm doing something wrong:

$ ./litex_setup.py update 
[checking litex_setup.py]...
https://github.com/m-labs/
[updating migen]...
Already on 'master'
Your branch is up to date with 'origin/master'.
Already up to date.
https://github.com/nmigen/
[updating nmigen]...
Already on 'master'
Your branch is up to date with 'origin/master'.
Already up to date.
https://github.com/antmicro/
[updating pythondata-software-picolibc]...
error: pathspec 'master' did not match any file(s) known to git
Traceback (most recent call last):
  File "./litex_setup.py", line 150, in <module>
    subprocess.check_call("git checkout master", shell=True)
  File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'git checkout master' returned non-zero exit status 1.
enjoy-digital commented 3 years ago

@bunnie: Thanks, we can keep it open to discuss/track other eventual issues. If I remember correctly you are not compiling the BIOS and just using the Rust generated headers, can you tell me at which point of your CI the regression happened? It should be possible to avoid the dependency for your project.

@tcal-x: Thanks, I'll look at this tomorrow.

bunnie commented 3 years ago

You're correct, we don't use the C bios at all. This is the transcript of the run as I have it in my logs:

22:13:08 script=./dut.py --lx-ignore-git -c
22:13:08 args=./deps/gateware/sim/trng_managed ./deps/gateware/sim/spififo ./deps/gateware/sim/wdt ./deps/gateware/sim/keyrom ./deps/gateware/sim/memlcd ./deps/gateware/sim/i2s ./deps/gateware/sim/sram32 ./deps/gateware/sim/aes ./deps/gateware/sim/kbd ./deps/gateware/sim/sram32_cached ./deps/gateware/sim/rom_block ./deps/gateware/sim/curve_engine ./deps/gateware/sim/template ./deps/gateware/sim/spi_dopi ./deps/gateware/sim/sha512 ./deps/gateware/sim/spi_basic ./deps/gateware/sim/sha2
22:13:08 
22:13:08 -- testing directory ./deps/gateware/sim/trng_managed ---
22:13:09 INFO:SoC:        __   _ __      _  __  
22:13:09 INFO:SoC:       / /  (_) /____ | |/_/  
22:13:09 INFO:SoC:      / /__/ / __/ -_)>  <    
22:13:09 INFO:SoC:     /____/_/\__/\__/_/|_|  
22:13:09 INFO:SoC:  Build your hardware, easily!
22:13:09 INFO:SoC:--------------------------------------------------------------------------------
22:13:09 INFO:SoC:Creating SoC... (2021-09-27 22:13:09)
22:13:09 INFO:SoC:--------------------------------------------------------------------------------
22:13:09 INFO:SoC:FPGA device : xc7s50-csga324-1il.
22:13:09 INFO:SoC:System clock: 100.00MHz.
22:13:09 INFO:SoCBusHandler:Creating Bus Handler...
22:13:09 INFO:SoCBusHandler:32-bit wishbone Bus, 4.0GiB Address Space.
22:13:09 INFO:SoCBusHandler:Adding reserved Bus Regions...
22:13:09 INFO:SoCBusHandler:Bus Handler created.
22:13:09 INFO:SoCCSRHandler:Creating CSR Handler...
22:13:09 INFO:SoCCSRHandler:32-bit CSR Bus, 32-bit Aligned, 64.0KiB Address Space, 4096B Paging, big Ordering (Up to 64 Locations).
22:13:09 INFO:SoCCSRHandler:Adding reserved CSRs...
22:13:09 INFO:SoCCSRHandler:CSR Handler created.
22:13:09 INFO:SoCIRQHandler:Creating IRQ Handler...
22:13:09 INFO:SoCIRQHandler:IRQ Handler (up to 32 Locations).
22:13:09 INFO:SoCIRQHandler:Adding reserved IRQs...
22:13:09 INFO:SoCIRQHandler:IRQ Handler created.
22:13:09 INFO:SoC:--------------------------------------------------------------------------------
22:13:09 INFO:SoC:Initial SoC:
22:13:09 INFO:SoC:--------------------------------------------------------------------------------
22:13:09 INFO:SoC:32-bit wishbone Bus, 4.0GiB Address Space.
22:13:09 INFO:SoC:32-bit CSR Bus, 32-bit Aligned, 64.0KiB Address Space, 4096B Paging, big Ordering (Up to 64 Locations).
22:13:09 INFO:SoC:IRQ Handler (up to 32 Locations).
22:13:09 INFO:SoC:--------------------------------------------------------------------------------
22:13:09 INFO:SoCBusHandler:io0 Region added at Origin: 0x80000000, Size: 0x80000000, Mode: RW, Cached: False Linker: False.
22:13:09 INFO:SoC:CPU overriding rom mapping from 0x0 to 0x0.
22:13:09 INFO:SoC:CPU overriding sram mapping from 0x1000000 to 0x10000000.
22:13:09 INFO:SoC:CPU overriding csr mapping from 0xf0000000 to 0xf0000000.
22:13:09 INFO:SoC:CPU overriding vexriscv_debug mapping from 0xefff0000 to 0xf00f0000.
22:13:09 INFO:SoCBusHandler:cpu_bus0 added as Bus Master.
22:13:09 INFO:SoCBusHandler:cpu_bus1 added as Bus Master.
22:13:09 INFO:SoCBusHandler:rom Region added at Origin: 0x00000000, Size: 0x00008000, Mode: R, Cached: True Linker: False.
22:13:09 INFO:SoCBusHandler:rom added as Bus Slave.
22:13:09 INFO:SoC:RAM rom added Origin: 0x00000000, Size: 0x00008000, Mode: R, Cached: True Linker: False.
22:13:09 INFO:SoCBusHandler:sram Region added at Origin: 0x10000000, Size: 0x00020000, Mode: RW, Cached: True Linker: False.
22:13:09 INFO:SoCBusHandler:sram added as Bus Slave.
22:13:09 INFO:SoC:RAM sram added Origin: 0x10000000, Size: 0x00020000, Mode: RW, Cached: True Linker: False.
22:13:09 INFO:SoCIRQHandler:uart IRQ allocated at Location 0.
22:13:09 INFO:SoCIRQHandler:timer0 IRQ allocated at Location 1.
22:13:09 INFO:SoCBusHandler:sram2 Region added at Origin: 0x01000000, Size: 0x00020000, Mode: RW, Cached: True Linker: False.
22:13:09 INFO:SoCBusHandler:sram2 added as Bus Slave.
22:13:09 INFO:SoC:RAM sram2 added Origin: 0x01000000, Size: 0x00020000, Mode: RW, Cached: True Linker: False.
22:13:09 INFO:S7MMCM:Creating S7MMCM, speedgrade -1.
22:13:09 INFO:S7MMCM:Registering Single Ended ClkIn of 12.00MHz.
22:13:09 INFO:S7MMCM:Creating ClkOut0 sys of 100.00MHz (+-0.00ppm).
22:13:09 INFO:S7MMCM:Creating ClkOut1 clk50 of 50.00MHz (+-10000.00ppm).
22:13:09 INFO:SoCCSRHandler:simstatus CSR allocated at Location 0.
22:13:09 INFO:SoCCSRHandler:trng_kernel CSR allocated at Location 1.
22:13:09 INFO:SoCIRQHandler:trng_kernel IRQ allocated at Location 2.
22:13:09 INFO:SoCCSRHandler:trng_server CSR allocated at Location 2.
22:13:09 INFO:SoCIRQHandler:trng_server IRQ allocated at Location 3.
22:13:09 INFO:SoCCSRHandler:trng CSR allocated at Location 3.
22:13:09 Traceback (most recent call last):
22:13:09   File "/var/lib/jenkins/workspace/soc-agnostic/deps/litex/litex/__init__.py", line 10, in get_data_mod
22:13:09     exec(imp, {}, l)
22:13:09   File "<string>", line 1, in <module>
22:13:09 ModuleNotFoundError: No module named 'pythondata_software_picolibc'
22:13:09 
22:13:09 During handling of the above exception, another exception occurred:
22:13:09 
22:13:09 Traceback (most recent call last):
22:13:09   File "./dut.py", line 229, in <module>
22:13:09     main()
22:13:09   File "./dut.py", line 207, in main
22:13:09     generate_top()
22:13:09   File "./dut.py", line 170, in generate_top
22:13:09     vns = builder.build(run=False)
22:13:09   File "/var/lib/jenkins/workspace/soc-agnostic/deps/litex/litex/soc/integration/builder.py", line 276, in build
22:13:09     new_variables_contents = self._get_variables_contents()
22:13:09   File "/var/lib/jenkins/workspace/soc-agnostic/deps/litex/litex/soc/integration/builder.py", line 143, in _get_variables_contents
22:13:09     picolibc_directory = get_data_mod("software", "picolibc").data_location
22:13:09   File "/var/lib/jenkins/workspace/soc-agnostic/deps/litex/litex/__init__.py", line 20, in get_data_mod
22:13:09     """.format(dt=data_type, dn=data_name, e=e))
22:13:09 ImportError: pythondata-software-picolibc module not installed! Unable to use picolibc software.
22:13:09 No module named 'pythondata_software_picolibc'
22:13:09 
22:13:09 You can install this by running;
22:13:09  pip install git+https://github.com/litex-hub/pythondata-software-picolibc.git
22:13:09 
22:13:09 lxbuildenv: v2020.2.18.1 (run ./dut.py --lx-help for help)
22:13:09 lxbuildenv: Skipping git configuration because "--lx-ignore-git" Was specified
22:13:09 FAIL SCRIPT 1
22:13:09 -- EXIT 1 --

The failure was picked up by our "bleeding edge" CI where we run all our gateware modules against the latest Litex, so our top-level script is named dut.py.

gsomlo commented 3 years ago

The picolibc migration broke Rocket

After some debugging (using the simulator), I can confirm that keyboard input triggers a UART interrupt which makes it all the way here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/isr.c#L54 with the correct PLIC claim number (corresponding to UART_INTERRUPT).

No idea currently why further calling uart_isr() does not result in a character being read and echoed back on the console...

enjoy-digital commented 3 years ago

@tcal-x: The default branch has been renamed so your issue should be fixed, for now for we'll use a master branch for similarity with the other repositories, but I also added a comment to https://github.com/enjoy-digital/litex/issues/1025 to address this is in the future.

enjoy-digital commented 3 years ago

@bunnie: https://github.com/enjoy-digital/litex/commit/c98c777bed3fec4c459361333f26e2292611d75b should remove the picolibc and compiler_rtdependencies for your use case.

gatecat commented 3 years ago

The pip install route didn't work for me, looks like the submodule data isn't being copied correctly (I can see the pip install does try and fetch it, but it ultimately doens't end up in the right place)?

% tree /home/gatecat/.local/lib/python3.9/site-packages/pythondata_software_picolibc     
/home/gatecat/.local/lib/python3.9/site-packages/pythondata_software_picolibc
├── data
├── __init__.py
└── __pycache__
    └── __init__.cpython-39.pyc
bunnie commented 3 years ago

@bunnie: c98c777 should remove the picolibc and compiler_rtdependencies for your use case.

Thanks. I'll pick it up when you do 2021.12 release. Since the hardware is ostensibly "finished", we're trying to stabilize the train for Precursor so we're pulling only tagged releases right now.

enjoy-digital commented 3 years ago

@bunnie: Sure, I can understand :) @gatecat: Thanks for the feedback, it should be good now, would you mind trying again?

tcal-x commented 3 years ago

I see a slight change in maximum UART speed. We had been using 3686400 with Arty A7-35t (which has an "HQ" FTDI chip). After bumping everything including the picolibc change, that speed does allow a stable terminal connection, but serialboot upload gives a CRC error. 

[LXTERM] Upload to device failed due to data corruption (CRC error)

It's OK if we reduce the speed to half that, 1843200.

The issue seems to be on the gateware side, not on the lxterm side (checked by cross-testing with different versions).

enjoy-digital commented 3 years ago

@tcal-x: Thanks for the feedback. I'll do some tests tomorrow and will see if I can implement an automatic calibration of the upload parameters in litex_term to avoid future similar issues.

tcal-x commented 3 years ago

@tcal-x: Thanks for the feedback. I'll do some tests tomorrow and will see if I can implement an automatic calibration of the upload parameters in litex_term to avoid future similar issues.

Thanks @enjoy-digital , that might help with https://github.com/enjoy-digital/litex/issues/773 too :)

enjoy-digital commented 3 years ago

Indeed @tcal-x, that's also for this one that I want to implement this :)

kgugala commented 3 years ago

@tcal-x is the baud related to picolibc? Maybe it's worth running serial load in simulation?

tcal-x commented 3 years ago

@kgugala I have not narrowed it down to a specific commit or even to a specific repository included in my bump. So yes, it may be completely unrelated. It would be worth testing on a pure LiteX Arty build to see if I see the same change.

enjoy-digital commented 3 years ago

@kgugala: The issue could be that the CPU takes more time to process/copy the payload with picolibc than with previous libbase and that litex_term parameters need to be updated. That's why I want to avoid manual tweaking of the parameters.

kgugala commented 3 years ago

@kgugala: The issue could be that the CPU takes more time to process/copy the payload with picolibc than with previous libbase and that litex_term parameters need to be updated. That's why I want to avoid manual tweaking of the parameters.

CPU runs way faster than UART it should be able to process this

tcal-x commented 3 years ago

I do see the same CRC error at 3686400 with a pure LiteX build. In litex_boards/targets/:

./digilent_arty.py --uart-baudrate=3686400 --build --load
litex_bare_metal_demo --build-path build/digilent_arty
lxterm --speed=3686400 --kernel=demo.bin /dev/ttyUSB1
--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
[LXTERM] Received firmware download request from the device.
[LXTERM] Uploading demo.bin to 0x40000000 (6516 bytes)...
[LXTERM] Upload to device failed due to data corruption (CRC error)
mithro commented 3 years ago

I think a simple acknowledgement type protocol would be super helpful. Thinks like running in a VM and the USB stack can also affect the achievable bandwidth even with the same gateware + firmware.

As well, if something got slower with picolibc we should also fix that!

gatecat commented 3 years ago

@gatecat: Thanks for the feedback, it should be good now, would you mind trying again?

Yep, working fine now, thanks!

enjoy-digital commented 3 years ago

CPU runs way faster than UART it should be able to process this

@kgugala: In fact the frame CRC and memcpy are done between each frame, which constraints things a lot more. Ideally, we should do the CRC during reception of frame N and memcpy of frame N during reception of the frame N+1; or increase the FIFO RX size/limit payload length.

For now I allowed the serial boot frame reception to time out (https://github.com/enjoy-digital/litex/commit/80cb53fb04060763152cc4fd5f33bfdef8cff90f) and added an auto-calibration in litex_term (https://github.com/enjoy-digital/litex/commit/56614804095ba03a8afec6270281b3d6981b9604). This also adds a --safe mode that should always work (but will be slow on regular UART with high round trip latency).

@tcal-x: The example you were providing now works correctly on my side, can you try it?

@mithro: It's indeed however possible that picolibc is slower on this than the previous libbase. It should be easier to improve this with the auto-calibration.

tcal-x commented 3 years ago

@enjoy-digital yes it fixes it for me. I'm also eager to test that it fixed the serialboot issue on Fomu, especially in conjunction with https://github.com/litex-hub/litex-boards/commit/5addd7f7d8a372cd7eb792af2d3a56b706b022f2 -- it's a good day for Fomu!

akioolin commented 3 years ago

Hi,

after update to latest litex by using litex_setup.py update. I met the following problem. please see the below log.

make: 「/opt/litex/litex-boards/litex_boards/targets/build/qmtech_wukong/software/libc」 if [ -d "/opt/litex/litex/litex/soc/software/libc/riscv" ]; then \ cp /opt/litex/litex/litex/soc/software/libc/riscv/* /opt/litex/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/machine/riscv/ ;\ fi meson /opt/litex/pythondata-software-picolibc/pythondata_software_picolibc/data \ -Dmultilib=false \ -Dpicocrt=false \ -Datomic-ungetc=false \ -Dthread-local-storage=false \ -Dio-long-long=true \ -Dformat-default=integer \ -Dincludedir=picolibc/riscv64-unknown-elf/include \ -Dlibdir=picolibc/riscv64-unknown-elf/lib \ --cross-file cross.txt WARNING: Unknown CPU family riscv, please report this at https://github.com/mesonbuild/meson/issues/new The Meson build system Version: 0.53.2 Source dir: /opt/litex/pythondata-software-picolibc/pythondata_software_picolibc/data Build dir: /opt/litex/litex-boards/litex_boards/targets/build/qmtech_wukong/software/libc Build type: cross build Project name: picolibc Project version: 1.7.2 C compiler for the build machine: ccache cc (gcc 9.3.0 "cc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0") C linker for the build machine: cc ld.bfd 2.34 C compiler for the host machine: riscv64-unknown-elf-gcc (gcc 10.1.0 "riscv64-unknown-elf-gcc (SiFive GCC 10.1.0-2020.08.2) 10.1.0") C linker for the host machine: riscv64-unknown-elf-gcc ld.bfd 2.35.0-2020 Build machine cpu family: x86_64 Build machine cpu: x86_64 Host machine cpu family: riscv Host machine cpu: vexriscv Target machine cpu family: riscv Target machine cpu: vexriscv Compiler for C supports arguments -fno-stack-protector: YES Compiler for C supports arguments -fno-common: YES Compiler for C supports arguments -frounding-math: YES Program scripts/duplicate-names found: YES (/opt/litex/pythondata-software-picolibc/pythondata_software_picolibc/data/scripts/duplicate-names) Compiler for C supports link arguments -Wl,--defsym=_start=0: YES Compiler for C supports link arguments -Wl,-alias,main,testalias: NO Compiler for C supports function attribute alias: YES Compiler for C supports function attribute format: YES Configuring picolibc.specs using configuration Configuring picolibcpp.specs using configuration Configuring test.specs using configuration Configuring picolibc.ld using configuration Configuring picolibcpp.ld using configuration Compiler for C supports arguments -Wno-missing-braces -Wmissing-braces: YES Compiler for C supports arguments -Wno-implicit-int -Wimplicit-int: YES Compiler for C supports arguments -Wno-return-type -Wreturn-type: YES Compiler for C supports arguments -Werror=implicit-function-declaration: YES Compiler for C supports arguments -Werror=vla: YES Checking if "long double check" compiles: YES Checking if "long double same as double" compiles: NO Checking if "packed structs may contain bitfields" compiles: YES Checking if "has builtin_mul_overflow" links: YES Checking if "supports _Complex" compiles: YES Checking if "has __builtin_expect" links: YES Compiler for C supports arguments -Werror: YES Checking if "attribute alloc_size" compiles: NO Compiler for C supports arguments -Werror: YES Checking if "attributes constructor/destructor" compiles: YES Checking if "test for builtin_alloca" links: YES Checking if "test for builtin_ffs" links: YES Checking if "test for __builtin_ffsl" links: YES Checking if "test for builtin_ffsll" links: YES Checking if "test for builtin_ctz" links: YES Checking if "test for __builtin_ctzl" links: YES Checking if "test for builtin_ctzll" links: YES Checking if "test for builtin_copysignl" links: NO Checking if "test for __builtin_copysign" links: NO Checking if "test for builtin_isinfl" links: YES Checking if "test for builtin_isinf" links: YES Checking if "test for __builtin_isnanl" links: YES Checking if "test for builtin_isnan" links: YES Checking if "test for __builtin_finitel" links: YES Checking if "test for __builtin_isfinite" links: YES Compiler for C supports arguments -fno-tree-loop-distribute-patterns: YES Compiler for C supports arguments -fno-builtin: YES Compiler for C supports arguments -ffunction-sections: YES Compiler for C supports arguments -ftls-model=local-exec: YES Message: host_cpu_family riscv Compiler for C supports arguments -fstack-protector-all: YES Compiler for C supports arguments -fstack-protector-strong: YES Compiler for C supports arguments -fno-builtin-malloc: YES Compiler for C supports arguments -fno-builtin-free: YES Message: libc/string/memcpy.c: machine overrides generic Message: libc/string/memmove.S: machine overrides generic Message: libc/string/memset.S: machine overrides generic Message: libc/string/strcpy.c: machine overrides generic Message: libc/string/strlen.c: machine overrides generic Message: libc/string/strcmp.S: machine overrides generic Message: libc/include/sys/fenv.h: machine overrides generic Message: libc/include/machine/math.h: machine overrides generic Compiler for C supports arguments -fno-builtin-exp2: YES Message: Set c_args_exp2 Message: libm/math/ef_sqrt.c: machine overrides generic Message: libm/math/e_sqrt.c: machine overrides generic Message: libm/math/s_fabs.c: machine overrides generic Message: libm/math/sf_fabs.c: machine overrides generic Message: libm/common/s_finite.c: machine overrides generic Message: libm/common/s_copysign.c: machine overrides generic Message: libm/common/s_isinf.c: machine overrides generic Message: libm/common/s_isnan.c: machine overrides generic Message: libm/common/s_fma.c: machine overrides generic Message: libm/common/s_fmax.c: machine overrides generic Message: libm/common/s_fmin.c: machine overrides generic Message: libm/common/s_fpclassify.c: machine overrides generic Message: libm/common/s_lrint.c: machine overrides generic Message: libm/common/s_llrint.c: machine overrides generic Message: libm/common/s_lround.c: machine overrides generic Message: libm/common/s_llround.c: machine overrides generic Message: libm/common/sf_finite.c: machine overrides generic Message: libm/common/sf_copysign.c: machine overrides generic Message: libm/common/sf_isinf.c: machine overrides generic Message: libm/common/sf_isnan.c: machine overrides generic Message: libm/common/sf_fma.c: machine overrides generic Message: libm/common/sf_fmax.c: machine overrides generic Message: libm/common/sf_fmin.c: machine overrides generic Message: libm/common/sf_fpclassify.c: machine overrides generic Message: libm/common/sf_lrint.c: machine overrides generic Message: libm/common/sf_llrint.c: machine overrides generic Message: libm/common/sf_lround.c: machine overrides generic Message: libm/common/sf_llround.c: machine overrides generic Message: libm/fenv/feclearexcept.c: machine overrides generic Message: libm/fenv/fegetenv.c: machine overrides generic Message: libm/fenv/fegetexceptflag.c: machine overrides generic Message: libm/fenv/fegetround.c: machine overrides generic Message: libm/fenv/feholdexcept.c: machine overrides generic Message: libm/fenv/feraiseexcept.c: machine overrides generic Message: libm/fenv/fesetenv.c: machine overrides generic Message: libm/fenv/fesetexceptflag.c: machine overrides generic Message: libm/fenv/fesetround.c: machine overrides generic Message: libm/fenv/fetestexcept.c: machine overrides generic Message: libm/fenv/feupdateenv.c: machine overrides generic Configuring picolibc.h using configuration Build targets in project: 35

Found ninja-1.10.2.git.kitware.jobserver-1 at /usr/local/bin/ninja meson compile

ERROR: Neither directory contains a build file meson.build. make: * [/opt/litex/litex/litex/soc/software/libc/Makefile:38：__libc.a] Error 1 make: 「/opt/litex/litex-boards/litex_boards/targets/build/qmtech_wukong/software/libc」 Traceback (most recent call last): File "./qmtech_wukong.py", line 186, in main() File "./qmtech_wukong.py", line 179, in main builder.build(vivado_build_argdict(args), run=args.build) File "/opt/litex/litex/litex/soc/integration/builder.py", line 304, in build self._generate_rom_software(compile_bios=use_bios) File "/opt/litex/litex/litex/soc/integration/builder.py", line 249, in _generate_rom_software subprocess.check_call(["make", "-C", dst_dir, "-f", makefile]) File "/usr/lib/python3.8/subprocess.py", line 364, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['make', '-C', '/opt/litex/litex-boards/litex_boards/targets/build/qmtech_wukong/software/libc', '-f', '/opt/litex/litex/litex/soc/software/libc/Makefile']' returned non-zero exit status 2.

====================================================================

If I copy the meson.build file from /opt/litex/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/machine/riscv to /opt/litex/litex-boards/litex_boards/targets/build/qmtech_wukong/software/libc the error message will change to

ERROR: Both directories contain a build file meson.build. not ERROR: Neither directory contains a build file meson.build.

I had already install meson, ninja by using pip3. where did I miss?

BR, Akio

tcal-x commented 3 years ago

@akioolin , I think I saw a similar issue in CFU Playground; the solution there was: make sure that the new picolibc submodule gets a recursive update, so that it loads its submodules.

I think this should happen if you run ./litex_setup.py init update install, but please check that the pythondata_software_picolibc/data submodule is loaded and not an empty directory.

akioolin commented 3 years ago

Hi, @tcal-x :

many thanks. after check the content of litex_setup.py about picolibc part, the recursive flag is true. and check the content of /opt/litex/pythondata-software-picolibc/pythondata_software_picolibc/data. the following is shown.

CODE_OF_CONDUCT.md COPYING.picolibc find-copyright meson.build picolibc.ld.in semihost CONTRIBUTING.md cross.tmpl hello-world meson_options.txt picolibc.specs.in test COPYING.GPL2 doc make-copyrights newlib README.md test.specs.in COPYING.NEWLIB dummyhost make-target picocrt scripts

it is not empty.

BTW, I do did "git submodule update --recursive" in /opt/litex/pythondata-software-picolibc/pythondata_software_picolibc/data.

It is very strange.

BR, Akio

akioolin commented 3 years ago

Hi,

after some try and test, I found if change the command from "meson compile" to "ninja -C ." in litex/litex/soc/software/libc/Makefile, the build will continue.

But it will appear new error. such like the followings,

/usr/local/toolchains/riscv64-unknown-elf-gcc-10.1.0/bin/../lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/bin/ld: ../libc/libc.a(csinhf.c.o): ABI is incompatible with that of the selected emulation: target emulation elf64-littleriscv' does not matchelf32-littleriscv'

It seems the target setting error. where could I change the target type?

Many Thanks.

BR, Akio

syed-ahmed commented 3 years ago

Anybody seen an issue like this where the linker complains about: unrecognised emulation mode: abi=ilp32? This is happening to me after I upgraded litex. I tried upgrading my old driver code to the new picolibc changes but not sure if I messed something up. Is there a migration guide for moving to latest litex with picolibc? cc: @enjoy-digital @kgugala

Here's how my driver code gets compiled:

riscv64-unknown-elf-gcc -std=gnu99 -c -MD -MP -Os -march=rv32im     -mabi=ilp32 -D__vexriscv__ -g3 -fomit-frame-pointer -Wall -fno-builtin -fno-stack-protector -I/media/lilbirb/scratch/code/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio -I/media/lilbirb/scratch/code/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/include -I/media/lilbirb/scratch/code/litex/litex/soc/software/libbase -I/media/lilbirb/scratch/code/litex/litex/soc/software/include -I/media/lilbirb/scratch/code/litex/litex/soc/software -I/media/lilbirb/scratch/code/rvpld/controller/build/software/include -I/media/lilbirb/scratch/code/rvpld/controller/build/software/include/../libc -I/media/lilbirb/scratch/code/litex/litex/soc/cores/cpu/vexriscv -fexceptions -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes  axi_lite_driver.c -o axi_lite_driver.o
riscv64-unknown-elf-gcc -std=gnu99 -c -MD -MP -Os -march=rv32im     -mabi=ilp32 -D__vexriscv__ -g3 -fomit-frame-pointer -Wall -fno-builtin -fno-stack-protector -I/media/lilbirb/scratch/code/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio -I/media/lilbirb/scratch/code/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/include -I/media/lilbirb/scratch/code/litex/litex/soc/software/libbase -I/media/lilbirb/scratch/code/litex/litex/soc/software/include -I/media/lilbirb/scratch/code/litex/litex/soc/software -I/media/lilbirb/scratch/code/rvpld/controller/build/software/include -I/media/lilbirb/scratch/code/rvpld/controller/build/software/include/../libc -I/media/lilbirb/scratch/code/litex/litex/soc/cores/cpu/vexriscv -fexceptions -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes  isr.c -o isr.o
riscv64-unknown-elf-gcc -std=gnu99 -c -MD -MP -Os -march=rv32im     -mabi=ilp32 -D__vexriscv__ -g3 -fomit-frame-pointer -Wall -fno-builtin -fno-stack-protector -I/media/lilbirb/scratch/code/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio -I/media/lilbirb/scratch/code/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/include -I/media/lilbirb/scratch/code/litex/litex/soc/software/libbase -I/media/lilbirb/scratch/code/litex/litex/soc/software/include -I/media/lilbirb/scratch/code/litex/litex/soc/software -I/media/lilbirb/scratch/code/rvpld/controller/build/software/include -I/media/lilbirb/scratch/code/rvpld/controller/build/software/include/../libc -I/media/lilbirb/scratch/code/litex/litex/soc/cores/cpu/vexriscv -fexceptions -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes  dma_driver.c -o dma_driver.o
riscv64-unknown-elf-gcc -std=gnu99 -c -MD -MP -Os -march=rv32im     -mabi=ilp32 -D__vexriscv__ -g3 -fomit-frame-pointer -Wall -fno-builtin -fno-stack-protector -I/media/lilbirb/scratch/code/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio -I/media/lilbirb/scratch/code/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/include -I/media/lilbirb/scratch/code/litex/litex/soc/software/libbase -I/media/lilbirb/scratch/code/litex/litex/soc/software/include -I/media/lilbirb/scratch/code/litex/litex/soc/software -I/media/lilbirb/scratch/code/rvpld/controller/build/software/include -I/media/lilbirb/scratch/code/rvpld/controller/build/software/include/../libc -I/media/lilbirb/scratch/code/litex/litex/soc/cores/cpu/vexriscv -fexceptions -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes  main.c -o main.o
riscv64-unknown-elf-ld -nostdlib -nodefaultlibs -Wl,--no-dynamic-linker -Wl,--build-id=none -MD -MP -Os -march=rv32im     -mabi=ilp32 -D__vexriscv__ -g3 -fomit-frame-pointer -Wall -fno-builtin -fno-stack-protector -I/media/lilbirb/scratch/code/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio -I/media/lilbirb/scratch/code/pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/include -I/media/lilbirb/scratch/code/litex/litex/soc/software/libbase -I/media/lilbirb/scratch/code/litex/litex/soc/software/include -I/media/lilbirb/scratch/code/litex/litex/soc/software -I/media/lilbirb/scratch/code/rvpld/controller/build/software/include -I/media/lilbirb/scratch/code/rvpld/controller/build/software/include/../libc -I/media/lilbirb/scratch/code/litex/litex/soc/cores/cpu/vexriscv -fexceptions -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -L/media/lilbirb/scratch/code/rvpld/controller/build/software/include \
    -T linker.ld \
    -N -o firmware.elf \
    crt0.o \
     axi_lite_driver.o  isr.o  dma_driver.o  main.o \
    -L../../build/software/libc -L../../build/software/libcompiler_rt -L../../build/software/libbase -L../../build/software/libfatfs -L../../build/software/liblitespi -L../../build/software/liblitedram -L../../build/software/libliteeth -L../../build/software/liblitesdcard -L../../build/software/liblitesata -L../../build/software/bios \
    -lc -lcompiler_rt -lbase -lfatfs -llitespi -llitedram -lliteeth -llitesdcard -llitesata
riscv64-unknown-elf-ld: unrecognised emulation mode: abi=ilp32
Supported emulations: elf64lriscv elf32lriscv
make: *** [Makefile:22: firmware.elf] Error 1
gregdavill commented 3 years ago

@syed-ahmed I've seen this when updating some legacy code too. The issue is calling riscv64-unknown-elf-ld directly. Check out how the LiteX bios is compiled, you should use riscv64-unknown-elf-gcc for the final linking step instead. gcc will invoke ld as needed.

enjoy-digital commented 2 years ago

We can probably close this issue now.