[U-Boot-Users] Debugging u-boot on a custom 8548 board
Hi all, been spending a few days with my board and I see no signs of life from u-boot. I'm running my code in u-boot pulled from sept 18th's git repo - rc1 I think. I've tried:
/home/iksrazal/eldk2/usr/bin> ./ppc_85xx-gdb /home/iksrazal/u-boot/u-boot GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux". The target architecture is set automatically (currently powerpc:e500) .. (gdb) set verbose on (gdb) target remote 10.101.43.42:2001 Remote debugging using 10.101.43.42:2001 0x00000000 in ?? () (gdb) mon break hard (gdb) b board_init_f Reading in symbols for board.c...done. Breakpoint 1 at 0xfff896e8: file board.c, line 365. (gdb) c Continuing.
Where it just hangs. I've tried 'go' in the bdi to no avail. I see no life on the serial port. While I have 128MB of flash positioned at 0xf8000000 , I've loaded u-boot to 0xff8000000 - the default boot rom location for the 8548. I suppose one of the things to try is booting from low memory - but I haven't figured out how to do that via the boot sequencer or another register just yet. I also tried loading uboot to 0xf8000000 but it didn't work either.
The first culprit is probably our memory - 1GB of DDR2 ram. The hardware guys tell me our DDR2 is exactly like the MPC8548CDS reference board. I have the memory mapped to 0x00000000 , and I can do this:
ATUM>mmh 0x00000000 0xcafe ATUM>mdh 0x00000000 1 0_00000000 : 0xcafe -13570 .. ATUM>
I get the feeling that somehow that u-boot isn't being executed yet - how can I verify that? Maybe setting a breakpoint in start.S ? Pins on the 8548 ? Googling has turned up a few posts saying that perhaps my bdi config could be the culprit. Since I can erase the flash and load u-boot into it, and seemingly read and write the memory, I'm going to post my latest bdi config version but its most definetly a work in progress! Any help appreciated.
; - BDI2000 - Atum ;--------------------------------------------------- ; ; ; 3 TLBs: 1 para CCSBAR - 1 para DDR (1GB) - 1 para Flash (1GB) ;
[INIT]
DELAY 5000 ;
;####################################################################### ; Errata PCI-Ex 26 workaround WM32 0xFF70A000 0x0000005C ;Clear bit 1 & 0 in Link Control & Status Register WM32 0xFF70A004 0x00000000 ;(PCIconfiguration space register at offset 0x5C) WM32 0xFF7E0F08 0x00000008 ;Clear bit 30 in the engineering only register ;(CCSR space register at offset 0xe0f08) ;#######################################################################
;####################################################################### ; use the following two lines for STARTUP HALT ;WSPR 63 0xffff0000 ;IVPR to boot core ;WSPR 415 0x0000f000 ;IVOR15 : Debug exception ; ;#######################################################################
;####################################################################### ; Move the L2SRAM to the initial MMU page WM32 0xFF720E44 0x0000001C ;L2ERRDIS: disable parity error WM32 0xFF720000 0x60010000 ;L2CTL - 0110 0000 0000 0001 0000 0000 0000 0000 WM32 0xFF720100 0x0FFF8000 ;L2SRBAR0: map to 0x0_FFF80000 WM32 0xFF720000 0xA0010000 ;L2CTL
; load and execute some boot code WM32 0xfffffffc 0x48000000 ;loop EXEC 0xfffffffc ; ;#######################################################################
;################################################################################## ;# MMU initialization ;# ;# MAS0: MMU read/write and replacement control ;# MAS1: descriptor context and configuration control ;# MAS2: EPN and page attributes ;# MAS3: RPN and access control ;# MAS4: Hardware replacement assist configuration
;---------------------------------------------------------------------------------- ;# define 1MB TLB1 entry 1: 0x40000000 - 0x400FFFFF ;# for CCSR
WSPR 624 0x10010000 ;# MAS0 WSPR 625 0x80000500 ;# MAS1 WSPR 626 0x40000008 ;# MAS2 WSPR 627 0x4000003f ;# MAS3 WSPR 628 0x00000000 ;# MAS4
;# write tlb entry WM32 0xFFFFF000 0x7C0007A4 ;# tlbwe WM32 0xFFFFF004 0x4C00012C ;# isync WM32 0xFFFFF008 0x7C0004AC ;# msync WM32 0xFFFFF00C 0x38600055 ;# li r3, 0x55 to confirm the running WM32 0xFFFFF010 0x48000000 ;# infinite loop WM32 0xfffffffc 0xfffff000
EXEC 0xfffff000
;---------------------------------------------------------------------------------- ;
;---------------------------------------------------------------------------------- ;# define 1GB TLB1 entry 2: 0x00000000 - 0x3FFFFFFF ;# for DDR
WSPR 624 0x10020000 ;# MAS0 WSPR 625 0x80000A00 ;# MAS1 - 1000 0000 0000 0000 0000 1010 0000 0000 WSPR 626 0x00000000 ;# MAS2 WSPR 627 0x0000003f ;# MAS3
;# write tlb entry WM32 0xfffffffc 0xfffff000 EXEC 0xfffff000 ;----------------------------------------------------------------------------------
;---------------------------------------------------------------------------------- ;# define 64MBytes TLB entry 3: 0xF8000000 - 0xFFFFFFFF ;# for FLASH bank #0 and bank #1
WSPR 624 0x10030000 ;# MAS0 WSPR 625 0x80000800 ;# MAS1 WSPR 626 0xF8000008 ;# MAS2 WSPR 627 0xF800003f ;# MAS3
;# write tlb entry WM32 0xfffffffc 0xfffff000 EXEC 0xfffff000 ;----------------------------------------------------------------------------------
;################################################################################## ;# move CCSR at 0xE0000000 ;# CCSRBAR ;# bit 12 - 23 - BASE_ADDR
WM32 0xFF700000 0x000E0000 ; ;##################################################################################
;################################################################################## ;# config BPTR register (Boot Page Translation Register) ;# remove the 4k boot page from 0xFFFFF000 address ;WM32 0xE0000020 0x00000000
;# Invalidate again BR0 to prevent flash data damage in case ;# the boot sequencer re-enables CS0 access ;WM32 0xE0005000 0x00001000 ;##################################################################################
;################################################################################## ;# configure internal SRAM at 0x40100000 ;# L2CTL ;# bit 0 = 0 - L2E: L2 SRAM disabled ;# bit 4-5 = 01 - L2BLKSZ: = 512KB ;# bit 13-15 = 001 - L2SRAM: Block 0 = SRAM 0 WM32 0xE0020000 0x00010000
;# L2SRBAR0 ;# bit 0-17 = BASE addr: 0x40100000 WM32 0xE0020100 0x40100000
;# L2CTL ;# bit 0 = 1 - L2E: L2 SRAM enable ;# bit 4-5 = 01 - L2BLKSZ: = 512KB ;# bit 13-15 = 001 - L2SRAM: Block 0 = SRAM 0 WM32 0xE0020000 0x80010000 ;##################################################################################
; Setup flash programming workspace in L2SRAM WM32 0xE0020000 0x68010000 ;L2CTL WM32 0xE0020100 0xf0000000 ;L2SRBAR0 WM32 0xE0020000 0xA8010000 ;L2CTL WSPR 63 0xf0000000 ;IVPR to workspace WSPR 415 0x0001500 ;IVOR15 : Debug exception WM32 0xf0001500 0x48000000 ;write valid instruction
;################################################################################## ;# ;# Memory Windows ;# ;# 0x00000000 0x3ffffff LAW0 DDR ;# 0xc0000000 0xfffffff LAW1 Local Bus ;# ;##################################################################################
;################################################################################## ;# configure local access windows ;# ;# window 0: DDR = F ;# window 1: Local Bus = 4
;---------------------------------------------------------------------------------- ;# LAWBAR0 ;# bit 12 - 31 = 0x00000000 - base addr WM32 0xE0000c08 0x00000000
;# LAWAR0 ;# bit 1 = 1 - enable window ;# bit 8-11 = F - DDR ;# bit 26 - 31 = 1GB - size WM32 0xE0000c10 0x80f0001D ;----------------------------------------------------------------------------------
;---------------------------------------------------------------------------------- ;# LAWBAR1 ;# bit 12 - 31 = 0xF8000000 - base addr WM32 0xE0000c28 0x000F8000
;# LAWAR1 ;# bit 1 = 1 - enable window ;# bit 8-11 = 4 - local bus ;# bit 26 - 31 = 256MB - size WM32 0xE0000c30 0x8040001A ;- 1D ;---------------------------------------------------------------------------------- ;###################################################################################
;################################################################################### ;# ;# DDR initalization ;# ;### Clocks: CPU: 990 MHz, CCB: 396 MHz, DDR: 198 MHz
;# DDR_SDRAM_CFG 0100 0011 0000 0000 0000 0000 0000 0000 ;# bit 0 = 0 - MEM_EN SDRAM interface logic is disabled ;# bit 1 = 1 - SREN enable self refresh during sleep ;# bit 2 = 0 - ECC_EN disable ECC interrupt generation ;# bit 3 = 0 - RD_EN unbuffered DIMMs ;# bit 6 - 7 = 2 - SDRAM_TYPE DDR2 SDRAM ;# bit 10 = 0 - DYN_PWR power management disabled
WM32 0xE0002110 0x43000000
;# configure the appropriate DDR controller registers
;# CS0_BNDS ;# bit 8-15 - starting address ;# bit 24-31 - ending address WM32 0xE0002000 0x0000000f ; DDR CS0
;# CS0_CONFIG WM32 0xE0002080 0x80000102
;# TIMING_CFG_0 WM32 0xE0002104 0x00260802
;# TIMING_CFG_1 WM32 0xE0002108 0x38355322
;# TIMING_CFG_2 WM32 0xE000210C 0x039048c7
;# DDR_SDRAM_MODE WM32 0xE0002118 0x00000432
;# DDR_SDRAM_INTERVAL WM32 0xE0002124 0x05150100
;# DDR_SDRAM_CFG2 WM32 0xE0002114 0x24000000
;# DDR_SDRAM_CLK_CNTL WM32 0xE0002130 0x03000000
DELAY 200
;# enable the memory interface ;# DDR_SDRAM_CFG ;# enable the memory interface WM32 0xE0002110 0xc3000000 ;##################################################################################
;################################################################################## ;# configure local bus memory controller
;# CS0 - Flash Bank #0 WM32 0xE0005000 0xf8001001 ;# BR0 base address at 0xF8000000, port size 16 bit, GPCM, valid WM32 0xE0005004 0xf8006e65 ;# OR1 64MBytes flash size ;##################################################################################
;WM16 0xf8000AAA 0x5500 ; ;WM16 0xf8000554 0xAA00 ; ;WM16 0xf8000AAA 0x0100 ; ;WM16 0xf8000AAA 0x5500 ; ;WM16 0xf8000554 0xAA00 ; ;WM16 0xf8000AAA 0x0800 ; ;;WM16 0xfbffffff 0x0010 ;WM16 0xf8000000 0x0010 ;
;WM32 0xf8000AAA 0x00AA ; ;WM32 0xf8000554 0x0055 ; ;WM32 0xf8000AAA 0x00A0 ; ;DELAY 2000 ;WM32 0xf8000F00 0x5555 ;
[TARGET] CPUTYPE 8548 ;the CPU type JTAGCLOCK 0 ;use 16 MHz JTAG clock STARTUP HALT ;halt core while HRESET is asserted BREAKMODE HARD ;SOFT or HARD, HARD uses PPC hardware breakpoint STEPMODE HWBP ;JTAG or HWBP, HWBP uses a hardware breakpointeraserase WAKEUP 2000 ;give reset time to complete POWERUP 5000 ;start delay after power-up detected in ms
[HOST] IP 10.101.42.16 FILE uboot.bin FORMAT BIN LOAD MANUAL ;load code MANUAL or AUTO after reset DUMP dump.bin PROMPT ATUM>
[FLASH] CHIPTYPE MIRRORX16 ;S29GL01GP CHIPSIZE 0x8000000 ;The size of one flash chip in bytes BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32) ;WORKSPACE 0xf0000000 ;workspace in L2SRAM ERASE 0xf8000000 CHIP; erase chip
[REGS] FILE $reg8548.def
Thanks! Robert
robert lazarski wrote:
Hi all, been spending a few days with my board and I see no signs of life from u-boot. I'm running my code in u-boot pulled from sept 18th's git repo - rc1 I think. I've tried:
/home/iksrazal/eldk2/usr/bin> ./ppc_85xx-gdb /home/iksrazal/u-boot/u-boot GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux". The target architecture is set automatically (currently powerpc:e500) .. (gdb) set verbose on (gdb) target remote 10.101.43.42:2001 Remote debugging using 10.101.43.42:2001 0x00000000 in ?? () (gdb) mon break hard (gdb) b board_init_f Reading in symbols for board.c...done. Breakpoint 1 at 0xfff896e8: file board.c, line 365. (gdb) c Continuing.
Is 0xfff896e8 actually board.c line 365 (gdb's symbols OK)? Low probability of error, but worth verifying.
You might want to telnet directly into the BDI and use the BDI breakpoint and go commands directly.
I see you told gdb to use hard breakpoints (good). Using the BDI command interface instead of gdb would eliminate one more piece of software to screw up.
Did you dump flash (disassemble if you are using gcc), did it match what you programmed?
Where it just hangs. I've tried 'go' in the bdi to no avail. I see no life on the serial port. While I have 128MB of flash positioned at 0xf8000000 , I've loaded u-boot to 0xff8000000 - the default boot rom location for the 8548. I suppose one of the things to try is booting from low memory - but I haven't figured out how to do that via the boot sequencer or another register just yet. I also tried loading uboot to 0xf8000000 but it didn't work either.
I wouldn't switch to low boot until you've exhausted your current options. I would suspect you would work hard for no different results.
The first culprit is probably our memory - 1GB of DDR2 ram. The hardware guys tell me our DDR2 is exactly like the MPC8548CDS reference board. I have the memory mapped to 0x00000000 , and I can do this:
board_init_f is the flash-based board initialization, run before RAM is used. If you aren't getting there, it isn't RAM's fault.
ATUM>mmh 0x00000000 0xcafe ATUM>mdh 0x00000000 1 0_00000000 : 0xcafe -13570 .. ATUM>
It may be RAM's fault later, but not yet...
I get the feeling that somehow that u-boot isn't being executed yet - how can I verify that? Maybe setting a breakpoint in start.S ?
YES! Set hardware breakpoints right at the start and see if you hit them (and I would do it directly with the BDI, since I'm paranoid).
I would also check what your PC register is when you start out, perhaps you aren't even starting where you think you are.
When you go/continue and no breakpoints are hit, halt the CPU... where is the PC?
Your BDI config file is pretty complex, can you trim out all but the essentials? I see a lot of "moving" and "mapping" and "TLB"ing. Your memory map may be completely different from the normal power up configuration, which is what u-boot expects.
Makes me ask my memory readback question again: can you read the flash holding u-boot at the memory location you think u-boot lives at???
[snip]
Thanks! Robert
Yerwelcome. Hope it helps. gvb
Hi Jerry and Robert,
You might want to telnet directly into the BDI and use the BDI breakpoint and go commands directly.
Additionally I wanted to hint at the fact that all the BDI "telnet commands" can be accessed through the "monitor" gdb command. So without switching any terminal you can easily do a "mon info" from gdb for example.
The convenience of this is worth the risk of iterating well known facts :)
Cheers Detlev
On 9/19/07, Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
robert lazarski wrote:
Thanks for the help Jerry...
Is 0xfff896e8 actually board.c line 365 (gdb's symbols OK)? Low probability of error, but worth verifying.
In vim with line numbers enabled, editing lib_ppc/board.c I get:
364 void board_init_f (ulong bootflag) 365 {
You might want to telnet directly into the BDI and use the BDI breakpoint and go commands directly.
I see you told gdb to use hard breakpoints (good). Using the BDI command interface instead of gdb would eliminate one more piece of software to screw up.
Good idea, see below.
Did you dump flash (disassemble if you are using gcc), did it match what you programmed?
Will try that if I can't grab low hanging fruit.
I wouldn't switch to low boot until you've exhausted your current options. I would suspect you would work hard for no different results.
The first culprit is probably our memory - 1GB of DDR2 ram. The hardware guys tell me our DDR2 is exactly like the MPC8548CDS reference board. I have the memory mapped to 0x00000000 , and I can do this:
board_init_f is the flash-based board initialization, run before RAM is used. If you aren't getting there, it isn't RAM's fault.
ATUM>mmh 0x00000000 0xcafe ATUM>mdh 0x00000000 1 0_00000000 : 0xcafe -13570 .. ATUM>
It may be RAM's fault later, but not yet...
I looked at the code after you mentioned that - thanks for pointing that out.
I get the feeling that somehow that u-boot isn't being executed yet - how can I verify that? Maybe setting a breakpoint in start.S ?
YES! Set hardware breakpoints right at the start and see if you hit them (and I would do it directly with the BDI, since I'm paranoid).
I'm using the bdi now directly, and googling turned this up:
http://www.ultsol.com/faq_p304.htm
"For an MPC85xx family processor the MSR[DE] bit must be set. Breakpoints will only trigger if this bit is set."
So after reset, info shows:
ATUM>info Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : COP halt Current PC : 0xfffffffc Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0x00000000 Current CCSRBAR : 0x0_e0000000
MSR[DE] in the 8548 manual at 6-12 says:
bit name description --------------------------------------------------------------------------------------------------------------------------- 54 DE Debug interrupt enable. See the description of the DBSR[UDE] in Section 6.13.2, "Debug Status Register (DBSR)." 0 Debug interrupts are disabled. 1 Debug interrupts are enabled if DBCR0[IDM] = 1.
I read this all as saying the MSR needs to be 0x00000220 - bit 54 off the MSR seems to be cleared by the bdi as shown above - seems odd to me.
Using gdb just to read the elf symbols and _not_ connected to the bdi, I get:
(gdb) b _start_e500 Breakpoint 1 at 0xfffff01c
So I do (ATUM> is my bdi prompt) :
ATUM>rm msr 0x00000220 ATUM>rd msr msr : 0x00000220 544 ATUM>bi 0xfffff01c Breakpoint identification is 0 ATUM>go
After waiting for minute or so, I do:
ATUM>halt Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : COP halt Current PC : 0x00000000 Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0x00000000 Current CCSRBAR : 0x0_e0000000
So the MSR bit I believe I need is getting cleared.
I would also check what your PC register is when you start out, perhaps you aren't even starting where you think you are.
When you go/continue and no breakpoints are hit, halt the CPU... where is the PC?
As shown above the PC is 0x00000000 - the start of my DDR2. What does that mean?
Your BDI config file is pretty complex, can you trim out all but the essentials? I see a lot of "moving" and "mapping" and "TLB"ing. Your memory map may be completely different from the normal power up configuration, which is what u-boot expects.
Will try that so that its easier to help me - was quite an effort to create that file.
Makes me ask my memory readback question again: can you read the flash holding u-boot at the memory location you think u-boot lives at???
This seems right to me:
ATUM>mdh 0xff800000 0_ff800000 : 2705 1956 552d 426f 6f74 2031 2e33 2e30 '..VU-Boot 1.3.0
Yerwelcome. Hope it helps. gvb
Helping quite a bunch as I have plenty of ideas to try - thanks! Robert
Just one point here my u-boot for our custom MPC8548 board starts at 0xfff80000 not 0xff800000. Unless you changed the linker map won't this mean that the code that is supposed to live at the reset vector is not actually there?
Try looking right at the top of flash (the last 16 bytes) for the jump.
Maybe I have missed something obvious here but I just thought I point it out
Regards
Steve Williams
This seems right to me:
ATUM>mdh 0xff800000 0_ff800000 : 2705 1956 552d 426f 6f74 2031 2e33 2e30 '..VU-Boot 1.3.0
On 9/20/07, Steve Williams steve@parsonscroft.plus.com wrote:
Just one point here my u-boot for our custom MPC8548 board starts at 0xfff80000 not 0xff800000. Unless you changed the linker map won't this mean that the code that is supposed to live at the reset vector is not actually there?
Try looking right at the top of flash (the last 16 bytes) for the jump.
Maybe I have missed something obvious here but I just thought I point it out
Regards
Steve Williams
Hi Steve. What board are you referring to - is it open sourced ? I can't get any signs of life yet so I tried 0xfff80000 (0xfffff01c is _start_e500 in start.S) :
ATUM4>mdh 0xfff80000 0_fff80000 : 2705 1956 552d 426f 6f74 2031 2e33 2e30 '..VU-Boot 1.3.0
ATUM4>bi 0xfffff01c Breakpoint identification is 0 ATUM4>go 0xfff80000 ATUM4>halt Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : COP halt Current PC : 0xf0000000 Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0x00000000 Current CCSRBAR : 0x0_e0000000
In a nutshell I'm trying to figure out what the pc is doing and why - I can't hit breakpoints nor see any signs of code running. The docs do say:
4.4.3.3 Boot ROM Location The MPC8548E defines the default boot ROM address range to be 8 Mbytes at address 0x0_FF80_0000 to 0x0_FFFF_FFFF. However, which peripheral interface handles these boot ROM accesses can be selected at power on.
As I said I could be reading this wrong. The 8548 cds code in 1.3 rc1 has:
#define CFG_BOOT_BLOCK 0xff000000 /* boot TLB block */ #define CFG_FLASH_BASE CFG_BOOT_BLOCK /* start of FLASH 16M */ #define CFG_FLASH_BANKS_LIST {0xff800000, CFG_FLASH_BASE}
Am I reading all this to mean I should load uboot to 0xff800000 - is that wrong ?
Incidently, I'm going thru the docs trying to find exceptions in the registers - these aren't changing for me:
ATUM4>rd spefscr spefscr : 0x00000000 0 ATUM4>rd dear dear : 0x00000000 0 ATUM4>rd esr esr : 0x00000000 0
In fact, I'm seeing the behavior running u-boot and with the flash erased via typing "go uboot address" - I can't see any difference in any registers.
I wrote an email to freescale tech support to see if there is some register I can see to find the error or some other type of help they can offer.
Thanks all! Robert
ATUM4>mdh 0xfff80000 0_fff80000 : 2705 1956 552d 426f 6f74 2031 2e33 2e30 '..VU-Boot 1.3.0
ATUM4>bi 0xfffff01c Breakpoint identification is 0 ATUM4>go 0xfff80000 ATUM4>halt Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : COP halt Current PC : 0xf0000000 Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0x00000000 Current CCSRBAR : 0x0_e0000000
This cannot work, as your own memory dump shows (above). You have the "magic word" and some ASCCI string at 0xfff80000. These are not valid ppc assembler instructions, but the begin of the u-boot image. Please check/dump address 0xfffffffc. There should be a valid jump instruction (see resetvec.S) which jumps to an address within a 4kbyte page at the end of the address space. ((0xfffff000, _start_e500()). There will be code that initializes the MMU that you can access the rest of the flash device(s), including the u-boot image (e.g cpu_init_f().
In a nutshell I'm trying to figure out what the pc is doing and why - I can't hit breakpoints nor see any signs of code running. The docs do say:
4.4.3.3 Boot ROM Location The MPC8548E defines the default boot ROM address range to be 8 Mbytes at address 0x0_FF80_0000 to 0x0_FFFF_FFFF. However, which peripheral interface handles these boot ROM accesses can be selected at power on.
As I said I could be reading this wrong. The 8548 cds code in 1.3 rc1 has:
#define CFG_BOOT_BLOCK 0xff000000 /* boot TLB block */ #define CFG_FLASH_BASE CFG_BOOT_BLOCK /* start of FLASH 16M */ #define CFG_FLASH_BANKS_LIST {0xff800000, CFG_FLASH_BASE}
Am I reading all this to mean I should load uboot to 0xff800000 - is that wrong ?
This means your Boot flash devices starts is at address 0xff800000, not that your boot code starts at this address.
For a start I would use the 8548 cds linker script unchanged, build your u-boot image, flash it to 0xfff80000 and single-step with your BDI.
Regards, Torsten
On Fri, Sep 21, 2007 at 07:14:20AM +0100, Demke Torsten-atd012 wrote:
ATUM4>mdh 0xfff80000 0_fff80000 : 2705 1956 552d 426f 6f74 2031 2e33 2e30 '..VU-Boot 1.3.0
ATUM4>bi 0xfffff01c Breakpoint identification is 0 ATUM4>go 0xfff80000 ATUM4>halt Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : COP halt Current PC : 0xf0000000 Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0x00000000 Current CCSRBAR : 0x0_e0000000
This cannot work, as your own memory dump shows (above). You have the "magic word" and some ASCCI string at 0xfff80000. These are not valid ppc assembler instructions, but the begin of the u-boot image. Please check/dump address 0xfffffffc. There should be a valid jump instruction (see resetvec.S) which jumps to an address within a 4kbyte page at the end of the address space. ((0xfffff000, _start_e500()). There will be code that initializes the MMU that you can access the rest of the flash device(s), including the u-boot image (e.g cpu_init_f().
Errm, having just done an initial build for the ep8248e, I first looked in the generated u-boot.map file. In my case, it says:
.text ... 0xfff00100 _start
so I'm planning to "go 0xfff00100", and if that doesn't do it, then "go 0x100", because CS0 is then hopefully mapping flash to put _start at the reset vector, so it'll work at power-on. (Just an optimistic WAG at this stage.)
Anyway, what does robert's u-boot.map say?
Erik
(Sorry, just subscribed, and it's Friday, so couldn't resist rashly chiming in. :)
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Erik Christiansen Sent: Freitag, 21. September 2007 08:59 To: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Debugging u-boot on a custom 8548 board
On Fri, Sep 21, 2007 at 07:14:20AM +0100, Demke Torsten-atd012 wrote:
ATUM4>mdh 0xfff80000 0_fff80000 : 2705 1956 552d 426f 6f74 2031 2e33 2e30 '..VU-Boot 1.3.0
ATUM4>bi 0xfffff01c Breakpoint identification is 0 ATUM4>go 0xfff80000 ATUM4>halt Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : COP halt Current PC : 0xf0000000 Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0x00000000 Current CCSRBAR : 0x0_e0000000
This cannot work, as your own memory dump shows (above). You have the "magic word" and some ASCCI string at 0xfff80000. These are not valid ppc assembler instructions, but the
begin of the
u-boot image. Please check/dump address 0xfffffffc. There should be a valid jump instruction (see resetvec.S) which jumps to an address
within a 4kbyte
page at the end of the address space. ((0xfffff000, _start_e500()). There will be code that initializes the MMU that you can access the rest of the flash device(s), including the u-boot image (e.g cpu_init_f().
Errm, having just done an initial build for the ep8248e, I first looked in the generated u-boot.map file. In my case, it says:
.text ... 0xfff00100 _start
And...? _start is at 0xfff00100 at my board too, but go 0xfff01000 will probably fail, because this address is outside the 4K page and MMU is not properly configured...
see start.S: ... _start_e500: ... /* Jump out of the last 4K page and continue to 'normal' start */ 1: bl 3f b _start ...
Regards, Torsten
so I'm planning to "go 0xfff00100", and if that doesn't do it, then "go 0x100", because CS0 is then hopefully mapping flash to put _start at the reset vector, so it'll work at power-on. (Just an optimistic WAG at this stage.)
Anyway, what does robert's u-boot.map say?
Erik
(Sorry, just subscribed, and it's Friday, so couldn't resist rashly chiming in. :)
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
On Fri, Sep 21, 2007 at 08:25:43AM +0100, Demke Torsten-atd012 wrote:
Errm, having just done an initial build for the ep8248e, I first looked in the generated u-boot.map file. In my case, it says:
.text ... 0xfff00100 _start
And...?
The helpful intent was to communicate the benefit of looking up the address of symbols, and suggesting where they might be found. (My ep8248e example can only use the symbols it has. I'm sure Robert does not need to be belaboured with "do same for your symbol, _start_e500" ;-)
_start is at 0xfff00100 at my board too, but go 0xfff01000 will probably fail, because this address is outside the 4K page and MMU is not properly configured...
You may well be right about 0xfff01000, but please compare that with the address I mentioned. ;-)
Ah, I shouldn't have brought up the ep8248e, because the MMU is inactive immediately after reset, in contrast to the 8548 case, IIUC. (But it's the only example I have.)
see start.S: ... _start_e500: ... /* Jump out of the last 4K page and continue to 'normal' start */ 1: bl 3f b _start ...
Though the cpu differs by only one digit, the start-up differs significantly. For 8248, it looks pretty dang old-fashioned to my naive eye:
$ ppc_6xx-objdump -D u-boot > u-boot.mydump # Just to confirm that # mpc824x/start.S is # used. fff00100 <_start>: fff00100: 3a a0 00 01 li r21,1 fff00104: 60 00 00 00 nop fff00108: 48 00 00 10 b fff00118 <boot_cold> fff0010c: 00 00 00 00 .long 0x0
fff00110 <_start_warm>: fff00110: 3a a0 00 02 li r21,2 fff00114: 48 00 00 04 b fff00118 <boot_cold>
fff00118 <boot_cold>: fff00118: 7c a0 00 a6 mfmsr r5 fff0011c: 3c 60 f0 00 lis r3,-4096
Now, I'll have to succeed in burning it to flash, before I can say anything about how well it works for me.
Avagoodweekend, Erik
On 9/21/07, Demke Torsten-atd012 torsten.demke@motorola.com wrote:
Thanks all, I can now debug! Please see below...
ATUM4>bi 0xfffff01c Breakpoint identification is 0 ATUM4>go 0xfff80000 ATUM4>halt Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : COP halt Current PC : 0xf0000000 Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0x00000000 Current CCSRBAR : 0x0_e0000000
This cannot work, as your own memory dump shows (above). You have the "magic word" and some ASCCI string at 0xfff80000. These are not valid ppc assembler instructions, but the begin of the u-boot image. Please check/dump address 0xfffffffc. There should be a valid jump instruction (see resetvec.S) which jumps to an address within a 4kbyte page at the end of the address space. ((0xfffff000, _start_e500()). There will be code that initializes the MMU that you can access the rest of the flash device(s), including the u-boot image (e.g cpu_init_f().
Seems so clear now - thank you very much for the kind help.
Am I reading all this to mean I should load uboot to 0xff800000 - is that wrong ?
This means your Boot flash devices starts is at address 0xff800000, not that your boot code starts at this address.
For a start I would use the 8548 cds linker script unchanged, build your u-boot image, flash it to 0xfff80000 and single-step with your BDI.
So I executed:
/home/iksrazal/eldk2/usr/bin> ./powerpc-linux-objdump -D /home/iksrazal/u-boot/u-boot > ~/u-boot.mydump
For clearer debugging, I compiled u-boot with:
OPTFLAGS= -Os -fno-schedule-insns -fno-schedule-insns2
After a reset in the bdi, I can now single step via 'ti' until:
ATUM>ti Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : single step Current PC : 0xfffff20c Current CR : 0x00000000 Current MSR : 0x00000200 Current LR : 0xfffff0b4 Current CCSRBAR : 0x0_e0000000 ATUM>ti Target CPU : MPC85xx (e500v2 rev.2) Target state : halted Debug entry cause : COP halt Current PC : 0xfff80e00 Current CR : 0x00000000 Current MSR : 0x00000000 Current LR : 0xfffff210 Current CCSRBAR : 0x0_e000000
Where in ~/u-boot.mydump :
fffff208 <tlb1_entry>: fffff208: 7c 28 02 a6 mflr r1 fffff20c: 48 00 00 b9 bl fffff2c4 <tlb1_entry+0xbc>
And:
fff80e00 <InstructionTLBError>
fffff20c is seemingly my init.S code - how can I find out for sure? The first lines I have are:
#define entry_start \ mflr r1 ; \ bl 0f ;
Thanks all more than words can tell, Robert
On 9/21/07, Demke Torsten-atd012 torsten.demke@motorola.com wrote:
For a start I would use the 8548 cds linker script unchanged, build your u-boot image, flash it to 0xfff80000 and single-step with your BDI.
Hi all, I'm stuck again. I can now single step and hit some breakpoints. However, I'm failing early in cpu/mpc85xx/start.S . I keep on getting:
ATUM>bi 0xfffff0c0 Breakpoint identification is 0 ATUM>go - TARGET: stopped ATUM>rd GPR00: fffff210 fffff0b4 00010001 00000000 GPR04: 0000000b fffff210 00000000 00000000 GPR08: 00000000 00000000 00000000 00000000 GPR12: 00000000 00000000 00000000 00000000 GPR16: 00000000 00000000 00000000 00000000 GPR20: 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 00000000 00000000 GPR28: 00000000 00000000 00000000 00000000 CR : 00000000 MSR: 00000200 ATUM>ti - Core status is 0x0041 *** Core is stopped, no debugging possible # PPC: timeout while waiting for halt ATUM> Target CPU : MPC85xx (e500v2 rev.2) Target state : running # Step timeout detected
0xfffff0c0 maps as cpu/mpc85xx/start.S, line 163:
162 163 0: lwzu r6,4(r5) 164 lwzu r7,4(r5)
Output from powerpc-linux-objdump on b-boot.bin:
fffff0c0: 84 c5 00 04 lwzu r6,4(r5)
When this happens, I seemingly can't read any registers or do any further analysis. I spent the last few days trying to develop the exact cause, but I'm getting inconsistent behavior from the bdi. The farthest I can go consistently is set a breakpoint this far on line 163.
The code on Line 163 happens after "bl tlb1_entry" , which calls my init.S . After trying a hundred times or so, once or twice I've been able to step further or set a slightly further breakpoint than line 163 - but not consistently. I've tried:
1) Doing 'ti' after reset, it gives 'Step timeout detected' at different locations on every run. 2) Taking out the init section of the bdi. 3) General tweaking of the init section in the bdi. 4) Making the jtag clock slower in the bdi config. 5) Making my tlb1_entry bare bones. 6) Using the cds tlb1_entry . 7) Flashing the cds code into my flash. 8) Setting the breakpoint much further, board_init_f , and typing go after reset.
Everything I've tried doesn't get me consistently past line 163 of cpu/mpc85xx/start.S. However, I've tried single stepping slightly before that and I've failed to single step consistently to line 163. So I'm having a hard time developing a pattern of failure. Any ideas on what I could try? I still haven't got as far as getting the serial port working. Thanks! Robert
participants (6)
-
Demke Torsten-atd012 -
Detlev Zundel -
erik＠dd.nec.com.au -
Jerry Van Baren -
robert lazarski -
Steve Williams