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