* [Bug 1001814] New: Kinetis clock gating
@ 2013-04-04 19:43 bugzilla-daemon
2013-04-04 19:44 ` [Bug 1001814] " bugzilla-daemon
` (25 more replies)
0 siblings, 26 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-04 19:43 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
Bug ID: 1001814
Summary: Kinetis clock gating
Product: eCos
Version: CVS
Target: freescale_twr_k70f120m (Freescale Kinetis TWR-K70F120M
board)
Architecture/Host Cortex-M
OS:
Status: NEW
Severity: enhancement
Priority: low
Component: Patches and contributions
Assignee: unassigned@bugs.ecos.sourceware.org
Reporter: ilijak@siva.com.mk
CC: ecos-patches@ecos.sourceware.org
Created attachment 2155
--> http://bugs.ecos.sourceware.org/attachment.cgi?id=2155&action=edit
Kinetis HAL clock gating
Current Kinetis HAL enables all peripheral clocks at startup which usually
causes unnecesarry high power consumption. Submitted patches provide clock
gatinf support at varian level and instantiate clock gating in available device
drivers. Also general startup clock gating is removed.
Ilija
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
@ 2013-04-04 19:44 ` bugzilla-daemon
2013-04-04 19:57 ` bugzilla-daemon
` (24 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-04 19:44 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2156
--> http://bugs.ecos.sourceware.org/attachment.cgi?id=2156&action=edit
Clock gating support for devices related to Kinetis HAL.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
2013-04-04 19:44 ` [Bug 1001814] " bugzilla-daemon
@ 2013-04-04 19:57 ` bugzilla-daemon
2013-04-06 5:49 ` bugzilla-daemon
` (23 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-04 19:57 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
Ilija Kocho <ilijak@siva.com.mk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1001815
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
2013-04-04 19:44 ` [Bug 1001814] " bugzilla-daemon
2013-04-04 19:57 ` bugzilla-daemon
@ 2013-04-06 5:49 ` bugzilla-daemon
2013-04-06 6:17 ` bugzilla-daemon
` (22 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 5:49 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
Mike Jones <mjones@linear.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mjones@linear.com
--- Comment #2 from Mike Jones <mjones@linear.com> ---
Ilija,
The only problem I had compiling was this macro:
CYGHWR_HAL_KINETIS_PIN_CFG
which was defined as:
CYGHWR_HAL_KINETIS_SETUP_PIN
which is the name I used in my GPIO patch.
Mike
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (2 preceding siblings ...)
2013-04-06 5:49 ` bugzilla-daemon
@ 2013-04-06 6:17 ` bugzilla-daemon
2013-04-06 12:47 ` bugzilla-daemon
` (21 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 6:17 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #3 from Mike Jones <mjones@linear.com> ---
Ilija,
I think the problem was you incorporated part of my GPIO patch and I patched
against my changes rather than a fresh tree. So with some hand editing I fixed
it. I can run my applications tomorrow to make sure nothing breaks and perhaps
play with the added API a little to turn off what I am not using.
I noticed the datasheet says in section 5.6 the peripheral should be disabled
before stopping their clock. I did not look, but is there API similar to these
+__externC void hal_clock_enable( cyg_uint32 clkcd );
+__externC void hal_clock_disable( cyg_uint32 clkcd );
for disabling peripherals? If not, I wonder if the clock API should handle that
at the same time. I assume that stopping a clock and then enabling it again
with the peripheral enabled might lead to unpredictable behavior. Perhaps
disable clock should disable the peripheral. I am not sure I would want it to
enable it, in case some setup was required before starting the clock.
Mike
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (3 preceding siblings ...)
2013-04-06 6:17 ` bugzilla-daemon
@ 2013-04-06 12:47 ` bugzilla-daemon
2013-04-06 12:49 ` bugzilla-daemon
` (20 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 12:47 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
Ilija Kocho <ilijak@siva.com.mk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #2155|0 |1
is obsolete| |
--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2162
--> http://bugs.ecos.sourceware.org/attachment.cgi?id=2162&action=edit
Kinetis HAL clock gating (fix, ref comment 3)
Mike
(In reply to comment #3)
> Ilija,
>
> I think the problem was you incorporated part of my GPIO patch and I patched
> against my changes rather than a fresh tree. So with some hand editing I
> fixed it. I can run my applications tomorrow to make sure nothing breaks and
> perhaps play with the added API a little to turn off what I am not using.
Thank you for the catch. It is there by accident. I used the same eCos
repsitory for testing of your contribution and it slipped of my mind.
Here I post a fixed patch.
>
> I noticed the datasheet says in section 5.6 the peripheral should be
> disabled before stopping their clock. I did not look, but is there API
> similar to these
>
> +__externC void hal_clock_enable( cyg_uint32 clkcd );
> +__externC void hal_clock_disable( cyg_uint32 clkcd );
>
> for disabling peripherals? If not, I wonder if the clock API should handle
> that at the same time. I assume that stopping a clock and then enabling it
> again with the peripheral enabled might lead to unpredictable behavior.
> Perhaps disable clock should disable the peripheral. I am not sure I would
> want it to enable it, in case some setup was required before starting the
> clock.
Devices with disabled clock are inaccessible. Some are simply silent, but for
majority, access attempt raises exception. Besides this some devices have some
kind of enable feature. But there's no general rule, therefore it's up to the
device driver to take care of that.
Ilija
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (4 preceding siblings ...)
2013-04-06 12:47 ` bugzilla-daemon
@ 2013-04-06 12:49 ` bugzilla-daemon
2013-04-06 13:06 ` bugzilla-daemon
` (19 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 12:49 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
Ilija Kocho <ilijak@siva.com.mk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #2156|0 |1
is obsolete| |
--- Comment #5 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2163
--> http://bugs.ecos.sourceware.org/attachment.cgi?id=2163&action=edit
Clock gating support for devices related to Kinetis HAL. compatible with
attachment 2162.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (5 preceding siblings ...)
2013-04-06 12:49 ` bugzilla-daemon
@ 2013-04-06 13:06 ` bugzilla-daemon
2013-04-06 13:54 ` bugzilla-daemon
` (18 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 13:06 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #6 from Mike Jones <mjones@linear.com> ---
Do you think the device driver should take care of clock gating or the
application?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (6 preceding siblings ...)
2013-04-06 13:06 ` bugzilla-daemon
@ 2013-04-06 13:54 ` bugzilla-daemon
2013-04-06 13:57 ` bugzilla-daemon
` (17 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 13:54 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #6)
> Do you think the device driver should take care of clock gating or the
> application?
This is a good question for discussion. Unfortunately we do not have power
management in eCos yet.
Currently the usage of clock gating by eCos is trivial. The drivers (for HALs
where clock gaing control is implemented) only call clock enable on
initilization.
[off topic]
Mike
If you (or anybody else) do not have further objections on current patches I
would like to commit them later today or tomorrow. I have tested them on K70,
K60 and K40.
Ilija
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (7 preceding siblings ...)
2013-04-06 13:54 ` bugzilla-daemon
@ 2013-04-06 13:57 ` bugzilla-daemon
2013-04-06 14:00 ` bugzilla-daemon
` (16 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 13:57 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #8 from Mike Jones <mjones@linear.com> ---
After applying the patches, my application will not start.
It gets stuck in a polling loop for awhile in kinetic_clocking.c line 47:
MCG_WAIT_WHILE(!(mcg_p->status & CYGHWR_HAL_KINETIS_MCG_S_LOCK_M));
Or in hal_misc.c line 217
for( p = &__bss_start; p < &__bss_end; p++ )
*p = 0;
If I keep pausing, it appears to be in the bas loop but clocking very slow.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (8 preceding siblings ...)
2013-04-06 13:57 ` bugzilla-daemon
@ 2013-04-06 14:00 ` bugzilla-daemon
2013-04-06 14:08 ` bugzilla-daemon
` (15 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 14:00 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #9 from Mike Jones <mjones@linear.com> ---
Are you saying that all clocks are gated off by default until a driver gates
its own clock on? That would make some sense because it would save power and
most application writers would not have to be aware of it.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (9 preceding siblings ...)
2013-04-06 14:00 ` bugzilla-daemon
@ 2013-04-06 14:08 ` bugzilla-daemon
2013-04-06 14:21 ` bugzilla-daemon
` (14 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 14:08 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #10 from Mike Jones <mjones@linear.com> ---
Turns out I am stuck in a reset loop. I can set a breakpoint at hal_system_init
and see it keeps resetting.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (10 preceding siblings ...)
2013-04-06 14:08 ` bugzilla-daemon
@ 2013-04-06 14:21 ` bugzilla-daemon
2013-04-06 14:24 ` bugzilla-daemon
` (13 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 14:21 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #9)
> Are you saying that all clocks are gated off by default until a driver gates
> its own clock on? That would make some sense because it would save power and
> most application writers would not have to be aware of it.
Allmost all are disabled. Check reset values of SIM_SCGCn registers in your
Kinetis reference manual for details.
The current eCos HAL enables ALL clocks and the new one will enable few,
leaving clockgating to device drivers.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (11 preceding siblings ...)
2013-04-06 14:21 ` bugzilla-daemon
@ 2013-04-06 14:24 ` bugzilla-daemon
2013-04-06 14:37 ` bugzilla-daemon
` (12 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 14:24 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #12 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #8)
> After applying the patches, my application will not start.
>
> It gets stuck in a polling loop for awhile in kinetic_clocking.c line 47:
>
> MCG_WAIT_WHILE(!(mcg_p->status & CYGHWR_HAL_KINETIS_MCG_S_LOCK_M));
>
> Or in hal_misc.c line 217
>
>
> for( p = &__bss_start; p < &__bss_end; p++ )
> *p = 0;
>
> If I keep pausing, it appears to be in the bas loop but clocking very slow.
Did you apply patches to clean CVS?
What is your target?
Evantually what silicon revision?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (12 preceding siblings ...)
2013-04-06 14:24 ` bugzilla-daemon
@ 2013-04-06 14:37 ` bugzilla-daemon
2013-04-06 14:54 ` bugzilla-daemon
` (11 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 14:37 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #13 from Mike Jones <mjones@linear.com> ---
No, I did not start from a clean CVS. Then I would have to apply patches for
MMC, GPIO, I2C, etc. But I don't think I am missing any CVS updates.
I am working on K60 P2. The application works fine pre patch. The patch applied
cleanly other than a very small problem I can fix by looking at the rej file.
I suppose I can do a CVS update and rematch everything again and see how it
goes.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (13 preceding siblings ...)
2013-04-06 14:37 ` bugzilla-daemon
@ 2013-04-06 14:54 ` bugzilla-daemon
2013-04-06 15:47 ` bugzilla-daemon
` (10 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 14:54 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #14 from Mike Jones <mjones@linear.com> ---
The only thing I am missing from CVS is the floating point support. However, I
will update and repatch. I'll make a shell script that applies all the patches
so I can attach a bundle of patches in case you need to apply them to debug
sometime. Perhaps it will work after I start from fresh and that can be
avoided.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (14 preceding siblings ...)
2013-04-06 14:54 ` bugzilla-daemon
@ 2013-04-06 15:47 ` bugzilla-daemon
2013-04-06 16:34 ` bugzilla-daemon
` (9 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 15:47 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #15 from Mike Jones <mjones@linear.com> ---
I updated CVS. Reapplied my patches for FXM, MMC, SPI, I2C, GPIO, and LWIP.
Diffed the result against my working packages tree to make sure all the patches
match. DID NOT APPLY THE CLOCK GATING PATCHES. The goal being to test what is
in CVS.
I get an exception 3 at startup causing a reset. So I believe my problems are
related to what is in CVS, and may not be related to this patch.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (15 preceding siblings ...)
2013-04-06 15:47 ` bugzilla-daemon
@ 2013-04-06 16:34 ` bugzilla-daemon
2013-04-06 17:21 ` bugzilla-daemon
` (8 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 16:34 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #16 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #15)
> I updated CVS. Reapplied my patches for FXM, MMC, SPI, I2C, GPIO, and LWIP.
> Diffed the result against my working packages tree to make sure all the
> patches match. DID NOT APPLY THE CLOCK GATING PATCHES. The goal being to
> test what is in CVS.
>
> I get an exception 3 at startup causing a reset. So I believe my problems
> are related to what is in CVS, and may not be related to this patch.
If you are using FXM, that might be a problem. The CVS is not updated with
patches that I have sent you. Also there may be some divergence between CVS and
your patches due to recent large commit of FPU support.
I just tested clock gating patches against CVS on TWR-K70F120M, I ran
nc_test_slave and fileiotest These combined include hal_diag serial, Ethernet,
DMA and DSPI. I also tried RedBoot that includes Flash support.
Ilija
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (16 preceding siblings ...)
2013-04-06 16:34 ` bugzilla-daemon
@ 2013-04-06 17:21 ` bugzilla-daemon
2013-04-06 17:40 ` bugzilla-daemon
` (7 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 17:21 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #17 from Mike Jones <mjones@linear.com> ---
I am not using FXM. I just applied your patches so I can diff the trees to
ensure the patches applied properly.
I regenerated my ecc file from an ecm file on the freshly patched tree and my
application ran. I'll call this package tree A, the latest CVS with my patches.
I then patched with the clock gating patches. My application gets exception 3
or 5 at startup. I'll call this package tree B, the latest CVS, with my
patches, and the cloc kgating patches.
After a few switching back and forth between packages, I consistently have a
problem only with the clock gating tree package tree B. Always exception 3 or
5.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (17 preceding siblings ...)
2013-04-06 17:21 ` bugzilla-daemon
@ 2013-04-06 17:40 ` bugzilla-daemon
2013-04-07 5:39 ` bugzilla-daemon
` (6 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-06 17:40 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #18 from Ilija Kocho <ilijak@siva.com.mk> ---
Note: Attachment 2163 contains patches for all supported drivers except DSPI.
For DSPI support apply Attachment 2164 from Bug 1001815.
Ilija
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (18 preceding siblings ...)
2013-04-06 17:40 ` bugzilla-daemon
@ 2013-04-07 5:39 ` bugzilla-daemon
2013-04-07 7:13 ` bugzilla-daemon
` (5 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-07 5:39 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #19 from Mike Jones <mjones@linear.com> ---
I worked though patches one by one until a problem was found with Ilija's help.
I was using the diag for shell IO rather than tty3, and this caused a problem.
Diag polls and that used up much of the CPU. That exposed a SPI bug that caused
a loop on status to never complete. Ilija created a patch for that. That got
most of my application up.
I am now down to one problem. A malloc no longer works. Here is what my heap
and stack look like:
STACK
-----
thread pri base size used percent state name
1 31 0x1fff6418 2048 260 12.7 0 Idle Thread
2 4 0x1fff1808 2048 1484 72.5 16 setup_thread
3 5 0x1fff2008 2048 336 16.4 1 alert_thread
4 6 0x1fff2a08 2048 792 38.7 1
telemetry_monitor_thread
5 7 0x1fff2808 512 212 41.4 1
telemetry_thread
6 10 0x1fff3208 4096 1588 38.8 0 shell_thread
7 11 0x1fff4208 1024 660 64.5 16 network_thread
8 8 0x1fff9a08 4096 644 15.7 1 tcpip
9 4 0x1fffaa08 4096 188 4.6 1 eth
10 7 0x1fff460c 2048 384 18.8 1 telnet
11 7 0x1fff4e0c 2048 336 16.4 1 ftp
12 7 0x1fff560c 1024 480 46.9 1 snmp
HEAP
----
arena 26464
fordblks 13756
fsmblks 0
hblkhd 0
hblks 0
keepcost 0
maxfree 13756
ordblks 1
smblks 0
uordblks 12688
usmblks 0
My malloc statement:
hex_data = (char*) malloc(17000);
Then down in dlmalloc.cxx
remainder_size = long_sub_size_t(chunksize(top), nb);
if (chunksize(top) < nb || remainder_size < (long)MINSIZE)
{
diag_printf("chunksize(top)=%ld, nb=%d, remainder=%ld\n", chunksize(top),
nb, remainder_size);
MALLOC_UNLOCK;
CYG_MEMALLOC_FAIL(bytes);
return NULL; /* propagate failure */
}
This returns null. The diag print displays:
chunksize(top)=13776, nb=17008, remainder=-3232
I tried to turn on the debug build, but I get the following ASSERT:
ASSERT FAIL: <1>thread.inl[186]void Cyg_HardwareThread::attach_stack() Stack
size too small
ASSERT FAIL: <1>thread.inl [ 186] void
Cyg_HardwareThread::attach_stack()
l
I tried to increase the idle thread stack size but could not get by this. If
anyone knows how to make the debug work, that might help me get data.
If I have to guess, the Doug Lea malloc has some chunk size, and no malloc
bigger than will work.
At this point in the game, my code and ecc file are very close to what used to
work. I only tweak a line related to a different parameter order in a GPIO
call. And the ecc is the same other than the new stuff from the patches. 26K of
heap is what I had before all this was patched.
When I diff'ed my ecc file with the old one, I find no differences related to
malloc settings.
I notice there is a fall back heap size
CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE of 16384. If this is the heap size,
my request would fail. But my print out of the heap says it is 26K. So I
believe the heap is externally defined.
I looked around and did not find any settings in the config tool to set the
block size. I don't have time to learn how the malloc works at the moment. I
suppose it is possible the chunk size is calculated and sensitive to space or
some subtle change from these patches.
Bottom line for now is, the whole application seems to work other than this
large malloc. Therefore, committing the code would break my app unless I
rewrote this section to work in smaller chunks. That would be a lot of work
given the way the code works, but I can't elaborate on this code. It is a very
complex data processing algorithm that would be hard to make work in chunks,
especially with my project deadlines.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (19 preceding siblings ...)
2013-04-07 5:39 ` bugzilla-daemon
@ 2013-04-07 7:13 ` bugzilla-daemon
2013-04-07 10:41 ` bugzilla-daemon
` (4 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-07 7:13 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #20 from Mike Jones <mjones@linear.com> ---
I printed out dlmalloc.cxx before I retired for the day and read some of the
description. I can't understand how this code with the large malloc ever
worked. Given the 26K heap, and the allocation up to 4K chunks, no chunk should
ever have been large enough unless it can append chunks, which my understanding
is that it can't do that.
Given that, I don't think I have any choice but to rewrite my algorithm to use
a 4K buffer.
So I can't find any reason not to commit this code, even if it breaks my code.
However, if anyone has any idea how it could have worked, please enlighten me.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (20 preceding siblings ...)
2013-04-07 7:13 ` bugzilla-daemon
@ 2013-04-07 10:41 ` bugzilla-daemon
2013-04-07 13:52 ` bugzilla-daemon
` (3 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-07 10:41 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #21 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #20)
> I printed out dlmalloc.cxx before I retired for the day and read some of the
> description. I can't understand how this code with the large malloc ever
> worked. Given the 26K heap, and the allocation up to 4K chunks, no chunk
> should ever have been large enough unless it can append chunks, which my
> understanding is that it can't do that.
>
> Given that, I don't think I have any choice but to rewrite my algorithm to
> use a 4K buffer.
>
> So I can't find any reason not to commit this code, even if it breaks my
> code.
>
> However, if anyone has any idea how it could have worked, please enlighten
> me.
Mike
If the buffer is permanent, you may use staticaly allocated array. Also, FYI
Cortex-M specification requires stack to be 8 Byte aligned (though I haven't
experienced any anomaly with 4 Byte alignment so far).
Ilija
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (21 preceding siblings ...)
2013-04-07 10:41 ` bugzilla-daemon
@ 2013-04-07 13:52 ` bugzilla-daemon
2013-04-07 14:19 ` bugzilla-daemon
` (2 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-07 13:52 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #22 from Mike Jones <mjones@linear.com> ---
The buffer is not permanent. There are three buffers, and data is processed
from SD, to B1, from B1 to B2, etc. To do it in chunks means the algorithm has
to be aware of boundary conditions. So it has to be modified to align
dynamically sized records with memory size and the state machine has to handle
a stream of chunks rather than operate out of one big chunk. It is far more
memory efficient to change the algorithm which needed to be changed anyway. It
is more a matter of schedules than what is the right thing to do.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (22 preceding siblings ...)
2013-04-07 13:52 ` bugzilla-daemon
@ 2013-04-07 14:19 ` bugzilla-daemon
2013-04-07 16:44 ` bugzilla-daemon
2013-04-15 22:29 ` bugzilla-daemon
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-07 14:19 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #23 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #22)
> The buffer is not permanent. There are three buffers, and data is processed
> from SD, to B1, from B1 to B2, etc. To do it in chunks means the algorithm
> has to be aware of boundary conditions. So it has to be modified to align
> dynamically sized records with memory size and the state machine has to
> handle a stream of chunks rather than operate out of one big chunk. It is
> far more memory efficient to change the algorithm which needed to be changed
> anyway. It is more a matter of schedules than what is the right thing to do.
You may also consider eCos memory pools.
http://ecos.sourceware.org/docs-3.0/ref/memalloc.html
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (23 preceding siblings ...)
2013-04-07 14:19 ` bugzilla-daemon
@ 2013-04-07 16:44 ` bugzilla-daemon
2013-04-15 22:29 ` bugzilla-daemon
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-07 16:44 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #24 from Ilija Kocho <ilijak@siva.com.mk> ---
Checked in. Thanks to Mike Jones for testing.
Ilija
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug 1001814] Kinetis clock gating
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
` (24 preceding siblings ...)
2013-04-07 16:44 ` bugzilla-daemon
@ 2013-04-15 22:29 ` bugzilla-daemon
25 siblings, 0 replies; 27+ messages in thread
From: bugzilla-daemon @ 2013-04-15 22:29 UTC (permalink / raw)
To: ecos-patches
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
Ilija Kocho <ilijak@siva.com.mk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |CURRENTRELEASE
--- Comment #25 from Ilija Kocho <ilijak@siva.com.mk> ---
Checked in a while ago.
Closing.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2013-04-15 22:29 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-04 19:43 [Bug 1001814] New: Kinetis clock gating bugzilla-daemon
2013-04-04 19:44 ` [Bug 1001814] " bugzilla-daemon
2013-04-04 19:57 ` bugzilla-daemon
2013-04-06 5:49 ` bugzilla-daemon
2013-04-06 6:17 ` bugzilla-daemon
2013-04-06 12:47 ` bugzilla-daemon
2013-04-06 12:49 ` bugzilla-daemon
2013-04-06 13:06 ` bugzilla-daemon
2013-04-06 13:54 ` bugzilla-daemon
2013-04-06 13:57 ` bugzilla-daemon
2013-04-06 14:00 ` bugzilla-daemon
2013-04-06 14:08 ` bugzilla-daemon
2013-04-06 14:21 ` bugzilla-daemon
2013-04-06 14:24 ` bugzilla-daemon
2013-04-06 14:37 ` bugzilla-daemon
2013-04-06 14:54 ` bugzilla-daemon
2013-04-06 15:47 ` bugzilla-daemon
2013-04-06 16:34 ` bugzilla-daemon
2013-04-06 17:21 ` bugzilla-daemon
2013-04-06 17:40 ` bugzilla-daemon
2013-04-07 5:39 ` bugzilla-daemon
2013-04-07 7:13 ` bugzilla-daemon
2013-04-07 10:41 ` bugzilla-daemon
2013-04-07 13:52 ` bugzilla-daemon
2013-04-07 14:19 ` bugzilla-daemon
2013-04-07 16:44 ` bugzilla-daemon
2013-04-15 22:29 ` bugzilla-daemon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).