[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
https://www.rtems.org/bugzilla/show_bug.cgi?id=1928
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
three.
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