RE: What does soft-mmu mean? What happens when we set MMU registers? (aarch64)

[ckim]

Hi,
I've mistakenly did objdump for the .elf file. The text section started at 
0x10000 from the start of .elf flie,
So it appeared the text section was at 0x10000. If I do objdump with the .bin 
file, it correctly shows the .text section (including the bootcode) at 0.
So loading address seems to be correct( at zero) and I'll look into other 
things.
Thank you!
Chan Kim


> -----Original Message-----
> From: Peter Maydell <peter.maydell@linaro.org>
> Sent: Wednesday, March 10, 2021 8:07 PM
> To: Chan Kim <ckim@etri.re.kr>
> Cc: qemu-discuss <qemu-discuss@nongnu.org>
> Subject: Re: What does soft-mmu mean? What happens when we set MMU
> registers? (aarch64)
> 
> On Wed, 10 Mar 2021 at 08:31, <ckim@etri.re.kr> wrote:
> >
> > Hello, Peter Maydell,
> >
> > I've added print in get_phys_addr at the entrance 'printf("address =
> > %llx\n", address);'
> > And found actualy it's called not that many times. (3 or 4 times
> > before this thing happens) Right after I set sctlr_el3 register, this
> get_phys_addr is again called. And I get
> >         Address = 28c.
> > But when I see the objdump code, it is like
> >
> >    1027c:   d53ec002    mrs x2, vbar_el3
> >    10280:   d5380702    mrs x2, id_aa64mmfr0_el1
> >    10284:   d53e2042    mrs x2, tcr_el3
> >    10288:   d51e1000    msr sctlr_el3, x0   <=== trap seems to happen here
> >    1028c:   d51c1000    msr sctlr_el2, x0    <=== accessing virtual address
> 28c, not 1028c.
> >    10290:   d5181000    msr sctlr_el1, x0
> >    10294:   d5034fff    msr daifclr, #0xf
> >    10298:   d53e1100    mrs x0, scr_el3
> >    1029c:   b27e0000    orr x0, x0, #0x4
> >
> > The next command (msr sctlr_el2, x0) is at 0x1028c, but the
> > get_phy_addr function was called with virtual address 0x28c. Is this
> > normal? I don't know why there is this difference of 0x10000.(0x10000
> > is the start address of page table)
> 
> You can see from your previous trace that you are executing from 0x28x,
> not 0x1028x. Your code was probably linked to load at 0x10000, which is
> why objdump output looks like that, but you have told QEMU to load it at
> 0x0, which is what is actually happening at runtime.
> 
> thanks
> -- PMM