linux : firmware 簡介

-

我以為device要可以運作, 只要在linux安裝相關的driver即可
最近看到原來device除了driver之外, 還是需要firmware這東西才可以運作...
稍微做個筆記....

Firmware

基本上device要可以正常運作是需要driver和firmware.
driver可以看成是系統跟device溝通的橋樑. firmware則是執行在device上面的程式.
Firmware除了可以預先寫死在device上外,另一方式就是driver初始化device的時候. 從系統讀取firmware, 在寫入到device.

Firmware讀取流程

linux放置firmware的地方為/lib/firmware. 讀取firmware的時候就是透過此.
(1) 流程參考[2]

  1. Driver跟kernel要求 "ar9170.fw"
  2. kernel傳遞event給udev來要求firmware
  3. udev執行對應的script,把firmware傳送至kernel所創建的一個特殊檔案
  4. kernel從此特殊檔案讀取firmware, 再把資料傳送給driver
  5. driver再把資料傳給device

(2) 流程參考[3][5] 
 1), kernel(driver):
    - calls request_firmware(&fw_entry, $FIRMWARE, device)
    - kernel searchs the fimware image with name $FIRMWARE directly
    in the below search path of root filesystem:
        User customized search path by module parameter 'path'[1]
        "/lib/firmware/updates/" UTS_RELEASE,
        "/lib/firmware/updates",
        "/lib/firmware/" UTS_RELEASE,
        "/lib/firmware"
    - If found, goto 7), else goto 2)

    [1], the 'path' is a string parameter which length should be less
    than 256, user should pass 'firmware_class.path=$CUSTOMIZED_PATH'
    if firmware_class is built in kernel(the general situation)

 2), userspace:
    - /sys/class/firmware/xxx/{loading,data} appear.
    - hotplug gets called with a firmware identifier in $FIRMWARE
      and the usual hotplug environment.
        - hotplug: echo 1 > /sys/class/firmware/xxx/loading

 3), kernel: Discard any previous partial load.

 4), userspace:
        - hotplug: cat appropriate_firmware_image > \
                    /sys/class/firmware/xxx/data

 5), kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
     comes in.

 6), userspace:
        - hotplug: echo 0 > /sys/class/firmware/xxx/loading

 7), kernel: request_firmware() returns and the driver has the firmware
     image in fw_entry->{data,size}. If something went wrong
     request_firmware() returns non-zero and fw_entry is set to
     NULL.

 8), kernel(driver): Driver code calls release_firmware(fw_entry) releasing
         the firmware image and any related resource.

Trace driver Code

這邊trace位於drivers/net/ethernet/brocade/bna底下的兩個檔案bfa_ioc.c和bnad_ethtool.c.
bnad_ethtool.c這邊可以看到driver透過request_firmware函數去跟kernel要求firmware.
在寫入至device之後就透過release_firmware把firmware給釋放掉了.
而bfa_nw_flash_update_part和bfa_flash_write_send則是driver如何把firmware寫入至device的流程. 

static int
bnad_flash_device(struct net_device *netdev, struct ethtool_flash *eflash)
{
    struct bnad *bnad = netdev_priv(netdev);
    struct bnad_iocmd_comp fcomp;
    const struct firmware *fw;
    int ret = 0;
    ret = request_firmware(&fw, eflash->data, &bnad->pcidev->dev);
    if (ret) {
        netdev_err(netdev, "can't load firmware %s\n", eflash->data);
        goto out;
    }
    fcomp.bnad = bnad;
    fcomp.comp_status = 0;
    init_completion(&fcomp.comp);
    spin_lock_irq(&bnad->bna_lock);
    ret = bfa_nw_flash_update_part(&bnad->bna.flash, BFA_FLASH_PART_FWIMG,
                bnad->id, (u8 *)fw->data, fw->size, 0,
                bnad_cb_completion, &fcomp);
    if (ret != BFA_STATUS_OK) {
        netdev_warn(netdev, "flash update failed with err=%d\n", ret);
        ret = -EIO;
        spin_unlock_irq(&bnad->bna_lock);
        goto out;
    }
    spin_unlock_irq(&bnad->bna_lock);
    wait_for_completion(&fcomp.comp);
    if (fcomp.comp_status != BFA_STATUS_OK) {
        ret = -EIO;
        netdev_warn(netdev,
                "firmware image update failed with err=%d\n",
                fcomp.comp_status);
    }
out:
    release_firmware(fw);
    return ret;
}

/**
 * bfa_nw_flash_update_part - Update flash partition.
 *
 * @flash: flash structure
 * @type: flash partition type
 * @instance: flash partition instance
 * @buf: update data buffer
 * @len: data buffer length
 * @offset: offset relative to the partition starting address
 * @cbfn: callback function
 * @cbarg: callback argument
 *
 * Return status.
 */
enum bfa_status
bfa_nw_flash_update_part(struct bfa_flash *flash, u32 type, u8 instance,
             void *buf, u32 len, u32 offset,
             bfa_cb_flash cbfn, void *cbarg)
{
    if (!bfa_nw_ioc_is_operational(flash->ioc))
        return BFA_STATUS_IOC_NON_OP;

    /*
     * 'len' must be in word (4-byte) boundary
     */
    if (!len || (len & 0x03))
        return BFA_STATUS_FLASH_BAD_LEN;

    if (type == BFA_FLASH_PART_MFG)
        return BFA_STATUS_EINVAL;

    if (flash->op_busy)
        return BFA_STATUS_DEVBUSY;

    flash->op_busy = 1;
    flash->cbfn = cbfn;
    flash->cbarg = cbarg;
    flash->type = type;
    flash->instance = instance;
    flash->residue = len;
    flash->offset = 0;
    flash->addr_off = offset;
    flash->ubuf = buf;

    bfa_flash_write_send(flash);

    return BFA_STATUS_OK;
}

/*
 * Send flash write request.
 */
static void
bfa_flash_write_send(struct bfa_flash *flash)
{
    struct bfi_flash_write_req *msg =
            (struct bfi_flash_write_req *) flash->mb.msg;
    u32 len;

    msg->type = be32_to_cpu(flash->type);
    msg->instance = flash->instance;
    msg->offset = be32_to_cpu(flash->addr_off + flash->offset);
    len = (flash->residue < BFA_FLASH_DMA_BUF_SZ) ?
           flash->residue : BFA_FLASH_DMA_BUF_SZ;
    msg->length = be32_to_cpu(len);

    /* indicate if it's the last msg of the whole write operation */
    msg->last = (len == flash->residue) ? 1 : 0;

    bfi_h2i_set(msg->mh, BFI_MC_FLASH, BFI_FLASH_H2I_WRITE_REQ,
            bfa_ioc_portid(flash->ioc));
    bfa_alen_set(&msg->alen, len, flash->dbuf_pa);
    memcpy(flash->dbuf_kva, flash->ubuf + flash->offset, len);
    bfa_nw_ioc_mbox_queue(flash->ioc, &flash->mb, NULL, NULL);

    flash->residue -= len;
    flash->offset += len;
}

Reference

  1. Linux Tv: Firmware
  2. Ubuntu: Firmware
  3. Linux 内核 firmware 加载过程
  4. 14.8. Dealing with Firmware
  5. linux-x.y.z/Documentation/firmware_class/README

留言

張貼留言

這個網誌中的熱門文章

yocto recipe : (1) 撰寫 recipe

-
此篇文章介紹如何透過 yocto 的 utilities 來產生 recipe. 而完成的 recipe 又如何加入到 image. yocto 相關工具介紹 有三個適用於 layer 與 recipe 相關的 utilities. bitbake-layers: 負責 (1) 建立 layer. (2) 修改 bblayers.conf. (3) 查看 layer 底下的 recipes recipetool: 用於建立一個 recipe 和新增/修改 recipe. 這邊 recipe 在 yocto 即是 xx.bb 或 xx.bbappend 檔案 devtool: 定位在開發測試上. devtool 會建立一個獨立的 workspace layer. 讓開發者於此建立/修改 recipe 與 patch source code. 在不修改原有設定下與現有 layers 進行整合測試. 完畢之後可以再透過 devtool 新增或更新到 layer 裡 利用 utilities 撰寫 recipe 的時候. 要確保所屬的 layer 是存在於 bblayer.conf. 不然執行 bitbake [recipe basename] 會找不到相關的 recipe. yocto 事前準備 以 core-image-miniaml recipe 為例子. core-image-miniaml 會產生系統所需的 image 相關檔案. 接著利用 bitbake-layers 建立自己的 layer 於 build 目錄底下. 再透過 bitbake-layers 把 layer 加入到 bblayers.conf 設定檔. [ yijyun@localhost poky ] $ . oe-init-build-env [ yijyun@localhost build ] $ bitbake core-image-minimal [ yijyun@localhost build ] $ bitbake-layers create-layer meta-layer [ yijyun@localhost build ] $ bitbake-layers add-
閱讀完整內容

yocto recipe : (2) 撰寫 bbappend

-
前言 xxx.bb 檔案是用來描述一個 recipe. 然而 xxx.bb 會因為 patch codes、新增 tasks、等等的因素修改. 這邊介紹如何使用 xxx.bbappend[1] 檔案. 以不修改 xxx.bb 的情況下擴充需求. 文章將以 patch codes 為例子, 並個別以 devtool 工具和手動的方式示範. bbapend 簡介 .bbappend 是擴充 .bb 的方式. 藉由 .bbappend 來新增 tasks、patch code、新增/修改變數等等諸此之類的事. 其名稱必須跟所要修改的相同, 而版本號則依據需求寫. 舉例: bb file 名稱: giflib_5.1.4.bb bbappend 名稱: giflib_5.1.4.bbappend 或 giflib_%.bbappend. %: 表示萬用字元 使用 .bbappend 的情況, 我個人認為有以下情況再使用 (1) 當 recipe 已存在 yocto 最基本的 layer, 不應隨便修改. 舉例: u-boot_2017.09.bb 存在於 yocto 的 meta layer (2) 某些 layers 會共用此 recipe 的情況下. 舉例: meta-raspberrypi 與 meta-ti 分別各自使用自己的 xserver-xf86-config_0.1.bbappend 來對 yocto meta layer 的 xserver-xf86-config_0.1.bb 做擴充修改. bbappend 範例 事前準備 用 giflib [4] 作為測試程式. 先下載 giflib-5.1.4.tar.bz2. 接著使用 bitbake-layer 建立 meta-custom layer, 再透過 recipetool 把產生的 giflib_5.1.4.bb 存放於此 layer. # 執行 oe-init-build-env 進行 yocto 編譯環境設定 [ yijyun@localhost poky ] $ . oe-init-build-env # 建立 3rd-pkgs, 並把 giflib 放至此 [ yijyun@localhost build ] $
閱讀完整內容

yocto recipe : (3) 使用 External Source 來編譯軟體

-
Yocto 有提供許多 fetch code 的方式[3], 大都是以抓取外網的方式. 雖然很齊全, 但是開發時候多少需要以本機上的 source code 作為來源進行編譯. 這邊就紀錄如何讓 yocto 直接抓取本機上的 source code 使用本機上的 source code 這邊介紹兩種方式. 使用硬碟上的 source code, 而不是透過 yocto fetch 去網路上抓取 (1) git fetcher: 基於 git fetcher, 僅修改 src_uri 參數, 就可以用本機上的 source code (2) external source: 基於 externalsrc class. 有兩種方式達成: (1) 於 recipe 直接新增 external source 變數 (2)於 local.conf 新增特定 recipe 的 external source 參數. 事前準備 於 build 目錄底下建立 3rd-pkgs. 把下載的 giflib 程式碼放置於此 [ yijyun@localhost build ] $ pwd /media/disk1-1/Github/poky/build [ yijyun@localhost build ] $ ls 3rd-pkgs/ giflib-5.1.4.tar.bz2 新增 meta-test 於 yocto. 並在此 meta-layer 底下新增 giflib 目錄. 存放之後的 bb files [ yijyun@localhost build ] $ bitbake-layers create-layer meta-test [ yijyun@localhost build ] $ bitbake-layers add-layer meta-test [ yijyun@localhost build ] $ mkdir meta-test/recipes-example/giflib git fetcher 使用 git fetcher 有兩個重點: src_uri 的 protocol 參數需要改為 file. S 的路徑要改為 S="
閱讀完整內容