Try looking over the board for a fleck of solder, tiny bit of wire strand, etc... that might have shorted something on the board, got between a couple of pins of a chip... Turn it upside down and tap it, blow it off... just in case theres a bit of something in there.
Long shot, but I've had mysterious problems end up being caused by things like that.
OP is probably not interested anymore, but for those who find the thread --
I'm seeing a similar UART behavior on D-Link DAP-1720.
U-boot is using a slightly higher baudrate (120000-8n1), which is later switched to the standard 115200-8n1, when the kernel re-initializes the console.
Putty can usually handle both baudrates at 118000.
P.S.
Found the rate using a logic analyzer (saleae clone) and sigrok:
sigrok-cli -d fx2lafw --config samplerate=24m --continuous -C D3 -P guess_bitrate:data=D3
That's so odd to me... Why would you depart from a decades old standard of baudrates, to something a little bit faster?? You bought a batch of 1 million cheap clock crystals that were way out of spec, and are trying to make it work? "Hey, the customer won't ever use the port..."??
There's a story there, that we'll probably never know...
Not even a crystal, since the kernel reconfigures the baud rate to the correct value.
Maybe a typo somewhere in the specific version of U-boot?