顯示文章

這裡允許您檢視這個會員的所有文章。請注意, 您只能看見您有權限閱讀的文章。


文章 - ts

頁: [1]
1
Embedded 討論版 / 請問busybox問題~
« 於: 2006-03-02 18:52 »
不懂你的問題?

不見得一定要built-in 在busybox, 可以用外部的指令呀

對於mkfs.ext2應該有很多resource吧!

2
我們通常不建議生手自己去 build toolchains
甚至我們這裡有超過5年以上的embedded linux經驗的工程師,
build toolchains 對他們而言依然是很困難。
一般而言,提供平台的廠商也會一併提供toolchains  :)

toolchains通常跟你的target SoC有很大的關聯,可能需要很多的patch

除非你那顆target上 SoC太common了,幾乎與原來ARM公司的一模一樣,那就比較容易 build 了。否則build出來的toolchains能不能用或者有無後遺症? Who knows?

3
恐怕你要先了解甚麼是major, minor
以及他們與driver之間的關係

如果你的mtd falsh driver可以讀到由redboot所建立的partition資訊,那就比較容易了,否則你還要在你的mtd driver 上 做相對應的修改。

如果你已經懂得如何修改你的 mtd driver的話,這些 /dev/mtd0, /dev/mtd1, ... 應該是沒問題才對 :)

你的mtd driver上有實作一些 open, close, read, write, ... 等 操作functions,
major就是告訴linux用你的 mtd上的這些操作functions,而不是其他的裝置上之操作functions.

而minor就是告訴linux上你的mtd driver,被操作的對象,在這裡,就是個別的partition了。

可以參考
The Linux Kernel Module Programming Guide
比較容易入門

有時間的話,可以詳讀
The Linux Device Drivers

4
雜七雜八 / Win xp怎找不到"影像"工具
« 於: 2006-02-27 05:05 »
從95的時代,就用它來掃描或看傳真TTF, G3的檔案,XP已經不內附這個程式了

微軟的support網站還可以download的到,不過xp不能用

網路上有人知道如何patch
http://www.patents.com/efs/xp.htm

還有人更是好心全包好了
http://techrepublic.com.com/5208-6247-0.html?forumID=12&threadID=127330&messageID=1661783

至於中文版,就要你看過之後,自己搞了

5
C/C++程式設計討論區 / gcc 與 ld 指令
« 於: 2006-02-27 03:29 »
當然不一樣!

gcc -o c.o a.o b.o 產生出來的c.o已經是一個可執行程式,當然名為 .o是不妥的。

ld -r c.o a.o b.o 產生出來的c.o還是一個 .o 的 relocatable object,

你可以再用 gcc -o d.exe c.o, 產生出來的執行檔, 跟前面的是一樣的。

6
這不只是embedded linux的問題!這是所有Linux的問題!

我花了一些時間,稍微詳細讀了wasabi 的研究報告,也試著去了解這篇報告的動機!

我相信絕大部分的台灣廠商都願意遵循各項有關著作權的法律規範,但是GPL的相關規範,法律上的詞句意義,有時後連律師都很難搞清楚。既然採用了Linux,台灣的廠商當然有源碼公開的打算,這點我想是無庸置疑的。我認為這篇報告主要會造成爭議的地方是:Linux kernel Module(LKM) 也是屬於Kernel的"延伸"部分,這對於是硬體重鎮的台灣無疑是一項重大的打擊(如果這篇報告有法律效用的話)。

這篇報告引述了Linus說法,

"If somebody wants to port his SVR4 driver to linux but doesn't want to GPL it, I feel that he should have the right to do that, using modules. After all, the driver wasn't actually derived from linux itself: it's a real driver in its own right, so I don't feel that I have the moral right to force him to switch copyrights."

顯然地,Linus 認為"不必"公開LKM源碼。而這正也是有那麼多的硬體廠商,願意port driver 到 Linux 平台的誘因,如果一旦結果不是這個樣子,真的是著時打了這些熱情擁抱Linux HW廠商一巴掌。

然而,就像這篇些報告所指出,甚至連Linus也表示:

Well, it really boils down to the equivalent of "all derived modules have to be GPL'd". An external module doesn't really change the GPL in that respect... [T]here really is no exception. However, copyright law obviously hinges on the
definition of "derived work", and as such anything can always be argued on that point. I personally consider anything a "derived work" that needs special hooks in the kernel to function with Linux (ie it is not acceptable to make a small
piece of GPL-code as a hook for the larger piece), as that obviously implies that the bigger module needs "help" from the main kernel. Similarly, I consider anything that has intimate knowledge about kernel internals to be a derived work

雖然Linus顯然支持LKM未必必須開源,但對於LKM是否為kernel之延伸,有了些的交代,而這也是wasabi拿來大做文章的部分。

我用一個比較技術性的實例來說明,

例如要開發一個wireless driver, 通常wireless晶片除了一些protocol與基本的chip控制需要與主CPU溝通,在細部信號處理的部分,甚至一些加密計算模組,則由另一個on-chip CPU來處理。有時為了有彈性,這部分的binary code(firmware),也放在driver中,當driver啟動(init)的時候,再載入晶片中,如果要更嚴苛的解釋,是否連這些code,也要釋放源碼?

更慘的是,wireless晶片為了要更costdown, 本來由on-chip CPU做的事情,全由PC CPU或SoC CPU來做,這些部分包含許多chip design house的專利與著作權,有時要公開是有困難的。

但我想事情終究有解答的,至少到目前為止,還未有LKM開源的部分被告的吧!

台灣的著作權法在老美的逼迫之下已經是全世界屬一屬二的嚴苛了,很難想像當你從國外,帶回你花錢買的(正版的)多本一樣的書或者是唱片、軟體,那你就有可能吃上平行輸入的著作權官司。

我認為台灣的廠商只是比較憨直,不懂得應付而已。早期連輸入美國的主機板,都要有合法的BIOS與OS授權的證明,許多廠商因此向微軟貢獻了不少。但後來有些廠商也很聰明,成立Linux團隊,以後就boundle linux到美國,至於最買家要灌哪套OS, 那是他家的事:)

另外,許多台灣HW廠商跟我反應,他們會有些疑慮,Embedded Linux 開源的服務,會造成公司的負擔。我常常告訴他們,不必緊張,這也可能是商機,因為可以向索取source code的仁兄,收取一些必要的處理用,例如燒錄光碟、快遞等費用,不怕人家來索取,只怕不過多!或許比那微薄的embedded硬體利潤還來的好:) 其實,embedded linux重點不在 source本身,例如如何建立build的環境,是相當複雜的,而這跟source的服務是無關的,如果user需要這樣的服務也很好呀,收取的費用更是可觀,商機無限哪!

Wasabi公司是何許人也,為何這麼好心幫我們做出這份報告,指出重要的觀點。看了他們公司主要產品,不禁讓我想起多年前,Unix lab告 BSD違反著作權一案,一直是一些 BSDer 引以為憾的事,並認為是user 捨 BSD 改用 Linux 的主因,歷史或許會在embedded Linux重演嗎?也希望只是我以小人之心推敲罷了。

頁: [1]