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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
