XIP aware file system

XIP aware file system

[Konstantin Kletschke]

Hi people!

Since I got a reasonable burst modus of flash device running XIP is not
taking more but less time now, so third attempt to get this running...
I have to port the stuff in xip.h.

PXA:

I have a question why (ICIP & ICMR) is done. Because ICIP _is_ already
the hardware "and"ed between  ICMR and ICPR so it seems bogus at this
place to "and" pending and mask by software again.
Is this done because of "ICCR[DIM]=0 & Idle mode='1'" "or"ed to ICMR?
If yes, on our i.MX it should be sufficient to do 
( IMX_NIPNDH || IMX_NIPNDL ) which are the IRQ pending registers already
"and"ed between IRQ source and INT enable.

The OSCR Register is read to get some timing stuff, at what frequency is
the timer ++ed? I am sure it is 32.768kHz or 32.8kHz. Is that correct?
In this case I should also do
(signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) /4).
because "our" timer runs at 32kHz. I am pretty sure though...

Further I found in funktion __xipram xip_udelay() a call to printk()
right at the beginning, "pending entry". This will never work,
becaus printk is located in flash,is that
correct (just trying to really understand)?
When I look at dissassembled vmlinux I find several calls to functions in
flash in xip_udelay:

c0013974:       ebc3fa2e        bl      bf112234 <cond_resched>
c0013994:       ebc34c31        bl      bf0e6a60 <memset>
c00139dc:       ebc18b27        bl      bf076680 <add_wait_queue>
c00139e0:       ebc3f696        bl      bf111440 <schedule>
c00139ec:       ebc18b45        bl      bf076708 <remove_wait_queue>

and so on.
Is this correct?

Hm, our Kernel freezes right after

Creating 5 MTD partitions on "scb9328_flash":             
0x00000000-0x00020000 : "U-boot"             
0x00020000-0x00040000 : "U-boot_env"
0x00040000-0x00140000 : "kernel"    
0x00140000-0x00540000 : "root"  
0x00540000-0x00940000 : "fs"

at the moment.

Kind regards, Konsti




-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: XIP aware file system

[Konstantin Kletschke]

eumn, in general, is it OK to try the XIP stuff with
linux-2.6.11-rc2-mm1?
The patches applied clean, I thought XIP is in mm tree and I realized
much later the XIP is already in 2.6.11-rc2...

Regards, Konsti


-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: XIP aware file system

[Nicolas Pitre]

On Tue, 15 Feb 2005, Konstantin Kletschke wrote:

> Hi people!
> 
> Since I got a reasonable burst modus of flash device running XIP is not
> taking more but less time now, so third attempt to get this running...
> I have to port the stuff in xip.h.
> 
> PXA:
> 
> I have a question why (ICIP & ICMR) is done. Because ICIP _is_ already
> the hardware "and"ed between  ICMR and ICPR so it seems bogus at this
> place to "and" pending and mask by software again.

   The  Interrupt Controller Pending register (ICPR) (see Section 25.5.1)
   has  a  bit  for  each of the peripherals (primary interrupt sources).
   Each  active  interrupt  sets  the  corresponding  bit.  The Interrupt
   Controller  IRQ  Pending  register (ICIP) (see Section 25.5.2) and the
   Interrupt  Controller FIQ Pending register (ICFP) (see Section 25.5.3)
   identify  the  active,  unmasked  pending  interrupt  sources that are
   causing  IRQ-  and  FIQ-level interrupts, respectively. Interrupts are
   set   at  their  source  and  masked  or  unmasked  in  the  interrupt
   controller. The programmable Interrupt Controller Mask register (ICMR)
   (see  Section 25.5.4) chooses which interrupt source is masked. Masked
   interrupt sources do not cause an IRQ or FIQ interrupt to the core and
   only update the ICPR. The Interrupt Control Level register (ICLR) (see
   Section 25.5.5) chooses whether an interrupt causes an IRQ or an FIQ.

> Is this done because of "ICCR[DIM]=0 & Idle mode='1'" "or"ed to ICMR?

I'm not sure if it is strictly necessary to use ICMR.  According to the 
manual quoted above masked interrupts only update ICPR and not ICIP.  If 
so the & with ICMR is redundent.

> If yes, on our i.MX it should be sufficient to do 
> ( IMX_NIPNDH || IMX_NIPNDL ) which are the IRQ pending registers already
> "and"ed between IRQ source and INT enable.

Right.

> The OSCR Register is read to get some timing stuff, at what frequency is
> the timer ++ed? I am sure it is 32.768kHz or 32.8kHz. Is that correct?

No. It's either 3686400 Hz or 3250000 Hz.  Therefore xip_elapsed_since() 
should do:

	ticks = OSCR(now) - OSCR(before)
	usecs = ticks / 3606400 (ticks/sec) * 1000000 (usecs/sec)

or	usecs = (OSCR - x) / 3.686400

Rounding it to avoid floats and making sure it provides a result smaller
than the actual delay in microsecs (per the comment in xip.h) we get:

#define xip_elapsed_since(x)    (signed)((OSCR - (x)) / 4)

The (signed) is to make sure the compiler does a signed compare with it 
later on regardless of the OSCR signedness.

> In this case I should also do
> (signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) /4).
> because "our" timer runs at 32kHz. I am pretty sure though...

If your time base runs at 32kHz you need:

#define xip_elapsed_since(x) (signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) * 31)

where 31 = 1000000 (usecs/sec) / 32000 (ticks/sec).

> Further I found in funktion __xipram xip_udelay() a call to printk()
> right at the beginning, "pending entry".

Where do you see that?

> This will never work,
> becaus printk is located in flash,is that
> correct (just trying to really understand)?
> When I look at dissassembled vmlinux I find several calls to functions in
> flash in xip_udelay:
> 
> c0013974:       ebc3fa2e        bl      bf112234 <cond_resched>
> c0013994:       ebc34c31        bl      bf0e6a60 <memset>
> c00139dc:       ebc18b27        bl      bf076680 <add_wait_queue>
> c00139e0:       ebc3f696        bl      bf111440 <schedule>
> c00139ec:       ebc18b45        bl      bf076708 <remove_wait_queue>
> 
> and so on.
> Is this correct?

Please study carefully xip_udelay() and try to understand _when_ it is 
OK to call other functions and when it is not.  This function is really 
where all the magic is happening.

> Hm, our Kernel freezes right after
> 
> Creating 5 MTD partitions on "scb9328_flash":             
> 0x00000000-0x00020000 : "U-boot"             
> 0x00020000-0x00040000 : "U-boot_env"
> 0x00040000-0x00140000 : "kernel"    
> 0x00140000-0x00540000 : "root"  
> 0x00540000-0x00940000 : "fs"
> 
> at the moment.

Look at your xip_elasped_since() implementation.


Nicolas

Re: XIP aware file system

[Konstantin Kletschke]

You got it!

Finally I considered the OSCR running at 3.6MHz and did

#define xip_elapsed_since(x)    (signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) * 28)

i.e. 112/4. And it runs and does xip and I can write to flash.
Im not believing what I see...

Am 2005-02-15 11:38 -0500 schrieb Nicolas Pitre:

> I'm not sure if it is strictly necessary to use ICMR.  According to the 
> manual quoted above masked interrupts only update ICPR and not ICIP.  If 
> so the & with ICMR is redundent.

I think it is redundant but I don't know exactly the meaning of
ICMR|ICCR.

> If your time base runs at 32kHz you need:
> 
> #define xip_elapsed_since(x) (signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) * 31)

Right. As said, I assumed OSCR runs 3.6MHz and came to * 28, but I
should do 112/3.6.
Thanks for your nice explanation.

> Where do you see that?

ARGH! It was mine! 

> Please study carefully xip_udelay() and try to understand _when_ it is 

Im trying hard :)

> Look at your xip_elasped_since() implementation.

All right, I did while you calculated the values for me :)

Thanks for your help, Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: XIP aware file system

[Nicolas Pitre]

On Tue, 15 Feb 2005, Konstantin Kletschke wrote:

> You got it!
> 
> Finally I considered the OSCR running at 3.6MHz and did
> 
> #define xip_elapsed_since(x)    (signed)((IMX_TCN(IMX_TIM1_BASE) - (x)) * 28)
> 
> i.e. 112/4. And it runs and does xip and I can write to flash.

Where does that 112/4 come from?


Nicolas

Re: XIP aware file system

[Konstantin Kletschke]

Am 2005-02-15 12:12 -0500 schrieb Nicolas Pitre:

> Where does that 112/4 come from?

OSCR: 3.6MHz
i.MX Timer: 32kHz

3.6/0.032~112

OSCR/4 == i.MX Timer*(112/4)

There I got my 28 from :)

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: XIP aware file system

[Nicolas Pitre]

On Tue, 15 Feb 2005, Konstantin Kletschke wrote:

> Am 2005-02-15 12:12 -0500 schrieb Nicolas Pitre:
> 
> > Where does that 112/4 come from?
> 
> OSCR: 3.6MHz
> i.MX Timer: 32kHz
> 
> 3.6/0.032~112
> 
> OSCR/4 == i.MX Timer*(112/4)
> 
> There I got my 28 from :)

Please re-read my previous email discussing implementation of 
xip_elapsed_since() again, and re-read it until it's obvious to you why 
I'm so insisting.

The SA11x0/PXA2xx implementation is an _example_ not a _reference_.


Nicolas

Re: XIP aware file system

[Konstantin Kletschke]

Hm, something is unstable yet.
Either my burstmode is too hard or something else...

The burst mode I tuned this day, it worked for a couple of hours, but my
xip kernels all brak now:

Creating 5 MTD partitions on "scb9328_flash":             
0x00000000-0x00020000 : "U-boot"             
0x00020000-0x00040000 : "U-boot_env"
0x00040000-0x00240000 : "kernel"    
0x00240000-0x00640000 : "root"  
0x00640000-0x01000000 : "fs"  
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
jffs2_scan_dirent_node(): Name CRC failed on node at 0x000b2128: Read
0x405647ad, calculated 0x7e3eb440
jffs2_scan_dirent_node(): Name CRC failed on node at 0x000b236c: Read
0xb9570647, calculated 0x35f96289
jffs2_scan_dirent_node(): Name CRC failed on node at 0x000b35a8: Read
0x9acd7a6e, calculated 0x87339b9f
jffs2_scan_dirent_node(): Name CRC failed on node at 0x000e8630: Read
0x03371d6d, calculated 0x4dcf6e71
jffs2_scan_dirent_node(): Name CRC failed on node at 0x0010adac: Read
0xe2abe810, calculated 0xe0794e1f

And freeze then. Is my xipuImage frying the fs on its first boot?
Yes, obviously but why not an hour ago? hm...

Adressess are constant with every version and the rootfs is reflashed
every time. 
I am puzzled...

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: XIP aware file system

[David Woodhouse]

On Tue, 2005-02-15 at 11:38 -0500, Nicolas Pitre wrote:
> Please study carefully xip_udelay() and try to understand _when_ it is 
> OK to call other functions and when it is not.  This function is really 
> where all the magic is happening.

Out of interest, how do we guarantee that there won't be speculative
prefetching of icache? If you're relying on hardware-specific knowledge
that it doesn't happen, please document that so that it doesn't bite
people implementing the XIP primitives on other platforms.

-- 
dwmw2

Re: XIP aware file system

[Nicolas Pitre]

On Tue, 15 Feb 2005, David Woodhouse wrote:

> On Tue, 2005-02-15 at 11:38 -0500, Nicolas Pitre wrote:
> > Please study carefully xip_udelay() and try to understand _when_ it is 
> > OK to call other functions and when it is not.  This function is really 
> > where all the magic is happening.
> 
> Out of interest, how do we guarantee that there won't be speculative
> prefetching of icache? If you're relying on hardware-specific knowledge
> that it doesn't happen, please document that so that it doesn't bite
> people implementing the XIP primitives on other platforms.

See xip_enable().  You'll find:

	(void) map_read(map, adr);
	asm volatile (".rep 8; nop; .endr"); /* fill instruction prefetch */

Hopefully that should be suficient to avoid this problem.


Nicolas