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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Sep 2009 01:11:54 -0500
From:	Rob Landley <rob@...dley.net>
To:	Paul Mundt <lethal@...ux-sh.org>
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 Friday 25 September 2009 03:44:30 Paul Mundt wrote:
> On Sun, Sep 20, 2009 at 07:19:17PM -0500, Rob Landley wrote:
> > The 2.6.30 kernel in the system image at
> > http://impactlinux.com/fwl/downloads/binaries/system-image-sh4.tar.bz2
> > boots to a shell prompt under a reasonably current qemu-git snapshot
> > (sometime Tuesday I think).
>
> In the future please make sure to cc the linux-sh@...r.kernel.org list, I
> only stumbled across this by chance.

Will do, thanks.

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

> > #
> > # 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.

> It's actually quite remarkable how far you
> made it in the boot process without a timer interrupt.

Tickless kernels, gotta love 'em. :)

> I'm running current git with qemu and the kernel without any issue,
> except for the aforementioned libata stuff.

Thank you.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
--
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/