<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Layerscape kernel code size in Layerscape</title>
    <link>https://community.nxp.com/t5/Layerscape/Layerscape-kernel-code-size/m-p/1589711#M11768</link>
    <description>&lt;P&gt;&lt;SPAN&gt;1) The compiler is not the same.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;2) The compiling arguments may be not the same. &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;3) We usually use uImage for PPC which is compressed, and use Image for ARM. Can you check the file size of vmlinux or Image.gz for the two arch?&lt;/SPAN&gt;&lt;/P&gt;</description>
    <pubDate>Mon, 30 Jan 2023 09:57:07 GMT</pubDate>
    <dc:creator>yipingwang</dc:creator>
    <dc:date>2023-01-30T09:57:07Z</dc:date>
    <item>
      <title>Layerscape kernel code size</title>
      <link>https://community.nxp.com/t5/Layerscape/Layerscape-kernel-code-size/m-p/1580978#M11660</link>
      <description>&lt;P&gt;Comparing PPC and ARM code size, we have Linux 5.17 running on a&amp;nbsp; P1014 and LS1021A with the same peripheral configuration. The PPC kernel size is 3.8MB while the LS1021A is 8.6MB.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I was wondering why the ARM kernel was so much bigger. Any clue?&lt;/P&gt;</description>
      <pubDate>Wed, 11 Jan 2023 16:37:44 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Layerscape/Layerscape-kernel-code-size/m-p/1580978#M11660</guid>
      <dc:creator>renaud</dc:creator>
      <dc:date>2023-01-11T16:37:44Z</dc:date>
    </item>
    <item>
      <title>Re: Layerscape kernel code size</title>
      <link>https://community.nxp.com/t5/Layerscape/Layerscape-kernel-code-size/m-p/1589711#M11768</link>
      <description>&lt;P&gt;&lt;SPAN&gt;1) The compiler is not the same.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;2) The compiling arguments may be not the same. &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;3) We usually use uImage for PPC which is compressed, and use Image for ARM. Can you check the file size of vmlinux or Image.gz for the two arch?&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 30 Jan 2023 09:57:07 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Layerscape/Layerscape-kernel-code-size/m-p/1589711#M11768</guid>
      <dc:creator>yipingwang</dc:creator>
      <dc:date>2023-01-30T09:57:07Z</dc:date>
    </item>
    <item>
      <title>Re: Layerscape kernel code size</title>
      <link>https://community.nxp.com/t5/Layerscape/Layerscape-kernel-code-size/m-p/1590650#M11772</link>
      <description>&lt;P&gt;I compared load time of a FIT image from a PNOR with UBI/UBIFS on our boot loaders&lt;/P&gt;&lt;P&gt;On LS1021A:&amp;nbsp;&lt;/P&gt;&lt;P&gt;* From the boot loader:&lt;/P&gt;&lt;P&gt;ls -l /mnt/primary/&lt;BR /&gt;lrwxrwxrwx 12 fit.itb -&amp;gt; fitImage.itb&lt;BR /&gt;-rwxr-xr-x 6757428 fitImage.itb&lt;/P&gt;&lt;P&gt;time cp /mnt/primary/fit.itb /&lt;BR /&gt;time: 3093ms&lt;/P&gt;&lt;P&gt;This gives about 2MiB/S&lt;/P&gt;&lt;P&gt;Broadcom iProc CPU: 3MB/s&lt;/P&gt;&lt;P&gt;* From Linux:&lt;/P&gt;&lt;P&gt;time cp /mnt/primary/fit.itb /tmp&lt;BR /&gt;real 0m1.608s&lt;/P&gt;&lt;P&gt;Or about 4.02 MB/s&lt;/P&gt;&lt;P&gt;========================================================&lt;/P&gt;&lt;P&gt;On P1014:&lt;/P&gt;&lt;P&gt;Our boot loader:&lt;/P&gt;&lt;P&gt;time cp /mnt/primary/fit.itb /&lt;BR /&gt;time: 742ms&lt;/P&gt;&lt;P&gt;Or about 5.34MB/s&lt;/P&gt;&lt;P&gt;Linux:&lt;/P&gt;&lt;P&gt;[root@openware]# time cp /mnt/primary/fit.itb /tmp/&lt;/P&gt;&lt;P&gt;real 0m0.907s&lt;/P&gt;&lt;P&gt;Or about 4MB/s&lt;/P&gt;&lt;P&gt;Note that at the MTD level, U-boot and our boot loader have the same performance. At the MTD level, mostly it is a memcpy.&lt;/P&gt;&lt;P&gt;Under Linux the data rate is about the same for both CPU but I get a great difference under the boot loaders. All platforms only uses one CPU.&lt;/P&gt;&lt;P&gt;The PPC boot loader is more than twice as fast as the LS1021A in term of data rate and in our measurement 4 times as fast to get to the prompt. Both boot loader do the same thing as the LS1021A is a replacement for the P1014 on our system.&lt;/P&gt;&lt;P&gt;Also we noticed that calculating the kernel sha256 is much slower on LS1021A than P1014. On both our boot loader and NXP U-boot it takes more than 5s. While the PPC is below 1s.&lt;/P&gt;&lt;P&gt;Some measurements of SHA1 below as there is no SHA256 on U-boot:&lt;/P&gt;&lt;P&gt;File size&amp;nbsp;6757428&lt;/P&gt;&lt;P&gt;Our boot loader: 6.458ms&lt;/P&gt;&lt;P&gt;U-boot: 28.178&lt;/P&gt;&lt;P&gt;Linux:0.565&lt;/P&gt;&lt;P&gt;My understanding is that U-boot uses the hash driver in drivers/crypto/fsl for sha1 but our bootloader and Linux uses a driver support in arch/arm/crypto for.&lt;/P&gt;&lt;P&gt;And also MD5 sum on a 5818764 bytes file:&lt;/P&gt;&lt;P&gt;md5sum ls1021a (u-boot): 27s&lt;/P&gt;&lt;P&gt;BCOM iProc: 0.359s&amp;nbsp;&lt;/P&gt;&lt;P&gt;Any clue of what could be&amp;nbsp; missing. As far as I know the L2 cache is fully under hardware control on the LS1021A. Why are U-boot, our bootloader not able to get the same performance as Linux?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 31 Jan 2023 14:49:04 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Layerscape/Layerscape-kernel-code-size/m-p/1590650#M11772</guid>
      <dc:creator>renaud</dc:creator>
      <dc:date>2023-01-31T14:49:04Z</dc:date>
    </item>
    <item>
      <title>Re: Layerscape kernel code size</title>
      <link>https://community.nxp.com/t5/Layerscape/Layerscape-kernel-code-size/m-p/1598015#M11845</link>
      <description>&lt;P&gt;&lt;SPAN&gt;28s for sha1 test in u-boot is abnormal.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;We run following command in u-boot, it returns around 1s.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;=&amp;gt; hash sha1 0x80000000 6757428&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;sha1 for 80000000 ... 86757427 ==&amp;gt; e1ba2ad7fdfde87015ea9c3aadc33575c7b9416e&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;=&amp;gt;&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;How did you test? Are you using LSDK to test? Which version?&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 13 Feb 2023 08:40:45 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Layerscape/Layerscape-kernel-code-size/m-p/1598015#M11845</guid>
      <dc:creator>yipingwang</dc:creator>
      <dc:date>2023-02-13T08:40:45Z</dc:date>
    </item>
  </channel>
</rss>

