[U-Boot] (no subject)
Dear Stefan,
your commit
commit 8a805df13615667ebdcc9f3a3a6fbf6c7778a992 Author: Stefan Roese sr@denx.de Date: Thu Sep 16 14:01:53 2010 +0200
ppc4xx/fdt/flash: Change fdt_fixup_nor_flash_node() to not rely on cs size
breaks building allboards that have both CONFIG_FDT_FIXUP_NOR_FLASH_SIZE and CONFIG_SYS_NO_FLASH defined.
The reason is that CONFIG_FDT_FIXUP_NOR_FLASH_SIZE references flash_info[], which is not defined when CONFIG_SYS_NO_FLASH is set.
Currently this affects especially the sequoia_ramboot configuration.
In "include/configs/acadia.h" you fixed this like this:
124 /* 125 * No NOR-flash on Acadia when NAND-booting. We need to undef the 126 * NOR device-tree fixup code as well, since flash_info is not defined 127 * in this case. 128 */ 129 #define CONFIG_SYS_NO_FLASH 1 130 #undef CONFIG_FDT_FIXUP_NOR_FLASH_SIZE 131 #endif
We could obviously do the same for sequoia_ramboot, but I think the "fix" for the Acadia boar dis actually not a good idea.
Why would you completely disable access to the NOR flash just because somebody decides to boot fom NAND? I think this is a very bad idea. I know of many use cases where customers (espeically such without access to a BDI3000 like to keep copies of U-Boot both in NOR and in NAND, so they can use the altenative copy to recover the system in case they happen to corrupt on U-Boot image.
However, you cannot use the NAND booting version to restore U-Boot in Nor when you completely disable all NOR support.
This needs to be reworked, please.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Sunday 10 October 2010 10:35:36 Wolfgang Denk wrote:
your commit
commit 8a805df13615667ebdcc9f3a3a6fbf6c7778a992 Author: Stefan Roese sr@denx.de Date: Thu Sep 16 14:01:53 2010 +0200
ppc4xx/fdt/flash: Change fdt_fixup_nor_flash_node() to not rely on cs sizebreaks building allboards that have both CONFIG_FDT_FIXUP_NOR_FLASH_SIZE and CONFIG_SYS_NO_FLASH defined.
The reason is that CONFIG_FDT_FIXUP_NOR_FLASH_SIZE references flash_info[], which is not defined when CONFIG_SYS_NO_FLASH is set.
Currently this affects especially the sequoia_ramboot configuration.
In "include/configs/acadia.h" you fixed this like this:
124 /* 125 * No NOR-flash on Acadia when NAND-booting. We need to undef the 126 * NOR device-tree fixup code as well, since flash_info is not defined 127 * in this case. 128 */ 129 #define CONFIG_SYS_NO_FLASH 1 130 #undef CONFIG_FDT_FIXUP_NOR_FLASH_SIZE 131 #endif
We could obviously do the same for sequoia_ramboot, but I think the "fix" for the Acadia boar dis actually not a good idea.
Why would you completely disable access to the NOR flash just because somebody decides to boot fom NAND?
Because NOR is physically not available in this case (see below).
I think this is a very bad idea. I know of many use cases where customers (espeically such without access to a BDI3000 like to keep copies of U-Boot both in NOR and in NAND, so they can use the altenative copy to recover the system in case they happen to corrupt on U-Boot image.
However, you cannot use the NAND booting version to restore U-Boot in Nor when you completely disable all NOR support.
This needs to be reworked, please.
Acadia is special in respect to NOR/NAND booting. In NAND boot mode NOR is not available. It's not accessible at all since the NOR chips select is not connected to the SoC in this case. This is different to the "other" APM eval boards with NOR & NAND support like Sequoia. Here both flash types are available regardless of the boot mode.
sequoia_ramboot definitely needs a different "fix". We do want to support NAND and NOR flash when booting from RAM (via debugger etc). I'll take a look at it soon.
Cheers, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
Hi Wolfgang,
On Monday 11 October 2010 09:49:52 Stefan Roese wrote:
sequoia_ramboot definitely needs a different "fix". We do want to support NAND and NOR flash when booting from RAM (via debugger etc). I'll take a look at it soon.
The Sequoia RAM-booting target has been created mainly for boards equipped only with NAND flash (no NOR). This image can be loaded via a JTAG debugger into RAM and started there. After this U-Boot can be used to initially program the NAND flash. To make porting easier for other PPC4xx NAND-only users, I therefore removed NOR support from this RAM-booting image.
I now see two possible solutions for the current compile breakage:
a) Enable NOR again on sequoia_ramboot
b) Keep NOR disabled and remove CONFIG_FDT_FIXUP_NOR_FLASH_SIZE for sequoia_ramboot
Just let me know which one you would prefer and I will send a patch for it.
Thanks.
Cheers, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
Dear Stefan Roese,
In message 201010111519.04457.sr@denx.de you wrote:
The Sequoia RAM-booting target has been created mainly for boards equipped only with NAND flash (no NOR). This image can be loaded via a JTAG debugger into RAM and started there. After this U-Boot can be used to initially program the NAND flash. To make porting easier for other PPC4xx NAND-only users, I therefore removed NOR support from this RAM-booting image.
But the Sequoia board has both NOR and NAND, so we should support both.
I now see two possible solutions for the current compile breakage:
a) Enable NOR again on sequoia_ramboot b) Keep NOR disabled and remove CONFIG_FDT_FIXUP_NOR_FLASH_SIZE for sequoia_ramboot
As a) is way more useful to customers we should do that.
Just let me know which one you would prefer and I will send a patch for it.
Thanks.
Best regards,
Wolfgang Denk
participants (2)
-
Stefan Roese -
Wolfgang Denk