diff mbox

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

Message ID 1436208879-8431-9-git-send-email-sjg@chromium.org
State Accepted
Delegated to: Simon Glass
Headers show

Commit Message

Simon Glass July 6, 2015, 6:54 p.m. UTC
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(-)

Comments

Simon Glass July 17, 2015, 11:58 p.m. UTC | #1
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.
Stephen Warren Aug. 11, 2015, 3:35 a.m. UTC | #2
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).
Simon Glass Aug. 11, 2015, 3:44 a.m. UTC | #3
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.

Regards,
Simon
Stephen Warren Sept. 25, 2015, 5:13 a.m. UTC | #4
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).
Stephen Warren Sept. 25, 2015, 5:32 a.m. UTC | #5
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:
Simon Glass Oct. 3, 2015, 5:21 p.m. UTC | #6
Hi Stephen,

On 25 September 2015 at 06:32, Stephen Warren <swarren@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@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:
>

I've sent a patch:

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

Regards,
Simon
diff mbox

Patch

diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index e6ddb17..3a7f5a0 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -20,7 +20,7 @@  static struct udevice *map_dev;
 unsigned long map_len;
 #endif
 
-void reset_cpu(ulong ignored)
+void sandbox_exit(void)
 {
 	/* Do this here while it still has an effect */
 	os_fd_restore();
@@ -34,13 +34,6 @@  void reset_cpu(ulong ignored)
 	os_exit(0);
 }
 
-int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
-{
-	reset_cpu(0);
-
-	return 0;
-}
-
 /* delay x useconds */
 void __udelay(unsigned long usec)
 {
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 7447f80..65bcf03 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -204,6 +204,14 @@ 
 		compatible = "sandbox,pinctrl";
 	};
 
+	reset@0 {
+		compatible = "sandbox,warm-reset";
+	};
+
+	reset@1 {
+		compatible = "sandbox,reset";
+	};
+
 	spi@0 {
 		#address-cells = <1>;
 		#size-cells = <0>;
diff --git a/arch/sandbox/include/asm/u-boot-sandbox.h b/arch/sandbox/include/asm/u-boot-sandbox.h
index da87cc3..2f3c3f9 100644
--- a/arch/sandbox/include/asm/u-boot-sandbox.h
+++ b/arch/sandbox/include/asm/u-boot-sandbox.h
@@ -83,4 +83,7 @@  void sandbox_set_enable_pci_map(int enable);
  */
 int sandbox_read_fdt_from_file(void);
 
+/* Exit sandbox (quit U-Boot) */
+void sandbox_exit(void);
+
 #endif	/* _U_BOOT_SANDBOX_H_ */
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 6fd4fa2..feba8d9 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -45,3 +45,4 @@  CONFIG_UT_ENV=y
 CONFIG_SANDBOX_SERIAL=y
 CONFIG_CLK=y
 CONFIG_PINCTRL=y
+CONFIG_RESET=y