Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 23 Jun 2003 02:57 PM by  elf-coastal@buici.com
ANSWER: Why slow kernel decompression?
 1 Replies
Sort:
You are not authorized to post a reply.
Author Messages
elf-coastal@buici.com
New Member
New Member
Posts:


--
21 Jun 2003 12:21 PM
    Reading from flash is slow.

    Using a different bootloader, I found that the kernel decompression time is not so intimidating. The only difference between this other boot loader and LogicLoader is that this one copies the kernel to RAM before jumping to it.

    I haven't checked to see if there is an improvement when caching is enabled for the flash memory region.
    elf-coastal@buici.com
    New Member
    New Member
    Posts:


    --
    23 Jun 2003 02:57 PM
    I've been looking through the Linux bootstrap code. It turns out that they enable the cache while decompressing the kernel. I haven't verified that it is enabling cache for the flash memory region, but the code says it is.

    I'm using the BLOB boot loader which is a lot faster booting Linux than LogicLoader. BLOB copies the kernel from flash to SDRAM and executes from there. I believe that slow decompression is primarily a flash access-time problem.

    Should someone be inclined to try it, you may get better performance from flash by tweaking the SMC controller settings for flash. I believe that LogicLoader leaves them in their default settings which is quite high: 0x1f. This translates to (31+1)*tHCLK or ~20ns if my math is correct. Compare this with SDRAM which is 32bit, not 16, and probably averages a read delay closer to 1 or zero cycles. All you need to do is check the specs for the StrataFlash part and come up with an optimal wait time.

    Cheers.
    You are not authorized to post a reply.