[Qemu-devel] [PATCH 0/3] PPC PReP: Use ElF kernel on PReP

[Qemu-devel] [PATCH 0/3] PPC PReP: Use ElF kernel on PReP

[Fabien Chouteau]

This patches serie implements ELF kernel support in PPC PReP board.

 - Being able to load an ELF file
 - Use the entry point to set nip value a reset
 - Allow to run the board without bios

Fabien Chouteau (3):
  PPC PReP: Load ELF kernel
  PPC PReP: Use kernel entry to set nip at reset
  PPC PReP: can run without bios image

 hw/ppc/prep.c |   67 ++++++++++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 54 insertions(+), 13 deletions(-)

-- 
1.7.9.5

[Qemu-devel] [PATCH 1/3] PPC PReP: Load ELF kernel

[Fabien Chouteau]

It is useful to be able to boot non-binary (i.e. ELF) kernels directly,
as it is simpler to use and it makes symbols available in -d in_asm.

Also remove, unnecessary exit() after hw_error().

Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
---
 hw/ppc/prep.c |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 2920911..a2730c8 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -41,6 +41,7 @@
 #include "sysemu/blockdev.h"
 #include "sysemu/arch_init.h"
 #include "exec/address-spaces.h"
+#include "elf.h"
 
 //#define HARD_DEBUG_PPC_IO
 //#define DEBUG_PPC_IO
@@ -521,12 +522,17 @@ static void ppc_prep_init(QEMUMachineInitArgs *args)
 
     if (linux_boot) {
         kernel_base = KERNEL_LOAD_ADDR;
-        /* now we can load the kernel */
-        kernel_size = load_image_targphys(kernel_filename, kernel_base,
-                                          ram_size - kernel_base);
+
+        /* Try to load the kernel as an ELF file */
+        kernel_size = load_elf(kernel_filename, NULL, NULL, NULL, NULL, NULL,
+                               1, ELF_MACHINE, 0);
+        if (kernel_size < 0) {
+            /* Try to load the kernel as an binary file */
+            kernel_size = load_image_targphys(kernel_filename, kernel_base,
+                                              ram_size - kernel_base);
+        }
         if (kernel_size < 0) {
             hw_error("qemu: could not load kernel '%s'\n", kernel_filename);
-            exit(1);
         }
         /* load initrd */
         if (initrd_filename) {
-- 
1.7.9.5

[Qemu-devel] [PATCH 2/3] PPC PReP: Use kernel entry to set nip at reset

[Fabien Chouteau]

When we load an ELF kernel we can start the board at the entry point.

Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
---
 hw/ppc/prep.c |   34 ++++++++++++++++++++++++++++++----
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index a2730c8..12198ff 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -56,6 +56,12 @@
 #define KERNEL_LOAD_ADDR 0x01000000
 #define INITRD_LOAD_ADDR 0x01800000
 
+typedef struct ResetData {
+    PowerPCCPU   *cpu;
+    bool          use_entry;
+    target_ulong  entry;        /* save kernel entry in case of reset */
+} ResetData;
+
 #if defined (HARD_DEBUG_PPC_IO) && !defined (DEBUG_PPC_IO)
 #define DEBUG_PPC_IO
 #endif
@@ -425,8 +431,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
 
 static void ppc_prep_reset(void *opaque)
 {
-    PowerPCCPU *cpu = opaque;
+    ResetData  *s   = (ResetData *)opaque;
+    PowerPCCPU *cpu = s->cpu;
+
 
+    if (s->use_entry) {
+        cpu->env.nip = s->entry;
+    }
     cpu_reset(CPU(cpu));
 }
 
@@ -463,11 +474,14 @@ static void ppc_prep_init(QEMUMachineInitArgs *args)
     qemu_irq *cpu_exit_irq;
     int ppc_boot_device;
     DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
+    ResetData *reset_data;
 
     sysctrl = g_malloc0(sizeof(sysctrl_t));
 
     linux_boot = (kernel_filename != NULL);
 
+    reset_data = g_malloc0(sizeof(ResetData) * smp_cpus);
+
     /* init CPUs */
     if (cpu_model == NULL)
         cpu_model = "602";
@@ -486,7 +500,11 @@ static void ppc_prep_init(QEMUMachineInitArgs *args)
             /* Set time-base frequency to 100 Mhz */
             cpu_ppc_tb_init(env, 100UL * 1000UL * 1000UL);
         }
-        qemu_register_reset(ppc_prep_reset, cpu);
+
+        /* Reset data */
+        reset_data[i].cpu       = cpu;
+        reset_data[i].use_entry = false;
+        qemu_register_reset(ppc_prep_reset, &reset_data[i]);
     }
 
     /* allocate RAM */
@@ -521,19 +539,27 @@ static void ppc_prep_init(QEMUMachineInitArgs *args)
     }
 
     if (linux_boot) {
+        uint64_t entry;
+
         kernel_base = KERNEL_LOAD_ADDR;
 
         /* Try to load the kernel as an ELF file */
-        kernel_size = load_elf(kernel_filename, NULL, NULL, NULL, NULL, NULL,
+        kernel_size = load_elf(kernel_filename, NULL, NULL, &entry, NULL, NULL,
                                1, ELF_MACHINE, 0);
-        if (kernel_size < 0) {
+        if (kernel_size > 0) {
+            /* Entry point for CPU #0 */
+            reset_data[0].entry = entry;
+            reset_data[0].use_entry = true;
+        } else {
             /* Try to load the kernel as an binary file */
             kernel_size = load_image_targphys(kernel_filename, kernel_base,
                                               ram_size - kernel_base);
         }
+
         if (kernel_size < 0) {
             hw_error("qemu: could not load kernel '%s'\n", kernel_filename);
         }
+
         /* load initrd */
         if (initrd_filename) {
             initrd_base = INITRD_LOAD_ADDR;
-- 
1.7.9.5

[Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Fabien Chouteau]

If we use an ELF kernel there's no need for bios. '-bios -' means no
bios.

Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
---
 hw/ppc/prep.c |   23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 12198ff..8acec46 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -517,13 +517,22 @@ static void ppc_prep_init(QEMUMachineInitArgs *args)
     memory_region_set_readonly(bios, true);
     memory_region_add_subregion(sysmem, (uint32_t)(-BIOS_SIZE), bios);
     vmstate_register_ram_global(bios);
-    if (bios_name == NULL)
-        bios_name = BIOS_FILENAME;
-    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
-    if (filename) {
-        bios_size = get_image_size(filename);
-    } else {
+
+    if (bios_name != NULL && strcmp(bios_name, "-") == 0) {
+        /* No bios */
         bios_size = -1;
+        filename = NULL;
+    } else {
+        if (bios_name == NULL) {
+            /* Default bios */
+            bios_name = BIOS_FILENAME;
+        }
+        filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
+        if (filename != NULL) {
+            bios_size = get_image_size(filename);
+        } else {
+            bios_size = -1;
+        }
     }
     if (bios_size > 0 && bios_size <= BIOS_SIZE) {
         hwaddr bios_addr;
@@ -531,7 +540,7 @@ static void ppc_prep_init(QEMUMachineInitArgs *args)
         bios_addr = (uint32_t)(-bios_size);
         bios_size = load_image_targphys(filename, bios_addr, bios_size);
     }
-    if (bios_size < 0 || bios_size > BIOS_SIZE) {
+    if (filename != NULL && (bios_size < 0 || bios_size > BIOS_SIZE)) {
         hw_error("qemu: could not load PPC PREP bios '%s'\n", bios_name);
     }
     if (filename) {
-- 
1.7.9.5

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Alexander Graf]

On 03.04.2013, at 18:40, Fabien Chouteau wrote:

> If we use an ELF kernel there's no need for bios. '-bios -' means no
> bios.

This sounds like you're actually looking for a way to load an ELF blob as bios using -bios, not a kernel, no?

The preferred way to load a kernel with -kernel is to load firmware which then detects that a kernel was loaded with -kernel and jumps in. Once Andreas moves PReP to OpenBIOS, this will be the normal mode of operation there too.


Alex

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Fabien Chouteau]

On 04/03/2013 06:59 PM, Alexander Graf wrote:
>
> On 03.04.2013, at 18:40, Fabien Chouteau wrote:
>
>> If we use an ELF kernel there's no need for bios. '-bios -' means no
>> bios.
>
> This sounds like you're actually looking for a way to load an ELF blob
> as bios using -bios, not a kernel, no?
>

No, we load the kernel with -kernel, that's what the first patch does.
But the board is implemented in such way that you can't start without a
bios. If the -bios switch is not present, then the board uses the
default bios. This patch allows to start without a bios:

-kernel <PROGRAM> -bios -

> The preferred way to load a kernel with -kernel is to load firmware
> which then detects that a kernel was loaded with -kernel and jumps in.
> Once Andreas moves PReP to OpenBIOS, this will be the normal mode of
> operation there too.
>

I'll have a look at Andreas' branch and see if it fits our scheme.

Thanks,

-- 
Fabien Chouteau

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Alexander Graf]

On 04.04.2013, at 10:37, Fabien Chouteau wrote:

> 
> On 04/03/2013 06:59 PM, Alexander Graf wrote:
>> 
>> On 03.04.2013, at 18:40, Fabien Chouteau wrote:
>> 
>>> If we use an ELF kernel there's no need for bios. '-bios -' means no
>>> bios.
>> 
>> This sounds like you're actually looking for a way to load an ELF blob
>> as bios using -bios, not a kernel, no?
>> 
> 
> No, we load the kernel with -kernel, that's what the first patch does.
> But the board is implemented in such way that you can't start without a
> bios. If the -bios switch is not present, then the board uses the
> default bios. This patch allows to start without a bios:
> 
> -kernel <PROGRAM> -bios -

Do you also pass in -initrd or -append? If not, then your kernel _is_ the firmware.


Alex

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Fabien Chouteau]

On 04/04/2013 11:26 AM, Alexander Graf wrote:
> 
> On 04.04.2013, at 10:37, Fabien Chouteau wrote:
> 
>>
>> On 04/03/2013 06:59 PM, Alexander Graf wrote:
>>>
>>> On 03.04.2013, at 18:40, Fabien Chouteau wrote:
>>>
>>>> If we use an ELF kernel there's no need for bios. '-bios -' means no
>>>> bios.
>>>
>>> This sounds like you're actually looking for a way to load an ELF blob
>>> as bios using -bios, not a kernel, no?
>>>
>>
>> No, we load the kernel with -kernel, that's what the first patch does.
>> But the board is implemented in such way that you can't start without a
>> bios. If the -bios switch is not present, then the board uses the
>> default bios. This patch allows to start without a bios:
>>
>> -kernel <PROGRAM> -bios -
> 
> Do you also pass in -initrd or -append? 

No I don't.
 
> If not, then your kernel _is_ the firmware.
> 

You can say it that way, see my other email.

-- 
Fabien Chouteau

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Artyom Tarasenko]

On Thu, Apr 4, 2013 at 10:37 AM, Fabien Chouteau <chouteau@adacore.com> wrote:
>
> On 04/03/2013 06:59 PM, Alexander Graf wrote:
>>
>> On 03.04.2013, at 18:40, Fabien Chouteau wrote:
>>
>>> If we use an ELF kernel there's no need for bios. '-bios -' means no
>>> bios.
>>
>> This sounds like you're actually looking for a way to load an ELF blob
>> as bios using -bios, not a kernel, no?
>>
>
> No, we load the kernel with -kernel, that's what the first patch does.
> But the board is implemented in such way that you can't start without a
> bios. If the -bios switch is not present, then the board uses the
> default bios. This patch allows to start without a bios:
>
> -kernel <PROGRAM> -bios -

Regardless of the firmware vs. kernel discussion, I think the syntax
may be improved. Under *nix '-' is commonly used for stdin. Would it
be possible to specify /dev/null (under *NIX) or NUL (in the
MS-World)? I think it would make the syntax more explicit.

Regards,
Artyom Tarasenko

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Alexander Graf]

On 04.04.2013, at 11:46, Artyom Tarasenko wrote:

> On Thu, Apr 4, 2013 at 10:37 AM, Fabien Chouteau <chouteau@adacore.com> wrote:
>> 
>> On 04/03/2013 06:59 PM, Alexander Graf wrote:
>>> 
>>> On 03.04.2013, at 18:40, Fabien Chouteau wrote:
>>> 
>>>> If we use an ELF kernel there's no need for bios. '-bios -' means no
>>>> bios.
>>> 
>>> This sounds like you're actually looking for a way to load an ELF blob
>>> as bios using -bios, not a kernel, no?
>>> 
>> 
>> No, we load the kernel with -kernel, that's what the first patch does.
>> But the board is implemented in such way that you can't start without a
>> bios. If the -bios switch is not present, then the board uses the
>> default bios. This patch allows to start without a bios:
>> 
>> -kernel <PROGRAM> -bios -
> 
> Regardless of the firmware vs. kernel discussion, I think the syntax
> may be improved. Under *nix '-' is commonly used for stdin. Would it
> be possible to specify /dev/null (under *NIX) or NUL (in the
> MS-World)? I think it would make the syntax more explicit.

I'd be inclined to say that running -kernel without -bios is simply bogus and shouldn't ever happen.


Alex

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Artyom Tarasenko]

On Thu, Apr 4, 2013 at 11:50 AM, Alexander Graf <agraf@suse.de> wrote:
>
> On 04.04.2013, at 11:46, Artyom Tarasenko wrote:
>
>> On Thu, Apr 4, 2013 at 10:37 AM, Fabien Chouteau <chouteau@adacore.com> wrote:
>>>
>>> On 04/03/2013 06:59 PM, Alexander Graf wrote:
>>>>
>>>> On 03.04.2013, at 18:40, Fabien Chouteau wrote:
>>>>
>>>>> If we use an ELF kernel there's no need for bios. '-bios -' means no
>>>>> bios.
>>>>
>>>> This sounds like you're actually looking for a way to load an ELF blob
>>>> as bios using -bios, not a kernel, no?
>>>>
>>>
>>> No, we load the kernel with -kernel, that's what the first patch does.
>>> But the board is implemented in such way that you can't start without a
>>> bios. If the -bios switch is not present, then the board uses the
>>> default bios. This patch allows to start without a bios:
>>>
>>> -kernel <PROGRAM> -bios -
>>
>> Regardless of the firmware vs. kernel discussion, I think the syntax
>> may be improved. Under *nix '-' is commonly used for stdin. Would it
>> be possible to specify /dev/null (under *NIX) or NUL (in the
>> MS-World)? I think it would make the syntax more explicit.
>
> I'd be inclined to say that running -kernel without -bios is simply bogus and shouldn't ever happen.

QEMU does it at least in one other architectures though: leon3_generic.

--
Regards,
Artyom Tarasenko

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Andreas Färber]

Am 04.04.2013 11:57, schrieb Artyom Tarasenko:
> On Thu, Apr 4, 2013 at 11:50 AM, Alexander Graf <agraf@suse.de> wrote:
>>
>> On 04.04.2013, at 11:46, Artyom Tarasenko wrote:
>>
>>> On Thu, Apr 4, 2013 at 10:37 AM, Fabien Chouteau <chouteau@adacore.com> wrote:
>>>>
>>>> On 04/03/2013 06:59 PM, Alexander Graf wrote:
>>>>>
>>>>> On 03.04.2013, at 18:40, Fabien Chouteau wrote:
>>>>>
>>>>>> If we use an ELF kernel there's no need for bios. '-bios -' means no
>>>>>> bios.
>>>>>
>>>>> This sounds like you're actually looking for a way to load an ELF blob
>>>>> as bios using -bios, not a kernel, no?
>>>>>
>>>>
>>>> No, we load the kernel with -kernel, that's what the first patch does.
>>>> But the board is implemented in such way that you can't start without a
>>>> bios. If the -bios switch is not present, then the board uses the
>>>> default bios. This patch allows to start without a bios:
>>>>
>>>> -kernel <PROGRAM> -bios -
>>>
>>> Regardless of the firmware vs. kernel discussion, I think the syntax
>>> may be improved. Under *nix '-' is commonly used for stdin. Would it
>>> be possible to specify /dev/null (under *NIX) or NUL (in the
>>> MS-World)? I think it would make the syntax more explicit.
>>
>> I'd be inclined to say that running -kernel without -bios is simply bogus and shouldn't ever happen.
> 
> QEMU does it at least in one other architectures though: leon3_generic.

Let's rather say: Fabien did it in leon3, too. ;)

Alex, isn't ARM running without -bios? Instead of a firmware blob it has
some hardcoded firmware'ish instructions in the loader code.

For PReP, Fabien has not stated what his use case actually is (in
particular which hardware?), so it's hard for me to comment on what the
hardware actually does and I thus won't accept random changes just
because they happen to be in Leon3 code. There's nothing conceptually
wrong with loading ELF code so I'm positive we will find a solution to
accommodate all use cases in some way. :)

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Alexander Graf]

On 04.04.2013, at 13:53, Andreas Färber wrote:

> Am 04.04.2013 11:57, schrieb Artyom Tarasenko:
>> On Thu, Apr 4, 2013 at 11:50 AM, Alexander Graf <agraf@suse.de> wrote:
>>> 
>>> On 04.04.2013, at 11:46, Artyom Tarasenko wrote:
>>> 
>>>> On Thu, Apr 4, 2013 at 10:37 AM, Fabien Chouteau <chouteau@adacore.com> wrote:
>>>>> 
>>>>> On 04/03/2013 06:59 PM, Alexander Graf wrote:
>>>>>> 
>>>>>> On 03.04.2013, at 18:40, Fabien Chouteau wrote:
>>>>>> 
>>>>>>> If we use an ELF kernel there's no need for bios. '-bios -' means no
>>>>>>> bios.
>>>>>> 
>>>>>> This sounds like you're actually looking for a way to load an ELF blob
>>>>>> as bios using -bios, not a kernel, no?
>>>>>> 
>>>>> 
>>>>> No, we load the kernel with -kernel, that's what the first patch does.
>>>>> But the board is implemented in such way that you can't start without a
>>>>> bios. If the -bios switch is not present, then the board uses the
>>>>> default bios. This patch allows to start without a bios:
>>>>> 
>>>>> -kernel <PROGRAM> -bios -
>>>> 
>>>> Regardless of the firmware vs. kernel discussion, I think the syntax
>>>> may be improved. Under *nix '-' is commonly used for stdin. Would it
>>>> be possible to specify /dev/null (under *NIX) or NUL (in the
>>>> MS-World)? I think it would make the syntax more explicit.
>>> 
>>> I'd be inclined to say that running -kernel without -bios is simply bogus and shouldn't ever happen.
>> 
>> QEMU does it at least in one other architectures though: leon3_generic.
> 
> Let's rather say: Fabien did it in leon3, too. ;)
> 
> Alex, isn't ARM running without -bios? Instead of a firmware blob it has
> some hardcoded firmware'ish instructions in the loader code.

That still means it runs a firmware. It just generates it on the fly instead of loading it from -bios :). X86 used to do the same.

> For PReP, Fabien has not stated what his use case actually is (in
> particular which hardware?), so it's hard for me to comment on what the
> hardware actually does and I thus won't accept random changes just
> because they happen to be in Leon3 code. There's nothing conceptually
> wrong with loading ELF code so I'm positive we will find a solution to
> accommodate all use cases in some way. :)

I think it makes a lot of sense to support loading -kernel as an ELF binary. I don't think it's a good idea to allow -kernel without any BIOS. We do that on the e500 machines and so far it's mostly hurt us.


Alex

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Scott Wood]

On 04/04/2013 06:59:24 AM, Alexander Graf wrote:
> 
> On 04.04.2013, at 13:53, Andreas Färber wrote:
> 
> > For PReP, Fabien has not stated what his use case actually is (in
> > particular which hardware?), so it's hard for me to comment on what  
> the
> > hardware actually does and I thus won't accept random changes just
> > because they happen to be in Leon3 code. There's nothing  
> conceptually
> > wrong with loading ELF code so I'm positive we will find a solution  
> to
> > accommodate all use cases in some way. :)
> 
> I think it makes a lot of sense to support loading -kernel as an ELF  
> binary. I don't think it's a good idea to allow -kernel without any  
> BIOS. We do that on the e500 machines and so far it's mostly hurt us.

If by "mostly hurt us" you mean allowed things to work without having  
to do a bunch of hacking to create a paravirt U-Boot and/or implement a  
bunch of emulation that we don't really need otherwise.

-Scott

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Alexander Graf]

Am 06.04.2013 um 01:00 schrieb Scott Wood <scottwood@freescale.com>:

> On 04/04/2013 06:59:24 AM, Alexander Graf wrote:
>> On 04.04.2013, at 13:53, Andreas Färber wrote:
>> > For PReP, Fabien has not stated what his use case actually is (in
>> > particular which hardware?), so it's hard for me to comment on what the
>> > hardware actually does and I thus won't accept random changes just
>> > because they happen to be in Leon3 code. There's nothing conceptually
>> > wrong with loading ELF code so I'm positive we will find a solution to
>> > accommodate all use cases in some way. :)
>> I think it makes a lot of sense to support loading -kernel as an ELF binary. I don't think it's a good idea to allow -kernel without any BIOS. We do that on the e500 machines and so far it's mostly hurt us.
> 
> If by "mostly hurt us" you mean allowed things to work without having to do a bunch of hacking to create a paravirt U-Boot and/or implement a bunch of emulation that we don't really need otherwise.

I mean that we lack compatibility. The less we diverge from what users are used to, the better usability becomes for users.

Just try to run *BSD on e500. Good luck ;)

Alex

> 
> -Scott

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Scott Wood]

On 04/06/2013 04:01:32 AM, Alexander Graf wrote:
> 
> 
> Am 06.04.2013 um 01:00 schrieb Scott Wood <scottwood@freescale.com>:
> 
> > On 04/04/2013 06:59:24 AM, Alexander Graf wrote:
> >> On 04.04.2013, at 13:53, Andreas Färber wrote:
> >> > For PReP, Fabien has not stated what his use case actually is (in
> >> > particular which hardware?), so it's hard for me to comment on  
> what the
> >> > hardware actually does and I thus won't accept random changes  
> just
> >> > because they happen to be in Leon3 code. There's nothing  
> conceptually
> >> > wrong with loading ELF code so I'm positive we will find a  
> solution to
> >> > accommodate all use cases in some way. :)
> >> I think it makes a lot of sense to support loading -kernel as an  
> ELF binary. I don't think it's a good idea to allow -kernel without  
> any BIOS. We do that on the e500 machines and so far it's mostly hurt  
> us.
> >
> > If by "mostly hurt us" you mean allowed things to work without  
> having to do a bunch of hacking to create a paravirt U-Boot and/or  
> implement a bunch of emulation that we don't really need otherwise.
> 
> I mean that we lack compatibility. The less we diverge from what  
> users are used to, the better usability becomes for users.
> 
> Just try to run *BSD on e500. Good luck ;)

It should be fine (or at least fixable without too much hassle) if the  
particular BSD complies with ePAPR.  I don't know the status of it, but  
Googling suggests that there's at least been effort to do this for  
FreeBSD.

If someone wants to implement an e500 boot mode other than ePAPR, they  
can -- I don't see how having the ePAPR option hurts that.

-Scott

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Julio Guerra]

No conclusion was finally done about the new option proposal to load
roms files. It really would be handy.

--
Julio Guerra

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Julio Guerra]

2013/7/4 Julio Guerra <guerr@julio.in>:
> No conclusion was finally done about the new option proposal to load
> roms files. It really would be handy.

I should rephrase it as: does a patch creating such an option would be welcomed?

--
Julio Guerra

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Alexander Graf]

Am 06.04.2013 um 01:00 schrieb Scott Wood <scottwood@freescale.com>:

> On 04/04/2013 06:59:24 AM, Alexander Graf wrote:
>> On 04.04.2013, at 13:53, Andreas Färber wrote:
>> > For PReP, Fabien has not stated what his use case actually is (in
>> > particular which hardware?), so it's hard for me to comment on what the
>> > hardware actually does and I thus won't accept random changes just
>> > because they happen to be in Leon3 code. There's nothing conceptually
>> > wrong with loading ELF code so I'm positive we will find a solution to
>> > accommodate all use cases in some way. :)
>> I think it makes a lot of sense to support loading -kernel as an ELF binary. I don't think it's a good idea to allow -kernel without any BIOS. We do that on the e500 machines and so far it's mostly hurt us.
> 
> If by "mostly hurt us" you mean allowed things to work without having to do a bunch of hacking to create a paravirt U-Boot and/or implement a bunch of emulation that we don't really need otherwise.

Also, as soon as ARM moves to uEFI, Linux won't run bare metal the way it would with formware either.

We went through that argument very leghthly on x86. It used to do direct -kernel without involving firmware. Then came SMP tables that were missing, ACPI tables that were missing, etc. Suddenly your -kernel booted system couldn't do hotplug for example. It ran through different code paths, causing testability pain.

What if Linux adds a callback into uboot tomorrow that it uses to do early printk? Suddenly we lack that.

On ARM, look at highbank. Because we're not running we're lacking a monitor mode blob that provides sys calls for flushing caches. Thus today the highbank machine doesn't boot anymore with Linux. If we ran firmware like the real board, that would provide for the sys call.


Alex

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Peter Maydell]

On 6 April 2013 10:07, Alexander Graf <agraf@suse.de> wrote:
> On ARM, look at highbank. Because we're not running we're lacking
> a monitor mode blob that provides sys calls for flushing caches.
> Thus today the highbank machine doesn't boot anymore with Linux.
> If we ran firmware like the real board, that would provide for the
> sys call.

We also flat out don't implement enough monitor mode to allow
a hypothetical firmware blob to work.

-- PMM

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Alexander Graf]

On 06.04.2013, at 13:27, Peter Maydell wrote:

> On 6 April 2013 10:07, Alexander Graf <agraf@suse.de> wrote:
>> On ARM, look at highbank. Because we're not running we're lacking
>> a monitor mode blob that provides sys calls for flushing caches.
>> Thus today the highbank machine doesn't boot anymore with Linux.
>> If we ran firmware like the real board, that would provide for the
>> sys call.
> 
> We also flat out don't implement enough monitor mode to allow
> a hypothetical firmware blob to work.

Why don't we implement enough monitor mode? Because we're not running firmware :). It's a chicken and egg thing. Bottom line is that Linux validly expects that firmware exists. If we don't run firmware, we diverge, thus we potentially break.


Alex

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Peter Maydell]

On 6 April 2013 12:38, Alexander Graf <agraf@suse.de> wrote:
>
> On 06.04.2013, at 13:27, Peter Maydell wrote:
>
>> On 6 April 2013 10:07, Alexander Graf <agraf@suse.de> wrote:
>>> On ARM, look at highbank. Because we're not running we're lacking
>>> a monitor mode blob that provides sys calls for flushing caches.
>>> Thus today the highbank machine doesn't boot anymore with Linux.
>>> If we ran firmware like the real board, that would provide for the
>>> sys call.
>>
>> We also flat out don't implement enough monitor mode to allow
>> a hypothetical firmware blob to work.
>
> Why don't we implement enough monitor mode?

Because (a) I haven't got round to it (b) doing it properly is
a huge job (c) KVM can't do monitor mode so we need a plan for
a "not really monitor mode" anyway (d) it isn't yet causing
problems on the boards I primarily care about. I'm happy to
review patches if somebody wants to submit them.

> Bottom line is that Linux validly expects that firmware exists.

I agree that we're going to want to run UEFI at some point.
My current plan for this is that we should get a version
of the UEFI firmware which runs in non-secure mode.

-- PMM

Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/3] PPC PReP: can run without bios image

[Edgar E. Iglesias]

On Sat, Apr 06, 2013 at 01:38:52PM +0200, Alexander Graf wrote:
> 
> On 06.04.2013, at 13:27, Peter Maydell wrote:
> 
> > On 6 April 2013 10:07, Alexander Graf <agraf@suse.de> wrote:
> >> On ARM, look at highbank. Because we're not running we're lacking
> >> a monitor mode blob that provides sys calls for flushing caches.
> >> Thus today the highbank machine doesn't boot anymore with Linux.
> >> If we ran firmware like the real board, that would provide for the
> >> sys call.
> > 
> > We also flat out don't implement enough monitor mode to allow
> > a hypothetical firmware blob to work.
> 
> Why don't we implement enough monitor mode? Because we're not running firmware :). It's a chicken and egg thing. Bottom line is that Linux validly expects that firmware exists. If we don't run firmware, we diverge, thus we potentially break.


Hi guys, A question -  For linux kernels that depend on preivous stages to setup
HW state. What is the prefered way to handle it?

In particular, if the boot loader chain depends on for example a boot rom
that is not Open Source. Is providing a QEMU specific loader in pc-bios/ a good
option?

Cheers,
Edgar

Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/3] PPC PReP: can run without bios image

[Alexander Graf]

On 06.04.2013, at 22:07, Edgar E. Iglesias wrote:

> On Sat, Apr 06, 2013 at 01:38:52PM +0200, Alexander Graf wrote:
>> 
>> On 06.04.2013, at 13:27, Peter Maydell wrote:
>> 
>>> On 6 April 2013 10:07, Alexander Graf <agraf@suse.de> wrote:
>>>> On ARM, look at highbank. Because we're not running we're lacking
>>>> a monitor mode blob that provides sys calls for flushing caches.
>>>> Thus today the highbank machine doesn't boot anymore with Linux.
>>>> If we ran firmware like the real board, that would provide for the
>>>> sys call.
>>> 
>>> We also flat out don't implement enough monitor mode to allow
>>> a hypothetical firmware blob to work.
>> 
>> Why don't we implement enough monitor mode? Because we're not running firmware :). It's a chicken and egg thing. Bottom line is that Linux validly expects that firmware exists. If we don't run firmware, we diverge, thus we potentially break.
> 
> 
> Hi guys, A question -  For linux kernels that depend on preivous stages to setup
> HW state. What is the prefered way to handle it?
> 
> In particular, if the boot loader chain depends on for example a boot rom
> that is not Open Source. Is providing a QEMU specific loader in pc-bios/ a good
> option?

That's pretty much what we do for all PPC machines that do execute firmware, yes :). Just make sure to license your own firmware code under an open source license.


Alex

Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/3] PPC PReP: can run without bios image

[Edgar E. Iglesias]

On Sat, Apr 06, 2013 at 10:12:49PM +0200, Alexander Graf wrote:
> 
> On 06.04.2013, at 22:07, Edgar E. Iglesias wrote:
> 
> > On Sat, Apr 06, 2013 at 01:38:52PM +0200, Alexander Graf wrote:
> >> 
> >> On 06.04.2013, at 13:27, Peter Maydell wrote:
> >> 
> >>> On 6 April 2013 10:07, Alexander Graf <agraf@suse.de> wrote:
> >>>> On ARM, look at highbank. Because we're not running we're lacking
> >>>> a monitor mode blob that provides sys calls for flushing caches.
> >>>> Thus today the highbank machine doesn't boot anymore with Linux.
> >>>> If we ran firmware like the real board, that would provide for the
> >>>> sys call.
> >>> 
> >>> We also flat out don't implement enough monitor mode to allow
> >>> a hypothetical firmware blob to work.
> >> 
> >> Why don't we implement enough monitor mode? Because we're not running firmware :). It's a chicken and egg thing. Bottom line is that Linux validly expects that firmware exists. If we don't run firmware, we diverge, thus we potentially break.
> > 
> > 
> > Hi guys, A question -  For linux kernels that depend on preivous stages to setup
> > HW state. What is the prefered way to handle it?
> > 
> > In particular, if the boot loader chain depends on for example a boot rom
> > that is not Open Source. Is providing a QEMU specific loader in pc-bios/ a good
> > option?
> 
> That's pretty much what we do for all PPC machines that do execute firmware, yes :). Just make sure to license your own firmware code under an open source license.

OK, got it, thanks Alex.

Cheers,
Edgar

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Peter Maydell]

On 4 April 2013 12:53, Andreas Färber <afaerber@suse.de> wrote:
> Alex, isn't ARM running without -bios? Instead of a firmware blob it has
> some hardcoded firmware'ish instructions in the loader code.

Varies from board to board, but yes, generally we have a trivial
bootloader (which on uniprocessor machines doesn't actually run
guest code, it just sets registers and memory up to jump to the
kernel).

> For PReP, Fabien has not stated what his use case actually is (in
> particular which hardware?), so it's hard for me to comment on what the
> hardware actually does and I thus won't accept random changes just
> because they happen to be in Leon3 code. There's nothing conceptually
> wrong with loading ELF code so I'm positive we will find a solution to
> accommodate all use cases in some way. :)

ARM also lets you pass an ELF file to -kernel which it treats
as "just pull this blob into RAM and jump to its entrypoint".
This is useful for 'bare metal' type test cases (equivalent
of dumping a file in over JTAG). The UI is all wrong, though:
-kernel should always mean "load a Linux kernel" and we should
have some other way (ideally a cross-architecture way) of saying
"just load this binary blob and start it". (-bios isn't that
because -bios tends to (a) mean different things on different
boards and (b) mean 'put this in flash or whatever' rather than
'dump stuff in RAM and go'.)

-- PMM

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Fabien Chouteau]

On 04/04/2013 02:43 PM, Peter Maydell wrote:
> On 4 April 2013 12:53, Andreas Färber <afaerber@suse.de> wrote:
>> Alex, isn't ARM running without -bios? Instead of a firmware blob it has
>> some hardcoded firmware'ish instructions in the loader code.
>
> Varies from board to board, but yes, generally we have a trivial
> bootloader (which on uniprocessor machines doesn't actually run
> guest code, it just sets registers and memory up to jump to the
> kernel).
>
>> For PReP, Fabien has not stated what his use case actually is (in
>> particular which hardware?), so it's hard for me to comment on what the
>> hardware actually does and I thus won't accept random changes just
>> because they happen to be in Leon3 code. There's nothing conceptually
>> wrong with loading ELF code so I'm positive we will find a solution to
>> accommodate all use cases in some way. :)
>
> ARM also lets you pass an ELF file to -kernel which it treats
> as "just pull this blob into RAM and jump to its entrypoint".

That's what we do for almost all the targets we are using at AdaCore
(leon, leon3, PReP(602), wrSbc8349(e300), wrSbc8548(e500v2),
lm3s(arm-M3), TMS570(arm-R4F)).

> This is useful for 'bare metal' type test cases (equivalent
> of dumping a file in over JTAG).

Exactly, maybe I have to explain how we use QEMU here:

The Ada language provides run-time features (tasking, timing services,
protected objects, etc...). These can be implemented on top of an OS
(Windows, Linux, Solaris, vxWorks, etc...). There's also the Ravenscar
profile, which restrict the language to a subset of run-time features
suitable for embedded and safety-critical tasks.

In that case there's no need for and OS, but the program itself can be a
simple kernel (scheduling, interrupts, timing services...) running on
bare metal. The program will also do the initialization of the board, so
there's no need for bootloader/firmware.

We run hundreds of thousands of tests on QEMU each days, on all the
guest platforms above and on Windows and Linux hosts. These tests are
very short programs that usually run for less than 2 secs.

In that context having a boot loader that initialize the board and load
the program from network or disk is not very interesting, it's time
consuming and it's complicated. Our compiler builds and ELF file, it's
easier to run it right away.

> The UI is all wrong, though:
> -kernel should always mean "load a Linux kernel" and we should
> have some other way (ideally a cross-architecture way) of saying
> "just load this binary blob and start it". (-bios isn't that
> because -bios tends to (a) mean different things on different
> boards and (b) mean 'put this in flash or whatever' rather than
> 'dump stuff in RAM and go'.)
>

I think -kernel works fine for all architecture. Linux is not the only
kernel available ;)

-- 
Fabien Chouteau

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Peter Maydell]

On 4 April 2013 17:17, Fabien Chouteau <chouteau@adacore.com> wrote:
> On 04/04/2013 02:43 PM, Peter Maydell wrote:
>> The UI is all wrong, though:
>> -kernel should always mean "load a Linux kernel" and we should
>> have some other way (ideally a cross-architecture way) of saying
>> "just load this binary blob and start it". (-bios isn't that
>> because -bios tends to (a) mean different things on different
>> boards and (b) mean 'put this in flash or whatever' rather than
>> 'dump stuff in RAM and go'.)
>>
>
> I think -kernel works fine for all architecture. Linux is not the only
> kernel available ;)

But -kernel for QEMU specifically means Linux kernel; you might
argue we should have picked a different option name but we're
stuck with it now. The problem on ARM is that we treat
'-kernel but this is an ELF file' and '-kernel and this is a
binary blob' differently.

-- PMM

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Artyom Tarasenko]

On Thu, Apr 4, 2013 at 6:20 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 4 April 2013 17:17, Fabien Chouteau <chouteau@adacore.com> wrote:
>> On 04/04/2013 02:43 PM, Peter Maydell wrote:
>>> The UI is all wrong, though:
>>> -kernel should always mean "load a Linux kernel" and we should
>>> have some other way (ideally a cross-architecture way) of saying
>>> "just load this binary blob and start it". (-bios isn't that
>>> because -bios tends to (a) mean different things on different
>>> boards and (b) mean 'put this in flash or whatever' rather than
>>> 'dump stuff in RAM and go'.)
>>>
>>
>> I think -kernel works fine for all architecture. Linux is not the only
>> kernel available ;)
>
> But -kernel for QEMU specifically means Linux kernel; you might
> argue we should have picked a different option name but we're
> stuck with it now.

No, it's not Linux-only. At least qemu-system-sparc can load NetBSD
kernel with this option.

--
Regards,
Artyom Tarasenko

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Peter Maydell]

On 4 April 2013 17:26, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
> On Thu, Apr 4, 2013 at 6:20 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> But -kernel for QEMU specifically means Linux kernel; you might
>> argue we should have picked a different option name but we're
>> stuck with it now.
>
> No, it's not Linux-only. At least qemu-system-sparc can load NetBSD
> kernel with this option.

Another example of being inconsistent across architectures, then.
My point stands:
 * -kernel (if it means anything at all) has to mean "boot in
the way a Linux kernel expects and defines its boot protocol"
 * "just load a binary and run it" needs to be some other option,
because that's not the same thing

The two aren't the same thing in all cases and it's just confusing
to try to make them mean the same thing for the subset of cases
where it happens to be ok.

-- PMM

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Alexander Graf]

On 04.04.2013, at 18:30, Peter Maydell wrote:

> On 4 April 2013 17:26, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
>> On Thu, Apr 4, 2013 at 6:20 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> But -kernel for QEMU specifically means Linux kernel; you might
>>> argue we should have picked a different option name but we're
>>> stuck with it now.
>> 
>> No, it's not Linux-only. At least qemu-system-sparc can load NetBSD
>> kernel with this option.
> 
> Another example of being inconsistent across architectures, then.
> My point stands:
> * -kernel (if it means anything at all) has to mean "boot in
> the way a Linux kernel expects and defines its boot protocol"

This is what -kernel does. If more OSs than Linux end up happy with that interface, great. Examples for that are multiboot kernels on x86. But in general, kernels want to talk to firmware.

> * "just load a binary and run it" needs to be some other option,
> because that's not the same thing

This is what -bios does. Maybe we should add an alias and call it "-firmware", but the idea stays the same. That's the initial blob executed when a VM gets up.

> The two aren't the same thing in all cases and it's just confusing
> to try to make them mean the same thing for the subset of cases
> where it happens to be ok.

I agree.


Alex

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Peter Maydell]

On 4 April 2013 17:34, Alexander Graf <agraf@suse.de> wrote:
> On 04.04.2013, at 18:30, Peter Maydell wrote:
>> * -kernel (if it means anything at all) has to mean "boot in
>> the way a Linux kernel expects and defines its boot protocol"
>
> This is what -kernel does. If more OSs than Linux end up happy with
> that interface, great. Examples for that are multiboot kernels on
> x86. But in general, kernels want to talk to firmware.

Agreed.

>> * "just load a binary and run it" needs to be some other option,
>> because that's not the same thing
>
> This is what -bios does. Maybe we should add an alias and call it
> "-firmware", but the idea stays the same. That's the initial blob
> executed when a VM gets up.

No, in general this isn't what -bios does. Usually -bios means
"take a blob and put it wherever this board expects to have
a ROM or flash firmware image". So on highbank it goes in the
sysram at 0xfff88000, on shix it's 0x4000 bytes loaded at address 0,
on mips_malta it's an image to load into a flash device, and
so on. And on some boards it does nothing at all, because we
ignore the parameter.

What is being asked for (and what ARM's -kernel does at the
moment if you pass it an ELF image) is "just load the ELF
image where the ELF image says to put it, and jump to the
ELF image's entrypoint".

-- PMM

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Alexander Graf]

On 04.04.2013, at 18:41, Peter Maydell wrote:

> On 4 April 2013 17:34, Alexander Graf <agraf@suse.de> wrote:
>> On 04.04.2013, at 18:30, Peter Maydell wrote:
>>> * -kernel (if it means anything at all) has to mean "boot in
>>> the way a Linux kernel expects and defines its boot protocol"
>> 
>> This is what -kernel does. If more OSs than Linux end up happy with
>> that interface, great. Examples for that are multiboot kernels on
>> x86. But in general, kernels want to talk to firmware.
> 
> Agreed.
> 
>>> * "just load a binary and run it" needs to be some other option,
>>> because that's not the same thing
>> 
>> This is what -bios does. Maybe we should add an alias and call it
>> "-firmware", but the idea stays the same. That's the initial blob
>> executed when a VM gets up.
> 
> No, in general this isn't what -bios does. Usually -bios means
> "take a blob and put it wherever this board expects to have
> a ROM or flash firmware image". So on highbank it goes in the
> sysram at 0xfff88000, on shix it's 0x4000 bytes loaded at address 0,
> on mips_malta it's an image to load into a flash device, and
> so on. And on some boards it does nothing at all, because we
> ignore the parameter.

For blobs, I agree. But for ELF, we could just use the ELF information to load it somewhere else. It would certainly be a much more natural fit than -kernel.

> What is being asked for (and what ARM's -kernel does at the
> moment if you pass it an ELF image) is "just load the ELF
> image where the ELF image says to put it, and jump to the
> ELF image's entrypoint".

I don't see why we couldn't make this the expected behavior for -bios. You want to load a blob at the same layer as firmware, no?


Alex

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Peter Maydell]

On 4 April 2013 17:51, Alexander Graf <agraf@suse.de> wrote:
>
> On 04.04.2013, at 18:41, Peter Maydell wrote
>> No, in general this isn't what -bios does. Usually -bios means
>> "take a blob and put it wherever this board expects to have
>> a ROM or flash firmware image".

> For blobs, I agree. But for ELF, we could just use the ELF
> information to load it somewhere else. It would certainly
> be a much more natural fit than -kernel.

OK, and then how do you say "load the usual firmware but I have
a binary blob I want to run" ?

-- PMM

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Alexander Graf]

Am 04.04.2013 um 18:52 schrieb Peter Maydell <peter.maydell@linaro.org>:

> On 4 April 2013 17:51, Alexander Graf <agraf@suse.de> wrote:
>> 
>> On 04.04.2013, at 18:41, Peter Maydell wrote
>>> No, in general this isn't what -bios does. Usually -bios means
>>> "take a blob and put it wherever this board expects to have
>>> a ROM or flash firmware image".
> 
>> For blobs, I agree. But for ELF, we could just use the ELF
>> information to load it somewhere else. It would certainly
>> be a much more natural fit than -kernel.
> 
> OK, and then how do you say "load the usual firmware but I have
> a binary blob I want to run" ?

That's -kernel today. Loading firmware means executing firmware.


Alex

> 
> -- PMM

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Peter Maydell]

On 4 April 2013 23:32, Alexander Graf <agraf@suse.de> wrote:
> Am 04.04.2013 um 18:52 schrieb Peter Maydell <peter.maydell@linaro.org>:
>
>> On 4 April 2013 17:51, Alexander Graf <agraf@suse.de> wrote:
>>>
>>> On 04.04.2013, at 18:41, Peter Maydell wrote
>>>> No, in general this isn't what -bios does. Usually -bios means
>>>> "take a blob and put it wherever this board expects to have
>>>> a ROM or flash firmware image".
>>
>>> For blobs, I agree. But for ELF, we could just use the ELF
>>> information to load it somewhere else. It would certainly
>>> be a much more natural fit than -kernel.
>>
>> OK, and then how do you say "load the usual firmware but I have
>> a binary blob I want to run" ?
>
> That's -kernel today. Loading firmware means executing firmware.

We're going round in circles. You can't use -kernel to do that
because -kernel means "load a linux kernel", which is a different
thing to "just pull in and run an ELF file". There really are
three different things here, so they won't all fit into two
options.

-- PMM

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Artyom Tarasenko]

On Thu, Apr 4, 2013 at 6:30 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 4 April 2013 17:26, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
>> On Thu, Apr 4, 2013 at 6:20 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> But -kernel for QEMU specifically means Linux kernel; you might
>>> argue we should have picked a different option name but we're
>>> stuck with it now.
>>
>> No, it's not Linux-only. At least qemu-system-sparc can load NetBSD
>> kernel with this option.
>
> Another example of being inconsistent across architectures, then.

No. :)

> My point stands:
>  * -kernel (if it means anything at all) has to mean "boot in
> the way a Linux kernel expects and defines its boot protocol"

Yes. That's what happens when loading the NetBSD/sparc kernel.


--
Regards,
Artyom Tarasenko

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Peter Maydell]

On 4 April 2013 17:46, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
> On Thu, Apr 4, 2013 at 6:30 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> My point stands:
>>  * -kernel (if it means anything at all) has to mean "boot in
>> the way a Linux kernel expects and defines its boot protocol"
>
> Yes. That's what happens when loading the NetBSD/sparc kernel.

Well, that's nice, but it doesn't mean we can use -kernel to
mean "load an arbitrary binary", so at this point I have no
idea what your point is.

-- PMM

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Artyom Tarasenko]

On 4/4/13, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 4 April 2013 17:46, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
>> On Thu, Apr 4, 2013 at 6:30 PM, Peter Maydell <peter.maydell@linaro.org>
>> wrote:
>>> My point stands:
>>>  * -kernel (if it means anything at all) has to mean "boot in
>>> the way a Linux kernel expects and defines its boot protocol"
>>
>> Yes. That's what happens when loading the NetBSD/sparc kernel.
>
> Well, that's nice, but it doesn't mean we can use -kernel to
> mean "load an arbitrary binary", so at this point I have no
> idea what your point is.

You were not happy about the naming. My point is the the current
naming may be not that bad.


-- 
Regards,
Artyom Tarasenko

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Andreas Färber]

Am 04.04.2013 18:26, schrieb Artyom Tarasenko:
> On Thu, Apr 4, 2013 at 6:20 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 4 April 2013 17:17, Fabien Chouteau <chouteau@adacore.com> wrote:
>>> On 04/04/2013 02:43 PM, Peter Maydell wrote:
>>>> The UI is all wrong, though:
>>>> -kernel should always mean "load a Linux kernel" and we should
>>>> have some other way (ideally a cross-architecture way) of saying
>>>> "just load this binary blob and start it". (-bios isn't that
>>>> because -bios tends to (a) mean different things on different
>>>> boards and (b) mean 'put this in flash or whatever' rather than
>>>> 'dump stuff in RAM and go'.)
>>>>
>>>
>>> I think -kernel works fine for all architecture. Linux is not the only
>>> kernel available ;)
>>
>> But -kernel for QEMU specifically means Linux kernel; you might
>> argue we should have picked a different option name but we're
>> stuck with it now.
> 
> No, it's not Linux-only. At least qemu-system-sparc can load NetBSD
> kernel with this option.

Look, you're not exactly making friends if you keep pointing out that
something works somewhere and you try to deduce a rule out of that. ;)

-bios loads something where the hardware expects it, not necessarily
RAM. If using ELF, the entry point must be configured appropriately.

-kernel loads something into RAM in a way a Linux kernel can run (and it
does not limit itself to it, so other use cases may or may not work).

Loading something in a way that matches neither hardware nor Linux
kernel is - for good or bad - simply not really supported at this time.

PMM tried to get a discussion going about how to solve that latter case
properly some months ago, possibly prompted by Xilinx, and there were
not many responses, especially no concrete solution beyond vaguely
pointing to devices/objects rather than fiddling with existing
-kernel/-bios command line options.
So I really feel this discussion is out of scope for this PReP patchset!

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Fabien Chouteau]

On 04/04/2013 07:22 PM, Andreas Färber wrote:
> Am 04.04.2013 18:26, schrieb Artyom Tarasenko:
>> On Thu, Apr 4, 2013 at 6:20 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 4 April 2013 17:17, Fabien Chouteau <chouteau@adacore.com> wrote:
>>>
>>> But -kernel for QEMU specifically means Linux kernel; you might
>>> argue we should have picked a different option name but we're
>>> stuck with it now.
>>
>> No, it's not Linux-only. At least qemu-system-sparc can load NetBSD
>> kernel with this option.
>
> Look, you're not exactly making friends if you keep pointing out that
> something works somewhere and you try to deduce a rule out of that. ;)
>
> -bios loads something where the hardware expects it, not necessarily
> RAM. If using ELF, the entry point must be configured appropriately.
>
> -kernel loads something into RAM in a way a Linux kernel can run (and it
> does not limit itself to it, so other use cases may or may not work).
>

May I add the -pflash option to this list :)

> Loading something in a way that matches neither hardware nor Linux
> kernel is - for good or bad - simply not really supported at this time.
>
> PMM tried to get a discussion going about how to solve that latter case
> properly some months ago, possibly prompted by Xilinx, and there were
> not many responses, especially no concrete solution beyond vaguely
> pointing to devices/objects rather than fiddling with existing
> -kernel/-bios command line options.

I didn't see this discussion (there too many traffic on Qemu-devel for
me, I can't read everything).

> So I really feel this discussion is out of scope for this PReP patchset!

My goal with this patchset is to be able to load an ELF file and start
the board at its entry point. So we are exactly in the scope.

If the -kernel option is for Linux only, we have to rename it to -linux.
And we remove the ambiguous -kernel option. The question is: Do we want
a -bsd, -solaris, -vxworks, -rtems, etc...?

I think we can keep the -bios option (maybe with an -firmware alias,
this is a question of vocabulary of different architectures). But it
should be possible to disable the default bios, with '-bios -' or '-bios
none' or '-bios null' or '-bios disabled' or whatever.

And I make a proposition for new options:

-elf loads an ELF file in RAM, ROM or whatever memory area and start the
board at entry point.

-raw-bin file=<filename>,addr=0x<load address> loads something at 'addr'

Or we can mix the two with a -load option:

-load file=<raw-bin-file>
-load file=<elf-file>
-load file=<raw-bin-file>,addr=<load address>
-load file=<raw-bin-file>,addr=<load address>,entry=<start addr>

The option can be used as many times as needed on the command line.

-- 
Fabien Chouteau

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Peter Maydell]

On 5 April 2013 10:19, Fabien Chouteau <chouteau@adacore.com> wrote:
> If the -kernel option is for Linux only, we have to rename it to -linux.
> And we remove the ambiguous -kernel option.

This isn't possible, for backwards compatibility reasons. We
have to retain -kernel/-initrd/-append under those names.

> And I make a proposition for new options:
>
> -elf loads an ELF file in RAM, ROM or whatever memory area and start the
> board at entry point.
>
> -raw-bin file=<filename>,addr=0x<load address> loads something at 'addr'
>
> Or we can mix the two with a -load option:
>
> -load file=<raw-bin-file>
> -load file=<elf-file>
> -load file=<raw-bin-file>,addr=<load address>
> -load file=<raw-bin-file>,addr=<load address>,entry=<start addr>
>
> The option can be used as many times as needed on the command line.

Of these, I prefer the last (-load).

thanks
-- PMM

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Andreas Färber]

Am 04.04.2013 18:17, schrieb Fabien Chouteau:
> On 04/04/2013 02:43 PM, Peter Maydell wrote:
>> On 4 April 2013 12:53, Andreas Färber <afaerber@suse.de> wrote:
>>> Alex, isn't ARM running without -bios? Instead of a firmware blob it has
>>> some hardcoded firmware'ish instructions in the loader code.
>>
>> Varies from board to board, but yes, generally we have a trivial
>> bootloader (which on uniprocessor machines doesn't actually run
>> guest code, it just sets registers and memory up to jump to the
>> kernel).
>>
>>> For PReP, Fabien has not stated what his use case actually is (in
>>> particular which hardware?), so it's hard for me to comment on what the
>>> hardware actually does and I thus won't accept random changes just
>>> because they happen to be in Leon3 code. There's nothing conceptually
>>> wrong with loading ELF code so I'm positive we will find a solution to
>>> accommodate all use cases in some way. :)
>>
>> ARM also lets you pass an ELF file to -kernel which it treats
>> as "just pull this blob into RAM and jump to its entrypoint".
> 
> That's what we do for almost all the targets we are using at AdaCore
> (leon, leon3, PReP(602), wrSbc8349(e300), wrSbc8548(e500v2),
> lm3s(arm-M3), TMS570(arm-R4F)).
> 
>> This is useful for 'bare metal' type test cases (equivalent
>> of dumping a file in over JTAG).
> 
> Exactly, maybe I have to explain how we use QEMU here:
> 
> The Ada language provides run-time features (tasking, timing services,
> protected objects, etc...). These can be implemented on top of an OS
> (Windows, Linux, Solaris, vxWorks, etc...). There's also the Ravenscar
> profile, which restrict the language to a subset of run-time features
> suitable for embedded and safety-critical tasks.
> 
> In that case there's no need for and OS, but the program itself can be a
> simple kernel (scheduling, interrupts, timing services...) running on
> bare metal. The program will also do the initialization of the board, so
> there's no need for bootloader/firmware.

Okay, so that's -bios for PReP at least and my patch adds the missing
ELF support, with fallback to current blob loading.

> We run hundreds of thousands of tests on QEMU each days, on all the
> guest platforms above and on Windows and Linux hosts. These tests are
> very short programs that usually run for less than 2 secs.
> 
> In that context having a boot loader that initialize the board and load
> the program from network or disk is not very interesting, it's time
> consuming and it's complicated. Our compiler builds and ELF file, it's
> easier to run it right away.
> 
>> The UI is all wrong, though:
>> -kernel should always mean "load a Linux kernel" and we should
>> have some other way (ideally a cross-architecture way) of saying
>> "just load this binary blob and start it". (-bios isn't that
>> because -bios tends to (a) mean different things on different
>> boards and (b) mean 'put this in flash or whatever' rather than
>> 'dump stuff in RAM and go'.)
>>
> 
> I think -kernel works fine for all architecture. Linux is not the only
> kernel available ;)

I fear that machines have hardcoded some Linux'ish assumptions of where
things get placed, including -append arguments, and what the state the
hardware is in. ;)

-kernel is supposed to be a fast way of loading a kernel, bypassing the
boot loader the hardware usually has, whereas -bios loads something to
baremetal hardware without changing registers from the hardware reset
defaults.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Rob Landley]

On 04/04/2013 04:57:32 AM, Artyom Tarasenko wrote:
> On Thu, Apr 4, 2013 at 11:50 AM, Alexander Graf <agraf@suse.de> wrote:
> >
> > On 04.04.2013, at 11:46, Artyom Tarasenko wrote:
> >
> >> On Thu, Apr 4, 2013 at 10:37 AM, Fabien Chouteau  
> <chouteau@adacore.com> wrote:
> >>>
> >>> On 04/03/2013 06:59 PM, Alexander Graf wrote:
> >>>>
> >>>> On 03.04.2013, at 18:40, Fabien Chouteau wrote:
> >>>>
> >>>>> If we use an ELF kernel there's no need for bios. '-bios -'  
> means no
> >>>>> bios.
> >>>>
> >>>> This sounds like you're actually looking for a way to load an  
> ELF blob
> >>>> as bios using -bios, not a kernel, no?
> >>>>
> >>>
> >>> No, we load the kernel with -kernel, that's what the first patch  
> does.
> >>> But the board is implemented in such way that you can't start  
> without a
> >>> bios. If the -bios switch is not present, then the board uses the
> >>> default bios. This patch allows to start without a bios:
> >>>
> >>> -kernel <PROGRAM> -bios -
> >>
> >> Regardless of the firmware vs. kernel discussion, I think the  
> syntax
> >> may be improved. Under *nix '-' is commonly used for stdin. Would  
> it
> >> be possible to specify /dev/null (under *NIX) or NUL (in the
> >> MS-World)? I think it would make the syntax more explicit.
> >
> > I'd be inclined to say that running -kernel without -bios is simply  
> bogus and shouldn't ever happen.
> 
> QEMU does it at least in one other architectures though:  
> leon3_generic.

sh4 runs without bios, arm versatile runs without bios, mips runs  
without bios...

http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 (or  
system-image-sh4.tar.bz2 or system-image-mips.tar.bz2) and  
./run-emulator.sh in that. Boots to a shell prompt, no bios.

Rob

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Andreas Färber]

Am 04.04.2013 10:37, schrieb Fabien Chouteau:
> 
> On 04/03/2013 06:59 PM, Alexander Graf wrote:
>> The preferred way to load a kernel with -kernel is to load firmware
>> which then detects that a kernel was loaded with -kernel and jumps in.
>> Once Andreas moves PReP to OpenBIOS, this will be the normal mode of
>> operation there too.
> 
> I'll have a look at Andreas' branch and see if it fits our scheme.

Rebased and pushed here:
http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/prep-openbios

Matching OpenBIOS hacks:
http://repo.or.cz/w/openbios/afaerber.git/shortlog/refs/heads/prep

HTH,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image

[Fabien Chouteau]

On 04/04/2013 01:16 PM, Andreas Färber wrote:
> Am 04.04.2013 10:37, schrieb Fabien Chouteau:
>>
>> On 04/03/2013 06:59 PM, Alexander Graf wrote:
>>> The preferred way to load a kernel with -kernel is to load firmware
>>> which then detects that a kernel was loaded with -kernel and jumps in.
>>> Once Andreas moves PReP to OpenBIOS, this will be the normal mode of
>>> operation there too.
>>
>> I'll have a look at Andreas' branch and see if it fits our scheme.
> 
> Rebased and pushed here:
> http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/prep-openbios
> 
> Matching OpenBIOS hacks:
> http://repo.or.cz/w/openbios/afaerber.git/shortlog/refs/heads/prep
> 

Thanks, I'll have a look.

-- 
Fabien Chouteau

Re: [Qemu-devel] [PATCH 0/3] PPC PReP: Use ElF kernel on PReP

[Alexander Graf]

On 03.04.2013, at 18:40, Fabien Chouteau wrote:

> This patches serie implements ELF kernel support in PPC PReP board.
> 
> - Being able to load an ELF file
> - Use the entry point to set nip value a reset
> - Allow to run the board without bios

Andreas maintains PReP :).


Alex

> 
> Fabien Chouteau (3):
>  PPC PReP: Load ELF kernel
>  PPC PReP: Use kernel entry to set nip at reset
>  PPC PReP: can run without bios image
> 
> hw/ppc/prep.c |   67 ++++++++++++++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 54 insertions(+), 13 deletions(-)
> 
> -- 
> 1.7.9.5
> 

Re: [Qemu-devel] [PATCH 0/3] PPC PReP: Use ElF kernel on PReP

[Andreas Färber]

Am 03.04.2013 18:47, schrieb Alexander Graf:
> 
> On 03.04.2013, at 18:40, Fabien Chouteau wrote:
> 
>> This patches serie implements ELF kernel support in PPC PReP board.
>>
>> - Being able to load an ELF file
>> - Use the entry point to set nip value a reset
>> - Allow to run the board without bios
> 
> Andreas maintains PReP :).

...and I have a branch that can load OpenBIOS. :)

Andreas

> 
> 
> Alex
> 
>>
>> Fabien Chouteau (3):
>>  PPC PReP: Load ELF kernel
>>  PPC PReP: Use kernel entry to set nip at reset
>>  PPC PReP: can run without bios image
>>
>> hw/ppc/prep.c |   67 ++++++++++++++++++++++++++++++++++++++++++++++-----------
>> 1 file changed, 54 insertions(+), 13 deletions(-)
>>
>> -- 
>> 1.7.9.5
>>
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 0/3] PPC PReP: Use ElF kernel on PReP

[Fabien Chouteau]

On 04/03/2013 07:32 PM, Andreas Färber wrote:
> Am 03.04.2013 18:47, schrieb Alexander Graf:
>>
>> On 03.04.2013, at 18:40, Fabien Chouteau wrote:
>>
>>> This patches serie implements ELF kernel support in PPC PReP board.
>>>
>>> - Being able to load an ELF file
>>> - Use the entry point to set nip value a reset
>>> - Allow to run the board without bios
>>
>> Andreas maintains PReP :).
> 
> ...and I have a branch that can load OpenBIOS. :)

Sorry I didn't know, where is that branch?

Regards,

-- 
Fabien Chouteau