Windows 10 IoT Core OS Status and Issues
Comments
-
espijk wrote:Dear all,
Did someone notice the release of Intel creating a BSP Intel® Pentium® /Celeron® Processor Family Platforms N3000 and
Intel Atom® x5-E8000 Processor.
I've tried to create an image, but the built is failing.
https://www.intel.com/content/www/us/en/embedded/products/braswell/software-and-drivers.html
See Board Support Packages, Link "Board Support Package for Intel Atom® Processor Windows* 10 IoT Core 32-bit and 64-bit Platforms"
Cheers! Eric
Eric,
I know that I have tried using this BSP before, but that might have been before they updated it. I can see that it was last updated in October, so I can maybe try giving it another shot and see what I come up with. -
I believe I had downloaded this bsp last week and spent about 2 hours reviewing through the custom Windows IoT build online documentation and ran into some errors during the process (I think it complained about certificates or the like). If you happen to build an FFU for x64 Windows IoT Core (if you wouldn't mind), could you post the steps you went through =or= perhaps the FFU itself ? :cheer:
I know that all current versions of Windows 10 (other than IoT core) coupled with the drivers offered on this site do not support I2C (best I could determine on that end is there is a dummy/stub call in the aaeon dll that basically returns an error code that is (according to the header file reference) "unknown/unspecified error"...as well one example posted in one of the threads on this site that has a link to someone's dropbox account contains an incorrect/invalid pinvoke wrapper (C#) for the byte array passed to the I2C call that basically stomps on memory...when corrected (I posted the code I used) it returns the unknown error.
Either case, it would be great if you got W10 IoT Core to build from that new BSP so I can test to see if (at a minimum) a newly constructed version of W10 IoT Core supports I2C communication...
Would actually make the UpBoard (relative to Windows development) useful finally! -
I believe I had downloaded this bsp last week and spent about 2 hours reviewing through the custom Windows IoT build online documentation and ran into some errors during the process (I think it complained about certificates or the like). If you happen to build an FFU for x64 Windows IoT Core (if you wouldn't mind), could you post the steps you went through =or= perhaps the FFU itself ? :cheer:
I know that all current versions of Windows 10 (other than IoT core) coupled with the drivers offered on this site do not support I2C (best I could determine on that end is there is a dummy/stub call in the aaeon dll that basically returns an error code that is (according to the header file reference) "unknown/unspecified error"...as well one example posted in one of the threads on this site that has a link to someone's dropbox account contains an incorrect/invalid pinvoke wrapper (C#) for the byte array passed to the I2C call that basically stomps on memory...when corrected (I posted the code I used) it returns the unknown error.
Either case, it would be great if you got W10 IoT Core to build from that new BSP so I can test to see if (at a minimum) a newly constructed version of W10 IoT Core supports I2C communication...
Would actually make the UpBoard (relative to Windows development) useful finally! -
I know that I went through the instructions on that BSP at some point, and I produced an image without any errors, but none of the pins were working with it. It might have been before they updated this though .
-
I've tried to build a x64 image.
All steps went fine accept the last one: buildimage <Product_Name> Test
The inital error is that some cab files are missing, seems to me there is some error in the script, the cab files are there, but have a different prefix than Intel.XXXXX.cab, this is due to the OEM_name from step 1.
I just copied the cab files and renamed is, than after some minutes the following error occurs stops the build:
Error: Imaging!ProcessCompDBPackages: FIP information in FM 'BSWx64FM.xml' packages for the following Features are incorrect:
Error : BASE
Error : OEM_BSW64_DRIVERS
Error : OEMDEVICEPLATFORM_BSWX64_DEVICE
Error : DEVICELAYOUT_BSWX64_SOC
Eric -
Not sure if this helps, but since I am getting this odd error:
=========================================================================================
Processing igdlh64.inf
Authoring BSW64.GFX.wm.xml
Processing iaiogpio.inf
Authoring BSW64.GPIO.wm.xml
Processing iaioi2c.inf
Authoring BSW64.I2C.wm.xml
Processing iaiouart.inf
Authoring BSW64.UART.wm.xml
Converting BSW64.DeviceLayout.pkg.xml
(PkgBldr.Common) : error : Failed to load schema resource stream for input 'PkgBldr.WM.Xsd\SecurityPlugin.xsd'.
Error : Failed to create package. See V:\iot-adk-addonkit-master\Build\amd64\pkgs\logs\BSW64.DeviceLayout.pkg.log
...
=========================================================================================
From that point forward I keep getting the same "SecurityPlugin.xsd" error...
=BUT=
In the name of trying to get the "!@!@??!@" out of my head, I realized that I must have the wrong version for one of the required installs as outlined in the Intel October 2017-Revision 001 User Guide:
=======================================================
Operating System -- Windows* 10 RS2 (Build 15063 or later) x86 or x64
Windows* 10 IoT Core Packages -- v10.1.15063
Windows* 10 IoT Core Dashboard -- v1.0.1708.31003
Windows* IoT Core ADK add-ons -- Master Branch (v10.0.15063)
Windows* Driver Kit (WDK) -- v10.1.15063
Windows* Assessment and Deployment Kit (ADK) - v10.1.15063
=======================================================
The current theme here is that everything looks like it was built around the v10.1.15063 version of the Windows Driver Kit and WADK as well.
I had updated to the "latest greatest" version and had pulled down the more recent 10.1.6299.15 version of the WDK and the Windows IoT Core Packages...so most likely I have to setup a new virtual system (or rollback everything which is a pain) with just the v10.1.15063 version of everything.
As a side note
The v10.1.15063 Windows IoT Core Packages (x86 and x64) can be v10.1.15063 Windows IoT Core Packages downloaded here
So, one thing to check would be what version of the Windows Drivers Kit, Windows Assessment and Deployment Kit, and Windows IoT Core Packages do you currently have installed. If it is v10.1.15063 across the board, then you might get the very latest version of the IoT ADK AddOn Kit - MasterIoT ADK AddOn Kit Here as it looks like there were some fixes/modifications for the Intel BSP scripts as of 2 days ago.
Let me know if any of this helps and/or you get a build (i.e. you have the magic combination of sdks...etc..)
-Cheers -
Using the v10.1.15063 version of everything **AND** the V2.0 of the Windows ADK Add-On Kit:
https://github.com/ms-iot/iot-adk-addonkit/tree/v2.0
Seems to have removed the errors I was getting and building with no errors thus far... will let you know if I generate an FFU. -
*DING*
Made an FFU (Flash.FFU) using the x64 BSP with the above combination using the v10.1.15063 version of everything **AND** the V2.0 of the Windows ADK Add-On Kit.
Just as a quick test pushed it to a USB stick, booted to bios CRB, then to Exit and booted on 2nd partition.
Windows IoT Core x64 loaded up and I am configuring it now.
Anyway, just read the last few posts if you are trying to build your own version of Windows IoT Core for the UpBoard using the most recent Intel BSPs.
Sometime over the next few days I will push out one of our IoT apps that utilizes I2C and will confirm that it works (or not).
-Cheers -
I'm able to confirm I used a different, versions of the:
Windows* IoT Core ADK add-ons
Windows* Driver Kit (WDK)
Windows* Assessment and Deployment Kit (ADK)
I installed 10.1.16299.15 this seems to be the latest, not sure where to download a prior version of this setups.
Eric -
Step 1: Install Intel BSP
https://edc.intel.com/Link.aspx?id=14935
Step 2: Install WDK for Windows 10, Version 1703 (uninstall any previous versions if any installed first)
https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit
Step 3: Install Windows 10 ADK, version 1703 (uninstall any previous versions if any installed first)
https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit
Step 4: Install Windows IoT Core Packages 15063.0.170317-1834 (uninstall any previous versions if any installed first)
https://download.microsoft.com/download/9/D/8/9D810574-3EED-4831-91C0-D498FEFC490E/15063.0.170317-1834.rs2_release_amd64fre_IOTCORE_PACKAGES.iso
Step 5: Download the Windows 10 ADK AddOn Kit and Extract to Folder (i.e. C:\iot-adk-addonkit-2.0)
https://github.com/ms-iot/iot-adk-addonkit/tree/v2.0
Step 6: From the Intel BSP Download, open the 336577_BSP for Win10 IoT Core_User Guide_Rev001.PDF file and follow the instructions.
Step 7: Enjoy your custom version of Windows IoT Core using the new Cherry Trail BSPs! -
Sadly....very sadly...
I can also confirm, just first pass running one of our apps, that the standard GpioController.GetDefault() method (which works under RPI2 & RPI3 as well as all other "officially supported" Windows based products (*including Windows IoT Core*)
*** DOES NOT WORK ON WINDOWS IOT CORE X64 BY DEFAULT***
So, at this point I am thinking that the very small Up Board Windows community is going to be greatly disappointed as it would seem that no version of Windows 10 works properly...
The Intel Cherry Trail bsp "supposedly" has support for I2C and GPIO, but it would appear that *NEITHER* works under Windows IoT Core x64... which after looking at the libraries a bit more it looks as if it might require the AAEON drivers...but who knows what kind of a nightmare that might be...
So... unless someone who is part of the Up Board group who created this board...and claimed it worked on Windows 10 (yes and no... GPIO on Windows 10 works...but only using weird drivers that provides "slow GPIO times") but it does *NOT* support I2C by any stretch of the imagination.
You can build a Windows IoT Core x64 version (and suspect x86 version as well) which will not work either...because (I believe) that the image build *must include properly signed drivers* which WOULD BE THE RESPONSIBILITY OF THE UP BOARD CREATORS.
So the bottom line is that the UpBoard (for IoT purposes) *DOES NOT SUPPORT WINDOWS 10*
PERIOD....
I will look at trying to query the GPIO using a unique provider... but it would seem that the UPBoard was never "designed properly" and more than likely why they moved away from it quickly and have since (seemingly) stopped all communication with Microsoft regarding this particular board and for sure have pretty much stopped any form of communicating with the community who "fell for their false advertisement of supporting Windows 10".
Sorry... have tested every version of Windows 10 and *NONE* provide full support for I2C and/or GPIO (properly).
Very disappointed in this product at this point... -
Just to be clear:
Windows 10 *runs* on the Upboard...but if you plan to make it do anything with I2C and GPIO... then forget about it.
All versions of Windows 10 (home, pro, enterprise) both x86 and x64 only support GPIO via some odd ball API. While the GPIO "works" it does it very slowly...regarding I2C...forget about it.
The Upboard running both x86 and x64 versions of Windows IoT Core have now been confirmed to no support GPIO and I2C at all...
When using the GpioController.GetDefault() method it returns NULL.
Per Microsoft documentation:
https://docs.microsoft.com/en-us/uwp/api/Windows.Devices.Gpio.GpioController
"The default GPIO controller for the system, or ****null if the system has no GPIO controller***".
Either there is a BIOS update or DRIVERS and since, evidently, there is ZERO SUPPORT from the makers of the Upboard... I can only guess they have long since given up on this product and moved on...
Otherwise... AAEON Folks???? UpBoard Creators???
Got Windows IoT Core x64 built and running on your UpBoard...and evidently not even the GPIO devices are recognized...the SOC devices are recognized but the additional drivers required...????
Bueler? Bueler? Bueler?
Anyone who has made a profit on the sale of this product care to comment or assure this will be resolved???
(i.e. is actually part of the UpBoard creators) -
I can confirm that I have taken the same steps as several of you mentioned and I’ve gotten my Up Squared Board runnning Windows IoT. I think I tried both the x86 and x64 versions of with the same issues you all were having with the GPIOs. I also went and tried to install the drivers provided for Windows 10 by AAEON using devcon, but even with those installed, I had no luck with the GPIOs.
-
We hear you, and we never rest on the development of Windows IoT Core.
Let me give you some update here.
1. UP board Windows IoT Core.
A few weeks, we noticed Microsoft started to support Windows IoT Core on Cherry Trail. So we contacted Microsoft Taiwan to understand more details. The FAE in Microsoft Taiwan confirmed the support and shared the installation steps he has done on other Cherry Trail platform. Obviously, there is still some factory setting to be done to build an image. Our team has started working since then. We hope we can release Windows IoT Core image at UP Community soon.
2. UP Squared Windows IoT Core
The beta image has been built and we are working on SOP to release it. The preparation of SOP is longer than we expected, as we want to improve our quality of documentation to make it easy for our users. I just got help from our community member @Eric Duncan to refine the SOP. I hope we can release it next week.
Though we have been using Windows in embedded version, or other version for long long time, but Windows IoT Core is not so straightforward as other versions. If you try to download SDK from Microsoft website, you might notice that the installation is quite different from other Windows versions. We are working on it with the help from Microsoft.
Thanks for your support, and we will get back with update soon. -
Thank you very much Aling for the update! It helps those of us with board in hand waiting on what was, I believe and anyone correct me if they feel otherwise, seemingly already working upon purchase based on all information provided at the time.
There are just a few questions as well as some additional information that would be *very helpful* in my opinion that you might be able to provide here and/or in the wiki:
From "bios default settings" a list of any and all values that you currently have changed/updated in order to assure proper functionality for both Windows IoT Core *and* normal windows 10 installations. Having the proper settings available will help everyone (in my opinion) and will help reduce any trouble shooting once you post any new drivers and/or images of Windows IoT core on this site.
A simple page with a table that shows version of operating system, device functionality (i.e. GPIO, I2C, etc), and the currently known functionality status (i.e. working, not working) with some form of "eta" to functionality complete. Having this will help reduce current Upboard product owners from spending their own time thinking that perhaps it should work but they might be doing something wrong ( which this concept points back to proper BIOS settings as well).
In my opinion, this would reduce the number of posts from people that might be frustrated and/or wondering if they are doing something wrong or it just isn't supported yet and there is nothing else they can do until such support if provided by drivers, bios updates, or os image.
If someone in your group could spend like 2-3 hours once or twice a month updating changes to the above described pages (with probably about 5-10 hours initially gathering all information, reviewing it, and then posting online), then I would be willing to bet it would increase customer "faith" in the product as well as squelch anyone who might feel that they were "tricked" into buying something that didn't and might never work as advertised.
Thank you for taking the time to give us a status update, and I hope that perhaps some of the information above might be taken with inspiration and opportunity in mind.
Cheers -
This is about nothing but reserving and devoting an amount of undistracted time and dedication in support of those wanting Windows 10 IoT Core on a recent Intel chip.
GPIO and I2C drivers aren't hard to write for an experienced C++ developer with intimate knowledge of the hardware. There are even complete sample drivers available in source code with the specific purpose of making those drivers easy and fast for hardware publishers to release.
If it was just for the promises made over the past several months, with no meaningful follow up whatsoever if there was competition, I would choose them today.
In lack of competition, I make do with a competitor ARM board if you must know. I've been tempted, but I am quite happy that I never spent a dime in up-shop just yet.
Just jot down a few lines in this forum please. Let us know where you stand. -
We're also looking for a board to run IoT Core on and would have purchased many units by now, with many more once we get our solution out of beta. UP Board does not seem interested in supporting IoT Core and we're forced to look at competing boards that do support IoT Core.
-
Good news.AlingWu wrote:We hear you, and we never rest on the development of Windows IoT Core.
Apology for responding without reading the quoted response, but it is a bit too little a bit too late.
More importantly, I simply don't agree with the priority here.
The OS images or documentation of a Standard Operating Procedure (SOP) are not the blocker. The drivers are.
It is maybe an hour of work to get up and running from scratch, save for downloading and installing components such as the Microsoft SDKs which are sizeable and take a bit of time to track down, download and install. Yes it is tedious and might be overwhelming for a first-timer, but it is doable with the walkthroughs Microsoft offers on the side.
Any image you release which does not work with the Microsoft IoT SDK for Visual Studio on top of that will not convince anyone not already buying UP or UP squared to do so after all. Get the drivers right so they work with those SDKs instead.
Any image you release does not at all reduce any time for any of us to build our own release image and incorporate our customizations, since that is best done from the standard build process that Microsoft already documents reasonably extensively. Documenting the SOP and offering .ffu's for download hence is wasted time on non-blocking features, unless there is flashing involved or otherwise configuring the BIOS, but in that case instead of a .ffu we will need the files and settings that allow making the necessary changes ourselves instead of completed images. -
Hi Eric,
I think that an honest answer as to what they need to fix, why it needs fixing, how they plan to fix it, and the time estimated to fix it would be *very* helpful for current and potential future consumers/customers as it then removes the questions as to what exactly the problem is...
From various forums here, I have heard:
-- The BIOS needs to be updated
-- It just needs drivers.
-- The BSPs are required for them (and consumers) to build Windows IoT Core (if that was the target)
From what I can tell, having run the UpBoard on all x64 versions of Windows including Core and Server 2016, that the I2C devices and GPIO devices on the Cherry Trail SOC are recognized and (according to windows) working.
However, if you try to access them using the provided "library" you can get the GPIO working but no I2C on all versions of Windows 10 or Server using C++ or C# (I can verify as true)...but the biggest issues here ( IMO ) is the fact that I2C does not work at all using the libraries provided even though if you look through the devices listed under the device manager it *shows I2C devices* that (according to the device manager) are working properly.
So, from that perspective it is either the library provided is broken and needs to be fixed =or= as I have read in some posts there is a BIOS update required for it to work properly. The end result being... it would seem that no one knows what actually needs to be fixed (and as such why that is a good place to start) as there has been no real post or wiki or simple webpage that lists known issues, what the problem is, and some form of status as to when it should be fixed and what is holding it up.
From the Windows IoT Core perspective, looking through the devices (ACPI if you have set GPIO and I2C to that in BIOS) upon installing a "custom built" version based on the instructions I provided a few posts back, you will notice that both the GPIO and I2C devices are listed...but for some reason the standard UWP Windows IoT GPIO and I2C calls finds nothing at all.
So, there is another *strange* pair of issues...the I2C and GPIO devices are listed as if they are "working" but are not being found by Windows Libraries...which could, again, be either a simple BIOS adjustment (i.e. should they be PCI as opposed to ACPI, are there other specific settings required, etc), a BIOS update (i.e. linking the SOC I/O buss to the proper memory address for Windows), or do the already existing drivers provided by Intel need to have their INF file adjusted specific to the Upboard in question?
With that being said, knowing what the issues are (which would best be described by AAEON folks) would help all of us understand "what the road block is"...it could be that they are waiting on a BIOS update that is done by a 3rd party group who is the block...it could be adjustments to the BIOS, BSP INF files (under BSW x86 or x64 Packages), or it could be that there is a "middle man" device that provides access to both GPIO and I2C that requires AAEON to provide additional drivers (like you are stating).
However, since the BIOS seems to take either the Windows 8.1 or Android/Linux memory model into consideration, there could very well be some improper BIOS mapping to the IO devices in question since Windows 10 handles memory differently (bios to kernel to user mode) than Windows 8.1...
Since it would seem that there are so many possible areas that "could be one of several problems", I was hoping that the AAEON folks could provide some kind of table that they would update regularly (i.e. once or twice a month) that outlined precisely what was being fixed, why, and the current estimated time to completion...otherwise we are all sort of "blindly guessing" as to what the real issue(s) at hand are.
Most definitely frustrating that it doesn't work as advertised, but more frustrating (at least in my opinion) is that there seems to be "several posts" that claim it is the BIOS or the Drivers or waiting on BSPs or...etc...etc...
For all we know, there could be a one to two line fix in some of the INF Packages files and a couple of BIOS changes (parameters not actual update...like changing from ACPI to PCI or the like) that could yield the "right combination" to getting Windows Universal calls recognizing the already recognized SOC devices... or very well a "middle man device driver" that is the in-between User Mode to Kernel mode (SOC devices) link missing that is required to get UWP IoT calls working...because Intel's release of the BSP claims that GPIO and I2C is supported in this first revision...and the devices do show up under the devices area (web portal) for W10 IoT Core...
Anyway... knowing what is broken is half the battle to figuring out a fix...heck...if I knew specifically what was broken (unless it is truly a BIOS update) then I might take a day or two to come up with a fix...but since I don't know what specifically is broken...there is no way to do that.
Which this product is "supposed to be" a sort of "open source" kind of product...which I think at this time...it might be *much faster* to post their current tree of source (i.e. if it is a driver issue only) on GitHub and let the community help them with what is obviously a lack in resources (man/person power)...of course unless it is a BIOS update required....
Just my two cents.... -
After reading a few of the non-windows based forum posts, I think that the mystery behind why I2C does not work under Windows in general (and possibly why GPIO does not work under Windows IoT Core) is because it is linked by a CPLD as can be seen by the post from AAEON here:
https://up-community.org/forum/search?query=CPLD&searchdate=all&childforums=1
"I2C0 and I2C1 goes to CPLD and from there to 40pin connector; as you don't have access to CPLD code, you cannot have access to 40pin connector."
For those unfamiliar with a CPLD:
https://en.wikipedia.org/wiki/Complex_programmable_logic_device
So, it would seem there *is* a "middle man" device between the SOC devices and the 40 pin breakout, which now begs to ask the question:
"Was the CPLD programmed properly prior to being shipped?"
If the answer to this is yes, then the next item of topics in question would be:
1.) Why use something like this between the SOC and the breakout? (was this actually necessary in the design?)
2.) If this is the issue, then that would mean there *are* missing drivers (for the CPLD) and if that is the case then will there *ever* be a working version of Windows IoT core? It would ~seem~ that the CPLD could be the primary culprit in most everyone's issues as well it explains why placing GPIO or I2C into PCI mode basically "breaks" the CPLD design as that is only ACPI and not PCI.
So, either case, I believe the CPLD is possibly the *primary reason* why there are so many issues across the board (Linux to Windows) as the "standard way of accessing said devices" (I believe) was changed when the choice to use the CPLD as the middle man between the I/O devices was made. Sounds good on paper, but then implementing full compatibility across all OS versions might require variations of the CPLD programming logic.
The final big question would be: "Can something like a BIOS update also update the CPLD or is this something that comes as factory default?"
If that is the case (factory default and no real way to update without specialized tools), then it might be that the upboard will never work properly under any version of Windows just due to hardware limitations/design choice.
It would be great to find out if this is the primary issue behind all of the problems being experienced under Windows.
(I thought the C++ code looked kind of whacky how the GPIO was being accessed...looked like it was communicating via some form of serial communication that in turn talked to the GPIO on the SOC) -
Dear all,
We understand it might take too long for you to wait. I would like to give you some update here.
1. For people who don't use 40-pin, but would like try Windows IoT Core on UP or UP Squared.
You can follow below:
BIOS version:
UP: UPC1BM0S
UP^2: UPA1AM21
No special setting required in BIOS.
*****************************************************************************************
https://docs.microsoft.com/en-us/windows/iot-core/build-your-image/createbsps
Apollo Lake / Braswell / Cherry trail
The BSP supporting Apollo Lake is available at Apollo Lake BSP.
The BSP supporting Braswell/Cherry trail are available at Braswell BSP.
Tip
The published BSP works with Windows 10 ADK release 1703 (15063).
Follow the steps below to use this BSP with the Windows 10 ADK release 1709 (16299) with iot-adk-addonkit version 4.0 or later.
Download the BSP package and install
Copy files from C:\Program Files (x86)\Intel IoT\Source-<arch> to iot-adk-addonkit\Source-<arch>
Launch IoTCoreShell, select arch (x64 / x86) as required
In the IoTCoreShell, run the below command to convert the BSP files to latest format and build
run .\bsptools\<bspname>\convert.cmd
buildbsp <bspname>
Process of environment:
How to build an image
How to install your image to a storage
***************************************************************************************
For people who would like to GPIO/I2C/PWM/High Speed UART in UP/ UP Squared:
* UP Squared
We are trying our best to complete SOP and work on a new BIOS V2.3 (temp defined).
With V2.1 BIOS, users need to put command line in BIOS to enable the function. We would like to have a new version of BIOS to save the efforts from users. ==> because of this change, we may delay a few days again.
Many people asked why it is so difficult to build an image. It is because we use FPGA to assign the pin definition of 40-pins, so we have to develop a proprietary SDK for it. To manage 40-pins in Windows under FPGA control, it is a new development. We can say we started the development 3 months ago already, here we are almost in the last step.
We hope we can come back with image and SOP soon.
*UP
IoT Core. As mentioned earlier, we just got the confirmation from Microsoft that IoT Core will support Cherry Trail. Our engineer has started working on it since then. Again, we use CPLD to control 40-pin, it gives us a long road in SDK development in enabling.
We plan to release an image without 40-pin support in the coming week; then our engineer is going to evaluate how much time will take to enable 40-pin.
If we have any community member who is willing to help us for the 40-pin SDK development or test+SOP refining, we are happy to have you. You can contact us via info@up-board.org
We really never rest on this topic. :-) -
Has anyone gotten Windows IoT running on the up? I tried the above procedure and haven't had any success getting it to work.
-
Hi there,
This issue is driving me crazy!.
Can we get a stable version of IoT Core in Up Board ASAP? -
@David said:
Hi there,This issue is driving me crazy!.
Can we get a stable version of IoT Core in Up Board ASAP?Hello,
Any update about that topic?After reading the previous posts, I am wondering if we can consider that IoT Core works properly on UP board (if we do not need neither I2C nor GPIOs)?
Thanks
-
Hello,
I've been able to successfully create a custom FFU using the April 2018 IoT Core package. I'm using this package because it adds support for on-screen keyboard.I also made a UWP app that is a basic browser that points to our intranet. This is all working.
Just thought I'd share a problem I spent an entire day trying to fix. I'm using a 22" Planar touch screen with the UP Board mounted to the back. About the time I thought everything was working great, a co-worker walked in to my office and tried to pinch-zoom the screen. The system automatically crashed and rebooted. I tried fixing it through code but it became obvious it was an issue with the iot package. It would even do it on the DefaultApp screen.
On a whim I had the system check for the updates. After about 40 minutes, it finally finished downloading and installing the updates. It restarted, and while trying to apply some updates, just crashed and restarted with a WDF_VIOLATION error. After a few times of just letting it continually restart it attempted to do what I would assume be a repair (Two spinning cogs and a progress bar). After it finished it restarted and finally came back up and the pinch-zoom crash was gone and the OS was showing version 10.0.17134.165 (was 10.0.17134.1).
Hopefully it will still be resolved in the next release. Hope this can help someone in the future.
-
Any update on GPIO support on IoT Core? really interested in buying some up-squared devices for industrial signage but require the 'Lightning' drivers to be working
-
I notice your suggestions above about the BSP: (not using GPIO)
"In the IoTCoreShell, run the below command to convert the BSP files to latest format and build
run .\bsptools\\convert.cmd
buildbsp "In the newest version of the powershell tools, these commands do not work. (object not found)
I'm getting a blue screen when trying to load my FFU Driver IRQL not less or equal
-
Has anyone succeeded to update the IoT Os version to the latest version ? The default OS version you get but flashing with the .ffu available on the UP website is version 10.0.16299.15. Trying to update via Windows device portal is a nightmare, it takes hours to download and install but ultimately fails. Sadly these isuses, really doesn't make people actually want to work on the up board with Windows IoT core. Raspberry Pi counterparts, on the other hand, work fine.
-
The Windows IoT Core OS is an important platform advantage for UP Board. It's gives UP board the edge over your competitors as it consists of the latest cherry trail intel atom chip. It can also provide security features for professional features and boot or run from mmc.
With Windows Iot Core on UP Board, it can provide a complete or total solutions for Internet of Things applications which is very hot today. Most of the early generation developers start using Visual Studio when we first start coding
This is an important market. If you can share or provide how the community can help to influence Microsoft and Intel on the implementation of Windows IoT Core OS, please feel free to let the community know.
Some suggestions that I can think of are:
-Start a Public Survey both registered and/or unregistered whether to have Windows IoT Core OS in UP Board. Provide and influence Microsoft/Intel with this survey suvey result.
-If extra funding is needed to show Microsoft/Intel support for Windows IoT Core OS, set that buy option in your UP Board Shop.
Maybe, need to provide the Windows IoT Core ProOS in this case whereby provides an ability to defer and control updates. This can differentiate professional developers who really need this requirement.
You can also start another kickstarter or other crowdfunding websites on Windows 10 IoT Core Pro OS for UP Board which provides discounts for different version of UP Board discounts.
Thanks
Fixbit
