[Pull Request] Several Kinetis KL-series peripherals implemented in QEMU

peripherals found in the Kinetis KL-series

ok, great!

I'm not familiar with the KL peripherals, but in my oppinion the minimum that needs to be implemented are those peripherals used by CMSIS SystemInit & Co., possibly by the special initialisations used in KDS templates, if any.

the goal is to run a simple blinky application, similarly to those for STM32F4-Discovery.

are you considering adding the LED definitions to the boards?

could you also correctly update the internal system clock, so that SysTick runs at the correct speed?

also I'm curious why did you choose not to use the new register definitions, and implement everything by hand?

the idea is that in a future version I plan to read the vendor SVD files and generate all processor registers automatically, so I would not spend much time with manual definitions.

it looks like you based your work on a preliminary version of GNU ARM QEMU, perhaps it would be useful to check the latest version.

Some background on this PR: My intention was to use QEMU to perform automated testing on a project I designed around a KL03. So I searched for a fork of QEMU that had done the most work towards supporting the KL series (that is, this fork) & implemented all the peripherals my particular project needed in order to not hard fault ;-)

in my oppinion the minimum that needs to be implemented are those peripherals used by CMSIS SystemInit & Co.

Looking through the SystemInit function in system_MKL03Z4.c, it reads/writes to registers under PMC, SIM, SMC, PORTA, MCG and OSC, though all under a net of #ifdefs. In my case, the init routine only wrote to SIM, SMC, MCGLite & PORT. So 67% of the work is done - only PMC and OSC need to be implemented for the default startup routines to work in all use cases.

I can make whatever small tweaks might be necessary to make these fit in with the GNUArmEclipse code base, but since this development has been sponsored by my employer & the project I was working on is now completed, I can't justifiably put in the time required to implement the remaining 2 peripherals.

the goal is to run a simple blinky application, similarly to those for STM32F4-Discovery.
are you considering adding the LED definitions to the boards?

I'm not totally sure what you mean by the LED definitions. My project controls some LEDs, but it just sets the appropriate GPIO pin high/low to turn on/off the LED, and that's handled correctly in my implementation of the GPIO/PORT peripheral. Whereas the UART can be interfaced with over stdio, I couldn't find any resources to access the GPIO pins externally, so the way that I verify the state of an output pin/LED in my tests is to attach a gdb process to the program being simulated & p/x {uint32_t} 0x400FF000 (i.e. inspect the Port Data Output Register). Inputs are achieved the same way, but by writing to the Port Data Input Register instead.

could you also correctly update the internal system clock, so that SysTick runs at the correct speed?

I could look into this. At a glance, it looks like I can just write to the global system_clock_scale variable defined in hw/arm/arm.h? That one seems to be in units of 100 kHz (?), and I believe you can run many of these micros of the 32 kHz crystal, so I'm not sure how that would be reconcilable.

also I'm curious why did you choose not to use the new register definitions, and implement everything by hand?

Well I did much searching online and through the codebase for documentation on how to add new peripherals before beginning. The internals of the QEMU codebase seemed, from my point of view, extremely under-documented. In the end I just took an existing peripheral, cloned it and modified it to match the Kinetis implementation, then repeated with the rest. I looked through about a dozen peripheral implementations & this is how they all seemed to function.

I'm not totally sure what you mean by the LED definitions.

if you have a few minutes, please update to the latest Eclipse plug-ins and the latest QEMU and follow the steps from:

http://gnuarmeclipse.livius.net/blog/blinky-project/

or at least please take a look at the picture from:

http://gnuarmeclipse.livius.net/blog/2015/08/02/gnu-arm-eclipse-qemu-2-3-50-20150801-dev-released/

the 4 LEDs are defined in:

https://github.com/gnuarmeclipse/qemu/blob/gnuarmeclipse-dev/hw/arm/stm32-boards.c

Well I did much searching online... I looked through about a dozen peripheral implementations...

yes, but you just used my deprecated APIs, which will no longer be supported in future versions, and missed the point with the new mechanisms I added, which are not present in the original QEMU.

please take a look at the stm32-gpio implementation:

https://github.com/gnuarmeclipse/qemu/blob/gnuarmeclipse-dev/hw/gpio/stm32-gpio.c

there are two important points:

• the register definitions, which for now are writen by hand, but in the future will be derived from the CMSIS SVD files
• the read/write callbacks, which obviously need to be written by hand to implement the functionality

also the MCUs should be defined in terms of capabilities, and the actual peripherals should test these bits, to implement various families and subfamilies in the same file, otherwise code duplication creates a big maintenance problem.

http://gnuarmeclipse.livius.net/blog/2015/08/02/gnu-arm-eclipse-qemu-2-3-50-20150801-dev-released/

Ah, I see. No, my interest is only in implementing the MCU - I added a board definition just because the examples I found were for launching FRDM-xxx boards rather than specific MCUs & I thought it'd be easiest to just follow that convention.

yes, but you just used my deprecated APIs, which will no longer be supported in future versions, and missed the point with the new mechanisms I added, which are not present in the original QEMU.

The APIs I used are the ones exposed in vanilla QEMU (i.e. MemoryRegionOps: https://github.com/gnuarmeclipse/qemu/blob/master/include/exec/memory.h). There is no deprecation note anywhere in that file regarding any functions I used & MemoryRegionOps is used extensively within QEMU and on non-arm architectures, so I don't think you have to worry about these APIs going anywhere.

also the MCUs should be defined in terms of capabilities, and the actual peripherals should test these bits

Agreed. If there is an easy way to achieve this then I will modify my code to support that, provided that you think these peripherals are worth merging.

The APIs I used are the ones exposed in vanilla QEMU

cortex_m0p_core_init() is not part of the vanilla QEMU and will no longer be available in future versions.

What is the intended replacement?

please take a look at how the STM32 families are implemented.

as I already mentioned, please keep in mind that the entire mechanism of defining cores and peripherals will be migrated to a generic engine that will read external json files, prepared off-line from the CMSIS SVD files.

I don't have a deadline for this, but the use of register tables validated the concept, the difference being that those tables (slightly trimmed to match the CMSIS definitions) will no longer be entered manually.