Commit 18e8cf159177 broke qemu-system-sh4 serial input.

Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Rob Landley]

In 4.11-rc7 the qemu serial console hangs after the first character you
type. To reproduce, configure linux with this mini.config:

CONFIG_CPU_SUBTYPE_SH7751R=y
CONFIG_MMU=y
CONFIG_MEMORY_START=0x0c000000
CONFIG_VSYSCALL=y
CONFIG_SH_FPU=y
CONFIG_SH_RTS7751R2D=y
CONFIG_RTS7751R2D_PLUS=y
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_CONSOLE=y
CONFIG_EARLY_PRINTK=y
CONFIG_BLK_DEV_INITRD=y"
CONFIG_RD_GZIP=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_DEVTMPFS=y

Using "make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=mini.conf", then build
the result, then boot under qemu using the following command line:

qemu-system-sh4 -M r2d -monitor null -serial null -serial stdio
-nographic -no-reboot -append "panic=1 HOST=sh4 console=ttySC1 noiotrap"
-kernel zImage -initrd sh4-linux-musl-root.cpio.gz

You'll need a simple cpio.gz initramfs (I built one using
https://github.com/landley/mkroot and the musl-cross-make cross
compiler, the cpio.gz is ~450k or I'd attach it here).

I bisected it to commit 18e8cf159177 back in February. If you do this
with the revision _before_ that commit, typing "ls -l" and hitting enter
works fine. Afterwards you get an "l" and then it hangs. (If type enough
it'll eventually deal a burst of characters all at once, and then hang
again.)

Rob

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Geert Uytterhoeven]

Hi Rob,

CC Adrian, linux-serial, linux-renesas-soc

On Fri, Apr 21, 2017 at 8:21 AM, Rob Landley <rob@landley.net> wrote:
> In 4.11-rc7 the qemu serial console hangs after the first character you
> type. To reproduce, configure linux with this mini.config:
>
> CONFIG_CPU_SUBTYPE_SH7751R=y
> CONFIG_MMU=y
> CONFIG_MEMORY_START=0x0c000000
> CONFIG_VSYSCALL=y
> CONFIG_SH_FPU=y
> CONFIG_SH_RTS7751R2D=y
> CONFIG_RTS7751R2D_PLUS=y
> CONFIG_SERIAL_SH_SCI=y
> CONFIG_SERIAL_SH_SCI_CONSOLE=y
> CONFIG_EARLY_PRINTK=y
> CONFIG_BLK_DEV_INITRD=y"
> CONFIG_RD_GZIP=y
> CONFIG_BINFMT_ELF=y
> CONFIG_BINFMT_SCRIPT=y
> CONFIG_MISC_FILESYSTEMS=y
> CONFIG_DEVTMPFS=y
>
> Using "make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=mini.conf", then build
> the result, then boot under qemu using the following command line:
>
> qemu-system-sh4 -M r2d -monitor null -serial null -serial stdio
> -nographic -no-reboot -append "panic=1 HOST=sh4 console=ttySC1 noiotrap"
> -kernel zImage -initrd sh4-linux-musl-root.cpio.gz
>
> You'll need a simple cpio.gz initramfs (I built one using
> https://github.com/landley/mkroot and the musl-cross-make cross
> compiler, the cpio.gz is ~450k or I'd attach it here).
>
> I bisected it to commit 18e8cf159177 back in February. If you do this
> with the revision _before_ that commit, typing "ls -l" and hitting enter
> works fine. Afterwards you get an "l" and then it hangs. (If type enough
> it'll eventually deal a burst of characters all at once, and then hang
> again.)

SH7751R has both SCI and SCIF ports. ttySC1 is the second (SCIF) port.

arch/sh/kernel/cpu/sh4/setup-sh7750.c registers a port with type PORT_SCIF,
so that should become SCIx_SH4_SCIF_REGTYPE. Hence I don't think the issue
is caused by changing fifosize to 64 for SCIx_SH7705_SCIF_REGTYPE.

My first guess is that qemu has a bug emulating the triggering.
According to the SH7751R datasheet, SCFCR does have the RTRG1 and RTRG0 bits.
I assume the problem goes away if you comment out the call to scif_set_rtrg()?

Does anyone have access to real hardware to try?
Adrian: does it work on your LANDISK, which also has SH7751R?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Geert Uytterhoeven]

Hi Rob,

CC Adrian, linux-serial, linux-renesas-soc

On Fri, Apr 21, 2017 at 8:21 AM, Rob Landley <rob@landley.net> wrote:
> In 4.11-rc7 the qemu serial console hangs after the first character you
> type. To reproduce, configure linux with this mini.config:
>
> CONFIG_CPU_SUBTYPE_SH7751R=y
> CONFIG_MMU=y
> CONFIG_MEMORY_START=0x0c000000
> CONFIG_VSYSCALL=y
> CONFIG_SH_FPU=y
> CONFIG_SH_RTS7751R2D=y
> CONFIG_RTS7751R2D_PLUS=y
> CONFIG_SERIAL_SH_SCI=y
> CONFIG_SERIAL_SH_SCI_CONSOLE=y
> CONFIG_EARLY_PRINTK=y
> CONFIG_BLK_DEV_INITRD=y"
> CONFIG_RD_GZIP=y
> CONFIG_BINFMT_ELF=y
> CONFIG_BINFMT_SCRIPT=y
> CONFIG_MISC_FILESYSTEMS=y
> CONFIG_DEVTMPFS=y
>
> Using "make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=mini.conf", then build
> the result, then boot under qemu using the following command line:
>
> qemu-system-sh4 -M r2d -monitor null -serial null -serial stdio
> -nographic -no-reboot -append "panic=1 HOST=sh4 console=ttySC1 noiotrap"
> -kernel zImage -initrd sh4-linux-musl-root.cpio.gz
>
> You'll need a simple cpio.gz initramfs (I built one using
> https://github.com/landley/mkroot and the musl-cross-make cross
> compiler, the cpio.gz is ~450k or I'd attach it here).
>
> I bisected it to commit 18e8cf159177 back in February. If you do this
> with the revision _before_ that commit, typing "ls -l" and hitting enter
> works fine. Afterwards you get an "l" and then it hangs. (If type enough
> it'll eventually deal a burst of characters all at once, and then hang
> again.)

SH7751R has both SCI and SCIF ports. ttySC1 is the second (SCIF) port.

arch/sh/kernel/cpu/sh4/setup-sh7750.c registers a port with type PORT_SCIF,
so that should become SCIx_SH4_SCIF_REGTYPE. Hence I don't think the issue
is caused by changing fifosize to 64 for SCIx_SH7705_SCIF_REGTYPE.

My first guess is that qemu has a bug emulating the triggering.
According to the SH7751R datasheet, SCFCR does have the RTRG1 and RTRG0 bits.
I assume the problem goes away if you comment out the call to scif_set_rtrg()?

Does anyone have access to real hardware to try?
Adrian: does it work on your LANDISK, which also has SH7751R?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[John Paul Adrian Glaubitz]

On 04/21/2017 09:26 AM, Geert Uytterhoeven wrote:
> Does anyone have access to real hardware to try?
> Adrian: does it work on your LANDISK, which also has SH7751R?

I can give it a try but that will take a few days since I am currently
not at home where my LANDISK boxes are. I also had issues with the
IDE driver in the past but Sato-san gave me some tips regarding it.

However, Rich also has a LANDISK device that I donated for him, so if his
hardware is currently ready to use, he could give it a try.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[John Paul Adrian Glaubitz]

On 04/21/2017 09:26 AM, Geert Uytterhoeven wrote:
> Does anyone have access to real hardware to try?
> Adrian: does it work on your LANDISK, which also has SH7751R?

I can give it a try but that will take a few days since I am currently
not at home where my LANDISK boxes are. I also had issues with the
IDE driver in the past but Sato-san gave me some tips regarding it.

However, Rich also has a LANDISK device that I donated for him, so if his
hardware is currently ready to use, he could give it a try.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Rob Landley]

On 04/21/2017 02:26 AM, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> CC Adrian, linux-serial, linux-renesas-soc
> 
> On Fri, Apr 21, 2017 at 8:21 AM, Rob Landley <rob@landley.net> wrote:
>> In 4.11-rc7 the qemu serial console hangs after the first character you
>> type. To reproduce, configure linux with this mini.config:
>>
>> CONFIG_CPU_SUBTYPE_SH7751R=y
>> CONFIG_MMU=y
>> CONFIG_MEMORY_START=0x0c000000
>> CONFIG_VSYSCALL=y
>> CONFIG_SH_FPU=y
>> CONFIG_SH_RTS7751R2D=y
>> CONFIG_RTS7751R2D_PLUS=y
>> CONFIG_SERIAL_SH_SCI=y
>> CONFIG_SERIAL_SH_SCI_CONSOLE=y
>> CONFIG_EARLY_PRINTK=y
>> CONFIG_BLK_DEV_INITRD=y"
>> CONFIG_RD_GZIP=y
>> CONFIG_BINFMT_ELF=y
>> CONFIG_BINFMT_SCRIPT=y
>> CONFIG_MISC_FILESYSTEMS=y
>> CONFIG_DEVTMPFS=y
>>
>> Using "make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=mini.conf", then build
>> the result, then boot under qemu using the following command line:
>>
>> qemu-system-sh4 -M r2d -monitor null -serial null -serial stdio
>> -nographic -no-reboot -append "panic=1 HOST=sh4 console=ttySC1 noiotrap"
>> -kernel zImage -initrd sh4-linux-musl-root.cpio.gz
>>
>> You'll need a simple cpio.gz initramfs (I built one using
>> https://github.com/landley/mkroot and the musl-cross-make cross
>> compiler, the cpio.gz is ~450k or I'd attach it here).
>>
>> I bisected it to commit 18e8cf159177 back in February. If you do this
>> with the revision _before_ that commit, typing "ls -l" and hitting enter
>> works fine. Afterwards you get an "l" and then it hangs. (If type enough
>> it'll eventually deal a burst of characters all at once, and then hang
>> again.)
> 
> SH7751R has both SCI and SCIF ports. ttySC1 is the second (SCIF) port.

Yeah, my qemu invocation for sh4 is a bit eldrich, I got it from the
qemu mailing list. Possibly from:

https://lists.nongnu.org/archive/html/qemu-devel/2007-09/msg00530.html

The really _fun_ thing about this is qemu broke it a couple years back
and now if you hit ctrl-c it kills the _emulator_ rather than passing it
through to the Linux console. (Just sh4, the rest do it right.)

I complained about it on the qemu mailing list in 2014 but nobody there
cared:

http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00000.html

Of course that's actually _useful_ for the testing I'm doing now because
when the kernel tries to shut down qemu it goes:

  / # exit
  reboot: Restarting system
  Unauthorized access

And then hangs eating 100% cpu. (Wheee!)

>  registers a port with type PORT_SCIF,
> so that should become SCIx_SH4_SCIF_REGTYPE. Hence I don't think the issue
> is caused by changing fifosize to 64 for SCIx_SH7705_SCIF_REGTYPE.
> 
> My first guess is that qemu has a bug emulating the triggering.

Very likely given how crappy the rest of its serial emulation is for
this architecture, but ever since qemu added glib support I've stopped
trying to understand their developers' thought processes.

> According to the SH7751R datasheet, SCFCR does have the RTRG1 and RTRG0 bits.
> I assume the problem goes away if you comment out the call to scif_set_rtrg()?

The current code has been further complicated by two more commits
(039403765 and 90afa5255) doing who knows what, but deleting the
"scif_set_rtrg(port, s->rx_trigger);" from sci_reset() does appear to
fix the problem.

Rob

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Rob Landley]

On 04/21/2017 02:26 AM, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> CC Adrian, linux-serial, linux-renesas-soc
> 
> On Fri, Apr 21, 2017 at 8:21 AM, Rob Landley <rob@landley.net> wrote:
>> In 4.11-rc7 the qemu serial console hangs after the first character you
>> type. To reproduce, configure linux with this mini.config:
>>
>> CONFIG_CPU_SUBTYPE_SH7751R=y
>> CONFIG_MMU=y
>> CONFIG_MEMORY_START=0x0c000000
>> CONFIG_VSYSCALL=y
>> CONFIG_SH_FPU=y
>> CONFIG_SH_RTS7751R2D=y
>> CONFIG_RTS7751R2D_PLUS=y
>> CONFIG_SERIAL_SH_SCI=y
>> CONFIG_SERIAL_SH_SCI_CONSOLE=y
>> CONFIG_EARLY_PRINTK=y
>> CONFIG_BLK_DEV_INITRD=y"
>> CONFIG_RD_GZIP=y
>> CONFIG_BINFMT_ELF=y
>> CONFIG_BINFMT_SCRIPT=y
>> CONFIG_MISC_FILESYSTEMS=y
>> CONFIG_DEVTMPFS=y
>>
>> Using "make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=mini.conf", then build
>> the result, then boot under qemu using the following command line:
>>
>> qemu-system-sh4 -M r2d -monitor null -serial null -serial stdio
>> -nographic -no-reboot -append "panic=1 HOST=sh4 console=ttySC1 noiotrap"
>> -kernel zImage -initrd sh4-linux-musl-root.cpio.gz
>>
>> You'll need a simple cpio.gz initramfs (I built one using
>> https://github.com/landley/mkroot and the musl-cross-make cross
>> compiler, the cpio.gz is ~450k or I'd attach it here).
>>
>> I bisected it to commit 18e8cf159177 back in February. If you do this
>> with the revision _before_ that commit, typing "ls -l" and hitting enter
>> works fine. Afterwards you get an "l" and then it hangs. (If type enough
>> it'll eventually deal a burst of characters all at once, and then hang
>> again.)
> 
> SH7751R has both SCI and SCIF ports. ttySC1 is the second (SCIF) port.

Yeah, my qemu invocation for sh4 is a bit eldrich, I got it from the
qemu mailing list. Possibly from:

https://lists.nongnu.org/archive/html/qemu-devel/2007-09/msg00530.html

The really _fun_ thing about this is qemu broke it a couple years back
and now if you hit ctrl-c it kills the _emulator_ rather than passing it
through to the Linux console. (Just sh4, the rest do it right.)

I complained about it on the qemu mailing list in 2014 but nobody there
cared:

http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00000.html

Of course that's actually _useful_ for the testing I'm doing now because
when the kernel tries to shut down qemu it goes:

  / # exit
  reboot: Restarting system
  Unauthorized access

And then hangs eating 100% cpu. (Wheee!)

>  registers a port with type PORT_SCIF,
> so that should become SCIx_SH4_SCIF_REGTYPE. Hence I don't think the issue
> is caused by changing fifosize to 64 for SCIx_SH7705_SCIF_REGTYPE.
> 
> My first guess is that qemu has a bug emulating the triggering.

Very likely given how crappy the rest of its serial emulation is for
this architecture, but ever since qemu added glib support I've stopped
trying to understand their developers' thought processes.

> According to the SH7751R datasheet, SCFCR does have the RTRG1 and RTRG0 bits.
> I assume the problem goes away if you comment out the call to scif_set_rtrg()?

The current code has been further complicated by two more commits
(039403765 and 90afa5255) doing who knows what, but deleting the
"scif_set_rtrg(port, s->rx_trigger);" from sci_reset() does appear to
fix the problem.

Rob

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Ulrich Hecht]

On Sat, Apr 22, 2017 at 10:49 AM, Rob Landley <rob@landley.net> wrote:
>
>
> On 04/21/2017 02:26 AM, Geert Uytterhoeven wrote:
>> According to the SH7751R datasheet, SCFCR does have the RTRG1 and RTRG0 bits.
>> I assume the problem goes away if you comment out the call to scif_set_rtrg()?
>
> The current code has been further complicated by two more commits
> (039403765 and 90afa5255) doing who knows what, but deleting the
> "scif_set_rtrg(port, s->rx_trigger);" from sci_reset() does appear to
> fix the problem.

Most(?) SCIFs have a feature that is always enabled and that asserts
DR even if the FIFO threshold has not been reached if no data is
received for 1.5 frames. Exceptions known to me are SCIFA/Bs, which
require special handling for it to work, and SH7705's SCIF, which does
not seem to have this at all. According to its datasheet, the
SH7751R's SCIF has the timeout feature, so I would have expected it to
work...

CU
Uli

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Ulrich Hecht]

On Sat, Apr 22, 2017 at 10:49 AM, Rob Landley <rob@landley.net> wrote:
>
>
> On 04/21/2017 02:26 AM, Geert Uytterhoeven wrote:
>> According to the SH7751R datasheet, SCFCR does have the RTRG1 and RTRG0 bits.
>> I assume the problem goes away if you comment out the call to scif_set_rtrg()?
>
> The current code has been further complicated by two more commits
> (039403765 and 90afa5255) doing who knows what, but deleting the
> "scif_set_rtrg(port, s->rx_trigger);" from sci_reset() does appear to
> fix the problem.

Most(?) SCIFs have a feature that is always enabled and that asserts
DR even if the FIFO threshold has not been reached if no data is
received for 1.5 frames. Exceptions known to me are SCIFA/Bs, which
require special handling for it to work, and SH7705's SCIF, which does
not seem to have this at all. According to its datasheet, the
SH7751R's SCIF has the timeout feature, so I would have expected it to
work...

CU
Uli

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Rob Landley]

On 04/24/2017 02:23 AM, Ulrich Hecht wrote:
> On Sat, Apr 22, 2017 at 10:49 AM, Rob Landley <rob@landley.net> wrote:
>> On 04/21/2017 02:26 AM, Geert Uytterhoeven wrote:
>>> According to the SH7751R datasheet, SCFCR does have the RTRG1 and RTRG0 bits.
>>> I assume the problem goes away if you comment out the call to scif_set_rtrg()?
>>
>> The current code has been further complicated by two more commits
>> (039403765 and 90afa5255) doing who knows what, but deleting the
>> "scif_set_rtrg(port, s->rx_trigger);" from sci_reset() does appear to
>> fix the problem.
> 
> Most(?) SCIFs have a feature that is always enabled and that asserts
> DR even if the FIFO threshold has not been reached if no data is
> received for 1.5 frames. Exceptions known to me are SCIFA/Bs, which
> require special handling for it to work, and SH7705's SCIF, which does
> not seem to have this at all. According to its datasheet, the
> SH7751R's SCIF has the timeout feature, so I would have expected it to
> work...

QEMU is an emulator. I've run sh4 linux on it for about 10 years now.
Sounds like they never implemented this feature because nothing used it
before now.

My general approach when dealing with this sort of thing is to point
figures at the thing that changed, and caused "it was working" to go to
"it's not working". When qemu broke this same sh4 serial port, I asked
_them_ to fix it:

https://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg03929.html

Asking qemu to change means current kernels will never run on existing
qemu installations again, when they did for a decade now, which seems
like a regression to me?

Rob

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Rob Landley]

On 04/24/2017 02:23 AM, Ulrich Hecht wrote:
> On Sat, Apr 22, 2017 at 10:49 AM, Rob Landley <rob@landley.net> wrote:
>> On 04/21/2017 02:26 AM, Geert Uytterhoeven wrote:
>>> According to the SH7751R datasheet, SCFCR does have the RTRG1 and RTRG0 bits.
>>> I assume the problem goes away if you comment out the call to scif_set_rtrg()?
>>
>> The current code has been further complicated by two more commits
>> (039403765 and 90afa5255) doing who knows what, but deleting the
>> "scif_set_rtrg(port, s->rx_trigger);" from sci_reset() does appear to
>> fix the problem.
> 
> Most(?) SCIFs have a feature that is always enabled and that asserts
> DR even if the FIFO threshold has not been reached if no data is
> received for 1.5 frames. Exceptions known to me are SCIFA/Bs, which
> require special handling for it to work, and SH7705's SCIF, which does
> not seem to have this at all. According to its datasheet, the
> SH7751R's SCIF has the timeout feature, so I would have expected it to
> work...

QEMU is an emulator. I've run sh4 linux on it for about 10 years now.
Sounds like they never implemented this feature because nothing used it
before now.

My general approach when dealing with this sort of thing is to point
figures at the thing that changed, and caused "it was working" to go to
"it's not working". When qemu broke this same sh4 serial port, I asked
_them_ to fix it:

https://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg03929.html

Asking qemu to change means current kernels will never run on existing
qemu installations again, when they did for a decade now, which seems
like a regression to me?

Rob

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Rich Felker]

On Fri, Apr 21, 2017 at 09:50:39AM +0200, John Paul Adrian Glaubitz wrote:
> On 04/21/2017 09:26 AM, Geert Uytterhoeven wrote:
> > Does anyone have access to real hardware to try?
> > Adrian: does it work on your LANDISK, which also has SH7751R?
> 
> I can give it a try but that will take a few days since I am currently
> not at home where my LANDISK boxes are. I also had issues with the
> IDE driver in the past but Sato-san gave me some tips regarding it.
> 
> However, Rich also has a LANDISK device that I donated for him, so if his
> hardware is currently ready to use, he could give it a try.

Presently my LANDISK is in storage along with lots of other stuff due
to fire, but as far as I know it was not damaged. However I never got
directions for how to install a new kernel and point the bootloader at
it. It'll probably be another couple months before I get to moving
back in and unpacking everything from storage, but if you or anyone
else can get me the info between now and then on how to install new
kernel rather than just dd'ing a whole disk image, I'll follow up as
soon as I can.

Rich

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Rich Felker]

On Fri, Apr 21, 2017 at 09:50:39AM +0200, John Paul Adrian Glaubitz wrote:
> On 04/21/2017 09:26 AM, Geert Uytterhoeven wrote:
> > Does anyone have access to real hardware to try?
> > Adrian: does it work on your LANDISK, which also has SH7751R?
> 
> I can give it a try but that will take a few days since I am currently
> not at home where my LANDISK boxes are. I also had issues with the
> IDE driver in the past but Sato-san gave me some tips regarding it.
> 
> However, Rich also has a LANDISK device that I donated for him, so if his
> hardware is currently ready to use, he could give it a try.

Presently my LANDISK is in storage along with lots of other stuff due
to fire, but as far as I know it was not damaged. However I never got
directions for how to install a new kernel and point the bootloader at
it. It'll probably be another couple months before I get to moving
back in and unpacking everything from storage, but if you or anyone
else can get me the info between now and then on how to install new
kernel rather than just dd'ing a whole disk image, I'll follow up as
soon as I can.

Rich

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Geert Uytterhoeven]

On Fri, Apr 21, 2017 at 8:21 AM Rob Landley <rob@landley.net> wrote:
> In 4.11-rc7 the qemu serial console hangs after the first character you
> type. To reproduce, configure linux with this mini.config:
>
> CONFIG_CPU_SUBTYPE_SH7751R=y
> CONFIG_MMU=y
> CONFIG_MEMORY_START=0x0c000000
> CONFIG_VSYSCALL=y
> CONFIG_SH_FPU=y
> CONFIG_SH_RTS7751R2D=y
> CONFIG_RTS7751R2D_PLUS=y
> CONFIG_SERIAL_SH_SCI=y
> CONFIG_SERIAL_SH_SCI_CONSOLE=y
> CONFIG_EARLY_PRINTK=y
> CONFIG_BLK_DEV_INITRD=y"
> CONFIG_RD_GZIP=y
> CONFIG_BINFMT_ELF=y
> CONFIG_BINFMT_SCRIPT=y
> CONFIG_MISC_FILESYSTEMS=y
> CONFIG_DEVTMPFS=y
>
> Using "make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=mini.conf", then build
> the result, then boot under qemu using the following command line:
>
> qemu-system-sh4 -M r2d -monitor null -serial null -serial stdio
> -nographic -no-reboot -append "panic=1 HOST=sh4 console=ttySC1 noiotrap"
> -kernel zImage -initrd sh4-linux-musl-root.cpio.gz
>
> You'll need a simple cpio.gz initramfs (I built one using
> https://github.com/landley/mkroot and the musl-cross-make cross
> compiler, the cpio.gz is ~450k or I'd attach it here).
>
> I bisected it to commit 18e8cf159177 back in February. If you do this
> with the revision _before_ that commit, typing "ls -l" and hitting enter
> works fine. Afterwards you get an "l" and then it hangs. (If type enough
> it'll eventually deal a burst of characters all at once, and then hang
> again.)

FTR, patch for qemu is "hw/char/sh_serial: Add timeout handling to unbreak
serial input"
(http://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg05579.html)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds