• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 120 subscribers
  • Views 3919 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Error: Could Not Calibrate SDARM

F.y

Hi,

I am trying to run a but project on Arria 10 but I received a different error in Commands and also in Terminal.

I built a Arria 10 Soc boot from QSPI based on https://rocketboards.org/ and based on this page I tried to debug with Arm DS-5 but during a my .ds file running I received  :

"+restore u-boot-socfpga/spl/u-boot-spl-dtb.bin binary 0xFFE00000
Restoring Binary file F:\repository\yazdandoust\sc50cont\u-boot.qspi\a10_soc_devkit_ghrd\software\bootloader\u-boot-socfpga\spl\u-boot-spl-dtb.bin into memory
Restoring section S:0x00000000 to S:0x00012A00 into memory S:0xFFE00000 to S:0xFFE12A00
+symbol-file u-boot-socfpga/spl/u-boot-spl
+set $PC = $ENTRYPOINT
+thbreak *0x0
Hardware breakpoint 1 at S:0x00000000
+continue
+wait 20s
Execution stopped in SVC mode at breakpoint 1: S:0x00000000
S:0x00000000 LDR pc,[pc,#24] ; [0x20] = 0xB8
Deleted temporary breakpoint: 1
+restore u-boot-socfpga/spl/u-boot-spl-dtb.bin binary 0xFFE00000
Restoring Binary file F:\repository\yazdandoust\sc50cont\u-boot.qspi\a10_soc_devkit_ghrd\software\bootloader\u-boot-socfpga\spl\u-boot-spl-dtb.bin into memory
Restoring section S:0x00000000 to S:0x00012A00 into memory S:0xFFE00000 to S:0xFFE12A00
+symbol-file u-boot-socfpga/spl/u-boot-spl
+set $PC = $ENTRYPOINT
+thbreak spl_boot_device
Hardware breakpoint 2 at S:0xFFE01060
on file spl_a10.c, line 77
on file spl_a10.c, line 78
on file spl_a10.c, line 78
+continue
+wait 60s
Execution stopped in SVC mode at breakpoint 2: S:0xFFE01060
In spl_a10.c
S:0xFFE01060 77,1 {
Deleted temporary breakpoint: 2
+delete
All user breakpoints deleted
+loadfile u-boot-socfpga/u-boot
Target Message: Memory access caused precise abort.
Debug Precise Abort Registers : DFSR = 0x00000808, DFAR = 0x01000040
ERROR(CMD16-TAD59-NAL18):
# in ...........u-boot.qspi\a10_soc_devkit_ghrd\software\preloader.ds:32 while executing: loadfile u-boot-socfpga/u-boot
! Failed to load "u-boot"
! Download of 311.088 bytes to address S:0x01000040 failed while writing block of 4.096 bytes to address S:0x01000040
! Bus error on memory operation.
ERROR(CMD656): The script ..........u-boot.qspi\a10_soc_devkit_ghrd\software\preloader.ds failed to complete due to an error during execution of the script "

and also in Terminal the other error is printed :

"

U-Boot SPL 2021.07-16360-gee63370553-dirty (Jan 21 2022 - 08:09:27 +0100)

U-Boot SPL 2021.07-16360-gee63370553-dirty (Jan 21 2022 - 08:09:27 +0100)
Error: Could Not Calibrate SDRAM
DDRCAL: Failed
WDT: Started with servicing (10s timeout)"

I already read most of answers in forums but most of them is for the last version of Quartus which is generate a preloader with BSP editor but in my case I built all with script. 

Is there any solution in this case? 

Parents
  • +1 Arm Employee Badge in reply to F.y

    Thanks for confirming the area of memory at S:0x01000040 is not writable.  That explains why the Debugger is unable to download U-Boot to that address.

    The differences you see between the behaviour of the Cortex-A9 FVP model and the Arria 10 hardware are to be expected.  The FVP is a model of an example Cortex-A9-based system.  It accurately models the behaviour of the Cortex-A9 processor core, but its memory system and peripherals are not the same as the ones on the Arria 10.

    I'm afraid that you will have to investigate why that area of memory is not writable on the Arria 10 yourself.  If the MMU is enabled, try using the Debugger's MMU/MPU view to see which areas are accessible.  You could also try temporarily turning the MMU off.  If that doesn't work, then try looking elsewhere for information about how the RAM/ROM/SDRAM remapping is controlled.

    Hope this helps

    Stephen

Reply
  • +1 Arm Employee Badge in reply to F.y

    Thanks for confirming the area of memory at S:0x01000040 is not writable.  That explains why the Debugger is unable to download U-Boot to that address.

    The differences you see between the behaviour of the Cortex-A9 FVP model and the Arria 10 hardware are to be expected.  The FVP is a model of an example Cortex-A9-based system.  It accurately models the behaviour of the Cortex-A9 processor core, but its memory system and peripherals are not the same as the ones on the Arria 10.

    I'm afraid that you will have to investigate why that area of memory is not writable on the Arria 10 yourself.  If the MMU is enabled, try using the Debugger's MMU/MPU view to see which areas are accessible.  You could also try temporarily turning the MMU off.  If that doesn't work, then try looking elsewhere for information about how the RAM/ROM/SDRAM remapping is controlled.

    Hope this helps

    Stephen

Children