question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Setting uart_name to 'bridge' results in linker errors

See original GitHub issue

I 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:open
  • Created 3 years ago
  • Comments:21 (11 by maintainers)

github_iconTop GitHub Comments

1reaction
cklarhorstcommented, Jul 21, 2020

Maybe like this?: (I also found out that you can connect the wishbone-tool to the litex_server)

# Connection Overview:
#                            
#      FPGA:                        
#                                                   |--> LiteScope
#   --SERIAL--> UARTWishboneBridge <--WISHBONE-BUS--+--> Crossover UART
#   |                                               |--> CPU Debug Interface
#   |  
#   |  Host:          
#   |                                  |-> LiteScope
#   |      |--->  litex_server  <--TCP-+-> litex_crossover_uart -> terminal
#   |      |                           |-> client that writes/reads any address
#   |      |                           |-> wishbone-tool
#   ^-----or
#          |                           |-> terminal
#          |-->   wishbone-tool <------+-> gdb
#                                      |-> client that writes/reads any address
#
# Note: The CPU Debug Interface is only available 
#       if your CPU_VARIANT includes "debug".
#
# Note: You can run multiple litex_server clients or 
#       wishbone-tool clients at the same time.
#
# There are currently two ways to connect to your UARTWishboneBridge:
#   1. Litex Server:
#       Usage: litex_server --uart --uart-port /dev/ttyXXX
#       - Features:
#           - LiteScope: (todo)
#           - Crossover UART:
#               - cd into build/[target]/test/
#               - start litex_crossover_uart
#               - connect to /dev/pts/XXX (e.g minicom -D /dev/pts/XXX)
#           - CPU Debug Interface: (not supported)
#           - Wishbone-tool: wishbone-tool --ethernet-host 127.0.0.1 --ethernet-tcp
#   2. Wishbone Tool (https://github.com/litex-hub/wishbone-utils)
#       - Features:
#           - LiteScope: (not supported)
#           - Crossover UART: 
#               wishbone-tool -s terminal --csr-csv build/[target]/test/csr.csv
#           - CPU Debug Interface: 
#               - wishbone-tool -s gdb --csr-csv build/[target]/test/csr.csv
#               - start gdb
#                   - issue: target remote :3333
0reactions
ewenmcneillcommented, Sep 23, 2020

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

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found