[U-Boot] qemu and u-boot-console and other ports?

[Stephen Warren]

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.