| Message ID | 1365007213-27603-4-git-send-email-chouteau@adacore.com |
|---|---|
| State | New |
| Headers | show |
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
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,
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
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
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
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
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
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
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
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
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 ;)
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.
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.
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
No conclusion was finally done about the new option proposal to load roms files. It really would be handy. -- 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
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) {
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(-)