This is not just with the bps speed on the client side.
Today I've hooked up one of my board to uart, to do some advanced tests and was surprised that the output is not completely clean 115200bps.
I'm used to see a tiny powerup glitch, but this much more then expected.
My board is booting fine and this is what I get on uart:
dL<88<<88<<88<88x<88p<<88x<88q<<88x<88p<<88q<<88q<<888p<<8dYyt4y55]y5pt4YyyYtYYtYy5qt5]yt5YYt5xTYYYy5t5y5t5YYt4ypt5yYT4YYxYY5yTYyYTY]xtYYt5YyYTYYyt4yyYTYYY5YyTyYt5YyYt5YYt5ypt5YYxt5Yy5y5xxYYt5y
U-Boot 2012.10-00003-g792c31c (Jan 03 2014 - 12:24:08)
I2C: ready
DRAM: 992 MiB
WARNING: Caches not enabled
MMC: SDHCI: 0
SF: Detected N25Q128 with page size 64 KiB, total 16 MiB
In: serial
Out: serial
Err: serial
Net: zynq_gem
Hit any key to stop autoboot: 0
Configuring PL and Booting Linux...
Device: SDHCI
Manufacturer ID: 82
OEM: 4a54
Name: NCard
Tran Speed: 50000000
Rd Block Len: 512
SD version 2.0
High Capacity: Yes
Capacity: 7.4 GiB
Bus Width: 4-bit
reading parallella.bit.bin
...
You clearly see that something glibberisch is send before something is send in 115200 bps.
However - the u-boot output is also send without an SD card inserted - unless that gliberisch stopped your terminal from printing, which my xterm fortunately didn't.
I've tried a few standard bps rates, but couldn't read the first bit pattern.
Will try to get it on scope later today to measure what frequency it is.