Hello Currie,
I am moving from bdiPro to bdiGDB and am having a difficult time getting the bdi2000 working with my mcp8266ads-pci board. I had thought that the mpc8260 cfg file would have been sufficient to accomplish this:
MPC8260>prog 0xfff00000 /tftpboot/u-boot.srec srec Programming /tftpboot/u-boot.srec , please wait .... Programming flash passed MPC8260>verify 0xfff00000 /tftpboot/u-boot.srec srec Verifying /tftpboot/u-boot.srec , please wait .... Verifying target memory passed
But then I do a reset, and a "go", but see nothing on the serial console.
MPC8260>reset
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x55 => 0xAA
- Bypass check: 0x55 => 0xAA
- JTAG exists check passed
- Target PVR is 0x80911014
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- Waiting for target stop passed
- TARGET: Target PVR is 0x80911014
- TARGET: resetting target passed
- TARGET: processing target startup ....
- TARGET: processing target startup passed
MPC8260>go
- TARGET: target has entered debug mode
I am using the same u-boot that I compiled for use with bdiPro, so I am pretty sure that it works for the board - I have been using it for some time.
This is only a general advice, but make sure that you initialize only the bare minimum of registers in the 8266 as u-boot does all the initialization. You should be able to use gdb to single step through u-boot and see where the problem occurs. See our documentation[1] for this.
I am very new to hardware programming, so please bear with me if I am missing the painfully obvious.
Incidentally, the reason I had to switch from bdiPro was that during kernel testing, u-boot stopped working after a boot - at which point tried to re-flash and this failed - it turned out that somehow flash sector 27 had becomed locked, and there was no way to unlock it from bdiPro; thus subsequent attempts to flash the board would fail.
Now that I am using bdiGDB, I would like not to have to switch between the 2 to accomplish different tasks ( obviously ), and I very much like the idea of having an alternative to printk's to conduct kernel debugging ( how I got in this mess in the first place).
You can use the gdb "monitor" command so there is absolutely no reason why you should use the telnet interface. "monitor info" under gdb with bdi as target gives the same info, "info" on the bdi does.
Cheers Detlev
[1] http://www.denx.de/twiki/bin/view/DULG/DebuggingUBoot