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

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

[Currie Reid]

Hello all,

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.

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).

Again, thank you very much for any assistance.

Currie

; bdiGDB configuration file for MPC8260-ADS board
; -----------------------------------------------
;
[INIT]
; init core register
WREG    MSR             0x00000000      ;clear MSR
WM32	0x0F0101A8	0x04700000	;IMMR : internal space @
0x04700000
WM32	0x04710004	0xFFFFFFC3	;SYPCR: disable watchdog
WM32	0x04710C80	0x00000001	;SCCR : normal operation

; init memory controller
WM32	0x04710104	0xFF800836	;OR0: Flash 8MB, CS early negate,
6 w.s., Timing relax
WM32	0x04710100	0xFF801801	;BR0: Flash @0xFF800000, 32bit, no
parity
WM32	0x0471010C	0xFFFF8010	;OR1: BCSR 32KB, all types
accesse, 1 w.s.
WM32	0x04710108	0x04501801	;BR1: BCSR @0x04500000, 32bit, no
parity
WM32	0x04500004	0x3D000000	;BCSR1: enable RS232-1

; init SDRAM Init (PPC bus)
WM16	0x04710184	0x1900	        ;MPTPR: Divide Bus clock by 26
WM8	0x0471019C	0x21	        ;PSRT : Divide MPTPR output by 34
;WM8	0x0471019C	0x14	        ;PSRT : Divide MPTPR output by 21
WM32	0x04710114	0xFF000C80	;OR2  : 16MB, 2 banks, row start
at A9, 11 rows
WM32	0x04710110	0x00000041	;BR2  : SDRAM @0x00000000, 64bit,
no parity
WM32	0x04710190	0x296EB452	;PSDMR: Precharge all banks
WM8	0x00000000	0xFF	        ;Access SDRAM
WM32	0x04710190	0x096EB452	;PSDMR: CBR Refresh
WM8	0x00000000	0xFF	        ;Access SDRAM
WM8	0x00000000	0xFF	        ;Access SDRAM
WM8	0x00000000	0xFF	        ;Access SDRAM
WM8	0x00000000	0xFF	        ;Access SDRAM
WM8	0x00000000	0xFF	        ;Access SDRAM
WM8	0x00000000	0xFF	        ;Access SDRAM
WM8	0x00000000	0xFF	        ;Access SDRAM
WM8	0x00000000	0xFF	        ;Access SDRAM
WM32	0x04710190	0x196EB452	;PSDMR: Mode Set
WM8	0x00000000	0xFF	        ;Access SDRAM
WM32	0x04710190	0x416EB452	;PSDMR: enable refresh, normal
operation


[TARGET]
CPUTYPE     8260        ;the CPU type (603EV,750,8240,8260)
JTAGCLOCK   0           ;use 16 MHz JTAG clock
BOOTADDR    0xfff00100  ;boot address used for start-up break
WORKSPACE   0x00000000	;workspace in target RAM for fast download
BDIMODE     AGENT     	;the BDI working mode (LOADONLY | AGENT | GATEWAY)
BREAKMODE   SOFT      	;SOFT or HARD, HARD uses PPC hardware breakpoints
;STEPMODE    HWBP        ;TRACE or HWBP, HWPB uses a hardware breakpoint
VECTOR      CATCH       ;catch unhandled exceptions
DCACHE      NOFLUSH	;data cache flushing (FLUSH | NOFLUSH)
;MMU         XLAT        ;translate effective to physical address
POWERUP     5000        ;start delay after power-up detected in ms
;REGLIST     SPR         ;select register to transfer to GDB
;REGLIST     ALL         ;select register to transfer to GDB
;VIO         7 9600       ;TCP port for virtual IO, BCSR1: enable RS232-1
!!!
;SIO         7 9600       ;TCP port for serial IO, check BCSR1: enable
RS232-1 !!!

[HOST]
IP          47.129.82.27
FILE        /tftpboot/u-boot.srec
;FILE        E:\cygnus\root\usr\demo\mpc8260\fibo.exe
FORMAT      SREC
LOAD        MANUAL      ;load code MANUAL or AUTO after reset
DEBUGPORT   2001
PROMPT      MPC8260>	;new prompt for Telnet
DUMP        /tftpboot/dump.bin
;DUMP        dump.bin            ;Linux: dump.bin must already exist and
public writable

[FLASH]
CHIPTYPE    I28BX8      ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 |
I28BX16)
;CHIPTYPE    AM29BX8
CHIPSIZE    0x200000    ;The size of one flash chip in bytes (e.g.
AM29F010 = 0x20000)
BUSWIDTH    32          ;The width of the flash memory bus in bits (8 | 16
| 32 | 64)
;WORKSPACE   0x04700000  ;workspace in dual port RAM
WORKSPACE   0x00400000  ;workspace in SDRAM
;FILE        E:\tornado\target\config\ads8260\test.hex  ;The file to
program
;FORMAT      SREC 0x01000000
;FILE        E:\cygnus\root\usr\demo\mpc8260\init8260.S3
FILE        /tftpboot/u-boot.srec
;FILE        E:\cygnus\root\usr\demo\mpc8260\ads8260.sss
;
ERASE       0xFF800000  ;erase sector  0 of flash SIMM (LH28F016SCT)
ERASE       0xFF840000  ;erase sector  1 of flash SIMM
ERASE       0xFF880000  ;erase sector  2 of flash SIMM
ERASE       0xFF8C0000  ;erase sector  3 of flash SIMM
ERASE       0xFF900000  ;erase sector  4 of flash SIMM
ERASE       0xFF940000  ;erase sector  5 of flash SIMM
ERASE       0xFF980000  ;erase sector  6 of flash SIMM
ERASE       0xFF9C0000  ;erase sector  7 of flash SIMM
ERASE       0xFFA00000  ;erase sector  8 of flash SIMM
ERASE       0xFFA40000  ;erase sector  9 of flash SIMM
ERASE       0xFFA80000  ;erase sector 10 of flash SIMM
ERASE       0xFFAC0000  ;erase sector 11 of flash SIMM
ERASE       0xFFB00000  ;erase sector 12 of flash SIMM
ERASE       0xFFB40000  ;erase sector 13 of flash SIMM
ERASE       0xFFB80000  ;erase sector 14 of flash SIMM
ERASE       0xFFBC0000  ;erase sector 15 of flash SIMM
ERASE       0xFFC00000  ;erase sector 16 of flash SIMM
ERASE       0xFFC40000  ;erase sector 17 of flash SIMM
ERASE       0xFFC80000  ;erase sector 18 of flash SIMM
ERASE       0xFFCC0000  ;erase sector 19 of flash SIMM
ERASE       0xFFD00000  ;erase sector 20 of flash SIMM
ERASE       0xFFD40000  ;erase sector 21 of flash SIMM
ERASE       0xFFD80000  ;erase sector 22 of flash SIMM
ERASE       0xFFDC0000  ;erase sector 23 of flash SIMM
ERASE       0xFFE00000  ;erase sector 24 of flash SIMM
ERASE       0xFFE40000  ;erase sector 25 of flash SIMM
ERASE       0xFFE80000  ;erase sector 26 of flash SIMM
ERASE       0xFFEC0000  ;erase sector 27 of flash SIMM
ERASE       0xFFF00000  ;erase sector 28 of flash SIMM
ERASE       0xFFF40000  ;erase sector 29 of flash SIMM
ERASE       0xFFF80000  ;erase sector 30 of flash SIMM
ERASE       0xFFFC0000  ;erase sector 31 of flash SIMM

[REGS]
DMM1        0x04700000
FILE        /tftpboot/reg8260.def

[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@gnu.org>