DarkDave said:
Thanks for all the great info! The Marvell processor has an ARM5 core. http://www.marvell.com/products/processors/applications/pxa_family/pxa_27x_emts.pdf
Wow, small world! I'm very familiar with the processor in the Blink. I was part of the team that did validation on this processor back in 2002-2003 timeframe. It actually uses the Intel XScale core architecture, which is an ARM 5TE compatible core. I bet that the Linux distro is most likely based on a MontaVista, Wind River, or a Debian ARM distro. I did quite a bit of testing under Linux for the XScale processors. I haven't cracked the case on my Blink to download the contents of the SD card, but I'm betting that some of the WiFi issues I've seen are due to a combination of the older kernel (2.6.20) being used and the WiFi management tools.
Modding the OS image for these is pretty straightforward. Build a new OS image with the same tools in the current image (Python, QT, BusyBox, etc.), then copy over any custom scripts or binaries for the charging hardware. I'm curious to see if all the charging is handled in Python scripts, which would make it very easy to debug. If it is all in Python, then we could add in some code to give us more diagnostic output when the charging fails. We could also add in sshd which would allow remote logging in to the units. The only debug output shown on the panel is the syslogd output, which isn't too helpful since none of the charging status is logged.
Nice to see we have some talent here in the forum! They're kernel is indeed based of the MontaVista work that was submitted to kernel.org and is based off a kernel.org 2.6.20 build. The charging logic is controlled by the python scripts by calling pxaregs (a simple console app to hit GPIO registers). They poll everything :evil: .
So I have a new SD card image almost complete, I've recompiled all of QT and its dependencies and busybox. I have the kernel source but haven't recompiled it. The item that I'm working right now is I'm writing a simple QT application (the right way
) to display charging status and to turn off the backlight during inactivity. We will envolve the app over time to display cool things and maybe my first public rev will display the weather....From my preliminary versions its extremely responsive and works well. Oh yeah I've never had the charger crash or stop charging, like the Blink firmware did for me 3 times.
Just for those who know better and directed towards Ingineer the following are the GPIO mapping for the J1772 board. The GPIOs are numbered with respect to the PXA.
The first 3 GPIOs are outputs and driven by the PXA.
96 = "Reset" -- active high. Must reset the PIC once per boot.
97 = "Stop" -- active high. I leave this low always. I have verified this actually stops charging.
98 = "Enable -- active low. I leave this low always. I have yet to get this GPIO to do anything for me.
The next 5 GPIOs are inputs to the PXA.
95 = "Ready" -- active high.
101 = "Connected" - low = charge port not connected, high = charge port connected
99 = "Charging" - low = not charging, high = charging. This will toggle really quickly if you have a Leaf charging timer enabled.
100 = "Protection" - low = no issue, high = issue. Haven't been able to test. Want one of those testers that the installers have.
102 = "Error" - low = no error, high = error. Once again haven't been able to test.