We are pleased to present below all posts archived in 'May 2015'. If you still can't find what you are looking for, try using the search box.
In this blog, the eBoot menu is modified to to allow user selection of Clearing of the Hive or not. This is implemeneted by adding a further parameter to the BOOT_CG and BSP_ARGS structures to handle the boolean selection. The eBoot code is then extended to pass the selection up to the OS args driver. The OS args driver then is modified to get the value when requested by getting it from the structure passed to it through shared memory. This replaces the use of the dummy variable s_bClearHive as used in args.c in the previous blog.
Read the rest of entry »
The previous blog in this series demonstrated how to add a custom OAL IOCTL to the BSP. In particular it implemented the IOCTL_HAL_GET_HIVE_CLEAN_FLAG IOCTL so that it returns a fixed value to the OS when called. In this blog, that code is extended to call the BSP boot args using a custom boot arg. A fixed value is returned by boot args in this case. A later blog will pass that arg from eboot.
OAL IOCTLs are callable from OAL code to perform specific functions within the OS Kernel. The OS requires the OEM to specifically implement certain IOTLCs that it calls, and some other standard IOTCLs if implemented are automatically called by the OS. One such optional IOCTL, IOCTL_HAL_GET_HIVE_CLEAN_FLAG, will cause the OS to clear the hive registry if it passes back a TRUE when called at OS startup. These IOCTLs are normally called in kernel mode as they are called directly by the the kernel. Some IOCTLs can be called by a user mode thread as well. In our book, Professional Windows Embedded Compact 7, I covered implementing a custom OAL IOCTL for the VCEPC BSP. This blog looks at adding an OAL IOCTL with the ARM TI AM335X BSP
Booting a Windows Embedded Compact image is a three step sequence.. A raw binary of binary file or a record based binary file is used for each phase of the OS boot. Includes use of CELoader to image a target.
Various scenarios were presented for Windows 10 IoT at Build 2015. In all cases, the object is to have a Windows 10 device, whether desktop, mobile or embedded/IoT, talking to custom hardware and to the cloud. The “reference” design for hardware from a Makers’ perspective is Arduino. Let’s examine the scenarios.
Windows 10 IoT is the third (lower) layer of Windows 10. All three are built from the same codebase, part of Microsoft’s one Windows mantra. Whilst the desktop will have significantly more features than the IOT layer, the IoT layer will embedded features such as General Purpose IO (GPIO) which the desktop doesn’t. The Phone layer will support cellular networks for phone calls whereas the other two only support this for internet access. Apart from the common code, a binding feature of all three is Universal Apps.
At Build 2015 in San Francisco this week, there has been a large range of announcements wrt Windows 10. The topic of interest here is "Windows 10 IoT Core Insider Preview" as a public release of this for this for the Raspberry Pi 2 was much anticipated. That is now available. The IoT sessions indicate that it is now available not only for that but for a number other contexts