[U-Boot] [ANN] U-Boot v2016.09 is released

[U-Boot] [ANN] U-Boot v2016.09 is released

[Tom Rini]

Hey all,

I've released v2016.09 and it's now live on git and FTP and ACD (along
with PGP sig file).

To repeat some of the highlights from the rc releases:
- More DM work (MMC, of-platdata for size constrained instances, etc)
- Lots and lots of architecture / SoC / Platform updates: x86, rockchip,
  sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier
- mkimage cleanups
- More test.py updates, vboot now a testcase
- Secure boot work on both ARM and PowerPC.
- PSCI updates
- MAKEALL is gone, buildman is for use by all
- We now have xtensa support
- DT overlays
- More Kconfig migration
- Some NFS fixes

Note that in some cases you may see a message like:
CACHE: Misaligned operation at range [xxxxxxxx,yyyyyyyy]
and there's good and bad news here.  What had been a debug print (and so
off basically) is now a regular message.  So there's no new problems,
just problems that are now visible and we're working on fixing.  Some of
these were solved during the cycle but some of them still need some more
discussion or just a decision being made (so, that's on me).

Another thing I'd like to call out, and ask for a little help with too
is automated testing.  The framework in test/py/test.py can be used on
real hardware and Stephen Warren has been doing a good job having things
run on Tegra boards.  You can see his scripts here[1].  I've setup
locally some of my boards (some TI, RPi3, A20-OLinuXino-Lime2) and I'm
looking at adding more still, so long as I can update U-Boot in a way
that does not involve the console.  You can see my scripts here[2] and
I'm cleaning things up and pushing them back up to Stephen.  But there's
always more to do and test.  Is anyone else out there running this on
real hardware, or would like to set this up?  Has anyone out there
gotten this hooked up with qemu?

As always, I know I'm missing pointing out a few things that I should
point out and would encourage folks to chime in if there's anything they
would like to highlight.

Thanks again everyone!

[1]: https://github.com/swarren/uboot-test-hooks
[2]: https://github.com/trini/uboot-test-hooks

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160912/53acd608/attachment.sig>

[U-Boot] [ANN] U-Boot v2016.09 is released

[Michal Simek]

Hi Tom,

2016-09-12 18:21 GMT+02:00 Tom Rini <trini@konsulko.com>:

> Hey all,
>
> I've released v2016.09 and it's now live on git and FTP and ACD (along
> with PGP sig file).
>
> To repeat some of the highlights from the rc releases:
> - More DM work (MMC, of-platdata for size constrained instances, etc)
> - Lots and lots of architecture / SoC / Platform updates: x86, rockchip,
>   sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier
> - mkimage cleanups
> - More test.py updates, vboot now a testcase
> - Secure boot work on both ARM and PowerPC.
> - PSCI updates
> - MAKEALL is gone, buildman is for use by all
> - We now have xtensa support
> - DT overlays
> - More Kconfig migration
> - Some NFS fixes
>
> Note that in some cases you may see a message like:
> CACHE: Misaligned operation at range [xxxxxxxx,yyyyyyyy]
> and there's good and bad news here.  What had been a debug print (and so
> off basically) is now a regular message.  So there's no new problems,
> just problems that are now visible and we're working on fixing.  Some of
> these were solved during the cycle but some of them still need some more
> discussion or just a decision being made (so, that's on me).
>
> Another thing I'd like to call out, and ask for a little help with too
> is automated testing.  The framework in test/py/test.py can be used on
> real hardware and Stephen Warren has been doing a good job having things
> run on Tegra boards.  You can see his scripts here[1].  I've setup
> locally some of my boards (some TI, RPi3, A20-OLinuXino-Lime2) and I'm
> looking at adding more still, so long as I can update U-Boot in a way
> that does not involve the console.  You can see my scripts here[2] and
> I'm cleaning things up and pushing them back up to Stephen.  But there's
> always more to do and test.  Is anyone else out there running this on
> real hardware, or would like to set this up?  Has anyone out there
> gotten this hooked up with qemu?
>


I do run them on boards which I have locally connected to my PC - zynq and
zynqmp.
I have tried it on microblaze but I don't have any setup which I can
directly run but I know it works.
Then I can run it on qemu without any issue and also I have setup for Xilinx
boardfarm which contain hundreds of boards.
The main question for me is how to make it stable.

I also want to try SD boot mode with flashair which Stephen tried. I have
it here. i have scripts
ready but just didn't run it.

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

[U-Boot] [ANN] U-Boot v2016.09 is released

[Lukasz Majewski]

Hi Tom,

> Hey all,
> 
> I've released v2016.09 and it's now live on git and FTP and ACD (along
> with PGP sig file).
> 
> To repeat some of the highlights from the rc releases:
> - More DM work (MMC, of-platdata for size constrained instances, etc)
> - Lots and lots of architecture / SoC / Platform updates: x86,
> rockchip, sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier
> - mkimage cleanups
> - More test.py updates, vboot now a testcase
> - Secure boot work on both ARM and PowerPC.
> - PSCI updates
> - MAKEALL is gone, buildman is for use by all
> - We now have xtensa support
> - DT overlays
> - More Kconfig migration
> - Some NFS fixes
> 
> Note that in some cases you may see a message like:
> CACHE: Misaligned operation at range [xxxxxxxx,yyyyyyyy]
> and there's good and bad news here.  What had been a debug print (and
> so off basically) is now a regular message.  So there's no new
> problems, just problems that are now visible and we're working on
> fixing.  Some of these were solved during the cycle but some of them
> still need some more discussion or just a decision being made (so,
> that's on me).
> 
> Another thing I'd like to call out, and ask for a little help with too
> is automated testing.  The framework in test/py/test.py can be used on
> real hardware and Stephen Warren has been doing a good job having
> things run on Tegra boards.  You can see his scripts here[1].  I've
> setup locally some of my boards (some TI, RPi3, A20-OLinuXino-Lime2)
> and I'm looking at adding more still, so long as I can update U-Boot
> in a way that does not involve the console.  You can see my scripts
> here[2] and I'm cleaning things up and pushing them back up to
> Stephen.  But there's always more to do and test.  Is anyone else out
> there running this on real hardware, or would like to set this up?
> Has anyone out there gotten this hooked up with qemu?

For testing I'm using real HW - Odroid U3 and Odroid XU3 boards

Basically, I'm using DFU [*] and Thor to upload binaries (kernel,
rootfs, u-boot, mbr.img when needed).

The architecture is as follows:
- Buildbot to display data
- Some bash scripts with wrapped expect to control the device (Yes, it
  works stable). I'm also using u-boot's  ./test/py/test.py 
- Simple FTDI serial dongle [2], control SW (python) can be found
  here [3]
- Arduino relays - [4]
- NO JENKINS - R.I.P


[*] - It is also possible to use DFU via ETH [1]

[1] - ./doc/README.dfutftp
[2] -
https://www.amazon.com/Gikfun-FT232RL-Adapter-Arduino-AE1186x2/dp/B01HXT8DZ4/ref=sr_1_18?s=pc&ie=UTF8&qid=1473698450&sr=1-18&keywords=ftdi+usb+to+serial
[3] - https://github.com/lmajewski/HWT_io_ctl
[4] -
https://www.amazon.com/JBtek-Channel-Module-Arduino-Raspberry/dp/B00KTEN3TM/ref=sr_1_3?s=pc&ie=UTF8&qid=1473698574&sr=1-3&keywords=arduino+relay

Cost effective and simple.

Moreover, the Buildbot controlled tests also perform build tests for
Samsung and other manufacturers.

Two remote repositories are monitored (polled) - u-boot master and my
u-boot-dfu {master|testing}

More than 1k runs for both boards without failure.

Supported tests:
- Build u-boot and flash it
- Check flashed u-boot version
- u-boot_dfu-gadget (out ./test/py/ test)
- u-boot_ums-gadget (out ./test/py/ test)
- u-boot_shell_basics (out ./test/py/ test)
- u-boot_help (out ./test/py/ test)
- u-boot_test_unknown_cmd (out ./test/py/ test)
- kernel_build_and_boot
- u-boot_sleep (out ./test/py/ test)

Screenshot attached.

> 
> As always, I know I'm missing pointing out a few things that I should
> point out and would encourage folks to chime in if there's anything
> they would like to highlight.
> 
> Thanks again everyone!
> 
> [1]: https://github.com/swarren/uboot-test-hooks
> [2]: https://github.com/trini/uboot-test-hooks
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Buildbot_test_setup.png
Type: image/png
Size: 79084 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160912/b4d34abe/attachment.png>

[U-Boot] [ANN] U-Boot v2016.09 is released

[Heiko Schocher]

Hello Tom,

Am 12.09.2016 um 18:21 schrieb Tom Rini:
> Hey all,
>
> I've released v2016.09 and it's now live on git and FTP and ACD (along
> with PGP sig file).
>
> To repeat some of the highlights from the rc releases:
> - More DM work (MMC, of-platdata for size constrained instances, etc)
> - Lots and lots of architecture / SoC / Platform updates: x86, rockchip,
>    sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier
> - mkimage cleanups
> - More test.py updates, vboot now a testcase
> - Secure boot work on both ARM and PowerPC.
> - PSCI updates
> - MAKEALL is gone, buildman is for use by all
> - We now have xtensa support
> - DT overlays
> - More Kconfig migration
> - Some NFS fixes
>
> Note that in some cases you may see a message like:
> CACHE: Misaligned operation at range [xxxxxxxx,yyyyyyyy]
> and there's good and bad news here.  What had been a debug print (and so
> off basically) is now a regular message.  So there's no new problems,
> just problems that are now visible and we're working on fixing.  Some of
> these were solved during the cycle but some of them still need some more
> discussion or just a decision being made (so, that's on me).

I had posted 2 fixes for at91 based boards:

[U-Boot] net, macb: fix misaligned cache operation warning
http://patchwork.ozlabs.org/patch/663488/
[U-Boot] net, cmd: fix misaligned cache operation warning
http://patchwork.ozlabs.org/patch/663489/

Is there any issue with them?

> Another thing I'd like to call out, and ask for a little help with too
> is automated testing.  The framework in test/py/test.py can be used on
> real hardware and Stephen Warren has been doing a good job having things
> run on Tegra boards.  You can see his scripts here[1].  I've setup
> locally some of my boards (some TI, RPi3, A20-OLinuXino-Lime2) and I'm
> looking at adding more still, so long as I can update U-Boot in a way
> that does not involve the console.  You can see my scripts here[2] and
> I'm cleaning things up and pushing them back up to Stephen.  But there's
> always more to do and test.  Is anyone else out there running this on
> real hardware, or would like to set this up?  Has anyone out there
> gotten this hooked up with qemu?

Did you tried tbot[1]? With it you can checkout, apply patches (directly from
your patchwork ToDo list if you want), compile, install for example U-Boot
and run tbot testcases on the hardware you have ...

I integrated test/py into tbot and use it for testing some boards
(powerpc mpc52xx, imx6, at91, am335x based boards), for example
current mainline on the at91 based board corvus here:

[2] http://xeidos.ddns.net/tests/test_db_auslesen.php#86
     http://xeidos.ddns.net/tbot/id_86/test-log.html

(I add in this testcase to the U-Boot tree I cloned, my patches from
my Patchwork ToDo list, also some local patches, if you interested in,
search for "2016-09-13 04:57:29,684" in
http://xeidos.ddns.net/tbot/id_86/tbot.txt
so if the result is green, I know all my patches in my ToDo list are clean
and work with current mainline ... :-D
(You get a pull request for them, if buildman finishs ;-)
)

May I make a testcase, which compiles a board with different toolchains ...
But as you see in [2] the current used toolchain is also documented,
also the used defconfig ... may we collect other information too...

Currently I have on some boards problems, when I release the serial
line and start test/py ... I have to look for this problem, but If
you go down in the table, there are test/py runs on other hardware too...

And you can do more with tbot, for example start a testcase, which checks,
if a kconfig move patch does not break boards, see such a result in the
commit comment:
http://patchwork.ozlabs.org/patch/668047/
(I do not post a log, because its over ~50MiB ...)

BTW: all boards I test I have not in my hands...

So "my dream" is, that everybody who have a board and want to support
automated U-Boot testing on it, he can setup a so called virtual lab,
and give us ssh access for testing, and we setup such a testserver.
As an example how this could look like, I did for my use such a setup
on a raspberry pi [3] running buildbot and tbot. I use buildbot only
for the webinterface and starting tbot.

I added to tbot an eventbackend, which fills some information while
testing into a mySQL database, and wrote a simple php script which
shows them in a table [2]. It is not perfect nor a fancy webpage, but
a good starting point.

Also if you want to use jenkins, it should be no big deal to integrate
tbot into jenkins (We only need to write a jenkins eventbackend, which
converts the tbot events into a jenkins format ...)

bye,
Heiko
[1] https://github.com/hsdenx/tbot
[3] http://xeidos.ddns.net/buildbot/tgrid

While writting this EMail, I tested for the shc, smartweb, tqm5200
and corvus board the current release .. works!
I used for the smartweb build another loglevel (console only), see
http://xeidos.ddns.net/tbot/id_89/tbot.txt
Its not so confusing then the info logs with timestamp ... but in an
errorcase every information is helpful ...

>
> As always, I know I'm missing pointing out a few things that I should
> point out and would encourage folks to chime in if there's anything they
> would like to highlight.
>
> Thanks again everyone!
>
> [1]: https://github.com/swarren/uboot-test-hooks
> [2]: https://github.com/trini/uboot-test-hooks
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [ANN] U-Boot v2016.09 is released

[Tom Rini]

On Tue, Sep 13, 2016 at 07:49:55AM +0200, Heiko Schocher wrote:
> Hello Tom,
> 
> Am 12.09.2016 um 18:21 schrieb Tom Rini:
> >Hey all,
> >
> >I've released v2016.09 and it's now live on git and FTP and ACD (along
> >with PGP sig file).
> >
> >To repeat some of the highlights from the rc releases:
> >- More DM work (MMC, of-platdata for size constrained instances, etc)
> >- Lots and lots of architecture / SoC / Platform updates: x86, rockchip,
> >   sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier
> >- mkimage cleanups
> >- More test.py updates, vboot now a testcase
> >- Secure boot work on both ARM and PowerPC.
> >- PSCI updates
> >- MAKEALL is gone, buildman is for use by all
> >- We now have xtensa support
> >- DT overlays
> >- More Kconfig migration
> >- Some NFS fixes
> >
> >Note that in some cases you may see a message like:
> >CACHE: Misaligned operation at range [xxxxxxxx,yyyyyyyy]
> >and there's good and bad news here.  What had been a debug print (and so
> >off basically) is now a regular message.  So there's no new problems,
> >just problems that are now visible and we're working on fixing.  Some of
> >these were solved during the cycle but some of them still need some more
> >discussion or just a decision being made (so, that's on me).
> 
> I had posted 2 fixes for at91 based boards:
> 
> [U-Boot] net, macb: fix misaligned cache operation warning
> http://patchwork.ozlabs.org/patch/663488/
> [U-Boot] net, cmd: fix misaligned cache operation warning
> http://patchwork.ozlabs.org/patch/663489/
> 
> Is there any issue with them?

I think I was waiting for Andreas and Joe to ack and pick them up.

> >Another thing I'd like to call out, and ask for a little help with too
> >is automated testing.  The framework in test/py/test.py can be used on
> >real hardware and Stephen Warren has been doing a good job having things
> >run on Tegra boards.  You can see his scripts here[1].  I've setup
> >locally some of my boards (some TI, RPi3, A20-OLinuXino-Lime2) and I'm
> >looking at adding more still, so long as I can update U-Boot in a way
> >that does not involve the console.  You can see my scripts here[2] and
> >I'm cleaning things up and pushing them back up to Stephen.  But there's
> >always more to do and test.  Is anyone else out there running this on
> >real hardware, or would like to set this up?  Has anyone out there
> >gotten this hooked up with qemu?
> 
> Did you tried tbot[1]? With it you can checkout, apply patches (directly from
> your patchwork ToDo list if you want), compile, install for example U-Boot
> and run tbot testcases on the hardware you have ...
> 
> I integrated test/py into tbot and use it for testing some boards
> (powerpc mpc52xx, imx6, at91, am335x based boards), for example
> current mainline on the at91 based board corvus here:
> 
> [2] http://xeidos.ddns.net/tests/test_db_auslesen.php#86
>     http://xeidos.ddns.net/tbot/id_86/test-log.html

I keep meaning to try tbot more but I haven't had a "slow" point where I
can go and rearrange my workflow (I've done a lot with Jenkins over the
years and I still have a plugin that people use out there, so it was a
quick thing for me to fire up an instance and a few jobs).

[snip]
> So "my dream" is, that everybody who have a board and want to support
> automated U-Boot testing on it, he can setup a so called virtual lab,
> and give us ssh access for testing, and we setup such a testserver.
> As an example how this could look like, I did for my use such a setup
> on a raspberry pi [3] running buildbot and tbot. I use buildbot only
> for the webinterface and starting tbot.

This is something I very strongly agree with.  I really really want it
to be easy and documented and understandable how to use our tests on
real boards at least manually.  Labs of boards testing master (or
polling my WIP branches or some to be made up branch or whatever) would
be awesome, but equally so if people can post a patch to $whatever and
can say they ran test.py and saw no regressions.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160914/00ef9985/attachment.sig>

[U-Boot] [ANN] U-Boot v2016.09 is released

[Wolfgang Denk]

Dear Tom,

In message <20160912162128.GI13192@bill-the-cat> you wrote:
> 
> I've released v2016.09 and it's now live on git and FTP and ACD (along
> with PGP sig file).

Thanks a lot.

Here the release statistics:

U-Boot 2016.09 Release Statistics

(Changes since v2016.07)

* Processed 987 csets from 129 developers
* 26 employers found
* A total of 76219 lines added, 14538 removed (delta 61681)

Developers with the most changesets
Simon Glass                172 (17.4%)
Masahiro Yamada             70 (7.1%)
Stephen Warren              37 (3.7%)
Vignesh R                   36 (3.6%)
Tom Rini                    24 (2.4%)
Ladislav Michl              24 (2.4%)
Fabio Estevam               23 (2.3%)
Mugunthan V N               22 (2.2%)
Chen-Yu Tsai                21 (2.1%)
Jaehoon Chung               21 (2.1%)
...

Developers with the most changed lines
Nobuhiro Iwamatsu         6753 (8.5%)
Simon Glass               6075 (7.6%)
Stephen Warren            5971 (7.5%)
masakazu.mochizuki.wd at hitachi.com 5036 (6.3%)
Chris Zankel              4844 (6.1%)
Hans de Goede             4539 (5.7%)
Kever Yang                3372 (4.2%)
Wenyou Yang               3297 (4.1%)
Tom Rini                  2867 (3.6%)
Max Filippov              2337 (2.9%)
...

Developers with the most lines removed
York Sun                   120 (0.8%)
Angelo Dureghello           52 (0.4%)
Siva Durga Prasad Paladugu   48 (0.3%)
karl beldan                 29 (0.2%)
Lokesh Vutla                23 (0.2%)
Breno Lima                  21 (0.1%)
Adam Ford                   12 (0.1%)
Eric Nelson                  4 (0.0%)
Chris Packham                3 (0.0%)
Jeremy Hunt                  3 (0.0%)
...

Developers with the most signoffs (total 174)
Tom Warren                  37 (21.3%)
Hans de Goede               32 (18.4%)
Xu Ziyuan                    9 (5.2%)
Michal Simek                 8 (4.6%)
Minkyu Kang                  7 (4.0%)
Stefan Roese                 7 (4.0%)
Daniel Allred                5 (2.9%)
Stephen Warren               5 (2.9%)
Nobuhiro Iwamatsu            5 (2.9%)
Karl Beldan                  4 (2.3%)
...

Developers with the most reviews (total 531)
Tom Rini                   144 (27.1%)
Simon Glass                130 (24.5%)
York Sun                    44 (8.3%)
Jagan Teki                  31 (5.8%)
Bin Meng                    29 (5.5%)
Mugunthan V N               19 (3.6%)
Fabio Estevam               18 (3.4%)
Stefan Roese                17 (3.2%)
Heiko Schocher              14 (2.6%)
Teddy Reed                  11 (2.1%)
...

Developers with the most test credits (total 29)
Tom Rini                     3 (10.3%)
Fabio Estevam                3 (10.3%)
George McCollister           3 (10.3%)
Jaehoon Chung                2 (6.9%)
Stephen Warren               2 (6.9%)
Marek Vasut                  2 (6.9%)
Lukasz Majewski              2 (6.9%)
Simon Glass                  1 (3.4%)
Stefan Roese                 1 (3.4%)
Lokesh Vutla                 1 (3.4%)
...

Developers who gave the most tested-by credits (total 29)
Tom Rini                     4 (13.8%)
Fabio Estevam                3 (10.3%)
Bin Meng                     3 (10.3%)
Jaehoon Chung                2 (6.9%)
Stefan Agner                 2 (6.9%)
Xu Ziyuan                    2 (6.9%)
Vignesh R                    2 (6.9%)
Cyrille Pitchen              2 (6.9%)
Stephen Warren               1 (3.4%)
Simon Glass                  1 (3.4%)
...

Developers with the most report credits (total 24)
Tom Rini                     3 (12.5%)
York Sun                     2 (8.3%)
Teddy Reed                   2 (8.3%)
Robert P. J. Day             2 (8.3%)
Guillaume GARDET             2 (8.3%)
Xu Ziyuan                    1 (4.2%)
Eric Nelson                  1 (4.2%)
Breno Lima                   1 (4.2%)
Masahiro Yamada              1 (4.2%)
Sandy Patterson              1 (4.2%)
...

Developers who gave the most report credits (total 24)
Simon Glass                  6 (25.0%)
Tom Rini                     3 (12.5%)
York Sun                     2 (8.3%)
Fabio Estevam                2 (8.3%)
Stephen Warren               2 (8.3%)
Alexander Graf               2 (8.3%)
Joe Hershberger              2 (8.3%)
Kevin Hao                    2 (8.3%)
Masahiro Yamada              1 (4.2%)
Daniel Schwierzeck           1 (4.2%)
...

Top changeset contributors by employer
(Unknown)                  280 (28.4%)
Google, Inc.               172 (17.4%)
NXP                        100 (10.1%)
Texas Instruments           91 (9.2%)
Socionext Inc.              70 (7.1%)
NVidia                      41 (4.2%)
Konsulko Group              24 (2.4%)
2N TELEKOMUNIKACE a.s.      24 (2.4%)
DENX Software Engineering   23 (2.3%)
Xilinx                      23 (2.3%)
...

Top lines changed by employer
(Unknown)                 25936 (32.5%)
Nobuhiro Iwamatsu         6753 (8.5%)
NVidia                    6211 (7.8%)
Google, Inc.              6075 (7.6%)
Hitachi                   5036 (6.3%)
Red Hat                   4539 (5.7%)
Atmel                     3750 (4.7%)
NXP                       3590 (4.5%)
DENX Software Engineering 3485 (4.4%)
Free Electrons            3305 (4.1%)
...

Employers with the most signoffs (total 174)
NVidia                      42 (24.1%)
Red Hat                     32 (18.4%)
(Unknown)                   19 (10.9%)
NXP                         18 (10.3%)
Texas Instruments           13 (7.5%)
Samsung                     11 (6.3%)
DENX Software Engineering    8 (4.6%)
Xilinx                       8 (4.6%)
Nobuhiro Iwamatsu            5 (2.9%)
Google, Inc.                 4 (2.3%)
...

Employers with the most hackers (total 130)
(Unknown)                   70 (53.8%)
NXP                         16 (12.3%)
Texas Instruments           10 (7.7%)
DENX Software Engineering    4 (3.1%)
NVidia                       3 (2.3%)
Xilinx                       3 (2.3%)
Atmel                        3 (2.3%)
Free Electrons               2 (1.5%)
Novell                       2 (1.5%)
Red Hat                      1 (0.8%)
...


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
There is a biblical analogy I'd like to draw here.   Casts are to C++
Programmers what the apple was to Eve.         - Scott Douglas Meyers

[U-Boot] [ANN] U-Boot v2016.09 is released

[Daniel Schwierzeck]

Hi Tom,

Am 12.09.2016 um 18:21 schrieb Tom Rini:
> 
> Another thing I'd like to call out, and ask for a little help with too
> is automated testing.  The framework in test/py/test.py can be used on
> real hardware and Stephen Warren has been doing a good job having things
> run on Tegra boards.  You can see his scripts here[1].  I've setup
> locally some of my boards (some TI, RPi3, A20-OLinuXino-Lime2) and I'm
> looking at adding more still, so long as I can update U-Boot in a way
> that does not involve the console.  You can see my scripts here[2] and
> I'm cleaning things up and pushing them back up to Stephen.  But there's
> always more to do and test.  Is anyone else out there running this on
> real hardware, or would like to set this up?  Has anyone out there
> gotten this hooked up with qemu?
> 

I have scripts for running tests on MIPS Malta in Qemu [1]. Currently
the only non-working tests are test_sleep and test_net_tftpboot on Malta
64Bit.

I think it's possible to create a generic ConsoleQemu class but I hadn't
time yet to try this.

[1] https://github.com/danielschwierzeck/u-boot-test-hooks

-- 
- Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160914/f3c02ab9/attachment.sig>

[U-Boot] [ANN] U-Boot v2016.09 is released

[Tom Rini]

On Wed, Sep 14, 2016 at 11:32:07PM +0200, Daniel Schwierzeck wrote:
> Hi Tom,
> 
> Am 12.09.2016 um 18:21 schrieb Tom Rini:
> > 
> > Another thing I'd like to call out, and ask for a little help with too
> > is automated testing.  The framework in test/py/test.py can be used on
> > real hardware and Stephen Warren has been doing a good job having things
> > run on Tegra boards.  You can see his scripts here[1].  I've setup
> > locally some of my boards (some TI, RPi3, A20-OLinuXino-Lime2) and I'm
> > looking at adding more still, so long as I can update U-Boot in a way
> > that does not involve the console.  You can see my scripts here[2] and
> > I'm cleaning things up and pushing them back up to Stephen.  But there's
> > always more to do and test.  Is anyone else out there running this on
> > real hardware, or would like to set this up?  Has anyone out there
> > gotten this hooked up with qemu?
> > 
> 
> I have scripts for running tests on MIPS Malta in Qemu [1]. Currently
> the only non-working tests are test_sleep and test_net_tftpboot on Malta
> 64Bit.
> 
> I think it's possible to create a generic ConsoleQemu class but I hadn't
> time yet to try this.
> 
> [1] https://github.com/danielschwierzeck/u-boot-test-hooks

Ah cool.  I think between that and what Michal sent me off-list throwing
together some helper scripts to fit into Stephens hook scripts should be
doable.  The only thing I'm not sure about, wrt doing a class is the
amount of flags that qemu needs (and how much they vary) compared with
sandbox.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160915/e43b995c/attachment.sig>

[U-Boot] [ANN] U-Boot v2016.09 is released

[Michal Simek]

On 15.9.2016 13:24, Tom Rini wrote:
> On Wed, Sep 14, 2016 at 11:32:07PM +0200, Daniel Schwierzeck wrote:
>> Hi Tom,
>>
>> Am 12.09.2016 um 18:21 schrieb Tom Rini:
>>>
>>> Another thing I'd like to call out, and ask for a little help with too
>>> is automated testing.  The framework in test/py/test.py can be used on
>>> real hardware and Stephen Warren has been doing a good job having things
>>> run on Tegra boards.  You can see his scripts here[1].  I've setup
>>> locally some of my boards (some TI, RPi3, A20-OLinuXino-Lime2) and I'm
>>> looking at adding more still, so long as I can update U-Boot in a way
>>> that does not involve the console.  You can see my scripts here[2] and
>>> I'm cleaning things up and pushing them back up to Stephen.  But there's
>>> always more to do and test.  Is anyone else out there running this on
>>> real hardware, or would like to set this up?  Has anyone out there
>>> gotten this hooked up with qemu?
>>>
>>
>> I have scripts for running tests on MIPS Malta in Qemu [1]. Currently
>> the only non-working tests are test_sleep and test_net_tftpboot on Malta
>> 64Bit.
>>
>> I think it's possible to create a generic ConsoleQemu class but I hadn't
>> time yet to try this.
>>
>> [1] https://github.com/danielschwierzeck/u-boot-test-hooks
> 
> Ah cool.  I think between that and what Michal sent me off-list throwing
> together some helper scripts to fit into Stephens hook scripts should be
> doable.  The only thing I'm not sure about, wrt doing a class is the
> amount of flags that qemu needs (and how much they vary) compared with
> sandbox.  Thanks!
> 

It is just the same style how to get a console out of qemu.

Some sort of integration can be good but the most problematic part
to decide what qemu version to use and if permit also out of tree qemu, etc.
But having a guidance how to do it would be good.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160916/f4d86aa5/attachment.sig>

[U-Boot] [ANN] U-Boot v2016.09.01 is released

[Tom Rini]

On Mon, Sep 12, 2016 at 12:21:28PM -0400, Tom Rini wrote:

> Hey all,
> 
> I've released v2016.09 and it's now live on git and FTP and ACD (along
> with PGP sig file).

Mistakes happen, and I'm announcing the release of v2016.09.01.  This
consists of two changes:
- Revert "image-fit: switch ENOLINK to ENOENT"
  As while I want to support OpenBSD hosts, this change broke FIT images
  as in the image checking code we care about ENOLINK and on further
  review we need to think about what to change ENOLINK to so we can be
  sure to handle the different cases here.
- Revert "Increase default of CONFIG_SYS_MALLOC_F_LEN for SPL_OF_CONTROL"
  This increase is too large and causes other problems, and we're still
  discussing things.  I wouldn't have done a release just for this
  change but since I must fix the other problem, I've included this.

As for the first problem, let this be a warning by example of relying
too much on tests without fully reading the logs rather than just
pass/fail.  We have FIT image tests, I ran the FIT image tests but they
weren't checking for success at the end of booting the image.  Now they
will (I posted that the other day).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160919/f1f4b1de/attachment.sig>

[U-Boot] [ANN] U-Boot v2016.09.01 is released

[Fabio Estevam]

On Mon, Sep 19, 2016 at 1:07 PM, Tom Rini <trini@konsulko.com> wrote:
> On Mon, Sep 12, 2016 at 12:21:28PM -0400, Tom Rini wrote:
>
>> Hey all,
>>
>> I've released v2016.09 and it's now live on git and FTP and ACD (along
>> with PGP sig file).
>
> Mistakes happen, and I'm announcing the release of v2016.09.01.  This
> consists of two changes:

Still does not appear at http://git.denx.de/?p=u-boot.git;a=shortlog

[U-Boot] [ANN] U-Boot v2016.09.01 is released

[Tom Rini]

On Mon, Sep 19, 2016 at 01:43:11PM -0300, Fabio Estevam wrote:
> On Mon, Sep 19, 2016 at 1:07 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Mon, Sep 12, 2016 at 12:21:28PM -0400, Tom Rini wrote:
> >
> >> Hey all,
> >>
> >> I've released v2016.09 and it's now live on git and FTP and ACD (along
> >> with PGP sig file).
> >
> > Mistakes happen, and I'm announcing the release of v2016.09.01.  This
> > consists of two changes:
> 
> Still does not appear at http://git.denx.de/?p=u-boot.git;a=shortlog

I've poked Wolfgang about why these aren't migrating over to the public
git side, but they are available on the github mirror.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160919/c194e912/attachment.sig>

[U-Boot] [ANN] U-Boot v2016.09.01 is released

[Fabio Estevam]

On Mon, Sep 19, 2016 at 2:01 PM, Tom Rini <trini@konsulko.com> wrote:

> I've poked Wolfgang about why these aren't migrating over to the public
> git side, but they are available on the github mirror.

Wolfgang?