U-boot spl for De0 Nano SoC Kit

ankurt · February 15, 2019, 8:28am

@RobertCNelson, it was purchased about 1 month ago

RobertCNelson · February 15, 2019, 4:34pm

@ankurt, I have another build for you to test:

 U-Boot SPL 2019.04-rc1-dirty (Feb 15 2019 - 10:27:47 -0600)
Trying to boot from MMC1


U-Boot 2019.04-rc1-dirty (Feb 15 2019 - 10:27:47 -0600)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
BOOT:  SD/MMC Internal Transceiver (3.0V)
DRAM:  1 GiB
MMC:   dwmmc0@ff704000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Model: Terasic DE-0(Atlas)
Net:   
Error: ethernet@ff702000 address not set.
eth-1: ethernet@ff702000
Hit any key to stop autoboot:

Please test:

wget -c https://github.com/eewiki/u-boot-testing/raw/master/socfpga_de0_nano_soc/u-boot-2019.04-rc1-with-spl.sfp
sudo dd if=./u-boot-2019.04-rc1-with-spl.sfp of=${DISK}1

If this version doesn’t work, you should contact the re-seller who sold you the board and request what changes they made vs the older Rev C’s.

Regards,

AlexeyG · May 15, 2019, 10:57am

Hello, Robert!
Forgive me, please, for such a huge delay. Here is actual project’s chronicle:

After your tips in January I became able to finally launch the new UBoot+Linux pair on a Terasic de0-nano dev-board. I got all the updates, installed and adjusted all the specific required software and so on.
Two weeks ago we received the custom hardware. It has almost the same schematics as DE0 board rev. C0 except the RAM size. The custom board has only 512 MBytes - e.g. twice less than DE0.
Obviously, U-Boot wouldn’t start on a new hardware - DDRAM calibration procedure on a early startup is not passing.
I started to dive into U-Boot sourcetree internals, trying to replace the existing terasic-related files with my own, generated right from the Intel QSys.
At some point in time the U-Boot started to pass the memory calibration, but began to fail at memory size checking.
Now it’s saying that I have only 8 Mbytes of RAM - not 512 as I’m expecting. Consequently it doesn’t let the Linux to boot up.

I’ve rechecked all the SDRAM-related settings in QSys - everything seems fine from that side. I guess I need to adjust/edit/replace something in u-boot source tree. Have you ever faced similar issues? Could you please share some of your priceless tips with me once again?

Thank you in advance, sir!

P.S: I should note that the “old” linux boots on a custom board with success - so it’s not a hardware related issue for sure

RobertCNelson · May 16, 2019, 10:58pm

@AlexeyG, Sorry, i’m not the expert on the SOCFPGA memory initialization in u-boot.

First double check your qts files:

There’s quiet a few magic numbers, so if you only changed the memory, try to limit your customizations.

Then, double check the memory value on the dts:

github.com

u-boot/u-boot/blob/master/arch/arm/dts/socfpga_cyclone5_de0_nano_soc.dts#L17-L21


	memory@0 {
		name = "memory";
		device_type = "memory";
		reg = <0x0 0x40000000>; /* 1GB */
	};

and finally, in this config:

github.com

u-boot/u-boot/blob/master/include/configs/socfpga_de0_nano_soc.h#L10-L11


/* Memory configurations */
#define PHYS_SDRAM_1_SIZE		0x40000000	/* 1GiB */

Finally, double check that none of these hard-coded offset’s end up above 512Mb:

github.com

u-boot/u-boot/blob/master/include/configs/socfpga_common.h

/* SPDX-License-Identifier: GPL-2.0+ */
/*
 * Copyright (C) 2012 Altera Corporation <www.altera.com>
 */
#ifndef __CONFIG_SOCFPGA_COMMON_H__
#define __CONFIG_SOCFPGA_COMMON_H__

/*
 * High level configuration
 */
#define CONFIG_CLOCKS

#define CONFIG_TIMESTAMP		/* Print image info with timestamp */

/*
 * Memory configurations
 */
#define PHYS_SDRAM_1			0x0
#define CONFIG_SYS_MALLOC_LEN		(64 * 1024 * 1024)
#define CONFIG_SYS_MEMTEST_START	PHYS_SDRAM_1

This file has been truncated. show original

Regards,

AK107bis · July 30, 2019, 3:30am

@RobertCNelson
Hi. I followed your tutorial on installing a ubuntu 18.04 LTS on the de0-nano-soc. The system works fine but the fpga part seems to not work correctly. Previously on debian system I would just use the dd command to flash the fpga and access the shared memory. However on the newly built ubuntu accessing the shared memory of fpga woule give a bus error. I am very confused, would you help?
Also in the /sys/class/fpga/fpga0/ there suppose to be a status that says user mode, but such status does not exist in the ubuntu system.

RobertCNelson · July 30, 2019, 3:24pm

@AK107bis, that’s odd as we just pull in Altera’s kernel:

any chance on your working system, can you grab the kernel version and it’s kernel config?

Regards,

mates · December 13, 2020, 4:54am

@RobertCNelson Thank you very much for the write-up. Still - after few years - it is a lifesaver. (Especially since many links in other tutorials from the “Latera Days” are broken).
I followed your original article to build bootable image with Ubuntu. Then I spent most of the rainy Saturday making the FPGA load. Switching between the Terasic Yocto and Debian. Works now
I have two questions though:
a) To make the FPGA load from the .rbf file at u-boot I made some (uneducated?) changes to the u-boot env variables - overwriting bootcmd=run loadfpga:

setenv loadfpga run loadfpgaimage\; run loadfpganow
setenv loadfpgaimage load mmc 0:2 ${fpgaloadaddr} ${fpgaimage}
setenv loadfpganow fpga load 0 ${fpgaloadaddr} ${filesize}
setenv fpgaimage /boot/de0_default.rbf
setenv fpgaloadaddr 0x2000000

Is this a “hack” or is it close to what is intended?

b) The Device Tree / Device Tree Overlay has different structure between the two OS versions.
On the Yocto Linux I was able to load the image from within the OS: dd if=DE0_NANO_SOC_Default_MV_PP16.rbf of=/dev/fpga0 bs=1M
What is the corresponding way of doing the same on the Debian built per your instructions?
Thanks - M.