<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Booting on Marcus Folkesson</title>
    <link>https://www.marcusfolkesson.se/tags/booting/</link>
    <description>Recent content in Booting on Marcus Folkesson</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 17 Aug 2024 12:39:34 +0200</lastBuildDate>
    <atom:link href="https://www.marcusfolkesson.se/tags/booting/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Board bring-up part 4: Wrap it up</title>
      <link>https://www.marcusfolkesson.se/blog/board-bring-up-part4/</link>
      <pubDate>Sat, 17 Aug 2024 12:39:34 +0200</pubDate>
      <guid>https://www.marcusfolkesson.se/blog/board-bring-up-part4/</guid>
      <description>Board bring-up part 4: Wrap it up I&#39;m currently working with a board bring up for a custom hardware based on a OMAPL138 from Texas Instruments. It is fun to work with &amp;quot;real&amp;quot; bring-ups. Most of my customers use System On Modules (SoM:s) these days. You get a lot for free with those modules but a lot of the fun is stripped away.&#xA;This post is not intended to be guide, it is more of a follow-me-through-my-work-post divided into three parts.</description>
    </item>
    <item>
      <title>Board bring-up part 3: Other peripherals</title>
      <link>https://www.marcusfolkesson.se/blog/board-bring-up-part3/</link>
      <pubDate>Fri, 16 Aug 2024 12:39:34 +0200</pubDate>
      <guid>https://www.marcusfolkesson.se/blog/board-bring-up-part3/</guid>
      <description>Board bring-up part 3: Other peripherals I&#39;m currently working with a board bring up for a custom hardware based on a OMAPL138 from Texas Instruments. It is fun to work with &amp;quot;real&amp;quot; bring-ups. Most of my customers use System On Modules (SoM:s) these days. You get a lot for free with those modules but a lot of the fun is stripped away.&#xA;This post is not intended to be guide, it is more of a follow-me-through-my-work-post divided into three parts.</description>
    </item>
    <item>
      <title>Board bring-up part 2: NAND flash</title>
      <link>https://www.marcusfolkesson.se/blog/board-bring-up-part2/</link>
      <pubDate>Thu, 15 Aug 2024 12:39:34 +0200</pubDate>
      <guid>https://www.marcusfolkesson.se/blog/board-bring-up-part2/</guid>
      <description>Board bring-up part 2: NAND flash I&#39;m currently working with a board bring up for a custom hardware based on a OMAPL138 from Texas Instruments. It is fun to work with &amp;quot;real&amp;quot; bring-ups. Most of my customers use System On Modules (SoM:s) these days. You get a lot for free with those modules but a lot of the fun is stripped away.&#xA;This post is not intended to be guide, it is more of a follow-me-through-my-work-post divided into three parts.</description>
    </item>
    <item>
      <title>Board bring-up part 1: Memory hassle</title>
      <link>https://www.marcusfolkesson.se/blog/board-bring-up-part1/</link>
      <pubDate>Wed, 14 Aug 2024 12:39:34 +0200</pubDate>
      <guid>https://www.marcusfolkesson.se/blog/board-bring-up-part1/</guid>
      <description>Board bring-up part 1: Memory hassle I&#39;m currently working with a board bring up for a custom hardware based on a OMAPL138 from Texas Instruments. It is fun to work with &amp;quot;real&amp;quot; bring-ups. Most of my customers use System On Modules (SoM:s) these days. You get a lot for free with those modules but a lot of the fun is stripped away.&#xA;This post is not intended to be guide, it is more of a follow-me-through-my-work-post divided into three parts.</description>
    </item>
    <item>
      <title>Flattened Image Tree (FIT) with Yocto</title>
      <link>https://www.marcusfolkesson.se/blog/flattened-image-tree/</link>
      <pubDate>Tue, 14 May 2024 11:00:34 +0100</pubDate>
      <guid>https://www.marcusfolkesson.se/blog/flattened-image-tree/</guid>
      <description>Flattened Image Tree (FIT) with Yocto Long time ago, I wrote a post [1] that compared the legacy Image format against Flattened Image Tree Format (FIT) [2] and highlighted the benefits of using it. The benefits are still valid and FIT images are my preferred way to boot a Linux kernel. Despite that, I almost never see FIT images used in examples nor Board Support Packages (BSPs).&#xA;So this post is mostly to give some more attention to the FIT images because I think it deserves it.</description>
    </item>
    <item>
      <title>FIT vs legacy image format</title>
      <link>https://www.marcusfolkesson.se/blog/fit-vs-legacy-image-format/</link>
      <pubDate>Wed, 18 Oct 2017 19:39:34 +0200</pubDate>
      <guid>https://www.marcusfolkesson.se/blog/fit-vs-legacy-image-format/</guid>
      <description>FIT vs legacy image format U-Boot supports several image formats when booting a kernel. However, a Linux system usually need multiple files for booting. Such files may be the kernel itself, an initrd and a device tree blob.&#xA;A typical embedded Linux system have all these files in at least two-three different configurations. It&#39;s not uncommon to have a&#xA;Default configuration Rescue configuration Development configuration Production configuration ... Only these four configurations may end up with unmanageable amount of different files.</description>
    </item>
  </channel>
</rss>
