Cool! I believe the KEAZ128 is similar to the KE04Z128, although I'll be
very curious to see the SIM_SRSID and various ID codes from it. I'm going
to be offline for a few days, but I'll shoot for getting something up to
Gerrit mid next week for folks to test out.
Cheers,
Phil
On Fri, Feb 19, 2016 at 5:54 AM, Jeffery Ciesielski <
jeffciesiel...@gmail.com> wrote:
> Hi Phillip,
>
> I've had a KEAZ128AMLK board sitting on my desk for like 6 months and
> just haven't gotten around to starting to hack on it yet, so I'm glad
> somebody is moving forward :). Let me dig through the TRMs and see if the
> EA8 family shares a flash controller (it's an automotive part), I'd love to
> just provide support in your driver if possible.
>
> Jeff
>
> On Fri, Feb 19, 2016 at 4:39 AM Tomas Vanek <tom_...@users.sourceforge.net>
> wrote:
>
>> On 19.02.2016 8:50, Phillip Pearson wrote:
>>
>> Thanks Tom!
>>
>> I have a few questions about coding style / acceptable changes in OpenOCD.
>>
>> 1. It would be super super useful if struct target had a void
>> *driver_priv member, like struct flash_bank. The target detection code in
>> kinetis.c is a bit scattered currently, and it stores target-specific stuff
>> like the SIM_SDID register value using flash_bank.driver_priv (struct
>> kinetis_flash_bank). This is manageable when only targetting K and L
>> devices, but E devices have a very different register layout, so there's a
>> lot of redundant probing without anywhere to cache it. Would it be OK if I
>> added a void *driver_priv to struct target?
>>
>>
>> Please do not regard kinetis.c as coding style quality example. IMHO
>> parts of this code would need a substantial
>> rewrite (and yes, SDID detection should be processed once per MCU and not
>> per flash bank as you pointed out). Unfortunately without support from
>> Freescale it is very hard to test changes with sufficient coverage
>> of Kinetis portfolio. So my personal policy in this particular driver is
>> not to touch what is working.
>>
>> There is not a lot of common between KE and other Kinetis series and also
>> automatic detection KE and others
>> could be problematic. I would recommend to write a new, simple and clean
>> flash driver for KE only.
>>
>>
>> 2. Is it OK to create helper functions for things that currently have a
>> lot of boilerplate code? For example, allocating a work area, copying in
>> code, initializing r0/r1/r2, and executing the code.
>>
>> No problem. Submit the code and reviews show.
>>
>> 3. I've written a Python script that will run a C file declaring a naked
>> function through arm-none-eabi-gcc to generate an assembly listing, then
>> extract the opcodes and output them as a C file that defines a static const
>> uint8_t[] array, like kinetis_flash_write_code in kinetis.c. Where would
>> be the best place to put this? Should I cut and paste the code into
>> kinetis.c (following existing convention) or #include it from elsewhere?
>>
>> There is a simpler way: src/helper/bin2char.sh - see
>> http://openocd.zylin.com/#/c/3134/
>> and http://openocd.zylin.com/#/c/3235/
>>
>> Thanks!
>> Phil
>>
>> Not at all
>>
>> Tom
>>
>>
>>
>> On Thu, Feb 18, 2016 at 11:30 PM, Tomas Vanek <
>> tom_...@users.sourceforge.net> wrote:
>>
>>> Welcome on board, Phil.
>>>
>>> Jeff wrote a mail with subject "Kinetis-KEx flash support" 4 month ago.
>>> There is no KE-related work submitted in gerrit so I suppose nobody is
>>> working on it.
>>>
>>> I have a custom testing board with MKE06Z128. I will help with driver
>>> testing/review.
>>>
>>> Please follow HACKING file in OpenOCD root directory for instructions
>>> how to submit a change.
>>>
>>> Tom
>>>
>>>
>>> On 19.02.2016 5:09, Phillip Pearson wrote:
>>>
>>> Hi,
>>>
>>> I've been hacking up a flash driver for OpenOCD for the Kinetis E series
>>> of chips. I have it currently working for the MKE02Z64VLD2 (FTMRH flash
>>> controller), programming and debugging via Kinetis Design Studio.
>>>
>>> Is anyone else working on Kinetis support right now? I have some
>>> MKE04Z8VTG4 boards I can use to program support for the FTMRE controller,
>>> and have ordered a bunch of samples of different Kinetis E chips (different
>>> sizes and speeds of MKE02/04/06) so I can test a bit better.
>>>
>>> I gather the procedure for getting code into OpenOCD is to upload it to
>>> Gerrit for review?
>>>
>>> Cheers,
>>> Phil
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup
>>> Now!http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenOCD-devel mailing
>>> listOpenOCD-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/openocd-devel
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>> _______________________________________________
>> OpenOCD-devel mailing list
>> OpenOCD-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openocd-devel
>>
>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
