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