[U-Boot] [PATCH] [v2] powerpc/85xx: move the Fman microcode from ef000000 to eff40000
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)
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
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 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.
participants (2)
-
Timur Tabi -
Wolfgang Denk