Skip to contentSkip to conversation

U-Boot v2016.09 is released

U-Boot Tom Rini 7 participants 13 messages Sep 12, 2016 – Sep 20, 2016

lore
Share & tools
lore

Tom Rini

author
#0 lore raw

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

Signature · 8 lines
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>
#1 lore raw

Hi Tom,

2016-09-12 18:21 GMT+02:00 Tom Rini <[email protected]>:

Quoted 27 lines

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

Quoted 12 lines

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

Signature · 5 lines
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
#2 lore raw
In reply to Tom Rini

Hi Tom,

Quoted 28 lines

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

Quoted 11 lines

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.

Quoted 10 lines

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

Signature · 12 lines
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>
#3 lore raw
In reply to Tom Rini

Hello Tom,

Am 12.09.2016 um 18:21 schrieb Tom Rini:

Quoted 19 lines

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

Quoted 7 lines

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?

Quoted 11 lines

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

Quoted 17 lines

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

Signature · 2 lines
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
author
#4 lore raw
Quoted 30 lines · Heiko Schocher

Hello Tom,

Am 12.09.2016 um 18:21 schrieb Tom Rini:

Quoted 19 lines

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

Quoted 7 lines

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

Quoted 8 lines

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.

Quoted 16 lines
Quoted 11 lines

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

Quoted 6 lines

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]

Quoted 6 lines

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.

Signature · 8 lines
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>
#5 lore raw
In reply to Tom Rini

Dear Tom,

Quoted 3 lines · 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

Signature · 5 lines
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
#6 lore raw
In reply to Tom Rini

Hi Tom,

Am 12.09.2016 um 18:21 schrieb Tom Rini:

Quoted 13 lines

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

Signature · 9 lines
- 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>
author
#7 lore raw
Quoted 17 lines · Daniel Schwierzeck

Hi Tom,

Am 12.09.2016 um 18:21 schrieb Tom Rini:

Quoted 13 lines

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?

Quoted 8 lines

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!

Signature · 8 lines
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>
#8 lore raw
Quoted 25 lines · Tom Rini
Quoted 24 lines · Daniel Schwierzeck

Hi Tom,

Am 12.09.2016 um 18:21 schrieb Tom Rini:

Quoted 13 lines

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.

Quoted 8 lines
Quoted 1 line

[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

Signature · 14 lines
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>
author
#9 lore raw

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

In reply to Tom Rini
Quoted 4 lines · 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).

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

Signature · 8 lines
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>
#10 lore raw

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

Quoted 9 lines · Tom Rini
Quoted 4 lines · 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).

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

author
#11 lore raw

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

Quoted 5 lines · Fabio Estevam
Quoted 4 lines · Tom Rini
Quoted 2 lines · Tom Rini

Hey all,

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

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.

Signature · 8 lines
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>
#12 lore raw

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

Quoted 2 lines · Tom Rini

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?