[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Silence on boot with Dreamplug.
On May 14, 2011, at 4:01 PM, <rjs%fdy2.demon.co.uk@localhost>
> 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.
Main Index |
Thread Index |