From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LR22h-0004U9-Qu for qemu-devel@nongnu.org; Sun, 25 Jan 2009 05:16:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LR22h-0004T9-6U for qemu-devel@nongnu.org; Sun, 25 Jan 2009 05:16:39 -0500 Received: from [199.232.76.173] (port=47859 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LR22g-0004Sr-TS for qemu-devel@nongnu.org; Sun, 25 Jan 2009 05:16:38 -0500 Received: from bart.se.axis.com ([195.60.68.10]:39490) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LR22g-0000j0-4Z for qemu-devel@nongnu.org; Sun, 25 Jan 2009 05:16:38 -0500 Received: from bart.se.axis.com (bart.se.axis.com [127.0.0.1]) by bart.se.axis.com (Postfix) with ESMTP id 4653C64092 for ; Sun, 25 Jan 2009 11:16:36 +0100 (CET) Received: from axis.com (edgar.se.axis.com [10.93.151.1]) by bart.se.axis.com (Postfix) with ESMTP id 34D4164045 for ; Sun, 25 Jan 2009 11:16:36 +0100 (CET) Date: Sun, 25 Jan 2009 11:16:36 +0100 From: "Edgar E. Iglesias" Subject: Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc Message-ID: <20090125101636.GA12918@edgar.se.axis.com> References: <1232830715-20476-1-git-send-email-agraf@suse.de> <20090124214840.GG19498@hall.aurel32.net> <20090124235908.GE16336@volta.aurel32.net> <20090125095443.GI19498@hall.aurel32.net> <2FBDAD19-BB46-433D-9515-3FCECDB6ADC7@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2FBDAD19-BB46-433D-9515-3FCECDB6ADC7@suse.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-devel@nongnu.org" , Aurelien Jarno On Sun, Jan 25, 2009 at 11:03:47AM +0100, Alexander Graf wrote: > > On 25.01.2009, at 10:54, Aurelien Jarno wrote: > >> On Sun, Jan 25, 2009 at 01:28:36AM +0100, Alexander Graf wrote: >>> >>> >>> >>> >>> On 25.01.2009, at 00:59, Aurelien Jarno wrote: >>> >>>> On Sat, Jan 24, 2009 at 10:57:19PM +0100, Alexander Graf wrote: >>>>> >>>>> On 24.01.2009, at 22:48, Aurelien Jarno wrote: >>>>> >>>>>> On Sat, Jan 24, 2009 at 09:58:35PM +0100, Alexander Graf wrote: >>>>>>> OpenBIOS searches for the preloaded kernel at 0x1000000, so let's >>>>>>> put it there instead of an invalid location. >>>>>> >>>>>> Your patch is actually wrong, the second argument of load_elf() is >>>>>> an >>>>>> offset to the physical address (as found in the elf header), and >>>>>> not a >>>>>> load address. >>>>>> >>>>>> By chance the physical address of a >= 2.6.25 kernel is >>>>>> 0x00000000, so >>>>>> your patch works. But it will break supports for < 2.6.25 kernel as >>>>>> their physical address is 0xc0000000. Not that they are only the >>>>>> default >>>>>> values, they can be changed in the .config file. >>>>> >>>>> Aah, that explains why :-). >>>>> >>>>>> I have already proposed a patch to use the virtual address of the >>>>>> elf >>>>>> header as done by yaboot or quik, but I have been told it is >>>>>> actually >>>>>> wrong. >>>>>> >>>>>> We have to find another way to load the elf file at a fixed address. >>>>> >>>>> Hm - can't we just give load_elf an override value for the base >>>>> address? >>>>> >>>>> /* address_offset is hack for kernel images that are >>>>> linked at the wrong physical address. */ >>>>> addr = ph->p_paddr + address_offset; >>>>> >>>>> cpu_physical_memory_write_rom(addr, data, mem_size); >>>>> >>>>> Just pass another variable here that overrides addr and doesn't >>>>> calculate it? >>>> >>>> Except that they can be more than one segment to load, so the last one >>>> will overwrite the previous ones. The PowerPC kernels I have seen only >>>> have one load segment, but I am not sure it is always the case. >>> >>> But then the addr hack wouldn't work either, right? It's just a question >>> if addr_offset is relative or absolute here. >> >> addr_offset is just an offset that is added to the load address of the >> elf header. >> >>> And fwiw in this case relative to the elf header's value doesn't make >>> any sense at all when the firmware expects the blob on a specific >>> address. >> >> As far as I understand it has been done like that to be able to support >> multiple segments. If the elf header says that the first segment has to >> be loaded at 0xc0000000 and the second at 0xd0000000, loading both at >> 0x10000000 won't work. Loading them with an offset of -0xb000000 will >> load the first one at 0x10000000 and the second one just after at >> 0x20000000. > > Aaah I'm starting to see the picture now :-). Sorry, I probably shouldn't > do this on a weekend at night. > > So at least for the Linux kernel case it would be enough to know which > lowest address the kernel is loaded to, right? Because that's what we need > to use as negative offset. > > So if we call load_elf twice, once to get the lowest address the binary is > loaded to (lowaddr) and the second one to actually load it, this should at > least fix it for Linux without breaking multiple segment support, as long > as the first segment is the text segment. > > Am I getting this right? I think so, that same kind of speculative loading is what I had in mind: http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg00438.html Best regards