Gus, i have already talked with Toshko about this and we think that we can do that.
I tried the Xmodem uploader to update my Domino and it worked perfectly. Thanks to all those who worked on it’s development!
Gus (FEZ God) & FEZ Users…
My VBMF solution for EMM depends (or should I say depended) exclusively on MFDEPLOY to push SREC encoded HEX files to the target device after my custom PE build-and-package and, for subsequent production deployments, to use its “Create Application Deployment” to create a “Golden Master”…Imagine my delight to find that these features are not supported on FEZ, instead implemented through the bootloader (grin)…Don’t get me wrong – not complaining, simply telling my tale…
(Gus, have you been waiting for me to stumble into this? [big grin])
So naturally GHI has a nice, straightforward alternative – the XMODEM path via bootloader, no big deal…Sounds like you guys have done a nice job of putting together a nice GUI driven tool…So the question is, does is support command-line deployments?
If not, I’ll end up writing one, so if it’s of use to your tools suite, let me know…
I’m looking into the format of the files that get pulled so that I can render my PE builds in that form for post-compile “package & push”…Any input would be welcome, thought I’m tearing into it now…
Gregg Bieser
Conduit Softworks
OK folks, some clarification…
My last post here (immediately above) may have implied that I don’t get it, but I’m pretty certain that I do…A little clarification…
I understand the following…
-
We are talking primarily about “capture-of-‘golden’-image-from-one-device-for-deployment-to-
many-others” with respect to your slick XMODEM Uploader tool -
The manual sequence would then be…
CAPTURE (assumes app is already loaded and qualified for distribution)
- Boot into BootLoader
- Enter “G”
- Initiate XMODEM-1K file receive, saving stream to file on dev box
DEPLOY (to a device ready to receive app image)
- Boot Into BootLoader
- Enter “L”
- Initial XMODEM-1K file send from file saved in CAPTURE (above) to dev box
- Enter “R” to fire-up CLR and test
-
Your XMODEM Uploader tool greatly formalizes and simplifies the sometimes quirky
business of dealing with the BL for already captured images
Now about my previous question…My goals a little more challenging…
I need to be able to take a PE file and package it for delivery to FEZ without going through VS 2010 immediately after build…This has always been possible via MFDEPLOY with EMM… Certainly I had to do some figurin’ and codin’ (SREC encode, key construction) to get this to work, but it is very smooth…Without MFDEPLOY I gots a problem – namely that there is NO documented way to put my PE onto FEZ without digging into the black magic of MS MFDeploy classes which make my vision cloud over on just reading the prelims – there has to be another way (there was before)…
I just worked out what may well be the answer…
Namely I took the following test steps…
- Deployed a quickie “flash the LED” applet (100ms flash interval) via VS 2010
- Rebooted FEZ into BL
- Captured image of deployment via “G” option and saved to FLASH100.IMG
- Modified the “flash the LED” applet st: flash interval is 500ms
- Compiled the new “FLASH500” applet into a PE – WITHOUT DEPLOYING VIA VS 2010
- (the meat of it) Overlayed the FLASH500.PE bytes on FLASH100.IMG such that the
starting point of the FLASH500.PE file bytes matched the starting point of FLASH100.PE
in the image (found this by looking at the pre-overlay image – it’s at $00000000)…
To be clear, I determined the length of FLASH500.PE, removed that many bytes from a
copy of FLASH100.IMG where FLASH100.PE lived, pasted the FLASH500.PE bytes
where the removed bytes had been, thus maintaining the offsets of everything else in
the image AND the image’s exact size. Called this new image file FLASH500.IMG - Rebooted FEZ into BL
- Deployed FLASH500.IMG into FEZ Mini via “L” options
- Rebooted FEZ into standard operation
- Enjoyed the moment as the LED flashed at 500ms
Damn…Lot of work but worth it…Why do I care?..I have a large investment of time and testing in an extensive series of VB libraries that I run on MF via a custom build system – I’d rather fight the bear on issues like this than start over on the libraries in C#…
Why does is work? It appears from my perusal of the captured FLASH100.IMG file that only three assemblies are actually deployed by VS 2010 – the FLASH###.PE at $00000000 and two GHI assemblies starting at $00020000…Don’t believe me? try capturing an image and searching for “MSSpot1”, the PE marker…Three on my FEZ Mini, including my app…
Certainly this is only research now and time will tell if more links to GHI libs require a rethink of this approach, but at present it seems like a way out that doesn’t involve eye-of-newt…I’ll have to write a “PE overlay” command line tool and a command-line savvy adaptation of XMODEM Upload, but it works out of the box, but I’m happier now than I was three hours ago thinking over the bleak alternatives…
Let me know what you think…
Gregg Bieser
Conduit Softworks
XMODEM is only used to update USBizi but you still need MFDeploy to update EMX
http://ravenlabs.org/downloads.php?cat_id=8&download_id=19
Thats the full source of FEZ Panel, you can use the Device class to easily hook up a USBizi device and update it with Device.Firmware.Update() or Device.Firmware.UpdateAsync(). So you’ll just have to write a quick tool to accept command line arguments(or wait until tomorrow when I’ll do that myself for the Panel).
newbe question. Why can’t a method be figured out to just use MFDeploy fez firmware without teraterm/xmodem out-of-band from mfdeploy?
^^ GHi has their own custom bootloader. for whatever the reason, it is not compatible with the way MFDeploy deploys firmware.
MFDeploy is a tool from Microsoft. It has nothing to do with GHI loader…
But you can create a Window program like this one (XModem uploader) and you can easily integrate the MFDploy stuff in it…
So one program can do both but somebody just needs sometime to put them together.
Thanks Chris and Mike. That makes more sense now. It was not clear from videos or directions (unless I missed it) why one could not just use MFDeply as one would expect at first blush. Is there a good primer on comm with the boot loader. I may take a stab at a FezDeply clone app.
Toshko, I have an issue running this on Win7 x64 - let me know if you have tested this or not and perhaps I can help debug what’s going on and we can fix? My issue seems to be when you enumerate the COM ports, it doesn’t find Fez and then tries to work on a null handle and throws an exception. I was not running in elevated mode. Let me know if you want the full stack info from the exception?