litex_term, fomu.py target: serialboot not working, but works with older revisions of litex_term

[tcal-x]

I am building and flashing the fomu target from litex-boards:

./fomu.py --cpu-type=vexriscv --cpu-variant=minimal  --build --flash

I then build the litex bare metal demo, although I need to make some modifications. I need to split the sram section to add a new section prog_ram in build/fomu_pvt/software/include/generated/regions.ld:

MEMORY {
        sram : ORIGIN = 0x00000000, LENGTH = 0x00010000
        prog_ram : ORIGIN = 0x00010000, LENGTH = 0x00010000
        spiflash : ORIGIN = 0x80000000, LENGTH = 0x01000000
        rom : ORIGIN = 0x80060000, LENGTH = 0x00008000
        csr : ORIGIN = 0x82000000, LENGTH = 0x00010000
}

In the demo linker.ld file, I move all of the sections except for fstack to prog_ram.

I then load the binary to the prog_ram section using lxterm:

lxterm  --kernel demo/demo.bin --kernel-adr  0x00010000  /dev/ttyACM0

This works if I check out litex/tools/litex_term.py from 05f83ca (Nov 13, 2020).

However, the serialboot fails if I use any version 513a799 (Dec 3, 2020) or newer. lxterm sees the serial boot request string and sends and ack, but the BIOS on Fomu does not recognize the ack, and times out.

[enjoy-digital]

@tcal-x: It could be related to the low speed of the CPU on the Fomu. Can you do a first test with sfl_outstanding = 0 here: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_term.py#L175?

[tcal-x]

Yeah, that's what I was thinking (that Fomu is just slow)!

Here's what I found:

• Baseline behavior with current litex_term.py: The progress bar zips to 100% very quickly, but then I get [LXTERM] Got unexpected response from device 'b'T''. Deeper debugging shows that the 'T' is from BIOS printing out 'Timeout'.
• Just setting sfl_outstanding = 0 as suggested causes the serial boot to hang at 2% progress.
• But setting sfl_outstanding = 0 and forcing sfl_payload = 64 makes it work! It's the same speed as when it was working before (at the Nov 13, 2020 commit), although one difference that I saw -- now, the progress bar is noticeably flickering during upload.
• I tried increasing sfl_outstanding to greater than zero, keeping sfl_payload = 64, but then I saw CRC errors.

[enjoy-digital]

tcal-x: OK thanks for the feedback. I initially wanted to add a self test to find the best sfl_outstanding/sfl_payload. Maybe we'll have to implement this then.

[david-sawatzke]

I have the same issue on the colorlight board with ecp5, running at 50MHz, loading over a crossover uart with the uart wishbone bridge. The issue is probably that the crossover uart is really slow. Since the crossover support was added afterwards, I'm not sure if it works with the earlier versions.

[giggiu16]

Same issue on OrangeCrab r0.2, any firmware fails to load using a usb-acm serial. The workaround of setting sfl_outstanding to 0 works to me also and firmware loads correctly without CRC errors.

Welcome to do some testing.

[tcal-x]

Update: with current litex (5661480) & litex-boards (litex-hub/litex-boards@5addd7f), I see this behavior when attempting to load the bare metal demo:

./kosagi_fomu.py --cpu-variant=minimal --build --flash
litex_bare_metal_demo --build-path build/kosagi_fomu_pvt
lxterm --kernel demo.bin /dev/ttyACM0

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
[LXTERM] Received firmware download request from the device.
[LXTERM] Uploading demo.bin to 0x40000000 (8208 bytes)...
[LXTERM] Upload calibration... (inter-frame: 10.00us, length: 64)
[LXTERM] Got unexpected response from device 'b'E''

The progress bar gets to about 50% before the final line error is displayed.

[tcal-x]

Here is earlier output from the initialization process:

--=============== SoC ==================--
CPU:            VexRiscv_Min @ 12MHz
BUS:            WISHBONE 32-bit @ 4GiB
CSR:            32-bit data
ROM:            32KiB
SRAM:           64KiB
FLASH:          2048KiB
MAIN-RAM:       64KiB 

--========== Initialization ============--

Initializing AT25SF161 SPI Flash @0x80000000...
SPI Flash clk configured to 6 MHz
Memspeed at 0x80000000 (Sequential, 4.0KiB)...
   Read speed: 105.9KiB/s
Memspeed at 0x80000000 (Random, 4.0KiB)...
   Read speed: 3.0KiB/s

[enjoy-digital]

Thanks @tcal-x, I indeed pushed litex-hub/litex-boards@5addd7f to test this but this was not correct and the main_ram was in fact not connected in the SoC. litex-hub/litex-boards@82653cf fixes it.

LiteX bare metal demo with upload over litex_term is now working on Fomu:

python3 -m litex_boards.targets.kosagi_fomu --cpu-variant=minimal --build --flash
litex_bare_metal_demo --build-path=build/kosagi_fomu_pvt
litex_term /dev/ttyACM0 --kernel=demo.bin --kernel-adr=0x10000

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

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

 BIOS built on Sep 30 2021 10:16:47
 BIOS CRC passed (481bc0ce)

 Migen git sha1: a5bc262
 LiteX git sha1: 47e4a1b4

--=============== SoC ==================--
CPU:		VexRiscv_Min @ 12MHz
BUS:		WISHBONE 32-bit @ 4GiB
CSR:		32-bit data
ROM:		32KiB
SRAM:		64KiB
FLASH:		2048KiB
MAIN-RAM:	64KiB 

--========== Initialization ============--

Initializing AT25SF161 SPI Flash @0x80000000...
SPI Flash clk configured to 6 MHz
Memspeed at 0x80000000 (Sequential, 4.0KiB)...
   Read speed: 105.9KiB/s
Memspeed at 0x80000000 (Random, 4.0KiB)...
   Read speed: 3.0KiB/s

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
[LXTERM] Received firmware download request from the device.
[LXTERM] Uploading demo.bin to 0x00010000 (8208 bytes)...
[LXTERM] Upload calibration... failed, switching to --safe mode.
[LXTERM] Upload complete (3.2KB/s).
[LXTERM] Booting the device.
[LXTERM] Done.
Executing booted program at 0x00010000

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

LiteX minimal demo app built Sep 30 2021 10:17:43

Available commands:
help               - Show this command
reboot             - Reboot CPU
led                - Led demo
donut              - Spinning Donut demo
helloc             - Hello C
litex-demo-app> 

[tcal-x]

Hi @enjoy-digital , I can reproduce this now. I was missing the --kernel-adr=0x10000 option, which I should have known about, since I needed to use it in my earlier Fomu/donut hacking.

[enjoy-digital]

Hi @tcal-x, thanks for the feedback.