From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Fri, 18 Dec 2015 15:50:59 +0100 Subject: [U-Boot] [PATCH V2 1/7] test/py: Implement pytest infrastructure In-Reply-To: <5671B046.1050307@wwwdotorg.org> References: <1449094708-14784-1-git-send-email-swarren@wwwdotorg.org> <56685784.9040907@wwwdotorg.org> <56717F09.8020407@monstr.eu> <567190E2.5010308@wwwdotorg.org> <5671A8D6.8090800@wwwdotorg.org> <5671B046.1050307@wwwdotorg.org> Message-ID: <56741D53.3040104@monstr.eu> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Stephen, >> Finally, the example scripts support two boards; my >> home/laptop dev >> setup that uses a Numato relay board to control the signals >> to the >> board I use there, and my work desktop dev setup that >> uses our >> "PM342" debug board to controll the signals. The latter >> works >> logically the same as the numato relay board, except it >> contains >> electronic switches driven by an FTDI chip. >> >> I expect this is FTDI chip on the target right? >> >> >> It's actually a separate common debug board. Most/all of our >> development boards (and perhaps some production boards) have a >> standardized connector into which the common debug board plugs. >> >> >> >> ok. >> I think my setup is not that far from what you are using and I expect >> that others SoCs will be very similar. >> Do you have any other testcases which you are running and you haven't >> sent? > > Not at present. > > As an FYI, I typically publish my local work-in-progress branch at: > git://github.com/swarren/u-boot.git tegra_dev I have looked at your patches and no problem to get it work on microblaze and zynq board. I do use kermit without any problem. I used cu on Microblaze. - What I do miss is power off functionality because it is not practical to keep board always on. On can be solved via reset script. - Then place tests to separate folder for better separation. - I see that output log doesn't handle tabs correctly - output from i2c bus for example. - Is there any way to handle timeouts or stucks? For example to recognize if sleep 60 fails or just takes long. It means setting up timeouts will be good. I will have more comments when I spend more time with it but it looks pretty good for start. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: