[U-Boot-Users] [PATCH] Fix AMCC bootstrap option letter label order
U-boot Users:
Several of the AMCC 440 processors have a stupid 'error' in the user manual resulting in the logical order of option 'G' and option 'F' being labeled in reverse. (The logical order of the bootstrap pins represent settings from 0 through 7, while the letters are ordered A, B, C, D, E, G, F, H.) In my case, I found this problem affecting the 440EPx and GRx processors.
See table 8-2 in the 440EPx Users' Manual.
The option AMCC_PINSTP_F_G_REVERSED has been added to these processors where they appear in cpu.c where the array bootstrap_str[] is located. Code to reverse a bootstrap setting of 5 and 6 (corresponding to G and F) has been added to bootstrap_option(). I know that this problem affects more processors in this family, so other users should add this option when they are identified.
Patch attached.
-Jeffrey
Hi Jeff,
On Tuesday 24 April 2007 21:49, Jeff Mann wrote:
Several of the AMCC 440 processors have a stupid 'error' in the user manual resulting in the logical order of option 'G' and option 'F' being labeled in reverse. (The logical order of the bootstrap pins represent settings from 0 through 7, while the letters are ordered A, B, C, D, E, G, F, H.) In my case, I found this problem affecting the 440EPx and GRx processors.
Good catch. I never noticed this, thanks.
See table 8-2 in the 440EPx Users' Manual.
The option AMCC_PINSTP_F_G_REVERSED has been added to these processors where they appear in cpu.c where the array bootstrap_str[] is located. Code to reverse a bootstrap setting of 5 and 6 (corresponding to G and F) has been added to bootstrap_option().
<insert some code from the patch>
@@ -207,7 +208,18 @@ static int bootstrap_option(void) unsigned long val;
mfsdr(SDR_PINSTP, val);
- return ((val & 0xf0000000) >> SDR0_PINSTP_SHIFT);
- val = ((val & 0xf0000000) >> SDR0_PINSTP_SHIFT);
+/* Some AMCC 440 processors have an error with bootstrap Option F and G
- labeled in reverse in the user manual. It has never been fixed */
+#if defined(AMCC_PINSTP_F_G_REVERSED)
- if (val == 5)
val=6;- else if (val==6)
val=5;+#endif
- return val;
} #endif /* SDR0_PINSTP_SHIFT */
I don't think this is the right way do deal with this problem. We should instead encode the bootstrap character "A..." into the string too:
#if defined(CONFIG_440EPX) || defined(CONFIG_440GRX) #define SDR0_PINSTP_SHIFT 29 static char *bootstrap_str[] = { "A - EBC (8 bits)", "B - EBC (16 bits)", "C - EBC (16 bits)", "D - NAND (8 bits)", "E - PCI", "G - I2C (Addr 0x54)", "F - PCI", "H - I2C (Addr 0x52)", }; #endif
I think this gives us more flexibility and doesn't "pollute" the code with more #ifdef's, especially when other 4xx PPC's will have such a "problem" too.
I know that this problem affects more processors in this family, so other users should add this option when they are identified.
I know that 440EP/GR are affected too. Do you know more?
If you (or any other) have no objection against my suggestions mentioned above, I'll change the code accordingly.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
Hi Jeff,
another note to your patch:
[PATCH] Fixed bootstrap option letter label error for some 440 processors Signed-off-by: Jeffrey Mann mannj@embeddedplanet.com
cpu/ppc4xx/cpu.c | 16 ++++++++++++++-- 1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/cpu/ppc4xx/cpu.c b/cpu/ppc4xx/cpu.c old mode 100644 new mode 100755
It happened earlier too, that you change the file modes. Please make sure that future patches do not touch the file modes of existing files and new files are added with the correct file mode.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
It happened earlier too, that you change the file modes. Please make sure that future patches do not touch the file modes of existing files and new files are added with the correct file mode.
Hmmm...I wonder why this is happening. It must have something to do with using ubuntu inside windows (and editing files in windows over samba). Nonetheless, I am having problems learning how to use git effectively. I am using some guide on kernel.com, but I wish I had some more detailed directions that were also less cryptic.
when I type: git format-patch origin, can I edit the text in pico instead of vi?
Stefan, one day you will stop getting all of these patch formating mistakes from me.
If you (or any other) have no objection against my suggestions
mentioned above, I'll change the code accordingly.
No objection. That works fine too.
-JMann
Hi Jeff,
On Wednesday 25 April 2007 15:52, Jeff Mann wrote:
It happened earlier too, that you change the file modes. Please make sure that future patches do not touch the file modes of existing files and new files are added with the correct file mode.
Hmmm...I wonder why this is happening. It must have something to do with using ubuntu inside windows (and editing files in windows over samba).
Autsch. I thought as much.
Nonetheless, I am having problems learning how to use git effectively. I am using some guide on kernel.com, but I wish I had some more detailed directions that were also less cryptic.
when I type: git format-patch origin, can I edit the text in pico instead of vi?
export EDITOR='pico'
in your .bashrc will help.
Stefan, one day you will stop getting all of these patch formating mistakes from me.
I'm looking forward... ;-)
If you (or any other) have no objection against my suggestions
mentioned above, I'll change the code accordingly.
No objection. That works fine too.
OK, I'll implement it this way.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
participants (2)
-
Jeff Mann -
Stefan Roese