Re: Silence on boot with Dreamplug.

[Ted Lemon <mellon%fugue.com@localhost>]

On May 14, 2011, at 4:01 PM, <rjs%fdy2.demon.co.uk@localhost> 
<rjs%fdy2.demon.co.uk@localhost> wrote:
> My understanding was that it is loaded at 0x2000000 then the data
> following the header is copied back down to 0x00008000 by u-boot.

It took me a while to get the debugger working with the JTAG board.  It turns 
out that the version of the extremely aptly-named openocd that you get from git 
is missing something (I don't know what) that's in the binaries you can get 
from the dreamplug google code repository 
(http://code.google.com/p/dreamplug/downloads/list).   Hopefully at some point 
this will get integrated or they'll at least drop the code they used to build 
those binaries so that *someone* can integrate the changes.  I had to do a 
custom i386 linux install just to run the openocd binaries.   I guess it's 
possible that it's simply a 32-bit versus 64-bit problem--I haven't tried 
building openocd from source on the i386 yet.

I had some trouble figuring out if I was really running the built kernel, 
because the hardware breakpoint mechanism wasn't actually working--if you set a 
breakpoint at 0x8000, which is the address uboot jumps to, the breakpoint never 
fires.   So there's some problem with the way openocd is doing this, which is 
probably worth debugging, but which I haven't debugged.

I finally figured out that if I assembled a breakpoint instruction at the 
beginning of marvell_start.S, I ought to see something in the debugger, and in 
fact I did.   The only way to get past the breakpoint instruction, 
unfortunately, is to modify the pc, and doing so causes gdb to hang (although 
it does modify the pc before hanging), so it's a bit rocky at the moment, but 
I've been able to step past the point where it has set up the virtual memory 
mappings and then set a breakpoint in the kernel at its correct address in vm 
and have it stop.

It would be nice to get this bit to be a little smoother, but the bottom line 
is that I'm pretty well set up to debug this now, and it's definitely the case 
that the kernel is loading and running; whatever's causing it to go silent is 
probably an issue with the console driver or something like that, and is not a 
simple mismatch between the kernel and uboot, nor a problem setting up VM.   If 
this requires significant further debugging, I may actually try to get openocd 
and gdb to play better together, but hopefully it'll be something simple and I 
can just submit a patch for it soon.

Thanks for the initial sanity checking!   I will report back when I know more.