Relocating bootwrapper causes kernel panic

[Scott Wood]

On Thu, 5 Aug 2010 00:23:17 -0700
Shawn Jin <shawnxjin at gmail.com> wrote:

> >> The flat tree located at 0xbe4300 as the kerne message showed. Why
> >> cannot the kernel access this area? No TLB set for this area?
> >>
> >> <1>Unable to handle kernel paging request for data at address 0xc0be4308
> >> <1>Faulting instruction address: 0xc01fdabc
> >> <4>Oops: Kernel access of bad area, sig: 11 [#1]
> >
> > Before the flat tree was accessed, I checked the DTLB and didn't find
> > any entry related to 0xc0be4300. After the exception, I found the
> > following DTLBs.
> >
> > 30 : 02  c0be4000   4KB ------ -> 00000000
> > 31 : 00  fa000000   8MB VI-S-M -> fa000000
> >
> > The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this
> > should be something like 00be4000?

Note that the valid bit is clear -- it's not mapping to anything.

> When the early_debug is enabled, the kernel can boot successfully. I
> checked the TLB settings and found the following.
> 
> 28 : 00  c0000000   8MB V--S-M -> 00000000
> 29 : 00  fa000000   8MB VI-S-M -> fa000000
> 30 : 00  c0800000   8MB V--S-M -> 00800000
> 31 : 14  04919000   ?KB V---WM -> 00e45000

That last entry looks weird... might want to look into that.

> So the kernel can access the dtb at 0xbe4300 because of the pinned down DTLB#30.
> 
> I think the cause is clear now. But how to fix it? Two questions:
> 1. Should this DTLB miss exception properly set a new TLB entry for
> the new dtb address 0xbe4300?

Not if it doesn't find an entry in the page tables.

> 2. If the DTLB miss exception handler is not the right guy to load a
> proper TLB entry, how can I set one entry based on the link_address
> and the address of the flat dt blob?

Given how early in the boot process it is, it's probably going to need
to be handled specially.

-Scott