From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH 0/8] Assorted fixes References: <20200131152713.1811748-1-rpm@xenomai.org> <0c811fd4-dc46-0bce-99b3-64c150725d3d@siemens.com> <230535ea0245408dbd941bc26c4f6df9@intel.com> <20200201112301.5d3146d9@md1za8fc.ad001.siemens.net> <4c3daf5ff92549a3a751b8332a0b612d@intel.com> From: Jan Kiszka Message-ID: <49bc9b58-f7ed-a455-3eac-0284ee2f6339@siemens.com> Date: Mon, 3 Feb 2020 08:00:12 +0100 MIME-Version: 1.0 In-Reply-To: <4c3daf5ff92549a3a751b8332a0b612d@intel.com> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Meng, Fino" , "xenomai@xenomai.org" On 01.02.20 12:35, Meng, Fino via Xenomai wrote: > Thanks Jan & Henning, got some ideas. > In 2020 our team's focus is modify UEFI BIOS for real time capability; > Most of OEM's industry PC cannot reach good worst case jitter using out of box BIOS, these items needed by PnP configs are hidden; > We want to push BIOS vendors and OEMs do real-time, deterministic, predictable BIOS, for Industry PC. That would be highly appreciated from a Xenomai perspective! I know that not all IPC vendors so far invests in making their BIOS RT-ready. And Xenomai would possibly be able to overcome in such boxes the nasty "turn off all NMI sources" hack (where it works at all). I hope your changes also find their way into OSS firmware, like Coreboot (which is of strategic importance here). Jan > > BR / Fino (孟祥夫) > Intel – IOTG Developer Enabling > > -----Original Message----- > From: Xenomai On Behalf Of Henning Schild via Xenomai > Sent: Saturday, February 1, 2020 6:23 PM > To: Greg Gallagher via Xenomai > Subject: Re: [PATCH 0/8] Assorted fixes > > Am Fri, 31 Jan 2020 14:20:33 -0500 > schrieb Greg Gallagher via Xenomai : > >> HI, >> >> >> On Fri, Jan 31, 2020 at 12:53 PM Jan Kiszka via Xenomai >> wrote: >>> >>> Hi Fino, >>> >>> On 31.01.20 17:25, Meng, Fino wrote: >>>> Hi Jan >>>> >>>> Regarding to torture tests, do we have a recommend test suite & >>>> working flow from the community? I searched xenomai wiki but >>>> didn't find a guide for this. >>> >>> Out testing leaves a bit of room for improvement, but it is getting >>> better. What we have so far is the smokey testsuite which is part of >>> many of our test runs. It has some shortcomings, e.g. unstructured >>> reporting, but it is at least a baseline. There are some further >>> tests, like switchtest, that are also included when running >>> xeno-test. And then there are loose ends like lib/*/testsuite that >>> should probably be hooked up. >> Is there anything on the wiki with what tests are needed or what area >> we need to focus on for unit tests? >> >>> >>>> We plan to recommend UP Extreme board >>>> (https://up-board.org/up-xtreme/) to public users since it's easy >>>> to buy for anyone And we want to write a guide for torture test, >>>> at least for these boards, >>> >>> Defining reference boards is indeed another topic. I think we >>> started that at some point on the list, but it did not go very far. >>> >> >> IMHO, based on what people on the list are posting as boards being >> used, beaglebone black or similar variant, raspberry-pi 2b or >> Zynq-7000 would be good choices for arm boards. Raspberry pi 3 and >> possibly Ultra96 for the ARM64 variants? I have these boards on hand >> and would help out with testing as I can. >>> >>> On x86, the situation is rather comfortable as the reference image >>> we produce with xenomai-images works well on many boards and larger >>> systems. I don't have an UP board around but many products that have >>> at least similar SoCs. We once played with a Minnow board but that >>> was, well, not recommendable. The UP Xtreme could be another option. >> >>> The next level is then automated execution of tests. There are many >>> ways, the one we are preparing so far is LAVA-based. Quirin started >>> that in >>> https://code.siemens.com/ebsy/debian/xenomai-images/tree/master/tests. >>> He is busy the next weeks but he wants to follow-up on that with >>> more details afterwards so that we can discuss in the community if >>> that could become an official pattern for Xenomai. >>> >> I like the idea of Lava, would there be extra hardware needed if >> someone wanted to create the test setup at home? >> I can't access the link above, is it possible to open that link up to >> the public? > > Quickly enabling people to build their own lab is a clear goal. > Community labs could be hooked into the central CI-CD-CT, so an upstream commit could eventually trigger a test+report in all maintainers labs wherever those may be. > But in fact private labs would be the prime target. > > Your lab setup will need a machine being able to run docker or you need to install lava yourself. You will want power-sockets that can be switched from that box. Serial connections to the target(s), maybe > dhcp+pxe+nfs, remote flashers, USB-mass-storage gadget ... > Ideally you want targets that support fully automatic CD. So full network boot or boot from USB or boot from a flash that you can write from the outside, no SDCards and other manual steps. > > ARM targets that have a bootloader which supports dhcp/tftp are well understood and easy to hook in. > > Henning > >>> Any comments, suggestions in this area are of course welcome! >>> >>> Thanks, >>> Jan >>> >>> -- >>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate >>> Competence Center Embedded Linux >>> >> > > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux