[Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Alexander Graf]

OpenBIOS searches for the preloaded kernel at 0x1000000, so let's
put it there instead of an invalid location.

Using this patch I was able to use -kernel for a current openSUSE
11.1 kernel.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/ppc_oldworld.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
index 042a40f..0af2436 100644
--- a/hw/ppc_oldworld.c
+++ b/hw/ppc_oldworld.c
@@ -209,7 +209,7 @@ static void ppc_heathrow_init (ram_addr_t ram_size, int vga_ram_size,
     if (linux_boot) {
         kernel_base = KERNEL_LOAD_ADDR;
         /* now we can load the kernel */
-        kernel_size = load_elf(kernel_filename, kernel_base - 0xc0000000ULL,
+        kernel_size = load_elf(kernel_filename, KERNEL_LOAD_ADDR,
                                NULL, NULL, NULL);
         if (kernel_size < 0)
             kernel_size = load_aout(kernel_filename, kernel_base,
-- 
1.6.0.2

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Aurelien Jarno]

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.

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.

> Using this patch I was able to use -kernel for a current openSUSE
> 11.1 kernel.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  hw/ppc_oldworld.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
> index 042a40f..0af2436 100644
> --- a/hw/ppc_oldworld.c
> +++ b/hw/ppc_oldworld.c
> @@ -209,7 +209,7 @@ static void ppc_heathrow_init (ram_addr_t ram_size, int vga_ram_size,
>      if (linux_boot) {
>          kernel_base = KERNEL_LOAD_ADDR;
>          /* now we can load the kernel */
> -        kernel_size = load_elf(kernel_filename, kernel_base - 0xc0000000ULL,
> +        kernel_size = load_elf(kernel_filename, KERNEL_LOAD_ADDR,
>                                 NULL, NULL, NULL);
>          if (kernel_size < 0)
>              kernel_size = load_aout(kernel_filename, kernel_base,
> -- 
> 1.6.0.2
> 
> 
> 
> 

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Alexander Graf]

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?

Alex

>
>
>> Using this patch I was able to use -kernel for a current openSUSE
>> 11.1 kernel.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> hw/ppc_oldworld.c |    2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
>> index 042a40f..0af2436 100644
>> --- a/hw/ppc_oldworld.c
>> +++ b/hw/ppc_oldworld.c
>> @@ -209,7 +209,7 @@ static void ppc_heathrow_init (ram_addr_t  
>> ram_size, int vga_ram_size,
>>     if (linux_boot) {
>>         kernel_base = KERNEL_LOAD_ADDR;
>>         /* now we can load the kernel */
>> -        kernel_size = load_elf(kernel_filename, kernel_base -  
>> 0xc0000000ULL,
>> +        kernel_size = load_elf(kernel_filename, KERNEL_LOAD_ADDR,
>>                                NULL, NULL, NULL);
>>         if (kernel_size < 0)
>>             kernel_size = load_aout(kernel_filename, kernel_base,
>> -- 
>> 1.6.0.2
>>
>>
>>
>>
>
> -- 
> Aurelien Jarno	                        GPG: 1024D/F1BCDB73
> aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Aurelien Jarno]

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.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Alexander Graf]

On 25.01.2009, at 00:59, Aurelien Jarno <aurelien@aurel32.net> 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.
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.

Alex

>
>
> -- 
> Aurelien Jarno                            GPG: 1024D/F1BCDB73
> aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Aurelien Jarno]

On Sun, Jan 25, 2009 at 01:28:36AM +0100, Alexander Graf wrote:
>
>
>
>
> On 25.01.2009, at 00:59, Aurelien Jarno <aurelien@aurel32.net> 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.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Alexander Graf]

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 <aurelien@aurel32.net> 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?

Alex

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Edgar E. Iglesias]

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 <aurelien@aurel32.net> 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

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Alexander Graf]

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 <aurelien@aurel32.net>  
>>>> 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.

Btw - is cdrom booting supported yet?

Alex

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Alexander Graf]

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 <aurelien@aurel32.net>  
>>>>> 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.

Alex

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[Aurelien Jarno]

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 <aurelien@aurel32.net>  
>>>>>> 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
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[François Revol]

> Ah :-). Does anyone have an old and a Haiku kernel lying around he
> could point me to so I can write a small patch?

I've put a loader here
http://revolf.free.fr/beos/boot_loader_openfirmware

Note it has 2 segments, though it can probably changed.

François.

Re: [Qemu-devel] [PATCH] Fix -kernel on target-ppc

[François Revol]

> >> 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.

The Haiku bootloader currently has both a text and data segment, but I
suppose I can easily change the ldscript.
It's not exactly a kernel but it's what is supposed to be loaded
because we have our own way to load modules and setup things.

I'd only need -kernel to ease testing anyway, I'd rather have OpenBIOS
actually read the ISO/HFS image and dig the loader from there...
The available commands seem a bit scarce.

François.