On Fri, Jan 15, 2010 at 01:11, Song, Barry wrote: >From: Mike Frysinger [mailto:[email protected]] >>On Thu, Jan 14, 2010 at 23:35, Song, Barry wrote: >>> I don't think ram driver is not a right choice for a real >>>flash. Its write and erase is fake. >> >>i mean when we're doing a ROM kernel. the plat-ram driver lets you >>specify a specific probe type (mtd-rom) which lets you disable >>write/erase funcs. a flash doing kernel XIP shouldnt be allowed to >>write/erase any sector. > > Even though plat-ram supports assigning probe, physmap needs this support too. > > For xip kernel to suppot writable flash, how about one of the following two > ways:
with parallel flashes, it is my understanding that most commands put the flash into an unreadable state until the command has been completed. any transition to an unreadable state is unacceptable for a XIP kernel since we're executing out of it. > 1. let user assign cfi (or other interfaces) in board files directly, and let > cfi ignore the detection. i dont think that would fly with mainline. their answer would be "stop complicating correct common code to account for dumb users". > 2. relocation detection codes into RAM? i think there's way too many async events that can occur and be implicitly called by the handlers for this to be feasible. -mike _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
