It may be that the UART0 RX signal is accidentally floating, or something is pulling it to an indeterminate logic state. To check, try connecting a strong pull-up resistor (the relevant power rail is board-dependent of course) and see if the issue still appears.
It could be helpful to know whether you’re using an off-the-shelf or custom board. (For instance, by “nothing connected”, do you mean there are absolutely no components on the board connected to the RX pin?)
That last line (“STM32MP>”) at the end is the U-Boot interactive prompt. It has stopped just before loading the kernel, presumably because it thinks it was interrupted by a keypress (“Hit any key to stop autoboot”). Since you see this when connected to UART, yet when not connected it progresses past here and you see the kernel heartbeat, something might be wrong with the TX side (PC/RPi to OSD32MP1) of your UART that is causing some character to be accidentally/continuously sent. This would also explain why your keyboard input is not working properly.
Try using only the RX side of the UART (OSD32MP1 to PC/RPi) and leaving TX unconnected.
After booting, the common way to get a console over USB is to configure it as a device (a USB “gadget” in Linux) using RNDIS in order to get Ethernet, and then SSH in from there. This is totally an OS-level thing and has nothing to do with boot. For example, OpenSTLinux configures this by default. This is of course convenient for software development after boot, but will not provide you a console earlier in the boot process. I am not aware of a way to get an earlier console over just USB, and I would think it is not very advisable to design a board without access to UART (at least on test pads) for debugging during the boot process.
It seems to me that an intermittent issue with the boot device would cause the boot ROM to fall back into serial DFU mode even if the boot pins are strapped correctly. According to ST’s ROM code overview on their wiki, if the FSBL cannot be loaded, in basically every configuration you will fall through to serial boot (UART or USB DFU). So the following things come to mind:
– Have you tried a different SD card?
– For issues with a custom board, have you checked the SD interface with a scope or logic analyzer to see if it looks like the ROM is trying and failing to load the FSBL from the card?
– Especially with a custom board, what do you see on the UART when you are trying to boot?
According to that wiki page, there’s no way to instruct the device to exit DFU mode once you’re there. You have to do a reset and get the ROM code to first read the correct strap pins (which I would bet is probably working fine), and then load the FSBL successfully (which I believe could fail due to various minor issues with the SD/MMC device itself or its interface).
I remember seeing exceptions like this a while ago as a result of bad devicetrees (with incorrect syntax/semantics and such). I assume you’re using a custom device tree as well, so that’d be the first thing I would check. However, I’m not knowledgeable about devicetree debugging and I would suppose that there are other causes of a message of this sort, given how generic it seems to be.
Just came across this thread – this patch might be relevant: http://u-boot.10912.n7.nabble.com/PATCH-v2-0-9-stm32mp1-use-OPP-information-for-PLL1-settings-in-SPL-td413606.html
Of course, if you feel like breaking the rules you can directly tweak PLL1 settings in the device tree. Last year I checked my STM32MP157C-DK2 just for fun: it was stable up to 1.05GHz without any change to the core voltage.
Thank you, that makes sense. The only thing I am not sure about is the initial configuration of Buck3. If the SiP is on a board with VDD tied to VDDA1V8_REG, at first wouldn’t 3.3V be applied to VDDA1V8_REG as that is the default setting of Buck3?
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields