ast2400 console problems with v2016.05-aspeed-openbmc

[bradbishop]

With a default u-boot environment on Palmetto everything is fine after POR. But if you do a reboot -f you don't get any console output until the kernel starts again.

Also, does the ast2400 DT need a chosen update to reflect the new 115200 default?

[mdmillerii]

The equivalent of 4b44678c11ac82c7c797bb115e276181752ad54d in the v2013.07-aspeed-openbmc branch was not applied to the v2016.05-aspeed-openbmc branch. Without this patch the uart is initialized only when the scratch register says the MPLL needs to be initialized (and presumably all of dram setup).

Are we reseting the SIO with the watchdog in our reset handler?

It was mentioned to me 4b44678c11ac82c7c797bb115e276181752ad54d was not just code movement, but also added a write to 0x1e6e202c of 0x00000010 (the documented reset value) which forces the div13 bit off in the divider. At first I thought this was related but it is more likely to be the setup of the uart hapening at all.

Why do we set this in the kernel and device-tree? Why not change the reference clock in linux to 24MHz?

Also supposedly the environment is accessed read-only very early to get the baud rate but this low level assembly is using #ifdef CONFIG_DRAM_UART to set the rate here very very early.

[shenki]

I can add the patch as people are hitting the no-uart after rebooting issue.

I'm not quite following what @mdmillerii's concern is? Is it something we need to fix before I apply this patch, or a future enhancement we should make?

[legoater]

@shenki : here is a port of the patch on latest u-boot [https://github.com/legoater/u-boot/commit/b9905fb04006120396a154f21a1b8a843014c658]. I gave it some test on a palmetto and it behaves fine. Disabling D2-PLL seems to be critical at boot time.

[shenki]

Thanks. Can you please send that to the list for inclusion? I will merge it on my Friday

[shenki]

This patch has been merged and is part of master