OK - I just ordered up some thru-hole RGB LEDs, so we can wire up the '207 eval board to look like a core/photon/whatever - if people can PM me their shipping address, I will post out a little kit with these LEDS, some resistors and buttons, to everyone working on this with the Olimex board.
Step 1 will be porting the bootloader (which should be trivial - hah, famous last words.) I have requested a USB PID from Spark for this device for use in the DFU code.
I was hoping the request to come my direction, but not seen it yet! 
Not to worry, Iāve created a new platform ID - 9 - and corresponding USB PIDs. (0xD009 for DFU and 0xC009 for CDC.)
Are you planning to build this on top of WICED? If so then the simplest route forward is to create a new hal/src/ethernet folder that uses the hal/src/core-v2 folder as a fallback for any missing files. This means you can reuse the existing photon stack while replacing the files for wlan and sockets implementation.
The USB PID request was piggybacked on a hardware request to Mohit/Will/Brett, was trying to avoid spamming half the company. Much appreciated.
Brief update. Iām currently working to get the bootloader to build.
My build platform is Linux, and my toolchain is 4.9.3 - the main spark firmware developers are still using 4.8.x, the code generated by 4.9.3 is slightly too large to fit in the flash area allocated for bootloader - Iām about 128 bytes larger than 4.8.x and about 24 bytes larger than the allocated space, so even the working code is tight now.
If I were under deadline, Iād just find and load up a 4.8.x toolchain, throw a symlink and move on, but I want to understand what is going on, because the main team will hit this eventually, they canāt stay with down-rev toolchains forever. So Iām going to keep on looking at this for a little longer.
For most of the code generation the newer toolchain does better, but for some of the USB stuff it generates larger code - I suspect the culprit is bitfield/union handling when looking at the data structures maintained by the USB OTG hardware. It may be there was a sloppy code generation problem that was fixed, or it may be that this is just collateral damage from some other feature, but disabling the likely candidates (such as Local Register Allocation) has no effect.
Spark are still working the terms of the source code release, so no progress on that front, Iām afraid; I have not put any effort into sanitizing a working code base for development, because Iām scared to death of the integration issues trying to reconcile that tree and push changes back into the official spark repo (whatever that looks like post-release.)
We will need to re-map some pins because of the way peripherals are allocated/connected on the '207 as compared to the '205 - there is work underway to figure out the smartest mapping and then Iāll adapt the bootloader to suit.
Anyway, I wanted to assure people that there was still activity underway.
I am very, very, interested in an ethernet version of the spark stack. If there is any way I can be of assistance please let me know!
If you can code (e.g. build and debug the firmware locally), then get hold of the Olimex '207 board mentioned above (Digikey/Mouser carry them if you are in the US) - PM me with an address so I can send a small kit of parts out to adapt (some soldering required) it into a wired-core prototype. @harrisonhjones / @eely22 , donāt fret - Iāve not sent the parts yet, still working out the optimal pin (re)mapping scheme.
In parallel, if anyone has a favourite POE device chipset, letās start discussing that here - I like the TI family, and see no reason why we should not implement the 25W standard (802.3at) - but am open to discussion.
Ideally you guys could take a photon add an ethernet shield, and everything would work seamlessly. Sign me up, I am a developer and can write code! Though I will receive my photon in mid June, I assume.
The point would not be to use up pins with a shield, but to provide a new device that had the full compliment of pins available for use.
I have the bootloader and proton firmware building now, I need to figure out the I/O pin adapt for the bootloader, and get that ported, then implement a '207 ethernet mac driver under the HAL in the new firmware tree.
Sadly, the new firmware source tree is not approved for public release yet, because of licensing with the broadcom WICED source, but completion of that is imminent, I am assured.
If you want to help, get your own version of the eval board listed above and get ready to join the fun as soon as the git tree can go public.
See this other thread:
Today is a big day, because the source tree with FreeRTOS, a full tcp/ip stack and the particle cloud-interface code is publicly available. This is the ideal vehicle for the cheapest wired core, based on the '207 chip.
I strongly suggest that everyone interested in working on the wired core begin by cloning the repo and building firmware for either the core or the photon as a baseline. I know that Mat is working on docs to explain the build process, so don't jump on him for lack of docs right away.
I have device ID and USB PIDs allocated for a wired core, I'll be checking that in real-soon-now (tm).
This is awesome, great to see the progress!
Hi All. Iām also very interested in an ethernet option. Just wondering if thereās been any movement on this?
After a bit of a delay, Iām getting back in the saddle on this.
Iāve started butchering one of the Olimex '207 dev boards. My plan is to move the bootloader over first, which shouldnāt be too painful, followed by a build of the firmware without the wiced stack, but with the TCP/IP stack (which might be a kinda entertaining bit of surgery) and no etherent interface - then find/port/write a suitable low-level driver.
I plan to do all of this in a fork of the particle firmware tree. Iāll post a link here when I have that fork up and ready to go.
I still have small kits that I plan to send out to interested parties that will add things like the tri-colour LED, the setup button etc etc to the Olimex dev board.
The olimex board is no longer available. so those of us just getting into this are out of luck.
if the idea is for a strictly ethernet ala photon without wifi, could we not place the ethernet port at the back end of the board, where the chip antenna is for the photon?
Hi @AndyW, I was wondering if you have made any progress on this so far, and if there is anything community members can do to support you in your efforts. If the Olimex board is not available anymore, what would be a suitable alternative? Wiznet has some (development) boards, that look interesting. Slight lower powered MCU, but fairly similar speced to the spark/photon.
http://www.wiznet.co.kr/product-item/w5200e01-m3/
http://www.wiznet.co.kr/product-item/wiz550web/
Would it be possible to port the Particle firmware do these devices?
Hi guys, any news?
We really need the ethernet connectionā¦ without it we should reconsider the photonā¦
Any movement on this, and ethernet option would really be great.