Forum Discussion
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.
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.
17 Replies
- Nirav_Altera
New Contributor
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.
- tehjingy_Altera
Regular Contributor
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
- pmarques
New Contributor
Hi Tehjingy,
Apologies for the delay, please see the requested files in attachment.
Best regards,
PM.
- tehjingy_Altera
Regular Contributor
Hi pmarques
It seems like the kernel.itb that you generated is incorrect.
As you see the kernel.itb do not consist a configuration3 ( board 4)
e.g Pre-built Kernel.itb

That is the configuration for the uboot environment.
Could you try booting the board with the pre-built sdcard image?
Regards
tehjingy
- pmarques
New Contributor
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
Regular Contributor
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
New Contributor
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
Regular Contributor
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.
- RolandoS_Altera
Occasional Contributor
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.
- pmarques
New Contributor
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.
- SueC_Altera
Contributor
Thanks for letting us know that solved the problem, pmarques !