uboot spl + helloworld baremetal repeats 4 times when boot

Attach the screenshot​

Forget to mention it is Cyclone V SoCFPGA SX (5CSXFC6D6F31C6N).

>>>May I know what you meant by "concatenate spl+spl+spl + helloworld bin file"?

I means the steps in uboot Makefile, see bellow (cat xxx)

----------------------------------------------------

ifneq ($(CONFIG_ARCH_SOCFPGA),)

quiet_cmd_socboot = SOCBOOT $@

cmd_socboot = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp \

spl/u-boot-spl.sfp spl/u-boot-spl.sfp \

u-boot.img > $@ || rm -f $@

u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE

$(call if_changed,socboot)

endif

----------------------------------------------------

>>>Have you tried running a simple hello world example? Was there any issue with that?

I tried EDS/19.1/embedded/examples/software/Altera-SoCFPGA-HelloWorld-Baremetal-GNU.

It can run from DS-5/Eclips, and print "Hello Tim"

But it is not what I want. I want to run from an SD card and print the message on UART. The App runs in DS-5/Eclips and print on a faked App console (not the UART terminal)

>>>It looks like you boot logs reports an unsupported OS image, which I suspect the this has something to do with the image itself maybe it is corrupted or not supported, I am unsure.

Unsupported OS is okay, because my image is not Uboot standard image and not a Linux OS image too.

The message in may helloworld main can be printed through UART which means my image is loaded correctly and the main/print is called correctly also

Now my problem is that it looks the system gets reset, and repeats 4 times. After a power cycle, I get 4 "hello world" message.

"concatenate spl+spl+spl + helloworld bin file" is actually "concatenate spl+spl+spl + spl + helloworld bin file" (4 SPL)

It could be the SPL issue which has WatchDog enabled.

I use the spl from http://www.altera.com/literature/an/cv_boot_guide.zip. It works well.

Now the question is how to disable the WatchDog in Uboot SPL.

The document on the Web is using EDS GUI tool to toggle the option, and the latest document https://rocketboards.org/foswiki/Documentation/BuildingBootloader doesn't mention anything about the WatchDog:

============================================

Boot ROM

The function of the boot ROM code is to determine the boot source, initialize the HPS after a reset, and

jump to the preloader. In the case of indirect execution, the boot ROM code loads the preloader image from

the flash memory to on-chip RAM. The boot ROM performs the following actions to initialize the HPS:

• Enable instruction cache, branch predictor, floating point unit, NEON vector unit

• Sets up the level 4 (l4) watchdog 0 timer

L4 Watchdog 0 Timer

The L4 watchdog 0 timer is reserved for boot ROM use. While booting, if a watchdog reset happens before

software control passes to the preloader, boot ROM code attempts to load the last valid preloader image,

identified by the initswlastld register in the romcodegrp group in the system manager.

If the watchdog reset happens after the preloader has started executing but before the preloader writes a

valid value to initswstate register, the boot ROM increments initswlastld and attempts to load that

image. If the watchdog reset happens after the preloader writes a valid value to initswstate register, boot

ROM code attempts to load the image indicated by initswlastld register.

Typical Preloader Boot Flow

This section describes a typical software flow from the preloader entry point until the software passes control

to the next stage boot software

Low-level initialization steps include reconfiguring or disabling the L4 watchdog 0 timer, invalidating the

instruction cache and branch predictor, remapping the on-chip RAM to the lowest memory region, and

setting up the data area.

Upon entering the preloader, the L4 watchdog 0 timer is active. The preloader can either disable, reconfigure,

or leave the watchdog timer unchanged. Once enabled after reset, the watchdog timer cannot be disabled,

only paused.

The instruction cache and branch predictor, which were previously enabled by the boot ROM code, need

to be invalidated.

Hi

From https://rocketboards.org/foswiki/Documentation/BuildingBootloader?elq_cid=2794385&erpm_id=5358823

===========================

Introduction

Starting with SoC EDS Pro version 19.3 and SoC EDS Standard version 19.1, the following changes were made:

• The bootloader source code was removed from SoC EDS. Instead, the user needs to clone the git trees from https://github.com/altera-opensource/u-boot-socfpga.
• The same U-Boot branch (socfpga_v2019.04) is used for all SoC FPGA devices: Cyclone V SoC, Arria V SoC, Arria 10 SoC, Stratix 10 SoC, Agilex.
• The bootloader generator (bsp-editor) still needs to be used for Cyclone V SoC, Arria V SoC and Arria 10 SoC, but:
  • Does not support custom user settings anymore. Instead all custom user settings must be done directly in U-Boot (device tree, configuration and source code).
  • Does not create a makefile which builds the bootloader. Instead the user is notified about this page, which contains instructions on how to build the bootloader.

..............................

Old Flow

The U-Boot could be built in previous versions of SoC EDS using the following flow:

Key aspects to note:

• Most user options (like boot source, enabling ECC scrubbing, watchdog etc) were set through the bsp-editor GUI or the command line equivalents.
• U-Boot source code was part of SoC EDS
• The makefile created by the bsp-editor allowed building the bootloader with a single 'make' command

New Flow

Starting with this release of SoC EDS, the build flow is different, as depicted below:

Key differences are:

• All the user options defined in the bsp-editor are not applicable anymore. They can still be set in the interface, but they have no effect
• All custom user settings must be done directly in U-Boot (device tree, configuration and source code).
• The makefile generated by bsp-editor does not build U-Boot, instead it instructs the user to go to this page
• The U-boot source code needs to be retrieved by the user from github
• A tool called qts_filter (part of U-Boot) needs to be called to convert the handoff files and bsp-editor generated files to the format required by the new U-Boot version.

===========================

The Old flow uses bsp-editor to set watchdog, for the new flow, I am not clear how to set watch dog, and don't see a document about it yet.

Hi,

Yes, for the new flow is mentioned some advanced features are not documented yet.

We recommend that you use the old flow for now to set the watchdog.

I will check with our internal team regarding the advance feature if they can be set.

Regards.