Follow https://rocketboards.org/foswiki/Documentation/BuildingBootloader, I can build spl and uboot. Spl+uboot can flash into SD card and boot to uboot console. It works fine.
Now I want to change "spl+uboot" to "spl + helloworld baremetal example" which is in
I follow the steps of uboot to mkimage and concatenate spl+spl+spl + helloworld bin file. After flash, it can boot to SPL and helloworld main should be called. However it looks spl+helloworld repeats 4 times and then stops.
I attach a screenshop here. I added some debug message in SPL code which can be ignored
My real purpose is to bring up SPL+FreeRtos Cyclone Demo, but I got the same problem, so I change to try the simple HelloWorld example which can help to illustrate the issue.
May I know what you meant by "concatenate spl+spl+spl + helloworld bin file"?
Have you tried running a simple hello world example? Was there any issue with that?
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.
Have you try to debug in DS-5 for anybclue?
>>>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)
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
>>>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.
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:
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,
The instruction cache and branch predictor, which were previously enabled by the boot ROM code, need
to be invalidated.
I apologize I thought I already replied.
In the reply; based on the generating the bootloader in the rocketboards link, it only demonstrates on how to generate the bootloader to boot up using SD card.
To use more advanced feature, disabling watchdog etc, you may use the bsp-editor in your 19.1 SoC EDS. Have you tried this before? Here are the steps to guide you:
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.
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
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.
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.