From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 17 Feb 2016 11:38:42 -0700 Subject: [U-Boot] test/py main_signon In-Reply-To: <56C43272.9020709@monstr.eu> References: <56C3121E.7060406@xilinx.com> <56C324F8.6090106@denx.de> <56C3487B.5070802@xilinx.com> <56C350C7.90804@wwwdotorg.org> <56C396D1.1050704@wwwdotorg.org> <56C43272.9020709@monstr.eu> Message-ID: <56C4BE32.40703@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 02/17/2016 01:42 AM, Michal Simek wrote: ... > Stephen: Do you have your u-boot-test-hooks for qemu? I only have some local hacks that aren't at all generic. They're on my laptop at home so I can't share them right now, but I can describe them from memory: u-boot-test-flash: Does nothing u-boot-test-reset: Does nothing (I assume the test/py code will kill and restart the u-boot-test-console process each time it executes u-boot-test-reset). u-boot-test-console: exec()s qemu with whatever target-specific options are required to make it execute the appropriate U-Boot binary as firmware (rather than the more common option of booting a Linux kernel for example), and with the emulated serial port connected to qemu's stdin/stdout. Something like: exec qemu-system-arm -M raspi2 -serial stdio -fw /path/to/u-boot.bin ... I had considered a new u_boot_console_qemu to standardize this a bit more. I'm not sure how useful this is since the user will still need to provide some configuration e.g. where the qemu binary is located, if there's a disk image to use for the emulated SD card, whether their system can support emulated Ethernet in qemu, etc. So, they may as well use u_boot_console_exec_attach, and implement the same hook scripts as any other system. I had also wondered about updating .travis.yml to test via qemu too. Maybe that's better done by an external test system though.