From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Mon, 4 Jan 2016 13:34:57 -0700 Subject: [U-Boot] [PATCH V2 1/7] test/py: Implement pytest infrastructure In-Reply-To: <568A6871.5030802@monstr.eu> 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> <56741D53.3040104@monstr.eu> <56745177.9040400@wwwdotorg.org> <568A6871.5030802@monstr.eu> Message-ID: <568AD771.8050101@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 01/04/2016 05:41 AM, Michal Simek wrote: > On 18.12.2015 19:33, Stephen Warren wrote: >> On 12/18/2015 07:50 AM, Michal Simek wrote: >>> 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. >> >> Great! > > btw: Is there any reason that you don't allow to clone your git repos? Hmm. git protocol doesn't seem to work on github any more; try cloning over SSH if you have a github ID (git at github.com:swarren/u-boot.git) or HTTPS otherwise (https://github.com/swarren/u-boot.git). ... >>> I will have more comments when I spend more time with it but it looks >>> pretty good for start. > > Then I see incorrect timeout reporting with tftpboot > > Loading: > *%08################################################################# > ###################### > 2.4 MiB/s This looks like another case where an individual test needs to adjust the timeout used to wait for the prompt. > Regarding board-identity parameter. If not setup you are using "na" but > I think CONFIG_IDENT_STRING can be used instead. I believe those two things are different. The test system's concept of board identity refers to the physical instance of the board (e.g. if you have 3 identical boards in order to test N branches/commits in parallel) whereas CONFIG_IDENT_STRING is something built into the U-Boot binary to identify the type (not instance) of board if I understand correctly. > Also I would like to have this parameter available in test because for > ethernet testing will be good to have several folders with golden images > for testing. I believe you can access uboot_console.config.board_identity. However, that would make the tests depend on your particular environment, so it's probably not a good idea to use that parameter at all. > Also is there a way to run one particular test for easier developing. I > know that I can simply remove all testing files but better option will > be useful. If you pass "-k testname" to the script, it'll only run test(s) that match that string. That's a standard pytest option.