[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc
From: |
Aurelien Jarno |
Subject: |
Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc |
Date: |
Sun, 25 Jan 2009 11:50:29 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Sun, Jan 25, 2009 at 11:28:28AM +0100, Alexander Graf wrote:
>
> On 25.01.2009, at 11:24, Alexander Graf wrote:
>
>>
>> On 25.01.2009, at 11:16, Edgar E. Iglesias wrote:
>>
>>> 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 <address@hidden>
>>>>>> 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
>>
>> Ah :-). Does anyone have an old and a Haiku kernel lying around he
>> could point me to so I can write a small patch?
>>
>> Also has anyone gotten console output from loaded kernels? For me the
>> kernel switches consoles from udbg0 to .. eh ... something. And after
>> that nothing gets displayed anymore. -append console=ttyS0 doesn't work
>> either.
>
> Scratch that part. -append console=ttyS0 causes the console switching
> which doesn't work. Normal fb does seem fine.
>
If you have a recent kernel, try ttyPZ0 instead.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
address@hidden http://www.aurel32.net
- [Qemu-devel] [PATCH] Fix -kernel on target-ppc, Alexander Graf, 2009/01/24
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc, Aurelien Jarno, 2009/01/24
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc, Alexander Graf, 2009/01/24
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc, Aurelien Jarno, 2009/01/24
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc, Alexander Graf, 2009/01/24
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc, Aurelien Jarno, 2009/01/25
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc, Alexander Graf, 2009/01/25
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc, Edgar E. Iglesias, 2009/01/25
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc, Alexander Graf, 2009/01/25
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc, Alexander Graf, 2009/01/25
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc,
Aurelien Jarno <=
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc, François Revol, 2009/01/25
- Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc, François Revol, 2009/01/24