[PATCH v3] test/py: reset: Add a test for reset command

Add a test for reset commands which performs resetting of CPU, It does COLD reset by default and WARM reset with -w option.
Signed-off-by: Love Kumar love.kumar@amd.com --- Changes in v2: - Set bootmode through boardenv if modeboot is not defined Changes in v3: - Fix the issue with bad pattern found on console --- test/py/tests/test_reset.py | 61 +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 test/py/tests/test_reset.py
diff --git a/test/py/tests/test_reset.py b/test/py/tests/test_reset.py new file mode 100644 index 000000000000..0178b1dc40a3 --- /dev/null +++ b/test/py/tests/test_reset.py @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0 +# (C) Copyright 2023, Advanced Micro Devices, Inc. + +""" +Note: This test doesn't rely on boardenv_* configuration value but they can +change test behavior. + +For example: + +# Setup env__reset_test_skip to True if reset test is not possible or desired +# and should be skipped. +env__reset_test_skip = True + +# Setup env__reset_test to set the bootmode if 'modeboot' u-boot environment +# variable is not set. Test will be skipped if bootmode is not set in both +# places i.e, boardenv and modeboot u-boot environment variable +env__reset_test = { + 'bootmode': 'qspiboot', +} + +# This test will be also skipped if the bootmode is detected to JTAG. +""" + +import pytest +import test_000_version + +def setup_reset_env(u_boot_console): + if u_boot_console.config.env.get('env__reset_test_skip', False): + pytest.skip('reset test is not enabled') + + output = u_boot_console.run_command('echo $modeboot') + if output: + bootmode = output + else: + f = u_boot_console.config.env.get('env__reset_test', None) + if not f: + pytest.skip('bootmode cannot be determined') + bootmode = f.get('bootmode', 'jtagboot') + + if 'jtag' in bootmode: + pytest.skip('skipping reset test due to jtag bootmode') + +def test_reset(u_boot_console): + """Test the reset command in non-JTAG bootmode. + It does COLD reset, which resets CPU, DDR and peripherals + """ + setup_reset_env(u_boot_console) + u_boot_console.run_command('reset', wait_for_reboot=True) + + # Checks the u-boot command prompt's functionality after reset + test_000_version.test_version(u_boot_console) + +def test_reset_w(u_boot_console): + """Test the reset -w command in non-JTAG bootmode. + It does WARM reset, which resets CPU but keep DDR/peripherals active. + """ + setup_reset_env(u_boot_console) + u_boot_console.run_command('reset -w', wait_for_reboot=True) + + # Checks the u-boot command prompt's functionality after reset + test_000_version.test_version(u_boot_console)

On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote:
Add a test for reset commands which performs resetting of CPU, It does COLD reset by default and WARM reset with -w option.
Signed-off-by: Love Kumar love.kumar@amd.com
Reviewed-by: Tom Rini trini@konsulko.com

On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote:
Add a test for reset commands which performs resetting of CPU, It does COLD reset by default and WARM reset with -w option.
Signed-off-by: Love Kumar love.kumar@amd.com Reviewed-by: Tom Rini trini@konsulko.com
Changes in v2:
- Set bootmode through boardenv if modeboot is not defined
Changes in v3:
- Fix the issue with bad pattern found on console
test/py/tests/test_reset.py | 61 +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 test/py/tests/test_reset.py
I had hoped this was all sorted out now, but both this and the saveenv test cause qemu_m68k to fail now. See: https://source.denx.de/u-boot/u-boot/-/jobs/791635

Hi Tom,
On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote:
Add a test for reset commands which performs resetting of CPU, It does COLD reset by default and WARM reset with -w option. Signed-off-by: Love Kumar love.kumar@amd.com Reviewed-by: Tom Rini trini@konsulko.com --- Changes in v2: - Set bootmode through boardenv if modeboot is not defined Changes in v3: - Fix the issue with bad pattern found on console --- test/py/tests/test_reset.py | 61 +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 test/py/tests/test_reset.py
I had hoped this was all sorted out now, but both this and the saveenv test cause qemu_m68k to fail now. See: https://source.denx.de/u-boot/u-boot/-/jobs/791635
looking into this.
Regards, angelo
On 02/03/24 4:18 PM, Tom Rini wrote:

On 3/3/24 22:58, Angelo Dureghello wrote:
Hi Tom,
On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote:
Add a test for reset commands which performs resetting of CPU, It does COLD reset by default and WARM reset with -w option. Signed-off-by: Love Kumar love.kumar@amd.com Reviewed-by: Tom Rini trini@konsulko.com --- Changes in v2: - Set bootmode through boardenv if modeboot is not defined Changes in v3: - Fix the issue with bad pattern found on console --- test/py/tests/test_reset.py | 61 +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 test/py/tests/test_reset.py
I had hoped this was all sorted out now, but both this and the saveenv test cause qemu_m68k to fail now. See: https://source.denx.de/u-boot/u-boot/-/jobs/791635
looking into this.
Is reset implemented in qemu? It should be skipped if it is not.
Thanks, Michal

Hi,
On 05/03/24 1:34 PM, Michal Simek wrote:
On 3/3/24 22:58, Angelo Dureghello wrote:
Hi Tom,
On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote:
Add a test for reset commands which performs resetting of CPU, It does COLD reset by default and WARM reset with -w option. Signed-off-by: Love Kumar love.kumar@amd.com Reviewed-by: Tom Rini trini@konsulko.com --- Changes in v2: - Set bootmode through boardenv if modeboot is not defined Changes in v3: - Fix the issue with bad pattern found on console --- test/py/tests/test_reset.py | 61 +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 test/py/tests/test_reset.py
I had hoped this was all sorted out now, but both this and the saveenv test cause qemu_m68k to fail now. See: https://source.denx.de/u-boot/u-boot/-/jobs/791635
looking into this.
Is reset implemented in qemu? It should be skipped if it is not.
yes, seems not implemented
=> reset => reset -w => =>
Not finding any trace in the qemu code related to
out_8(&rcm->rcr, RCM_RCR_SOFTRST);
Regards, angelo
Thanks, Michal

On Thu, Mar 07, 2024 at 12:36:42AM +0100, Angelo Dureghello wrote:
Hi,
On 05/03/24 1:34 PM, Michal Simek wrote:
On 3/3/24 22:58, Angelo Dureghello wrote:
Hi Tom,
On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote:
Add a test for reset commands which performs resetting of CPU, It does COLD reset by default and WARM reset with -w option. Signed-off-by: Love Kumar love.kumar@amd.com Reviewed-by: Tom Rini trini@konsulko.com --- Changes in v2: - Set bootmode through boardenv if modeboot is not defined Changes in v3: - Fix the issue with bad pattern found on console --- test/py/tests/test_reset.py | 61 +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 test/py/tests/test_reset.py
I had hoped this was all sorted out now, but both this and the saveenv test cause qemu_m68k to fail now. See: https://source.denx.de/u-boot/u-boot/-/jobs/791635
looking into this.
Is reset implemented in qemu? It should be skipped if it is not.
yes, seems not implemented
=> reset => reset -w => =>
Not finding any trace in the qemu code related to
out_8(&rcm->rcr, RCM_RCR_SOFTRST);
Does reset work on the real HW, or can you not test? What I'm wondering is if we have a missing feature on the board/arch code (and should disable the reset command) or a problem with QEMU.

Hi Tom,
On 07/03/24 1:10 AM, Tom Rini wrote:
On Thu, Mar 07, 2024 at 12:36:42AM +0100, Angelo Dureghello wrote:
Hi,
On 05/03/24 1:34 PM, Michal Simek wrote:
On 3/3/24 22:58, Angelo Dureghello wrote:
Hi Tom,
On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote:
Add a test for reset commands which performs resetting of CPU, It does COLD reset by default and WARM reset with -w option. Signed-off-by: Love Kumar love.kumar@amd.com Reviewed-by: Tom Rini trini@konsulko.com --- Changes in v2: - Set bootmode through boardenv if modeboot is not defined Changes in v3: - Fix the issue with bad pattern found on console --- test/py/tests/test_reset.py | 61 +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 test/py/tests/test_reset.py
I had hoped this was all sorted out now, but both this and the saveenv test cause qemu_m68k to fail now. See: https://source.denx.de/u-boot/u-boot/-/jobs/791635
looking into this.
Is reset implemented in qemu? It should be skipped if it is not.
yes, seems not implemented
=> reset => reset -w => =>
Not finding any trace in the qemu code related to
out_8(&rcm->rcr, RCM_RCR_SOFTRST);
Does reset work on the real HW, or can you not test? What I'm wondering is if we have a missing feature on the board/arch code (and should disable the reset command) or a problem with QEMU.
I don't have the exact hardware (m5208evb) but:
1) i checked by tracing that on qemu the reset function is properly called
=> reset resetting, RCR fc0a0000
2) reset register address is correct. I checked also that writing directly to it by mw.b does now produce the reset,
=> reset resetting, RCR fc0a0000
=> mw.b 0xfc0a0000 80 =>
So looks not implemented in qemu.
3) testing reset on similar mcf5282, real hardware, it works
Regards, angelo

On 3/7/24 08:56, Angelo Dureghello wrote:
Hi Tom,
On 07/03/24 1:10 AM, Tom Rini wrote:
On Thu, Mar 07, 2024 at 12:36:42AM +0100, Angelo Dureghello wrote:
Hi,
On 05/03/24 1:34 PM, Michal Simek wrote:
On 3/3/24 22:58, Angelo Dureghello wrote:
Hi Tom,
On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote: > Add a test for reset commands which performs resetting of > CPU, It does COLD reset by default and WARM reset with -w > option. Signed-off-by: Love Kumar love.kumar@amd.com > Reviewed-by: Tom Rini trini@konsulko.com --- Changes in > v2: - Set bootmode through boardenv if modeboot is not > defined Changes in v3: - Fix the issue with bad pattern > found on console --- test/py/tests/test_reset.py | 61 > +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 > insertions(+) create mode 100644 test/py/tests/test_reset.py I had hoped this was all sorted out now, but both this and the saveenv test cause qemu_m68k to fail now. See: https://source.denx.de/u-boot/u-boot/-/jobs/791635
looking into this.
Is reset implemented in qemu? It should be skipped if it is not.
yes, seems not implemented
=> reset => reset -w => =>
Not finding any trace in the qemu code related to
out_8(&rcm->rcr, RCM_RCR_SOFTRST);
Does reset work on the real HW, or can you not test? What I'm wondering is if we have a missing feature on the board/arch code (and should disable the reset command) or a problem with QEMU.
I don't have the exact hardware (m5208evb) but:
- i checked by tracing that on qemu the reset function is properly called
=> reset resetting, RCR fc0a0000
- reset register address is correct. I checked also that writing directly to it
by mw.b does now produce the reset,
=> reset resetting, RCR fc0a0000
=> mw.b 0xfc0a0000 80 =>
So looks not implemented in qemu.
ok. That means that we shouldn't run reset test inside CI loop for this platform.
Thanks, Michal

On Thu, Mar 07, 2024 at 09:26:42AM +0100, Michal Simek wrote:
On 3/7/24 08:56, Angelo Dureghello wrote:
Hi Tom,
On 07/03/24 1:10 AM, Tom Rini wrote:
On Thu, Mar 07, 2024 at 12:36:42AM +0100, Angelo Dureghello wrote:
Hi,
On 05/03/24 1:34 PM, Michal Simek wrote:
On 3/3/24 22:58, Angelo Dureghello wrote:
Hi Tom, > On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote: > > Add a test for reset commands which performs resetting of > > CPU, It does COLD reset by default and WARM reset with -w > > option. Signed-off-by: Love Kumar love.kumar@amd.com > > Reviewed-by: Tom Rini trini@konsulko.com --- Changes in > > v2: - Set bootmode through boardenv if modeboot is not > > defined Changes in v3: - Fix the issue with bad pattern > > found on console --- test/py/tests/test_reset.py | 61 > > +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 > > insertions(+) create mode 100644 test/py/tests/test_reset.py > I had hoped this was all sorted out now, but both this and the > saveenv test cause qemu_m68k to fail now. See: > https://source.denx.de/u-boot/u-boot/-/jobs/791635 looking into this.
Is reset implemented in qemu? It should be skipped if it is not.
yes, seems not implemented
=> reset => reset -w => =>
Not finding any trace in the qemu code related to
out_8(&rcm->rcr, RCM_RCR_SOFTRST);
Does reset work on the real HW, or can you not test? What I'm wondering is if we have a missing feature on the board/arch code (and should disable the reset command) or a problem with QEMU.
I don't have the exact hardware (m5208evb) but:
- i checked by tracing that on qemu the reset function is properly called
=> reset resetting, RCR fc0a0000
- reset register address is correct. I checked also that writing
directly to it by mw.b does now produce the reset,
=> reset resetting, RCR fc0a0000
=> mw.b 0xfc0a0000 80 =>
So looks not implemented in qemu.
ok. That means that we shouldn't run reset test inside CI loop for this platform.
Agreed. The TEST_PY_TEST_SPEC variable in both of the pipelines can be used to say "not reset" for this platform in the next rev. It would also be nice to file a bug report with QEMU too I think. Thanks for digging in to this everyone.

Hi,
On 07/03/24 1:55 PM, Tom Rini wrote:
On Thu, Mar 07, 2024 at 09:26:42AM +0100, Michal Simek wrote:
On 3/7/24 08:56, Angelo Dureghello wrote:
Hi Tom,
On 07/03/24 1:10 AM, Tom Rini wrote:
On Thu, Mar 07, 2024 at 12:36:42AM +0100, Angelo Dureghello wrote:
Hi,
On 05/03/24 1:34 PM, Michal Simek wrote:
On 3/3/24 22:58, Angelo Dureghello wrote: > Hi Tom, >> On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote: >>> Add a test for reset commands which performs resetting of >>> CPU, It does COLD reset by default and WARM reset with -w >>> option. Signed-off-by: Love Kumar love.kumar@amd.com >>> Reviewed-by: Tom Rini trini@konsulko.com --- Changes in >>> v2: - Set bootmode through boardenv if modeboot is not >>> defined Changes in v3: - Fix the issue with bad pattern >>> found on console --- test/py/tests/test_reset.py | 61 >>> +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 >>> insertions(+) create mode 100644 test/py/tests/test_reset.py >> I had hoped this was all sorted out now, but both this and the >> saveenv test cause qemu_m68k to fail now. See: >> https://source.denx.de/u-boot/u-boot/-/jobs/791635 > looking into this.
Is reset implemented in qemu? It should be skipped if it is not.
yes, seems not implemented
=> reset => reset -w => =>
Not finding any trace in the qemu code related to
out_8(&rcm->rcr, RCM_RCR_SOFTRST);
Does reset work on the real HW, or can you not test? What I'm wondering is if we have a missing feature on the board/arch code (and should disable the reset command) or a problem with QEMU.
I don't have the exact hardware (m5208evb) but:
- i checked by tracing that on qemu the reset function is properly called
=> reset resetting, RCR fc0a0000
- reset register address is correct. I checked also that writing
directly to it by mw.b does now produce the reset,
=> reset resetting, RCR fc0a0000
=> mw.b 0xfc0a0000 80 =>
So looks not implemented in qemu.
ok. That means that we shouldn't run reset test inside CI loop for this platform.
Agreed. The TEST_PY_TEST_SPEC variable in both of the pipelines can be used to say "not reset" for this platform in the next rev. It would also be nice to file a bug report with QEMU too I think. Thanks for digging in to this everyone.
good. I also sent a patch to qemu, lets see
https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg01899.html
Regards, angelo

Hi,
jfyi,
reset support added in qemu merged as commit d3c79c3974.
Regards, angelo
On 07/03/24 1:55 PM, Tom Rini wrote:
On Thu, Mar 07, 2024 at 09:26:42AM +0100, Michal Simek wrote:
On 3/7/24 08:56, Angelo Dureghello wrote:
Hi Tom,
On 07/03/24 1:10 AM, Tom Rini wrote:
On Thu, Mar 07, 2024 at 12:36:42AM +0100, Angelo Dureghello wrote:
Hi,
On 05/03/24 1:34 PM, Michal Simek wrote:
On 3/3/24 22:58, Angelo Dureghello wrote: > Hi Tom, >> On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote: >>> Add a test for reset commands which performs resetting of >>> CPU, It does COLD reset by default and WARM reset with -w >>> option. Signed-off-by: Love Kumar love.kumar@amd.com >>> Reviewed-by: Tom Rini trini@konsulko.com --- Changes in >>> v2: - Set bootmode through boardenv if modeboot is not >>> defined Changes in v3: - Fix the issue with bad pattern >>> found on console --- test/py/tests/test_reset.py | 61 >>> +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 >>> insertions(+) create mode 100644 test/py/tests/test_reset.py >> I had hoped this was all sorted out now, but both this and the >> saveenv test cause qemu_m68k to fail now. See: >> https://source.denx.de/u-boot/u-boot/-/jobs/791635 > looking into this.
Is reset implemented in qemu? It should be skipped if it is not.
yes, seems not implemented
=> reset => reset -w => =>
Not finding any trace in the qemu code related to
out_8(&rcm->rcr, RCM_RCR_SOFTRST);
Does reset work on the real HW, or can you not test? What I'm wondering is if we have a missing feature on the board/arch code (and should disable the reset command) or a problem with QEMU.
I don't have the exact hardware (m5208evb) but:
- i checked by tracing that on qemu the reset function is properly called
=> reset resetting, RCR fc0a0000
- reset register address is correct. I checked also that writing
directly to it by mw.b does now produce the reset,
=> reset resetting, RCR fc0a0000
=> mw.b 0xfc0a0000 80 =>
So looks not implemented in qemu.
ok. That means that we shouldn't run reset test inside CI loop for this platform.
Agreed. The TEST_PY_TEST_SPEC variable in both of the pipelines can be used to say "not reset" for this platform in the next rev. It would also be nice to file a bug report with QEMU too I think. Thanks for digging in to this everyone.

Hi,
On 11/03/24 2:11 pm, Angelo Dureghello wrote:
Hi,
jfyi,
reset support added in qemu merged as commit d3c79c3974.
Regards, angelo
The other issue was with echo commands: => echo $modeboot $modeboot
=> echo $? $?
Does HUSH shell is enabled by default for this?
Regards, Love Kumar
On 07/03/24 1:55 PM, Tom Rini wrote:
On Thu, Mar 07, 2024 at 09:26:42AM +0100, Michal Simek wrote:
On 3/7/24 08:56, Angelo Dureghello wrote:
Hi Tom,
On 07/03/24 1:10 AM, Tom Rini wrote:
On Thu, Mar 07, 2024 at 12:36:42AM +0100, Angelo Dureghello wrote:
Hi,
On 05/03/24 1:34 PM, Michal Simek wrote: > > > On 3/3/24 22:58, Angelo Dureghello wrote: >> Hi Tom, >>> On Tue, Feb 20, 2024 at 01:11:38PM +0530, Love Kumar wrote: >>>> Add a test for reset commands which performs resetting of >>>> CPU, It does COLD reset by default and WARM reset with -w >>>> option. Signed-off-by: Love Kumar love.kumar@amd.com >>>> Reviewed-by: Tom Rini trini@konsulko.com --- Changes in >>>> v2: - Set bootmode through boardenv if modeboot is not >>>> defined Changes in v3: - Fix the issue with bad pattern >>>> found on console --- test/py/tests/test_reset.py | 61 >>>> +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 >>>> insertions(+) create mode 100644 test/py/tests/test_reset.py >>> I had hoped this was all sorted out now, but both this and the >>> saveenv test cause qemu_m68k to fail now. See: >>> https://source.denx.de/u-boot/u-boot/-/jobs/791635 >> looking into this. > > Is reset implemented in qemu? It should be skipped if it is not. > yes, seems not implemented
=> reset => reset -w => =>
Not finding any trace in the qemu code related to
out_8(&rcm->rcr, RCM_RCR_SOFTRST);
Does reset work on the real HW, or can you not test? What I'm wondering is if we have a missing feature on the board/arch code (and should disable the reset command) or a problem with QEMU.
I don't have the exact hardware (m5208evb) but:
- i checked by tracing that on qemu the reset function is properly
called
=> reset resetting, RCR fc0a0000
- reset register address is correct. I checked also that writing
directly to it by mw.b does now produce the reset,
=> reset resetting, RCR fc0a0000
=> mw.b 0xfc0a0000 80 =>
So looks not implemented in qemu.
ok. That means that we shouldn't run reset test inside CI loop for this platform.
Agreed. The TEST_PY_TEST_SPEC variable in both of the pipelines can be used to say "not reset" for this platform in the next rev. It would also be nice to file a bug report with QEMU too I think. Thanks for digging in to this everyone.

On Mon, Mar 11, 2024 at 02:40:59PM +0530, Love Kumar wrote:
Hi,
On 11/03/24 2:11 pm, Angelo Dureghello wrote:
Hi,
jfyi,
reset support added in qemu merged as commit d3c79c3974.
Regards, angelo
The other issue was with echo commands: => echo $modeboot $modeboot
=> echo $? $?
Does HUSH shell is enabled by default for this?
It is not, so at least the saveenv test needs to depend on HUSH_PARSER too.

On 3/11/24 15:39, Tom Rini wrote:
On Mon, Mar 11, 2024 at 02:40:59PM +0530, Love Kumar wrote:
Hi,
On 11/03/24 2:11 pm, Angelo Dureghello wrote:
Hi,
jfyi,
reset support added in qemu merged as commit d3c79c3974.
Regards, angelo
The other issue was with echo commands: => echo $modeboot $modeboot
=> echo $? $?
Does HUSH shell is enabled by default for this?
It is not, so at least the saveenv test needs to depend on HUSH_PARSER too.
Based on logs on this platform echo $? doesn't return any value. There is any config for it which is not enabled for this platform. Do you know which Kconfig symbol it is?
Depending on HUSH is likely big hammer but I was not able to find that exact Kconfig symbol just for $?
thanks, Michal

On Mon, Mar 11, 2024 at 03:52:57PM +0100, Michal Simek wrote:
On 3/11/24 15:39, Tom Rini wrote:
On Mon, Mar 11, 2024 at 02:40:59PM +0530, Love Kumar wrote:
Hi,
On 11/03/24 2:11 pm, Angelo Dureghello wrote:
Hi,
jfyi,
reset support added in qemu merged as commit d3c79c3974.
Regards, angelo
The other issue was with echo commands: => echo $modeboot $modeboot
=> echo $? $?
Does HUSH shell is enabled by default for this?
It is not, so at least the saveenv test needs to depend on HUSH_PARSER too.
Based on logs on this platform echo $? doesn't return any value. There is any config for it which is not enabled for this platform. Do you know which Kconfig symbol it is?
Depending on HUSH is likely big hammer but I was not able to find that exact Kconfig symbol just for $?
Well, if we don't have the hush parser we have a much more limited parser enabled and I bet that's why (I think there's no variable expansion).

On 3/11/24 16:09, Tom Rini wrote:
On Mon, Mar 11, 2024 at 03:52:57PM +0100, Michal Simek wrote:
On 3/11/24 15:39, Tom Rini wrote:
On Mon, Mar 11, 2024 at 02:40:59PM +0530, Love Kumar wrote:
Hi,
On 11/03/24 2:11 pm, Angelo Dureghello wrote:
Hi,
jfyi,
reset support added in qemu merged as commit d3c79c3974.
Regards, angelo
The other issue was with echo commands: => echo $modeboot $modeboot
=> echo $? $?
Does HUSH shell is enabled by default for this?
It is not, so at least the saveenv test needs to depend on HUSH_PARSER too.
Based on logs on this platform echo $? doesn't return any value. There is any config for it which is not enabled for this platform. Do you know which Kconfig symbol it is?
Depending on HUSH is likely big hammer but I was not able to find that exact Kconfig symbol just for $?
Well, if we don't have the hush parser we have a much more limited parser enabled and I bet that's why (I think there's no variable expansion).
ok. Then this test should be limited to HUSH too based on how it is written. I think it should be okish limitation and if someone wants to test it on systems without HUSH enabled it should just update it. If is fine for you?
Thanks, Michal

On Mon, Mar 11, 2024 at 04:14:04PM +0100, Michal Simek wrote:
On 3/11/24 16:09, Tom Rini wrote:
On Mon, Mar 11, 2024 at 03:52:57PM +0100, Michal Simek wrote:
On 3/11/24 15:39, Tom Rini wrote:
On Mon, Mar 11, 2024 at 02:40:59PM +0530, Love Kumar wrote:
Hi,
On 11/03/24 2:11 pm, Angelo Dureghello wrote:
Hi,
jfyi,
reset support added in qemu merged as commit d3c79c3974.
Regards, angelo
The other issue was with echo commands: => echo $modeboot $modeboot
=> echo $? $?
Does HUSH shell is enabled by default for this?
It is not, so at least the saveenv test needs to depend on HUSH_PARSER too.
Based on logs on this platform echo $? doesn't return any value. There is any config for it which is not enabled for this platform. Do you know which Kconfig symbol it is?
Depending on HUSH is likely big hammer but I was not able to find that exact Kconfig symbol just for $?
Well, if we don't have the hush parser we have a much more limited parser enabled and I bet that's why (I think there's no variable expansion).
ok. Then this test should be limited to HUSH too based on how it is written. I think it should be okish limitation and if someone wants to test it on systems without HUSH enabled it should just update it. If is fine for you?
Yup, sounds good. And I'll take the next iteration of this test patch when I also grab the patch I posted to cherry-pick the missing reset functionality in our QEMU.
participants (4)
-
Angelo Dureghello
-
Love Kumar
-
Michal Simek
-
Tom Rini