2.6.31 kernel built for sh4 doesn't boot under qemu-system-sh4.
Rob Landley
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).
Swapping in a 2.6.31 kernel, the boot gets as far as:
>long read to SH7750_WCR1_A7 (0x000000001f800008) ignored
>long read to SH7750_WCR2_A7 (0x000000001f80000c) ignored
>long read to SH7750_WCR3_A7 (0x000000001f800010) ignored
>long read to SH7750_MCR_A7 (0x000000001f800014) ignored
>long read to SH7750_MCR_A7 (0x000000001f800014) ignored
>Linux version 2.6.30-rc4 (landley@driftwood) (gcc version 4.2.1) #1 Sun Sep
> 20 18:55:18 CDT 2009 Boot params:
>... MOUNT_ROOT_RDONLY - 00000000
>... RAMDISK_FLAGS - 00000000
>... ORIG_ROOT_DEV - 00000000
>... LOADER_TYPE - 00000000
>... INITRD_START - 00000000
>... INITRD_SIZE - 00000000
>Booting machvec: RTS7751R2D
>Renesas Technology Sales RTS7751R2D support.
>FPGA version:1 (revision:0)
>Node 0: start_pfn = 0xc000, low = 0x10000
>Zone PFN ranges:
> Normal 0x0000c000 -> 0x00010000
>Movable zone start PFN for each node
>early_node_map[1] active PFN ranges
> 0: 0x0000c000 -> 0x00010000
>Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
>Kernel command line: root=/dev/sda rw init=/usr/sbin/init.sh panic=1
> PATH=/usr/distcc:/usr/bin console=ttySC0 DISTCC_HOSTS=10.0.2.2:28739/4
> CPUS=4 NR_IRQS:256
>Using R2D-PLUS interrupt controller.
>PID hash table entries: 256 (order: 8, 1024 bytes)
>Console: colour dummy device 80x25
>Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
>Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
>Memory: 61072k/65536k available (2306k kernel code, 598k data, 116k init)
>PVR=04050005 CVR=00110000 PRR=00000113
>I-cache : n_ways=2 n_sets=64 way_incr=2048
>I-cache : entry_mask=0x000007e0 alias_mask=0x00000000 n_aliases=0
>D-cache : n_ways=2 n_sets=64 way_incr=2048
>D-cache : entry_mask=0x000007e0 alias_mask=0x00000000 n_aliases=0
>Calibrating delay loop (skipped)... 120.00 BogoMIPS PRESET (lpj=240000)
>Mount-cache hash table entries: 512
>CPU: SH7751R
>net_namespace: 520 bytes
>NET: Registered protocol family 16
>PCI: Starting intialization.
>PCI: Using configuration type 1
>registering PCI controller with io_map_base unset
>bio: create slab <bio-0> at 0
>SCSI subsystem initialized
>usbcore: registered new interface driver usbfs
>usbcore: registered new interface driver hub
>usbcore: registered new device driver usb
>NET: Registered protocol family 2
>IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
>TCP established hash table entries: 2048 (order: 2, 16384 bytes)
>TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
>TCP: Hash tables configured (established 2048 bind 2048)
>TCP reno registered
>NET: Registered protocol family 1
>trapped io 0xc0000000 overrides mmio 0xb4001000
>trapped io 0xc0001000 overrides mmio 0xb400080c
>squashfs: version 4.0 (2009/01/31) Phillip Lougher
>msgmni has been set to 119
>io scheduler noop registered
>io scheduler anticipatory registered (default)
>io scheduler deadline registered
>io scheduler cfq registered
>pci_hotplug: PCI Hot Plug PCI Core version: 0.5
>Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>SuperH SCI(F) driver initialized
>sh-sci: ttySC0 at MMIO 0xffe80000 (irq = 40) is a scif
>console [ttySC0] enabled
>brd: module loaded
>sm501 sm501: SM501 At b3e00000: Version 050100a0, 8 Mb, IRQ 100
And hangs at that point.
I've managed to bisect it to kernel commit
8be5f1a68f2c14082939dd54e7037dcee2eb54f8 which is messing around with the
timer code.
Attached is the .config I'm building with. If you need the toolchain, it's at
http://impactlinux.com/fwl/downloads/binaries/cross-static-sh4.tar.bz2
I dunno if this is a kernel issue or a qemu issue, so I thought I'd ping both
lists.
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
Paul Mundt
> 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).
>
only stumbled across this by chance.
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.
> >squashfs: version 4.0 (2009/01/31) Phillip Lougher
> >msgmni has been set to 119
> >io scheduler noop registered
> >io scheduler anticipatory registered (default)
> >io scheduler deadline registered
> >io scheduler cfq registered
> >pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> >Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> >SuperH SCI(F) driver initialized
> >sh-sci: ttySC0 at MMIO 0xffe80000 (irq = 40) is a scif
> >console [ttySC0] enabled
> >brd: module loaded
> >sm501 sm501: SM501 At b3e00000: Version 050100a0, 8 Mb, IRQ 100
>
> And hangs at that point.
>
Well, the fact you have no clocksource or clockevent messages in this
log explains why you're hanging..
> I've managed to bisect it to kernel commit
> 8be5f1a68f2c14082939dd54e7037dcee2eb54f8 which is messing around with the
> timer code.
>
It's not so much "messing around" as it is "moving to new
infrastructure". I can guess what happened. You probably ran through
oldconfig across these versions, the old TMU config option went away, and
the new one was default-disabled, leaving you without clockevents. Lets
see..
> #
> # 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. It's actually quite remarkable how far you
made it in the boot process without a timer interrupt.
I'm running current git with qemu and the kernel without any issue,
except for the aforementioned libata stuff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Rob Landley
> 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 linu...@vger.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
Paul Mundt
> 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.
>
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.