QEMU serial still broken in -rc1.

QEMU serial still broken in -rc1.

[Rob Landley]

I refer to the previous thread, which is still the case:

http://www.spinics.net/lists/linux-sh/msg51190.html

I poked at QEMU's internals to see if there was an easy way to fiddle
with stuff, but A) ttySC1 appears to be the only serial type the board
emulates, B) the ttySC0 instance is broken, dunno why.

More context from years in the QEMU mines:

http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00825.html

http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00976.html

http://lists.gnu.org/archive/html/qemu-devel/2014-09/msg00207.html

As you can see from the fact the 2014 bug is still there in qemu, asking
QEMU to fix anything is basically shouting into a hole. (Although if
other people want to add their voices maybe it'll work better.)

Rob

Re: QEMU serial still broken in -rc1.

[John Paul Adrian Glaubitz]

On 05/15/2017 04:46 AM, Rob Landley wrote:
> As you can see from the fact the 2014 bug is still there in qemu, asking
> QEMU to fix anything is basically shouting into a hole. (Although if
> other people want to add their voices maybe it'll work better.)

Did you actually file a bug report in the QEMU tracker? I don't quite have
this experience with QEMU. They do fix bugs but they often take some time
to work through the patch queue because they usually get a larger number
of patches [1].

Adrian

> [1] https://patchwork.ozlabs.org/project/qemu-devel/list/

-- 
 .''`.  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: QEMU serial still broken in -rc1.

[John Paul Adrian Glaubitz]

On 05/15/2017 07:11 AM, John Paul Adrian Glaubitz wrote:
> They do fix bugs but they often take some time to work through the
> patch queue because they usually get a larger number of patches [1].

Oh, and Aurelien Jarno has pushed a larger number of SH-related fixes [1].

Adrian

> [1] https://patchwork.ozlabs.org/patch/761962/

-- 
 .''`.  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: QEMU serial still broken in -rc1.

[Rob Landley]

On 05/15/2017 12:11 AM, John Paul Adrian Glaubitz wrote:
> On 05/15/2017 04:46 AM, Rob Landley wrote:
>> As you can see from the fact the 2014 bug is still there in qemu, asking
>> QEMU to fix anything is basically shouting into a hole. (Although if
>> other people want to add their voices maybe it'll work better.)
> 
> Did you actually file a bug report in the QEMU tracker?

Nope. I re-email about stuff every few years though.

https://lists.nongnu.org/archive/html/qemu-devel/2007-10/msg00245.html
http://lists.nongnu.org/archive/html/qemu-devel/2009-09/msg01327.html
https://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg02361.html
https://lists.nongnu.org/archive/html/qemu-devel/2012-04/msg03091.html
http://lists.landley.net/pipermail/aboriginal-landley.net/2015-December/001580.html

My rule of thumb is if it requires me to log in with an account, it's
not open source. *shrug* YMMV and I admit mailing lists you have to
subscribe to are an edge case. But they never ask me to remember yet
another password 6 months later.

(I'm currently waiting for the next Android NDK release version to see
if _that_ builds toybox because when I asked about nightly builds
http://lists.landley.net/pipermail/toybox-landley.net/2017-May/008976.html
led to
https://android.googlesource.com/platform/ndk/+/master/docs/ContinuousBuilds.md
which led to http://partner.android.com/build which is a login screen,
and I stopped there. It's not so much a principle as a "life's too
short, my todo list is too long" thing...)

Rob

Re: QEMU serial still broken in -rc1.

[Rob Landley]

On 05/15/2017 12:13 AM, John Paul Adrian Glaubitz wrote:
> On 05/15/2017 07:11 AM, John Paul Adrian Glaubitz wrote:
>> They do fix bugs but they often take some time to work through the
>> patch queue because they usually get a larger number of patches [1].
> 
> Oh, and Aurelien Jarno has pushed a larger number of SH-related fixes [1].
> 
> Adrian
> 
>> [1] https://patchwork.ozlabs.org/patch/761962/

Hmmm, I should poke him about attempting to get j-core SOC support and
sh2 cpu emulation working. And the whole "qemu-system-sh4" naming when
there's sh2 and sh3... (Also, why does QEMU _not_ support the -kernel
vmlinux ELF loader on all boards? In theory that's reasonably generic...)

Rob

Re: QEMU serial still broken in -rc1.

[Rob Landley]

On 05/15/2017 12:13 AM, John Paul Adrian Glaubitz wrote:
> On 05/15/2017 07:11 AM, John Paul Adrian Glaubitz wrote:
>> They do fix bugs but they often take some time to work through the
>> patch queue because they usually get a larger number of patches [1].
> 
> Oh, and Aurelien Jarno has pushed a larger number of SH-related fixes [1].

My attempts to re-test hit:

cd ~/qemu/qemu && git clean -fdx && git checkout -f && git pull &&
./configure && make
...
  CC      hw/core/loader-fit.o
hw/core/loader-fit.c: In function ‘fit_image_addr’:
hw/core/loader-fit.c:105:32: error: ‘fdt32_t’ undeclared (first use in
this function)
         *addr = fdt32_to_cpu(*(fdt32_t *)prop);

I'll let you know if it fixes anything when the tree starts building again.

Thanks,

Rob

Re: QEMU serial still broken in -rc1.

[John Paul Adrian Glaubitz]

Hi Rob!

On Sun, May 14, 2017 at 09:46:07PM -0500, Rob Landley wrote:
> I refer to the previous thread, which is still the case:
> 
> http://www.spinics.net/lists/linux-sh/msg51190.html
> 
> I poked at QEMU's internals to see if there was an easy way to fiddle
> with stuff, but A) ttySC1 appears to be the only serial type the board
> emulates, B) the ttySC0 instance is broken, dunno why.

I gave it a try myself now and I can't get the emulated machine to
boot or show any output over the serial console.

It hangs here:

root@nofan:~/sh4-system> qemu-system-sh4 -M r2d -m 1000M -drive file=sh4-system.img,format=qcow2 -nographic -append "root=/dev/sda1 rw console=ttySC0 earlyprintk=sh-sci.1" -kernel vmlinux-3.18.0-trunk-sh7751r 
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

Any ideas?

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: QEMU serial still broken in -rc1.

[John Paul Adrian Glaubitz]

On Wed, Jun 14, 2017 at 03:48:21PM +0200, John Paul Adrian Glaubitz wrote:
> It hangs here:
> 
> root@nofan:~/sh4-system> qemu-system-sh4 -M r2d -m 1000M -drive file=sh4-system.img,format=qcow2 -nographic -append "root=/dev/sda1 rw console=ttySC0 earlyprintk=sh-sci.1" -kernel vmlinux-3.18.0-trunk-sh7751r 
> 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

Correction: Framebuffer console works. Just the serial one doesn't.

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: QEMU serial still broken in -rc1.

[Rob Landley]

On 06/14/2017 08:48 AM, John Paul Adrian Glaubitz wrote:
> Hi Rob!
> 
> On Sun, May 14, 2017 at 09:46:07PM -0500, Rob Landley wrote:
>> I refer to the previous thread, which is still the case:
>>
>> http://www.spinics.net/lists/linux-sh/msg51190.html
>>
>> I poked at QEMU's internals to see if there was an easy way to fiddle
>> with stuff, but A) ttySC1 appears to be the only serial type the board
>> emulates, B) the ttySC0 instance is broken, dunno why.
> 
> I gave it a try myself now and I can't get the emulated machine to
> boot or show any output over the serial console.
> 
> It hangs here:
> 
> root@nofan:~/sh4-system> qemu-system-sh4 -M r2d -m 1000M -drive file=sh4-system.img,format=qcow2 -nographic -append "root=/dev/sda1 rw console=ttySC0 earlyprintk=sh-sci.1" -kernel vmlinux-3.18.0-trunk-sh7751r 
> 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
> 
> Any ideas?

By default qemu-system-sh4 outputs to the broken first serial port
(which Linux apparently has no driver for) instead of the second serial
port that Linux does have a driver for. I have no idea why it does that,
but you have to add extra command line options to work around it:

http://wiki.qemu.org/Documentation/Platforms/SH4

In my build, that's this line:

https://github.com/landley/mkroot/blob/master/module/kernel#L263

Rob

Re: QEMU serial still broken in -rc1.

[Geert Uytterhoeven]

Hi Rob,

On Thu, Jun 15, 2017 at 3:07 AM, Rob Landley <rob@landley.net> wrote:
> On 06/14/2017 08:48 AM, John Paul Adrian Glaubitz wrote:
>> On Sun, May 14, 2017 at 09:46:07PM -0500, Rob Landley wrote:
>>> I refer to the previous thread, which is still the case:
>>>
>>> http://www.spinics.net/lists/linux-sh/msg51190.html
>>>
>>> I poked at QEMU's internals to see if there was an easy way to fiddle
>>> with stuff, but A) ttySC1 appears to be the only serial type the board
>>> emulates, B) the ttySC0 instance is broken, dunno why.
>>
>> I gave it a try myself now and I can't get the emulated machine to
>> boot or show any output over the serial console.
>>
>> It hangs here:
>>
>> root@nofan:~/sh4-system> qemu-system-sh4 -M r2d -m 1000M -drive file=sh4-system.img,format=qcow2 -nographic -append "root=/dev/sda1 rw console=ttySC0 earlyprintk=sh-sci.1" -kernel vmlinux-3.18.0-trunk-sh7751r
>> 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
>>
>> Any ideas?
>
> By default qemu-system-sh4 outputs to the broken first serial port
> (which Linux apparently has no driver for) instead of the second serial
> port that Linux does have a driver for. I have no idea why it does that,
> but you have to add extra command line options to work around it:

The first serial port is a SCI, which should be supported by the sh-sci
driver, too.

Perhaps the issue is that using the first port as a serial console depends
on the bootloader initializing it?
Does it work as a normal serial port from userspace?

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: QEMU serial still broken in -rc1.

[Rob Landley]

On 06/15/2017 01:26 AM, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Thu, Jun 15, 2017 at 3:07 AM, Rob Landley <rob@landley.net> wrote:
>> On 06/14/2017 08:48 AM, John Paul Adrian Glaubitz wrote:
>>> On Sun, May 14, 2017 at 09:46:07PM -0500, Rob Landley wrote:
>>>> I refer to the previous thread, which is still the case:
>>>>
>>>> http://www.spinics.net/lists/linux-sh/msg51190.html
>>>>
>>>> I poked at QEMU's internals to see if there was an easy way to fiddle
>>>> with stuff, but A) ttySC1 appears to be the only serial type the board
>>>> emulates, B) the ttySC0 instance is broken, dunno why.
>>>
>>> I gave it a try myself now and I can't get the emulated machine to
>>> boot or show any output over the serial console.
>>>
>>> It hangs here:
>>>
>>> root@nofan:~/sh4-system> qemu-system-sh4 -M r2d -m 1000M -drive file=sh4-system.img,format=qcow2 -nographic -append "root=/dev/sda1 rw console=ttySC0 earlyprintk=sh-sci.1" -kernel vmlinux-3.18.0-trunk-sh7751r
>>> 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
>>>
>>> Any ideas?
>>
>> By default qemu-system-sh4 outputs to the broken first serial port
>> (which Linux apparently has no driver for) instead of the second serial
>> port that Linux does have a driver for. I have no idea why it does that,
>> but you have to add extra command line options to work around it:
> 
> The first serial port is a SCI, which should be supported by the sh-sci
> driver, too.
> 
> Perhaps the issue is that using the first port as a serial console depends
> on the bootloader initializing it?
> Does it work as a normal serial port from userspace?

I've never gotten any output from it (despite trying every couple years
since
https://lists.nongnu.org/archive/html/qemu-devel/2009-02/msg00825.html
). The most recent interaction I had with them was
https://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg04425.html
where they doubled down on it.

The very first submission of qemu-system-sh4 said "Use these options to
get the serial ports right":

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

Here's one of my periodic attempts at trying the other one:

http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00976.html
http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01005.html

If you can get it to work, I'd love to drop that strangeness. It's never
worked with Linux in the history of qemu, that I'm aware of.

The relevant serial init plumbing in qemu/hw/sh4/sh7750.c is:

    sh_serial_init(sysmem, 0x1fe00000,
                   0, s->periph_freq, serial_hds[0],
                   s->intc.irqs[SCI1_ERI],
                   s->intc.irqs[SCI1_RXI],
                   s->intc.irqs[SCI1_TXI],
                   s->intc.irqs[SCI1_TEI],
                   NULL);
    sh_serial_init(sysmem, 0x1fe80000,
                   SH_SERIAL_FEAT_SCIF,
                   s->periph_freq, serial_hds[1],
                   s->intc.irqs[SCIF_ERI],
                   s->intc.irqs[SCIF_RXI],
                   s->intc.irqs[SCIF_TXI],
                   NULL,
                   s->intc.irqs[SCIF_BRI]);

Although there's also this bit in r2d.c:

    qdev_prop_set_ptr(dev, "chr-state", serial_hds[2]);

Which is just confusing because I didn't think there was a third serial
port? (MAX_SERIAL_PORTS is 4 in include/sysemu/sysemu.h so it's not
overflowing anything, it's just... weird. I found much of the qemu code
impenetrable even before they decided libglib was a good idea...)

At the moment what I'd _really_ like is for -M virt to work on the sh
arch instead of being arm-only. But I haven't even figured out how to
get the Linux kernel ELF loader to apply generically. (Half the
architectures can boot from vmlinux. The other half can't. There is no
obvious reason for this, but after about 6 hours down the rathole of
trying to make it work, it went back on the todo list. Let's see, that
would have been back around
https://lists.nongnu.org/archive/html/qemu-devel/2011-05/msg00678.html)

Rob