1
Embedded 討論版 / 請問busybox問題~
« 於: 2006-03-02 18:52 »
不懂你的問題?
不見得一定要built-in 在busybox, 可以用外部的指令呀
對於mkfs.ext2應該有很多resource吧!
不見得一定要built-in 在busybox, 可以用外部的指令呀
對於mkfs.ext2應該有很多resource吧!
顯示文章
這裡允許您檢視這個會員的所有文章。請注意, 您只能看見您有權限閱讀的文章。
頁: [1]
2
Embedded 討論版 / [問題]想在ARM上使用gcc，使用native & corss compiler有些疑問請教
« 於: 2006-03-02 18:44 »
我們通常不建議生手自己去 build toolchains
甚至我們這裡有超過5年以上的embedded linux經驗的工程師，
build toolchains 對他們而言依然是很困難。
一般而言，提供平台的廠商也會一併提供toolchains
toolchains通常跟你的target SoC有很大的關聯，可能需要很多的patch
除非你那顆target上 SoC太common了，幾乎與原來ARM公司的一模一樣，那就比較容易 build 了。否則build出來的toolchains能不能用或者有無後遺症? Who knows?
甚至我們這裡有超過5年以上的embedded linux經驗的工程師，
build toolchains 對他們而言依然是很困難。
一般而言，提供平台的廠商也會一併提供toolchains
toolchains通常跟你的target SoC有很大的關聯，可能需要很多的patch
除非你那顆target上 SoC太common了，幾乎與原來ARM公司的一模一樣，那就比較容易 build 了。否則build出來的toolchains能不能用或者有無後遺症? Who knows?
3
Embedded 討論版 / 請問一下， MTD 如何跟 /dev/ 下的裝置做成對應
« 於: 2006-03-02 18:21 »
恐怕你要先了解甚麼是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
以及他們與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
至於中文版，就要你看過之後，自己搞了
微軟的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, 產生出來的執行檔, 跟前面的是一樣的。
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嵌入式應用確實違反了GPL
« 於: 2006-02-26 18:42 »
這不只是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重演嗎？也希望只是我以小人之心推敲罷了。
我花了一些時間，稍微詳細讀了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]