Part Number: AM3352
Tool/software: Linux
So I have a custom board on AM3352 SoC which is similar to BeagleBone. In fact my vendor gave me some step-by-step instruction for board bring-up which totally works. Still the bad thing is it uses an old version of U-Boot (v2014.10). This one was a total mainline version but a small patch to parse a custom board ID within EEPROM, and am335x_evm_defconfig config was used. Compiled with gcc-linaro-4.8-2014.4 compiler. Everything is perfect.
Then I try to migrate on the newest version of U-Boot. Download mainline, compile master branch (also tried few others which are just some random ones: v2018.7, v2017.11) with gcc-linaro-6.2.1 (also tried 7.2.1), still using am335x_evm_defconfig. Put my MLO image to SDcard and try to boot. Power up, but console is totally silent, not even a small "C" printed. The same hardware with the same console works well with just an old version of MLO put to the same SDcard. Also no vendor patch applied as it totally incompatible with the newer version of U-Boot. But as far as I can see the only sense it makes is configuring SDRAM with appropriate params. Which doesn't anyhow imply UART to be broken. I would rather check if I2C is working too with an ocsi, but unfortunately I don't have it's lines on motherboard's pin-header and the EEPROM IC is on the side of board which is pointed to the motherboard so no physical contact.
And here I have no ideas on how to degug it and what is even probably the case. I tried on blaming my compiler, but no way to check it. Older version of U-Boot gets compilation errors with a newer compiler but the newer version of U-Boot says it won't build with an old compiler. Viewed a lot of U-Boot hacking/porting guides, read all the mans I could find. Still nothing even close to my problem. Would really appreciate any kind of help.
UPD. So not to blame this vendor patch I mentioned. Downloaded mainline, checkout for v2014.10, then make %CC and ARCH% am335x_evm_defconfig; make %CC and ARCH%. Console is fine.
