Uploading binary fails at BAUD rates over 230400 about linux-on-litex-rocket

[gsomlo]

Booting via serial (and debugging with LiteScope over Ethernet) are not technically supported as part of linux-on-litex-rocket, but rather features of the underlying LiteX project in general. As such, any problems (or PRs, for that matter) would be better off if submitted there. Arty-specific UART problems probably belong in litex-hub/litex-boards. Last, but not least, I've never tried running LiteX at baud rates beyond 115200, so whether things work or not at 230400 is another LiteX (*not* linux-on-litex-rocket) specific question... HTH, --Gabriel

[troibe]

Hi Gabriel,
Thank you for the suggestion.
Maybe I should have highlighted in my first post that this only applies to Rocket Chip.
VexRiscv and BlackParrot perform fine at these higher baudrates.
Also I'm aware that you specifically don't mention the UART upload in the README.
That is why I brought up that usecase where both UART and Ethernet are being used.
I can also move this issue to LiteX (or pythondata-cpu-rocket) if you feel like that's a more appropriate place.
Best wishes
Martin

[gsomlo]

I can't reproduce this for the simple fact that I don't own an Arty
board (in fact, you yourself contributed Arty support to this project,
see commits c9e032c, 21706b1)... :)

So, at a very high level, you're either hitting a resource limit
(Rocket is the slowest and "fattest" CPU model supported by Litex afaik), or some
sort of bug in the way LiteX interacts with the UART IP block,
possibly triggered by the added "weight" of Rocket (as compared to the
"lighter" CPU models you say you tried successfully). Throw in
LiteScope's additional logic, and we're way off the beaten path in
terms of "typical" configurations for this project. Maybe this would work
even using Rocket, but maybe at a lower baud rate than what you're trying?

Chances are much better anyone will be able to even hazard a useful
guess as to just what the problem might be if you ask this question
where experienced LiteX devleopers hang out (e.g., on #litex IRC).

Opening an issue on LiteX (or litex-hub/litex-boards) might be the
next best thing to do.

The main question to ask would be: where do you expect any patch fixing this issue to be
applied? Unless that's against any file currently in linux-on-litex-rocket
(e.g., one of the .dts config files), or the fix is as simple as
providing a better command line to build LiteX bitstream, then asking here
is likely limiting yourself to asking me, which, as it turns out, is unfortunately not
as useful as I would have preferred... :)

Cheers,
--Gabriel

[mithro]

BTW @gsomlo - If you send me an email to [email protected] with a postal address and phone number, I'll get you an Arty.

[troibe]

Haha well manually reproducing the issue would probably be way too time consuming even if you had the FPGA.
Also yes it definitely does work with a lower baudrate. Even with Litescope.
You are completly right this is likely an RTL/BIOS issue. I'll move this issue to litex-boards.

@mithro Talking about funding and reproducibility: Did you, Florent or Antmicro consider building an FPGA test server?
I'm thinking of a setup similar to mobile phone farms. Of course combined with some powerful cloud server for simulation and synthesis.

[mithro]

@developandplay - Yes we did and are slowly working towards such as thing see https://antmicro.com/blog/2021/08/open-source-github-actions-runners-with-gcp-and-terraform/ -- We would love help making this happen.

[enjoy-digital]

@developandplay, @gsomlo: The issue is probably similar to this one: enjoy-digital/litex#773. I don't know the exact reason for now (otherwise #733 would be closed :)) but I'm planning to work on this soon. To avoid paying the latency penalty, we are sending multiple outstanding frames and with a high link_speed/cpu_freq ratio the CPU is probably not able to process fast enough the frames. I want to see how to avoid it or to add an automatic calibration phase in litex_term to determine the best parameters automatically.

[enjoy-digital]

@developandplay: This is probably fixed with enjoy-digital/litex@80cb53f and enjoy-digital/litex@5661480.

[troibe]

@enjoy-digital Thanks a lot. Just tried it and it works.

[enjoy-digital]

@developandplay: Great, thanks for the feedback.