Subject: RE: slower decompress?

From: "Jeff Sutherland" <[email-masked]>
Date: Tue, 22 Aug 2000 09:46:46 -0400

> > > 	The dots are appearing at a slow pace.  What should the
> status of
> > > the mmu and icache be when decompress_kernel is called?
> >
> > MMU, i-cache and d-cache are actually enabled for
> decompression speed in
> > linux/arch/arm/compressed/head.S.
> >
> > Just tried it again on my Assabet and everything looks OK here.
> > What bogomips number do you get?
>
> 	I'm getting 124.52 bogomips.  Sound about right?
>
> Chris

Looks a little on the low side to me.  Which version of the Assabet do you have?  Early versions up to phase 4 were designed to run
at 147.5MHz if you want the 1341 audio codec to work properly.  I ran mine all the way up to 221MHz at one point (works as long as
the SDRAM clock is running at CPU/4, not CPU/2).  A bug in the PLD for the lcd mandates running SDRAM at CPU/4 anyway.  But, even at
124.52Bogomips (CPU  should be somewhere around 132.7MHz) it still moves along pretty well.  It should take maybe 1.5 seconds to
decompress at this frequency if the Icache and buffering are enabled.  If you are fooling around with the mmu and the buffer
settings beware that there are only a few valid combinations.  Turning on debugging in the low level assembler routines turns off
the mmu and buffering, which gives a drastic reduction in performance.

//Jeff

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Chris Blazie <[email-masked]>
Date: Tue, 22 Aug 2000 10:26:36 -0400 (EDT)

> Looks a little on the low side to me.  Which version of the Assabet do you have?  Early versions up to phase 4 were designed to run

	It's not an Assabet, just a custom development board (SA-1110) 
which we're clocking at 133mhz and SDRAM divisor is CPU/4.  But again,
with the 2.3.99-pre3 kernel it decompressed in about 1 second. 

	I have debugging turned off, and just verified that immediately
before decompress_kernel is called, both icache and mmu are turned on.

	What else could have changed here?  Could the page table setup
in head.S affect this?

Thanks,
Chris

---

From: Nicolas Pitre <[email-masked]>
Date: Tue, 22 Aug 2000 11:30:00 -0400 (EDT)

> 	What else could have changed here?  Could the page table setup

Are you executing zImage from RAM or directly from Flash?

Nicolas

---

From: Chris Blazie <[email-masked]>
Date: Tue, 22 Aug 2000 11:29:52 -0400 (EDT)

Okay, I answered my own question (partially); my problem is in the
page table setup changes since pre3.  I made the following changes to
cache_on in head.S:

/*
 *  Initialise the page tables
 */
                mov     r0, r3   
                mov     r8, r0, lsr #18
                mov     r8, r8, lsl #18         @ start of RAM
                add     r9, r8, #0x20000000     @ the maximum RAM size
                mov     r1, #0x1e	//  CHANGED THIS from 0x12
                orr     r1, r1, #3 << 10
                add     r2, r3, #16384

		//  Commented out next 4 lines

1:              @cmp    r1, r8                  @ if virt > start of RAM
                @orrge  r1, r1, #0x0c           @ set cacheable, bufferable
                @cmp    r1, r9                  @ if virt > end of RAM
                @bicge  r1, r1, #0x0c           @ clear cacheable, bufferable
                str     r1, [r0], #4            @ 1:1 mapping
                add     r1, r1, #1048576
                teq     r0, r2
                bne     1b

	And it decompresses normally now (about a second).  So it seems
that the test for virt > start of RAM is failing, and cachable/bufferable
is not getting set at all.  Can someone explain what these setup changes
are about? I'm guessing one of the entry registers is incorrectly set in
my case, but not really sure right now.

Thanks,
Chris

---

From: Chris Blazie <[email-masked]>
Date: Tue, 22 Aug 2000 12:09:21 -0400 (EDT)

> Are you executing zImage from RAM or directly from Flash?

	It's executing directly from flash (0x00050000 to be exact).

Chris

---

From: Nicolas Pitre <[email-masked]>
Date: Tue, 22 Aug 2000 12:35:25 -0400 (EDT)

> 	It's executing directly from flash (0x00050000 to be exact).

Ha!  That's the reason.

The code in head.S is only activating the cache from the start of
RAM.  The solution would be also to activate the cache for 2 MB from
the run-time address of "start".  If the kernel is started from RAM, the
cache will simply be enabled twice.

Nicolas

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 22 Aug 2000 19:21:34 +0100 (BST)

> my case, but not really sure right now.

Basically, its to ensure that only the RAM is marked cacheable, and not
the IO.  If the IO is marked cacheable/bufferable, then Bad Things (tm)
happen.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |