DE10-nano; Booting from SD-Card fails

I just got similar issue widh DE-10 after I loaded with new fpga image. The DE-10 stuck at loading kernel.

U-Boot 2013.01.01 (Jun 13 2017 - 10:16:44)

cpu : altera socfpga platform

board : altera socfpga cyclone v board

i2c: ready

dram: 1 gib

mmc: altera dwmmc: 0

in: serial

out: serial

err: serial

skipped ethaddr assignment due to invalid emac address in eeprom

net: mii0

warning: failed to set mac address

hit any key to stop autoboot: 0

reading u-boot.scr

232 bytes read in 4 ms (56.6 kib/s)

## executing script at 02000000

reading soc_system.rbf

7007204 bytes read in 386 ms (17.3 mib/s)

altera_load: failed with error code -4

## starting application at 0x3ff795a4 ...

## application terminated, rc = 0x0

reading zimage

5172040 bytes read in 310 ms (15.9 mib/s)

reading soc_system.dtb

26527 bytes read in 8 ms (3.2 mib/s)

## flattened device tree blob at 00000100

booting using the fdt blob at 0x00000100

loading device tree to 03ff6000, end 03fff79e ... ok

starting kernel ...

I hooked a Avalon-slave device on the lwt mm-bridge in the FPGA. I figured that I need to updated the device tree. So I did that, now the system loaded the kernel. But it stuck again after the kernel loaded mmc driver. I did similar changes in the FPGA before, and did not have any problem. The only difference is that the memory map address was different. The slave address is at 0x0, which I think it should be a different address. I have not tried my hypothesis yet. I started a google search, and found your thread :-).

Did you try to load a new device tree? Also how do you enable the debug script?

thx

--- Quote Start ---

Hello,

I switched from using the DE0-nano Development Board (Rocketboard) to the DE10-nano Development Board (Rocketboard) for a baremetal-Application. Both use a Cyclone V SoC FPGA. The FPGA is configured trough the onboard EPCS. The MPU main-routine is supposed to be loaded by an external memory card. On that card are two different partitions. One in which I programmed the preloader (A2) and one FAT-partition which hosts my image-file. This image-file includes the main-application which is loaded by the preloader into the MPU.

I successfully designed my FPGA-Design in Qsys and programmed the FPGA. With the generated handoff-files, I build the preloader with the bsp-editor.

When I load the ELF-file (“u-boot-spl”) of the compiled preloader with the DS-5 debugger, the MPU and the FPGA are running correctly. Same applies, when I load just the ELF-file via the debugger and put the HPS-image-file on the FAT-partition of the SD-Card. Thus, both the preloader-ELF-file and the HPS-image-file seem to be flawless.

To get the system working standalone, I need to boot the preloader from the SD-Card. So I programmed the SD-card with the corresponding executable binary of the compiled preloader-files (“preloader-mkpimage.bin”). When I power up the board, the preloader successfully configures the HPS. This can be seen by establishing the UART-connection with Putty. However, this time the main-routine gets stuck. So it seems like the preloader compiled ELF-file works but the corresponding bin-file does not.

When I boot the preloader from the SD-Card and load the axf-file manually (with the help of a debugger script) into the SDRAM I can see that the main-routine gets stuck at the source line “alt_int_handler_abort” of the assembly file “alt_interrupt_armcc.s”. Latter file is part of the HWLIB provided by Altera.

Since the boot.img of the HPS is working well, I think the problem is the preloader which starts from the SD-card (preloader-mkpimage.bin). With the debugger-command:

“restore preloader-mkpimage.bin binary 0x0”

I tried to directly load the “preloader-mkpimag.bin” into the the Boot ROM in order to see whether this file is somehow corrupted. Unfortunately this does not work. I get the error “Unable to restore image”.

My Questions:

• Does anybody encounter similar problems when using the DE10-nano-board? Previously I worked with the DE0-nano board which just worked fine.

• Does anybody know what the “alt_int_handler_abort” line does? Why gets the main-routine stuck here? Under what conditions do I end up here?

• Is it possible to load directly the “preloader-mkimage.bin” into the Boot ROM?

The setup:

• DE10-nano development board (Cyclone V SoC FPGA)

• Windows 7 SP1

• Quatus Prime 16.1

• Eclipse with DS-5 v5.25.0

Any help would be appreciated!

Best regards

Benny

--- Quote End ---

Hello,

Since I do not want to run Linux on the DE10-nano board I do not think I can help you with your problems. In baremetal-application the FPGA-design is described by header-files, not a device tree.

For how to run DS-5 debugger-scripts, I can recommend the "Bare Metal User Guide" from Altera (https://www.altera.com/documentation/lro1424280108409.html).

Hope this is any help for you,

best regards

ISE

--- Quote Start ---

I just got similar issue widh DE-10 after I loaded with new fpga image. The DE-10 stuck at loading kernel.

U-Boot 2013.01.01 (Jun 13 2017 - 10:16:44)

cpu : altera socfpga platform

board : altera socfpga cyclone v board

i2c: ready

dram: 1 gib

mmc: altera dwmmc: 0

in: serial

out: serial

err: serial

skipped ethaddr assignment due to invalid emac address in eeprom

net: mii0

warning: failed to set mac address

hit any key to stop autoboot: 0

reading u-boot.scr

232 bytes read in 4 ms (56.6 kib/s)

## executing script at 02000000

reading soc_system.rbf

7007204 bytes read in 386 ms (17.3 mib/s)

altera_load: failed with error code -4

## starting application at 0x3ff795a4 ...

## application terminated, rc = 0x0

reading zimage

5172040 bytes read in 310 ms (15.9 mib/s)

reading soc_system.dtb

26527 bytes read in 8 ms (3.2 mib/s)

## flattened device tree blob at 00000100

booting using the fdt blob at 0x00000100

loading device tree to 03ff6000, end 03fff79e ... ok

starting kernel ...

I hooked a Avalon-slave device on the lwt mm-bridge in the FPGA. I figured that I need to updated the device tree. So I did that, now the system loaded the kernel. But it stuck again after the kernel loaded mmc driver. I did similar changes in the FPGA before, and did not have any problem. The only difference is that the memory map address was different. The slave address is at 0x0, which I think it should be a different address. I have not tried my hypothesis yet. I started a google search, and found your thread :-).

Did you try to load a new device tree? Also how do you enable the debug script?

thx

--- Quote End ---