[Bug 1928] mpc5674fevb: powerpc/mpc55xx/misc/flash_support.c:183:9: warning: case label value exceeds maximum value for type

bugzilla-daemon at rtems.org bugzilla-daemon at rtems.org
Thu Oct 6 19:00:14 UTC 2011


dufault at hda.com changed:

           What    |Removed                     |Added
                 CC|                            |dufault at hda.com

--- Comment #3 from dufault at hda.com 2011-10-06 14:00:13 CDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > Hardware accessed via bit fields is always trouble even if you think things
> > look ok.
> Partially agreed, bitfields are a double wedged sword - They have pros and
> cons.
> (E.g. if this case was implemented via bit-masks, gcc would not have raised a
> warning, but code would have been silently broken)
> Portability-wise, they are a nightmare, e.g. wrt. byte-order.
> > There is no standards based means to control the size of the access to
> > the specific field.
> As long as these bitfields are sufficiently tied to a specific setup, they
> normally should be OK with gcc. 
> At least, I've never seen a case with gcc where it did not work.

Your analysis is correct, on the MPC5554 the size of the bit field is four, not

This might work fine in all cases and avoid warnings:

int size = FLASH.MCR.B.SIZE;
switch(size) {

HOWEVER, someone with the MPC5674 better first check that flash_support.c is
even compatible with the MPC567X. A web search results in this from the
"MPC5566 to MPC5674F Migration Guide":

"The MPC5674F requires a different flash-programming algorithm that will be
provided by FSL as a software driver. Any proprietary flash-programming
algorithms or drivers must be re-coded for the MPC5674F."

It might be a good thing we got that warning.

Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

More information about the bugs mailing list