linux-kernel - Re: [Qemu-devel] 2.6.31 kernel built for sh4 doesn't boot under qemu-system-sh4.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20090928061922.GA6668@linux-sh.org>
Date:	Mon, 28 Sep 2009 15:19:22 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Rob Landley <rob@...dley.net>
Cc:	kernel list <linux-kernel@...r.kernel.org>, qemu-devel@...gnu.org
Subject: Re: [Qemu-devel] 2.6.31 kernel built for sh4 doesn't boot under qemu-system-sh4.

On Mon, Sep 28, 2009 at 01:11:54AM -0500, Rob Landley wrote:
> On Friday 25 September 2009 03:44:30 Paul Mundt wrote:
> > > >trapped io 0xc0000000 overrides mmio 0xb4001000
> > > >trapped io 0xc0001000 overrides mmio 0xb400080c
> >
> > Also, you do not want to be using trapped io with qemu, it is only there
> > to aid broken hardware, and degrades performance under emulation. Boot
> > with the "noiotrap" argument on the kernel command line, documented in
> > Documentation/kernel-parameters.txt.
> 
> Is _that_ why it's so slow?  Thanks.
> 
Yes, you can see more about it here:

http://marc.info/?t=123850681600007&r=1&w=2

This isn't a problem for most platforms, but unfortunately it is for the
one that qemu has chosen to emulate. It would be nice if we had a way to
figure out if we were under emulation from the kernel side, then these
sorts of things can be tuned automatically.

> > > #
> > > # Timer and clock configuration
> > > #
> > > # CONFIG_SH_TIMER_TMU is not set
> > > CONFIG_SH_PCLK_FREQ=60000000
> > > CONFIG_SH_CLK_CPG=y
> > > CONFIG_SH_CLK_CPG_LEGACY=y
> > > # CONFIG_NO_HZ is not set
> > > # CONFIG_HIGH_RES_TIMERS is not set
> > > CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
> >
> > And here we can see that the TMU option is unset. Fix this up and
> > everything should be fine.
> 
> Yup, that did it.
> 
I suppose we should see about making it impossible to run in to this
situation in the future. I'll see if I can come up with something clever
in Kconfig to make sure at least one gets enabled. 'choice' semantics are
not sufficient, given that many platforms require multiple timers to be
enabled.

> > It's actually quite remarkable how far you
> > made it in the boot process without a timer interrupt.
> 
> Tickless kernels, gotta love 'em. :)
> 
You would have never made it past the delay loop calibration, except for
the fact that we don't use the timer for that, we calculate the value
directly from the clock framework, so there is no 'real' calibration.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/