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

[Heiko Schocher <hs@denx.de>]

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