Forum Discussion

pmarques's avatar
pmarques
Icon for New Contributor rankNew Contributor
1 month ago
Solved

Linux not booting - can't get kernel image

Hi,

I'm having trouble booting to Linux after migrating a project to the newest GSRD 2.0 (Quartus 25.3). 

I'm using an Agilex 5 FPGA E-Series 065B Premium Devkit. The project was based in the GSRD for Quartus 25.1 (QPDS25.1_REL_GSRD_PR) and had a few modifications, working in version 25.1 with the default device-tree.

I'm guessing this might be something related to differences in the device-tree between GRSD 2.0 and the previous version ? I've tried looking around but there's so many .dts and .dtsi files that I'm a bit lost.

Any advice appreciated.

Hps Boot
  • RolandoS_Altera's avatar
    RolandoS_Altera
    29 days ago

    Hi pmarques​ 

    From this thread, I see the the JTAG_USER_CODE is being set a 4 as it was set with that value in the example design used for the SD_CARD daughter card. I think that in the new design, this should be either 0 or undefined:

    You can find this value from Quartus in the Assignments >> Device >> Device and Pin Options >> General.

    Also you may find this in your .qsf: 

    set_global_assignment -name STRATIX_JTAG_USER_CODE 4

    So, you can either change this value to 0 or remove it. 

    There is some documentation about how this JTAG_USER_CODE was used in GSRD 1.0

    https://www.rocketboards.org/foswiki/Documentation/SingleImageBoot , Seems that something about this is still used in GSDR 2.0, but the board IDs changed in GSRD 2.0.

    In this file you will see how the kernel.itb is created. This includes 2 sets of images: board-0 and board-1. The USER_CODE=0 will use the board-0 configuration and USER_CODE=1 will use the board-1 configuration (it's the same but doesn't include the core.rbf in the kernel.itb. I am guessing that when this is not defined it will use also the board-0 configuration.

    https://github.com/altera-fpga/meta-altera-fpga/blob/main/meta-altera-bsp/recipes-kernel/linux/linux-socfpga-lts/fit_agilex5_kernel.its

     

     

     

17 Replies

  • Nirav_Altera's avatar
    Nirav_Altera
    Icon for New Contributor rankNew Contributor
    25 days ago

    pmarques​ 

    Just a note for GHRD/GSRD1.0 to 2.0 migration.

    GSRD2.0 Board_id is always defaulted to zero for all the GHRD2.0 designs.

    In GSRD2.0, Board_id 1 is only used for the debug purpose(not required to set in design), and it is optional, so run time user can change (from uboot -> setenv board_id 1) to base/vanilla device tree instead of using design specific device tree. 

    Thanks.

  • RolandoS_Altera's avatar
    RolandoS_Altera
    Icon for Occasional Contributor rankOccasional Contributor
    29 days ago

    Hi pmarques​ 

    From this thread, I see the the JTAG_USER_CODE is being set a 4 as it was set with that value in the example design used for the SD_CARD daughter card. I think that in the new design, this should be either 0 or undefined:

    You can find this value from Quartus in the Assignments >> Device >> Device and Pin Options >> General.

    Also you may find this in your .qsf: 

    set_global_assignment -name STRATIX_JTAG_USER_CODE 4

    So, you can either change this value to 0 or remove it. 

    There is some documentation about how this JTAG_USER_CODE was used in GSRD 1.0

    https://www.rocketboards.org/foswiki/Documentation/SingleImageBoot , Seems that something about this is still used in GSDR 2.0, but the board IDs changed in GSRD 2.0.

    In this file you will see how the kernel.itb is created. This includes 2 sets of images: board-0 and board-1. The USER_CODE=0 will use the board-0 configuration and USER_CODE=1 will use the board-1 configuration (it's the same but doesn't include the core.rbf in the kernel.itb. I am guessing that when this is not defined it will use also the board-0 configuration.

    https://github.com/altera-fpga/meta-altera-fpga/blob/main/meta-altera-bsp/recipes-kernel/linux/linux-socfpga-lts/fit_agilex5_kernel.its

     

     

     

    • pmarques's avatar
      pmarques
      Icon for New Contributor rankNew Contributor
      25 days ago

      Hi RolandoS_Altera​,

      Thanks very much for your input. This was indeed the problem!

      I tested with JTAG user code = FFFF FFFF and the board finally boots successfully now.

      Best regards,

      PM.

  • pmarques's avatar
    pmarques
    Icon for New Contributor rankNew Contributor
    1 month ago

    Hi again tehjingy_Altera​,

    I don't know if you had to opportunity to see my previous reply but in the meantime I've been doing some more testing.

    I just compiled a fresh default build as described in Rebuilding GSRD 2.0 Binaries. and compared the kernel.itb dump and the printenv output with my custom project.

    The kernel.itb dump is the same but the printenv output has some differences:

    • board_id=4 instead of 0;

    • Different bootargs;

    • bootfstype, fileaddr and filesize parameters are missing entirely.

    Do you know what could be causing this ? I'm attaching the printenv log files.

    Best regards,

    PM.

    • tehjingy_Altera's avatar
      tehjingy_Altera
      Icon for Regular Contributor rankRegular Contributor
      29 days ago

      Hi pmarques 

       

      Thanks for you patience!

      I managed to reproduce the issue here.

      It seems like the board_id was not updated to reflect the new kernel.itb configuration.

      Let me try out some changes on my end before I shared it to you.

    • tehjingy_Altera's avatar
      tehjingy_Altera
      Icon for Regular Contributor rankRegular Contributor
      1 month ago

      Hi pmarques 

       

      The modification you make should just remove the simulation files and would not cause the board to not being boot up.

      For now we could ignore the bootargs value in the env. This value will be overwritten by the boot_scripts (boot.scr <- part of the generated files)

       

      When you are booting the board with the generated kernel.itb and printenv where board_id =0 , is it able to be booted? With this combination it is supposed to be able to boot.

       

      Regards

      tehjingy

       

       

      • pmarques's avatar
        pmarques
        Icon for New Contributor rankNew Contributor
        1 month ago

        Hi  tehjingy_Altera​,

        Yes, the board boots successfully with a compiled default GSRD2.0 build. Printenv shows board_id=0.

        Best regards,

        PM.

  • tehjingy_Altera's avatar
    tehjingy_Altera
    Icon for Regular Contributor rankRegular Contributor
    1 month ago

    Hi 

     

    The binaries required to boot are the same between the GSRD and GSRD2.0.

     

     

    First, lets check your kernel.itb that is stored in your mmc0.

    In your host could you try out the command "  dumpimage -l  kernel.itb" and share the output?

     

    In the device uboot stage, could you try printenv to see the uboot environment of the board?

     

     

    Regards

    tehjingy