Uploading binary fails at BAUD rates over 230400

[troibe]

I'm not quite sure what is causing this but I tried different BAUD rates on the Arty. When using LiteX+BlackParrot I can upload at BAUD rates up to 921600. This makes it easy to use LiteScope over Ethernet and still have decent upload speed over UART.

serialboot
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
[LXTERM] Received firmware download request from the device.
[LXTERM] Uploading boot-arty-success.bin to 0x80000000 (15705408 bytes)...
[LXTERM] Upload to device failed due to data corruption (CRC error)

[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 me@mith.ro 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: https://github.com/enjoy-digital/litex/issues/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 https://github.com/enjoy-digital/litex/commit/80cb53fb04060763152cc4fd5f33bfdef8cff90f and https://github.com/enjoy-digital/litex/commit/56614804095ba03a8afec6270281b3d6981b9604.

[troibe]

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

[enjoy-digital]

@developandplay: Great, thanks for the feedback.