From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 21:02:27 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 E9EA0895; Thu, 28 Feb 2013 21:02:27 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6B70A1F6; Thu, 28 Feb 2013 21:02:27 +0000 (UTC) Received: from rnote.ddteam.net (12-60-135-95.pool.ukrtel.net [95.135.60.12]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 87EE4C4930; Thu, 28 Feb 2013 23:02:19 +0200 (EET) Date: Thu, 28 Feb 2013 23:02:03 +0200 From: Aleksandr Rybalko To: Tim Kientzle Subject: Re: PHYSADDR Message-Id: <20130228230203.e6228ff1.ray@freebsd.org> In-Reply-To: <1F9B0ED4-7FAF-43D8-BECD-1D42792E81DF@freebsd.org> References: <1A428660-39FB-45EB-979B-103F7E83BC4A@bsdimp.com> <1F9B0ED4-7FAF-43D8-BECD-1D42792E81DF@freebsd.org> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 21:02:28 -0000 On Thu, 28 Feb 2013 08:56:54 -0800 Tim Kientzle wrote: > > On Feb 27, 2013, at 10:41 PM, Warner Losh wrote: > > > > > On Feb 27, 2013, at 11:27 PM, Tim Kientzle wrote: > > > >> 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… ;-) > >> > >> First up: Can we get rid of PHYSADDR? > > > > 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. > >> > >> For example, I think this works in several places: > >> and r0, pc, #0xF0000000 > > > > 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? > > > > >> And I've found at least one reference that I think can be simply > >> eliminated: > >> > >> Index: arm/elf_trampoline.c > >> =================================================================== > >> --- arm/elf_trampoline.c (revision 247250) > >> +++ arm/elf_trampoline.c (working copy) > >> @@ -169,7 +169,7 @@ > >> void > >> _startC(void) > >> { > >> - int physaddr = KERNPHYSADDR; > >> + unsigned int physaddr = (unsigned int)&_start & > >> 0xfffff000; > > > > How'd you come up with this? Perhaps we should just define > > KERNPHYSADDR as this gross expression :) > > > > 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. > > > > >> int tmp1; > >> unsigned int sp = ((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 = (uint32_t)&_start - PHYSADDR > >> + FLASHADDR > >> - + (pc - FLASHADDR - ((uint32_t)&_startC - > >> PHYSADDR)) & 0xfffff000; > >> + uint32_t src_addr = (uint32_t)&_start; > > > > I'm not sure how this works… > > 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 = (unsigned int)&_start - PHYSADDR + > >> LOADERRAMADDR; > >> + target_addr = (unsigned int)&_start - (pc & > >> 0xf0000000) + LOADERRAMADDR; > > > > This might work, but I'd suggest a PC_TO_PHYSADDR(pc) macro or > > something similar… > > 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 = target_addr + 0x100000 + > >> (unsigned int)&_end - (unsigned int)&_start; > >> memcpy((char *)target_addr, (char *)src_addr, > >> > >> > >> Tim > >> > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" We will have problems sometime with pc & 0xf0000000, because a lot of hardware already on market with RAM size more than 256M. So if loader load kernel higher than 256M with 0xf0000000 mask we will assume wrong segment start address. IMO we need to get such info from DTB and better to parse it with loader(8), then pass it with kenv to kernel. Since FDT already have info about physical RAM location you can calculate difference and make decision to move kernel lower, like trampoline do. Thanks! WBW -- Aleksandr Rybalko