* Breakpoint is not hitting for Kernel Debugging
@ 2007-09-03 14:02 dnl
2007-09-03 19:20 ` Dan Malek
2007-09-04 4:07 ` Bill F
0 siblings, 2 replies; 5+ messages in thread
From: dnl @ 2007-09-03 14:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 554 bytes --]
Hi all,
I am using uboot and montavista kernel for our custom MPC8555CDS board.
I enabled the following options in Kernel for kernel Debugging, CONFIG_BDI_SWITCH=y CONFIG_DEBUG_INFO=y under kernel hacking and MMU XALT in BDI config file. After uboot initialization I fixed break point at start_kernel(0xc02784bc), and then I booted the kernel. Without breaking at start_kernel, it came to login prompt. Please find attached config file with this mail. Could anybody help me to solve this problem?
Thanks in advance,
Saravanan.S
Bangalore.
[-- Attachment #1.2: Type: text/html, Size: 988 bytes --]
[-- Attachment #2: BDI_break_Kernel.txt --]
[-- Type: text/plain, Size: 16034 bytes --]
BDI Config File
[INIT]
TSZ1 0xFE000000 0xFFFFFFFF ;for flash
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;; TESTING START ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Move the L2SRAM to the initial MMU page
WM32 0xFF720000 0x68010000 ;L2CTL
WM32 0xFF720100 0xFFFC0000 ;L2SRBAR0
WM32 0xFF720000 0xA8010000 ;L2CTL
;
; Clear L2SRAM with DMA
WM32 0xff721110 0x00040000 ;SATR0 SREADTTYPE=Read, don't snoop
WM32 0xff721114 0xff700004 ;SAR0 Dummy source register
WM32 0xff721118 0x00050000 ;DATR0 DWRITETTTYPE=Write, snoop local processor
WM32 0xff721120 0x00040000 ;BCR0 Size
WM32 0xff721100 0x0f009404 ;MR0 BWC=f,SAHTS=2(4 bytes),SAHE=1,SWSM=Dest,SRW=1,CTM=1,CS=0
WM32 0xff72111c 0xfffc0000 ;DAR0 which sets CS=1
DELAY 200 ;let DMA complete
WM32 0xff721100 0x00000000 ;MR0 reset condition
; load and execute boot code (needed if STARTUP HALT)
WM32 0xfffffffc 0x48000000 ;loop
EXEC 0xfffffffc 1000
;
; load TLB entries, helper code @ 0xfffff000
WM32 0xfffff000 0x7c0007a4 ;tlbwe
WM32 0xfffff004 0x7c0004ac ;msync
WM32 0xfffff008 0x48000000 ;loop
;
; 1MB TLB1 #1 0x40000000 - 0x400fffff
WSPR 624 0x10010000 ;MAS0:
WSPR 625 0x80000500 ;MAS1:
WSPR 626 0x4000000a ;MAS2:
WSPR 627 0x40000015 ;MAS3:
WSPR 628 0x00000000 ;MAS4:
EXEC 0xfffff000
;
; 64 MB TLB1 #2 0xc0000000 - 0xc3ffffff
WSPR 624 0x10020000 ;MAS0:
WSPR 625 0x80000800 ;MAS1:
WSPR 626 0xc0000008 ;MAS2:
WSPR 627 0xc0000015 ;MAS3:
EXEC 0xfffff000
;
; 64 MB TLB1 #3 0x00000000 - 0x03ffffff
WSPR 624 0x10030000 ;MAS0:
WSPR 625 0x80000800 ;MAS1:
WSPR 626 0x00000008 ;MAS2:
WSPR 627 0x00000015 ;MAS3:
EXEC 0xfffff000
;
; 64 MB TLB1 #4 0x04000000 - 0x07ffffff
WSPR 624 0x10040000 ;MAS0:
WSPR 625 0x80000800 ;MAS1:
WSPR 626 0x04000008 ;MAS2:
WSPR 627 0x04000015 ;MAS3:
EXEC 0xfffff000
;
; 16 MB TLB1 #5 0xff000000 - 0xffffffff
WSPR 624 0x10050000 ;MAS0:
WSPR 625 0x80000700 ;MAS1:
WSPR 626 0xff00000a ;MAS2:
WSPR 627 0xff000015 ;MAS3:
EXEC 0xfffff000
;
; 16 MB TLB1 #0 0xf0000000 - 0xf0ffffff
WSPR 624 0x10000000 ;MAS0:
WSPR 625 0x80000700 ;MAS1:
WSPR 626 0xf0000008 ;MAS2:
WSPR 627 0xf0000015 ;MAS3:
EXEC 0xfffff000
;
; Remove the L2SRAM from the initial MMU page
WM32 0xFF720000 0x28010000 ;L2CTL
;WM32 0xFF720000 0x28000000 ;L2CTL
;;;;;;;;;;;;;;;;;;;;;;;;;; TESTING END ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; move CCSR at 0x40000000
; CCSRBAR
; bit 12 - 23 - BASE_ADDR
WM32 0xFF700000 0x00040000
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; configure local access windows
; LAWBAR0
; bit 12 - 31 = 0x00000000 - base addr
WM32 0x40000c08 0x00000000
; LAWAR0
; bit 1 = 1 - enable window
; bit 8-11 = F - DDR
; bit 26 - 31 = 128MB - size
WM32 0x40000c10 0x80f0001a
; LAWBAR1
; bit 12 - 31 = 0xc0000000 - base addr
WM32 0x40000c28 0x000c0000
; LAWAR1
; bit 1 = 1 - enable window
; bit 8-11 = 4 - local bus
; bit 26 - 31 = 1GB - size
WM32 0x40000c30 0x8040001D
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;Interface enable
WM32 0x400E0070 0xc0000000
;ECM streaming
WM32 0x40001000 0x00000000
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; disable the memory interface with DDR_SDRAM_CFG[MEM_EN]
; DDR_SDRAM_CFG
WM32 0x40002110 0x42008000
; CS0_BNDS
WM32 0x40002000 0x00000007; DDR CS0 now 128MB
; CS0_CONFIG
WM32 0x40002080 0x80800101;0x80800202
; TIMING_CONFIG_1
WM32 0x40002108 0x26241341
; TIMING_CONFIG_2
WM32 0x4000210C 0x00001000
; DDR_SDRAM_MODE
WM32 0x40002118 0x00000062 ;0x00000022 ;old
; DDR_SDRAM_INTERVAL
WM32 0x40002124 0x05200000
; DDR_SDRAM_CLK_CNTL
WM32 0x40002130 0x83000000
DELAY 2000
; DDR_SDRAM_CFG
WM32 0x40002110 0xc2008000 ;0xc2000000 CS_old_value
DELAY 2000
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; configure local bus memory controller
; CS0 - Flash Bank ;0
WM32 0x40005000 0xFe001001 ;BR0 base address at 0xFF800000, port size 16 bit, GPCM, valid
WM32 0x40005004 0xFe006117 ;OR0 32MB flash size working for flash
;set the PC at the reset address (for debug-->connect)
WREG PC 0xfffffffc ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;; TESTING START ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Setup flash programming workspace in L2SRAM disable for now needs to check
;WM32 0x40020000 0x68010000 ;L2CTL
;WM32 0x40020100 0xf0000000 ;L2SRBAR0
;WM32 0x40020000 0xA8010000 ;L2CTL
;WSPR 63 0xf0000000 ;IVPR to workspace
;WSPR 415 0x0001500 ;IVOR15 : Debug exception
;WM32 0xf0001500 0x48000000 ;write valid instruction
;
; Setup flash programming workspace in dual port RAM
;WSPR 63 0x40080000 ;IVPR to workspace
;WSPR 415 0x000007F0 ;IVOR15 : Debug exception
;WM32 0x400807F0 0x48000000 ;write valid instruction
;
; Setup for program execution
WM32 0x40020000 0x28010000 ;L2CTL
WM32 0x40020000 0x28000000 ;L2CTL
WSPR 63 0x00000000 ;IVPR to workspace
WSPR 406 0x0000700 ;IVOR6 : Program exception
WSPR 415 0x0001500 ;IVOR15 : Debug exception
WM32 0x00000700 0x48000000 ;write valid instruction
WM32 0x00001500 0x48000000 ;write valid instruction
;
;;;;;;;;;;;;;;;;;;;;;;;;;; TESTING END ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[TARGET]
MMU XLAT ;Added to chech the mmu translation
CPUTYPE 8555 ;the CPU type
JTAGCLOCK 1 ;use 8 MHz JTAG clock
STARTUP RUN ; Start up with loop, halt, run
BREAKMODE HARD ;SOFT or HARD, HARD uses PPC hardware breakpoint
STEPMODE JTAG ;JTAG or HWBP, HWBP uses a hardware breakpoint
WAKEUP 200 ;give reset time to complete
POWERUP 1000 ;start delay after power-up detected in ms
MEMACCESS CORE ;use SAP or CORE for JTAG memory accesses
[HOST]
IP 172.16.4.9
FILE C:\BDI2000\u-boot.bin
FORMAT BIN 0x00080000
LOAD MANUAL ;load code MANUAL or AUTO after reset
PROMPT 8555BBCARD>
[FLASH]
CHIPTYPE STRATAX16
CHIPSIZE 0x2000000 ;The size of one flash chip in bytes
BUSWIDTH 16 SWAP ;The width of the flash memory bus in bits (8 | 16 | 32)
;WORKSPACE 0x0 ;workspace in RAM
FILE C:\BDI2000\u-boot.bin
FORMAT BIN 0xFFF80000
ERASE 0xFFF80000 ;erase sector 0
[REGS]
FILE C:\BDI2000\reg8560.def
HyperTerminal Boot Messages
=> imi 0x900000
## Checking Image at 00900000 ...
Image Name: Linux-2.6.10_mvl401-8555cds
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1245282 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
=> bootm 0x900000 0xb00000
## Booting image at 00900000 ...
Image Name: Linux-2.6.10_mvl401-8555cds
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1245282 Bytes = 1.2 M
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x03FADD00 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF2C
## Loading RAMDisk Image at 00b00000 ...
Image Name: uImage.ramdisk
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 2402307 Bytes = 2.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## initrd at 0x00B00040 ... 0x00D4
Loading Ramdisk to 03d62000, end 03fac803 ... OK
## Transferring control to Linux (at address 00000000) ...
Memory CAM mapping: CAM0=64Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.10_mvl401-8555cds (Administrator@Deepa) (gcc version 3.4.3 (Mo
ntaVista 3.4.3-25.0.70.0501961 2005-12-17)) #3 Thu Aug 30 18:28:00 IST 2007
CDS Version = 0 in PCI slot 1
Built 1 zonelists
Kernel command line: console=ttyS1,115200 root=/dev/ram rw ip=off
OpenPIC Version 1.2 (1 CPUs and 44 IRQ sources) at fbf76000
PID hash table entries: 512 (order: 9, 8192 bytes)
Warning: real time clock seems stuck!
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 59648k available (1968k kernel code, 700k data, 120k init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
desched cpu_callback 2/00000000
checking if image is initramfs...desched thread 0 s
it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 2346k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0001:01:00.0
PCI: Cannot allocate resource region 1 of device 0001:01:00.0
PCI: Failed to allocate mem resource #1:80000000@0 for 0001:01:00.0
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Generic RTC Driver v1.07
i8042.c: i8042 controller self test timeout.
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ s
ttyS0 at MMIO 0xe0004500 (irq = 106) is a 16550A
ttyS1 at MMIO 0xe0004600 (irq = 106) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: Gianfar Ethernet Controller Version 1.1, 00:e0:0c:00:00:fd
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.1, 00:e0:0c:00:01:f
eth1: Running with NAPI enabled
eth1: 256/256 RX/TX BD ring size
i2c /dev entries driver
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
elevator: using anticipatory as default io scheduler
physmap flash device: 1000000 at ff000000
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET: Registered protocol family 1
NET: Registered protoco
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 120k init
modprobe: FATAL: Could not load /lib/modules/2.6.10_mvl401-8555cds/modules.dep:
No such file or directory
modprobe: FATAL: Could not load /lib/modules/2.6.10_mvl401-8555cds/modules.dep:
No such file or directory
INIT: version 2.85 booting
0
Mounting a tmpfs over /dev...done.
Creating initial device nodes...done.
0
Mounting local filesystems: mount none on /var/run type tmpfs (rw)
none on /tmp type tmpfs (rw)
Starting hotplug subsystem:
pci
pci [success]
usb
usb [success]
isapnp
isapnp [success]
ide
ide [success]
input
input [success]
scsi
scsi [success]
done.
Starting portmap daemon: portmap/etc/rc.d/rcS.d/S41portmap: 156: nice: not found
INIT: Entering runlevel: 3
Starting internet superserver: inetd.
MontaVista(R) Linux(R) Professional Edition 4.0.1 (0502020)
(none) login:
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Breakpoint is not hitting for Kernel Debugging
2007-09-03 14:02 Breakpoint is not hitting for Kernel Debugging dnl
@ 2007-09-03 19:20 ` Dan Malek
2007-09-04 4:07 ` Bill F
1 sibling, 0 replies; 5+ messages in thread
From: Dan Malek @ 2007-09-03 19:20 UTC (permalink / raw)
To: dnl; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]
On Sep 3, 2007, at 7:02 AM, dnl wrote:
> Hi all,
>
> I am using uboot and montavista kernel for our custom MPC8555CDS
> board.
You should contact MontaVista first, since we really
don't know what your source code looks like. I'm
assuming it's a ppc, not powerpc, although the patch
is similar for either choice. I'd suggest this as a starting
point:
diff -Naru linux-2.6.21/arch/ppc/kernel/head_fsl_booke.S linux-2.6.21-
dbg/arch/ppc/kernel/head_fsl_booke.S
--- linux-2.6.21/arch/ppc/kernel/head_fsl_booke.S 2007-07-05
13:08:16.000000000 -0800
+++ linux-2.6.21-dbg/arch/ppc/kernel/head_fsl_booke.S 2007-07-10
03:45:33.000000000 -0800
@@ -317,6 +322,16 @@
/* clear any residual debug events */
li r2,-1
mtspr SPRN_DBSR,r2
+#else
+ /* Enable BDI200 debugging beyond this point for "normal"
+ * kernel debugging. If you are debugging code prior to this
+ * point, it needs to be done with more specific set up
+ * of configuration files and boot rom.
+ */
+ mfmsr r2
+ ori r2, r2, MSR_DE
+ mtmsr r2
+ isync
#endif
Your first breakpoint should be a hard breakpoint
at the label start_kernel. You can then switch to
soft breakpoints and continue your debugging.
Ultimate Solutions have some useful white papers
on kernel debugging with the BDI2000 (that some
people have plagiarized). Check out ultsol.com
Good Luck.
-- Dan
[-- Attachment #2: Type: text/html, Size: 2336 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Breakpoint is not hitting for Kernel Debugging
2007-09-03 14:02 Breakpoint is not hitting for Kernel Debugging dnl
2007-09-03 19:20 ` Dan Malek
@ 2007-09-04 4:07 ` Bill F
2007-09-05 13:27 ` Detlev Zundel
1 sibling, 1 reply; 5+ messages in thread
From: Bill F @ 2007-09-04 4:07 UTC (permalink / raw)
To: linuxppc-embedded
On 9/4/07, dnl <ssaravanan@mail2web.com> wrote:
> I enabled the following options in Kernel for kernel Debugging,
> CONFIG_BDI_SWITCH=y CONFIG_DEBUG_INFO=y under kernel hacking and MMU XALT in
> BDI config file. After uboot initialization I fixed break point at
> start_kernel(0xc02784bc), and then I booted the kernel. Without breaking at
> start_kernel, it came to login prompt. Please find attached config file with
> this mail. Could anybody help me to solve this problem?
Hi Saravanan,
Try adding this line to your BDI config to clear/invalidate the page
table base address so that the MMU translation works before the MMU
has been initialised.
;; Following is to clear the page table base address
WM32 0x000000f0 0x00000000
Make sure that you reload the BDI config, I use the the BDI "BOOT"
command to do this.
Are you obtaining the start_kernel address from your kernel System.map
file and setting the breakpoint using the BDI command "BI 0xc02784bc"
or are you using a gdb debugger frontend ?
Bill
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Breakpoint is not hitting for Kernel Debugging
2007-09-04 4:07 ` Bill F
@ 2007-09-05 13:27 ` Detlev Zundel
2007-09-05 16:31 ` Dan Malek
0 siblings, 1 reply; 5+ messages in thread
From: Detlev Zundel @ 2007-09-05 13:27 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
> Try adding this line to your BDI config to clear/invalidate the page
> table base address so that the MMU translation works before the MMU
> has been initialised.
>
> ;; Following is to clear the page table base address
> WM32 0x000000f0 0x00000000
Did you really need this under any circumstance? To only hit a
breakpoint?
I am asking because recent experiences with BDI debugging showed that
there are some pitfalls that one can fall into (and these are only the
ones that I got aware of):
a) - PTBASE is 0x00 (!) for head_fsl_booke, head_44x,
- PTBASE is 0xf0 for head_4xx
Don't ask me if this makes any sense, but that's how it is right
now.
So for the original poster I would say a PTBASE 0x0 would be in
order.
b) Moreover even with a _wrong_ PTBASE on a 440EPx the BDI translated
start_kernel just fine by only subtracting 0xc0000000 (using a
"default" translation) - it was only later (debugging dynamic
modules) that the wrong PTBASE hit me hard.
What proved very useful for me is the bdi command "phys <addr>" to
check the translation the BDI uses [you can use the command (as all
BDI commands) through gdb with "mon phys <addr>" btw.] - a wrong
PTBASE led to subsequent "JTAG instruction overruns" so I was pretty
sure that this was my real problem.
Best wishes
Detlev
--
The limits of my language stand for the limits of my world.
-- Ludwig Wittgenstein
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Breakpoint is not hitting for Kernel Debugging
2007-09-05 13:27 ` Detlev Zundel
@ 2007-09-05 16:31 ` Dan Malek
0 siblings, 0 replies; 5+ messages in thread
From: Dan Malek @ 2007-09-05 16:31 UTC (permalink / raw)
To: Detlev Zundel; +Cc: linuxppc-embedded
On Sep 5, 2007, at 6:27 AM, Detlev Zundel wrote:
> Hi,
>
>> ;; Following is to clear the page table base address
>> WM32 0x000000f0 0x00000000
>
> Did you really need this under any circumstance? To only hit a
> breakpoint?
No, you don't. For the identify mapped kernel
space, only the MMU XLAT is required, which
covers nearly all kernel. This is only necessary for
tracking vmalloc()'ed space, like for loadable
modules.
However, this WM32 should not be necessary
in any case, as the page table pointers for
BDI information tracking are set up by the
kernel initialization functions.
> I am asking because recent experiences with BDI debugging showed that
> there are some pitfalls that one can fall into (and these are only the
> ones that I got aware of):
Yes, and I apologize for not allocating the
time to work with Abatron to make this
work better. The page tables changes
that have taken (and still take) place in
2.6 caused our original 2.4 implementation
to not work well. Abatron has made updates
that work well, but there are still some edge
cases that may not work well. I need to find
those and provide some assistance.
The whole of the Linux BDI configuration
has been abused as well, the BDI_SWITCH
should not be used as it is today. That
was not the intention for this particular
configuration option.
> So for the original poster I would say a PTBASE 0x0 would be in
> order.
It changes a little among the processor variants,
in particular traditional Power versus Book E.
Check the release notes and manuals for the
BDI2000, along with the information from
Ultimate Solutions to determine what is best.
> b) Moreover even with a _wrong_ PTBASE on a 440EPx the BDI translated
> start_kernel just fine by only subtracting 0xc0000000 (using a
> "default" translation) - it was only later (debugging dynamic
> modules) that the wrong PTBASE hit me hard.
That's correct. If the BDI firmware can find the
translation in the TLB, it will just use that. In the
case of many processors, this is either a wired
entry or a BAT. If the BDI firmware can't find
a valid translation, it walks the page tables.
For 8xx and some 40x, the PTBASE is required
as there may be no wired entries by default.
Just remember that the values for both MMU XLAT
and PTBASE must match the kernel software and
configuration. This is the only correct answer :-)
Documentation will describe the public source,
default configuration at the time of the writing,
but it's very easy to change and will cause
debugging problems.
Thanks.
-- Dan
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-09-05 16:31 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-03 14:02 Breakpoint is not hitting for Kernel Debugging dnl
2007-09-03 19:20 ` Dan Malek
2007-09-04 4:07 ` Bill F
2007-09-05 13:27 ` Detlev Zundel
2007-09-05 16:31 ` Dan Malek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).