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