I received a Pioneer v1.3 bare board a week ago. I have the MCU and RISC-V UARTs hooked up and get output on the MCU. There’s nothing on RISC-V UART with either of the Fedora 38 images. I’ve tried several different microSD cards, and several different DIMMs (including one that others claim to see working). I’ve also got one of the “official” DDR sticks on order now, so I will try that when it arrives, but I do plan to stop constantly buying different DDR memories just to get the same no output
Meanwhile, I would like to triage the problem further. I see there’s a JTAG header, so I would like to hook that up, and also test the SPI content to see that it’s not corrupt. Of course, there is no documentation on this. Are there any pointers to openocd scripts that I can use to talk to the various things in that JTAG chain? Any docs on what is in that chain, etc.? I would prefer not to have to guess
In my experience, I got nothing on the RISCV serial port until I found a DDR4 DIMM that worked. You need that first.
Also, even with a DIMM that worked, I have not gotten more than 1 DIMM configuration to work. Only configs that boot are a single DIMM in the slot closest to the PCI slot.
I recommend you confirm you have an Registered ECC DIMM with 1 or 2 Ranks of x8 memory chips. There may be additional requirements (speed, CAS latency (CL), etc…)
There have been at least one report of a x4 memory DIMM working, but my 1Rx4 DIMM didn’t work.
So indeed it is the DDR4 modules I’ve been using that’s the problem. A Micron 32GB 2Rx4 doesn’t work among several I’ve tried. A Samsung 8GB stick in a 1Rx8 config does finally result in the DDR coming up. It’s unfortunate that they don’t output anything prior to memory training (I assume they’re running from cache in an OCM config while training, it’s not rocket science to output something on the UART). Anyway, at this point I am able to load the LinuxBoot[0] and get the Fedora 38 image booting.
[0] This should be UEFI. LinuxBoot is a poor choice for those moving from existing ecosystems and will only make the process of building distros more complex than it needs to be.
from what I gather from the TRM, the memory controller being configured by the System Co-Processor might be the reason there is nothing written to UART in that stage yet, maybe it’s only the actual RISC-V cores writing to UART.
There is a strapping pin to enable “SCP Console” (BOOT_SEL2), maybe that enables UART messages in that early stage? Sadly no clue how if that strapping pin is exposed somewhere we can access it … or if it is even interpreted by the software they run (which should be the fip.bin at this stage, from what I gather).
Indeed. The lack of documentation and labeling on the board is really frustrating at answering these questions.
But btw, what some designs in industry do is mux these kinds of UARTs so that some other agent (e.g. the management micro) can squirt out proof-of-life prior to the main cores being up. That kind of design would allow them to output a banner and an error about training to the main UART and is how they /should/ have designed this SoC.
As long as we are bitching about what they /haven’t/ done, I’ll chime in that all three of my boards have the SAME MAC address on boot.
There have been commits to the boot code that would read a config file with a serialized MAC address for the NIC’s, but access to the SPI to create the config file or confirmation that such settings work hasn’t been confirmed.
since I’ve not seen this in the forums here yet, this seems a very useful third serial console - apparently even telling you about memory initialization!
Hahahahaha. This is excellent. It provides exactly the kind of output you would want to debug the kinds of issues we have all been having, so /of course/ it’s not documented at all? Why would you document it? That would make debugging possible, and we wouldn’t want that to be easy for anyone, right?
