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

[Simon Glass]

Hi Stephen,

On 25 September 2015 at 06:32, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 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 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).
>
> 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:
>

I've sent a patch:

http://patchwork.ozlabs.org/patch/525967/

Regards,
Simon