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