I think it is telling you all you need to know:
In: serial Out: serial Err: serial Machine check in kernel mode. Caused by (from msr): regs 0f778dd8 Unknown values in msr NearIP: 0FFB4CD0 XER: 00000000 LR: 0FFB4CB8 REGS: 0f778dd8 TRAP: 0200 DAR: 00000000 MSR: 00003000 EE: 0 PR: 0 FP: 1 ME: 1 IR/DR: 00 GPR00: 0FFB4CB8 0F778EC8 0F778F4C FFFFFFFF FFFFFFFE 00000000 00000000 1BB24510 GPR08: 0FF82064 F001C044 007B2BDF 0F778EC8 28000024 0000A0A0 0FFCA000 11F7D000 GPR16: 00000000 04000100 00001000 80000000 FFFFFFFF FFFFFFFF 00000000 0FF80098 GPR24: 0FF80BC4 FFFFA0A0 FE7FE000 00002000 F001C048 FFFFFFFF 0FFCB650 00000000 Call backtrace: 0FFB4CB8 0FFA6338 0FF81B74 0FF80724
It was running near "Near Instruction Pointer" [Note 1] 0xffb4cd0, so disassemble the code and find out where that instruction is and what it is doing.
If you're building with the gcc tools then run the appropriate "objdump -S" on the U-Boot ELF file.
If you're running a debugger (you should be) then load U-Boot and use it to disassemble. You can also put a breakpoint near there and step through the crash, inspecting variables and registers as you go.
The Link Register is showing 0x0ffb4cb8, so that's where it came from, or is the last function it called, so find that in the disassembly and find out what it is doing.
You can also find out the functions that match the values in the "Call backtrace" to find out where it was and how it got there.
Once you know what instruction it failed on, find out what that instruction was doing (what memory location it was trying to read or write) and as it almost always accesses memory via register pointers, read what register it was using then look at the register dump to see the value in that register, and thus what it was trying to get to.
It is probably configured for peripherals you don't have. Finding the addresses and the code should lead you to work out what you have to change in the configuration.
Read the source code that printed "Caused by (from msr): regs 0f778dd8 Unknown values in msr" and see what that address means.
If "all else fails" (and you don't know how to do the above or don't have a debugger) then do what everyone did in the 70's and 80's (and even this year when we're unlucky 
and sprinkle some "print statements" in the code after the last thing it managed to print, which was the "Err: serial" line. Then edit/compile/load/crash/repeat for a few hours and you'll zero in on the line giving problems, and can print the variables is is accessing, and then work out what it is doing wrong and fix it.
If you don't know enough to fix it by then, then you can post all of your investigations to this forum saying "it is in this function trying to access this whatever when it crashes' and you might be able to get some better help.
You should also check the U-Boot forums.
BTW your post is the only thing on the web that Google can find for "0FFB4CD0", so you're the first at that address at least.
Note 1: Would you believe I can't paste in the exact message because this forum software replaces the acronym for "Near Instruction Pointer" with **bleep**? I assume it has logged me as using naughty words too. I'll have to post to the U-Boot forum telling them to change their code.
Tom
