Message ID | 1436208879-8431-9-git-send-email-sjg@chromium.org |
---|---|
State | Accepted |
Delegated to: | Simon Glass |
Headers | show |
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.
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).
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
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).
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:
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 --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
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(-)