XIP & GCC optimization & halting

Nicolas Pitre nico at cam.org
Mon Oct 17 16:49:19 EDT 2005

On Mon, 17 Oct 2005, Korolev, Alexey wrote:

> Hi all,
> I faced several issues with XIP on kernel 2.6.11.
> I used Mainstone board and NOR flash with the only partition (non RWW
> device).
> First found issue of XIP was concerned with GCC optimization.
> The function Do_write_buffer was inlined into upper function and as a
> result loose __xipram attribute in case of default -Os compile option.
> I reduced compile option to -O1 and it helped.

Please apply this patch to your tree:

diff --git a/include/linux/mtd/xip.h b/include/linux/mtd/xip.h
index 7b7deef..46ddb14 100644
--- a/include/linux/mtd/xip.h
+++ b/include/linux/mtd/xip.h
@@ -27,7 +27,7 @@
  * obviously not be running from flash.  The __xipram is therefore marking
  * those functions so they get relocated to ram.
-#define __xipram __attribute__ ((__section__ (".data")))
+#define __xipram noinline __attribute__ ((__section__ (".data")))
  * We really don't want gcc to guess anything.

> After resolving this issue I found another one halting. 
> The system halts with rather big probability on write and erase
> operations (good way to reproduce it download file (of size ~1M) via
> tftp on JFFS2 volume).
> I used BDI debugger to investigate the issue and found that after
> halting flash device was in READ_STATUS mode and write operation is not
> complete. PC reg points to stuff in virtual memory region mapped to
> I disabled for just a case FIQs, but it didn't help.

The default FIQ exception handler lives in ram anyway.

> I really puzzled what code could interrupt write operation then IRQs and
> FIQs are disabled. 

data abort I'd guess.

If you could set your BDI to trap any data abort when XIP is disabled 
and provide the content of the FAR (fault address register) when it 
happens that might be extremely helpful.

> Also from time to time I see another issue. 
> I get kernel panic message of the view :
> I added debug print just before BUG was called. 
> It looks very strange according to code chips_per_word = worwidth *
> cfi_interleave / map_bankwidth. There is no way to get 6 !
> 2005-10-15 17:49:58 | cfi_interleave = 2 worwidth = 4 map_bankwidth = 4
> chips_per_word = 6 cmd = 0x80.

Probably a side effect of the above bug.


More information about the linux-mtd mailing list