U-Boot page tables

[Branden Sherrell]

Hi,

I have an odd issue that I’m trying to debug on a rockpro64 board. I’m using uboot to load grub, which then boots small test payload that was linked at a fixed address. The code has a simple relocation scheme at the beginning to move itself to this link address if it was loaded somewhere else. This mostly works, except I have a bug that’s causing me some trouble. So I wanted to use uboot shell to inspect memory. I noticed some odd behavior so I wrote a simple payload:

	• Uboot -> grub -> payload
	• Write a constant to 0xf7000000
	• Cause an exception

After #3 (which is handled by uboot’s intact VBAR), I stop in the uboot shell and inspect memory. I see this:

=> md.l f7000000 32
f7000000: deafbeff febdffff deadbeef dfadbfef    ................
f7000010: debdbeef ffafbeff debdbeef feedffef    ................
f7000020: dfafbfef dfefffef feadbeef deadbfee    ................
f7000030: deadbeff feedfeff dffdfeff feadfeef    …………….

So I use uboot to write constant to memory to set a known state:

=> mw.l f7000000 abcdabcd 32
=> md.l f7000000 32
f7000000: abcdabcd abcdabcd abcdabcd abcdabcd    ................
f7000010: abcdabcd abcdabcd abcdabcd abcdabcd    ................
f7000020: abcdabcd abcdabcd abcdabcd abcdabcd    ................
f7000030: abcdabcd abcdabcd abcdabcd abcdabcd    …………….

I run the payload again, noting the uboot register dump:

"Synchronous Abort" handler, esr 0x96000004
elr: ffffffffc0651050 lr : 000000000025b498 (reloc)
elr: 00000000b4393050 lr : 00000000f3f9d498
x0 : 00000000f1f503c0 x1 : cafebabeaaaaaaaa
x2 : 00000000b4393000 x3 : 0000000000000000
x4 : 0000000000000010 x5 : 00000000b4392000
x6 : 00000000f7000000 x7 : 00000000f3fbe668
x8 : 00000000f1f6c440 x9 : 00000000f1f26de0
x10: 00000000f1f26e98 x11: 00000000fffffffe
x12: 000000000000200d x13: 000000000000000a
x14: 0000000000000014 x15: 00000000ff1a0000
x16: 000000000000005a x17: 00000000f0c18ca0
x18: 00000000f0e96b88 x19: 00000000f3f42c10
x20: deadbeefdeadbeef x21: 00000000f09b1f8c
…

The ELR was given as 0xb4393050. Checking the appropriate offset in my payload shows (PIC code until this point):

    f7001018:   d2bee01b        mov     x27, #0xf7000000
    f700101c:   f2f95fc1        movk    x1, #0xcafe, lsl #48
    f7001020:   f2d757c1        movk    x1, #0xbabe, lsl #32
    f7001024:   f2b55541        movk    x1, #0xaaaa, lsl #16
    f7001028:   f2955541        movk    x1, #0xaaaa
    f700102c:   f8008761        str     x1, [x27], #8
    f7001030:   f8008761        str     x1, [x27], #8
    f7001034:   f8008761        str     x1, [x27], #8
    f7001038:   f8008761        str     x1, [x27], #8
    f700103c:   f8008761        str     x1, [x27], #8
    f7001040:   f2fbd5b4        movk    x20, #0xdead, lsl #48
    f7001044:   f2d7ddf4        movk    x20, #0xbeef, lsl #32
    f7001048:   f2bbd5b4        movk    x20, #0xdead, lsl #16
    f700104c:   f297ddf4        movk    x20, #0xbeef
    f7001050:   f9400295        ldr     x21, [x20] 			<— exception

And after running the payload again, I inspect memory:

=> md.l f7000000 32
f7000000: abcdabcd abcdabcd abcdabcd abcdabcd    ................
f7000010: abcdabcd abcdabcd abcdabcd abcdabcd    ................
f7000020: abcdabcd abcdabcd abcdabcd abcdabcd    ................
f7000030: abcdabcd abcdabcd abcdabcd abcdabcd    …………….

Noticing there was no change. I realize this is not a u-boot specific issue, but I mention all the above if nothing else but background context. The question I emailed this list for in particular was for debugging techniques within uboot. I searched around but did not find much information on the runtime environment within uboot. Does it use 1:1 page table mappings at all times? The MMU should be disabled when payloads get execution, so I am unsure what the issue could be here regarding why memory read in the shell might be different than expected.

In particular, is there a supported mechanism for dumping uboot page tables? Or evaluating a particular VA -> PA map?


Thanks,
Branden