Hi,

Please can you let us know the number of gates in the following IC

45-000018-R6    PCIe x1 2.5GT/s 1000Base-T GbE Controller -40-85C           Intel       WGI210ITSLJXS               Integrated Circuit             Digital, CMOS

Best regards

Javed

Codemotion is the ecosystem devoted to innovation, focused on developers and coding. Pioneering spirits, we scout the future to deliver a first class experience to our people.  Get involved in Codemotion, join Codemotion People. Discover Codemotionworld. Let’s code the future.       

Codemotion is the biggest tech conference in Italy and one of the most important in Europe, with a network of more than 30k developers

This is an Intel sponsored event

Register here

La série Intel® Buzz Workshop est de retour suite au succès de son édition mondiale 2014. Et pour sa 3e étape en Europe, elle pose enfin ses manettes à Paris le mardi 24 novembre.

Rejoignez-nous pour cet évènement Intel® qui a pour ambition de rassembler à chaque workshop des professionnels du monde du jeu vidéo pour qu’ils puissent échanger entre eux sur les challenges les plus importants du secteur.

Tout au long de la journée, vous pourrez assister à des conférences, des panels, des ateliers techniques et vous aurez peut être même la chance de présenter le jeu que vous avez créé lors du Développeur Showcase.

Les places sont limitées ! Inscrivez-vous dès maintenant pour réserver votre siège et vous garantir de découvrir toutes les dernières tendances dans le gaming. Ce sera aussi l’occasion de boire un verre en notre compagnie !

Si vous souhaitez présenter votre jeu lors du Développeur Showcase, merci de remplir ce formulaire.

Huit jeux seront sélectionnés et présentés lors de l’événement. Le gagnant remportera un Gigabyte Brix Pro GB-BXi7-4770R !

Le site officiel de l’événement :http://intelbuzz.bemyapp.com/paris/

Le programme complet de la journée sera annoncé très prochainement

Et pour vous faire une idée de ce à quoi la journée ressemblera, vous pouvez regarder cette vidéo tournée lors des Workshops de 2014, cliquez ici.

Register here

Everybody is talking about the Internet of Things (IoT).However,the IoT paradigm comprises of a diverse array of vertical markets and is not a homogenous entity. Take the Industrial Internet of Things (IIoT) for instance.Known to some people, particularly in Europe, as Industry 4.0,such technology often finds a home in the Smart Building or Smart Factory.

The drive behind IIoTcomes from the notion of connecting machines to the cloud and adding intelligence to them, a concept that is easier said than done. Machinesdon't necessarily talk in the language of networks and the cloud.Moreover, the number of network types and protocols operating in an industrial automation environment is steadily rising,so there is a growing need to bridge the gap between the industrial and IT networking domains. That bridge is typically handled with an IoT gateway.

A developer needs to look no further than theIntel® Internet of Things Solutions Alliance for help. One Associate member of the Alliance aiming to bring industrial automation into the IoT arena is AAEON, the industrial and embedded computing subsidiary of ASUS, a large-scalemanufacturer of PCs, tablets, and mobile phones based in Taipei, Taiwan. AAEONspecializes in the design and manufacture of industrial PC (IPC) products, such as industrial motherboards, embedded CPU boards, panel computers, and industrial box computers. Such products are quite suited to Smart Building/Factory applications.

AAEON is leveraging the Intel^®IoT Gateway reference designwhich includes technology from McAfee and Alliance membersWind River. This design is helping AAEON expand connectivity, improve interoperability, and shorten time to market for developers looking to transform business and operations.

AAEON, which recently joined hands with HMS Networks AB, a supplier of communications solutions for industrial automation, is now offering end-to-end IoT solutions that exchange data between "things" and the cloud—hence the need for a gateway as the IIoT bridge. AAEON’s gateway solutions offerIntel® Quark™ SoCs and Intel® Atom™ processors, Wind River Intelligent Device Platform XT* 3,Linux*,and McAfee*Embedded Control security technologies.

The solution targets the Smart Building/Factory,whichwould require a programmable logic controller (PLC) for industrial electromechanical processes, in addition to the industrial I/O modules for multiple arrangements of digital and analog inputs and outputs, and a gateway to pass the information back and forth between the server and end-devices (Figure 1).AAEON's AIOT-DRM isan Intel Quark SoC-based IoT gateway that can function as an industrial I/Omodule. When paired with a PLC, it reduces the overall solution's cost, size and weight, while enabling cloud connectivity and greater flexibility.

Figure 1. The AAEON gatewayforms the bridge required in an Industrial IoT platform.

The steppyramid-shapedgateway is comprised of abase PC board, CPU board, and industrial I/O board, each stacked atop one another from the top to bottom, respectively.The top level of the AIOT-DRM system provides Internet access and expansion capabilities; computation in the middle; and analog-to-digital conversion at the bottom.

This IoT gateway takes data from sensors, video cameras and RFID tags via multiple sources like Wi-Fi and ZigBee and dispatches the data to a server. In the Smart Building/Factory example, it allows those responsible for building management to monitor the data with a tablet or a mobile phone via a gateway link to the cloud.

Embedded computing solution providers like AAEON focuses more on the x86 ecosystem compared to ARM as it is less fragmented and offers greater space for differentiation. Basing the solution on the Intel IoT Gateway design, whichincludes an embedded OS and security software stacks, allows firms like AAEON to offer application-ready embedded platforms. An SDK supplied by AAEON simplifies the access capability needed by third-party software to control or access the IoT gateway and sensors.

Gateway solutions for other IoT applications are also available from AAEON. For example, the AIOT-X1000 subcompact board—powered by theIntel® Quark™SoC X1000 series—integrates rich communication interfaces such as RS-485 and analog and digital I/Os. The motherboard provides the basic building blocks for IoT gateways like AIOT-QA for retail and banking applications, and additional customization and support for industrial communication protocols like EtherCAT, ProfiNET, ModBus, and more (Figure 2).

Figure 2. AAEON offers one-stop shopping for IoT gateway solutions.

AAEON providesIoT solutions combining hardware and software for the specific vertical markets it serves. The Intel IoT Gateway designthat AAEON has adopted provides an integrated software platform and OS board support package (BSP) to support the operation of the gateway. Moreover, the company works closely with system integrators and installer to ensure that it provides validated IoT solutions with actual IoT system integration track records.

See our Solutions Directory for more products from AAEON.

AAEON is an Associate member of the Intel® Internet of Things Solutions Alliance.

Richard Nass

OpenSystems Media by special arrangement with the Intel® Internet of Things Solutions Alliance.

The Internet of Things (IoT) is a paradox. The potential is huge, but the challenges can be daunting. Take the industrial automation facet of the IoT—also known as the Industrial IoT, or IIoT—which is currently quite fragmented amid interoperability issues, thereby making it difficult to demonstrate true value and ROI.

The task of connecting devices and systems with potentially incompatible protocols and fieldbus technologies can be a daunting challenge. Once completed, the next uphill task is securing dependable transmission of collected data and functionality in harsh and demanding industrial environments. Moreover, it's imperative to intelligently forecast machine failure to minimize downtime and revenue loss.

By leveraging Intel® IoT Gateway designs that include technology from McAfee and Intel® Internet ofThings Solutions Alliance member Wind River, technology partners can expand the connectivity, improve the interoperability, and shorten time to market for developers looking to transform their IIoT business and operations. For example, ADLINK Technology, a maker of embedded computing devices, designs and manufactures intelligent IoT gateways that address the above challenges. The Taipei, Taiwan–based company is a Premier member of the Alliance. Its MXE 100iand MXE 200i gateways connect with disparate things and the cloud to collect data for analysis and insight (Figure 1). To do this, these smart gateways provide legacy I/O options for fieldbus and other industry protocols. They then use IP-based protocols to connect to the cloud through wired, WiFi, or cellular networks.

Figure 1. A host of vertical industrial applications can be satisfied using an Internet/Cloud architecture.

The IoT gateways facilitate the configuration of sensors and I/O nodes (Figure 2). Furthermore, the Event Execution Engine in ADLINK EdgePro allows remote monitoring of status and actuator control with RESTFul web-service APIs. Simple configuration of reliable and secure connectivity with Amazon and Microsoft Azure clouds round out the offering.

Figure 2. Diagram showing an end-to-end IoT gateway solution.

The next link in the chain is Wind River'sHelix Device Cloud agent, which provides cloud connectivity to facilitate device configuration, file transfers, data capture, and rules-based data analysis and response. The edge-to-cloud M2M communication between devices or between the gateway and server nodes integrates a massive collection of linked elements while empowering remote data analysis.

Smart gateways secure data in harsh industrial environments by using pre-integrated and pre-validated McAfee* Embedded Control security technology (Figure 3). The software uses application whitelisting to avoid running unauthorized code and enables change control functionality by allowing only authorized changes. This ensures secure data transmission and connection to the cloud.

Figure 3. Pre-integrated, pre-validated software stacks are an integral part of the Intel IoT Gateway design.

Let's take machine-failure prediction as a design example. It's a relevant and important example because one of the biggest industrial constraints is unplanned downtime that subsequently leads to repair, maintenance, and manpower costs. Factory environments often have demanding physical conditions, and effective prevention comes with implementing the machine-condition monitoring solution for failure prediction usages.

As a key component in a factory environment, ADLink's MXE 200i is a rugged, fanless gateway with an extended temperature range and with ADLINK USB-2405 USBDAQ that collects data that's subsequently used for predictive maintenance and downtime alerts. It boasts a DAQ function for data collection with real-time machine behavior and creates models to trigger alerts for potential machine failure. That, in turn, enables remote monitoring, management, system health diagnostics, and tailor-made machine status to meet the failure prediction and carry out system recovery (Figure 4).

Figure 4. ADLINK’s application-ready IoT gateway is suited for industrial applications.

Designed to facilitate a variety of edge nodes in industrial networks, particularly those connecting business intranets with the cloud, the MXE 100i embedded computing platform is based on the Intel® Quark™ SoC X1021 which features rich I/O capabilities. A key feature of the Quark X1021 embedded processor is its ability to collect data to facilitate predictive maintenance and downtime alerts.

The MXE 200i IoT gateways are based on the Intel® Atom™ processor E3826 which features a 1.46-GHz dual-core CPU and a maximum operating temperature of 85°C.

Both the MXE 100i and MXE 200i come pre-loaded with Wind River's Intelligent Device Platform XT software and McAfee's Embedded Control security software as part of the Intel® IoT Gateway reference design they employ. ADLINK includes its embedded SEMA cloud utility, plus offers its EdgePro software utility for device and sensor management on the other side of the value chain, if desired. The MXE 100i and MXE 200i IoT gateways run on popular embedded operating systems and architectures; moreover, they feature an interface to ERP and firmware update downloads, as well as ADLink's Smart Embedded Management Agent (SEMA) cloud.

See the Solutions Directory for more products from ADLINK.

ADLINK is a Premier member of the Intel® Internet of Things Solutions Alliance.

Richard Nass

OpenSystems Media by special arrangement with the Intel® Internet of Things Solutions Alliance.

Hello,

       I would like to understand if there are any drivers or libraries being released for the Bay Trail-I's SIO PWM controller for Windows 8 OS (64 and 32 bits).

       Currently the only drivers I am able to find for the Bay Tail-I SIO ports are HSUART, GPIO, I2C & SPI.

       Any help or pointer is appreciated.

       Thank you.

Regards,

Tai

Hi Folks,

I've designed and built and embedded solution using the NM10 and N2600 (CedarTrail) chipset. My end customer has now asked for a full MTBF for the Design.

Firstly do Intel have MTTF / FIT data for their parts?

I was just hoping for transistor counts etc as many processor vendors supply these as they show a compliance with Mores Law, but I cant find that data for both the NM10 and N2600.

Does anyone know where this data is available?

Many thanks.

hi i'm new to this community
i wanna know how to get best use of this great community in intel

i mean what to do here

Although white box server models bring economies of scale, a one-size-fits-all approach reaches its limits with multiple 40GbE and 100GbE ports caused by fundamental compute and I/O bandwidth constraints. Advantech demonstrates how its new platforms offer the flexibility and performance needed for 100Gbps packet processing in next generation networks.

For more information: Download a full product brief here: http://www2.advantech.com.tw/nc/newsletter/NCG/DOC/Ultra-high-end-network-appliance.pdf

or visit our website: http://www2.advantech.com.tw/networks-telecom/

Video - Accelerating Network Platform Evolution

Axiomtek is pleased to announce that we will be showcasing our latest developments in automation technology at the SPS Drives Exhibition in Nuremberg, Germany from November 24-26 2015!

Please stop by our booth in Hall 8, Stand #502 to have a look at Axiomtek’s most noteworthy technological advances in electric automation.  Our booth will showcase a variety of sleek touch panel computers, robust embedded systems, and powerful single board computers and SoMs.

Stay updated on the latest trends, achievements, and innovations for the industrial cloud at Europe’s largest and most successful electric automation exhibit. You do not want to miss this event!

Fanless Embedded System eBOX626-853-FL: Built-in Intel® Celeron® processor N3150 1.6GHz

Suports VGA/HDMI, 4 COM ports, 2 GbE ports, 4 USB ports, 2 Mini PCIe slots and 9 ~34VDC wide range input

https://www.youtube.com/watch?v=PwoymT-sJUg

The recent SDN & OpenFlow World Congress in Dusseldorf attracted a fascinating mix of attendees. On one side were long-time veterans of the telecom industry exploring the opportunities that virtualization is bringing to service provider networks. On the other side were IT and cloud experts working on the challenges of extending their infrastructure to support telecom services.

The topic bringing these two groups together, of course, is Network Functions Virtualization (NFV). The promise of NFV is that a combination of virtualization and “cloudification” will enable service providers both to reduce their OPEX through improved network efficiency and to improve their top-line revenue through the agile delivery of new, value-added services. In order to successfully achieve this goal, IT teams and networking teams are going to have to work together in unprecedented ways. Each group approaches the challenges from a different perspective and with a different set of experiences.

One area that causes a lot of confusion and misunderstanding for folks with a background in IT and cloud infrastructure is the whole topic of “Carrier Grade” reliability for telecom services. More and more vendors are starting to use Carrier Grade terminology in connection with their products, but the requirements and challenges of Carrier Grade reliability are very different from what many of people have had to deal with before, while the telecom industry of course brings its own alphabet soup of confusing acronyms and terminology.

In this post, we’ll outline some of the myths about Carrier Grade that we often encounter when we’re demonstrating NFV solutions to conference attendees whose main focus until now has been on enterprise-type applications.

Myth #1: Carrier Grade reliability has no direct impact on service provider revenues

In 2014, Heavy Reading published a detailed analysis titled “Mobile Network Outages & Service Degradations” that discussed the business impact of network outages. The report calculated that during the twelve months ending October 2013 service providers worldwide lost approximately $15B in revenue through such outages, representing between 1% and 5% of their total revenues. All major service providers were affected.

There are several sources of this lost revenue. First, there’s the increased rate of subscriber churn (dissatisfied customers take their business elsewhere). Second, there are the operational expenses incurred to fix the problems. Third, service providers lose the ability to capture revenue from a billable service if it’s unavailable. Fourth, future revenues are impacted due to damage to brand reputation. Fifth, refunds must be paid to enterprise customers with Service Level Agreements (SLAs) that guarantee a certain level of uptime. And finally there are inevitably legal costs relating to SLA issues.

It’s important to note that this analysis relates to a 12-month period ending in 2013, when service providers’ infrastructure was completely based on physical equipment, typically with high reliability proven over many years’ deployments and before any adoption of network virtualization.

NFV has the potential to make this situation much worse: services and applications will now be virtualized; they will be new and unproven; VMs will be dynamically reallocated across servers, racks and even data centers; traffic flows will be more complex and hard to debug; solutions will inevitably be multi-vendor rather than from a single supplier.

As they progressively adopt NFV, it’s a business imperative for service providers to maintain Carrier Grade reliability for their critical services and high-value customers. Otherwise their overall uptime will decrease, further impacting their revenues and negating one of the key reasons (top-line growth) for moving to NFV in the first place.

Myth #2: Carrier Grade reliability is a stand-alone “feature” that you can add to your infrastructure

It’s extremely difficult to develop network infrastructure that delivers Carrier Grade reliability. Multiple, complex technologies are needed in order to guarantee six-nines (99.9999%) reliability at the infrastructure level so that services can achieve five-nines uptime.

Looking first at what it takes to guarantee network availability for virtualized applications, an optimized hypervisor is required that minimizes the duration of outages during the live migration of Virtual Machines (VMs). The standard implementation of KVM, for example, doesn’t provide the response time that’s required to minimize downtime during orchestration operations for power management, software upgrades, or reliability spare reconfiguration. In order to respond to failures of physical or virtual elements within the platform, the management software must be able to detect failed controllers, hosts or VMs very quickly launch self-healing actions, so that service impact is minimized or eliminated when failovers occur. The system must automatically act to recover failed components and to restore sparing capability if that has been degraded. To do this, the platform must provide a full range of Carrier Grade availability APIs (shutdown notification, VM monitoring, live migration deferral, etc.), compatible with the needs of the OSS, orchestrator and VNFs. The software design must ensure there is no single point of failure that can bring down a network component, nor any “silent” VM failures that can go undetected.

Second, network security requirements present major challenges. Carrier Grade security can’t be implemented as a collection of bolt-on enhancements to enterprise-class software, rather it must be designed-in from the start as a set of coordinated, fully-embedded features. These features include: full protection for the program store and hypervisor; AAA (Authentication, Authorization and Accounting) security for the configuration and control point; rate limiting, overload and Denial-of-Service (DoS) protection to secure critical network and inter-VM connectivity; encryption and localization of tenant data; secure, isolated VM networks; secure password management and the prevention of OpenStack component spoofing.

Third, a Carrier Grade network has stringent performance requirements, in terms of both throughput and latency. The host virtual switch (vSwitch) must deliver high bandwidth to the guest VMs over secure tunnels. At the same time, the processor resources used by the vSwitch must be minimized, because service providers derive revenue from resources used to run services and applications, not those consumed by switching. The data plane processing functions running in the VMs must be accelerated to maximize the revenue-generating payload per Watt. In terms of latency constraints, the platform must ensure a deterministic interrupt latency of 10µs or less, in order for virtualization to be feasible for the most demanding CPE and access functions, such as C-RAN. Finally, live migration of VMs must occur with an outage time less than 200ms, using a “share nothing” model in which all a subscriber’s data and state are transferred as part of the migration. The “share nothing” model, used in preference to the shared storage model in enterprise software, ensures that legacy applications are fully supported without needing to be rewritten for deployment in NFV.

Finally, key capabilities must be provided for network management. To eliminate the need for planned maintenance downtime windows, the system must support hitless software upgrades and hitless patches. The backup and recovery system must be fully integrated with the platform software. And support must be implemented for “Northbound” APIs that interface the infrastructure platform to the OSS/BSS and NFV orchestrator, including SNMP, Netconf, XML, REST APIs, OpenStack plug-ins and ACPI.

You can’t achieve these challenging requirements by starting from enterprise-class software that was originally developed for IT applications. This type of software usually achieves three-nines (99.9%) reliability, equivalent to a downtime of almost nine hours per year.

Myth #3: Carrier Grade reliability can be implemented in the network applications themselves

There’s been a lot of industry discussion recently about Application-Level High Availability (HA). This concept places the burden of ensuring service-level reliability on the applications themselves, which in an NFV implementation are the VNFs. If it’s achievable, it’s an attractive idea because it means that the underlying NFV Infrastructure (NFVI) could be based on a simple open-source or enterprise-grade platform.

Even though such platforms, designed for IT applications, typically only achieve three-nines reliability, that would be acceptable if the applications themselves could recover from any potential platform failures, power disruptions, network attacks, link failures etc. while also maintaining their operation during server maintenance events.

Unfortunately, Application-Level HA by itself doesn’t achieve these goals. No matter which of the standard HA configurations you choose (Active / Standby, Active / Active, N-Way Active with load balancing), it won’t be sufficient to ensure Carrier Grade reliability at the platform level.

In order to ensure five-nines availability for services delivered in an NFV implementation, you need a system that guarantees six-nines uptime at the platform level, so that the platform can detect and recover from failures quickly enough to maintain operation of the services. This implies that the platform needs to deal with a wide range of disruptive events which cannot be addressed by the applications because they don’t have the right level of system awareness or platform management capability.

For anyone involved in architecting, developing or deploying any part of an end-to-end NFV solution, this new white paper “NFV: The Myth of Application Level HA” is required reading. It provides a detailed technical analysis of the tradeoffs between Application-Level HA and Carrier Grade platforms and gives a clear direction to follow.

Myth #4: Carrier Grade reliability is something you get from the OPNFV project

Formally launched in September 2014, the Open Platform for NFV (OPNFV) project is an open source reference platform intended to accelerate the introduction of NFV solutions and services. OPNFV operates under the Linux Foundation and the primary goal of the project is to implement the ETSI specification for NFV.

Several service providers have been quoted publicly as confirming that they see the OPNFV reference platform as a way to accelerate the transition from the standards established by ETSI to actual NFV deployments. Of course they recognize that OPNFV code can’t be directly deployed into live networks, anticipating that software companies will use OPNFV as the baseline for commercial solutions with full SLA support.

OPNFV’s initial focus is NFV Infrastructure (NFVI) and Virtualized Infrastructure Management (VIM) software, implemented by integrating components from upstream projects such as OpenDaylight, OpenStack, Ceph Storage, KVM, Open vSwitch and Linux. Along with application programmable interfaces (APIs) to other NFV elements, these NFVI and VIM components form the basic infrastructure required for hosting VNFs and interfacing to Management and Network Orchestration (MANO).

The first OPNFV release “Arno” became available in June 2015. Arno is a developer-focused release that includes the NFVI and VIM components. The combination offers the ability to deploy and connect VNFs in a cloud architecture based on OpenStack and OpenDaylight. The next release “Brahmaputra” is planned as the first “lab-ready” release, incorporating numerous enhancements in areas such as installation, installable artifacts, continuous integration, improved documentation and sample test scenarios.

Neither Arno nor Brahmaputra, however, incorporates any features that contribute to delivering Carrier Grade reliability in the NFVI platform. This is an example of an area where companies with proven experience in delivering six-nines infrastructure will continue to add critical value.

Solutions such as Wind River’s Titanium Server build on community-driven reference code and enhance it with functionality that is an absolute requirement for platforms deployed in live service provider networks, while remaining fully compatible with all the applicable open standards.

At SDN & OpenFlow World Congress, we enjoyed exploring these topics with attendees who stopped by our booth to see a comprehensive demonstration of a proven Carrier Grade NFV cloud solution that’s already been selected by multiple customers. The folks whose background was primarily in IT or cloud applications quickly developed a whole new appreciation for the complexities associated with guaranteeing the level of reliability that’s an absolute requirement in the world of telecom.

If you missed us in Dusseldorf, or simply want to learn more about how we deliver NFVI with the performance and uptime that service providers require, visit our Titanium Server website.

Hello

I need to get 6Gbps storage speed for SSD disks on my Skylake-U motherboard which is under development.

The situation is: I capture 6Gbps video (4K 60 fps) stream from 2x3G-SDI inputs and then I need to store it to disk for processing at the next time. Generally, there is no serious problem in case if I use same motherboard for read and write operations: use two SATA 3.0 SSDs with activated RAID0 option in H110 PCH and the task is solved.

The problem arrives if I need to read stored data from these 2 SSDs, but on another computer, because disk configuration on another computer can be any, for example, it can happens that there is no RAID support on this motherboard. Additional, another computer has its own disk and wrong RAID configuration can damage data on it.

I plan is to solve this problem by one of two ways:

     1. Use Thunderbolt controller chip (for example, Intel DSL5110) on my motherboard and use this Thunderbolt storage:

     http://www.g-technology.com/products/g-speed-studio-xl-thunderbolt-ev-series-bay-adapters

     Simple, ready-to-use, but quite expensive decision. And another computer should have Thunderbolt interface, too.

     2. Configure storage subsystem on my motherboard as RAID and use RAID controller card for PC (unfortunately, it cannot be used with notebooks).

Relatively cheap (I need only mass production RAID PCIe card), but it requires motherboard that supports RAID option

I have two questions to make decision which option I will use:

     1. On Intel site I can’t get access to Intel’s Thunderbolt controller’ documentation; only thing I know is that they are exist:

     http://ark.intel.com/products/series/67021/Thunderbolt-Controllers

     Can I get access to it?

     2. I hope but I don’t know if I use H110 PCH with RAID0 option for write operation and Intel RAID controller card for read operation, data will be read correct. Is there any document that could clear up this speculation? All      I have now is only Slylake-U PCH documentation

Thank you for advance,

Nikolay

Hi,

I recently got this product km2m806-02 from @Kontron :

What do you know about km2m806-02 Kontron IoT P... | element14

It's based on FRI2 Intel platform which was supported by Yocto project :

https://www.yoctoproject.org/product/fish-river-island-2-board

Can you share current status on fido (meta-intel's generic_x86) ?

I booted a couple of images and even tried debian-8 it boots

I  also gave hints on ELinux wiki for Community :

FRI - eLinux.org

I'll may ask also about GMA500 and other components,

Until you also reach users in this place :

https://www.reddit.com/r/IOT/comments/3rsgyd/just_got_a_kontron_m2m_smart_services_developer/

Or check random notes at :

http://rzr.online.fr/q/m2m

Regards

Edit:

Any yocto-project developers out there ?

It seems that EMGD in this device is retired now ... so we will have to use gma500_gfx as fallback driver ;( ...

http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/common/recipes-graphics/xorg-driver?h=fido&id=c939705c186388df1eb68341a207fb2c6ac95f66

{

Remove all the changes related to the proprietary EMGD graphics driver

As all the EMGD based BSPs have been retired, there is no need for the proprietary EMGD support in the meta-intel layer.

}

Anyway I plan to use it headless and focus on modem support...

Hello!

I’m looking to develop using high-volume, price-sensitive (<$70) Android tablets for a specific application. I’m currently evaluating various options, including those using Intel processors, and I would like to know what the process is to build custom Android ROMs using Intel Atom (x3-C3130’s). I do not plan on developing the hardware from scratch at this point (repurposed Android tablets from Alibaba are preferred), but security is still a concern for this project. So far I’ve tried Allwinner A33 boards and have disliked its closed-source/badly documented/black-boxed process. If I had, for example, a Teclast X70 or a similar Intel reference tablet, how much leeway would I have developing for it? Would this depend on the motherboard and OEM?

If there's a better forum for this than Embedded, let me know, but I'm still hoping someone can point me to specific resources.

Thanks!

Clinton

Hi everyone,

Is there any code example of how to access and configure the SDP on the i210 (or any other variant)? I want to update the kernel driver to make special behavior over the SDP.

I have four i210 and I want to update the time on them simultaneously. Which can never be done by the software by itself. I want to update the time on on of the i210 and cause to trigger and SDP to update the time on .

Thank you all

Bassam,

I have 4 i210 device on one board. I want to make sure that the four of them has the exact timer offset (will be used in 1588 setup).

Because they may have different initialization time they may end up with different time offset. I want to use the SDP at boot time to set the four of then on the same time offset.

Thank you

Bassam,

We have server system using I210 as share network for both PCH chipset and BMC.

When OS windows disable network device manually on windows, the network activity for BMC will also be disabled.

The correct behavior should be BMC be able re-initialize I210 after disable to get the network back. 

However, as describe below some unexpected behavior caused the network issue.

Description:

When host OS is windows and user disabled network device, NCSI(I210) will keep send "Link Status Change" AEN to BMC per second.

It'll make BMC keep to reset and enable NCSI cause network could not used.

Test Environment:

Verified OS : windows7, windows 8.1 and windows 10.

Verified Driver : 18.4, 18.5, 18.6, 18.7, 18.8.1, 19.0, 19.1, 19.3, 19.5, 20.0 and 20.2

Test case:

[1] Initialize and Boot BMC

[2] Disabled network device in windows.

Result:

NCSI still send AEN "Link Status Change 0x60" when windows diabled device then send AEN "Link Status Change 0x6b" and BMC reset and enable NCSI will failed.

Even we execute command to down/up network device,

NCSI will keep send AEN "Link Status Change 0x6b or 0x65", which cause BMC keep to reset and enable NCSI and not allow the network for BMC to work properly.

Regards

James

The Smart Home market accounts for many of the early success stories in the build out of the Internet of Things (IoT). Features of the Smart Home include energy management, occupant comfort, asset management, and security access. Note that most of these same features will apply to the Smart Building.

By leveraging the Intel® IoT Gateway reference design, which includes technology from Intel® Internet of Things Solutions Alliance members Wind River and McAfee, technology partners can expand the connectivity, improve the interoperability, and shorten the time to market for developers looking to transform their IoT business and operations.

Elitegroup Computer Systems, generally known asECS, has turned its own office into a smart building in an effort to replicate a "super" smart home (Figure 1). The Taipei, Taiwan–based maker of computing products, and a General member of the Alliance, has deployed 90 IoT gateways on its 25 floors across an area of 32,000 m². ECS’s office building receives readings from different types of sensors, including temperature sensors, motion detectors, O₂/CO₂ sensors, etc., which give the office administration the option to automatically adjust the environment and save energy in real-time. ECS claims to have achieved an 8% power savings so far this year and the company is now aiming for energy savings as high 30% next year.

Figure 1. Elitegroup Computer Systems (ECS) is using gateways based on the Intel® IoT Gateway design to monitor a wide range of systems in their own building.

Administrators can also remotely control lighting, HVAC, and meeting room equipment. Moreover, employees can only access a floor through their ID cards, which are supervised by a central security system for protection and access control. The video makes it clear. In the smart home, consumers could have access to lighting, HVAC, and door locks, amongst other things, as shown in the Smart Home video.

A key issue that must be dealt with in Smart Home and Smart Building environments is how to handle the plethora of wired and wireless protocols. ECS’s GWS-QXgateway,with fullwired and wireless connection interface, achieves the minimum infrastructure changes on already installed wire devices, as well as connects to various wireless legacy devices during installation (Figure 2). For the use of Smart Home the GWS-QX2 gateway is also equipped with custom changeable I/O ports (RS-232 and RS-485 interfaces), as well as LAN and GPIO ports to support most Smart Home applications. The GWS-QX2, smaller than a television set-top box, integrates the Wind River* Intelligent Device Platform XT customizable middleware development environment that provides security, connectivity, rich networking options, and device management. It simplifies the development, integration, and deployment of gateways for the Internet of Things.

Figure 2. The blueprint of a Smart Building.

ECS works closely with Tatung Group, ECS's parent company and a system integrator. Tatung uses IoT gateways like the GWS-QX and GWS-QX2 with its cloud framework for monitoring sensor data such as power consumption levels.

Both the GWS-QX and GWS-QX2 gateways for Smart Home applications are powered by Intel®  Quark™ Soc X1021, which supports an extreme temperature (up to 85°C) and secure boot. The Intel®Quark™ SoC embedded processors have been designed from the ground up for thermally constrained, fanless, and headless designs, which simplifies integration into smart homes. Intel Quark SoC offers rich I/O capabilities and an array of connectivity options for both wired and wireless protocols. Moreover, it seamlessly interfaces with sensors and various memory options through several expansion ports.

For developers looking to target similar technology for industrial applications, ECS will offer another IoT gateway early next year, the GWS-BTI, which is aimed at industrial applications like manufacturing automation that involve high voltage and heavy industrial equipment. Such industrial use models require constant surveillance with predictive maintenance to avoid shutdowns or component failure. The gateway provides the connectivity needed to capture edge data in real-time. This data is stored in the cloud with Tatung's Stream Analytics software that helps the gateway identify the status of equipment and individual power consumption by subcomponents to ensure reliability and robust operations.

The GWS-BTI's industrial design can deal with a challenging environment at temperatures from -40°C to 70°C. A full-featured I/O port allows the gateway to be connected to a variety of sensors, including those for energy management (Figure 3). Moreover, 3G cellular and Wi-Fi features enable real-time remote supervision and instant event reporting.

Figure 3. Energy management in a wide range of markets can be handled through IoT gateways based on the Intel® IoT Gateway design.

Note that the GWS-BTI device is designed with a more powerful processor, from the Intel® Atom™ processor E3800 product family, also specified for Intel IoT Gateway designs. This Intel® Atom™ processor supports up to 8 GB DDR3L.

ECS is also employs Intel®Trend Analytics Software (TAS) which, when combined with ECS’s home-grown Energy Management Sensor, can enable IoT gateways like the GWS-BTI to perform energy predictive maintenance, energy monitoring, and vibration detection functions via a standard USB port.

See the Solutions Directory for more products from ECS.

ECS is a General member of the Intel® Internet of Things Solutions Alliance

Richard Nass

OpenSystems Media by special arrangement with the Intel® Internet of Things Solutions Alliance.

Hi,

I have the following problem. When periodic SMI events are enabled the APIC error interrupt gets triggered for each CPU. I run the tests on a board with E3845 and use the default interval of 64 seconds.

Each 64 seconds Linux ERR count are increased with 4. If I disable periodic events, the ERR counter will stay at 0. The SMI is generated by chipset and thus it triggers all CPUs.

Any idea of how to avoid this behavior except disabling SMIs? I expect that chipset SMIs should not end up as APIC error interrupts, like spurious interrupts will do. Other than the 4 APIC error interrupts each minute, I have no abnormal interrupt activity.

Any ideas?

Best regards,

B-O