[U-Boot] [ANN] U-Boot v2016.09 is released
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
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
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... [3] - https://github.com/lmajewski/HWT_io_ctl [4] - https://www.amazon.com/JBtek-Channel-Module-Arduino-Raspberry/dp/B00KTEN3TM/...
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!
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!
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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.
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@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
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
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.
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!
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.
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
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).
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
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.
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?
participants (7)
-
Daniel Schwierzeck -
Fabio Estevam -
Heiko Schocher -
Lukasz Majewski -
Michal Simek -
Tom Rini -
Wolfgang Denk