Hello Afzal,
On 05/14/12 12:33, Mohammed, Afzal wrote:
Hi All,
On Thu, May 03, 2012 at 14:12:11, Mohammed, Afzal wrote:
Some boards depend on bootloader to update chip select value for NAND.
It is felt that Kernel should not depend on bootloader to get CS, as
for a particular board CS is hardwired and is fixed, hence this can
directly be updated in Kernel. But as CS value for boards that depend
on this behaviour is not available, educate gpmc driver to acquire
chip select value for NAND. this ideally should be removed once CS
for those boards are available.
Do you know how many boards require this? If so which are those boards?
devkit8000, beagle board, omap3touchbook, overo.
Beagle board, found out to be zero.
I need a help.
Can someone familiar with boards - devkit8000, omap3touchbook, overo boards,
let me know GPMC CS on which NAND is connected.
On Devkit8000 the NAND is connected to CS0.
I thought that all NAND devices for booting are connected to CS0,
because of ROM code?
According to spruf98w.pdf:
25.4.7.4 NAND
...
* The device is connected to CS0.
...
Regards,
Thomas
Hi Tony,
I am planning to provide actual CS # used for NAND on above boards instead of
finding the value at runtime. Is there any reason that NAND CS# is found out
at runtime ? (hence remove necessity of omap_nand_flash_init()).
Presence of this also causes an additional dependency of bootloader.
As CS # depends on wiring on the board, my understanding is that it will be
fixed for a given board. Are you ok if acquiring NAND CS # is removed ?
Removal of this helps in simplifying gpmc driver (undergoing conversion).
Regards
Afzal
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
