Mity CPU Platforms » MitySOM-A5

Hi Eleonora,

The test/Kconfig error most likely means the U-Boot source tree under software/bootloader/u-boot-socfpga is incomplete. The first time you build, the project Makefile clones U-Boot from our git server into that directory and it only does the clone when the directory doesn't exist yet. If that initial clone was interrupted, or the project folder was copied from another machine/location and some files didn't make the trip (this is common when a Linux tree passes through a Windows filesystem), the directory is present but incomplete, so make skips the clone and fails on the first missing file. test/Kconfig is one of the first files U-Boot's top-level Kconfig pulls in, which is why it's the one that surfaces.

You're right that copying test/ from the 25.3 project isn't a real fix, and if test/ is missing, other files are likely missing too. The clean fix is to let the Makefile re-clone a fresh tree:

1. Delete software/bootloader/u-boot-socfpga entirely (or move this to another location temporarily as a backup)
2. Delete the bootloader stamp file if present: stamp/25.3.1/bootloader.stamp.
3. Re-run make jic. The Makefile will re-clone U-Boot (this needs network access to git.criticallink.com) and rebuild.

On the second question, make generate_from_tcl isn't a supported flow in the externally released projects, that target is part of our internal project-generation infrastructure. The releases we provide are pre-generated per SOM/SBC model, so the expected workflow is to navigate to the project folder that was pre-generated for the model you want (the same way your mitysbc-a5-ref delivery has a folder per model, e.g. A5ED-B96-C7F-RC-SBC-X) and build from there.

Therefore, running make AGILEX5_MODEL=A5ED-B64-144-SRI generate_from_tcl is the equivalent of obtaining the design from here: mitysom-a5e-ref/A5ED-B64-144-SRI/mitysom-a5e-ref-base

- Mike

Hello Mike,
Deleting the u-boot-socfpga and bootloade.stamp and running make jic did give me test/ folder and produced *.jic file. Unfortunately, when I tried to program through JTAG, using:
quartus_pgm -m jtag -o "piv;output_files/a5e.hps.jic@2"
it fails. I get message that the FPGA ID is different than the expected ID. The project has the FPGA set as A5ED065BB32AI4S. I have DK# 80-0011854 Model# A5ED-BB64-144-SRI. Do I have the correct FPGA setting?

Thank you,
Elronora Haralanova

Hi Eleonora,

Yes A5ED065BB32AI4S is the correct part number for A5ED-B64-144-SRI .

Please confirm the output JIC was compiled for the correct device by running the following:

Note - The second string is the full string. I show a different model number for my example

$ quartus_pfg -i output_files/a5e.hps.jic | grep "Device" 
Device name: A5ED065AB32A
Device name: A5ED065AB32AE3V

For Windows you'd use:
quartus_pfg.exe -i output_files/a5e.hps.jic | findstr "Device" 

To confirm the model number on the unit over JTAG run the following:

Note - Once again I have a different model number attached

$ jtagconfig
1) USB-BlasterII [7-1.1.1]
  4BA06477   ARM_CORESIGHT_SOC_600
  0364F0DD   A5E(C065BB32AR0|D065BB32AR0)

Windows should just be jtagconfig.exe

The part number of my attached unit is therefore A5ED065BB32AR0

- Mike

Correction to my last statement, jtagconfig doesn't list the temperature / speed grade (because it is not a gating factor to flash the device).

So jtagconfig reported A5ED065BB32AR0 while my device is really A5ED065BB32AE6SR0

I get the correct device

quartus_pfg -i output_files/a5e.hps.jic | grep "Device"
Device name: A5ED065BB32A
Device name: A5ED065BB32AI4S

Is it possible to be a SD card mismatch? A coworker of mine might have used a mitySBC FPGA when making the bootloader.

Thank you,
Eleonora

No the SD card is irrelevant at this stage. JTAG talks directly to the SoC device.

Have you confirmed the device you are trying to flash also has the matching ID via jtagconfig?

If you're still stuck, can you post the entire output of quartus_pgm -m jtag -o "piv;output_files/a5e.hps.jic@2"

It actually came back with different FPGA - the one that you have

jtagconfig
1) USB-BlasterII [USB-1]
4BA06477 ARM_CORESIGHT_SOC_600
0364F0DD A5E

I'll change the devise and start over.
I'll let you know how it goes. Thank you.

Eleonora,

Can you read the label / sticker that is on the SOM module? I believe the device you actually have installed into the development kit is the A5ED-B64-144-SRC-X and not A5ED-B64-144-SRI. I think this is where the confusion is coming from. The -X is R0 silicon, which is why the FPGA ID is not matching like you would expect.

So your SBC board and SOM board are the exact same part, except the SOM is speed grade 4 versus speed grade 6 on the SBC.

- Mike

Yes,
The actual label on the SOM is A5ED-B64-144-SRC-X, but the box says A5ED-B64-144-SRI-X
I checked the SBC also using jtagconfig and it came back as
1) USB-BlasterII [USB-1]
4BA06477 ARM_CORESIGHT_SOC_600
0364F0DD A5E

The example that I have for PCIE RP doesn't like the change of the part/speed grade - the HPS_subsys emif gives errors because the DDR clock is set to 1066 instead of 800 MHz. The pcie_rp_subsys also, but I haven't gotten into it yet.

I believe the PCIe RP IP needs to be regenerated / re-added if you switch between production silicon or R0 silicon so that may be your issue with the PCIe IP.

The speed grade 4 SOM is capable of 1066 MHz DDR while the speed grade 6 SBC is capable of 800 MHz DDR.

Based on your filenames, I suspect you are looking at the root port designs we had posted / shared. You can see the ones for the A5ED-B64-144-SRC-X posted here as a reference if this is helpful: A5ED-B64-144-SRC-X

If you are still stuck and want to share your project with us to take a look feel free.

Good morning,
I have readded the PCIe RP IP, but it I still can't regenerate/update the a5e because the tool complaints about the hps emif.

Thank you,
Eleonora