[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 0xEF00 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 0xEFF4, which is the flash sector adjacent to the environment. Signed-off-by: Timur Tabi ti...@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 0xEF00 +#define CONFIG_SYS_QE_FMAN_FW_ADDR 0xEFF4 #else #define CONFIG_SYS_QE_FMAN_FW_IN_NAND #define CONFIG_SYS_QE_FMAN_FW_ADDR 0x1f0 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 0xEF00 +#define CONFIG_SYS_QE_FMAN_FW_ADDR 0xEFF4 #endif #define CONFIG_SYS_QE_FMAN_FW_LENGTH 0x1 #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 0xEF00 +#define CONFIG_SYS_QE_FMAN_FW_ADDR 0xEFF4 #endif #define CONFIG_SYS_QE_FMAN_FW_LENGTH 0x1 #define CONFIG_SYS_FDT_PAD (0x3000 + CONFIG_SYS_QE_FMAN_FW_LENGTH) -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [v2] powerpc/85xx: move the Fman microcode from ef000000 to eff40000
Dear Timur Tabi, In message 1326472903-6423-1-git-send-email-ti...@freescale.com you wrote: On some Freescale reference boards for SOCs with Fman devices, the Fman microcode is located at address 0xEF00 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 0xEFF4, 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: w...@denx.de A dog always bit deepest on the veterinary hand. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [v2] powerpc/85xx: move the Fman microcode from ef000000 to eff40000
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:eff4 And then at runtime parse the 'nor' and the 'eff4'. 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [v2] powerpc/85xx: move the Fman microcode from ef000000 to eff40000
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
