* [U-Boot] qemu and u-boot-console and other ports?
@ 2016-12-02 14:40 Tom Rini
2016-12-02 18:03 ` Stephen Warren
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2016-12-02 14:40 UTC (permalink / raw)
To: u-boot
Hey,
I'm trying to debug adding sh4 and r2dplus support to test.py. Until my
current round of testing is applied you'll need
http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
for us to get a functional U-Boot. After that, I have a "normal" conf
file for the board for QEMU that looks like:
console_impl=qemu
qemu_machine="r2d"
qemu_binary="qemu-system-sh4"
qemu_extra_args="-nographic -serial null -serial mon:stdio"
qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
reset_impl=none
flash_impl=none
And here's where things get funny. When I kick off test.py with --bd
r2dplus --id qemu --build -s -k sleep it will build and launch the board
and since I have -s I can see stdio and I see U-Boot come up and give me
the prompt, and then test.py says it times out waiting for the prompt.
Any ideas where to poke next? I want to say something is funny with
respect to what we see and where we see it (in terms of pipes) due to
having to say -serial null -serial mon:stdio so that we see port #2 on
the "board" rather than port #1 as this is the port that U-Boot and
Linux use by default. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161202/6e5db49f/attachment.sig>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] qemu and u-boot-console and other ports?
2016-12-02 14:40 [U-Boot] qemu and u-boot-console and other ports? Tom Rini
@ 2016-12-02 18:03 ` Stephen Warren
2016-12-02 19:18 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Warren @ 2016-12-02 18:03 UTC (permalink / raw)
To: u-boot
On 12/02/2016 07:40 AM, Tom Rini wrote:
> Hey,
>
> I'm trying to debug adding sh4 and r2dplus support to test.py. Until my
> current round of testing is applied you'll need
> http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
> for us to get a functional U-Boot. After that, I have a "normal" conf
> file for the board for QEMU that looks like:
> console_impl=qemu
> qemu_machine="r2d"
> qemu_binary="qemu-system-sh4"
> qemu_extra_args="-nographic -serial null -serial mon:stdio"
> qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
> reset_impl=none
> flash_impl=none
>
> And here's where things get funny. When I kick off test.py with --bd
> r2dplus --id qemu --build -s -k sleep it will build and launch the board
> and since I have -s I can see stdio and I see U-Boot come up and give me
> the prompt, and then test.py says it times out waiting for the prompt.
> Any ideas where to poke next? I want to say something is funny with
> respect to what we see and where we see it (in terms of pipes) due to
> having to say -serial null -serial mon:stdio so that we see port #2 on
> the "board" rather than port #1 as this is the port that U-Boot and
> Linux use by default. Thanks!
Does "-serial null -serial mon:stdio" cause qemu to re-open file
descriptors rather than just using stdout directly, or something like
that? If so, perhaps its output is getting into the overall script's
stdout (e.g. your terminal/console?) rather than the pipe that test/py
is reading. If so, you'd see the qemu output but test/py wouldn't.
I think you can test this assumption by removing the -s option. If you
still see qemu output, then qemu is sending it directly to wherever the
overall stdout is going. If you no longer see qemu's output, then
test/py must be reading it and only echo'ing it due to the -s option,
and so you'd have to look somewhere else.
Is test/py waiting for the exact prompt that U-Boot is actually emitting?
In the past I've debugged such things by editing test/py/u_boot_spawn.py
expect() to print some debug spew; I made it dump the current unmatched
buffer content and the strings/regexes it was waiting for.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] qemu and u-boot-console and other ports?
2016-12-02 18:03 ` Stephen Warren
@ 2016-12-02 19:18 ` Tom Rini
2016-12-02 19:21 ` Stephen Warren
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2016-12-02 19:18 UTC (permalink / raw)
To: u-boot
On Fri, Dec 02, 2016 at 11:03:00AM -0700, Stephen Warren wrote:
> On 12/02/2016 07:40 AM, Tom Rini wrote:
> >Hey,
> >
> >I'm trying to debug adding sh4 and r2dplus support to test.py. Until my
> >current round of testing is applied you'll need
> >http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
> >for us to get a functional U-Boot. After that, I have a "normal" conf
> >file for the board for QEMU that looks like:
> >console_impl=qemu
> >qemu_machine="r2d"
> >qemu_binary="qemu-system-sh4"
> >qemu_extra_args="-nographic -serial null -serial mon:stdio"
> >qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
> >reset_impl=none
> >flash_impl=none
> >
> >And here's where things get funny. When I kick off test.py with --bd
> >r2dplus --id qemu --build -s -k sleep it will build and launch the board
> >and since I have -s I can see stdio and I see U-Boot come up and give me
> >the prompt, and then test.py says it times out waiting for the prompt.
> >Any ideas where to poke next? I want to say something is funny with
> >respect to what we see and where we see it (in terms of pipes) due to
> >having to say -serial null -serial mon:stdio so that we see port #2 on
> >the "board" rather than port #1 as this is the port that U-Boot and
> >Linux use by default. Thanks!
>
> Does "-serial null -serial mon:stdio" cause qemu to re-open file
> descriptors rather than just using stdout directly, or something
> like that? If so, perhaps its output is getting into the overall
> script's stdout (e.g. your terminal/console?) rather than the pipe
> that test/py is reading. If so, you'd see the qemu output but
> test/py wouldn't.
>
> I think you can test this assumption by removing the -s option. If
> you still see qemu output, then qemu is sending it directly to
> wherever the overall stdout is going. If you no longer see qemu's
> output, then test/py must be reading it and only echo'ing it due to
> the -s option, and so you'd have to look somewhere else.
When I drop out -s instead I get:
----------------------------------- Captured stdout ------------------------------------
+u-boot-test-reset r2dplus qemu
long write to SH7750_WCR1_A7 (0x000000001f800008) ignored
long write to SH7750_WCR2_A7 (0x000000001f80000c) ignored
long write to SH7750_WCR3_A7 (0x000000001f800010) ignored
long write to SH7750_MCR_A7 (0x000000001f800014) ignored
word write to SH7750_RTCNT_A7 (0x000000001f800020) ignored
word write to SH7750_RTCOR_A7 (0x000000001f800024) ignored
Write access to refresh count register
word write to SH7750_RTCSR_A7 (0x000000001f80001c) ignored
Read access to refresh count register, incrementing
long write to SH7750_MCR_A7 (0x000000001f800014) ignored
U-Boot 2016.11-00492-ged6a1e9bbf0c (Dec 02 2016 - 14:14:17 -0500)
CPU: SH4
BOARD: Renesas Solutions R2D Plus
DRAM: 64 MiB
Flash: ERROR: too many flash sectors
8 MiB
*** Warning - bad CRC, using default environment
PCI: SH7751 PCI host bridge found.
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
PCI: Bus Dev VenId DevId Class Int
PCI:
00:00.0 - 1054:350e - Bridge device
00:02.0 - 10ec:8139 - Network controller
In: serial
Out: serial
Err: serial
Net: RTL8139#0
Error: RTL8139#0 address not set.
IDE: Bus 0: not available
=> => s
=========================== 92 tests deselected by '-ksleep' ===========================
======================= 1 failed, 92 deselected in 31.20 seconds =======================
So it's seeing output, but for some reason not matching on it?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161202/4b26c2f8/attachment.sig>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] qemu and u-boot-console and other ports?
2016-12-02 19:18 ` Tom Rini
@ 2016-12-02 19:21 ` Stephen Warren
2016-12-02 20:01 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Warren @ 2016-12-02 19:21 UTC (permalink / raw)
To: u-boot
On 12/02/2016 12:18 PM, Tom Rini wrote:
> On Fri, Dec 02, 2016 at 11:03:00AM -0700, Stephen Warren wrote:
>> On 12/02/2016 07:40 AM, Tom Rini wrote:
>>> Hey,
>>>
>>> I'm trying to debug adding sh4 and r2dplus support to test.py. Until my
>>> current round of testing is applied you'll need
>>> http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
>>> for us to get a functional U-Boot. After that, I have a "normal" conf
>>> file for the board for QEMU that looks like:
>>> console_impl=qemu
>>> qemu_machine="r2d"
>>> qemu_binary="qemu-system-sh4"
>>> qemu_extra_args="-nographic -serial null -serial mon:stdio"
>>> qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
>>> reset_impl=none
>>> flash_impl=none
>>>
>>> And here's where things get funny. When I kick off test.py with --bd
>>> r2dplus --id qemu --build -s -k sleep it will build and launch the board
>>> and since I have -s I can see stdio and I see U-Boot come up and give me
>>> the prompt, and then test.py says it times out waiting for the prompt.
>>> Any ideas where to poke next? I want to say something is funny with
>>> respect to what we see and where we see it (in terms of pipes) due to
>>> having to say -serial null -serial mon:stdio so that we see port #2 on
>>> the "board" rather than port #1 as this is the port that U-Boot and
>>> Linux use by default. Thanks!
>>
>> Does "-serial null -serial mon:stdio" cause qemu to re-open file
>> descriptors rather than just using stdout directly, or something
>> like that? If so, perhaps its output is getting into the overall
>> script's stdout (e.g. your terminal/console?) rather than the pipe
>> that test/py is reading. If so, you'd see the qemu output but
>> test/py wouldn't.
>>
>> I think you can test this assumption by removing the -s option. If
>> you still see qemu output, then qemu is sending it directly to
>> wherever the overall stdout is going. If you no longer see qemu's
>> output, then test/py must be reading it and only echo'ing it due to
>> the -s option, and so you'd have to look somewhere else.
>
> When I drop out -s instead I get:
> ----------------------------------- Captured stdout ------------------------------------
> +u-boot-test-reset r2dplus qemu
> long write to SH7750_WCR1_A7 (0x000000001f800008) ignored
> long write to SH7750_WCR2_A7 (0x000000001f80000c) ignored
> long write to SH7750_WCR3_A7 (0x000000001f800010) ignored
> long write to SH7750_MCR_A7 (0x000000001f800014) ignored
> word write to SH7750_RTCNT_A7 (0x000000001f800020) ignored
> word write to SH7750_RTCOR_A7 (0x000000001f800024) ignored
> Write access to refresh count register
> word write to SH7750_RTCSR_A7 (0x000000001f80001c) ignored
> Read access to refresh count register, incrementing
> long write to SH7750_MCR_A7 (0x000000001f800014) ignored
>
>
> U-Boot 2016.11-00492-ged6a1e9bbf0c (Dec 02 2016 - 14:14:17 -0500)
>
> CPU: SH4
> BOARD: Renesas Solutions R2D Plus
> DRAM: 64 MiB
> Flash: ERROR: too many flash sectors
> 8 MiB
> *** Warning - bad CRC, using default environment
>
> PCI: SH7751 PCI host bridge found.
> 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
> PCI: Bus Dev VenId DevId Class Int
> PCI:
> 00:00.0 - 1054:350e - Bridge device
> 00:02.0 - 10ec:8139 - Network controller
> In: serial
> Out: serial
> Err: serial
> Net: RTL8139#0
> Error: RTL8139#0 address not set.
>
> IDE: Bus 0: not available
> => => s
> =========================== 92 tests deselected by '-ksleep' ===========================
> ======================= 1 failed, 92 deselected in 31.20 seconds =======================
>
> So it's seeing output, but for some reason not matching on it?
If you drop -s, you shouldn't see any of U-Boot's output. It looks like
qemu is writing its serial port output to a file descriptor other than
the stdout that's fed to its parent.
Oh, you can also confirm this by looking in the test-log.html generated
by test/py; that will show you whether test/py sees qemu's output at
all, since all of qemu's output is logged to that file. I guess this
assumes you're running locally, since Travis doesn't save that file for
you to look at. Perhaps you could cat it after running test/py though.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] qemu and u-boot-console and other ports?
2016-12-02 19:21 ` Stephen Warren
@ 2016-12-02 20:01 ` Tom Rini
2016-12-02 21:00 ` Stephen Warren
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2016-12-02 20:01 UTC (permalink / raw)
To: u-boot
On Fri, Dec 02, 2016 at 12:21:43PM -0700, Stephen Warren wrote:
> On 12/02/2016 12:18 PM, Tom Rini wrote:
> >On Fri, Dec 02, 2016 at 11:03:00AM -0700, Stephen Warren wrote:
> >>On 12/02/2016 07:40 AM, Tom Rini wrote:
> >>>Hey,
> >>>
> >>>I'm trying to debug adding sh4 and r2dplus support to test.py. Until my
> >>>current round of testing is applied you'll need
> >>>http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
> >>>for us to get a functional U-Boot. After that, I have a "normal" conf
> >>>file for the board for QEMU that looks like:
> >>>console_impl=qemu
> >>>qemu_machine="r2d"
> >>>qemu_binary="qemu-system-sh4"
> >>>qemu_extra_args="-nographic -serial null -serial mon:stdio"
> >>>qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
> >>>reset_impl=none
> >>>flash_impl=none
> >>>
> >>>And here's where things get funny. When I kick off test.py with --bd
> >>>r2dplus --id qemu --build -s -k sleep it will build and launch the board
> >>>and since I have -s I can see stdio and I see U-Boot come up and give me
> >>>the prompt, and then test.py says it times out waiting for the prompt.
> >>>Any ideas where to poke next? I want to say something is funny with
> >>>respect to what we see and where we see it (in terms of pipes) due to
> >>>having to say -serial null -serial mon:stdio so that we see port #2 on
> >>>the "board" rather than port #1 as this is the port that U-Boot and
> >>>Linux use by default. Thanks!
> >>
> >>Does "-serial null -serial mon:stdio" cause qemu to re-open file
> >>descriptors rather than just using stdout directly, or something
> >>like that? If so, perhaps its output is getting into the overall
> >>script's stdout (e.g. your terminal/console?) rather than the pipe
> >>that test/py is reading. If so, you'd see the qemu output but
> >>test/py wouldn't.
> >>
> >>I think you can test this assumption by removing the -s option. If
> >>you still see qemu output, then qemu is sending it directly to
> >>wherever the overall stdout is going. If you no longer see qemu's
> >>output, then test/py must be reading it and only echo'ing it due to
> >>the -s option, and so you'd have to look somewhere else.
> >
> >When I drop out -s instead I get:
> >----------------------------------- Captured stdout ------------------------------------
> >+u-boot-test-reset r2dplus qemu
> >long write to SH7750_WCR1_A7 (0x000000001f800008) ignored
> >long write to SH7750_WCR2_A7 (0x000000001f80000c) ignored
> >long write to SH7750_WCR3_A7 (0x000000001f800010) ignored
> >long write to SH7750_MCR_A7 (0x000000001f800014) ignored
> >word write to SH7750_RTCNT_A7 (0x000000001f800020) ignored
> >word write to SH7750_RTCOR_A7 (0x000000001f800024) ignored
> >Write access to refresh count register
> >word write to SH7750_RTCSR_A7 (0x000000001f80001c) ignored
> >Read access to refresh count register, incrementing
> >long write to SH7750_MCR_A7 (0x000000001f800014) ignored
> >
> >
> >U-Boot 2016.11-00492-ged6a1e9bbf0c (Dec 02 2016 - 14:14:17 -0500)
> >
> >CPU: SH4
> >BOARD: Renesas Solutions R2D Plus
> >DRAM: 64 MiB
> >Flash: ERROR: too many flash sectors
> >8 MiB
> >*** Warning - bad CRC, using default environment
> >
> >PCI: SH7751 PCI host bridge found.
> >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
> >PCI: Bus Dev VenId DevId Class Int
> >PCI:
> > 00:00.0 - 1054:350e - Bridge device
> > 00:02.0 - 10ec:8139 - Network controller
> >In: serial
> >Out: serial
> >Err: serial
> >Net: RTL8139#0
> >Error: RTL8139#0 address not set.
> >
> >IDE: Bus 0: not available
> >=> => s
> >=========================== 92 tests deselected by '-ksleep' ===========================
> >======================= 1 failed, 92 deselected in 31.20 seconds =======================
> >
> >So it's seeing output, but for some reason not matching on it?
>
> If you drop -s, you shouldn't see any of U-Boot's output. It looks
> like qemu is writing its serial port output to a file descriptor
> other than the stdout that's fed to its parent.
Well, it doesn't give me output until it times out and then dumps that.
> Oh, you can also confirm this by looking in the test-log.html
> generated by test/py; that will show you whether test/py sees qemu's
> output at all, since all of qemu's output is logged to that file. I
> guess this assumes you're running locally, since Travis doesn't save
> that file for you to look at. Perhaps you could cat it after running
> test/py though.
I'm not quite sure what I should (not) be seeing,
http://hastebin.com/upimerumaz.xml is the file. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161202/a7d515e0/attachment.sig>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] qemu and u-boot-console and other ports?
2016-12-02 20:01 ` Tom Rini
@ 2016-12-02 21:00 ` Stephen Warren
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Warren @ 2016-12-02 21:00 UTC (permalink / raw)
To: u-boot
On 12/02/2016 01:01 PM, Tom Rini wrote:
> On Fri, Dec 02, 2016 at 12:21:43PM -0700, Stephen Warren wrote:
>> On 12/02/2016 12:18 PM, Tom Rini wrote:
>>> On Fri, Dec 02, 2016 at 11:03:00AM -0700, Stephen Warren wrote:
>>>> On 12/02/2016 07:40 AM, Tom Rini wrote:
>>>>> Hey,
>>>>>
>>>>> I'm trying to debug adding sh4 and r2dplus support to test.py. Until my
>>>>> current round of testing is applied you'll need
>>>>> http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
>>>>> for us to get a functional U-Boot. After that, I have a "normal" conf
>>>>> file for the board for QEMU that looks like:
>>>>> console_impl=qemu
>>>>> qemu_machine="r2d"
>>>>> qemu_binary="qemu-system-sh4"
>>>>> qemu_extra_args="-nographic -serial null -serial mon:stdio"
>>>>> qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
>>>>> reset_impl=none
>>>>> flash_impl=none
>>>>>
>>>>> And here's where things get funny. When I kick off test.py with --bd
>>>>> r2dplus --id qemu --build -s -k sleep it will build and launch the board
>>>>> and since I have -s I can see stdio and I see U-Boot come up and give me
>>>>> the prompt, and then test.py says it times out waiting for the prompt.
>>>>> Any ideas where to poke next? I want to say something is funny with
>>>>> respect to what we see and where we see it (in terms of pipes) due to
>>>>> having to say -serial null -serial mon:stdio so that we see port #2 on
>>>>> the "board" rather than port #1 as this is the port that U-Boot and
>>>>> Linux use by default. Thanks!
>>>>
>>>> Does "-serial null -serial mon:stdio" cause qemu to re-open file
>>>> descriptors rather than just using stdout directly, or something
>>>> like that? If so, perhaps its output is getting into the overall
>>>> script's stdout (e.g. your terminal/console?) rather than the pipe
>>>> that test/py is reading. If so, you'd see the qemu output but
>>>> test/py wouldn't.
>>>>
>>>> I think you can test this assumption by removing the -s option. If
>>>> you still see qemu output, then qemu is sending it directly to
>>>> wherever the overall stdout is going. If you no longer see qemu's
>>>> output, then test/py must be reading it and only echo'ing it due to
>>>> the -s option, and so you'd have to look somewhere else.
>>>
>>> When I drop out -s instead I get:
>>> ----------------------------------- Captured stdout ------------------------------------
>>> +u-boot-test-reset r2dplus qemu
>>> long write to SH7750_WCR1_A7 (0x000000001f800008) ignored
>>> long write to SH7750_WCR2_A7 (0x000000001f80000c) ignored
>>> long write to SH7750_WCR3_A7 (0x000000001f800010) ignored
>>> long write to SH7750_MCR_A7 (0x000000001f800014) ignored
>>> word write to SH7750_RTCNT_A7 (0x000000001f800020) ignored
>>> word write to SH7750_RTCOR_A7 (0x000000001f800024) ignored
>>> Write access to refresh count register
>>> word write to SH7750_RTCSR_A7 (0x000000001f80001c) ignored
>>> Read access to refresh count register, incrementing
>>> long write to SH7750_MCR_A7 (0x000000001f800014) ignored
>>>
>>>
>>> U-Boot 2016.11-00492-ged6a1e9bbf0c (Dec 02 2016 - 14:14:17 -0500)
>>>
>>> CPU: SH4
>>> BOARD: Renesas Solutions R2D Plus
>>> DRAM: 64 MiB
>>> Flash: ERROR: too many flash sectors
>>> 8 MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> PCI: SH7751 PCI host bridge found.
>>> 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
>>> PCI: Bus Dev VenId DevId Class Int
>>> PCI:
>>> 00:00.0 - 1054:350e - Bridge device
>>> 00:02.0 - 10ec:8139 - Network controller
>>> In: serial
>>> Out: serial
>>> Err: serial
>>> Net: RTL8139#0
>>> Error: RTL8139#0 address not set.
>>>
>>> IDE: Bus 0: not available
>>> => => s
>>> =========================== 92 tests deselected by '-ksleep' ===========================
>>> ======================= 1 failed, 92 deselected in 31.20 seconds =======================
>>>
>>> So it's seeing output, but for some reason not matching on it?
>>
>> If you drop -s, you shouldn't see any of U-Boot's output. It looks
>> like qemu is writing its serial port output to a file descriptor
>> other than the stdout that's fed to its parent.
>
> Well, it doesn't give me output until it times out and then dumps that.
>
>> Oh, you can also confirm this by looking in the test-log.html
>> generated by test/py; that will show you whether test/py sees qemu's
>> output at all, since all of qemu's output is logged to that file. I
>> guess this assumes you're running locally, since Travis doesn't save
>> that file for you to look at. Perhaps you could cat it after running
>> test/py though.
>
> I'm not quite sure what I should (not) be seeing,
> http://hastebin.com/upimerumaz.xml is the file. Thanks!
The qemu output is getting into test/py; I see the U-Boot boot output
all the way up to the first shell prompt.
It looks like some test is attempting to execute a "sleep" command. The
code sends the command text to the target in chunks and waits for it to
echo back. The chunk size is 16 characters so I believe would included
the entire command and trailing \n in this cae. I can see that qemu has
only echo'd back the first character "s", so I think U-Boot hung and
stopped responding, or there's some issue getting the command string
into/out-of qemu?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-12-02 21:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-02 14:40 [U-Boot] qemu and u-boot-console and other ports? Tom Rini
2016-12-02 18:03 ` Stephen Warren
2016-12-02 19:18 ` Tom Rini
2016-12-02 19:21 ` Stephen Warren
2016-12-02 20:01 ` Tom Rini
2016-12-02 21:00 ` Stephen Warren
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.