Setting uart_name to 'bridge' results in linker errors
See original GitHub issueI would like to use the uart bridge (for openocd debugging and for litescope).
So I changed my target file (atlys/base) and added:
[...]
def __init__(self, platform, **kwargs):
kwargs['uart_name']='bridge'
[...]
But I’m unable to run make gateware
for the following config:
export PLATFORM=atlys
export TARGET=base
export VARIANT=lite+debug
it results in linker errors:
riscv64-unknown-elf-ld: ../libbase/libbase-nofloat.a(uart.o): in function `uart_isr':
[...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:32: undefined reference to `uart_ev_pending_read'
riscv64-unknown-elf-ld: [...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:35: undefined reference to `uart_rxempty_read'
riscv64-unknown-elf-ld: [...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:46: undefined reference to `uart_ev_pending_write'
riscv64-unknown-elf-ld: [...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:47: undefined reference to `uart_txfull_read'
riscv64-unknown-elf-ld: [...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:38: undefined reference to `uart_rxtx_read'
riscv64-unknown-elf-ld: [...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:41: undefined reference to `uart_ev_pending_write'
riscv64-unknown-elf-ld: [...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:48: undefined reference to `uart_rxtx_write'
riscv64-unknown-elf-ld: ../libbase/libbase-nofloat.a(uart.o): in function `uart_write':
[...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:88: undefined reference to `uart_txfull_read'
riscv64-unknown-elf-ld: [...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:92: undefined reference to `uart_rxtx_write'
riscv64-unknown-elf-ld: ../libbase/libbase-nofloat.a(uart.o): in function `uart_init':
[...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:105: undefined reference to `uart_ev_pending_read'
riscv64-unknown-elf-ld: [...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:105: undefined reference to `uart_ev_pending_write'
riscv64-unknown-elf-ld: [...]litex-buildenv/third_party/litex/litex/soc/software/libbase/uart.c:106: undefined reference to `uart_ev_enable_write'
[...]litex-buildenv/third_party/litex/litex/soc/software/bios/Makefile:64: recipe for target 'bios.elf' failed
make[1]: *** [bios.elf] Error 1
make[1]: Leaving directory '[...]litex-buildenv/build/atlys_base_vexriscv/software/bios'
Traceback (most recent call last):
File "./make.py", line 185, in <module>
main()
File "./make.py", line 167, in main
vns = builder.build(**dict(args.build_option))
File "[...]litex-buildenv/third_party/litex/litex/soc/integration/builder.py", line 198, in build
self._generate_rom_software(not self.soc.integrated_rom_initialized)
File "[...]litex-buildenv/third_party/litex/litex/soc/integration/builder.py", line 178, in _generate_rom_software
subprocess.check_call(["make", "-C", dst_dir, "-f", makefile])
File "[...]litex-buildenv/build/conda/lib/python3.7/subprocess.py", line 363, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['make', '-C', '[...]litex-buildenv/build/atlys_base_vexriscv/software/bios', '-f', '[...]litex-buildenv/third_party/litex/litex/soc/software/bios/Makefile']' returned non-zero exit status 2.
So how do I deactivate that it builds the uart code?
I’m only able to run make gateware
when I use the stub uart (to keep the sw happy) and an additional uart bridge:
kwargs['uart_name']='stub'
sys_clk_freq = 75*1000000
# SoCSDRAM ---------------------------------------------------------------------------------
SoCSDRAM.__init__(self, platform, clk_freq=sys_clk_freq, **kwargs)
self.submodules.uartbone = uart.UARTWishboneBridge(
pads = self.platform.request("serial"),
clk_freq = self.sys_clk_freq,
baudrate = 115200)
self.bus.add_master(name="uartbone", master=self.uartbone.wishbone)
Or is that maybe the only intended way? But even then I’m not able to use openocd over litex_server. I get 0xff for all reads inside the debug region (0xf00f0000). I also tried to read/write inside the sram region. That was working fine.
Issue Analytics
- State:
- Created 3 years ago
- Comments:21 (11 by maintainers)
Top Results From Across the Web
Understanding and fixing compiler and linker errors
How to fix common compiler and linker errors in C++. ... Compiler errors are restricted to single source code files and are the...
Read more >Linker error in UI Test Target | Apple Developer Forums
I am using XCode 7.1 Beta to develop an app in Swift 2.0. I am trying to access a few classes in the...
Read more >Calling Objective-C from Swift class causing linker errors
Your bridging header has an absolute path reference, I'd suggest removing that altogether by selecting it in build settings and hitting ...
Read more >Linker Errors and Warnings - Arm Developer
The Arm Compiler Errors and Warnings Reference Guide provides lists of the errors and warnings that each of the compilation tools can generate....
Read more >Linker Tools Error LNK2005 - Microsoft Learn
Learn more about: Linker Tools Error LNK2005. ... include this header file in more than one source file in your project, an error...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Maybe like this?: (I also found out that you can connect the wishbone-tool to the litex_server)
FTR, because it took me a while to figure out (and isn’t linked here), the PR mentioned in this change seems to be https://github.com/timvideos/litex-buildenv/pull/492 (which is currently still open, apparently due to CI failing on it, and it seems unclear if that’s a simulation or real problem.).
There’s also issue #497 to add an equivalent for the Digilent Arty. And I think if #492 is merged, this issue could probably be closed just leaving #497 as future work.
Ewen