From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNnbT-0000h3-Ut for qemu-devel@nongnu.org; Thu, 04 Apr 2013 13:05:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNnbS-0006C0-CD for qemu-devel@nongnu.org; Thu, 04 Apr 2013 13:05:35 -0400 Message-ID: <515DB2DB.30907@suse.de> Date: Thu, 04 Apr 2013 19:05:31 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1365007213-27603-1-git-send-email-chouteau@adacore.com> <1365007213-27603-4-git-send-email-chouteau@adacore.com> <7C0E04C3-1FDF-460E-8F78-1E24E5759C93@suse.de> <515D3BDE.20400@adacore.com> <8FE7E3AF-D822-4DBF-8A7E-BD0EA80AD07A@suse.de> <515D69B8.9040007@suse.de> <515DA789.1060505@adacore.com> In-Reply-To: <515DA789.1060505@adacore.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fabien Chouteau Cc: Peter Maydell , Alexander Graf , qemu-devel , =?UTF-8?B?SGVydg==?= =?UTF-8?B?w6kgUG91c3NpbmVhdQ==?= , qemu-ppc@nongnu.org, Artyom Tarasenko 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=C3=A4rber 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 t= he >>> 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 t= o >>> 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". >=20 > 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)). >=20 >> This is useful for 'bare metal' type test cases (equivalent >> of dumping a file in over JTAG). >=20 > Exactly, maybe I have to explain how we use QEMU here: >=20 > 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. >=20 > 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, s= o > 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. >=20 > 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. >=20 >> 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'.) >> >=20 > 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg