• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 1124 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/DRA77P: Dra7x u-boot L2 cache enable

Xiongwei Huang60
Prodigy 220 points

Part Number: DRA77P

Tool/software: Linux

Hello all 

Anyone know  , does Ti enable L2 cache on Ti default u-boot code ?

I get over than 2 seconds when uncompress 4M Bytes kernel with lz4 compressed 

Compare with other PL310 cache controller enabled chip , it will take no more than 1 second

regards 

  • 0
    TI__Mastermind 42515 points
    Hi,

    I have forwarded your question to U-boot experts.

    Regards,
    Yordan
  • 0 in reply to Yordan Kamenov
    TI__Genius 14650 points

    Hi,

    L2-cache is enabled in u-boot by default. However, just before u-boot jumps to kernel, L2-cache is disabled since Linux configures the MMU as part of its initialization. On the DRA77p SoC PL310 cache controller isn't used. 

    Regards
    Shravan

  • 0 in reply to Shravan Karthik
    Prodigy 220 points

    Hi Shravan

    Thanks for reply 

    I means in iMX6 , that use pl310 cache controller , and it will cost no more than 1 s to uncompress the zImage @1Ghz

    While I tried on dra777p @1G (default ti u-boot config) ,seems it will take over than 2 seconds from u-boot print "Starting kernel..." to the first kernel console print

    All the zImage is compressed with lz4 and size almost about 4M bytes

    How can I speed up this ?

    Regards

  • 0 in reply to Xiongwei Huang60
    TI__Genius 14650 points
    Hi Xiongwei,

    Decompression of the kernel doesn't happen as part of u-boot, u-boot loads the image to a specified address, and jumps to kernel. As part of the kernel init sequence, the image is decompressed. Is the 2s measurement after the kernel image has been loaded from storage to DDR? The bottle-neck could be the boot-media, i.e it takes time to load the compressed image from boot-media to DDR, and decompression of zImage isn't the bottleneck.

    Regards
    Shravan
  • 0 in reply to Shravan Karthik
    Prodigy 220 points

    Hello shravan 

    Here is my teraterm log with time stamp

    [Tue Feb 27 08:49:25.053 2018] MMC read: dev # 1, block # 101152, count 12288 ... 12288 blocks read: OK
    [Tue Feb 27 08:49:25.131 2018]
    [Tue Feb 27 08:49:25.131 2018] MMC read: dev # 1, block # 5376, count 768 ... 768 blocks read: OK
    [Tue Feb 27 08:49:25.147 2018] Kernel image @ 0x82000000 [ 0x000000 - 0x3eee08 ]
    [Tue Feb 27 08:49:25.162 2018] ## Flattened Device Tree blob at 88000000
    [Tue Feb 27 08:49:25.162 2018] Booting using the fdt blob at 0x88000000
    [Tue Feb 27 08:49:25.162 2018] Loading Device Tree to 8ffe4000, end 8ffff6fb ... OK
    [Tue Feb 27 08:49:25.178 2018]
    [Tue Feb 27 08:49:25.178 2018] Starting kernel ...//u-boot print
    [Tue Feb 27 08:49:25.178 2018]
    [Tue Feb 27 08:49:27.113 2018] [ 0.000000] Booting Linux on physical CPU 0x0 //first kernel print
    [Tue Feb 27 08:49:27.113 2018] [ 0.000000] Initializing cgroup subsys cpuset
    [Tue Feb 27 08:49:27.113 2018] [ 0.000000] Initializing cgroup subsys cpu
    [Tue Feb 27 08:49:27.129 2018] [ 0.000000] Initializing cgroup subsys cpuacct

    The first kernel printk line over than 2 seconds,If this not caused by u-boot , Do you know if someone  can help about this ?

    regards

  • 0 in reply to Xiongwei Huang60
    TI__Genius 14650 points

    Hi Xiongwei,

    The print that you see isn't an accurate depiction of the time taken for the first kernel print. Can you add 'earlyprintk' to your boot kernel boot arguments and try booting. 

    Regards
    Shravan

  • 0 in reply to Shravan Karthik
    Prodigy 220 points
    Hello Shravan
    Thanks for all information

    Seems our pci driver block 1 seconds for boot this
    We have solve this
    Thanks again