[U-Boot] [PATCH 08/18] sandbox: Use the reset driver to handle reset

[Stephen Warren <swarren@wwwdotorg.org>]

On 09/24/2015 11:13 PM, Stephen Warren wrote:
> On 08/10/2015 09:44 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On 10 August 2015 at 21:35, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> On 07/17/2015 05:58 PM, Simon Glass wrote:
>>>> On 6 July 2015 at 12:54, Simon Glass <sjg@chromium.org> wrote:
>>>>> Move sandbox over to use the reset uclass for reset, instead of a direct
>>>>> call to do_reset(). This allows us to add tests.
>>>>>
>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>> ---
>>>>>
>>>>>  arch/sandbox/cpu/cpu.c                    | 9 +--------
>>>>>  arch/sandbox/dts/test.dts                 | 8 ++++++++
>>>>>  arch/sandbox/include/asm/u-boot-sandbox.h | 3 +++
>>>>>  configs/sandbox_defconfig                 | 1 +
>>>>>  4 files changed, 13 insertions(+), 8 deletions(-)
>>>>
>>>> Applied to u-boot-dm.
>>>
>>> This patch causes the reset command to stop working in sandbox. It now
>>> prints:
>>>
>>> => reset
>>> Reset not supported on this platform
>>> ### ERROR ### Please RESET the board ###
>>>
>>> Among other things, this causes ./test/fs/fs-test.sh to hang without any
>>> particular indication why. (In that test, running under expect/pyexpect
>>> might be nicer, so the user could see progress; the error above doesn't
>>> even show up in the test log files).
>>
>> Yes I noticed the reset problem recently but haven't got back to it
>> yet sorry. Ctrl-C works if you are at the command line, but will not
>> fix the test.
>>
>> One problem is that sandbox.dts needs a reset node, one of the ones
>> from test.dts. Then at least 'u-boot -D' will work.
>>
>> The other is that we need a U_BOOT_DEVICE() declaration for the reset
>> controller. This is how drivers/serial/sandbox.c gets around this
>> problem.
>>
>> It would be good if we could run all the tests easily. At present it
>> involves lots of steps and the method used to run each is different.
> 
> Any update on this? I had forgotten about this issue and just debugged
> the exact same problem again. Unfortunately, reverting this commit seems
> to make U-Boot hang() at early init time now, so I can't work around the
> issue either (unless I made a mistake implementing the revert; I'll try
> again).

The following hack makes reset work again. This sounds like something
other than the issues you mentioned above?

> https://github.com/swarren/u-boot/commit/2e41c317516e414326620374725a25b7b531d2e2

> diff --git a/drivers/misc/reset_sandbox.c b/drivers/misc/reset_sandbox.c
> index 917121bc5e80..0208e11dbf3a 100644
> --- a/drivers/misc/reset_sandbox.c
> +++ b/drivers/misc/reset_sandbox.c
> @@ -40,8 +40,10 @@ static int sandbox_reset_request(struct udevice *dev, enum reset_t type)
>          * (see the U_BOOT_DEVICE() declaration below) should not do anything.
>          * If we are that device, return an error.
>          */
> +#if 0
>         if (gd->fdt_blob && dev->of_offset == -1)
>                 return -ENODEV;
> +#endif
>  
>         switch (type) {
>         case RESET_COLD: