Please pull u-boot-watchdog/next
Hi Tom,
please pull the following watchdog related patches:
---------------------------------------------------------------- - Migrate watchdog reset to cyclic infrastructure (Stefan) ----------------------------------------------------------------
Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260&view=resu...
Thanks, Stefan
The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852:
Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 17:02:52 -0400)
are available in the Git repository at:
git@source.denx.de:u-boot/custodians/u-boot-watchdog.git next
for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8:
watchdog: Further cleanup (2022-09-16 07:09:05 +0200)
---------------------------------------------------------------- Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup
arch/arm/mach-at91/phy.c | 2 +- arch/arm/mach-imx/i2c-mxv7.c | 2 +- arch/arm/mach-socfpga/spl_a10.c | 8 +-- .../mach-stm32mp/cmd_stm32prog/stm32prog_serial.c | 6 +- arch/m68k/lib/time.c | 2 +- arch/powerpc/cpu/mpc8xx/cpu_init.c | 2 +- arch/powerpc/lib/bootm.c | 6 +- arch/powerpc/lib/cache.c | 2 +- arch/powerpc/lib/interrupts.c | 2 +- arch/powerpc/lib/ticks.S | 5 +- board/astro/mcf5373l/fpga.c | 4 +- board/dhelectronics/dh_stm32mp1/board.c | 2 +- board/liebherr/display5/spl.c | 2 +- board/nokia/rx51/rx51.c | 2 +- board/st/stm32mp1/stm32mp1.c | 2 +- boot/bootretry.c | 2 +- boot/image-board.c | 2 +- cmd/fastboot.c | 2 +- cmd/mem.c | 16 ++--- cmd/usb_mass_storage.c | 2 +- cmd/ximg.c | 2 +- common/board_f.c | 4 +- common/board_r.c | 2 +- common/cli_readline.c | 4 +- common/console.c | 2 +- common/cyclic.c | 11 ++++ common/dfu.c | 2 +- common/lcd.c | 10 +-- common/menu.c | 6 +- common/usb_kbd.c | 2 +- common/xyzModem.c | 2 +- drivers/block/ide.c | 8 +-- drivers/crypto/aspeed/aspeed_hace.c | 2 +- drivers/crypto/hash/hash_sw.c | 2 +- drivers/ddr/altera/sdram_arria10.c | 4 +- drivers/ddr/altera/sdram_n5x.c | 4 +- drivers/ddr/altera/sdram_soc64.c | 2 +- drivers/fpga/intel_sdm_mb.c | 8 +-- drivers/fpga/socfpga_arria10.c | 8 +-- drivers/i2c/mxc_i2c.c | 4 +- drivers/mmc/octeontx_hsmmc.c | 12 ++-- drivers/mmc/sh_mmcif.c | 6 +- drivers/mmc/stm32_sdmmc2.c | 2 +- drivers/mtd/cfi_flash.c | 4 +- drivers/mtd/nand/core.c | 2 +- drivers/mtd/nand/raw/atmel_nand.c | 6 +- drivers/mtd/nand/raw/nand_base.c | 10 +-- drivers/mtd/nand/raw/nand_util.c | 6 +- drivers/mtd/nand/spi/core.c | 4 +- drivers/mtd/onenand/onenand_base.c | 4 +- drivers/mtd/spi/spi-nor-core.c | 4 +- drivers/net/octeontx2/nix.c | 2 +- drivers/net/octeontx2/nix_af.c | 32 +++++----- drivers/ram/stm32mp1/stm32mp1_tests.c | 2 +- drivers/serial/atmel_usart.c | 2 +- drivers/serial/ns16550.c | 6 +- drivers/serial/serial-uclass.c | 2 +- drivers/serial/serial_bcm283x_mu.c | 2 +- drivers/serial/serial_lpuart.c | 8 +-- drivers/serial/serial_mpc8xx.c | 4 +- drivers/serial/serial_mt7620.c | 2 +- drivers/serial/serial_mtk.c | 4 +- drivers/serial/serial_mxc.c | 6 +- drivers/serial/serial_octeon_bootcmd.c | 2 +- drivers/serial/serial_octeon_pcie_console.c | 4 +- drivers/serial/serial_pl01x.c | 8 +-- drivers/serial/serial_sifive.c | 2 +- drivers/serial/serial_zynq.c | 2 +- drivers/spi/mtk_snfi_spi.c | 2 +- drivers/spi/octeon_spi.c | 2 +- drivers/spi/stm32_qspi.c | 2 +- drivers/timer/mpc83xx_timer.c | 4 +- drivers/usb/eth/lan7x.h | 4 +- drivers/usb/gadget/f_acm.c | 4 +- drivers/usb/gadget/f_sdp.c | 4 +- drivers/usb/host/ehci-hcd.c | 2 +- drivers/usb/musb-new/musb_uboot.c | 2 +- drivers/video/video_bmp.c | 4 +- drivers/watchdog/Kconfig | 2 + drivers/watchdog/wdt-uclass.c | 73 ++++++++++++---------- env/common.c | 2 +- fs/cramfs/uncompress.c | 3 +- fs/jffs2/jffs2_1pass.c | 2 +- include/cyclic.h | 12 ++++ include/linux/compat.h | 2 +- include/wait_bit.h | 2 +- include/watchdog.h | 68 +------------------- lib/bzip2/bzlib.c | 2 +- lib/bzip2/bzlib_decompress.c | 8 +-- lib/crc32.c | 2 +- lib/efi_loader/efi_boottime.c | 4 +- lib/gunzip.c | 2 +- lib/lzma/LzmaDec.c | 16 ++--- lib/lzma/LzmaTools.c | 2 +- lib/md5.c | 2 +- lib/sha1.c | 2 +- lib/sha256.c | 2 +- lib/sha512.c | 4 +- lib/time.c | 2 +- lib/zlib/inflate.c | 8 +-- net/net.c | 2 +- post/cpu/mpc83xx/ecc.c | 2 +- post/drivers/memory.c | 36 +++++------ post/lib_powerpc/cpu.c | 16 ++--- post/lib_powerpc/fpu/fpu.c | 4 +- post/post.c | 4 +- test/common/cyclic.c | 2 +- test/dm/wdt.c | 9 +-- 108 files changed, 306 insertions(+), 333 deletions(-)
On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote:
Hi Tom,
please pull the following watchdog related patches:
- Migrate watchdog reset to cyclic infrastructure (Stefan)
Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260&view=resu...
Thanks, Stefan
The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852:
Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 17:02:52 -0400)
are available in the Git repository at:
git@source.denx.de:u-boot/custodians/u-boot-watchdog.git next
for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8:
watchdog: Further cleanup (2022-09-16 07:09:05 +0200)
Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup
Good bad news, I've got your first hardware failure report. One of these three: cyclic: Use schedule() instead of WATCHDOG_RESET() cyclic: Introduce schedule() function watchdog: Integrate watchdog triggering into the cyclic framework
Causes am335x_evm to have no output in SPL and just hang. It, along with all of the other TI AM335x platforms have watchdog enabled in SPL. I can also observe that the system watchdog is not triggering, so maybe we're stuck in some loop where that's being serviced still?
I suspect all the am335x boards are broken, so if you don't have something there you can test on let me know off-list and I'll get you access to my lab.
On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote:
On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote:
Hi Tom,
please pull the following watchdog related patches:
- Migrate watchdog reset to cyclic infrastructure (Stefan)
Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260&view=resu...
Thanks, Stefan
The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852:
Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 17:02:52 -0400)
are available in the Git repository at:
git@source.denx.de:u-boot/custodians/u-boot-watchdog.git next
for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8:
watchdog: Further cleanup (2022-09-16 07:09:05 +0200)
Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup
Good bad news, I've got your first hardware failure report. One of these three: cyclic: Use schedule() instead of WATCHDOG_RESET() cyclic: Introduce schedule() function watchdog: Integrate watchdog triggering into the cyclic framework
Causes am335x_evm to have no output in SPL and just hang. It, along with all of the other TI AM335x platforms have watchdog enabled in SPL. I can also observe that the system watchdog is not triggering, so maybe we're stuck in some loop where that's being serviced still?
I suspect all the am335x boards are broken, so if you don't have something there you can test on let me know off-list and I'll get you access to my lab.
I'll note that pine64_plus_defconfig is now also failing, but interestingly dra7xx_evm_defconfig is passing.
Hi Tom,
On 16.09.22 16:21, Tom Rini wrote:
On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote:
On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote:
Hi Tom,
please pull the following watchdog related patches:
- Migrate watchdog reset to cyclic infrastructure (Stefan)
Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260&view=resu...
Thanks, Stefan
The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852:
Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 17:02:52 -0400)
are available in the Git repository at:
git@source.denx.de:u-boot/custodians/u-boot-watchdog.git next
for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8:
watchdog: Further cleanup (2022-09-16 07:09:05 +0200)
Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup
Good bad news, I've got your first hardware failure report. One of these three: cyclic: Use schedule() instead of WATCHDOG_RESET() cyclic: Introduce schedule() function watchdog: Integrate watchdog triggering into the cyclic framework
Causes am335x_evm to have no output in SPL and just hang. It, along with all of the other TI AM335x platforms have watchdog enabled in SPL. I can also observe that the system watchdog is not triggering, so maybe we're stuck in some loop where that's being serviced still?
I suspect all the am335x boards are broken, so if you don't have something there you can test on let me know off-list and I'll get you access to my lab.
I'll note that pine64_plus_defconfig is now also failing, but interestingly dra7xx_evm_defconfig is passing.
Thanks for all your testing Tom. I'll check, if I still have an AM355x here. I just now found an Cubieboard2, which also seems to have SPL watchdog enabled. Let me check, if I can get this board running and tested.
If all fails, I'll get back to you with the offer to access your HW.
Thanks, Stefan
Hi Tom,
On 16.09.22 16:37, Stefan Roese wrote:
Hi Tom,
On 16.09.22 16:21, Tom Rini wrote:
On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote:
On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote:
Hi Tom,
please pull the following watchdog related patches:
- Migrate watchdog reset to cyclic infrastructure (Stefan)
Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260&view=resu...
Thanks, Stefan
The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852:
Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 17:02:52 -0400)
are available in the Git repository at:
git@source.denx.de:u-boot/custodians/u-boot-watchdog.git next
for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8:
watchdog: Further cleanup (2022-09-16 07:09:05 +0200)
Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup
Good bad news, I've got your first hardware failure report. One of these three: cyclic: Use schedule() instead of WATCHDOG_RESET() cyclic: Introduce schedule() function watchdog: Integrate watchdog triggering into the cyclic framework
Causes am335x_evm to have no output in SPL and just hang. It, along with all of the other TI AM335x platforms have watchdog enabled in SPL. I can also observe that the system watchdog is not triggering, so maybe we're stuck in some loop where that's being serviced still?
I suspect all the am335x boards are broken, so if you don't have something there you can test on let me know off-list and I'll get you access to my lab.
I'll note that pine64_plus_defconfig is now also failing, but interestingly dra7xx_evm_defconfig is passing.
Thanks for all your testing Tom. I'll check, if I still have an AM355x here. I just now found an Cubieboard2, which also seems to have SPL watchdog enabled. Let me check, if I can get this board running and tested.
Cubieboard2 does not really use the watchdog in U-Boot and especially not very early (SPL). So no help here. But I figured out a potential problem that might explain you system hang. Could you please give the attached patch a try and let me know, if this changes the situation a bit?
Thanks, Stefan
On Fri, Sep 16, 2022 at 09:12:54PM +0200, Stefan Roese wrote:
Hi Tom,
On 16.09.22 16:37, Stefan Roese wrote:
Hi Tom,
On 16.09.22 16:21, Tom Rini wrote:
On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote:
On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote:
Hi Tom,
please pull the following watchdog related patches:
- Migrate watchdog reset to cyclic infrastructure (Stefan)
Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260&view=resu...
Thanks, Stefan
The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852:
Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 17:02:52 -0400)
are available in the Git repository at:
git@source.denx.de:u-boot/custodians/u-boot-watchdog.git next
for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8:
watchdog: Further cleanup (2022-09-16 07:09:05 +0200)
Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup
Good bad news, I've got your first hardware failure report. One of these three: cyclic: Use schedule() instead of WATCHDOG_RESET() cyclic: Introduce schedule() function watchdog: Integrate watchdog triggering into the cyclic framework
Causes am335x_evm to have no output in SPL and just hang. It, along with all of the other TI AM335x platforms have watchdog enabled in SPL. I can also observe that the system watchdog is not triggering, so maybe we're stuck in some loop where that's being serviced still?
I suspect all the am335x boards are broken, so if you don't have something there you can test on let me know off-list and I'll get you access to my lab.
I'll note that pine64_plus_defconfig is now also failing, but interestingly dra7xx_evm_defconfig is passing.
Thanks for all your testing Tom. I'll check, if I still have an AM355x here. I just now found an Cubieboard2, which also seems to have SPL watchdog enabled. Let me check, if I can get this board running and tested.
Cubieboard2 does not really use the watchdog in U-Boot and especially not very early (SPL). So no help here. But I figured out a potential problem that might explain you system hang. Could you please give the attached patch a try and let me know, if this changes the situation a bit?
Thanks, Stefan
From 3788aadff5d697e3e150a9e520915007f7a26def Mon Sep 17 00:00:00 2001 From: Stefan Roese sr@denx.de Date: Fri, 16 Sep 2022 21:08:51 +0200 Subject: [PATCH] cyclic: Only call cyclic_run() from schedule() when it's ready
schedule() might get called very early in the boot process (SPL etc), when the cyclic IF is not initialized. Let's make sure, that we only call into cyclic_run() when it's ready.
Signed-off-by: Stefan Roese sr@denx.de
common/cyclic.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/common/cyclic.c b/common/cyclic.c index 594f9cd92592..9cdbed4ecc92 100644 --- a/common/cyclic.c +++ b/common/cyclic.c @@ -104,7 +104,12 @@ void schedule(void) if (IS_ENABLED(CONFIG_HW_WATCHDOG)) hw_watchdog_reset();
- cyclic_run();
- /*
* schedule() might get called very early before the cyclic IF is* ready. Make sure to only call cyclic_run() when it's initalized.*/- if (gd->cyclic->cyclic_ready)
cyclic_run();}
int cyclic_uninit(void)
No change.
Hi Tom,
On 16.09.22 21:22, Tom Rini wrote:
On Fri, Sep 16, 2022 at 09:12:54PM +0200, Stefan Roese wrote:
Hi Tom,
On 16.09.22 16:37, Stefan Roese wrote:
Hi Tom,
On 16.09.22 16:21, Tom Rini wrote:
On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote:
On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote:
Hi Tom,
please pull the following watchdog related patches:
- Migrate watchdog reset to cyclic infrastructure (Stefan)
Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260&view=resu...
Thanks, Stefan
The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852:
Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 17:02:52 -0400)
are available in the Git repository at:
git@source.denx.de:u-boot/custodians/u-boot-watchdog.git next
for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8:
watchdog: Further cleanup (2022-09-16 07:09:05 +0200)
Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup
Good bad news, I've got your first hardware failure report. One of these three: cyclic: Use schedule() instead of WATCHDOG_RESET() cyclic: Introduce schedule() function watchdog: Integrate watchdog triggering into the cyclic framework
Causes am335x_evm to have no output in SPL and just hang. It, along with all of the other TI AM335x platforms have watchdog enabled in SPL. I can also observe that the system watchdog is not triggering, so maybe we're stuck in some loop where that's being serviced still?
I suspect all the am335x boards are broken, so if you don't have something there you can test on let me know off-list and I'll get you access to my lab.
I'll note that pine64_plus_defconfig is now also failing, but interestingly dra7xx_evm_defconfig is passing.
Thanks for all your testing Tom. I'll check, if I still have an AM355x here. I just now found an Cubieboard2, which also seems to have SPL watchdog enabled. Let me check, if I can get this board running and tested.
Cubieboard2 does not really use the watchdog in U-Boot and especially not very early (SPL). So no help here. But I figured out a potential problem that might explain you system hang. Could you please give the attached patch a try and let me know, if this changes the situation a bit?
Thanks, Stefan
From 3788aadff5d697e3e150a9e520915007f7a26def Mon Sep 17 00:00:00 2001 From: Stefan Roese sr@denx.de Date: Fri, 16 Sep 2022 21:08:51 +0200 Subject: [PATCH] cyclic: Only call cyclic_run() from schedule() when it's ready
schedule() might get called very early in the boot process (SPL etc), when the cyclic IF is not initialized. Let's make sure, that we only call into cyclic_run() when it's ready.
Signed-off-by: Stefan Roese sr@denx.de
common/cyclic.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/common/cyclic.c b/common/cyclic.c index 594f9cd92592..9cdbed4ecc92 100644 --- a/common/cyclic.c +++ b/common/cyclic.c @@ -104,7 +104,12 @@ void schedule(void) if (IS_ENABLED(CONFIG_HW_WATCHDOG)) hw_watchdog_reset();
- cyclic_run();
/*
* schedule() might get called very early before the cyclic IF is* ready. Make sure to only call cyclic_run() when it's initalized.*/if (gd->cyclic->cyclic_ready)
cyclic_run();}
int cyclic_uninit(void)
No change.
Thanks for testing. I do have one last experiment for tonight. Please give the attached v2 a try.
Thanks, Stefan
On Fri, Sep 16, 2022 at 09:46:49PM +0200, Stefan Roese wrote:
Hi Tom,
On 16.09.22 21:22, Tom Rini wrote:
On Fri, Sep 16, 2022 at 09:12:54PM +0200, Stefan Roese wrote:
Hi Tom,
On 16.09.22 16:37, Stefan Roese wrote:
Hi Tom,
On 16.09.22 16:21, Tom Rini wrote:
On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote:
On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote:
> Hi Tom, > > please pull the following watchdog related patches: > > ---------------------------------------------------------------- > - Migrate watchdog reset to cyclic infrastructure (Stefan) > ---------------------------------------------------------------- > > Here the Azure build, without any issues: > > https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260&view=resu... > > > Thanks, > Stefan > > The following changes since commit > 6ec7207ab3c4dad098967fef5df75e25240fd852: > > Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 > 17:02:52 -0400) > > are available in the Git repository at: > > git@source.denx.de:u-boot/custodians/u-boot-watchdog.git next > > for you to fetch changes up to > 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8: > > watchdog: Further cleanup (2022-09-16 07:09:05 +0200) > > ---------------------------------------------------------------- > Stefan Roese (6): > watchdog: Integrate watchdog triggering into the > cyclic framework > cyclic: Introduce schedule() function > cyclic: Use schedule() instead of WATCHDOG_RESET() > watchdog: Get rid of ASSEMBLY hacks > watchdog: Remove WATCHDOG_RESET macro > watchdog: Further cleanup
Good bad news, I've got your first hardware failure report. One of these three: cyclic: Use schedule() instead of WATCHDOG_RESET() cyclic: Introduce schedule() function watchdog: Integrate watchdog triggering into the cyclic framework
Causes am335x_evm to have no output in SPL and just hang. It, along with all of the other TI AM335x platforms have watchdog enabled in SPL. I can also observe that the system watchdog is not triggering, so maybe we're stuck in some loop where that's being serviced still?
I suspect all the am335x boards are broken, so if you don't have something there you can test on let me know off-list and I'll get you access to my lab.
I'll note that pine64_plus_defconfig is now also failing, but interestingly dra7xx_evm_defconfig is passing.
Thanks for all your testing Tom. I'll check, if I still have an AM355x here. I just now found an Cubieboard2, which also seems to have SPL watchdog enabled. Let me check, if I can get this board running and tested.
Cubieboard2 does not really use the watchdog in U-Boot and especially not very early (SPL). So no help here. But I figured out a potential problem that might explain you system hang. Could you please give the attached patch a try and let me know, if this changes the situation a bit?
Thanks, Stefan
From 3788aadff5d697e3e150a9e520915007f7a26def Mon Sep 17 00:00:00 2001 From: Stefan Roese sr@denx.de Date: Fri, 16 Sep 2022 21:08:51 +0200 Subject: [PATCH] cyclic: Only call cyclic_run() from schedule() when it's ready
schedule() might get called very early in the boot process (SPL etc), when the cyclic IF is not initialized. Let's make sure, that we only call into cyclic_run() when it's ready.
Signed-off-by: Stefan Roese sr@denx.de
common/cyclic.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/common/cyclic.c b/common/cyclic.c index 594f9cd92592..9cdbed4ecc92 100644 --- a/common/cyclic.c +++ b/common/cyclic.c @@ -104,7 +104,12 @@ void schedule(void) if (IS_ENABLED(CONFIG_HW_WATCHDOG)) hw_watchdog_reset();
- cyclic_run();
- /*
* schedule() might get called very early before the cyclic IF is* ready. Make sure to only call cyclic_run() when it's initalized.*/- if (gd->cyclic->cyclic_ready)
cyclic_run();No change.
Thanks for testing. I do have one last experiment for tonight. Please give the attached v2 a try.
Thanks, Stefan
From 2f61bc2cf011190eedbc0be34b4d61f342e7e5a5 Mon Sep 17 00:00:00 2001 From: Stefan Roese sr@denx.de Date: Fri, 16 Sep 2022 21:08:51 +0200 Subject: [PATCH v2] cyclic: Only call cyclic_run() from schedule() when it's ready
schedule() might get called very early in the boot process (SPL etc), when the cyclic IF is not initialized. Let's make sure, that we only call into cyclic_run() when it's ready.
Signed-off-by: Stefan Roese sr@denx.de
common/cyclic.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/common/cyclic.c b/common/cyclic.c index 594f9cd92592..b3c180bd1a62 100644 --- a/common/cyclic.c +++ b/common/cyclic.c @@ -104,7 +104,12 @@ void schedule(void) if (IS_ENABLED(CONFIG_HW_WATCHDOG)) hw_watchdog_reset();
- cyclic_run();
- /*
* schedule() might get called very early before the cyclic IF is* ready. Make sure to only call cyclic_run() when it's initalized.*/- if (gd && gd->cyclic && gd->cyclic->cyclic_ready)
cyclic_run();}
int cyclic_uninit(void)
This worked and both boards that failed before now pass.
Hi Tom,
On 16.09.22 23:48, Tom Rini wrote:
<snip>
Thanks for testing. I do have one last experiment for tonight. Please give the attached v2 a try.
Thanks, Stefan
From 2f61bc2cf011190eedbc0be34b4d61f342e7e5a5 Mon Sep 17 00:00:00 2001 From: Stefan Roese sr@denx.de Date: Fri, 16 Sep 2022 21:08:51 +0200 Subject: [PATCH v2] cyclic: Only call cyclic_run() from schedule() when it's ready
schedule() might get called very early in the boot process (SPL etc), when the cyclic IF is not initialized. Let's make sure, that we only call into cyclic_run() when it's ready.
Signed-off-by: Stefan Roese sr@denx.de
common/cyclic.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/common/cyclic.c b/common/cyclic.c index 594f9cd92592..b3c180bd1a62 100644 --- a/common/cyclic.c +++ b/common/cyclic.c @@ -104,7 +104,12 @@ void schedule(void) if (IS_ENABLED(CONFIG_HW_WATCHDOG)) hw_watchdog_reset();
- cyclic_run();
/*
* schedule() might get called very early before the cyclic IF is* ready. Make sure to only call cyclic_run() when it's initalized.*/if (gd && gd->cyclic && gd->cyclic->cyclic_ready)
cyclic_run();}
int cyclic_uninit(void)
This worked and both boards that failed before now pass.
Perfect. Thanks again for testing.
I'll re-spin v2 of the patchset with this patch squashed in, so that git bisect'ing will work.
Thanks, Stefan
participants (2)
-
Stefan Roese -
Tom Rini