Skip to contentSkip to conversation

looking for 8266.cfg file

U-Boot-Users Currie Reid 2 participants 2 messages Sep 19, 2003 – Sep 20, 2003 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw

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

#2 lore raw

Hello Currie,

Quoted 38 lines

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

Quoted 3 lines

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.

Quoted 9 lines

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.

Quoted 4 lines

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

Signature · 3 lines
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 <[email protected]>