I'm bringing up a custom A33-based design as a blog / hobby project, and I'm getting some strange behavior that looks like stack memory corruption.
U-Boot will throw interesting warnings like Loading Environment from FAT... ** Invalid partition type "U-Boot▒o▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒" (expect "U-Boot") Next, if I run printenv, it will only print the first 12 environmental variables before finishing up with "Environment size: 4442/131068 bytes" I know that other environmental variables are set, even if they're not printed, since I can ask it to printenv bootcmd for example, and it returns the correct string. I've also noticed that when a command finishes and I'm returned to the U-Boot prompt, the prompt already has the first character of the last command I executed. It's very bizarre. I wouldn't be bothered by any of this if the system actually booted into Linux fine, but the system hangs on "Starting Linux..." so it looks like there's some underlying issues that I need to work out here first. I've tested this same microSD card on an Olinuxino A33, and it boots into Linux fine, and doesn't show any of this odd behavior. I assumed my RAM was to blame, so I activated the new memtest in U-Boot and ran mtest 0x40000000 0xb9000000 and it has run for more than 900 iterations without any issues. If I try to test it all the way up to 0xC0000000 I get errors, but I assume U-Boot is using the end of the memory (I verified that an Olinuxino A33 has the same behavior when attempting to memtest the entire DRAM). And, in practice, the DRAM seems to work. Just as the boot script does, I loaded zImage to 0x46000000. Then I used md.b to display the first 1000 bytes and they're an exact match with the zImage I wrote to the card. Either way, just to be sure, I tried reducing my DRAM clock to 333 MHz, as well as reducing my 1 GHz core clock to that speed as well, and that hasn't improved anything. Hardware info: I have a 16 Gb (2 GB) dual-rank DDR3L-1600 chip soldered down (datasheet PDF link <http://www.issi.com/WW/pdf/43-46TR16K01S2A-AL.pdf>). I'm running the system with no PMIC, and just powering VDD_CPU, VDD_CPUS, VDD_SYS, VCC_DRAM, and VCC_HSIC off a 1.35V buck converter (while providing a 2.5V LDO for VDD_DLL and 3.3V LDO for the other supplies). I don't have any explicit power sequencing. I've completely disabled the PMIC code in Kconfig, and I've verified that there are no attempted I2C transactions on the bus using a logic analyzer, so I know the kernel isn't hanging at some weird point trying to initialize the PMIC or something. Does anyone have any ideas of where to look to investigate this further? -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/cebc035a-f2f3-44f6-9e7c-2dcc54f155ado%40googlegroups.com.
