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