Enphase Data Access

12467

Comments

  • ag4wakeag4wake Registered Users Posts: 18
    Re: Enphase Data Access

    I thought I'd share. In comparing my envoy unit to Sandeens, I can tell mine does not have the JTAG or COM soldered into the board. So I would need to buy the JTAG connector and COM connector and solder them on myself. I'll post a picture soon.

    Here's sandeens board for those that don't remember

    http://www.flickr.com/photos/[email protected]/4662039404/in/set-72157624185399680/

    Alan
  • sandeensandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    ag4wake wrote: »
    I thought I'd share. In comparing my envoy unit to Sandeens, I can tell mine does not have the JTAG or COM soldered into the board. So I would need to buy the JTAG connector and COM connector and solder them on myself. I'll post a picture soon.

    Here's sandeens board for those that don't remember

    http://www.flickr.com/photos/[email protected]/4662039404/in/set-72157624185399680/

    Alan

    funky. I'm interested to see your pics :)
  • sandeensandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access

    FWIW, for anyone who is in the device, if you wish to screen-scrape the production page with a bit more precision (right now it's in 1kWh units), find the "data.rb" file, and change the j_to_kWh() function to be:
    def j_to_kWh(j)
       sprintf( "%0.02f", j/3600000.0)
    end
    

    which will give you 2 decimals of precision in energy output. (being a bit opaque here so that there's no question of pasting copyrighted code; I'm sure you can find it w/o much trouble).

    I did this after I started reporting data to pvoutput.org with a perl script I wrote - see here for example output, it's kinda neat. We could start an "enphase" team ;)

    (It's not necessary to get the extra precision, but reporting 1kWh jumps makes the graphing a little odd)
  • System2System2 Posts: 6,290 admin
    Re: Enphase Data Access

    For those who just want to check individual panels periodically, could you not use the admin interface, Device conditions and controls, and remove all but the target inverter from the list, then check total output?

    Has anyone tried this?
  • ag4wakeag4wake Registered Users Posts: 18
    Re: Enphase Data Access

    I can't log into the Admin page. What user/password are you using? The manual actually doesn't even mention it.

    The only thing I've tried so far is I setup an Amazon EC2 instance for a GPU compute cluster and ran the root password hash through a GPU based password crack for a day using the rockyou password list but didn't get any successes. I also ran a brute force on the root password and the Enlighten user for up to 5 characters in length. At $2 an hour, that was around $50 in compute time and as much as I was willing to spend to try.

    I still need to post the pictures of my envoy circuit board, but I've been fiddling with my home energy monitoring system to get it working right and haven't yet gotten to the envoy unit. I did find that jtag connectors come in difference sizes and pin widths, so I'll have to measure the widths of the contacts. If the JTAG headers of existing units has a manufacturer or model number that would simplify which component to get in my case. So if anyone with the last version could check their boards I'd appreciate it.

    Alan
  • dreesdrees Solar Expert Posts: 481 ✭✭✭
    Re: Enphase Data Access
    ag4wake wrote: »
    I can't log into the Admin page. What user/password are you using? The manual actually doesn't even mention it.
    The admin username / password is admin / admin
  • andymanandyman Solar Expert Posts: 32
    Re: Enphase Data Access

    I've had a little probem with my EMU recently. Mostly a database issue on the unit itself.

    I should have known this but basically what enphase does is they use a binary (emu) to gather stats from the inverters and put it into an sqlite database. It continuously updates the database at specific time intervals and fires a cron job to do a bin-roll in an attempt to not grow the database file too large and also to retain the data. When the unit is connected to the service , the scripts clear the disk automatically and the database is flushed.

    But if you don't have it pluged into the network, I gotta do this myself. This part is not a problem. Except when I do start cleaning out the binned.db file where the data is stored for the panels, the operation can take a while and thus locking up the db and causing some issues. I wrote a script that will rebuild this database so should be quick.

    Anyway the main issue I do have tho is that although my inverters will last 300+ years, at the write cycles this thing does, I don't think my monitoring unit will last as long. The flash memory will start failing possibly.

    I really don't wanna spend $300 for another unit so I mounted a usb flash memory stick and mounted it in /var/opt/emu .. Now I'm writing to USB instead and if that goes bad , easy to replace.
  • sandeensandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    andyman wrote: »
    Anyway the main issue I do have tho is that although my inverters will last 300+ years, at the write cycles this thing does, I don't think my monitoring unit will last as long. The flash memory will start failing possibly.

    I really don't wanna spend $300 for another unit so I mounted a usb flash memory stick and mounted it in /var/opt/emu .. Now I'm writing to USB instead and if that goes bad , easy to replace.

    300 years ;) Mine has a microSD card in it too, which seems unused, that might be another option. The USB stick is simpler, I suppose.

    Have you written up your findings on the database schema anywhere?

    The other thing I want to work out is why the unit is so dog-slow, for example loading the production page takes 10s sometimes. Querying the unit more than every 10m seems to overload <something> to the point where it stops reporting. Crazy.
  • andymanandyman Solar Expert Posts: 32
    Re: Enphase Data Access

    The reason why its so slow is the emu software that does the data query on the inverters is also the webserver. It is 1 application that is the core of the entire system (/opt/emu/bin/emu). I bet its not multithreaded, and if it is, very poorly threaded. Anyway you hit this piece of code and have to wait your turn to pull the data back.

    If you poll it too much you could trip the watchdog and it will reboot the entire emu. So using the web interface is at your own risk. Especially for data polling.

    However if you poll the sql database directly there is no problems and you can poll it very quickly. My data returns instantly using the sql i posted earlier in this thread.
  • ag4wakeag4wake Registered Users Posts: 18
    Re: Enphase Data Access

    I mentioned I'd post the pictures of my envoy circuit board. Here they are.

    http://www.flickr.com/photos/[email protected]/sets/72157626078050734/

    I also was able to get sandeen's pvoutput.org script running on my server and my output is being posted now. The average power doesn't look quite right, but it's a work in progress. I haven't had time to look at the script more to see what's the issue there. I also can't seem to have the graphs posted publicly. So I can't yet link to it here.

    Alan
  • sandeensandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    ag4wake wrote: »
    I mentioned I'd post the pictures of my envoy circuit board. Here they are.

    http://www.flickr.com/photos/[email protected]/sets/72157626078050734/

    I also was able to get sandeen's pvoutput.org script running on my server and my output is being posted now. The average power doesn't look quite right, but it's a work in progress. I haven't had time to look at the script more to see what's the issue there. I also can't seem to have the graphs posted publicly. So I can't yet link to it here.

    Alan

    Guess they saved a few pennies on components eh :)

    Not sure what you mean about not being able to post a link, I didn't have any trouble with that as far as I know. Mine is http://pvoutput.org/list.jsp?userid=1241 - does that not work for your userid? (I get that when I go to "your outputs")

    The avg. power oddity is probably because of the 1kWh steps the Envoy reports. To pvoutput it looks like a big surge, I guess, when it jumps from 4kWh to 5kWh in the course of 10 minutes. I modified ruby in the envoy to print a couple decimal places, and it smooths it out. I'm not sure what the point of the "avg power" is on pvoutput.org anyway, to be honest.
  • sandeensandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    andyman wrote: »
    The reason why its so slow is the emu software that does the data query on the inverters is also the webserver. It is 1 application that is the core of the entire system (/opt/emu/bin/emu). I bet its not multithreaded, and if it is, very poorly threaded. Anyway you hit this piece of code and have to wait your turn to pull the data back.

    If you poll it too much you could trip the watchdog and it will reboot the entire emu. So using the web interface is at your own risk. Especially for data polling.

    However if you poll the sql database directly there is no problems and you can poll it very quickly. My data returns instantly using the sql i posted earlier in this thread.

    Perhaps, but I think the Ruby is a bit borked too. Running the production webpage script, it issues 1000 stat() calls, 90% of which are ENOENT as it looks for libraries to load in various places.

    If I take out all db calls from the script, and leave only "require" of the one library at the top, the script still takes 6s or so to run(!).
  • CORNWALLAV8RCORNWALLAV8R Registered Users Posts: 5
    Re: Enphase Data Access

    You guys are starting to make me envious. My 10kW system hardware is almost all here, ready to be installed. I have received the (2) massive 2 axis tracking systems, and am currently constructing the foundation steel reinforcement and digging for the 7' deep foundation concrete for them. Once it is done, and making power, I am hopeful to venture into this endeavor to access the data. Was kinda hoping for some "English language instructions" to implement my own power data monitoring. I'm an electrical engineer, but not a computer techie to the extent some of you are, so hopefully somebody will help us out in this regard.

    Linux isn;t my native tongue, but I took the step of installing it onto a spare laptop...gearing up!

    I would post some pics of my tracker hardware but not sure a) how to do it here or b) anybody wants to see them... :-)
    Cheers, and thanks.
  • sandeensandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    Once it is done, and making power, I am hopeful to venture into this endeavor to access the data. Was kinda hoping for some "English language instructions" to implement my own power data monitoring. I'm an electrical engineer, but not a computer techie to the extent some of you are, so hopefully somebody will help us out in this regard.

    One thing to keep in mind is that you can do whole-array solar production monitoring without bothering with the Envoy at all; normal monitors with current transformers like the TED 5000 or the Brultech unit can do that just fine. The Envoy unit has per-module tracking which is neat, but you can make pretty graphs without it ...

    My biggest thing is I want consumable, accessible data. Honestly even if Enphase put up an API behind a subscription fee, it would remove some of my impetus to hack the thing. If I could get accurate, detailed, and timely data through an official API, I'd much rather do that than spend my time with a JTAG. At my salary, I've already burned up several years worth of subscription fees for the time I've put into it. :)
  • jcgee88jcgee88 Solar Expert Posts: 154 ✭✭
    Re: Enphase Data Access
    sandeen wrote: »
    I've already burned up several years worth of subscription fees for the time I've put into it. :)

    Ahhh, but think of the fun you've had doing it!

    John
  • System2System2 Posts: 6,290 admin
    Re: Enphase Data Access

    I will be using an enphase EMU soon and I'm also curious about the technical details. I'm glad you guys were already able to get into the thing and check out the linux environment. Has anyone done any analysis on the powerline communications between the microinverters and the EMU? What powerline communications standard are they using? Is the communications authenticated or encrypted? Are there any off-the-shelf devices that would allow someone to directly communicate with the microinverters without using an EMU?

    On the EMU side, has anyone found a way to access the EMU directly without using JTAG? I noticed that people have recovered the password file and found an ssh port open. Has anyone recovered the password? Has anyone been able to get in through the serial console or even better through some sort of network access using a system flaw?

    Finally, has anyone looked into the nature of the openvpn tunnel they create? What kind of addresses are they assigning? Is the link permanently up? What kind of information flows over the tunnel?
  • dak664dak664 Registered Users Posts: 14 ✭✭
    Re: Enphase Data Access
    newsh wrote: »
    Has anyone done any analysis on the powerline communications between the microinverters and the EMU? What powerline communications standard are they using? Is the communications authenticated or encrypted? Are there any off-the-shelf devices that would allow someone to directly communicate with the microinverters without using an EMU?
    See post 25 of this thread. The Ariane firmware is available, if that is indeed what they are using.
    http://www.arianecontrols.com/firmware.php
    I have a one enphase but have not opened it up to see what chips are inside. I did scope the powerline, filtering for the expected signals but don't see anything. It appears the units don't transmit until they receive the right external request. Someone with functioning two-way communication would have to verify that (and hopefully discover the interrogation code).
  • System2System2 Posts: 6,290 admin
    Re: Enphase Data Access

    a few more questions.. does anyone have a copy of the binaries from the EMU device? I would love to get a copy of the full filesystem image. (I have an EMU device of my own here, though I do not have access to the embedded linux). Has anyone done any analysis on them yet?
  • System2System2 Posts: 6,290 admin
    Re: Enphase Data Access
    dak664 wrote: »
    See post 25 of this thread. The Ariane firmware is available, if that is indeed what they are using.
    http://www.arianecontrols.com/firmware.php
    I have a one enphase but have not opened it up to see what chips are inside. I did scope the powerline, filtering for the expected signals but don't see anything. It appears the units don't transmit until they receive the right external request. Someone with functioning two-way communication would have to verify that (and hopefully discover the interrogation code).

    Thank you. Indeed, the flickr images of the PCB posted earlier show the ariane PLM-1 chip. Interestingly, Ariane sells an eval board. I wonder if it is suitable for communicating directly to the microinverters or viewing the data exchanged between inverters and EMU. The board has a power connector and an RS232 jack. http://www.arianecontrols.com/evaluation.php

    Does anyone know if the redboot configuration tries to boot off of anything other than the built in sdram? Ie. the sdcard, a USB attached device or over the NIC?
  • sandeensandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    newsh wrote: »
    a few more questions.. does anyone have a copy of the binaries from the EMU device? I would love to get a copy of the full filesystem image. (I have an EMU device of my own here, though I do not have access to the embedded linux). Has anyone done any analysis on them yet?

    Distributing all the binaries would almost certainly violate copyright and/or license. Not all of it is GPL, of course.
    newsh wrote: »
    Does anyone know if the redboot configuration tries to boot off of anything other than the built in sdram? Ie. the sdcard, a USB attached device or over the NIC?

    I've got the redboot config, and have dumped it with the fconfig tool. Here's why you can't get in ;)

    boot_no_break: TRUE

    which is an enphase-special config/patch.

    There's also hope here maybe?

    bootp: TRUE

    but in some quick fiddling I don't think I was able to get it to request a boot image over tftp. Might be worth further investigation though.
  • dreesdrees Solar Expert Posts: 481 ✭✭✭
    Re: Enphase Data Access

    Anyone notice that Enphase has made an API available to developers? I haven't signed up myself, yet.

    http://www.enphaseenergy.com/api/
  • sandeensandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    drees wrote: »
    Anyone notice that Enphase has made an API available to developers? I haven't signed up myself, yet.

    I missed that. Got details? :)
  • solar_davesolar_dave Solar Expert Posts: 2,382 ✭✭✭✭
    Re: Enphase Data Access
    sandeen wrote: »
    I missed that. Got details? :)

    http://www.enphaseenergy.com/api/
  • System2System2 Posts: 6,290 admin
    Re: Enphase Data Access
    sandeen wrote: »
    Distributing all the binaries would almost certainly violate copyright and/or license. Not all of it is GPL, of course.

    I own an EMU box which has the binaries on it. I am simply asking someone who has already extracted the binaries to provide me with a backup of the binaries on my device. I can provide proof on demand. I do not have a JTAG rig to extract the binaries myself. I am not interested in violating the copyright, but I believe I have a legal right to access the binaries.
    sandeen wrote: »
    I've got the redboot config, and have dumped it with the fconfig tool. Here's why you can't get in ;)

    boot_no_break: TRUE

    They manufacture these boxes with the flash chip soldered on the board. I imagine they have some mechanism for installing the software on the flash at the factory, perhaps involving JTAG. They probably also have some mechanism to force a software update on a device in the field while it is "offline". Perhaps by plugging in some kind of usb flash device, or perhaps by having it netboot. Its possible they did this in a secure fashion (ie. by baking in a public key, and refusing to boot any image that is not signed with the matching private key), but often manufacturers skip this step and allow booting of an arbitrary image. At any rate, if there is such a mechanism, it might be possible to get access to the EMU device you own to poke around and explore the system further.

    Having access to the binaries for the system would make it a lot easier to analyze this. It would also make it easier to look for defects that might allow simpler access (ie. if there are security issues in the ruby web scripts which might allow shell access via an HTTP request).
  • sandeensandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    newsh wrote: »
    I own an EMU box which has the binaries on it. I am simply asking someone who has already extracted the binaries to provide me with a backup of the binaries on my device. I can provide proof on demand. I do not have a JTAG rig to extract the binaries myself. I am not interested in violating the copyright, but I believe I have a legal right to access the binaries.

    Well, if you can show me in their license where they say it's ok for me to send you binaries, I'll do it ;) Otherwise, no ... I do understand your plight; and it's doubly hard since I'm pretty confident they are (unintentionally, I hope) violating the GPL, something I intend to keep pursuing. But I'm not in a position to redistribute their non-GPL'd bits, sorry.
    newsh wrote: »
    They manufacture these boxes with the flash chip soldered on the board. I imagine they have some mechanism for installing the software on the flash at the factory, perhaps involving JTAG. They probably also have some mechanism to force a software update on a device in the field while it is "offline". Perhaps by plugging in some kind of usb flash device, or perhaps by having it netboot. Its possible they did this in a secure fashion (ie. by baking in a public key, and refusing to boot any image that is not signed with the matching private key), but often manufacturers skip this step and allow booting of an arbitrary image. At any rate, if there is such a mechanism, it might be possible to get access to the EMU device you own to poke around and explore the system further.

    Having access to the binaries for the system would make it a lot easier to analyze this. It would also make it easier to look for defects that might allow simpler access (ie. if there are security issues in the ruby web scripts which might allow shell access via an HTTP request).

    Agreed, there must be some way. I still mean to look into bootp methods, and maybe I can see if it does anything with USB attached. Granting you access to my system might be some middle ground, but then of course I have to trust you to behave while groveling around in my envoy ;) I'll see what I can come up with.

    There are very few input fields in the ruby html code, and every one I looked at seems robust, FWIW.
  • System2System2 Posts: 6,290 admin
    Re: Enphase Data Access

    Andy,

    stat1 looks likely to be Joules. Using it should be more accurate than the (possibly instantaneous?), value you get using stat4 and stat5.

    Kirk
    andyman wrote: »
    Ok I guess I'm still a little puzzled by the stats. I dug a little deeper and it looks like the way the EMU works is that there is a daemon called emu /opt/emu/bin/emu runs constantly. This software is what either polls data or gathers data from the actual inverters and its output is an sqlite database as I've been referring to located on /var/opt/emu

    Now the actual data for each panel is stored in binned/binned.db under the channel_perf_interval tables.

    What I don't understand is what is stat1 (11793). Its definitely not watts.

    ******** update *****

    Since I don't know what stat1 is I've decided its easier just to multiply the DC voltage with the current (stat4 * stat5 /1000000) = watts. I then set my graph up such that Y has a max of 200watts. Using mrtg to graph. I've now got a virtual display of how all my panels are doing and how shade affects each panel. Not as pretty as enphases flash but it will get the job done perfectly.


    andy

    ********************


    A sample line of that table is below.
    783161|1|822329601|1290788400|300|300|1|0|11793|244510|60050|30833|1375|12|0|0|1290788206


    where
    item 1 = 783161 = interval_id
    2 interval type
    3 device_id
    4 interval_duration (300 )
    5 stat_duration (happens to be 300)
    6 complete
    7 exported
    8 stat1 (11793) energy produced
    9 stat2 (244510) 244 volts AC voltage
    10 stat3 (60050) 60.050 hz
    11 stat4 (30833) 30.833V DC voltage
    12 stat5 (1375) 1.375A DC current
    13 stat6 (12) 12 Celcius
    14 stat7 (0) errors_sec
    15 stat8 (0) max error cycles
    16 created_date 1290788206
  • brturnbrturn Registered Users Posts: 7
    Re: Enphase Data Access

    Hello all,

    Great thread, just getting setup to play and this information has been very helpful. My 7kW system has only been running a week, now I want full access! I've got the newer rev-3 board as seen in the latest pics on this thread. No JTAG or COM headers populated.

    Looking over the sources, I diffed against eCos 2.0 and 3.0 (from http://ecos.sourceware.org). The Envoy's redboot is closer to eCos 3.0. Only two differences I saw (in redboot/src) are the BOOTP retry time is 20 ms instead of 2000 ms, and the boot_no_break change mentioned earlier. Have not diffed the other directories yet.

    While I could certainly go the JTAG route, that won't help others who want access. I have two attack strategies that might work out for a wider audience:

    1) Locate the "boot from SD card" pin on the new Envoy board.
    2) Force redboot prompt by disabling the flash chip.


    1) Locate boot-from-sd-card pin

    The first attack vector would significantly widen the audience, since it does not require COM dongles and poking your Envoy with wires while power is connected.

    Initial examination of the chip suggests that the processor is the Freescale Semiconductor MX27L 19x19mm 473-pin package (datasheets here: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX27L&fpsp=1&tab=Documentation_Tab).

    [UPDATE: BOOT pins are not tied to Redboot boot-select as I had originally thought]
    This places the BOOT3 boot-select pin accessible along the outer edge of the chip (location W23). The other boot-select pins are hidden under the package and would have to be accessed from below the board (if indeed there are traces to them at all).

    The post from nbias reports the current boot mode as [NOR Flash], which is boot-pin configuration 0x00 in the source code. This suggests that we need only hold boot3 high in order to force boot from sd card (value 0x40). Since location W23 is edge-exposed, this should make tracing this pin relatively easy. (see picture)


    2) Disable the flash chip

    The second attack seems quite feasible but has a few cases to consider.

    Case 1: Redboot stored in MX27L internal flash

    In this case the external flash chip can be disabled before booting the unit. Redboot is loaded and attempts to run the boot script from the external flash module but cannot. Redboot drops immediately to a prompt.

    Case 2: Redboot loaded from external flash

    [UPDATE: Case 2 is verified]
    If redboot is loaded from the external flash chip, then we would have to disable the flash chip AFTER redboot is loaded, but before executing the boot script. This is about a 1 second window.

    Case 3: Everything copied to RAM before execution

    Unfortunatley, it is also possible that the initial boot code simply copies the entire redboot + kernel into RAM and accesses the boot script there. Thus disabling the flash chip cannot achieve our goal.

    [EDIT: Sorry, this is the wrong chip! The NOR Flash is on the other side of the board. I'll post a followup about it.]
    The flash chip is a Micron 512 MB NAND flash MT29F4G08ABC. This chip exposes several attack vectors, specifically the ALE line, which can be pinned to ground to disable reading from the chip (I suggest a 400+ Ohm resistor as current limiter). Assuming this does not cause an interrupt in some other part of the code (or fry the upstream circuit), the flash chip will appear to be disabled or in an error state.

    I selected the ALE line since it is easily located by a novice, has a large header on the board away from other components, and can be pinned to ground (easier for non-techies to find ground). Other alternatives exist, but this seemed safest. (see picture)

    TODO:
    - Diff all eCos directories and sift out the important changes.

    Attack #1:
    - Test BOOT3 pin connectivity with ground (may be direct-tied to ground). Anything over 1MOhm should be safe to pull up.
    - Expose traces for possible BOOT3 pins (see pic), check connectivity with BOOT3 pin on MX27L chip.
    - Trace the BOOT3 pin line to other parts of the board - is there an un-populated header or resistor where the boot pins terminate?

    Attack #2:
    - Verify case 1 or 2 for attack #2. Ground ALE pin during bootup, connect via telnet to port 9000 and check for redboot prompt.
    - Failing that, attempt the attack in the delay between redboot initialization and boot script execution.

    Comments, suggestions? May be a few days before I can try any of these.
    --Bryan
  • sandeensandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access

    It is a great thread, isn't it ;)
    brturn wrote: »
    1) Locate boot-from-sd-card pin

    The first attack vector would significantly widen the audience, since it does not require COM dongles and poking your Envoy with wires while power is connected.

    Initial examination of the chip suggests that the processor is the Freescale Semiconductor MX27L 19x19mm 473-pin package (datasheets here: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX27L&fpsp=1&tab=Documentation_Tab).

    This places the BOOT3 boot-select pin accessible along the outer edge of the chip (location W23). The other boot-select pins are hidden under the package and would have to be accessed from below the board (if indeed there are traces to them at all).

    The post from nbias reports the current boot mode as [NOR Flash], which is boot-pin configuration 0x00 in the source code. This suggests that we need only hold boot3 high in order to force boot from sd card (value 0x40). Since location W23 is edge-exposed, this should make tracing this pin relatively easy. (see picture)

    if anyone still has the old envoy with the boot-from-sd jumper, maybe this could be confirmed...
  • brturnbrturn Registered Users Posts: 7
    Re: Enphase Data Access

    Digging a little deeper on the boot-selection; the RedBoot boot select is not tied to the boot-select pins on the MX27 as I originally thought. Instead, it is activated by asserting interrupts to the ARM core. These can be asserted in hardware (inputs to the core), or in software.

    There is no place in the Envoy source code where the MMC interrupt is asserted in software. I diffed the ecos package from Enphase against the ecos package from Freescale (version redboot_200845) and did not see any obvious changes to the MMC flags.

    Assuming the source code is correct, and the hardware is equivalent to the old Envoy, then there exists an input to some peripheral chip which asserts this interrupt. I cannot find any documentation on which pins of the MX27 are used to signal interrupts to the AITC (interrupt controller). Perhaps there's a platform reference?


    I dug a bit more on the flash disable attack as well. The effect I was going for was to force the boot script to be invalid (or blank) and thus drop to a prompt. It appears that RedBoot and the boot script are loaded from flash together, so case #1 is eliminated. Case #2 might still work, but the boot script will still be executed, so the commands "fis load .." followed by "exec ..".

    If the chip is disabled before running the script (case #2), then the fis load will read all-zero data into memory instead of a kernel image. Don't know if this causes the script to abort or if this behavior is ignored.

    The "exec" command only has a few failure cases, none of which seem to be hit by reading a null-kernel into memory, so this command will jump to a buffer full of zeros and cause a crash. Don't know if RedBoot takes over again in this case.

    --Bryan
  • sandeensandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access

    At one point, the old envoy apparently came from the ts-linux/embeddedarm.com folks. The older one, from another comment in this thread, said:
    Loading emuk2u...Using /lib/modules/2.6.24.7-ee404/kernel/drivers/emuk2u/emuk2u.
    ko
    done
    LCD Timeout
    Starting emu...done
    
    
    Technologic Systems TS-LINUX/arm 7.0
    envoy login:
    

    The new one has uname 2.6.24.7-eee62a87, so presumably the same shop? I wonder if reading up on the tslinux boards might offer a hardware clue. They have schematics, manuals, etc available for download.

    On edit - probably the 7800 board? Based on info in the makefile in the kernel tarball:
    # Targets for the Enphase EMU Products
    VARIANTS                = 7800 mx27 mx27ads
    
Sign In or Register to comment.