On custom hardware using an OSD3358-512-BCB, we are having some issues. Our kernel is the 5.10.56-bone-rt48 kernel from Robert Nelson (with a couple auxiliary patches which are demonstrably unrelated), and we are using u-boot 2021.07. This issue is very similar to my previous post (https://forum.digikey.com/t/am3358-based-board-will-not-reboot-no-issue-with-cold-boot), but I have more information and have been unable to fix it this time. Here’s the situation:
First, I found out that we had weird intermittent boot issues (every now and again it wouldn’t properly reboot). This seemed to be fixed by disabling falcon mode in u-boot, so we were happy with that. Then, I realized that u-boot was setting the system to OPP turbo (I believe that’s the one-whichever it is, it’s the 800MHz option). This appears to be because the efuse in the OSD3358 reports strange information (a known issue) and u-boot determines the system max is 800MHz instead of 1GHz, which we know it’s capable of. My initial thought was that u-boot doesn’t really need to be running very fast, so we’d be fine leaving it at 800MHz. Instead, I enabled CPU frequency scaling in Linux with a default governor of “performance,” which achieved our goal of 1GHz.
This seemed fine, but then a while later I tried a warm restart (using the
reboot command in Linux) I noticed that the system just hangs. The SPL never prints its version message, but it appears the kernel is properly shutting down (I am not entirely sure how to test this, but according to the code I have read in the kernel for shutdown on the AM3358, it should be printing an error to the UART console if shutdown fails). The console goes silent after the kernel’s final messages, then nothing happens. It’s clear that the hardware is being reset, as our LEDs are reset to their POR states (which does not happen under Linux, as the Linux device tree disables them at boot, while they’re on at cold start). It appears that u-boot does not get along with CPU frequency scaling. However, when I manually changed the governor to “userspace” and set a target frequency of 800MHz, it also failed to reboot, suggesting that something to do with cpufreq is causing the problem.
I have tried some modifications to u-boot in all the places I can think of, including (but not limited to):
- Using the internal RTC 32K OSC instead of external (and the corresponding change in Linux, of course)
MPUPLL_M_1000in all cases
- Changing board/ti/am335x/board.c to use
MPUPLL_M_1000everywhere that the Pocketbeagle does (
scale_vcores_bone(), and then
scale_vcores()for good measure)
The RTC OSC change had no effect and the second and third seem to have inconsistent results–sometimes a complete failure to boot, sometimes getting part of the way through the boot process before hanging, etc. I have tried enabling more logging in u-boot, but it doesn’t reveal anything useful, the bootloader just hangs randomly at some point during boot each time.
If anyone has any ideas, I’m all ears. We are using the pocketbeagle device tree, though with the addition of
tick-timer = &timer2; and changing stdout to uart5. Previously we were using the am335x-evm device tree, and it seemed to be more broken, but I am not entirely sure why yet.