[Aboriginal] qemu-system-sh4 sdb mounting broken

[John Spencer]

Rob Landley wrote:
> 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...)

is there a known good version of qemu-system-sh4 ?

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

hmm... in that case it may make sense if the dev-environment script has 
special case code for sh4 that creates an image with userdefined size 
and then copies the rootfs on it.
otherwise anyone trying it will be puzzled that his hdb.img doesn't get 
mounted.

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

yes...

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

experiencing date problems with current image as well.
the clock is set to 2000-01-01, and that seems to confuse make.
if the busybox date command can deal with that better, maybe it makes 
sense to revert that applet to busybox again.

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

[...]

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

doesn't seem so, the emulation doesn't abort

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

good to know. can we maybe add that to the run-emulator script (at least 
for all known-broken archs) ?

type reset > /dev/null && reset
(we need to check it's there since its a ncurses command)

 1393863853.0