From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Tue, 29 May 2012 07:25:18 -0700 Subject: [U-Boot] [PATCH 1/3] common/cmd_rsmode.c: add imx reset mode command In-Reply-To: <4FC3B7A5.2080805@googlemail.com> References: <1338066111-5835-1-git-send-email-troy.kisky@boundarydevices.com> <4FC1C403.6000409@googlemail.com> <4FC26173.9060907@boundarydevices.com> <4FC3B7A5.2080805@googlemail.com> Message-ID: <4FC4DC4E.9030007@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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