[Qemu-devel] qemu-system-sh4 vs qemu-system-arm/i386 default behavior

[Qemu-devel] qemu-system-sh4 vs qemu-system-arm/i386 default behavior

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Hey all,

I'm trying to make use of the r2d platform for U-Boot testing via QEMU.
After applying a series[1] I can use the kernel.org sh4 toolchain to get
a u-boot.bin that runs, mostly.  I say mostly as first of all I have to
pass "-monitor null -serial null -serial stdio -nographic" to
qemu-system-sh4 and in that order for me to get output from U-Boot on
the prompt.  On other platforms such as arm and vexpress or i386 and the
'pc' machine I do not need to do this.  Does anyone have any idea why
this might be and where to start poking in the code to fix this?  I see
this on v2.8.0-rc1 along with various older releases, thanks!

[1]: https://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/
-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] qemu-system-sh4 vs qemu-system-arm/i386 default behavior

[Thomas Huth]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

On 30.11.2016 02:01, Tom Rini wrote:
> Hey all,
> 
> I'm trying to make use of the r2d platform for U-Boot testing via QEMU.
> After applying a series[1] I can use the kernel.org sh4 toolchain to get
> a u-boot.bin that runs, mostly.  I say mostly as first of all I have to
> pass "-monitor null -serial null -serial stdio -nographic" to
> qemu-system-sh4 and in that order for me to get output from U-Boot on
> the prompt.  On other platforms such as arm and vexpress or i386 and the
> 'pc' machine I do not need to do this.  Does anyone have any idea why
> this might be and where to start poking in the code to fix this?

The "-serial" parameter is related to the serial_hds[] array in the
code, so you could search for that one.

The following line in hw/sh4/r2d.c looks somewhat suspicious:

    sm501_init(address_space_mem, 0x10000000, SM501_VRAM_SIZE,
               irq[SM501], serial_hds[2]);

Why is this machine always using serial_hds[2] and not a lower index?
... Maybe the maintainer of the board (Magnus) knows the answer here...

 Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Qemu-devel] qemu-system-sh4 vs qemu-system-arm/i386 default behavior

[Aurelien Jarno]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

On 2016-11-30 08:33, Thomas Huth wrote:
> On 30.11.2016 02:01, Tom Rini wrote:
> > Hey all,
> > 
> > I'm trying to make use of the r2d platform for U-Boot testing via QEMU.
> > After applying a series[1] I can use the kernel.org sh4 toolchain to get
> > a u-boot.bin that runs, mostly.  I say mostly as first of all I have to
> > pass "-monitor null -serial null -serial stdio -nographic" to
> > qemu-system-sh4 and in that order for me to get output from U-Boot on
> > the prompt.  On other platforms such as arm and vexpress or i386 and the
> > 'pc' machine I do not need to do this.  Does anyone have any idea why
> > this might be and where to start poking in the code to fix this?

The reason is that u-boot and the linux kernel do not have the same way
to number the serial port than the physical hardware. Therefore u-boot
and the Linux kernel use the second physical serial port .The question is
whether we should number our ports from the software (or part of the
sofrware) or hardware point of view.

> The "-serial" parameter is related to the serial_hds[] array in the
> code, so you could search for that one.
> 
> The following line in hw/sh4/r2d.c looks somewhat suspicious:
> 
>     sm501_init(address_space_mem, 0x10000000, SM501_VRAM_SIZE,
>                irq[SM501], serial_hds[2]);
> 
> Why is this machine always using serial_hds[2] and not a lower index?
> ... Maybe the maintainer of the board (Magnus) knows the answer here...

The third serial port is provided by the graphic chipset. The first two
serial ports are provided by the SH7750 CPU, see in hw/sh4/sh7750.c.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] qemu-system-sh4 vs qemu-system-arm/i386 default behavior

[Thomas Huth]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

On 30.11.2016 09:02, Aurelien Jarno wrote:
> On 2016-11-30 08:33, Thomas Huth wrote:
>> On 30.11.2016 02:01, Tom Rini wrote:
>>> Hey all,
>>>
>>> I'm trying to make use of the r2d platform for U-Boot testing via QEMU.
>>> After applying a series[1] I can use the kernel.org sh4 toolchain to get
>>> a u-boot.bin that runs, mostly.  I say mostly as first of all I have to
>>> pass "-monitor null -serial null -serial stdio -nographic" to
>>> qemu-system-sh4 and in that order for me to get output from U-Boot on
>>> the prompt.  On other platforms such as arm and vexpress or i386 and the
>>> 'pc' machine I do not need to do this.  Does anyone have any idea why
>>> this might be and where to start poking in the code to fix this?
> 
> The reason is that u-boot and the linux kernel do not have the same way
> to number the serial port than the physical hardware. Therefore u-boot
> and the Linux kernel use the second physical serial port .The question is
> whether we should number our ports from the software (or part of the
> sofrware) or hardware point of view.

OK, thanks for the explanation, that makes sense now. ... maybe we
should put this information on a SH4 machine page under
http://qemu-project.org/Documentation/Platforms so that users have a
possibility to understand this serial port numbering?

 Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Qemu-devel] qemu-system-sh4 vs qemu-system-arm/i386 default behavior

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

On Wed, Nov 30, 2016 at 10:12:09AM +0100, Thomas Huth wrote:
> On 30.11.2016 09:02, Aurelien Jarno wrote:
> > On 2016-11-30 08:33, Thomas Huth wrote:
> >> On 30.11.2016 02:01, Tom Rini wrote:
> >>> Hey all,
> >>>
> >>> I'm trying to make use of the r2d platform for U-Boot testing via QEMU.
> >>> After applying a series[1] I can use the kernel.org sh4 toolchain to get
> >>> a u-boot.bin that runs, mostly.  I say mostly as first of all I have to
> >>> pass "-monitor null -serial null -serial stdio -nographic" to
> >>> qemu-system-sh4 and in that order for me to get output from U-Boot on
> >>> the prompt.  On other platforms such as arm and vexpress or i386 and the
> >>> 'pc' machine I do not need to do this.  Does anyone have any idea why
> >>> this might be and where to start poking in the code to fix this?
> > 
> > The reason is that u-boot and the linux kernel do not have the same way
> > to number the serial port than the physical hardware. Therefore u-boot
> > and the Linux kernel use the second physical serial port .The question is
> > whether we should number our ports from the software (or part of the
> > sofrware) or hardware point of view.
> 
> OK, thanks for the explanation, that makes sense now. ... maybe we
> should put this information on a SH4 machine page under
> http://qemu-project.org/Documentation/Platforms so that users have a
> possibility to understand this serial port numbering?

I'm still a bit confused, sorry.  Digging around a bit I guess what is
happening is that serial_hds[0] is being used, but Linux and U-Boot
expect to use serial_hds[1] and that's what the above combination of
arguments is getting me?  How would I go about saying in a more simple
form perhaps, to use the second described port not the first described
port?  Thanks!

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]