[Aboriginal] qemu-system-sh4 sdb mounting broken

Sun Mar 2 09:49:01 PST 2014

On 02/28/14 10:16, John Spencer wrote:
> /dev/sdb is not there, and there are a lot of kernel errors...
> see below

Yeah, I've been poking at sh4 a bit this week. If you boot to a shell
prompt and then hit ctrl-c at that prompt, QEMU receives the interrupt
and exits.

Sigh. (Qemu bug, I should report it upstream and come up with a local
patch...)

The sh4 emulation only emulates one hard drive. For local hacking I did
a 2 gigabyte ext2 image.

AND the sh4 emulation only emulates 64 megs ram, so I created a swap
file in that ext2 hda.

And THEN I hit a bug where clock thought it was 1990 (make is unhappy
when files are in the future), and the toybox "date" command was
refusing to set the time. So, toybox bug added to the heap.

But right now, the musl guys announced feature freeze for 1.0 so I've
been dinking at the ccwrap rewrite to let aboriginal use musl. Doesn't
look like I'll get it done this weekend, but it's bubbled to the top of
my todo list due to external packages I need to stay up to date with.

(Speaking of which: yes, I missed a kernel version.
http://landley.net/notes-2014.html#06-02-2014 made me just not want to
_think_ about the kernel for a bit. At this point my plan isnext
aboriginal release will probably be two releases, catching us up on the
kernel version. I should do one using 3.13 just in case anybody wants to
use that specific version, and the 3.14 one at approximately the same
time to catch up.)

Sorry 'bout the radio silence.

> + qemu-system-sh4 -M r2d -nographic -no-reboot -kernel zImage -hda
> hda.sqf -append 'root=/dev/sda rw init=/sbin/
> init.sh panic=1 PATH=/bin:/sbin console=ttySC1 noiotrap HOST=sh4 CPUS=1
> ' -hdb hdb.img -m 256 -monitor null -ser
> ial null -serial stdio
> 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

Those are actually qemu errors (you can tell because they're to stderr,
not stdout).

> Linux version 3.12.0 (landley at driftwood) (gcc version 4.2.1) #1 Mon Nov
> 18 10:05:39 CST 2013
> 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
> Node 0: start_pfn = 0xc000, low = 0x10000
> Zone ranges:
>   Normal   [mem 0x0c000000-0x0fffffff]
> Movable zone start for each node
> Early memory node ranges
>   node   0: [mem 0x0c000000-0x0fffffff]
> Renesas Technology Sales RTS7751R2D support.
> FPGA version:1 (revision:0)
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
> Kernel command line: root=/dev/sda rw init=/sbin/init.sh panic=1
> PATH=/bin:/sbin console=ttySC1 noiotrap HOST=sh4 CPUS=1
> PID hash table entries: 256 (order: -2, 1024 bytes)
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Sorting __ex_table...
> 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
> Memory: 62188K/65536K available (1977K kernel code, 136K rwdata, 264K
> rodata, 96K init, 183K bss, 3344K reserved)
> virtual kernel memory layout:
>     fixmap  : 0xdfff7000 - 0xdffff000   (  32 kB)
>     vmalloc : 0xc0000000 - 0xdfff5000   ( 511 MB)
>     lowmem  : 0x8c000000 - 0x90000000   (  64 MB) (cached)
>             : 0xa0000000 - 0xc0000000   ( 512 MB) (uncached)
>       .init : 0x8c265000 - 0x8c27d000   (  96 kB)
>       .data : 0x8c1ff700 - 0x8c2649e0   ( 404 kB)
>       .text : 0x8c010000 - 0x8c1ff700   (1981 kB)
> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> NR_IRQS:8 nr_irqs:8 0
> intc: Registered controller 'sh7750' with 20 IRQs
> intc: Registered controller 'sh7750_dma8' with 9 IRQs
> intc: Registered controller 'sh7750_tmu34' with 2 IRQs
> intc: Registered controller 'sh7750_pci' with 8 IRQs
> Using R2D-PLUS interrupt controller.
> intc: Registered controller 'r2d-plus' with 13 IRQs
>  sh_tmu.0: used for clock events
>  sh_tmu.0: used for periodic clock events
>  sh_tmu.1: used as clock source
> Calibrating delay loop (skipped)... 120.00 BogoMIPS PRESET (lpj=240000)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: SH7751R
> devtmpfs: initialized
> NET: Registered protocol family 16
> PCI: Starting initialization.
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> sh_tmu sh_tmu.0: kept as earlytimer
> sh_tmu sh_tmu.1: kept as earlytimer
> PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io  0x1000-0x3fffff]
> pci_bus 0000:00: root bus resource [mem 0xfd000000-0xfdffffff]
> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
> pci 0000:00:02.0: BAR 6: assigned [mem 0xfd000000-0xfd03ffff pref]
> pci 0000:00:02.0: BAR 0: assigned [io  0x1000-0x10ff]
> pci 0000:00:02.0: BAR 1: assigned [mem 0xfd040000-0xfd0400ff]
> Switched to clocksource sh_tmu.1
> sh_tmu sh_tmu.0: used for oneshot clock events
> NET: Registered protocol family 2
> TCP established hash table entries: 512 (order: 0, 4096 bytes)
> TCP bind hash table entries: 512 (order: -1, 2048 bytes)
> TCP: Hash tables configured (established 512 bind 512)
> TCP: reno registered
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> squashfs: version 4.0 (2009/01/31) Phillip Lougher
> 9p: Installing v9fs 9p2000 file system support
> msgmni has been set to 121
> io scheduler noop registered (default)
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> SuperH (H)SCI(F) driver initialized
> sh-sci.1: ttySC1 at MMIO 0xffe80000 (irq = 40, base_baud = 0) is a scif
> console [ttySC1] enabled
> loop: module loaded
> sm501 sm501: SM501 At b3e00000: Version 050100a0, 8 Mb, IRQ 100
> Attribute dbg_regs: write permission without 'store'
> ------------[ cut here ]------------
> WARNING: at 8c1487c0 [verbose debug info unavailable]
> 
> CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0 #1
> task: 8fc2c000 ti: 8fc2e000 task.ti: 8fc2e000
> PC  : 8c1487c0 SP  : 8fc2fe78 SR  : 40008000 TEA : 00000000
> R0  : 00000034 R1  : 00000000 R2  : 40008000 R3  : 00000000
> R4  : 00000000 R5  : 8c280e1c R6  : 00000002 R7  : 00001ac4
> R8  : 8c25df38 R9  : 8c253280 R10 : 8fd5b480 R11 : 8c147d5c
> R12 : 8fd5b4fc R13 : 00000000 R14 : 00000000
> MACH: 00000000 MACL: 0000005b GBR : 00000000 PR  : 8c1487c0

Is that this old bug?

http://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg03870.html

Pretty sure it wasn't doing that last time I tried it, but I'm not sure
which version I was testing. I can take a look in a bit, I have to run
right now...

> reboot: Restarting system
> Unauthorized access
> qemu: fatal: Trying to execute code outside RAM or ROM at 0xa0000000
> 
> pc=0xa0000000 sr=0x700000f0 pr=0x8c013324 fpscr=0x00080000
> spc=0x8c01332a ssr=0x10000000 gbr=0x00463448 vbr=0x8c018000
> sgr=0x8fe6fe88 dbr=0x00000000 delayed_pc=0x8c013324 fpul=0x00000000
> r0=0x400080f1 r1=0x80000001 r2=0x10000000 r3=0x00000000
> r4=0x000000f0 r5=0x8c280e1c r6=0x00000006 r7=0x00002c4c
> r8=0x01234567 r9=0x00000000 r10=0xfee1dead r11=0x01234567
> r12=0x00000000 r13=0x00000000 r14=0x7bab3d04 r15=0x8fe6fe88
> r16=0x00000000 r17=0xffffff0f r18=0x40008000 r19=0x40008000
> r20=0x8fe6fe30 r21=0x00000000 r22=0x00000000 r23=0x8fe6e000
> Killed

It never rebooted cleanly. That's a qemu problem, not a kernel problem.
(Hey, the emulator exits. I'll take it.)

> btw, after receiving the kill signal, the terminal (xterm) is messed up
> (you dont see what you type, and hitting enter displays the new prompt
> in the same line instead of on a new line).

Yup. Type "reset" and hit enter to fix it.

Again, a qemu bug.

> if otoh you run the qemu command by hand, the terminal stays intact.
> putting the qemu command into a script file and calling that, the
> breakage is there as well.
> so it seems there's some interaction between the qemu kill and the shell
> running as script processor (both bash and ash are affected).

Qemu needs a signal handler to reset the terminal state. Most targets
have one, sh4 doesn't.

The fact they implemented qemu so you need to reimplement that per
target is left as a rant for the reader...

Rob