- 追加された行はこの色です。
- 削除された行はこの色です。
- AppPark へ行く。
&size(24){&color(red){'''Tentative release, Not ready for review'''};};
#contents();
** Linux overview [#p63e123b]
*** Linux become business infrastructure [#wcb3ee1f]
You may have heard the word of "Linux" in various conjuncture. As well as "Windows", Linux is a name of major computer operating system. However in most cases, it implicitly indicates a bit wider computer environments. If you introduce Linux is already ported to SuperH, people may expect they can utilize bunch of opensource application programs also on SH processor like Linux PC. So in this case Linux may indicate various application software asset those can be executed on Linux OS environment. In other case Linux may indicate Linux targeted development environment like GNU compiler or debugger. So we need to be conscious about supposed coverage of "Linux" in each context.
&ref(coverage.jpg,nolink); &ref(linux_as_bridge.jpg,nolink);
For us Renesas affiliates, the most important aspect of Linux is "common software foundation to the PC based processor". It means if we can run full-functional Linux upon our 32bit RISC processor, all Linux based application like Samba (File server), Apache (Web server) and Postfix (Mail Transfer Agent) can be executed upon Renesas SuperH processor just same as on Linux PC. Then we could compete with PC targeted major CPU like x86 variants, MIPS and PPC. We also need to note that our competitor Freescale, ARM also put muscle into Linux support now to get into these former PC oriented products. Actually &color(red){Linux already became one of most major OS selection in media ware products like DTV, DVR, PND and Smart phone. So importance of "Linux" is getting very high, not only for generic computer environment but also for our microcomputer business.};
*** Customer expectation [#x1110fa7]
If you are requested to provide Linux solution from your customer, what you can do for that. If requested to provide uITRON, it must be handy because you can handle it just like Renesas device. You may have an experience of offering VxWorks, QNX or Windows CE to your customer. Ownership and business model for these 3rd party products are clearly defined, and if you could find proper contact point you can manage them. However Linux support situation is totally different from these cases and you may face various difficulty.
Initially &color(red){Linux kernel and most related softwares are a kind of opensource, and needless to say they are not our product};. Further out they are not belongs to one single organization. For example Linux kernel is released by it's development community and GNU tools ( like GCC compiler ) are from "Free Software Foundation". Other application programs are released by each developer's group. Essentially &color(red){Linux solution is the collections of various software components developed and delivered independently, and no single company or organization can provide Linux solution as a consolidated own solution};, like other OS. So initial hurdle would be finding the proper party who can manage appropriate collections and delivery.
Please be aware that &color(red){Linux is the accomplishment of various opensource developer's committed works. As each programmer works individually and voluntarily, no one can control his activity. If your customer claim about our Linux solution you can not ask opensource developer to fix the issue like other commercial OS. Though you can not criticize about deficiency of Linux, you can help opensource developers to improve Linux mutuality};, and it is really expected approach to make Linux asset well maintained on our processor environment. If you want to provide better Linux support than our competitors, we need to establish good and live collaborative relationship with opensource development community. There is no other straightforward method to improve our status.
By the way when thinking by becoming customer's standpoint, they might think delivery of Linux should be easy and hard to understand our hardship, especially when customer have had a experience of using Intel x86 (including it's variant like Geode) or Power PC environment. Because various Linux server / desktop solutions are already in place for these enterprise processor and customer can easily utilize these asset also on embedded space. Even you can purchase Linux magazine that bundles free Linux installer DVD, and installing Linux to PC is almost boy's play. &color(red){As Linux kernel already support our SuperH and M32R processor, and GNU compiler also supported these environment, customer may expect Linux can be ported and works on Renesas processor just like PC Linux. However it is not actually such an easy thing};, even this is technically true.
&ref(bsp.jpg);
&color(red){Actual customer support needs various Linux experience and ingenuity because each project requires different delivery.}; It would be hard for you to collect all requested software components as they are not centralized to the single place. These circumstances are totally different from other embedded OS, however we need to have good Linux solution to compete our competitors. Honestly speaking we have some handicap against enterprise oriented CPU like x86, PPC and MIPS, we need to catchup them like ARM is doing. RSO Japan try to make Linux foundation asset (= root of each software ) better so that everyone can earn privilege from wherever they get the solution.
*** Turnkey BSP [#i40c33c8]
&color(red){Customer expect a kind of turnkey method like DVD PC-Linux installer. In embedded Linux world we call it "BSP (= Board Support Packages)"};, that is a collection of all required software components. &color(red){BSP should include 1) kernel, 2) Toolchain (compiler and other development tools) and 3) Application programs (=Userland)};, contents of userland may vary depends on each customer's demand. When designing embedded Linux BSP, hardware abstraction would be a big headache against PC Linux. There runs small program named BIOS in PC hardware and it abstracts each board specific configurations, then looking from OS layer every PC hardwares look like totally same. By virtue of BIOS function single DVD installer can boot all PC platform and it makes PC Linux support easy and efficient.
However each embedded platform has it's own memory map, interrupt assignment and dedicated peripheral device allocation, so embedded BSP need to be developed as custom design. &color(red){To reduce support overhead, embedded CPU like ARM, FreeScale defines their reference platform and develop standard BSP for that. Currently Renesas have various platforms developed regionally and lucking W/W Linux BSP consolidation.}; We need to fix these problem soon.
Another problem is application software coverage in embedded Linux BSP. PC Linux DVD installer includes over thousand applications so that PC Linux can be used for various purpose like server, office client or network appliance. Furthermore most &color(red){PC Linux have on-line automated software management infrastructure and you can easily add/remove applications by yourself upon your needs.}; Unfortunately embedded Linux does not established such smart manageability. &color(red){Even most opensource application distributed with source code and you can re-compile to generate embedded CPU executable binary, it is much harder than PC-Linux.}; To expand Linux adoption in embedded world, we need to improve these application software manageability more.
&ref(bsp_component.jpg);
*** Distribution and System Integrator [#k22d1122]
As Linux solution is composed of various opensource software components, you can gather them separately from the Internet and combine them to make your own BSP by yourself. If you want to use latest software combination, it would be the best way. However in most cases it seems a roundabout approach and customer do not want to waste their time on this. &color(red){There are a number of commercial or non-commercial organization called "distributor" who collect and distribute Linux asset as their "distribution".};
In enterprise Linux world, &color(red){"Redhat" is the biggest distributor}; and many company adopts "Redhat Enterprise Linux" for their IT infrastructure. &color(red){In embedded world "Montavista" is most famous distribution};, You may have requested to provide "Montavista Linux" from your customer. &color(red){Common misconception is these branded Linux differs from opensource Linux.}; Distributor pulls each Linux components from opensource and as long as they call it "Linux" the root code must have same origin. Of course each distribution consist of different collection of components ( kernel version, application selection etc ) and include their original stuff like package management tools, boot method, configuration script. Also distributor do their own QA test, bug fixes if any and providing paid technical support to contracted customer. Finally &color(red){each distribution have their own characteristics and target application, even so there is no essential difference in distributions.}; To our annoyance embedded distribution company seems not so successful lately, due to the difficult-to-reuse their BSP like PC environment. Currently Montavista mostly focus on ARM solution and does not release Renesas CPU BSP. Then customer start anticipating CPU vendor might release standard Linux BSP and it is becoming big challenge for Renesas. If we want to release our own distribution, we need to maintain each software component for the long term and this can not be achieved without good collaborations to each development community. &color(red){Anyway customer demands any distribution for our processor}; if we promote our Linux solution.
&ref(relations.JPG);
&ref(distoro.JPG);
&color(red){There are another type of engineering company categorized "system integrator"};. They do not release generic BSP as distribution, but they will provide custom porting work to each project. Though engineering support is already familiar service in embedded world, &color(red){Linux system integration requires broad and different types of knowledge base. Actually sometime IT application programmer those who are familiar with UNIX operating system adapt better for embedded Linux system than experienced embedded engineer.}; If your customer is not so familiar with Linux,it is highly recommended that to introduce Linux aware system integrator with your solution.
&ref(sier.JPG);
*** W/W support structure [#bb5b5230]
&color(red){As previously mentioned Linux solution requires well maintained distribution (=BSP) and customer support infrastructure.}; At this moment RSO Japan try to manage upstream code quality and functionality with development community as a center of Linux excellence. Due to the limitation of our support resources unfortunately we can not end customer support for all project. &color(red){We defiantly expect good collaboration with each regional Linux system integrator}; to support customer project.
&ref(collabo.JPG);
Lately I understand fundamental guidelines to make this collaboration framework works.
- Essential code quality and functionality must be maintained by Renesas
- Renesas need to provide standard BSP for generic platform that can be purchased from everyone.
- We can not expect deep kernel skills for SI company like kernel scheduler adjustment.
- Toolchain should be delivered from Renesas to eliminate confusion comes from environment.
- Toolchain must be enough sanitized before release, we should not ask SI to maintain these infrastructure.
- All bug-fix done by SI company should be reported and migrate back to mainline to eliminate duplication.
- Application space must be fully cared by SI company.
At this moment, device driver support politics for Renesas specific IP like media codecs are not organized yet. If we want to promote these SoC oriented processor more, we need to find the reasonable solution for this issue.
** kernel development [#w7649367]
*** POSIX compliant [#le266731]
As mentioned, the word of Linux indicates rather broad target in general, though the strict meaning of Linux only indicates just OS kernel core, that is described at middle blue block in following software structure chart. You can see two lines up and down to this middle block. The green colored bottom line divides hardware and software, so it would be easy to distinguish. Another &color(red){blue colored upper line is called POSIX interface};, it stays inside software and divides OS and application space. Even this is not visible and hard to line, this is very important boundary when you learn Linux. All Linux kernel and device drivers must stay inside &color(red){this middle block that is called "Kernel Space"};. In contrast to "Kernel Space" usually we call upper pink colored space as "User Land". The word &color(red){"POSIX"}; stands for "Portable Operating System Interface for uniX" and it &color(red){is generic "OS-Application interface" adopted in various OSs not limited to UNIX but Linux, QNX and Windows NT. All POSIX compliant application program can run on any POSIX supported OSs.}; Therefore a discussion regarding POSIX application would be quite generic and not Renesas specific, and it may hard for us to support them all because we are not familiar with such generic "User Land" applications.
&ref(linux_boundery.jpg);
*** SuperH Linux kernel repository [#ucff8362]
&color(red){You can download latest Linux kernel source for SuperH and other Renesas CPUs from following [[Linux master code repository:http://www.kernel.org]] web site.};~
You may know other code repository, you need to know all these code has been delivered from this site.
&ref(KernelArchives.png);
*** Decentralized management [#j88fcbb4]
Linux kernel has hierarchical structure upon technology sub-system. Each sub-system has sub-system maintainer and as a top of hierarchy there stays master kernel maintainer. To avoid excessive concentration to master maintainer each sub-system manage some child sub-system. And code administration has fully decentralized as following figure. CPU architecture specific manipulations are treated under CPU sub-system, and all CPU support is consolidated into single code. Currently &color(red){Renesas SuperH, M32R and H8 sub-system exist in kernel CPU sub-system, just like other embedded processor ARM, PPC, MIPS, M68K and FRV. So we can say Renesas SuperH is Linux ready device and we are on an equal footing with other major processors};.
&ref(subsystem.JPG);
*** Single source for all CPU [#d21c91a7]
In most OS case, only core API definition are shared but each architecture targeted OS binaries are released separately. Though &color(red){in Linux, all CPU architecture support codes and device driver codes are fully concentrated into one single kernel source}; unlike other OSs. You may surprise to know Linux kernel runs on SuperH is exactly same code used in company's enterprise server. This is the Linux way. I believe this is quite significant factor of Linux code management and it is highly related to Linux productivity. &color(red){Linux kernel generic code must be written as architecture-free universal code and fully shared with all CPU architectures}; except architecture specific functions (MMU, INT, TIMER,... ) . With this code sharing process, every bug-fix or new device support developed upon one CPU architecture penetrate automatically to all other CPU environment. For example if someone write device driver for latest PCI Express LAN card upon Intel processor based PC Linux, we can utilize that code with Renesas SuperH Linux environment with slight mapping adjustment. Utilizing this mechanism Linux can improve its coverage compared to other OS.
&ref(source_consolidate.JPG);
I have highlighted beneficial aspect of Linux code sharing manner, but I also need to mention its difficulty at the same time. Code sharing methodology does not allow each programmer to keep his own proper development speed. &color(red){If you want to stick on some specific kernel version, it immediately means you will be dropped from mainstream Linux momentums and lose opportunity to utilize its knowledge share basis. I strongly emphasise Renesas need to cache up Linux kernel mainline development speed to keep our processor support as well as our competitors.};
*** Kernel migration [#sbd50ec5]
Microsoft takes 3-5 year to make major Windows OS migration like "2000 --> Xp --> Vista". Most of embedded OSs like VxWorks, QNX, Symbian and Windows CE also take over three year to migrate major changes. Then how frequently does Linux version up ? [[ gitstat website managed by CE Linux Forum:http://tree.celinuxforum.org/gitstat/]] monitors Linux development activity and show you live development status. I captured the snapshot of August 2007 kernel release history as follows.
&ref(freq.JPG);
&ref(Andrew.JPG);
&color(red){Linux kernel migration happened in every 60 to 90 days};. Note that kernel 2.6.x to 2.6.y is not a minor revision up, but major version migration like "Xp --> Vista". This record clearly tells you that &color(red){Linux migration speed is beyond comparison to other generic computer OS};. I guess not all people are pleased with this release speed, as they can not spend enough time to system stabilization. Even so at least Linux has a potential to adopt state-of-art industry standards and can be most modern OS than any other. Anyway &color(red){please understand Linux kernel development gains marvelous speed and it seems mostly successful. We defiantly need to catch up this speed to keep our stuff fresh. We are struggling with mainline activity now and I noticed this is tough and everlasting task.};
At the age of former kernel (before version 2.6 release), code migration speed used to be a bit slow and as major difference, there were two kernel versions at the same time to isolate development and stabilization. Even number kernel like 2.4.x was released as stable version and odd-number version like 2.5.x created in parallel for development purpose. With this scheme most of people could use stable one for their product development. When current kernel 2.6 series was released, people expected to have new development version. However Andrew Morton who is master kernel maintainer of kernel 2.6 finally announced &color(red){there is no more development 2.7 branch};, after then development and stabilization are fully merged and kernel release cycle shortened dramatically with the help of high performance distributed code version management system called "git".
&ref(gitk-2.6.png);
Next figure shows current Linux kernel release mechanism. Right after new version (N) released, next development activity (N+1) launches. Initial two weeks is called &color(red){"merge window"}; and kernel developer can put their new code only during this period. Patch is normalized difference code against original kernel source (is last released version), and developer create patches to submit their code . &color(red){If you have any intention to merge something new stuff into mainline kernel like new CPU type support, you have to prepare patch and raise discussion in proper mailing list to introduce your idea so that maintainer accept your submission when you send a patch during next merge window};. Actual patch adoption is judged by each sub-system maintainer and Andrew Morton is takes care for patch that does not have specific maintainer. At every merge window period, bunch of new codes submitted by various developers, then kernel became rather unstable at this point, sometime even compilation fails with the collection of various un-adjusted new code.
&ref(dev_cycle.jpg);
&ref(180px-Linus_Torvalds.jpg);
Once "merge window" closed patch contributor start modify their code to make it work with all other new patches. This coordination takes roughly 2-3 weeks. You may have hard that Linux is originally developed by the guy named Linus Torvalds when he studied at Helsinki university in 1991. After that has been cultivating Linux and lead it's direction to make productive for every developer. Since then Linus has been managing new kernel release. When Linus recognize all new patches becomes enough coordinated, he releases "RC1". The objective of "RC1" is to test and debug on various software and hardware environment. &color(red){Initial kernel consolidation only tested on IA32 and IA32-64, all other CPU architecture need to be tested during RC period}; to reflect hidden bug fixes. So we should test "RC" kernel on our platform and expected to report if we faced any problems. Before new kernel achieved sufficient maturity, several RC version would be released and they spend almost 6 to 8 week to release final version. &color(red){It is critically important that test RC kernel upon our processor and feedback any issues we found to maintain our Linux quality healthy during verification period (= before final release. )}; RSO Japan Linux development team started this activity and I believe SuperH Linux kernel getting better even we need to do more work.
*** Bugfix reduction [#x9a286bd]
&color(red){Based on single code repository every bug fixes are reducible to the master code, }; Thus Linux kernel is getting clean and matured compared to any other proprietary or in-house OS. &color(red){In case some bug fix was released as a fork code, this mechanism will be destroyed. Linux management standpoint, this deviation is quite undesirable situation.}; When you ask 3rd party SI company to fix some bug they might keep it as their private resolution inside their company then deviation occurs. We must be very careful not to cause these confusion.
Another potential disincentive factor is kernel version. &color(red){Development community engineer always works on the latest version, then it would be hard to merge if you submit patch against old kernel.}; We should spend more time to verify opensource code while it is enough fresh.
&ref(recurrent.jpg);
*** No backward compatibility [#e432cbaf]
Most of computer OS make consideration to keep backward compatibility, however &color(red){Linux do not have any intention to secure proven driver. Actually at the Linux kernel migration internal core device driver API like TIMER, DMA, USB ... often changes and former device driver no more works at that point.}; Linux core kernel developer thinks backward compatibility is evil that might cause various lawless driver bugs, and they do not want to carry any obsolete stuff with new kernel API. It seems legitimate argument, but it also requires all device drivers kept maintained at every kernel migration and this transmigration works as an automated driver sanitary mechanism. It means &color(red){if anyone became hard to maintain his code it would be dropped from mainline code. As a result it works as automated code screening.}; You can refer Linux kernel document introducing this philosophy from ----> &ref(stable_api_nonsense.txt);
&ref(backward.JPG);
This is another reason we need to verify our Linux asset at every kernel verification "RC" period.
*** kernel direction [#l26978e6]
Some people claims about Linux roadmap. They say there is no roadmap and commitment for the future technology direction. It is sure that there is no written roadmap in Linux like other commercial OS, however please remember that migration speed of Linux kernel is much faster than others and various new idea,technology and standards have been merged. Linus Torvalds explained about this concept as &color(red){"Linux is evolution, not a intelligent design". It means there is no predetermined roadmap but it moves forward with most expected direction.}; So if you want to add something new to the Linux you can work for that and if your proposal is enough reasonable to many people it would be merged in future kernel. Actually various beneficial idea for small embedded system were proposed and merged into latest Linux kernel like realtime response improvement. So we can say Linux is moving forward with real dynamism.
&ref(evolution.jpg);
*** Board support [#oc6ed70a]
Initial Linux port to the embedded CPU was happened on various consumer products like PDA, Game machine and Network equipment. For example &color(red){SuperH was originally developed upon Sega Deamcast game machine (SH-4)}; and ARM Linux was developed targeting Compaq iPaq PDA (ARM9). &color(red){It used to be a kind of "hacking" without any technical support from CPU venders.}; Embedded CPU venders including Renesas thought that it must be just a hobby and could not expect Linux will become our business infrastructure at that time, so they did not support these activities. Then most of CPU sub-system maintainers are not affiliated with it's CPU vender even now.
Reflecting these history, various board support code stay in mainline kernel. Some of these boards are still aggressively maintained by the community developer but others are already became obsolete and no more maintained. For our case &color(red){Deamcast and HP Jornada are still maintained by the enthusiastic community people, but old RTA platform like Biscaine is no more maintained.}; You can guess why these situation occurs.
As we are still minor in Linux world, customer's first impression for our Linux asset would be important. &color(red){If customer can successfully compile and run Linux upon our reference platform, they might think Renesas Linux seems almost stable like other verified CPU. However if they have faced any difficulty during these process, they may wonder about quality. So first customer success experience is one of key factor to improve our Linux business.}; To achieve this, we need to collaborate with Linux community developer to maintain our board support in kernel code. Like DreamCast or HP Jornada, we should keep our reference platform maintained at every kernel migration. This must be cared by ourselves, because no other people can do this without actual hardware. RSO Japan adopted our Highlander platform to verify SH Linux.
** Renesas Activity [#y2a682ce]
*** Linux supports SuperH, M32R and H8 [#c3287af4]
Like other embedded CPU, several our processor have been supported in Linux kernel. &color(red){SuperH Linux was originally developed by Mr.Niibe who works for Japanese government agency named Sanso-ken and it was merged to the mainline kernel at its version 2.4.0.}; So SuperH has rather long Linux history and &color(red){current SuperH Linux is maintained by the CPU architecture sub-system maintainer named Mr.Paul Mundt.};
H8 support was merged at kernel 2.6.0 with the great contribution of freelance young engineer named Mr.Sato. Several MMU-less processors like H8, M68K (Coldfire) are supported in mainline kernel, however it still requires special development tools and know-how to build Linux environment. Therefore H8 Linux adoption is not so common in business field. &color(red){As here comes the SH-2(A) Linux support expectation, we have just started to care about these MMU-less environment.};
&color(red){M32R Linux support was merged relatively recently at kernel 2.6.9.}; Former SuperH maintainer assume a role of M32R maintainer, however it is mostly maintained by Renesas and our affiliate due to the limitation of generic development board that can be delivered to the opensource developers. &color(red){Some new kernel function like embedded SMP was developped on M32R Linux.}; Anyway SuperH, M32R and H8 are officially supported in mainline Linux code at various maintenance rate. For our business prospective, RSO Japan System Business division have been focused on SuperH Linux utilization, and I will introduce current support status for SuperH processor
&ref(shm32rh8.JPG);
*** SuperH architecture maintainer work in Renesas [#rb33c0b2]
As mentioned previously Linux is mostly driven by the opensource community and its supporting party, Initially I tried to contribute SuperH support code to the mainline with the help of embedded Linux distributer and/or system integrator. However I recognize these investment does not affect the mainline because software know-how is their differentiator and they do not willing to feedback their work to the upstream. &color(red){Finally I understand the only way to achieve our goal is participate ourselves into the actual community development field and establish our position in real Linux world.};
For SuperH Linux development, the key role was taken by the SuperH architecture maintainer. &color(red){So our first step was to talk to Mr.Paul Mundt}; who used to work for another major consumer products company. We can measure Linux development activity level by the number of patch submission. During 2005 to 2006 SuperH Linux patch rate was decreased due to the busyness of his daily work and it was directly reflected SuperH Linux maintenance level. So we really wanted to fix this situation. &color(red){To improve SuperH maintenance level we needed to allocate his time to SH Linux development as much as possible};, then I started to invite him to Renesas. After some discussion, finally &color(red){Paul Mundt have started his career at RTA as a Renesas employee from July 2006. After that SuperH maintenance ratio was dramatically improved and it was reflected after the kernel version 2.6.16.};
&ref(submittion.JPG);
Next figure shows another activity indicator, it is a statistics of SH-Linux mailing list conversation. Currently we have two mailing list, old one mostly used inside Japan is [[ [linuxsh-cvs] :http://sourceforge.net/mailarchive/forum.php?forum_name=linuxsh-cvs]] and current global discussion one is [[ [linuxsh-dev] :http://sourceforge.net/mailarchive/forum.php?forum_name=linuxsh-dev]]. You can see there is a peak traffics in 2001, it was mostly happened inside Japan. I want to point out that &color(red){W/W SH-Linux discussion is getting more active after 2004, I think this is really good tendency}; because it means SH becomes more generic architecture used in W/W.
&ref(ML_stat.JPG);
I believe &color(red){it is our big advantage that we have the community kernel maintainer with us};, because if there happens any necessity of SuperH kernel improvement we can do it with the community power together. If customer ask about our Linux capability please emphasise this point.
*** SuperH kernel improvement [#j2f1b190]
&color(red){At the timing of kernel 2.6.19 release, SuperH architecture sub-system code repository was fully merged with the master repository};. After then SuperH kernel source was integrated into the master code. &color(red){Now only one SH-Linux kernel release point exist at [[master kernel web site (http://www.kernel.org):http://www.kernel.org]]};, and no more confusion of searching local repository. It would make a contribution to improve "test -> patch submission -> merge" cycle on SuperH. This repository consolidation effect the utilization of SuperH, it means right after new kernel released all generic kernel improvement can be used on SuperH. Now you can say "SuperH is one of most actively maintained CPU architecture and customer can use latest Linux technology upon SuperH." So &color(red){looking from functionality coverage view point, our handicap almost dissolved};. These promotion of status was given form the community by the improved contribution level on SuperH.
Here is the list of SuperH specific kernel improvement happened between 2.6.17 to 2.6.22 done by Paul. You can see various new stuff incorporated to these kernel. I know some customer want to stick on an old kernel, however there is no special reason to do so. &color(red){As we know the fact that we have fixed various old kernel bugs};, we do not want to recommend them. If customer thinks old kernel is more stable, we need to say it is totally wrong. Of course it takes sometime to verify BSP, the collection of various components, &color(red){we suggest to adopt the kernel no later than 1 year from its release};. Please note that if you stick on 2.6.15 or older, they do not have any reform done by Paul.
[ 2.6.17 ] -----------------------------------------------------------------------
[ 2.6.18 ] -----------------------------------------------------------------------
[ 2.6.19 ] -----------------------------------------------------------------------
[ 2.6.20 ] -----------------------------------------------------------------------
■ Variable page size support
- SH-X2 extended mode TLB still requires some more work.
- Possible to use 64kB PAGE_SIZE in 29-bit compat mode.
■ Support for SH7722 and SH7785 processors.
■ Improved BUG() reporting through special trapa vector
■ On-chip RTC driver enhancements
- Common driver for all on-chip parts.
- Alarm support
[ 2.6.21 ] -----------------------------------------------------------------------
[ 2.6.22 ] -----------------------------------------------------------------------
*** GNU toolchain for Linux [#a7eefc52]
As mentioned Linux kernel source is unified to all CPU architectures and it must be compiled with GNU compiler, and all other CPU propiatry tools can not be used. So if we provide Linux kernel to our customer, we need to care about GNU development tools together. Usually we call them as "toolchain", it includes 1) compiler, 2) standard library and 3) binary utility. Some Linux kernel function depends on GNU library capabilities, so we should deliver kernel and toolchain as a pair.
&ref(gnutools.JPG);
----
&ref(syncho.JPG);
----
&ref(gnusupport.JPG);
*** Userland [#r2180741]
*** BSP [#we9e679e]
http://www.superh-linux.org
&ref(superh-linux.png);
** Opensource [#vdb8f82d]
*** Definition of "opensource" [#s00d0988]
The organization named OSI ( Opensource Software Initiative ) defines "opensource " as follows
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software
distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form
of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more
than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the
preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed.
Intermediate forms such as the output of a preprocessor or translator are not allowed.
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the
license of the original software.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distribution of
"patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit
distribution of software built from modified source code. The license may require derived works to carry a different name or
version number from the original software.
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not
restrict the program from being used in a business, or from being used for genetic research.
7. Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution
of an additional license by those parties.
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's being part of a particular software distribution.
If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties
to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original
software distribution.
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example,
the license must not insist that all other programs distributed on the same medium must be open-source software.
10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual technology or style of interface.
referred from OSI web site ( http://www.opensource.org/docs/osd )
*** GNU General Public Licence (GPL) [#b07c060d]
Linux kernel is developed and distributed as opensource software, and we can combine it with various other open source programs. We need to be aware of the concept of "open source" and follow its rule even when we utilize them for business usage. First, you must understand the open source license named GPL, it stands for "GNU General Public Licence". GPL/LGPL licence is executed by the organization named GNU and it is adopted by Linux kernel and various open source softwares. GNU also developed various software like GCC, GDB, MAKE and other famous programs you may familiar. Of course there are other open source licences like BSD, however GPL is overwhelming majority one and we can say GPL is one of key factor that assist current Linux success. Original GPL/LGPL draft can be referred them from http://www.gnu.org/licenses/gpl.html and I suggest you to read them once to get correct understanding about GPL. One important notes about GPL is, Linux kernel and most of device driver
adopt and stay on GPL version 2, even GPL plans to update to version 3. For quick GPL review, you need to notice following items at least.
- [[GPL (version 2):http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#TOC1]] -----> &ref(gpl-2.0.txt);
- [[LGPL (version 2.1) :http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC1]] ----> &ref(lgpl-2.1.txt);
*** GPL propagation [#k3fa6388]
- combination of GPL with any other licenced program ===> GPL adopted to all program including proprietary licenced program
- combination of LGPL with any other licenced program ===> GPL + original licence
*** GPL scope of application [#ud3e6392]
- Any program runs inside kernel space must be GPL signed. So all Linux device driver must be GPL licensed.
- Userland program can adopt any preferred license, however you need to care GPL propagation rule described previously.
*** Source code publication [#z80f4c97]
- If you ship any product using GPL signed program, you must indicate that fact to the end user of the products.
- If you provide any software including GPL code to set producer like our customer, you must clarify which code adopted GPL and ask set producer to notice that GPL based code is used in the products in EULA (End User Licence Agreement)
- Anyone who purchased the product that uses GPL program have a right to request it's source code to the product donor ( not to the original program developer and/or other intervening party like Renesas ).
- If the product producer requested to provide source code, he must inform how to get the source that can create exact same binary code used in the products.
- The source code must be delivered only with the cost of reasonable distribution and/or media cost. You can not charge any licence cost on the software code itself.
*** Anyone who received GPL'd source code [#mddea139]
- can analyze and modify disclosed source code.
- can use disclosed source code to any purpose
- can distribute original and/or modified code to anyone.
- can organize group to maintain disclosed source code
- can NOT modify original license statement and developer sign
- must follow GPL statement
*** No warranty (from original GPL v2 chapter 11) [#ra3056cf]
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT
PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER
PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
** Common Issue [#l4ce43bc]
*** coordination of each component [#h249fc18]
*** incompatibility between kernel version [#t0e58113]
*** incompatibility between CPU architecture [#q9fe1ed6]
*** support responsibility [#la87ac30]
*** BUG fixing [#c0a8f7a7]
*** warranty [#affe17da]
** Useful links [#x908aa80]
*** Generic Linux Resources [#i1564b63]
+ [[Linux kernel archives:http://www.kernel.org/]]
+ [[GNU project:http://www.gnu.org/]]
+ [[Linux Device:http://linuxdevices.com/]]
+ [[Linux Weekly News:http://lwn.net/]]
*** SuperH Linux Resources [#k1bb5877]
+ [[Renesas Linux Code repository:http://www.superh-linux.org/]]
+ [[KPIT GNU toolchain distribution:http://www.kpitgnutools.com/index.php]]
+ [[Linux SH project wiki:http://www.linux-sh.org/cgi-bin/moin.cgi]]
*** Technical Documents [#x749afee]
+ [[Linux Device Driver:]]
![[PukiWiki]](image/taikyoku.gif "[PukiWiki]")
