Unable to replicate Analogue Pocket about litex-boards HOT 6 CLOSED

This string sL5DdSMmkekro is part of the normal BIOS boot, you should have seen the last bit of the boot messages if you waited a few more seconds.
I also replied to your message on discord.

from litex-boards.

Hi @agg23,

if you have the developer cart bridge, as discussed on Discord, I would recommend using it as UART to start with:

• Make sure that the serial pins defined here: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/analog_pocket.py#L18-L23 match the ones of the dev cart bridge and modify if not.
• Build and load with design with ./analog_pocket.py --build --load.
• Open LiteX Term: litex_term /dev/ttyUSBX

from litex-boards.

I have been using the dev cartridge UART, in the following janky way:

# Platform

# Cart
("cart",  0,
    # Bank 0 only has 4 pins enabled, so subtract 4 from the index
    # Subsignal("tran_bank0",        Pins("AB7 AA8 AB8 AA9")),
    Subsignal("tran_bank0_dir",    Pins("AB6")),
    Subsignal("tran_bank1",        Pins("AB13 AA12 AB12 Y11 AB11 Y10 AB10 AA10")),
    Subsignal("tran_bank1_dir",    Pins("AA13")),
    Subsignal("tran_bank2",        Pins("AB20 AA19 AA18 AB18 AA17 AB17 AA15 AB15")),
    Subsignal("tran_bank2_dir",    Pins("AA14")),
    Subsignal("tran_bank3",        Pins("W22 W21 Y22 Y21 AA22 AB22 AB21 AA20")),
    Subsignal("tran_bank3_dir",    Pins("V21")),
    Subsignal("tran_pin30",        Pins("L8"),  IOStandard("1.8 V")),
    Subsignal("tran_pin30_dir",    Pins("AB5")),
    Subsignal("pin30_pwroff_reset",Pins("L17"), IOStandard("1.8 V")),
    # Subsignal("tran_pin31",        Pins("K9"),  IOStandard("1.8 V")),
    Subsignal("tran_pin31_dir",    Pins("U22")),
    IOStandard("3.3-V LVCMOS"),
),

("serial", 0,
    Subsignal("tx", Pins("AB8"), IOStandard("3.3-V LVCMOS")),
    Subsignal("rx", Pins("K9"), IOStandard("1.8 V"))
),

# Target
cart = platform.request("cart")
self.comb += cart.tran_bank0_dir.eq(1)

self.comb += cart.tran_pin31_dir.eq(0)

I imagine there's probably a way to allow definitions with overlapping pins (this is needed as the UART functionality automagically pulls a pin group with a certain name and the tx and rx nets), but I haven't looked into it very much.

In any case, I get the exact same output from UART as over the JTAG bridge; it prints the magic string, but nothing else. Writing output in the same manner as the magic string, I have determined that the printf calls are executing "successfully", as they're properly returning the number of characters written.

from litex-boards.

@agg23: OK, that's strange. Would you mind testing this bitstream (with JTAG-UART) to see if it behaves similarly? (Just want to rule out an RISC-V GCC eventual issue): analog_pocket_2023_10_02.zip

Also just for info, I was testing this with the Pong FPGA core previously loaded/running. Not sure it should impact behavior, but could still be worth testing if still not working.

from litex-boards.

@agg23: OK, that's strange. Would you mind testing this bitstream (with JTAG-UART) to see if it behaves similarly? (Just want to rule out an RISC-V GCC eventual issue): analog_pocket_2023_10_02.zip

That is bizarre. Your build works correctly. It prints the BIOS startup message, and responds to my commands.

Installed gcc RISC-V is:

binutils-riscv64-unknown-elf/jammy,now 2.35.1-0ubuntu1 amd64 [installed,automatic]
gcc-riscv64-unknown-elf/jammy,now 10.2.0-0ubuntu1 amd64 [installed]

I don't remember if it was installed this way, but this appears to be the same gcc package as litex_setup.py installs.

from litex-boards.

I don't know if this was my fault or not, but it seems like that LiteX build environment was just messed up somehow. I literally had just created it, as it was created for the purpose of testing this target, and I don't think I did anything unusual, just install via:

litex_setup.py --init --install --config=standard

In any case, my second environment, which contained a scoped set of the LiteX packages as Git submodules, seems to be producing working builds.

Since this is highly likely not a symptom of the target, I will close this issue, though there may be an issue hiding here with LiteX installs.

from litex-boards.