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

[Stephen Warren]

On 08/10/2015 09:44 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On 10 August 2015 at 21:35, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 07/17/2015 05:58 PM, Simon Glass wrote:
>>> On 6 July 2015 at 12:54, Simon Glass <sjg at 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 at 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).