-
Notifications
You must be signed in to change notification settings - Fork 21
CM4 does not reboot #188
Comments
ping @timg236 in case this is an issue with the EEPROM. |
hmm ... how do I know if this is an issue with the EEPROM? |
Why would the host OS make any difference to the bootloader? |
Sorry Tim, I thought that after you do a |
Yes, @lurch the kernel reboot driver optionally sets the partition number in PM_RSTS then uses the 2711 watchdog to reset the chip. It's possible that systemd etc isn't invoking the reboot. However, more likely, the custom carrier board is getting something wrong in terms of the reset power sequencing so the ROM never runs The first things that the second stage bootloads does are clearing the GPIO which turns off the power LED and enables the activity LED. It then reads the EEPROM and if BOOT_UART=1 it will output the first log message. If there's no UART log activity either the reboot didn't happen or there is a hardware issue on the board coming out of reset. We do 1000s of reboots on CM4 IO boards with various flavours of CM4 boards so we'd need to see a log showing that the bootloader is running and then failing. |
Ok, could someone please explain me how to produce such a logfile? |
One thing I forgot to mention ... I just updated the OS to bullseye (Debian 11), although it is not officially supported. The problem occurred also with buster (Debian 10), therefore I think, this makes no difference. |
You need a USB serial cable |
... lot of stuff to read .... |
I'd recommend reading the Compute Module forums |
Ah, thank you! |
finally got it ... |
Because it's not obvious to me, is this a CM4 with onboard EMMC or is it a Lite? |
oh, excuse me, this is a Lite |
Looking at the log I can see that kernel is triggering a reboot:
After the watchdog reset, the bootloader sees that the SD card voltage is still at 1.8V and triggers a global reset:
On boards with a dedicated power switch for the SD card (of which CM4 is one). the firmware is supposed to power off the card before rebooting. But in the case of the CM4 the firmware doesn't know about the voltage switch because it isn't on the CM4 - it's on the CM4IO board - and then it's only relevant on the Lite version because the onboard EMMC is driven by the 1V8 rail from the PMIC. The questions therefore are:
|
ping @dp111 |
In trying to recreate this issue the SD card isn't switching to 1.8V. More investigation required. |
Please let me know if I can add anything to it! |
I've switched to a different card (even though the old card was running at 1.8V on a 4B), and now its running at 1.8V on CM4L. And it's rebooting successfully:
So although the global reset shouldn't be necessary, it is working correctly in 64- and 32-bit modes. |
What additional hardware to have connected to the CM4+IO? Have you installed a custom dt-blob.bin or similar? |
to whom is this question addressed? |
To the person for whom rebooting isn't working, i.e. you. |
The OP's initial message mentions "CM4-IO-BASE-B" - is that one of these? https://thepihut.com/products/mini-base-board-b-for-raspberry-pi-compute-module-4 Whereas it sounds like @pelwell is testing with the standard CM4IO board? https://thepihut.com/products/raspberry-pi-compute-module-4-io-board |
yes, I use this board: https://www.waveshare.com/cm4-io-base-b.htm https://www.waveshare.com/wiki/CM4-IO-BASE-B There is just a (USB) keyboard and mouse, a network cable and a HDMI-Monitor. dtoverlay=dwc2,dr_mode=host My card looks like this: [klaus@picloud ~] sudo cat /sys/kernel/debug/mmc0/ios clock: 50000000 Hz There is no custom dt-blob.bin or similar stuff. It's just a Raspberry-Pi-OS-64bit as you can download it (and updated/upgraded to bullseye). Furthermore I upgraded the bootloader, because I thought this could help ... [klaus@picloud ~] sudo CM4_ENABLE_RPI_EEPROM_UPDATE=1 rpi-eeprom-update VL805_FW: Using bootloader EEPROM |
@dp111 What could a base board do to screw up reboot? Bouncing or noise on the RUN pin? |
@rapkin61 Just to clarify, is the 32-bit version of Raspberry Pi OS successfully able to reboot your CM4-lite and baseboard combo? |
I don't think the ARM software will have any bearing on this reboot failure. A CM4-IO-BASE-B is being ordered for testing. |
to be honest ... I never tried that. I use 64-bit software whenever possible. |
Any reason to use the 64bit software? I'm Interested for my blog post concerning the 64 bit OS, which currently measures use-cases and shows them all to be slower or the same with the 64bit OS, it would be nice to find a reason to actually use it over the 32bit one! |
I honestly don't think 32-bit will make a difference, but if you don't mind the few minutes it would take to flash and test a different card then go ahead. |
That's good to hear - it's a nice little board. By the way, the most recent firmware release (e.g. via rpi-update) includes the change to use the SD power switch, avoiding the need to power-cycle the SoC to reboot. |
Hmmm .... in case your board boots from SD card you could try using another one. It seems the problem is related to a certain type of cards ... those who use 1.8V. |
Well alright then. Switched to a SanDisk Ultra 16G (microSDHC UHS-I) and it reboots correctly. Thanks |
If it's working for you as it is, don't change anything. In my case that link made the board try to start the SD card in 1.8V mode, which is not permitted. |
As @lurch already mentioned, I seem to have a similar problem. At least I'm using the same board with the CM4. My problem Any ideas how to fix this?
The successful boot
|
sad to notice, the problem has re-occurred ... sudo reboot PM_RSTS: 0x00001020 the board hangs after the GLOABAL_RESET. |
What kind of update? Mixing apt upgrade and rpi-update is not a job for the unwary |
I only do apt upgrades - up to now I never had the need for a rpi-update |
The apt kernel and firmware come from the stable branches - this patch is too new to have made it into there. We recently pushed a minor bump to kernel and firmware in apt to fix one or two specific issues. The next release is likely to include the patch you require, but until then continue to use the trial version above. |
ah ... ok! |
Not sure if this fixes your problem, but it did mine... |
Your problem wasn't a failure to reboot, but rather the failure of an NVME drive to work after a reboot. The EEPROM change won't help with the latter. |
Thanks for the update - it fits with our understanding of the problem. |
- firmware: isp: Fix handling of different YUV colour spaces - firmware: poe_hat: Actually close the I2C handle - firmware: platform: Define DVFS modes and change default to be fixed AVS voltage - firmware: arm_loader: Auto-select 64-bit for kernel8.img See: #1193 - firmware: hdmi: Throttle auto-i2c register writes to avoid PWM audio underrun - firmware: platform: Define DVFS modes and change default to be fixed AVS voltage - firmware: arm_loader: Auto-select 64-bit for kernel8.img See: #1193 - firmware: hdmi: Throttle auto-i2c register writes to avoid PWM audio underrun - firmware: video_decode lockup handling - firmware: isp: Initialise extras to avoid vpitch being random - firmware: usb: Fix dropouts with USB ethernet gadget See: raspberrypi/linux#4084 - firmware: imx477: Allow long exposures for the binned modes. See: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=297521 - firmware: arm_dispmanx: Use ALPHA_MIX flag See: https://www.raspberrypi.org/forums/viewtopic.php?t=300769 - firmware: power: Refactor the interface to the PMICs - firmware: platform: vl805: Get BAR2 address from PCIe BAR2 registers - firmware: arm_loader: Return all borrowed DMA channels See: #1541 - firmware: hdmi_2711: Rework I2C driver to NOT use the AUTO-I2C block - firmware: gencmd: Allow groups of clocks/plls to be read together - firmware: power: Fix DA9090 under-voltage detection - firmware: NVME boot support - firmware: brfs: Fix USB bulk-read in start.elf See: Hexxeh/rpi-firmware#258 - firmware: hdmi_2711_i2c: Correct handling of start/stop codes for long read See: #1548 - firmware: video_decode: For VC1/WMV with no signalled header bytes, use start of 1st buffer See: raspberrypi/linux#4113 - firmware: vl805: Remove redundant log statement and fix warning - firmware: power: Fix DA9090 ADC1 register definition - firmware: arm_loader: Only report clocks arm has set, not siblings - firmware: arm_loader: Don't report clocks set as turbo side effect of arm clock - firmware: arm_loader: 2711: gpu clocks are not dependant - firmware: platform: Need to clear cached versions of get_max_clock_internal vars - firmware: Move core to PLLA and support accurate clk108 See: xbmc/xbmc#19263 - firmware: board_info: Separate memory size from OTP field encoding - firmware: power: Swap DA9090 ADC assignments to match XR77004 - firmware: board-info: Fix memsize on 3B+ - firmware: vcfw/power: Add a new latch for power_pad_control See: #1552 - firmware: arm_loader: kernel_old=1 should force kernel_address=0 See: #1561 - firmware: scalerlib: Fix offset applied to x coordinate of YUV10COL image See: https://forum.kodi.tv/showthread.php?tid=361164&pid=3024654#pid3024654 - firmware: isp: Ensure the VRF is locked when setting up video colour denoise See: raspberrypi/rpicam-apps#19 - firmware: isp: Remove custom EV mappings from camera tunings - firmware: Add support for board-type=0xXX conditional filters in bootloader, bootcode and firmware - firmware: Two UART1 patches See: #1566 - firmware: Pi400: Reduce MII clock freq when probing ethernet PHY - firmware: platform: Remove build-time constant for MICROVOLTS_PER_PIP - firmware: dt-blob.dts: Correct HDMI HPD and EMMC_ENABLE for CM4 See: https://www.raspberrypi.org/forums/viewtopic.php?f=29&p=1858516 - firmware: vcfw/hdmi: CUSTOM modes used for FKMS didn't set RGB quant range correctly See: #1580 - firmware: PoE+ HAT support See: raspberrypi/linux#4367 - firmware: arm_loader: Use Pi4 bootloader MAC_ADDRESS if set - firmware: platform: Apply ARM thermal throttling rules on BCM2711 - firmware: bcm_host: Recognise all Pi 4 variants, add BCM2711 See: raspberrypi/userland#695 - firmware: video_decode: Use the ISP instead of vc_image_convert - firmware: hdmi-2711: Wait for HDMI hardware scheduler to activate in HDMI mode - arm_loader: Add message to release firmware framebuffer - firmware: arm_loader: Add rng-seed DT property See: #1595 - firmware: isp: Set the YUV420/YVU420 format stride to 64 byte - firmware: Revert: video_decode: Use the ISP instead of vc_image_convert - firmware: cec: Avoid sending messages with kms See: raspberrypi/linux#4460 - firmware: hdmi_cec: Remove TX/RX SW_INIT on power_on See: Hexxeh/rpi-firmware#267 See: https://www.raspberrypi.org/forums/viewtopic.php?p=1895082#p1895082 - firmware: arm_dt: Limit CMA to 256MB if total_mem < 2GB or gpu_mem > 256MB See: #1603 - firmware: video_decode: Use the ISP instead of vc_image_convert - firmware: video_decode: Correct support for YVU formats using ISP - firmware: firmware: Disable VLL loading from file system See: #1605 - firmware: arm_loader: Make most arm clock requests required See: #1598 - firmware: arm_loader: Consider required flags from GET_CLOCK_RATE See: #1598 - firmware: arm_dt: Load overlays for detected cameras - firmware: Make more use of the user-warnings DT property - firmware: hdmi_2711: Use HDMI block REPEAT_PIXEL instead of PV See: https://forum.libreelec.tv/thread/24415-le-10-beta-for-i4-force-hdmi-resolution - firmware: DSI display autodetection for kms - firmware: arm_loader: Allow hvs interrupt during SET_NOTIFY_DISPLAY_DONE - firmware: arm_display: Allow null buffer in successful call See: raspberrypi/linux#4540 - firmware: video_decode: Ensure all buffers are flushed before port disable completes - firmware: filesystem: sdcard: Fix Hybrid GPT partitions See: #1465 - firmware: tvservice: Add check to warn when running with kms - firmware: arm_loader: Allow non-optional reads of current clock See: #1619 - firmware: dispmanx: Demote null eptr from vcos_verify to no warning See: raspberrypi/linux#4592 - firmware: filesystem: sdcard: Probe FAT type in GPT ESD partitions - firmware: clock-2711: Limit PLLB VCO frequency to the high range - firmware: arm_dt: Export the boot-mode, partition and usb state via device-tree See: #1621 - firmware: video_decode: i/p port enable/disable without o/p active could stall See: RPi-Distro/vlc#48 See: Hexxeh/rpi-firmware#272 See: #1637 - firmware: userland: Reduce debug_sym error messages See: https://forums.raspberrypi.com/viewtopic.php?f=98&t=322238 - firmware: arm_dt: Increase maximum line length to 98 See: raspberrypi/linux#4638 - firmware: arm_loader: Allow VEC clock to be controlled by arm - firmware: platform: Remove licence on VP6, VP8, Theora, and FLAC See: raspberrypi/linux#4661 - firmware: ISP: Fix magenta colour in right hand image of stereo pair See: https://forums.raspberrypi.com/viewtopic.php?t=321089 - firmware: platform: Fix incorrect turbo voltage scaling on Pi0 See: raspberrypi/documentation#2255 - firmware: platform: Declare CM4's SIO_1V8_SEL and SD_PWR_ON See: raspberrypi/Raspberry-Pi-OS-64bit#188 - firmware: hello_fft: Update outdated link to V3D spec - firmware: hello_fft: Remove unused function declaration See: #1645 See: raspberrypi/userland#710 - firmware: dtoverlay: Rebase aliases in overlays like labels - firmware: isp: Set core/vpu min clock to 320Mhz during ISP operation - firmware: arm_loader: Enable watchdog early if wanted See: #1651 - firmware: board_info: Add upstream dtb names for cm1 & 3 - firmware: board_info: Add upstream dtb name for cm4 See: #1660 - firmware: platform: Allow users to disable camera boot HMAC check See: #1657 - firmware: clock: 2711: Fix potential API issue in 2711 VCO setup - firmware: arm_loader: Enable USB MSD boot mode on Zero 2 W - firmware: isp: Fix Rec.709 colour space problems
just wanted to share that i've experienced this issue on many of my CM4's that are configured as headless servers, and most A/V behavior is tuned down or disabled (ex. perhaps |
I have a baseboard from sourcekit.cc using CM4 with 4GB RAM and 8 GB EMMC. |
Contact sourcekit.cc? |
I found and solved my problem. It's power supply. So as usual low voltage can cause various issues. It reboots and works fine when plugged to a proper 5V power. |
I've just received a rev 3.1 CM4-IO-BASE-B - thanks @me-peng - and it reboots successfully. I'm going to close the issue since I believe the points have been addressed. |
I know this topic is almost a year old but the feedback from Waveshare helped me solve my CM4 reboot problem. |
I have both CM-NANO-B and C boards and run into the same issue. The bootloader does not detect SD card (sdhc card works but sdxc card not) after reboot and it took me quite some time to get here. Good to know it's a hardware issue. Hope waveshare will fix this too. |
BTW, I revert to the old pieeprom-2020-04-16.bin as a workaround. Hope this helps. |
64 bit OS runs very well on my CM4, but reboot is not working as expected. When I enter commands like "reboot", "shutdown -r", etc the system shuts down and does not come up again. I have to disconnect power supply an re-connect it.
I'm not sure if this is an issue of the base board (I use a CM4-IO-BASE-B) or an issue of the OS.
I have already installed the latest bootloader, but that does not help either.
Reboot works well on all my "normal Raspberries", even with the 64bit OS, therefore I think it is an issue in the context of CM4 or the baseboard. I contacted the vendor of the baseboard - they say reboot works with "the latest Raspberry Pi system" ... whatever this means...
The text was updated successfully, but these errors were encountered: