Re: use invd instead of wbinvd in real mode start code
(Cc'ing mailing list and Tom again, thus keep entire previous answer)
On Mon, Feb 17, 2020 at 3:39 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Feb 17, 2020 at 2:41 PM Masahiro Yamada masahiroy@kernel.org wrote:
On Mon, Feb 17, 2020 at 9:31 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
It seems Masahiro's patches (don't know yet which one out of two, probably invd one) broke the boot on Intel Edison.
Reverting (both for now) helps.
Why both?
Because I did bisecting by intuition (much faster than usual one).
git bisect is the usual way to figure out the culprit.
Too much work to do this way.
And since I was about to have my lunch, I didn't continue investigating. Let me do it now.
OK, as my intuition told me the problematic one is
commit 0d67fac29f3187e67f4fd3ef15f73e91be2fad12 Author: Masahiro Yamada masahiroy@kernel.org Date: Wed Jan 8 20:08:44 2020 +0900
x86: use invd instead of wbinvd in real mode start code
Please, revert or fix ASAP before v2020.04 release! ^^^
P.S. I dunno how it has been tested, so, if you have Intel Edison in possession, please, don't forget to test on it. It's not first time the Intel Edison behaviour is broken due to poor testing.
I tested my patches on qemu.
Exactly my point of definition "poor". It's not first time (and not last) when QEmu sucks.
Sorry for the breakage on your board, but I do not have Edison board. It is not possible to test every board.
No problem, it's rather to x86 maintainers to have at least one-two real hardware testing before applying this. QEMU is completely not enough!
Hi Andy,
On Mon, Feb 17, 2020 at 9:47 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
(Cc'ing mailing list and Tom again, thus keep entire previous answer)
On Mon, Feb 17, 2020 at 3:39 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Feb 17, 2020 at 2:41 PM Masahiro Yamada masahiroy@kernel.org wrote:
On Mon, Feb 17, 2020 at 9:31 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
It seems Masahiro's patches (don't know yet which one out of two, probably invd one) broke the boot on Intel Edison.
Reverting (both for now) helps.
Why both?
Because I did bisecting by intuition (much faster than usual one).
git bisect is the usual way to figure out the culprit.
Too much work to do this way.
And since I was about to have my lunch, I didn't continue investigating. Let me do it now.
OK, as my intuition told me the problematic one is
commit 0d67fac29f3187e67f4fd3ef15f73e91be2fad12 Author: Masahiro Yamada masahiroy@kernel.org Date: Wed Jan 8 20:08:44 2020 +0900
x86: use invd instead of wbinvd in real mode start code
Please, revert or fix ASAP before v2020.04 release! ^^^
P.S. I dunno how it has been tested, so, if you have Intel Edison in possession, please, don't forget to test on it. It's not first time the Intel Edison behaviour is broken due to poor testing.
I tested my patches on qemu.
Exactly my point of definition "poor". It's not first time (and not last) when QEmu sucks.
Sorry for the breakage on your board, but I do not have Edison board. It is not possible to test every board.
No problem, it's rather to x86 maintainers to have at least one-two real hardware testing before applying this. QEMU is completely not enough!
Is that because on Intel Edison U-Boot is not the first stage bootloader?
Regards, Bin
On Mon, Feb 17, 2020 at 3:52 PM Bin Meng bmeng.cn@gmail.com wrote:
On Mon, Feb 17, 2020 at 9:47 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Feb 17, 2020 at 3:39 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Feb 17, 2020 at 2:41 PM Masahiro Yamada masahiroy@kernel.org wrote:
On Mon, Feb 17, 2020 at 9:31 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
...
OK, as my intuition told me the problematic one is
commit 0d67fac29f3187e67f4fd3ef15f73e91be2fad12 Author: Masahiro Yamada masahiroy@kernel.org Date: Wed Jan 8 20:08:44 2020 +0900
x86: use invd instead of wbinvd in real mode start code
Please, revert or fix ASAP before v2020.04 release! ^^^
P.S. I dunno how it has been tested, so, if you have Intel Edison in possession, please, don't forget to test on it. It's not first time the Intel Edison behaviour is broken due to poor testing.
I tested my patches on qemu.
Exactly my point of definition "poor". It's not first time (and not last) when QEmu sucks.
Sorry for the breakage on your board, but I do not have Edison board. It is not possible to test every board.
No problem, it's rather to x86 maintainers to have at least one-two real hardware testing before applying this. QEMU is completely not enough!
Is that because on Intel Edison U-Boot is not the first stage bootloader?
I don't know for sure, but I may speculate that this is a prerequisite.
On Mon, Feb 17, 2020 at 10:00 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Feb 17, 2020 at 3:52 PM Bin Meng bmeng.cn@gmail.com wrote:
On Mon, Feb 17, 2020 at 9:47 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Feb 17, 2020 at 3:39 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Feb 17, 2020 at 2:41 PM Masahiro Yamada masahiroy@kernel.org wrote:
On Mon, Feb 17, 2020 at 9:31 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
...
OK, as my intuition told me the problematic one is
commit 0d67fac29f3187e67f4fd3ef15f73e91be2fad12 Author: Masahiro Yamada masahiroy@kernel.org Date: Wed Jan 8 20:08:44 2020 +0900
x86: use invd instead of wbinvd in real mode start code
Please, revert or fix ASAP before v2020.04 release! ^^^
P.S. I dunno how it has been tested, so, if you have Intel Edison in possession, please, don't forget to test on it. It's not first time the Intel Edison behaviour is broken due to poor testing.
I tested my patches on qemu.
Exactly my point of definition "poor". It's not first time (and not last) when QEmu sucks.
Sorry for the breakage on your board, but I do not have Edison board. It is not possible to test every board.
No problem, it's rather to x86 maintainers to have at least one-two real hardware testing before applying this. QEMU is completely not enough!
Is that because on Intel Edison U-Boot is not the first stage bootloader?
I don't know for sure, but I may speculate that this is a prerequisite.
anyway, for now please send a revert patch.
Regards, Bin
On Mon, Feb 17, 2020 at 4:49 PM Bin Meng bmeng.cn@gmail.com wrote:
On Mon, Feb 17, 2020 at 10:00 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
...
Is that because on Intel Edison U-Boot is not the first stage bootloader?
I don't know for sure, but I may speculate that this is a prerequisite.
anyway, for now please send a revert patch.
Just sent, thanks!
Dear Andy,
In message CAHp75VdUY7zJfkc4YV-KTt1aEKg9Ggy6PsJAEOkgo9eCtQx9Kg@mail.gmail.com you wrote:
git bisect is the usual way to figure out the culprit.
Too much work to do this way.
If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks?
Best regards,
Wolfgang Denk
On Mon, Feb 17, 2020 at 04:09:29PM +0100, Wolfgang Denk wrote:
Dear Andy,
In message CAHp75VdUY7zJfkc4YV-KTt1aEKg9Ggy6PsJAEOkgo9eCtQx9Kg@mail.gmail.com you wrote:
git bisect is the usual way to figure out the culprit.
Too much work to do this way.
If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks?
The problem with bisect'ing problems like these is always "how do I wire up updating the board" and not so much "how do I bisect it quickly". If you can update the board automatically you can let 'git bisect run' go off on the problem with a simple script that updates + runs our test.py code and just the version check test. That's what I do anyhow :)
While I think the programmer I have for my minnowboard could be wired up in such a way, I have not due to general fear of wearing out the SPI.
On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wd@denx.de wrote:
In message CAHp75VdUY7zJfkc4YV-KTt1aEKg9Ggy6PsJAEOkgo9eCtQx9Kg@mail.gmail.com you wrote:
git bisect is the usual way to figure out the culprit.
Too much work to do this way.
If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks?
Bisection time something about 10%, while 90% is flashing the board and, given the result, triggering either bad or good next cycle.
On Mon, Feb 17, 2020 at 5:32 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wd@denx.de wrote:
In message CAHp75VdUY7zJfkc4YV-KTt1aEKg9Ggy6PsJAEOkgo9eCtQx9Kg@mail.gmail.com you wrote:
git bisect is the usual way to figure out the culprit.
Too much work to do this way.
If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks?
Bisection time something about 10%, while 90% is flashing the board and, given the result, triggering either bad or good next cycle.
And btw, doing git bisect is not mandatory technique to follow as long as I can guarantee the (reproducible) result, right?
On Mon, Feb 17, 2020 at 05:33:59PM +0200, Andy Shevchenko wrote:
On Mon, Feb 17, 2020 at 5:32 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wd@denx.de wrote:
In message CAHp75VdUY7zJfkc4YV-KTt1aEKg9Ggy6PsJAEOkgo9eCtQx9Kg@mail.gmail.com you wrote:
git bisect is the usual way to figure out the culprit.
Too much work to do this way.
If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks?
Bisection time something about 10%, while 90% is flashing the board and, given the result, triggering either bad or good next cycle.
And btw, doing git bisect is not mandatory technique to follow as long as I can guarantee the (reproducible) result, right?
No, it's not. But personally 'git bisect run' and 'git stash' are the two features that put git far above any other SCM I've used.
Dear Andy,
In message CAHp75VfuzMm=CPJ86GspRiiv+AAYbs+jFDKP2rfNmYhsmvOY+w@mail.gmail.com you wrote:
On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wd@denx.de wrote:
In message CAHp75VdUY7zJfkc4YV-KTt1aEKg9Ggy6PsJAEOkgo9eCtQx9Kg@mail.gmail.com you wrote:
git bisect is the usual way to figure out the culprit.
Too much work to do this way.
If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks?
Bisection time something about 10%, while 90% is flashing the board and, given the result, triggering either bad or good next cycle.
Yes, and this is exactly what tbot was made for - automating such repeating, boring activities. It is wasted life time to do this manually.
Best regards,
Wolfgang Denk
Hello Andy,
Am 17.02.2020 um 17:04 schrieb Wolfgang Denk:
Dear Andy,
In message CAHp75VfuzMm=CPJ86GspRiiv+AAYbs+jFDKP2rfNmYhsmvOY+w@mail.gmail.com you wrote:
On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wd@denx.de wrote:
In message CAHp75VdUY7zJfkc4YV-KTt1aEKg9Ggy6PsJAEOkgo9eCtQx9Kg@mail.gmail.com you wrote:
git bisect is the usual way to figure out the culprit.
Too much work to do this way.
If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks?
Bisection time something about 10%, while 90% is flashing the board and, given the result, triggering either bad or good next cycle.
Yes, and this is exactly what tbot was made for - automating such repeating, boring activities. It is wasted life time to do this manually.
Yes, that is one benefit if you use tbot, see git bisect help:
http://tbot.tools/modules/tc.html?highlight=bisect#tbot.tc.git.GitRepository...
You only have to pass to the function the good commit as string and a tbot python function which tests the current commit. This test function now can call other functions like run a complete build of current source, copy the resulting images let say to a tftp directory, install the new images on the device, reboot it and run tests on the U-Boot comamndline on the real board ...
So using tbot for the complete development process makes a lot of sense, also as you have at the end a complete setup for testing your board (not only U-Boot also linux or other commandline based machines are possible to automate), it is easy to start a CI ... as tbot is a commandline tool a simple cron job is enough .. or you can integrate it easily into jenkins, buildbot, gitlab CI runner ... whatever CI you use...
If you want to get help setting up tbot, feel free to ask me or Harald directly or on the tbot mailinglist:
https://lists.denx.de/listinfo/tbot
bye, Heiko
On Tue, Feb 18, 2020 at 7:48 AM Heiko Schocher hs@denx.de wrote:
Am 17.02.2020 um 17:04 schrieb Wolfgang Denk:
In message CAHp75VfuzMm=CPJ86GspRiiv+AAYbs+jFDKP2rfNmYhsmvOY+w@mail.gmail.com you wrote:
On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wd@denx.de wrote:
In message CAHp75VdUY7zJfkc4YV-KTt1aEKg9Ggy6PsJAEOkgo9eCtQx9Kg@mail.gmail.com you wrote:
> git bisect is the usual way to figure out the culprit.
Too much work to do this way.
If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks?
Bisection time something about 10%, while 90% is flashing the board and, given the result, triggering either bad or good next cycle.
Yes, and this is exactly what tbot was made for - automating such repeating, boring activities. It is wasted life time to do this manually.
Yes, that is one benefit if you use tbot, see git bisect help:
http://tbot.tools/modules/tc.html?highlight=bisect#tbot.tc.git.GitRepository...
You only have to pass to the function the good commit as string and a tbot python function which tests the current commit. This test function now can call other functions like run a complete build of current source, copy the resulting images let say to a tftp directory, install the new images on the device, reboot it and run tests on the U-Boot comamndline on the real board ...
So using tbot for the complete development process makes a lot of sense, also as you have at the end a complete setup for testing your board (not only U-Boot also linux or other commandline based machines are possible to automate), it is easy to start a CI ... as tbot is a commandline tool a simple cron job is enough .. or you can integrate it easily into jenkins, buildbot, gitlab CI runner ... whatever CI you use...
If you want to get help setting up tbot, feel free to ask me or Harald directly or on the tbot mailinglist:
How the feed back line is organized? I mean how host system will know that a) we done flash correctly? b) the booted image is bad or good?
Hello Andy,
Am 18.02.2020 um 11:45 schrieb Andy Shevchenko:
On Tue, Feb 18, 2020 at 7:48 AM Heiko Schocher hs@denx.de wrote:
Am 17.02.2020 um 17:04 schrieb Wolfgang Denk:
In message CAHp75VfuzMm=CPJ86GspRiiv+AAYbs+jFDKP2rfNmYhsmvOY+w@mail.gmail.com you wrote:
On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wd@denx.de wrote:
In message CAHp75VdUY7zJfkc4YV-KTt1aEKg9Ggy6PsJAEOkgo9eCtQx9Kg@mail.gmail.com you wrote:
>> git bisect is the usual way to figure out the culprit. > > Too much work to do this way.
If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks?
Bisection time something about 10%, while 90% is flashing the board and, given the result, triggering either bad or good next cycle.
Yes, and this is exactly what tbot was made for - automating such repeating, boring activities. It is wasted life time to do this manually.
Yes, that is one benefit if you use tbot, see git bisect help:
http://tbot.tools/modules/tc.html?highlight=bisect#tbot.tc.git.GitRepository...
You only have to pass to the function the good commit as string and a tbot python function which tests the current commit. This test function now can call other functions like run a complete build of current source, copy the resulting images let say to a tftp directory, install the new images on the device, reboot it and run tests on the U-Boot comamndline on the real board ...
So using tbot for the complete development process makes a lot of sense, also as you have at the end a complete setup for testing your board (not only U-Boot also linux or other commandline based machines are possible to automate), it is easy to start a CI ... as tbot is a commandline tool a simple cron job is enough .. or you can integrate it easily into jenkins, buildbot, gitlab CI runner ... whatever CI you use...
If you want to get help setting up tbot, feel free to ask me or Harald directly or on the tbot mailinglist:
How the feed back line is organized? I mean how host system will know that a) we done flash correctly? b) the booted image is bad or good?
For both questions the answer is, that you need to write a testcase which answer this question.
For a) you flash the image in some way through U-Boot commands. You start this commands from a tbot testcase written in python and parse the output and/or return code of the command and than decide ...
Same for b) reboot the board, check if new version is installed by parsing the U-Boot bootlog, than start U-Boot commands to find out, if current installed version is good or bad.
bye, Heiko
On Tue, Feb 18, 2020 at 1:06 PM Heiko Schocher hs@denx.de wrote:
Am 18.02.2020 um 11:45 schrieb Andy Shevchenko:
On Tue, Feb 18, 2020 at 7:48 AM Heiko Schocher hs@denx.de wrote:
...
How the feed back line is organized? I mean how host system will know that a) we done flash correctly? b) the booted image is bad or good?
For both questions the answer is, that you need to write a testcase which answer this question.
For a) you flash the image in some way through U-Boot commands. You start this commands from a tbot testcase written in python and parse the output and/or return code of the command and than decide ...
Same for b) reboot the board, check if new version is installed by parsing the U-Boot bootlog, than start U-Boot commands to find out, if current installed version is good or bad.
Thank you for elaboration. I hoped and still hope that x86 won't be broken so drastically that I need real bisection. Above mentioned test cases is somewhat time consuming (yes, I agree that is ~one time big effort), and for now it seems much bigger effort than just guess by reading the code. Maybe in the future I'll consider to do something like this, but I think that U-Boot may gain some patches and config option to have BAT cases enabled (like predefined output on the serial when we consider commit is good and some C&C interface during the test).
On Tue, Feb 18, 2020 at 01:29:04PM +0200, Andy Shevchenko wrote:
On Tue, Feb 18, 2020 at 1:06 PM Heiko Schocher hs@denx.de wrote:
Am 18.02.2020 um 11:45 schrieb Andy Shevchenko:
On Tue, Feb 18, 2020 at 7:48 AM Heiko Schocher hs@denx.de wrote:
...
How the feed back line is organized? I mean how host system will know that a) we done flash correctly? b) the booted image is bad or good?
For both questions the answer is, that you need to write a testcase which answer this question.
For a) you flash the image in some way through U-Boot commands. You start this commands from a tbot testcase written in python and parse the output and/or return code of the command and than decide ...
Same for b) reboot the board, check if new version is installed by parsing the U-Boot bootlog, than start U-Boot commands to find out, if current installed version is good or bad.
Thank you for elaboration. I hoped and still hope that x86 won't be broken so drastically that I need real bisection. Above mentioned test cases is somewhat time consuming (yes, I agree that is ~one time big effort), and for now it seems much bigger effort than just guess by reading the code. Maybe in the future I'll consider to do something like this, but I think that U-Boot may gain some patches and config option to have BAT cases enabled (like predefined output on the serial when we consider commit is good and some C&C interface during the test).
Please note that you don't need to go and write a test case for "does it boot" as we already have one as part of our test/py/ code.
On Tue, Feb 18, 2020 at 4:43 PM Tom Rini trini@konsulko.com wrote:
On Tue, Feb 18, 2020 at 01:29:04PM +0200, Andy Shevchenko wrote:
On Tue, Feb 18, 2020 at 1:06 PM Heiko Schocher hs@denx.de wrote:
Am 18.02.2020 um 11:45 schrieb Andy Shevchenko:
On Tue, Feb 18, 2020 at 7:48 AM Heiko Schocher hs@denx.de wrote:
...
How the feed back line is organized? I mean how host system will know that a) we done flash correctly? b) the booted image is bad or good?
For both questions the answer is, that you need to write a testcase which answer this question.
For a) you flash the image in some way through U-Boot commands. You start this commands from a tbot testcase written in python and parse the output and/or return code of the command and than decide ...
Same for b) reboot the board, check if new version is installed by parsing the U-Boot bootlog, than start U-Boot commands to find out, if current installed version is good or bad.
Thank you for elaboration. I hoped and still hope that x86 won't be broken so drastically that I need real bisection. Above mentioned test cases is somewhat time consuming (yes, I agree that is ~one time big effort), and for now it seems much bigger effort than just guess by reading the code. Maybe in the future I'll consider to do something like this, but I think that U-Boot may gain some patches and config option to have BAT cases enabled (like predefined output on the serial when we consider commit is good and some C&C interface during the test).
Please note that you don't need to go and write a test case for "does it boot" as we already have one as part of our test/py/ code.
Ah, thanks, that's nice!
Dear Heiko,
In message 7d480cee-88aa-f4e3-7e3d-8740bbdcc224@denx.de you wrote:
How the feed back line is organized? I mean how host system will know that a) we done flash correctly? b) the booted image is bad or good?
For both questions the answer is, that you need to write a testcase which answer this question.
For a) you flash the image in some way through U-Boot commands. You start this commands from a tbot testcase written in python and parse the output and/or return code of the command and than decide ...
Same for b) reboot the board, check if new version is installed by parsing the U-Boot bootlog, than start U-Boot commands to find out, if current installed version is good or bad.
Maybe it would be nice for people who don't know tbot if you could link to some examples for such testcases? I think this should even be covered in the tbot docs?
Best regards,
Wolfgang Denk
On Wed, Feb 19, 2020 at 02:14:31PM +0100, Wolfgang Denk wrote:
Dear Heiko,
In message 7d480cee-88aa-f4e3-7e3d-8740bbdcc224@denx.de you wrote:
How the feed back line is organized? I mean how host system will know that a) we done flash correctly? b) the booted image is bad or good?
For both questions the answer is, that you need to write a testcase which answer this question.
For a) you flash the image in some way through U-Boot commands. You start this commands from a tbot testcase written in python and parse the output and/or return code of the command and than decide ...
Same for b) reboot the board, check if new version is installed by parsing the U-Boot bootlog, than start U-Boot commands to find out, if current installed version is good or bad.
Maybe it would be nice for people who don't know tbot if you could link to some examples for such testcases? I think this should even be covered in the tbot docs?
The tbot docs should cover things like running test/py and specifying testcases so you don't have to write things like "is the board alive?" from scratch :)
Hello Tom, Wolfgang,
Am 19.02.2020 um 14:42 schrieb Tom Rini:
On Wed, Feb 19, 2020 at 02:14:31PM +0100, Wolfgang Denk wrote:
Dear Heiko,
In message 7d480cee-88aa-f4e3-7e3d-8740bbdcc224@denx.de you wrote:
How the feed back line is organized? I mean how host system will know that a) we done flash correctly? b) the booted image is bad or good?
For both questions the answer is, that you need to write a testcase which answer this question.
For a) you flash the image in some way through U-Boot commands. You start this commands from a tbot testcase written in python and parse the output and/or return code of the command and than decide ...
Same for b) reboot the board, check if new version is installed by parsing the U-Boot bootlog, than start U-Boot commands to find out, if current installed version is good or bad.
Maybe it would be nice for people who don't know tbot if you could link to some examples for such testcases? I think this should even be covered in the tbot docs?
The tbot docs should cover things like running test/py and specifying testcases so you don't have to write things like "is the board alive?" from scratch :)
Yes, there is room for optimizations in docs and examples ;-)
Harald just have a first rough version, which can start nicely test/py from U-Boot ... so I hope we have this soon "online" and in the docs.
Ok, next step is to bring some examples to a online repo... I see, this would help much for starting from scratch... beside of:
http://tbot.tools/quickstart.html http://tbot.tools/quickstart.html#testcases http://tbot.tools/quickstart.html#hardware-interaction
or
http://tbot.tools/configuration.html
But hey, tbot is open source, feel free to help.
bye, Heiko
On Mon, Feb 17, 2020 at 05:32:45PM +0200, Andy Shevchenko wrote:
On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wd@denx.de wrote:
In message CAHp75VdUY7zJfkc4YV-KTt1aEKg9Ggy6PsJAEOkgo9eCtQx9Kg@mail.gmail.com you wrote:
git bisect is the usual way to figure out the culprit.
Too much work to do this way.
If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks?
Bisection time something about 10%, while 90% is flashing the board and, given the result, triggering either bad or good next cycle.
In case our emails crossed, this is where 'git bisect run' comes in handy if you can automate the flashing. It's why I have the follow script locally:
#!/bin/bash
if [ $# -ne 1 -a $# -ne 2 ]; then echo "Usage: $0 buildman-spec test.py-id" exit 1 fi
if [ $# -eq 2 ]; then ARGS="$1 --id $2" else ARGS="$1" fi
# Build the board virtualenv -p /usr/bin/python3 /tmp/venv . /tmp/venv/bin/activate pip install -r test/py/requirements.txt
set +e ./tools/buildman/buildman -o /tmp -P ^${1}$ set -e
# Run the tests export PATH=${PATH}:/home/trini/work/u-boot/uboot-test-hooks/bin export PYTHONPATH=/home/trini/work/u-boot/uboot-test-hooks/py/bill-the-cat:${PYTHONPATH} export UBOOT_TRAVIS_BUILD_DIR=/tmp/.bm-work/$1 ./test/py/test.py --bd $ARGS --build-dir "$UBOOT_TRAVIS_BUILD_DIR" -k 'not sleep'
To run test.py automatically for a board, and I have several boards hooked up to the framework Stephen Warren has. When I need to bisect a boot failure I change 'not sleep' to 'version' so it only runs that one super quick test. Then 'git bisect run uboot-test.sh boardname' once I have the first good/bad. And I'll do a 'git checkout' of a commit or two if I have a hunch of what introduced the failure.
participants (5)
-
Andy Shevchenko -
Bin Meng -
Heiko Schocher -
Tom Rini -
Wolfgang Denk