From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 16:57:03 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7416142B for ; Thu, 28 Feb 2013 16:57:03 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 47E3E19C for ; Thu, 28 Feb 2013 16:57:02 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1SGus6E044986; Thu, 28 Feb 2013 16:56:54 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id hfe6p3ud2mdx8n9w63a2ref7t6; Thu, 28 Feb 2013 16:56:54 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <1A428660-39FB-45EB-979B-103F7E83BC4A@bsdimp.com> Date: Thu, 28 Feb 2013 08:56:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1F9B0ED4-7FAF-43D8-BECD-1D42792E81DF@freebsd.org> References: <1A428660-39FB-45EB-979B-103F7E83BC4A@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 16:57:03 -0000 On Feb 27, 2013, at 10:41 PM, Warner Losh wrote: >=20 > On Feb 27, 2013, at 11:27 PM, Tim Kientzle wrote: >=20 >> Starting to look at what is needed for a Generic ARM kernel. >> There's a lot here; I sincerely hope I'm not the only one=85 ;-) >>=20 >> First up: Can we get rid of PHYSADDR? >=20 > There's lots of places in the tree that use it, but not so many that a = whack-a-mole approach wouldn't work. It's mostly only used in locore.S and machdep.c (and, of course, the many copies of machdep.c). >> I think we can always compute it at runtime from PC. >>=20 >> For example, I think this works in several places: >> and r0, pc, #0xF0000000 >=20 > This only works early in boot before we've turned on the MMU, right? I'm still pretty new to this section of the code, so might have missed something, but I don't think we need PHYSADDR after the kernel has relocated itself. Do we? >=20 >> And I've found at least one reference that I think can be simply >> eliminated: >>=20 >> Index: arm/elf_trampoline.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- arm/elf_trampoline.c (revision 247250) >> +++ arm/elf_trampoline.c (working copy) >> @@ -169,7 +169,7 @@ >> void >> _startC(void) >> { >> - int physaddr =3D KERNPHYSADDR; >> + unsigned int physaddr =3D (unsigned int)&_start & 0xfffff000; >=20 > How'd you come up with this? Perhaps we should just define = KERNPHYSADDR as this gross expression :) >=20 > But isn't _start a virtual address, not a physical address? Honestly, I'm still trying to figure that part out. ;-) Disassembling the compiler output, taking the address of the current function always uses a PC-relative address. So &_startC here would give the current address of the function as it's executing. >=20 >> int tmp1; >> unsigned int sp =3D ((unsigned int)&_end & ~3) + 4; >> #if defined(FLASHADDR) && defined(LOADERRAMADDR) >> @@ -189,10 +189,9 @@ >> */ >> unsigned int target_addr; >> unsigned int tmp_sp; >> - uint32_t src_addr =3D (uint32_t)&_start - PHYSADDR + = FLASHADDR >> - + (pc - FLASHADDR - ((uint32_t)&_startC - PHYSADDR)) = & 0xfffff000; >> + uint32_t src_addr =3D (uint32_t)&_start; >=20 > I'm not sure how this works=85 Here's my reasoning: FLASHADDR and PHYSADDR are always multiples of 4k, so you can pull those out of the parentheses to get: _start - PHYSADDR + FLASHADDR - FLASHADD + PHYSADDR + (pc - _startC) = & 0xffffff000 And since pc was sampled early in _startC, the last expression should always be zero. I was a little surprised by this myself, so I might have missed something. >> - target_addr =3D (unsigned int)&_start - PHYSADDR + = LOADERRAMADDR; >> + target_addr =3D (unsigned int)&_start - (pc & = 0xf0000000) + LOADERRAMADDR; >=20 > This might work, but I'd suggest a PC_TO_PHYSADDR(pc) macro or = something similar=85 I'll try that later on. I suspect some of these PHYSADDRs will simply go away, since I think what we really want in the early bootstrap stage is just "what address is the kernel currently executing at". I still need to piece together some more things before I understand that. As with the above, at least some of the expressions using PHYSADDR seem more complex than necessary. >> tmp_sp =3D target_addr + 0x100000 + >> (unsigned int)&_end - (unsigned int)&_start; >> memcpy((char *)target_addr, (char *)src_addr, >>=20 >>=20 >> Tim >>=20 >=20