Fwd: use invd instead of wbinvd in real mode start code

Fwd: use invd instead of wbinvd in real mode start code

[Andy Shevchenko]

---------- Forwarded message ---------
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Mon, Feb 17, 2020 at 2:31 PM
Subject: use invd instead of wbinvd in real mode start code
To: Masahiro Yamada <masahiroy@kernel.org>, Simon Glass
<sjg@chromium.org>, Bin Meng <bmeng.cn@gmail.com>


Hi!

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.

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.

--
With Best Regards,
Andy Shevchenko


-- 
With Best Regards,
Andy Shevchenko

use invd instead of wbinvd in real mode start code

[Andy Shevchenko]

On Mon, Feb 17, 2020 at 2:31 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> ---------- Forwarded message ---------
> From: Andy Shevchenko <andy.shevchenko@gmail.com>
> Date: Mon, Feb 17, 2020 at 2:31 PM
> Subject: use invd instead of wbinvd in real mode start code
> To: Masahiro Yamada <masahiroy@kernel.org>, Simon Glass
> <sjg@chromium.org>, Bin Meng <bmeng.cn@gmail.com>
>
>
> Hi!
>
> It seems Masahiro's patches (don't know yet which one out of two,
> probably invd one) broke the boot on Intel Edison.

Before patches:
...
DRAM:  980.6 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc at ff3fc000: 0, mmc at ff3fa000: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Saving Environment to MMC... Writing to redundant MMC(0)... OK
Saving Environment to MMC... Writing to MMC(0)... OK
Net:   No ethernet found.
Hit any key to stop autoboot:  0


After them (v2020.04-rc2):
...
DRAM:  sfi: failed to locate SYST table
sfi: failed to locate SYST table
16 EiB


>
> Reverting (both for now) helps.
>
> 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.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
With Best Regards,
Andy Shevchenko

use invd instead of wbinvd in real mode start code

[Andy Shevchenko]

(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!

-- 
With Best Regards,
Andy Shevchenko

use invd instead of wbinvd in real mode start code

[Bin Meng]

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

use invd instead of wbinvd in real mode start code

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

use invd instead of wbinvd in real mode start code

[Bin Meng]

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

use invd instead of wbinvd in real mode start code

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All he had was nothing, but that was something, and now it  had  been
taken away.                             - Terry Pratchett, _Sourcery_

use invd instead of wbinvd in real mode start code

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200217/532b5138/attachment.sig>

use invd instead of wbinvd in real mode start code

[Andy Shevchenko]

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!

-- 
With Best Regards,
Andy Shevchenko

use invd instead of wbinvd in real mode start code

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

use invd instead of wbinvd in real mode start code

[Andy Shevchenko]

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?

-- 
With Best Regards,
Andy Shevchenko

use invd instead of wbinvd in real mode start code

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200217/171a8d55/attachment.sig>

use invd instead of wbinvd in real mode start code

[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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
GUIs  are  virtually  useless.  Learn  tools.  They're  configurable,
scriptable, automatable, cron-able, interoperable, etc. We don't need
no brain-dead winslurping monolithic claptrap.
                               -- Tom Christiansen in 371140df at csnews

use invd instead of wbinvd in real mode start code

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200217/db0bb901/attachment.sig>

use invd instead of wbinvd in real mode start code

[Heiko Schocher]

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.bisect

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
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

use invd instead of wbinvd in real mode start code

[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.bisect
>
> 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?

-- 
With Best Regards,
Andy Shevchenko

use invd instead of wbinvd in real mode start code

[Heiko Schocher]

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.bisect
>>
>> 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
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

use invd instead of wbinvd in real mode start code

[Andy Shevchenko]

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).

-- 
With Best Regards,
Andy Shevchenko

use invd instead of wbinvd in real mode start code

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200218/88787d5b/attachment.sig>

use invd instead of wbinvd in real mode start code

[Andy Shevchenko]

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!


-- 
With Best Regards,
Andy Shevchenko

use invd instead of wbinvd in real mode start code

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If ignorance is bliss, why aren't there more happy people?

use invd instead of wbinvd in real mode start code

[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 :)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200219/bbd4a84e/attachment.sig>

use invd instead of wbinvd in real mode start code

[Heiko Schocher]

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
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de