I'm running Altera's Cyclone5 SOCFPGA provided by terasic development kit. Running Linux 4.19 with U-Boot 2017.11.
In U-Boot; I'm reading reset_manager's status register to know the boot source/reason. On warm reboot; I read a valid value (SWWARM) but for a PowerUp (hard power cycle), I read a value 0x0.
What is it that I am doing wrong here?
Thanks for your response to my question. But how does that specific section answers my question? It talks about Boot ROM and preloader. I need to know/read 'Reset Manager's Status register' in U-Boot (secondary bootloader).
In U-Boot, I have access to Reset Manager (0xFFD05000). But when I read its status register (stat @ offset 0x0); I read a value of 0x0 in case of cold boot. which is not true (for a warm boot, I read a correct non-zero value). This is my problem. Why Reset Manger's 'stat' register doesn't provide required information upon cold boot?
Are you able to bring up the board? Because on a cold reset, the HPS boot process starts when CPU0 is released from reset (for example, on a power up) and executes code in the internal boot ROM at the reset exception address, 0x00000000.
Are you running into any other issue while executing your booting process?
Yes, my board (Arrow SocKit for Cyclone5) comes up fully (U-Boot to Linux kernel to filesystem). It works fine. Only now, I'm adding a mechanism in U-Boot to know the source of boot.
- Upon warm reboot (either from main OS, or from U-boot); I read reset_manager_base->status and it returns 0x00000400 which indicates software warm reboot.
- Upon cold reboot (either triggered by software in main OS, or via power plug in); I read reset_manager_base->status and it returns 0x0.
Why cold bit is not set in reset manager's status register? Do I need to employ a different method to read reset manager's status register upon cold boots?
No issues with boot process itself. Only issue I'm incurring is reading status register of reset manager upon a cold boot.
'reset_manager_base' that I mentioned above is simply a pointer to reset manager's base address defined in 'arch/arm/mach-socfpga/reset_manager_gen5.c':
static const struct socfpga_reset_manager *reset_manager_base =
and in '/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h': #define SOCFPGA_RSTMGR_ADDRESS 0xffd05000
Thanks again for looking into it. Hope you find a solution for it!
Great to hear that your booting is working fine.
Well, cold reset it is on board level itself thus, on cold reset, everything is from point zero. Following your returned address values 0x00000000, this is the address that is supposed to be read as mentioned in my previous reply for cold reset.
Well, first of all thank you! Let me ask this; are you familiar with SOCFPGA and 'Reset Manager' defined in CycloneV and Arria10? If yes, are you familiar with Reset Manager's status register bits? If yes, please explain under what cases:
- bit0 (porvoltrst) will be set?
- bit1 (nporpinrst) will be set?
- bit4 (swcoldrst) will be set?
The purpose of these bits is to tell the source of power up. I don't understand your logic 'everything is from point zero'. Of course it is, but status register (of Reset Manager) is there to tell me what caused me to start from point zero. Who woke me (the processor) up? Was it the power-on reset? or the voltage caused me (the processor) to reset? or was it the software who wanted me (the processor) to perform a cold reset?
BTW; I have Arria10 based board which tells me the source of power up upon cold boots (reading the same status register from Reset Manager)!
My apology for the last reply.
For cold reset, the last source of the cold reset can be identify:
"After a cold reset is complete, all bits are reset to their reset value except for the bit(s) that indicate the source of the cold reset. If multiple cold reset requests overlap with each other, the source de-asserts the request last will be logged."
Here are the links for you reference for Cyclone V regarding the Reset Manager Module Address Map:
Software wrote CTRL.SWCOLDRSTREQ to 1 and triggered a cold reset
FPGA entered CONFIG_IO mode and a triggered a cold reset
FPGA core triggered a cold reset (f2h_cold_rst_req_n = 1)
nPOR pin triggered a cold reset (por_pin_req = 1)
Here are the stats field regarding the bits, you can scroll down to the bottom of the page for the descriptions of the bits: