litex_sdk submodule missing?

[machdyne]

Hi. When trying to build the demo I get:

usb_main.c:20:10: fatal error: litesdk_timer.h: No such file or directory
   20 | #include <litesdk_timer.h>

It looks like the repo expects a submodule git@github.com:suarezvictor/litex_sdk.git but it doesn't seem to exist.

[suarezvictor]

Oh, I see that the repo was private, now made public, please retry

[machdyne]

Thanks, I was able to get it to build.

I had to change WEAK to __attribute__((weak)) in isr.c to avoid a compilation error.

However, now it seems to be getting stuck at liftoff.

I am using an Arty A7-100 and built the gateware with this command:

$ ./digilent_arty.py --timer-uptime --uart-baudrate=1000000 --with-pmod-gpio --integrated-sram-size 32768 --sys-clk-freq=200e6     --cpu-type=vexriscv --cpu-variant=full --variant=a7-100 --build

Using up-to-date official litex, I get the random data on VGA output and the scrolling LEDs, seems to be working.

Then:

$ litex_term --speed 1000000 --kernel usb_main.elf.bin /dev/ttyUSB1
litex> serialboot
[LITEX-TERM] Received firmware download request from the device.
[LITEX-TERM] Uploading usb_main.elf.bin to 0x40000000 (896008 bytes)...
[LITEX-TERM] Upload calibration... (inter-frame: 10.00us, length: 64)
[LITEX-TERM] Upload complete (86.1KB/s).
[LITEX-TERM] Booting the device.
[LITEX-TERM] Done.
Executing booted program at 0x40000000

--============= Liftoff! ===============--

Maybe it's an issue with my toolchain ... please let me know if you have any ideas.

[suarezvictor]

I didn't test it with the newest version of LiteX, so I published the link to my fork, see the tweet or the 'litex' repo on my github. We'll make it work one way or the other ;-)

El sáb., 11 feb. 2023 06:50, Machdyne @.***> escribió:

Thanks, I was able to get it to build.

I had to change WEAK to attribute((weak)) in isr.c to avoid a compilation error.

However, now it seems to be getting stuck at liftoff.

I am using an Arty A7-100 and built the gateware with this command:

$ ./digilent_arty.py --timer-uptime --uart-baudrate=1000000 --with-pmod-gpio --integrated-sram-size 32768 --sys-clk-freq=200e6 --cpu-type=vexriscv --cpu-variant=full --variant=a7-100 --build

Using up-to-date official litex, I get the random data on VGA output and the scrolling LEDs, seems to be working.

Then:

$ litex_term --speed 1000000 --kernel usb_main.elf.bin /dev/ttyUSB1 litex> serialboot [LITEX-TERM] Received firmware download request from the device. [LITEX-TERM] Uploading usb_main.elf.bin to 0x40000000 (896008 bytes)... [LITEX-TERM] Upload calibration... (inter-frame: 10.00us, length: 64) [LITEX-TERM] Upload complete (86.1KB/s). [LITEX-TERM] Booting the device. [LITEX-TERM] Done. Executing booted program at 0x40000000

--============= Liftoff! ===============--

Maybe it's an issue with my toolchain ... please let me know if you have any ideas.

— Reply to this email directly, view it on GitHub https://github.com/suarezvictor/litex_imgui_usb_demo/issues/1#issuecomment-1426678325, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBHVWJF4UH2T7XM2XOHHSLWW5OF5ANCNFSM6AAAAAAUYRRA6Y . You are receiving this because you commented.Message ID: @.***>

[suarezvictor]

The weak attribute should be kept, please do not remove it

[machdyne]

It seems that the WEAK macro is undefined for me:

isr.c:12:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'i2s_tx_isr'
   12 | void WEAK i2s_tx_isr(void);
      |           ^~~~~~~~~~
isr.c:13:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'i2s_rx_isr'
   13 | void WEAK i2s_rx_isr(void);
      |           ^~~~~~~~~~

I have tried building with your litex fork and get the same result, will try again.

[suarezvictor]

There was a pending commit to https://github.com/suarezvictor/litex_sdk, can you sync with it and retry? it adds the WEAK macro

[machdyne]

I get the same result with that update. One additional thing, the simulation doesn't seem to work either. It says:

[gmii_ethernet] loaded (0x56033e1331c0)
[serial2tcp] loaded (0x56033e1331c0)
[clocker] loaded
[xgmii_ethernet] loaded (0x56033e1331c0)
[ethernet] loaded (0x56033e1331c0)
[serial2console] loaded (0x56033e1331c0)
[video] loaded (0x56033e1331c0)
[spdeeprom] loaded (addr = 0x0)
[clocker] sys_clk: freq_hz=1000000, phase_deg=0

        __   _ __      _  __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|
   Build your hardware, easily!

 (c) Copyright 2012-2022 Enjoy-Digital
 (c) Copyright 2007-2015 M-Labs

 BIOS built on Feb 18 2023 08:02:00
 BIOS CRC passed (ca392fa9)

 LiteX git sha1: dc438a03

--=============== SoC ==================--
CPU:        VexRiscv @ 1MHz
BUS:        WISHBONE 32-bit @ 4GiB
CSR:        32-bit data
ROM:        128KiB
SRAM:       8KiB
L2:     8KiB
SDRAM:      65536KiB 32-bit @ 1MT/s (CL-2 CWL-2)

--========== Initialization ============--
Initializing SDRAM @0x40000000...
Switching SDRAM to software control.
Switching SDRAM to hardware control.

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
Timeout
Executing booted program at 0x40000000

--============= Liftoff! ===============--
Initializing ImGui at 800x600...

But nothing shows up in the Litex Video Simulator. Maybe I'm not being patient enough, I only waited a few minutes.

[suarezvictor]

The vídeo simulator is newer than the ImGUI project and not much tested. However on some early tests I discovered that ImGUI takes too much time creating the font atlas at initialization. So there are these options 1) just wait 2) wait for me to publish a version of ImGUI that has a prebuilt font atlas 3) wait for me to have finish a much faster simulator based on integration of external emulators, including one that runs natively if the instruction set matches the host For case 1 I wish you luck, it may work indeed For other cases please let me know how important that options would be for you since I currently lack time for further development. Last but not least did it work in hardware? I mean the Arty board. That was the only option tested by me. Un hardware, both your USB host PMOD compatible and the DVI one should work.

El sáb., 18 feb. 2023 04:07, Machdyne @.***> escribió:

I get the same result with that update. One additional thing, the simulation doesn't seem to work either. It says:

[gmii_ethernet] loaded (0x56033e1331c0) [serial2tcp] loaded (0x56033e1331c0) [clocker] loaded [xgmii_ethernet] loaded (0x56033e1331c0) [ethernet] loaded (0x56033e1331c0) [serial2console] loaded (0x56033e1331c0) [video] loaded (0x56033e1331c0) [spdeeprom] loaded (addr = 0x0) [clocker] sys_clk: freq_hz=1000000, phase_deg=0

    __   _ __      _  __
   / /  (_) /____ | |/_/
  / /__/ / __/ -_)>  <
 /____/_/\__/\__/_/|_|

Build your hardware, easily!

(c) Copyright 2012-2022 Enjoy-Digital (c) Copyright 2007-2015 M-Labs

BIOS built on Feb 18 2023 08:02:00 BIOS CRC passed (ca392fa9)

LiteX git sha1: dc438a03

--=============== SoC ==================-- CPU: VexRiscv @ 1MHz BUS: WISHBONE 32-bit @ 4GiB CSR: 32-bit data ROM: 128KiB SRAM: 8KiB L2: 8KiB SDRAM: 65536KiB 32-bit @ 1MT/s (CL-2 CWL-2)

--========== Initialization ============-- Initializing SDRAM @0x40000000... Switching SDRAM to software control. Switching SDRAM to hardware control.

--============== Boot ==================-- Booting from serial... Press Q or ESC to abort boot completely. sL5DdSMmkekro Timeout Executing booted program at 0x40000000

--============= Liftoff! ===============-- Initializing ImGui at 800x600...

But nothing shows up in the Litex Video Simulator. Maybe I'm not being patient enough, I only waited a few minutes.

— Reply to this email directly, view it on GitHub https://github.com/suarezvictor/litex_imgui_usb_demo/issues/1#issuecomment-1435508446, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBHVWMPKFTU2ZU2NPVTHC3WYBYLZANCNFSM6AAAAAAUYRRA6Y . You are receiving this because you commented.Message ID: @.***>

[suarezvictor]

It takes 9 minutes to start in my machine, with the font caching (still working on it) it reduces to 1 minute Didn't the update solve the WEAK macro issue?

[machdyne]

It's not working on A7-100T so far, nothing happens after "Liftoff!".

The WEAK macro is fixed but I was manually replacing it with the correct attribute so I don't think that was the issue.

I have been using your litex fork but I wonder if there are plans to get it working with the latest version of litex.

I'm out of ideas for the moment but I'll post back here if there's any change.

[suarezvictor]

I'm traveling now for a couple of days with no access to my development PC, but I'm commited to help with this until it works also for you when I'm back, and then on your board when I receive it. In the mean time I'd recommend that you run the LiteX demo (with the donut example) to check your full setup.

In regards to the issue relating to the WEAK macro, if you see the update it's correctly defined, please check that the Lib folder contains the updated sources, besides you manually patched it.

Just in case, I'm using LiteX litex_term script to upload firmware to the hardware instead of the serialboot command. Make sure you're not using the .bin made for simulation since the compiled firmware is not the same as for hardware.

Btw, I assume you configured the SoC main configuration python script (digilent_arty.py) for the 100T.

As prevously shown, the simulation is able to render the screen after various minutes, and that can be significantly optimized as of my tests (not ready to publish yet)

El sáb., 18 feb. 2023 08:32, Machdyne @.***> escribió:

It's not working on A7-100T so far, nothing happens after "Liftoff!".

The WEAK macro is fixed but I was manually replacing it with the correct attribute so I don't think that was the issue.

I have been using your litex fork but I wonder if there are plans to get it working with the latest version of litex.

I'm out of ideas for the moment but I'll post back here if there's any change.

— Reply to this email directly, view it on GitHub https://github.com/suarezvictor/litex_imgui_usb_demo/issues/1#issuecomment-1435648460, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBHVWIT3BGSBYU5V6M2PITWYCXNXANCNFSM6AAAAAAUYRRA6Y . You are receiving this because you commented.Message ID: @.***>

[machdyne]

Just in case, I'm using LiteX litex_term script to upload firmware to the hardware instead of the serialboot command. Make sure you're not using the .bin made for simulation since the compiled firmware is not the same as for hardware.

I'm using make all to build usb_main.elf.bin ... this seems to be used by the sim, is there another way to build it for hardware?

[suarezvictor]

You have to first run one of those commands on the root dir: https://github.com/suarezvictor/litex_imgui_usb_demo/blob/main/digilent_arty.py#L431 Add the --variant flag for the a7-100 (check if that's the qrgument value in LiteX docs) Then cd to the src dir and run make BOARD=digilent_arty usb_main.elf.bin

I can't check that but something like that should work. I bet you have tried a .bin targeted to simulation and it hangs since the peripherals get mapped to different addresess. Did the simulation work after a lot of waiting? I tested it today

[suarezvictor]

DVI flag is here, set to false by default requiring the VGA PMOD. https://github.com/suarezvictor/litex_imgui_usb_demo/blob/main/digilent_arty.py#L40 As shown in the example commands, the system frequency and other parameters should change for analog por digital output. DVI expects direct connection (tdms outputs) but I have some code to use 3.3v and your PMOD compatible adapter

El sáb., 18 feb. 2023 12:25, Machdyne @.***> escribió:

Just in case, I'm using LiteX litex_term script to upload firmware to the hardware instead of the serialboot command. Make sure you're not using the .bin made for simulation since the compiled firmware is not the same as for hardware.

I'm using make all to build usb_main.elf.bin ... this seems to be used by the sim, is there another way to build it for hardware?

— Reply to this email directly, view it on GitHub https://github.com/suarezvictor/litex_imgui_usb_demo/issues/1#issuecomment-1435699562, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBHVWOE6PK75ZXYCPT2IRTWYDSVHANCNFSM6AAAAAAUYRRA6Y . You are receiving this because you commented.Message ID: @.***>

[machdyne]

I can't check that but something like that should work. I bet you have tried a .bin targeted to simulation and it hangs since the peripherals get mapped to different addresess.

That was the problem. It's printing FPS over the UART and I see the 3 windows over VGA. USB keyboard/mouse doesn't seem to do anything yet.

This is the USB host PMOD pinout:

Pin	Signal
1	USB2_DP
2	USB2_DN
3	USB1_DP
4	USB1_DN
5	GND
6	3V3

[suarezvictor]

Good to know it wasn't an issue with the code but just not so clear build instructions. I'm happy of having helped to found it while on the bus ;-)

The USB host uses just GPIOs bits in the 8-15 range, that gets mapped to the Arty PMOD-D here https://github.com/suarezvictor/litex_imgui_usb_demo/blob/main/digilent_arty.py#L282 Note that GPIOs 0-7 can't be used for limitations from the original library.

The selection of what pins are use for D+/D- of each port is here: https://github.com/suarezvictor/litex_imgui_usb_demo/blob/main/src/usb.cpp#L133

From the pinout you have sent, it's different and you have to update the source accordingly.

At program startup, the recognized USB device's descriptors are printed to the console, with a message about if they're a HID device and which one (mouse and keyboard are the only supported). It's assumed that they're low speed devices as is almost always the case, and that the mouse uses 12-bit protocol (not sure how frequent is that but all tested mouses worked) If the devices are not recognized, you can try replugging them in the middle of execution since that's supported.