[PATCH] cmd: boot: Update reset usage message

[Michal Simek]

Hi Wolfgang,

On 8/13/21 8:54 AM, Wolfgang Denk wrote:
> Dear Michal,
> 
> In message <90e6c670-9e11-beb8-bcb5-9d22ba00fd11 at xilinx.com> you wrote:
>>
>>> In case of the hard (cold) reset - is it really only a reset of the
>>> CPU, or of the whole board hardware?
>>
>> If you look at sysreset headers you will find these levels
>>  11         SYSRESET_WARM,  /* Reset CPU, keep GPIOs active */
>>  12         SYSRESET_COLD,  /* Reset CPU and GPIOs */
>>  13         SYSRESET_POWER, /* Reset PMIC (remove and restore power) */
>>  14         SYSRESET_POWER_OFF,     /* Turn off power */
>>
>> When you call reset sysreset uclass is calling sysreset_walk which is
>> request to drivers with type passed.
>> I see we have mixed drivers which deals with levels and especially in
>> gpio case it is question how you connect it.
>> I develop this for microblaze where gpio is connected reset logic which
>> is normally only for CPU and subsystem.
>> But in general you can connect whatever you want. It means it doesn't
>> need to be only cpu which is reset.
> 
> Thanks a lot for the explanation.
> 
>> Do you want me to update that line and remove CPU from it?
> 
> I don't know :-)
> 
> What the "reset" command _should_ do is a hard cold boot including
> the reset of all peripherals - for example, when booting from SPI
> NOR flash it is mandatory to reset this flash to make sure the ROM
> boot loader can actually read it.
> 
> I would appreciate if the help message documents what it actually
> does.  Also, what the difference between "cold" and "warm" reset is.
> My expectation (without knowing any hardware details) would be that
> a warm reset is just a restart of the already loaded code? Or is it
> just a reset of the CPU (without external reset)? This might then
> hang the system if it's attempting to boot from a flash which is in
> the wrong state.
> 
> So my problem with this is primarily that I don't understand what
> the command really does, and the help command is of no help either.
> 
> [And if I understand correctly, this is even board dependent?]


https://developer.arm.com/documentation/den0022/latest/
DEN0022D_b_Power_State_Coordination_Interface.pdf
Where 5.11.1 chapter is saying
"This function provides a method for performing a system cold reset. To
the caller, the behavior is
equivalent to a hardware power-cycle sequence."

And also 5.12.2.1 for SYSTEM_RESET2
5.12.2.1 System Warm reset
This reset is selected when reset_type is 0x0 (SYSTEM_WARM_RESET).
The function is intended to provide a fast reboot path that guarantees
not to reset system main memory.
This is defined as volatile memory accessible by cores when executing in
the calling operating system.
This definition does not extend to caches or to memory-mapped IO.
The memory that is to be preserved and not trashed by boot firmware
needs to be described by
firmware table technologies such as ACPI [6] and Device Tree [7] and
does not need to cover all
available system main memory.

But they also open vendor-specific resets.
It means defining resets is more or less implementation dependent.

Thanks,
Michal