[U-Boot-Users] looking for 8266.cfg file

[Detlev Zundel]

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

-- 
It's like manually inflatable airbags -- people will never
think to use it in time to actually get any help from it.
             -- Miles Bader in <20030607122005.GA1086 at gnu.org>