From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Fri, 2 Dec 2016 11:03:00 -0700 Subject: [U-Boot] qemu and u-boot-console and other ports? In-Reply-To: <20161202144027.GN2546@bill-the-cat> References: <20161202144027.GN2546@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.