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

2015-10-03 Thread Simon Glass 
Hi Stephen,

On 25 September 2015 at 06:32, Stephen Warren  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  wrote:
 On 07/17/2015 05:58 PM, Simon Glass wrote:
> On 6 July 2015 at 12:54, Simon Glass  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 
>> ---
>>
>>  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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

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

  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).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2015-09-24 Thread Stephen Warren 
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  wrote:
>>> On 07/17/2015 05:58 PM, Simon Glass wrote:
 On 6 July 2015 at 12:54, Simon Glass  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 
> ---
>
>  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:

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2015-08-10 Thread Stephen Warren 
On 07/17/2015 05:58 PM, Simon Glass wrote:
 On 6 July 2015 at 12:54, Simon Glass s...@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 s...@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).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2015-08-10 Thread Simon Glass 
Hi Stephen,

On 10 August 2015 at 21:35, Stephen Warren swar...@wwwdotorg.org wrote:
 On 07/17/2015 05:58 PM, Simon Glass wrote:
 On 6 July 2015 at 12:54, Simon Glass s...@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 s...@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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2015-07-17 Thread Simon Glass 
On 6 July 2015 at 12:54, Simon Glass s...@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 s...@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.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2015-07-06 Thread Simon Glass 
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 s...@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(-)

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
-- 
2.4.3.573.g4eafbef

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot