[U-Boot] [PATCH] [v2] powerpc/85xx: move the Fman microcode from ef000000 to eff40000

[U-Boot] [PATCH] [v2] powerpc/85xx: move the Fman microcode from ef000000 to eff40000

[Timur Tabi]

On some Freescale reference boards for SOCs with Fman devices, the Fman
microcode is located at address 0xEF000000 in NOR flash.  Unfortunately,
this address is in the "middle of nowhere" and makes it difficult to
partition flash space for other images.

So we change the expected address to 0xEFF40000, which is the flash
sector adjacent to the environment.

Signed-off-by: Timur Tabi <timur@freescale.com>
---
 include/configs/P1023RDS.h   |    2 +-
 include/configs/P2041RDB.h   |    2 +-
 include/configs/corenet_ds.h |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/P1023RDS.h b/include/configs/P1023RDS.h
index e057b1f..54f4dd4 100644
--- a/include/configs/P1023RDS.h
+++ b/include/configs/P1023RDS.h
@@ -527,7 +527,7 @@ extern unsigned long get_clock_freq(void);
 /* Default address of microcode for the Linux Fman driver */
 /* QE microcode/firmware address */
 #define CONFIG_SYS_QE_FMAN_FW_IN_NOR
-#define CONFIG_SYS_QE_FMAN_FW_ADDR	0xEF000000
+#define CONFIG_SYS_QE_FMAN_FW_ADDR	0xEFF40000
 #else
 #define CONFIG_SYS_QE_FMAN_FW_IN_NAND
 #define CONFIG_SYS_QE_FMAN_FW_ADDR	0x1f00000
diff --git a/include/configs/P2041RDB.h b/include/configs/P2041RDB.h
index a48055e..bc177d0 100644
--- a/include/configs/P2041RDB.h
+++ b/include/configs/P2041RDB.h
@@ -429,7 +429,7 @@ unsigned long get_board_sys_clk(unsigned long dummy);
 #define CONFIG_SYS_QE_FMAN_FW_ADDR	(6 * CONFIG_SYS_NAND_BLOCK_SIZE)
 #else
 #define CONFIG_SYS_QE_FMAN_FW_IN_NOR
-#define CONFIG_SYS_QE_FMAN_FW_ADDR	0xEF000000
+#define CONFIG_SYS_QE_FMAN_FW_ADDR	0xEFF40000
 #endif
 #define CONFIG_SYS_QE_FMAN_FW_LENGTH	0x10000
 #define CONFIG_SYS_FDT_PAD		(0x3000 + CONFIG_SYS_QE_FMAN_FW_LENGTH)
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index 7925b95..e03d318 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -493,7 +493,7 @@
 #define CONFIG_SYS_QE_FMAN_FW_ADDR	(6 * CONFIG_SYS_NAND_BLOCK_SIZE)
 #else
 #define CONFIG_SYS_QE_FMAN_FW_IN_NOR
-#define CONFIG_SYS_QE_FMAN_FW_ADDR		0xEF000000
+#define CONFIG_SYS_QE_FMAN_FW_ADDR		0xEFF40000
 #endif
 #define CONFIG_SYS_QE_FMAN_FW_LENGTH	0x10000
 #define CONFIG_SYS_FDT_PAD		(0x3000 + CONFIG_SYS_QE_FMAN_FW_LENGTH)
-- 
1.7.3.4

[U-Boot] [PATCH] [v2] powerpc/85xx: move the Fman microcode from ef000000 to eff40000

[Wolfgang Denk]

Dear Timur Tabi,

In message <1326472903-6423-1-git-send-email-timur@freescale.com> you wrote:
> On some Freescale reference boards for SOCs with Fman devices, the Fman
> microcode is located at address 0xEF000000 in NOR flash.  Unfortunately,
> this address is in the "middle of nowhere" and makes it difficult to
> partition flash space for other images.
> 
> So we change the expected address to 0xEFF40000, which is the flash
> sector adjacent to the environment.

Instead  of hard-coding magic addresses which then need to be changed
again and again, would it not make more sense to read the value from
an environment variable so it can be easily changed without having to
modify the source, rebuild, reinstall all the time?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A dog always bit deepest on the veterinary hand.
                                    - Terry Pratchett, _Wyrd Sisters_

[U-Boot] [PATCH] [v2] powerpc/85xx: move the Fman microcode from ef000000 to eff40000

[Timur Tabi]

Wolfgang Denk wrote:
> Instead  of hard-coding magic addresses which then need to be changed
> again and again, would it not make more sense to read the value from
> an environment variable so it can be easily changed without having to
> modify the source, rebuild, reinstall all the time?

(Adding Haiying)

Well, I tried that a while back and it didn't work, but I can't remember
why.  That was before I implemented a unified approach to Fman ucode
identification, so maybe it will work better now.

Part of the problem is that the meaning of the address depends on where
the ucode actually is stored -- NOR flash, NAND flash, SPI flash, etc.  I
suppose we could do something like this:

ucode_loc=nor:eff40000

And then at runtime parse the 'nor' and the 'eff40000'.  I just wish I
could remember why I rejected the env variable approach back then.

Haiying, is there ever a situation where we need to upload the QE ucode
*before* the environment variables are available?

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH] [v2] powerpc/85xx: move the Fman microcode from ef000000 to eff40000

[Timur Tabi]

Timur Tabi wrote:
> Well, I tried that a while back and it didn't work, but I can't remember
> why.  That was before I implemented a unified approach to Fman ucode
> identification, so maybe it will work better now.

Ok, I remember now.

The problem was that using the environment variable was messy.  On some
systems, we have two code sections: 1) loads the ucode into RAM early
during boot, and 2) that same ucode is needed to when booting Linux.  We
used an environment variable to pass the address of the ucode from 1) to
2).  That was deemed to be too fragile, so we switched to macros.

I suppose if we get #2 to reload the ucode, that will make it work.  Then
#1 won't need to store the ucode permanently in memory.  It's not a
trivial fix, though.  All of the existing code works on the assumption
that the ucode is only located in one place.

I still have a nagging feeling that I'm missing something, though.

-- 
Timur Tabi
Linux kernel developer at Freescale