0

現在、S3C6410 CPU を搭載した SBC のボード サポート パッケージに取り組んでいます。ボードのベンダーは 2.6 カーネルのサポートのみを提供しており、新しい 3.x カーネルに移行しようとしています。残念ながら、後者のカーネルでは多くのデバイスが適切にサポートされていないという問題に遭遇し続けています。たとえば、USB のサポートはプロジェクトにとって重要です。3.0.x シリーズでは動作しますが、3.2.x 以降では正しく起動しません。パッチ/アップデートを探しても役に立たなかったので、袖をまくり上げてカーネルソースを汚してしまいました。

カーネル ツリー ( ) に大幅な変更があることに気付きましたarch/arm/plat-samsung。以前は、サポートされているデバイスごとに 1 つの複数のモジュールが存在していましたが、現在は、それらすべてのサポートを含む 1 つのモノリシック モジュールがあります。例えば、

Linux 3.0.80arch/arm/plat-samsung/dev-usb-hsotg.c

#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>

#include <mach/irqs.h>
#include <mach/map.h>

#include <plat/devs.h>

static struct resource s3c_usb_hsotg_resources[] = {
        [0] = {
                .start  = S3C_PA_USB_HSOTG,
                .end    = S3C_PA_USB_HSOTG + 0x10000 - 1,
                .flags  = IORESOURCE_MEM,
        },
        [1] = {
                .start  = IRQ_OTG,
                .end    = IRQ_OTG,
                .flags  = IORESOURCE_IRQ,
        },
};

static u64 s3c_hsotg_dmamask = DMA_BIT_MASK(32);

struct platform_device s3c_device_usb_hsotg = {
        .name           = "s3c-hsotg",
        .id             = -1,
        .num_resources  = ARRAY_SIZE(s3c_usb_hsotg_resources),
        .resource       = s3c_usb_hsotg_resources,
        .dev            = {
                .dma_mask               = &s3c_hsotg_dmamask,
                .coherent_dma_mask      = DMA_BIT_MASK(32),
        },
};

このファイルは削除され、サポートはに移管されましたarch/arm/plat-samsung/devs.c

ただし、元のコードと新しいカーネルのコードを比較すると...

Linux 3.2.48arch/arm/plat-samsung/devs.c

/* USB HSOTG */

#ifdef CONFIG_S3C_DEV_USB_HSOTG
static struct resource s3c_usb_hsotg_resources[] = {
        [0] = DEFINE_RES_MEM(S3C_PA_USB_HSOTG, SZ_16K),
        [1] = DEFINE_RES_IRQ(IRQ_OTG),
};

struct platform_device s3c_device_usb_hsotg = {
        .name           = "s3c-hsotg",
        .id             = -1,
        .num_resources  = ARRAY_SIZE(s3c_usb_hsotg_resources),
        .resource       = s3c_usb_hsotg_resources,
        .dev            = {
                .dma_mask               = &samsung_device_dma_mask,
                .coherent_dma_mask      = DMA_BIT_MASK(32),
        },
};
#endif /* CONFIG_S3C_DEV_USB_HSOTG */

... ドライバーにいくつかの変更が加えられましたが、私の素朴な目には、バグのように見えます。

  • のメモリサイズがs3c_usb_hsotg_resources[0]64K から 16K に変更されました。
  • はs3c_device_usb_hsotg.dev.dma_maskローカル変数を使用しなくなりu64 ましたが、多くの構造体によって共有されている変数への参照を使用します platform_device。

現在、2 か月の大半でカーネル コードをくまなく調べたにもかかわらず、ドライバー開発に関しては、私はまだ非常に初心者です。メモリサイズの変更は十分に正当化され、現在モジュールをサポートしている人物によって行われた変更の一部である可能性がありますが、単一の共有u64変数への参照を使用することが、私が見てきた問題のいくつかを引き起こしているのではないかと心配しています.とりわけ、この特定のデバイスで。USB ドライバーの場合、ボードを立ち上げるとロードされますが、接続されているデバイスはまったく検出されません。デバイスは 2.6 および 3.0 カーネルで正しく認識されるため、これはハードウェア関連の問題ではないことを確認しました。したがって、これにより、新しいカーネルコードが原因であることに傾倒します。

そう、

  1. この共有参照が問題の原因である可能性があるかどうかは誰にもわかりませんか?
  2. カーネル ソースにこのような大幅な変更が加えられた理由を説明できる人はいますか?
  3. 3.0 シリーズから 3.2+ シリーズへのカーネル デバイス ドライバーの変更をカバーする簡潔なリソース (リンク、書籍など) はありますか?
4

1 に答える 1

3

最初の質問にはお答えできませんが、2 番目と 3 番目の質問にはお答えします。

あなたが経験していることは、実際にはカーネル開発のごく普通の部分です。Linux は非常に速いペースで開発されており、ベンダーが追いつくために速度を落とす時間はありません。カーネルは常に改善されており、その結果、コードが入れ替わったり、API が完全に刷新されたり、関数が追加されたり、名前が変更されたり、削除されたりする可能性があります。それが起こらなければ、後方互換性を維持するために多くの努力が無駄になるでしょう。 . つまり、メインライン カーネルの開発者は、ベンダーの Linux フォークを気にしません。メインライン カーネルにあるコードだけを気にします。

残念ながら、これを回避できた唯一の方法は、ベンダーにプラットフォーム サポートを上流に送ってもらい、移植が完了したらすぐにメインラインに移行してもらうことでした。今）。そうすれば、別のコーダーが行った何らかの変更が原因でプラットフォームで問題が発生した場合、通常、コードを修正するのはその人次第です。

Linux 開発がこのように機能する理由について詳しくは、 Stable API Nonsenseをお読みください。

3 番目の質問に答えるために、Kernel Newbies は、参照できる Linux のすべてのメジャー リリースの簡単な変更ログを保持しています。

http://kernelnewbies.org/Linux_3.2

http://kernelnewbies.org/Linux_3.1

http://kernelnewbies.org/Linux_3.0

より詳細な情報については、git コミット ログで釣りをする必要があります。

于 2013-07-10T01:48:54.647 に答える