I'm bringing up a custom STM32MP15x-based design, and I'm encountering what looks like stack corruption issues in U-Boot (and I can't get a kernel to boot).
Symptoms:
I've enabled early debug printing, and get the following output:
U-Boot SPL 2020.04-stm32mp-r1 (Aug 15 2020 - 13:11:31 -0500)
Model: STMicroelectronics STM32MP157A-DK1 Discovery Board
RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.45
Trying to boot from MMC1
At this point, the console hangs for a really long time. Looking at the UART on a logic analyzer, I see that during this time, it's printing seemingly gibberish characters at 1750 baud (which my USB-to-serial converter is ignoring due to the framing errors caused by the wrong baud).
I did some brief JTAG investigations, and somewhere along the way, something calls printf() on a character buffer that's corrupted (so it doesn't encounter a null-terminating character for a very, very, very long time).
Eventually, it will print something like this:
▒▒*aQ▒rrr▒In: serial
Out: serial
Err: serial
Enter fastboot!
invalid MAC address in OTP 00:00:00:00:00:00
board_check_usb_power: Can't get adc device(-19)
Net: No ethernet found.
No USB device found
USB init failed: -19
Hit any key to stop autoboot: 0
Boot over mmc0!
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:4...
Unknown command 'test▒t▒▒t▒▒▒t▒▒▒' - try 'help'
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
131 bytes read in 18 ms (6.8 KiB/s)
1: stm32mp157a-dk1-buildroot
Retrieving file: /boot/zImage
4158848 bytes read in 200 ms (19.8 MiB/s)
append: root=/dev/mmcblk0p4 rootwait
Retrieving file: /boot/stm32mp157a-dk1.dtb
44188 bytes read in 19 ms (2.2 MiB/s)
## Flattened Device Tree blob at c4000000
Booting using the fdt blob at 0xc4000000
Loading Device Tree to cfff2000, end cffffc9b ... OK
Starting kernel ...
At this point, it hangs and doesn't do anything else.
Sometimes it finds all the environmental variables and attempts to boot the kernel, sometimes it doesn't. Either way, it often complains about bad filesystems, gibberish character names for things, etc.
I can poke around with my J-Link some more, but it looks like RAM is corrupted.
However, after enabling the (supposedly fancier) new memtest in buildroot, I tested 0xC0000000 to 0xDD000000 for hundreds of iterations without a single reported problem (If I test higher than that, I think I start running into U-Boot).
About the board:
My goal is to to throw together the simplest break-out board possible, so I've got VDD_CORE and VDDQ_DDR tied to a 1.35V 2A buck converter, and VDD at 3.3V via a 600 mA LDO. I'm using the internal 1.8V, 1.1V, and 1.2V regulator. I'm using the STM32MP157A-DK1 U-boot / DTS config, modified to eliminate the PMIC. I have the identical Micron memory part mounted to the board.
- DDR Bank 0 is 1004-1014 mil long
- DDR Bank 1 is 1120-1126 mil long
- ADDR/CMD ranges from 592 to 711mil long
- DDR CLK is 1062 mil long
Known issues
- I think DDR_CLK is supposed to be the longest route on the board --- but it's 60 mil shorter than Bank 1. Is that really a problem? None of these length differences seem significant at 533 MHz, and my mtest in U-Boot showed no errors.
- I realized after the fact that VDD3V3_USBHS is only supposed to appear after VDDA_1V8, but I've got it wired directly to 3.3V. I understand it could damage the USB PHY on the processor and I plan to fix that on my next version, but that wouldn't affect the behavior I'm seeing, correct?
- My MMC bus isn't length-tuned, and varies from about 900 to 1180 mil. Again, that doesn't seem relevant at the frequencies I'm operating my SD card at.
Any ideas of where to look next? Because the DRAM seems to check out, I'm thinking it's a power delivery issue. I've added quite a bit of bulk capacitance (five or six 10 uF caps) around the processor and RAM, but that doesn't seem to do much of anything.
