[U-Boot] [PATCH 1/3] common/cmd_rsmode.c: add imx reset mode command

[Eric Nelson]

Hi Dirk,

On 05/28/2012 10:36 AM, Dirk Behme wrote:
> On 27.05.2012 19:16, Eric Nelson wrote:
>> Hi Dirk,
>>
>> On 05/26/2012 11:04 PM, Dirk Behme wrote:
>>> Hi Troy,
>>>
>>> On 26.05.2012 23:01, Troy Kisky wrote:
>>>> This is useful for forcing the ROM's
>>>> usb downloader to activate upon a watchdog reset.
>>>> Or, you can boot from either SD Card.
>>>
>>> Thanks!
>>>
>>> Just for my understanding: Who will enable/run the watchdog reset?
>>> It was my
>>> understanding that after writing gpr9 and gpr10 someone has to
>>> enable the
>>> watchdog to execute the reset?
>>>
>> Or just issue the 'reset' command, so we can prevent the need to
>> re-program the SPI ROM with the boot to SD shim with something like
>> this:
>>
>> U-Boot> set bootcmd 'rsmode esdhc3 && reset' && saveenv
>>
>> I discussed this with Troy yesterday and would like to get some feedback
>> from those most likely to use the features of this code.
>
> I like this idea.
>
> But I haven't looked into the detailed implementation of the 'reset' command for
> i.MX6. Does it run/execute the necessary watchdog reset?
>
It does. I just traced this code:
	common/cmd_boot defines the command
	arch/arm/lib/reset.c calls reset_cpu()

reset_cpu() is defined here:
	http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/imx-common/cpu.c;h=b3195dd6fb2a9817d37f2d6e0e37b83833ed2d7b;hb=HEAD#l127

Writing a 4 to the WDOG_BASE register enables the watchdog with a 1/2s delay.
I think there should be a delay or while(1) loop afterwards though. It appears
that the reset_cpu() routine will return.


>> Troy's implementation exposes the internals and all of the power
>> of the reset mode override feature. Through the 'rsmode' command,
>> you can set up what happens during the next watchdog reset and then do
>> something else.
>>
>> For instance, you could say 'rsmode esdhc1', set up the watchdog and
>> then launch an O/S which should take over the watchdog. If something
>> fails, the ROM will attempt to boot to esdhc1, providing a fallback
>> mechanism of sorts.
>
> What I read from above is that we need to flavors of the reset (watchdog setup)
> command? Or better: Two ways of enabling the watchdog for the two usage
> scenarios I read above:
>
> Usage scenario 1: We wan't to reset/reboot as soon as possible after doing the
> rsmode command. This would be used as a replacement for what we use at the
> moment with the SabreLite boards: They boot from SPI NOR, but we like to switch
> as fast as possible to SD boot. This implies that the watchdog reset is needed
> as fast as possible after the rsmode command is done.
>
> Usage scenario 2: This is what you describe above: Set the rsmode, set up the
> watchdog and let the OS take over the watchdog. This would imply a longer
> watchdog reset period, to give the OS some time to take over.
>
>> While there may be some conditions under which this will be used,
>> a few dominant use cases and these could be made simpler to understand
>> and use.
>>
>> 1. Change 'rsmode' to 'rstmode'. I suspect that everyone will have
>> an easier time understanding that the latter means 'reset mode'.
>
> Yes, this sounds better :) I'm not sure about the naming conventions, but
> spending some additional characters to name it 'resetmode' would work, too?
>
>> 2. Implement 'download_mode' or 'downusb' as a short-hand for the
>> sequence:
>>
>> U-Boot> rsmode usb && reset
>>
>> This sequence will be executed mostly by those on this list and
>> the abbreviation is worth the small addition of code.
>>
>> I already have 'down' in muscle memory and using it will ease
>> the pain for the (hopefully short) interval while I'm using
>> both the Freescale 2009.08 code base and mainline.
>>
>> 3. Similarly, implement 'bootsd' or 'bootmmc' with a parameter that
>> matches the SD card naming used by other U-Boot commands.
>>
>> How many of you know without grepping or pulling up a schematic
>> which device corresponds to 'mmc 0'?
>>
>> It seems more intuitive to issue this command:
>>
>> U-Boot> bootmmc 0
>>
>> instead of this:
>>
>> U-Boot> rsmode esdhc3 && reset
>>
>> 4. Same rationale for 'bootsata'.
>>
>> 5. Allow boards to say which devices are even exposed in their config
>> headers. i.e.
>> #define BOARD_HAS_ESDHC3
>>
>> ...
>>
>> #ifdef BOARD_HAS_ESDHC3
>> {"esdhc1", mkval(0x40, 0x20, 0x00, 0x12)},
>> #endif
>>
>> This will allow a form of self-documentation when running 'rsmode'
>> with no parameters.
>
> This sounds good, too.
>
>> I doubt any board supports all of the boot options.
>>
>> Let us know your thoughts on this and thanks for the code Troy!
>
> Yes, many thanks for the code!
>
> I think we should clarify how the watchdog is handled in this scenario. By the
> reset command? And do we need a 'long timeout' and a 'immediate timeout' watchdog?
>
These are probably different things. It seems that the fact that the watchdog
timer is used to implement reset is just an implementation detail.

Implementation of a true watchdog timer (i.e. 'long timeout') seems like a
separate feature.

Regards,


Eric