Hi Drew, On 4/19/21 4:56 PM, Alexandru Elisei wrote: > Hi Drew, > > On 4/15/21 6:25 PM, Andrew Jones wrote: >> On Thu, Apr 15, 2021 at 05:59:19PM +0100, Alexandru Elisei wrote: >>> Hi Drew, >>> >>> On 4/7/21 7:59 PM, Andrew Jones wrote: >>>> Keep as much memory layout assumptions as possible in init::start >>>> and a single setup function. This prepares us for calling setup() >>>> from different start functions which have been linked with different >>>> linker scripts. To do this, stacktop is only referenced from >>>> init::start, making freemem_start a parameter to setup(). We also >>>> split mem_init() into three parts, one that populates the mem regions >>>> per the DT, one that populates the mem regions per assumptions, >>>> and one that does the mem init. The concept of a primary region >>>> is dropped, but we add a sanity check for the absence of memory >>>> holes, because we don't know how to deal with them yet. >>>> >>>> Signed-off-by: Andrew Jones <drjones@xxxxxxxxxx> >>>> --- >>>> arm/cstart.S | 4 +- >>>> arm/cstart64.S | 2 + >>>> arm/flat.lds | 23 ++++++ >>>> lib/arm/asm/setup.h | 8 +-- >>>> lib/arm/mmu.c | 2 - >>>> lib/arm/setup.c | 165 ++++++++++++++++++++++++-------------------- >>>> 6 files changed, 123 insertions(+), 81 deletions(-) >>>> >>>> diff --git a/arm/cstart.S b/arm/cstart.S >>>> index 731f841695ce..14444124c43f 100644 >>>> --- a/arm/cstart.S >>>> +++ b/arm/cstart.S >>>> @@ -80,7 +80,9 @@ start: >>>> >>>> /* complete setup */ >>>> pop {r0-r1} >>>> - bl setup >>>> + mov r1, #0 >>> Doesn't that mean that for arm, the second argument to setup() will be 0 instead >>> of stacktop? >> The second argument is 64-bit, but we assume the upper 32 are zero. > I didn't realize that phys_addr_t is 64bit. > > According to ARM IHI 0042F, page 15: > > "A double-word sized type is passed in two consecutive registers (e.g., r0 and r1, > or r2 and r3). The content of the registers is as if the value had been loaded > from memory representation with a single LDM instruction." > > I think r3 should be zeroed, not r1. r2 and r3 represent the 64bit value. arm is > little endian, so the least significant 32bits will be in r2 and the most > significant bits will be in r3. I can't figure out why r3 is zero, but moving the Correction: r3 is zero because KVM zeroes the general purpose registers on vcpu reset. Thanks, Alex