Compare commits
868 Commits
Author | SHA1 | Date |
---|---|---|
Harald Welte | 8bb59f081a | |
Holger Hans Peter Freyther | 5075145814 | |
Holger Hans Peter Freyther | 74b543bbb1 | |
Holger Hans Peter Freyther | 8062967cf3 | |
Holger Hans Peter Freyther | 0b2ae79dad | |
Holger Hans Peter Freyther | 83edf1dce4 | |
Harald Welte | e9ead4c0f3 | |
Harald Welte | e003221b02 | |
Harald Welte | 5cf873f499 | |
Harald Welte | 3c99769de2 | |
Harald Welte | a2a2d67e1a | |
Harald Welte | b16ceec77f | |
Harald Welte | 7fa273ffc2 | |
Holger Hans Peter Freyther | 8fab0f3222 | |
Holger Hans Peter Freyther | 4f6d4893ce | |
Holger Hans Peter Freyther | 44c4b09e83 | |
Holger Hans Peter Freyther | 2f86725324 | |
Holger Hans Peter Freyther | 57cc5e9c58 | |
Holger Hans Peter Freyther | f608e7e4f9 | |
Holger Hans Peter Freyther | ffce9e7f87 | |
Holger Hans Peter Freyther | 1a9dd62e22 | |
Holger Hans Peter Freyther | f79726fdcc | |
Holger Hans Peter Freyther | f5d3fba955 | |
Holger Hans Peter Freyther | 03fd342e14 | |
Holger Hans Peter Freyther | 69d9a0609d | |
Holger Hans Peter Freyther | 6e7383839c | |
Holger Hans Peter Freyther | 6453080cef | |
Holger Hans Peter Freyther | 57c0346f56 | |
Holger Hans Peter Freyther | 040f4432f5 | |
Holger Hans Peter Freyther | fea919fa5d | |
Holger Hans Peter Freyther | 5b35766651 | |
Holger Hans Peter Freyther | 3f228b8e6e | |
Holger Hans Peter Freyther | 16f9bbb288 | |
Holger Hans Peter Freyther | 673d53bbf5 | |
Holger Hans Peter Freyther | 01e96dd240 | |
Holger Hans Peter Freyther | b6dc4b91a7 | |
Holger Hans Peter Freyther | e9d0aa7cb4 | |
Holger Hans Peter Freyther | bd76a6f5b6 | |
Holger Hans Peter Freyther | 286a9a90cf | |
Holger Hans Peter Freyther | 212ab87663 | |
Holger Hans Peter Freyther | a7946542c8 | |
Holger Hans Peter Freyther | 0c797643dd | |
Holger Hans Peter Freyther | 0ca774fc19 | |
Holger Hans Peter Freyther | f59fe37872 | |
Holger Hans Peter Freyther | 94a82eeedd | |
Holger Hans Peter Freyther | 5732aadd15 | |
Harald Welte | 49ca632e9a | |
Holger Hans Peter Freyther | a144d1c3c0 | |
Harald Welte | 0c79987641 | |
Holger Hans Peter Freyther | 2761cd97f4 | |
Holger Hans Peter Freyther | e89d7ce77d | |
Holger Hans Peter Freyther | 1bca046d23 | |
Holger Hans Peter Freyther | c83652a73a | |
Holger Hans Peter Freyther | 3105854fcb | |
Holger Hans Peter Freyther | 8becd5a4bf | |
Holger Hans Peter Freyther | f9d158b747 | |
Holger Hans Peter Freyther | 96c91eb8d6 | |
Holger Hans Peter Freyther | 9c3b75040a | |
Holger Hans Peter Freyther | 5e475b6b99 | |
Holger Hans Peter Freyther | 8b40a0c2f9 | |
Holger Hans Peter Freyther | 4214e03720 | |
Harald Welte | fcfffacfa8 | |
Harald Welte | 920b27acba | |
Holger Hans Peter Freyther | 336c4212e5 | |
Holger Hans Peter Freyther | 40075f5141 | |
Holger Hans Peter Freyther | 661e10551b | |
Holger Hans Peter Freyther | 4a35eb9273 | |
Holger Hans Peter Freyther | 7782174da7 | |
Harald Welte | 558d76a412 | |
Holger Hans Peter Freyther | 8e4991163e | |
Christopher Larson | 3a01a4f2bc | |
Holger Hans Peter Freyther | cd0d240314 | |
Holger Hans Peter Freyther | 7059d16861 | |
Holger Hans Peter Freyther | d01ad496af | |
Harald Welte | 3cf0f9d338 | |
Harald Welte | 27edfb7481 | |
Holger Hans Peter Freyther | 6e5e1f8b9e | |
Holger Hans Peter Freyther | d9a117ed21 | |
Holger Hans Peter Freyther | 84f23b2203 | |
Harald Welte | 1c3982289e | |
Harald Welte | c793b65258 | |
Harald Welte | 2bae25e4cd | |
Holger Hans Peter Freyther | 7cb8c8d1b5 | |
Harald Welte | 410d086a5a | |
Holger Hans Peter Freyther | 87f47c8586 | |
Harald Welte | 23689a489f | |
Holger Hans Peter Freyther | 7389f6f2b1 | |
Holger Hans Peter Freyther | b7f2cddc23 | |
Holger Hans Peter Freyther | 2257338267 | |
Holger Hans Peter Freyther | 63085244df | |
Holger Hans Peter Freyther | a5d6d983ec | |
Holger Hans Peter Freyther | 41a683d627 | |
Holger Hans Peter Freyther | 99a6840eb4 | |
Holger Hans Peter Freyther | de0f9b5f3d | |
Holger Hans Peter Freyther | aea5136f30 | |
Holger Hans Peter Freyther | ec29824f84 | |
Holger Hans Peter Freyther | 1b7bb4ae95 | |
Holger Hans Peter Freyther | 85d5ea4aae | |
Holger Hans Peter Freyther | 675a2f814f | |
Holger Hans Peter Freyther | 0f3ea35f17 | |
Holger Hans Peter Freyther | a7c614b3dd | |
Holger Hans Peter Freyther | 3e7dbdcdba | |
Holger Hans Peter Freyther | 90d152fcff | |
Holger Hans Peter Freyther | 7aa59c430e | |
Harald Welte | 35ff59937b | |
Harald Welte | 209d4ec0be | |
Harald Welte | cbb7200e61 | |
Harald Welte | fc1c332a7e | |
Harald Welte | 8d7bfd23e9 | |
Harald Welte | 85a4948d4b | |
Harald Welte | 6c31e6c557 | |
Holger Hans Peter Freyther | b6780a5826 | |
Harald Welte | 29263f1625 | |
Harald Welte | b7d4da72b6 | |
Harald Welte | 2b21fe5ad9 | |
Harald Welte | b67bed4d3a | |
Harald Welte | c71b4ead63 | |
Holger Hans Peter Freyther | 89df7559e5 | |
Holger Hans Peter Freyther | 78a632ea52 | |
Harald Welte | b1be0d9702 | |
Harald Welte | 5b6ad0ce9d | |
Harald Welte | 766aabc563 | |
Holger Hans Peter Freyther | 52ddf4d91b | |
Holger Hans Peter Freyther | 0473bf96d3 | |
Harald Welte | 9b48f833cf | |
Harald Welte | e518a3224a | |
Harald Welte | ad495228e2 | |
Holger Hans Peter Freyther | 2b59ca73fe | |
Holger Hans Peter Freyther | c4c453a1db | |
Holger Hans Peter Freyther | e9379558e3 | |
Holger Hans Peter Freyther | 9383d3a2a6 | |
Harald Welte | cf29168330 | |
Holger Hans Peter Freyther | cb0096d041 | |
Harald Welte | bcf7764458 | |
Holger Hans Peter Freyther | ffe5723a3a | |
Harald Welte | 0925b23f06 | |
Holger Hans Peter Freyther | a060c5d2ab | |
Harald Welte | 489f392cc6 | |
Holger Hans Peter Freyther | 487211e30f | |
Holger Hans Peter Freyther | 2deddb9f09 | |
Harald Welte | 7a9a2ddecb | |
Holger Hans Peter Freyther | 73b77fe9ba | |
Harald Welte | d0d30fee99 | |
Harald Welte | 4aad63620b | |
Holger Hans Peter Freyther | 87a6d04505 | |
Holger Hans Peter Freyther | 8523266bce | |
Harald Welte | 557e1b47ba | |
Holger Hans Peter Freyther | cd37803dab | |
Holger Hans Peter Freyther | 267d7a4dab | |
Holger Hans Peter Freyther | c88a4fb4c4 | |
Holger Hans Peter Freyther | b726969f84 | |
Holger Hans Peter Freyther | 0b9c954d0b | |
Holger Hans Peter Freyther | fd02a175f6 | |
Holger Hans Peter Freyther | db8e4ec0e4 | |
Holger Hans Peter Freyther | 9bf7206ce7 | |
Holger Hans Peter Freyther | 8b61400347 | |
Holger Hans Peter Freyther | 7370f20647 | |
Holger Hans Peter Freyther | c7dc800cc5 | |
Holger Hans Peter Freyther | 5368ea68f1 | |
Harald Welte | aff7df713e | |
Holger Hans Peter Freyther | 738df59de8 | |
Holger Hans Peter Freyther | e8e126f1eb | |
Holger Hans Peter Freyther | b92f71e94b | |
Harald Welte | d8a23bc008 | |
Harald Welte | be7111d6c6 | |
Harald Welte | 5b7eff1c95 | |
Harald Welte | 350981f9a8 | |
Harald Welte | 8c57364452 | |
Harald Welte | df64e62c45 | |
Harald Welte | e74231478d | |
Harald Welte | 98b850cdb7 | |
Holger Hans Peter Freyther | a8c239f2a4 | |
Holger Hans Peter Freyther | 38d2ca2f36 | |
Holger Hans Peter Freyther | 8431d916a5 | |
Holger Hans Peter Freyther | f9756a1ec6 | |
Holger Hans Peter Freyther | 1c5bff88f1 | |
Holger Hans Peter Freyther | f63bb56056 | |
Holger Hans Peter Freyther | 671337f9c8 | |
Holger Hans Peter Freyther | 99d3462a72 | |
Holger Hans Peter Freyther | 99fabcdfd6 | |
Holger Hans Peter Freyther | bd02fdb4a0 | |
Holger Hans Peter Freyther | 0f9b8cb7e6 | |
Holger Hans Peter Freyther | 6f27e12588 | |
Holger Hans Peter Freyther | f8d915a370 | |
Holger Hans Peter Freyther | a02d4dfabf | |
Holger Hans Peter Freyther | 790799b138 | |
Holger Hans Peter Freyther | 3e4ffca0b3 | |
Holger Hans Peter Freyther | 02f61cf522 | |
Holger Hans Peter Freyther | f36b6907a9 | |
Harald Welte | 55b7b92f34 | |
Harald Welte | a1aad22e4e | |
Harald Welte | 638474f669 | |
Holger Hans Peter Freyther | b272d37c60 | |
Holger Hans Peter Freyther | 9e2fce0fba | |
Holger Hans Peter Freyther | 91523445fc | |
Holger Hans Peter Freyther | 65e5ee8e4e | |
Holger Hans Peter Freyther | 12a1b8ea4b | |
Holger Hans Peter Freyther | 9e130f1ac1 | |
Holger Hans Peter Freyther | dbb57efcd1 | |
Holger Hans Peter Freyther | d6fd5c09d0 | |
Holger Hans Peter Freyther | ee7b9cf4fa | |
Holger Hans Peter Freyther | 9106dd27b9 | |
Holger Hans Peter Freyther | 67ff3d4b8b | |
Holger Hans Peter Freyther | 61eb982980 | |
Holger Hans Peter Freyther | 16aafee394 | |
Holger Hans Peter Freyther | 653bccdde1 | |
Holger Hans Peter Freyther | 8d053fb3ae | |
Harald Welte | b13eaf470f | |
Holger Hans Peter Freyther | 3279c6791f | |
Holger Hans Peter Freyther | 6f54e1b374 | |
Harald Welte | d1e0a1f78d | |
Harald Welte | 6ae5eefa93 | |
Harald Welte | d07870af73 | |
Holger Hans Peter Freyther | 0f4626d2d8 | |
Jan Luebbe | 5e17d8e537 | |
Holger Hans Peter Freyther | a5c48367a6 | |
Holger Hans Peter Freyther | 2ae26ee3fa | |
Holger Hans Peter Freyther | 3be74372be | |
Holger Hans Peter Freyther | 46ea81ade5 | |
Holger Hans Peter Freyther | aeb390d1cf | |
Holger Hans Peter Freyther | 6a4abb5830 | |
Holger Hans Peter Freyther | b8b0dff3d4 | |
Holger Hans Peter Freyther | 4f78b6ef78 | |
Holger Hans Peter Freyther | 97ba83f17a | |
Holger Hans Peter Freyther | 4f61482461 | |
Holger Hans Peter Freyther | a6cbcf75d5 | |
Holger Hans Peter Freyther | 25a726eea5 | |
Holger Hans Peter Freyther | 1579cdf0fe | |
Holger Hans Peter Freyther | c0cbc30d4c | |
Holger Hans Peter Freyther | d6415c8069 | |
Holger Hans Peter Freyther | a4331e9bee | |
Holger Hans Peter Freyther | 138ac3bc45 | |
Holger Hans Peter Freyther | c35fa18841 | |
Holger Hans Peter Freyther | d9150d375c | |
Holger Hans Peter Freyther | fd604f8497 | |
Holger Hans Peter Freyther | bbbc805a2d | |
Holger Hans Peter Freyther | ba44e70c38 | |
Holger Hans Peter Freyther | f5b92b4bf2 | |
Holger Hans Peter Freyther | 2d8f097946 | |
Holger Hans Peter Freyther | f88c9a6fbd | |
Holger Hans Peter Freyther | 62e7f7f1bc | |
Holger Hans Peter Freyther | d03aa9c516 | |
Harald Welte | 2be99ac429 | |
Harald Welte | 6734e9a695 | |
Harald Welte | 5928a0374a | |
Holger Hans Peter Freyther | 8479f83f39 | |
Harald Welte | 73295758f9 | |
Holger Hans Peter Freyther | a641873503 | |
Holger Hans Peter Freyther | 9805fb9f81 | |
Holger Hans Peter Freyther | 50dba82586 | |
Holger Hans Peter Freyther | 4e2ab7017f | |
Holger Hans Peter Freyther | 9f0744ce76 | |
Holger Hans Peter Freyther | 21c475ae4a | |
Holger Hans Peter Freyther | f4320dd67f | |
Holger Hans Peter Freyther | 1f71735516 | |
Holger Hans Peter Freyther | fe53a9d4aa | |
Holger Hans Peter Freyther | 9416f178b1 | |
Holger Hans Peter Freyther | d838ac6e80 | |
Holger Hans Peter Freyther | e2ab56be8f | |
Holger Hans Peter Freyther | e0bf4c7fea | |
Holger Hans Peter Freyther | 4166201d03 | |
Holger Hans Peter Freyther | a6ae74f721 | |
Holger Hans Peter Freyther | 94fa2d9623 | |
Holger Hans Peter Freyther | be68ad33d2 | |
Holger Hans Peter Freyther | 4cfac93114 | |
Holger Hans Peter Freyther | 4df5621826 | |
Holger Hans Peter Freyther | 5d46944934 | |
Holger Hans Peter Freyther | d5f6ae1142 | |
Holger Hans Peter Freyther | e423b30a83 | |
Holger Hans Peter Freyther | ae891be609 | |
Holger Hans Peter Freyther | 4d8fef32c9 | |
Holger Hans Peter Freyther | a6f1cb82a7 | |
Holger Hans Peter Freyther | 33fe48f3b7 | |
Holger Hans Peter Freyther | 794c0e73e6 | |
Holger Hans Peter Freyther | d1d9f99eb6 | |
Holger Hans Peter Freyther | e568fa2c27 | |
Holger Hans Peter Freyther | e6ec2228da | |
Holger Hans Peter Freyther | 9257e4b8a1 | |
Holger Hans Peter Freyther | 0f6a89c788 | |
Holger Hans Peter Freyther | c1625ee284 | |
Holger Hans Peter Freyther | 40355ff62e | |
Holger Hans Peter Freyther | a7befd603b | |
Holger Hans Peter Freyther | 88c1293c49 | |
Jan Luebbe | e94c542d7c | |
Holger Hans Peter Freyther | 90a211eb56 | |
Elizabeth Flanagan | 06072024be | |
Robert Yang | 107ec95659 | |
Richard Purdie | af3e5039e8 | |
Richard Purdie | 08d70734d5 | |
Holger Hans Peter Freyther | f3f2d7149d | |
Yi Zhao | 164a4d1bac | |
Richard Purdie | 7e0dd59e30 | |
Holger Hans Peter Freyther | 4fed144378 | |
Holger Hans Peter Freyther | 914296ad20 | |
Holger Hans Peter Freyther | c0663ce337 | |
Holger Hans Peter Freyther | 420ea289a2 | |
Holger Hans Peter Freyther | d9a77eb641 | |
Holger Hans Peter Freyther | 17acc4a562 | |
Holger Hans Peter Freyther | 45580f23e8 | |
Holger Hans Peter Freyther | 62ac580831 | |
Holger Hans Peter Freyther | be8f70e8a1 | |
Holger Hans Peter Freyther | c29b5d8bb4 | |
Holger Hans Peter Freyther | 03c9643695 | |
Harald Welte | ce6f4b0bce | |
Holger Hans Peter Freyther | 9f86fa35a2 | |
Harald Welte | 242922ceae | |
Harald Welte | a79df5e650 | |
Harald Welte | df89bf00e7 | |
Harald Welte | a3c1f02557 | |
Lianhao Lu | aca161f8a0 | |
Richard Purdie | 94c8d01eba | |
Richard Purdie | e1e0dd932b | |
Richard Purdie | 6c335846d9 | |
Beth 'pidge' Flanagan | 774f93e8d3 | |
Joshua Lock | 535cfa538b | |
Joshua Lock | ac63b3f8ef | |
Scott Garman | 4039b5b97c | |
Richard Purdie | 67334bfb26 | |
Richard Purdie | 36e13dd42f | |
Richard Purdie | de485f4973 | |
Darren Hart | 56310cbc4c | |
Scott Garman | 68cd8deadc | |
Zhai Edwin | b2a0243f05 | |
Otavio Salvador | a99b7d39dc | |
Otavio Salvador | 755508c423 | |
Richard Purdie | adbf38414e | |
Richard Purdie | c3be61e204 | |
Richard Purdie | 490753f440 | |
Richard Purdie | f3fc5e1e3f | |
Richard Purdie | e2c5e5a513 | |
Richard Purdie | c5a9efca96 | |
Holger Hans Peter Freyther | 5508643b52 | |
Holger Hans Peter Freyther | 910852c052 | |
Dexuan Cui | 842d3ece07 | |
Holger Hans Peter Freyther | 7aaa4cc880 | |
Holger Hans Peter Freyther | 6d69dba610 | |
Holger Hans Peter Freyther | aed232262e | |
Holger Hans Peter Freyther | 6dcaf7d614 | |
Harald Welte | 77f660aa0d | |
Holger Hans Peter Freyther | 39d7350b90 | |
Harald Welte | 967184aef7 | |
Holger Hans Peter Freyther | bdbd14a8d5 | |
Harald Welte | b9d489c543 | |
Holger Hans Peter Freyther | 2a378aa333 | |
Holger Hans Peter Freyther | f1ce2c13e5 | |
Holger Hans Peter Freyther | 999cf4843e | |
Holger Hans Peter Freyther | b863e59aa6 | |
Holger Hans Peter Freyther | 73bcda3f97 | |
Holger Hans Peter Freyther | dd6f9356b1 | |
Holger Hans Peter Freyther | 1e224b39ae | |
Holger Hans Peter Freyther | 39b09a8849 | |
Holger Hans Peter Freyther | 8caa70df0a | |
Holger Hans Peter Freyther | 5a11d46c4e | |
Holger Hans Peter Freyther | d24c97d308 | |
Saul Wold | 15905aec48 | |
Saul Wold | 2b92d9f6d3 | |
Holger Hans Peter Freyther | 96a864f527 | |
Richard Purdie | bfa48c3c09 | |
Otavio Salvador | ef6062981b | |
Scott Garman | f57eca6f28 | |
Saul Wold | 885ebdae10 | |
Darren Hart | 33561a5417 | |
Darren Hart | bb31c819be | |
Darren Hart | d1c5de9ccb | |
Darren Hart | 4274ebdd00 | |
Holger Hans Peter Freyther | e005f8d60e | |
Holger Hans Peter Freyther | fab01cc657 | |
Holger Hans Peter Freyther | 9d939cbe6c | |
Holger Hans Peter Freyther | aeca0842f3 | |
Elizabeth Flanagan | 0fbd6a1615 | |
Scott Rifenbark | bda8a084f5 | |
Beth Flanagan | 939ec1ca1e | |
Holger Hans Peter Freyther | e08238ed3d | |
Richard Purdie | 69b307523c | |
Joshua Lock | 6482c0e20d | |
Saul Wold | ac9c62c907 | |
Saul Wold | 806c23ef2e | |
Saul Wold | 4c496a970f | |
Richard Purdie | fa6eb32a5a | |
Joshua Lock | eaec7e9624 | |
Wenzong Fan | e6ea83fece | |
Nitin A Kamble | 613e985811 | |
Wenzong Fan | b900d54f57 | |
Wenzong Fan | 83e5279d62 | |
Wenzong Fan | b36cde2308 | |
Wenzong Fan | c1a2249c96 | |
Joshua Lock | e3afb1ebc8 | |
Saul Wold | 686345f1d0 | |
Saul Wold | 7b15a9372c | |
Saul Wold | b52792d84d | |
Nitin A Kamble | a684aa1df4 | |
Holger Hans Peter Freyther | 904300e21a | |
Matthew McClintock | 69a3fba2aa | |
Jessica Zhang | c6ec5a0d9e | |
Lianhao Lu | de68393270 | |
Richard Purdie | 12e5797e51 | |
Bruce Ashfield | 6c65263f8d | |
Joshua Lock | 32f0a45c33 | |
Jean-François Dagenais | 726f3bce5a | |
Saul Wold | 75f253d7d2 | |
Wolfgang Denk | a5c04850e6 | |
Joshua Lock | cef4500611 | |
Saul Wold | df2da07184 | |
Matthew McClintock | 77912d65c7 | |
Saul Wold | 878425f147 | |
Richard Purdie | fa9ad15e41 | |
Nitin A Kamble | 961f75d11b | |
Matthew McClintock | 60c5ef3508 | |
Matthew McClintock | e5e7a913c2 | |
Richard Purdie | 165e39a0bb | |
Khem Raj | 09d5966e46 | |
Richard Purdie | 0bd433ebf5 | |
Richard Purdie | c2e003ecd5 | |
Richard Purdie | 9f51e226dc | |
Richard Purdie | 681499ebfe | |
Richard Purdie | 5d96094939 | |
Richard Purdie | 10d9e0805e | |
Richard Purdie | c1c6613ddd | |
Richard Purdie | 5db4eaac2d | |
Richard Purdie | f99f36f637 | |
Jiajun Xu | 7705d9a8cc | |
Richard Purdie | bcec98bf1c | |
Matthew McClintock | 0d9809c4ec | |
Saul Wold | dcf64630f8 | |
Saul Wold | fa610f7f20 | |
Paul Eggleton | d97ad36d90 | |
Paul Eggleton | de7377a170 | |
Paul Eggleton | c471ec56b4 | |
Mei Lei | 9d55534cc7 | |
Richard Purdie | 54f4e9b66c | |
Zhai Edwin | 3e783002b3 | |
Martin Jansa | 935678cbe1 | |
Matthew McClintock | ee75b5020b | |
Richard Purdie | 5f21a24580 | |
Richard Purdie | 100002e4c6 | |
Richard Purdie | 71824019fb | |
Matthew McClintock | 3400b3d2df | |
Richard Purdie | 745d83f968 | |
Richard Purdie | 340a680de2 | |
Matthew McClintock | 3048bd79b3 | |
Michael Brown | ef37926f31 | |
Richard Purdie | 4c30bcfbfe | |
Phil Blundell | 709ad80662 | |
Martin Jansa | 08a834a08a | |
Martin Jansa | 6c3dd24e59 | |
Martin Jansa | 66d6c031b0 | |
Martin Jansa | 957882caef | |
Khem Raj | 8781450256 | |
Martin Jansa | 9d23f215a0 | |
Richard Purdie | 2c1a0b7d32 | |
Richard Purdie | 9e52c53a5d | |
Richard Purdie | f812a2c912 | |
Richard Purdie | d3c848094f | |
Richard Purdie | 37d694ae80 | |
Otavio Salvador | e391e1a200 | |
Otavio Salvador | 199f985754 | |
Paul Eggleton | 395ffa8930 | |
Matthew McClintock | 90920546e4 | |
Koen Kooi | 1d9ec42166 | |
Koen Kooi | 57481984c9 | |
Mark Hatle | 05051d864d | |
Mark Hatle | 48ee7e9b3a | |
Mark Hatle | 1278cee687 | |
Mark Hatle | b5195d2739 | |
Mark Hatle | 7561770d43 | |
Paul Menzel | 03fbfe7cf1 | |
Darren Hart | 9faa58ecdc | |
Saul Wold | cc19812fb4 | |
Richard Purdie | 110d499544 | |
Scott Garman | 7fe64f43f4 | |
Scott Garman | 47007075d4 | |
Scott Garman | 9dc2193d31 | |
Scott Garman | 403d5e0b7d | |
Paul Eggleton | 5d9dfed5c4 | |
Paul Eggleton | 9924a6c72d | |
Tom Zanussi | ccf6077d4e | |
Tom Zanussi | 38978dc0b8 | |
Tom Zanussi | 9152ef8b1d | |
Otavio Salvador | 4e4521b5bf | |
Otavio Salvador | 501211d4d5 | |
Eric Bénard | 155aad308c | |
Dongxiao Xu | 11e383d24c | |
Joshua Lock | aff0c68b0f | |
Joshua Lock | 3b75e27536 | |
Joshua Lock | 5f3b7a7616 | |
Eric Bénard | fb8d219960 | |
Scott Garman | ae88920dec | |
Martin Jansa | 57c6f14828 | |
Martin Jansa | bd9a5e1b88 | |
Martin Jansa | 8614fcf709 | |
Martin Jansa | 2202d845ab | |
Koen Kooi | a55d8c6aa4 | |
Martin Jansa | b6312e2d51 | |
Dmitry Cherukhin | 5a41a612c9 | |
Kumar Gala | aaea770f1f | |
Elizabeth Flanagan | 6e4607f23a | |
Richard Purdie | 5a192f85d9 | |
Koen Kooi | 9ce56ec4ca | |
Koen Kooi | e47cfd447c | |
Saul Wold | fc2433de1d | |
Saul Wold | 8cf7c76ce1 | |
Saul Wold | 5d8269d28a | |
Saul Wold | 9f542cf856 | |
Holger Hans Peter Freyther | 398a0159a6 | |
Richard Purdie | 8ce627f9b1 | |
Richard Purdie | a7e5ad1268 | |
Richard Purdie | 8223a46ca0 | |
Richard Purdie | 1890a0f3b2 | |
Joshua Lock | 2dbcd4154c | |
Saul Wold | 0524f419cf | |
Saul Wold | a90c197e94 | |
Saul Wold | 21458bd419 | |
Saul Wold | 7e96247751 | |
Saul Wold | 07e2aa9b80 | |
Saul Wold | 5c37b7ea47 | |
Joshua Lock | 79081f46ec | |
Matthew McClintock | 4f9e333b05 | |
Julian Pidancet | dc09c258f0 | |
Khem Raj | 5de0f305f9 | |
Khem Raj | 52dc5edde3 | |
Otavio Salvador | 9d086cd151 | |
Otavio Salvador | 2edde1021f | |
Otavio Salvador | afc60481c7 | |
Khem Raj | eb94ba9052 | |
Khem Raj | 6fa445d50e | |
Anders Darander | 795843df09 | |
Khem Raj | 8a20492e8a | |
Khem Raj | 70ff3b6d98 | |
Lauri Hintsala | ba79e6f631 | |
Martin Jansa | 071d5de3f3 | |
Xiaofeng Yan | 1fa324c533 | |
Saul Wold | 958c7f773f | |
Saul Wold | 141240c409 | |
Samuel Stirtzel | 89e945be6a | |
Samuel Stirtzel | 7d30c2df87 | |
Wenzong Fan | 90a4f95d3d | |
Tom Rini | 53db004d24 | |
Christopher Larson | f7d5b31d6c | |
Richard Purdie | 35d3782099 | |
Matthew McClintock | 1080ef1105 | |
Matthew McClintock | 7bd151a4f3 | |
Martin Jansa | e1f53370ed | |
Martin Jansa | e708d0ab68 | |
Julian Pidancet | e6e867558b | |
Julian Pidancet | ab81049f37 | |
Jason Wessel | 0b2f036a81 | |
Richard Purdie | 6ed9f0763b | |
Saul Wold | 1e225af16e | |
Richard Purdie | 385365f689 | |
Richard Purdie | dec4fb1bee | |
Kumar Gala | ef1a8f21e0 | |
Richard Purdie | 0c1b16db4c | |
Tom Zanussi | 02c530f442 | |
Dmitry Eremin-Solenikov | df2fddf9cb | |
Martin Jansa | 6f0c0167c6 | |
Richard Purdie | 47c5f1c3bc | |
Otavio Salvador | 29a5cc693c | |
Denis Carikli | c3a1b97511 | |
Eric Bénard | f1369ae9fe | |
Matthew McClintock | 8620d997d4 | |
Matthew McClintock | 7d06a71c02 | |
Richard Purdie | 7c5028614b | |
Matthew McClintock | 6844fac9d5 | |
Saul Wold | 41b5ca8582 | |
Matthew McClintock | 7a1504dfe8 | |
Matthew McClintock | 062623f6ef | |
Matthew McClintock | 62ad5b81cb | |
Matthew McClintock | ada8ebb116 | |
Matthew McClintock | f1f2cbbc0d | |
Matthew McClintock | c434795edf | |
Matthew McClintock | 25330d9f38 | |
Richard Purdie | c1c5eb6866 | |
Richard Purdie | 51e089403a | |
Richard Purdie | 058ef489a0 | |
Khem Raj | 3eb7e626d0 | |
Andrew Gabbasov | 386e75b7f0 | |
Andrew Gabbasov | f72a801d51 | |
Andrew Gabbasov | 4ffc32566a | |
Paul Eggleton | 3f692305dc | |
Paul Eggleton | 4ff17dc89d | |
Saul Wold | 1a506c5dfd | |
Simon Busch | 84865e45ea | |
Richard Purdie | ae97dbe1db | |
Richard Purdie | edb2641243 | |
Richard Purdie | c8635bab0b | |
Richard Purdie | cd50451812 | |
Dmitry Eremin-Solenikov | 877979c8b5 | |
Dmitry Eremin-Solenikov | f69eca96d1 | |
lumag | c0a8c9b985 | |
Dmitry Eremin-Solenikov | 09ab224a2f | |
Dmitry Eremin-Solenikov | 0e9001afd5 | |
Dmitry Eremin-Solenikov | d63678cdfa | |
Khem Raj | 1af2581f0b | |
Richard Purdie | 9dcb176dc8 | |
Zhai Edwin | 64ba74deff | |
Mark Hatle | ff047d3a77 | |
Khem Raj | b137421cfc | |
Dmitry Eremin-Solenikov | 3a8590f105 | |
Dmitry Eremin-Solenikov | 3571525ab8 | |
Dmitry Eremin-Solenikov | 204762c531 | |
Daniel Lazzari | 394d340ab1 | |
Bruce Ashfield | 4bf5435d95 | |
Bruce Ashfield | 05dba88379 | |
Paul Eggleton | 1ab5a6851d | |
Paul Eggleton | 781866f64e | |
Joshua Lock | 702c428804 | |
Xiaofeng Yan | 5882121a94 | |
Joshua Lock | 6c2f754a0a | |
Joshua Lock | acd0bedbce | |
Joshua Lock | 90f8d53800 | |
Matthew McClintock | 23c6b49566 | |
Robert Yang | f204d16012 | |
Richard Purdie | 3796541746 | |
Richard Purdie | 0e676f74c5 | |
Richard Purdie | 26666187e3 | |
Matthew McClintock | c270f92b08 | |
Christopher Larson | 1670051a79 | |
Christopher Larson | c61f04c34e | |
Christopher Larson | 2b26745c70 | |
Christopher Larson | 28ca6cc34b | |
Christopher Larson | ada59bde67 | |
Richard Purdie | 9a68fb1364 | |
Richard Purdie | f87c92143e | |
Richard Purdie | f38e44bbb2 | |
Richard Purdie | 4d7f50382e | |
Matthew McClintock | 6803d97bdb | |
Matthew McClintock | 81ed10442b | |
Richard Purdie | 1a46002fad | |
Richard Purdie | 2747b2003e | |
Richard Purdie | 375297ea28 | |
Richard Purdie | c2662a5095 | |
Richard Purdie | da56e3df88 | |
Richard Purdie | 388dbe4928 | |
Richard Purdie | dbcce81f66 | |
Christopher Larson | 46ac868403 | |
Paul Eggleton | 6e1105e1e8 | |
Richard Purdie | 4494f59a26 | |
Joshua Lock | 13590b23c6 | |
Matthew McClintock | 2c3861ee68 | |
Matthew McClintock | 9cf7aabecf | |
Scott Rifenbark | 81d1a4aadf | |
Scott Rifenbark | 6578845f69 | |
Scott Rifenbark | b5a4e78df5 | |
Scott Rifenbark | 68b55c1e85 | |
Scott Rifenbark | 4234beb034 | |
Scott Rifenbark | ddb5143d9d | |
Scott Rifenbark | 25dcd673f5 | |
Scott Rifenbark | 1ad7977742 | |
Scott Rifenbark | fe40f117c1 | |
Scott Rifenbark | 0550d8c73e | |
Scott Rifenbark | bc821a2ab5 | |
Scott Rifenbark | aa72ed0b23 | |
Scott Rifenbark | e0a2bbd2a4 | |
Scott Rifenbark | 1a2454fcba | |
Scott Rifenbark | 92675a93ba | |
Scott Rifenbark | 1bafc89431 | |
Scott Rifenbark | dc785b64c1 | |
Scott Rifenbark | 257dbe8d39 | |
Scott Rifenbark | c81c4cb0c7 | |
Scott Rifenbark | da3edbd85b | |
Scott Rifenbark | 44aa4f320a | |
Scott Rifenbark | 38dbccd997 | |
Scott Rifenbark | 6c27a7b50e | |
Scott Rifenbark | 7ef3bc97b7 | |
Scott Rifenbark | 807b96f882 | |
Scott Rifenbark | 2add98ffc8 | |
Scott Rifenbark | ed7fe93178 | |
Scott Rifenbark | 397081ef41 | |
Scott Rifenbark | 570eeea297 | |
Scott Rifenbark | b9232eb2b4 | |
Scott Rifenbark | 405578286d | |
Scott Rifenbark | 1c937b6359 | |
Scott Rifenbark | 567200dcf2 | |
Scott Rifenbark | b4f5708c05 | |
Scott Rifenbark | b8cb28fc2f | |
Tom Zanussi | 495d37ab0b | |
Scott Rifenbark | 9d60cb9450 | |
Scott Rifenbark | 5592e80877 | |
Scott Rifenbark | 979ecf3eea | |
Scott Rifenbark | 770f5bb229 | |
Scott Rifenbark | 44211ed500 | |
Scott Rifenbark | ac715efc14 | |
Scott Rifenbark | b256ae8f80 | |
Scott Rifenbark | fa969ffb59 | |
Scott Rifenbark | e67311606e | |
Scott Rifenbark | b17aecd70a | |
Scott Rifenbark | 1cb265f575 | |
Scott Rifenbark | 31b7cac818 | |
Scott Rifenbark | 05738313c3 | |
Scott Rifenbark | 25cf1a65ec | |
Scott Rifenbark | 442730168e | |
Scott Rifenbark | 2ca5c8c03e | |
Scott Rifenbark | fa056279ea | |
Scott Rifenbark | 7ec098bedc | |
Scott Rifenbark | 68d048abfd | |
Scott Rifenbark | d5848aa719 | |
Scott Rifenbark | 9edf601d2d | |
Scott Rifenbark | 155d0deae8 | |
Scott Rifenbark | 85408dfd36 | |
Scott Rifenbark | 43fb63af31 | |
Scott Rifenbark | 8add7fccde | |
Scott Rifenbark | 01f5e6778c | |
Scott Rifenbark | 1ff81200ac | |
Scott Rifenbark | d2f1ca8cba | |
Scott Rifenbark | caab52f6cc | |
Scott Rifenbark | b4eb195b34 | |
Scott Rifenbark | 3dbabb693d | |
Scott Rifenbark | 5dd34a717e | |
Scott Rifenbark | e7cfb3b469 | |
Scott Rifenbark | c2494d3014 | |
Scott Rifenbark | 9d87cd9952 | |
Scott Rifenbark | 1851a96b47 | |
Scott Rifenbark | efd2d7ee05 | |
Scott Rifenbark | b16bc3d277 | |
Holger Hans Peter Freyther | a56c10d89a | |
Holger Hans Peter Freyther | 75abc06f34 | |
Holger Hans Peter Freyther | 23dbc00a4e | |
Holger Hans Peter Freyther | 73bcd9a75c | |
Holger Hans Peter Freyther | 6e64338f29 | |
Holger Hans Peter Freyther | 8f3955af20 | |
Holger Hans Peter Freyther | e77df798a7 | |
Holger Hans Peter Freyther | 9566715405 | |
Holger Hans Peter Freyther | c2d998c9b4 | |
Holger Hans Peter Freyther | 8946d523ed | |
Holger Hans Peter Freyther | 183d75b24d | |
Holger Hans Peter Freyther | dca725b368 | |
Holger Hans Peter Freyther | f58538edcd | |
Holger Hans Peter Freyther | 9d9e971a87 | |
Holger Hans Peter Freyther | f75ebc3f4b | |
Holger Hans Peter Freyther | 447e9fa77d | |
Scott Rifenbark | adcf8bf7b5 | |
Scott Rifenbark | fda17235fd | |
Holger Hans Peter Freyther | 8083eb0be3 | |
Holger Hans Peter Freyther | 1d9cbe012b | |
Holger Hans Peter Freyther | 0b0ef8aae6 | |
Holger Hans Peter Freyther | 6fe3d67299 | |
Holger Hans Peter Freyther | b49f5121bb | |
Holger Hans Peter Freyther | f52b4a6ba8 | |
Holger Hans Peter Freyther | ba3023edbc | |
Holger Hans Peter Freyther | 60ee4cd504 | |
Scott Rifenbark | c5bdef5617 | |
Scott Rifenbark | 77640e96dd | |
Scott Rifenbark | 98d9b82759 | |
Scott Rifenbark | 1aac5c310f | |
Scott Rifenbark | 1924f52cc8 | |
Scott Rifenbark | 6535ba6077 | |
Scott Rifenbark | eae4945a9d | |
Scott Rifenbark | 5ec43fdbb8 | |
Richard Purdie | 5ed59ae0f2 | |
Scott Rifenbark | e02d553b45 | |
Scott Rifenbark | 720446629b | |
Scott Rifenbark | db9d36f196 | |
Scott Rifenbark | 4cca048ab8 | |
Scott Rifenbark | 51b3d9dd53 | |
Bruce Ashfield | bc885cd8d3 | |
Scott Rifenbark | c657668a07 | |
Scott Rifenbark | 02e3d4dc70 | |
Scott Rifenbark | 57746012d0 | |
Scott Rifenbark | 8a48ec4297 | |
Scott Rifenbark | 61637a5241 | |
Scott Rifenbark | 8a475908b5 | |
Scott Rifenbark | b7d2cf0525 | |
Khem Raj | 4d7fbeda35 | |
Scott Rifenbark | baf536c62c | |
Scott Rifenbark | 0c48a6805e | |
Scott Rifenbark | 1ea2c63bf5 | |
Scott Rifenbark | f33f49a348 | |
Scott Rifenbark | cc6819ede7 | |
Scott Rifenbark | 2a68be025b | |
Scott Rifenbark | f05471dcf8 | |
Scott Rifenbark | 5fe2c53493 | |
Scott Rifenbark | 6b2ae5fd17 | |
Scott Rifenbark | 4eeeded4a7 | |
Scott Rifenbark | 931db10bd0 | |
Scott Rifenbark | 522268be49 | |
Scott Rifenbark | 8e17bffa42 | |
Scott Rifenbark | cc004358f1 | |
Scott Rifenbark | 0e623482d5 | |
Scott Rifenbark | ec31ee62d5 | |
Scott Rifenbark | a59ca8316b | |
Scott Rifenbark | 4423b5b024 | |
Scott Rifenbark | b47f39dbc3 | |
Scott Rifenbark | 9d72b706fa | |
Scott Rifenbark | 5d4888723b | |
Scott Rifenbark | 49e3171850 | |
Scott Rifenbark | 66ddb69916 | |
Scott Rifenbark | de1dcde413 | |
Scott Rifenbark | 9f36b1fe16 | |
Scott Rifenbark | 38c7a8a069 | |
Scott Rifenbark | 23bac7cb0e | |
Scott Rifenbark | 0021456aad | |
Scott Rifenbark | a568995f40 | |
Scott Rifenbark | f82ac840aa | |
Scott Rifenbark | cd2c80dedc | |
Scott Rifenbark | ed93525e65 | |
Scott Rifenbark | 4025831e90 | |
Scott Rifenbark | 94c381f71b | |
Scott Rifenbark | 588e21b339 | |
Richard Purdie | 3429095e86 | |
Richard Purdie | feb11f1079 | |
Richard Purdie | fbec475275 | |
Dongxiao Xu | 317fc4fbd0 | |
Dongxiao Xu | 909dd5b306 | |
Jessica Zhang | 24623d149d | |
Dongxiao Xu | 5687f68f3e | |
Dongxiao Xu | f282b7a027 | |
Dongxiao Xu | 32b1c9150f | |
Dongxiao Xu | 7a541d69dd | |
Joshua Lock | aa1cb68ce2 | |
Saul Wold | dc1f3a3bd0 | |
Saul Wold | 5fbb040355 | |
Bruce Ashfield | 9886c510f9 | |
Paul Eggleton | 49de6096b1 | |
Paul Eggleton | 7eb193fc49 | |
Joshua Lock | 4aa6a8e9a6 | |
Joshua Lock | a1f3aff110 | |
Joshua Lock | bb351c2f41 | |
Joshua Lock | bed552f8d0 | |
Scott Rifenbark | 41c564fe60 | |
Scott Rifenbark | cae817e833 | |
Scott Rifenbark | 7bb8b8f438 | |
Scott Rifenbark | c32652716d | |
Scott Rifenbark | 748fd4543b | |
Scott Rifenbark | 56f7ed979c | |
Scott Rifenbark | 3a15c9f8d0 | |
Scott Rifenbark | fc7ceaead0 | |
Scott Rifenbark | a626a5c208 | |
Scott Rifenbark | cb333ad6f3 | |
Scott Rifenbark | 5b58674c6b | |
Scott Rifenbark | 1017d2aec8 | |
Scott Rifenbark | 9786db045f | |
Scott Rifenbark | 158b84844e | |
Scott Rifenbark | 421c22d32c | |
Scott Rifenbark | 90ccadecc3 | |
Scott Rifenbark | 07638448b0 | |
Scott Rifenbark | f343aa4cc6 | |
Scott Rifenbark | 5cd07954ea | |
Scott Rifenbark | e0338b844f | |
Scott Rifenbark | cde57ddf84 | |
Scott Rifenbark | bee5046908 | |
Scott Rifenbark | 4e6b4c09a5 | |
Scott Rifenbark | 89496194ba | |
Scott Rifenbark | 19f9b25947 | |
Scott Rifenbark | f97e445fc6 | |
Scott Rifenbark | 2766a88a3b | |
Scott Rifenbark | b57c529115 | |
Scott Rifenbark | 319f4ee481 | |
Scott Rifenbark | 2cf26ef150 | |
Scott Rifenbark | 2c1b5b1054 | |
Scott Rifenbark | b8be92c34d | |
Scott Rifenbark | 6b4133b08f | |
Scott Rifenbark | 96d43c2410 | |
Richard Purdie | cde2aa61cf | |
Richard Purdie | 1d18aeafa6 | |
Richard Purdie | b8a67d3000 | |
Richard Purdie | c3c8084855 | |
Richard Purdie | cd0ef4d7c1 | |
Saul Wold | c9e35a126a | |
Richard Purdie | 4456226e45 | |
Saul Wold | bf8f071c5b | |
Elizabeth Flanagan | 3b1e8a214e | |
Darren Hart | 1015dfce8d | |
Richard Purdie | a0b1c14587 | |
Dexuan Cui | 66934fc311 | |
Richard Purdie | 80de0f946b | |
Richard Purdie | 5e65389335 | |
Zhai Edwin | d513e5f92c | |
Saul Wold | e9f8b99215 |
|
@ -9,11 +9,9 @@ build*/pyshtables.py
|
|||
pstage/
|
||||
scripts/oe-git-proxy-socks
|
||||
sources/
|
||||
meta-darwin
|
||||
meta-maemo
|
||||
meta-extras
|
||||
meta-m2
|
||||
meta-prvt*
|
||||
!meta-*
|
||||
!meta-skeleton
|
||||
!meta-demoapps
|
||||
*.swp
|
||||
*.orig
|
||||
*.rej
|
||||
|
|
|
@ -68,12 +68,12 @@ Intel Atom based PCs and devices (atom-pc)
|
|||
|
||||
The atom-pc MACHINE is tested on the following platforms:
|
||||
|
||||
o Asus eee901
|
||||
o Asus EeePC 901
|
||||
o Acer Aspire One
|
||||
o Toshiba NB305
|
||||
o Intel Embedded Development Board 1-N450 (Black Sand)
|
||||
|
||||
and is likely to work on many unlisted atom based devices. The MACHINE type
|
||||
and is likely to work on many unlisted Atom based devices. The MACHINE type
|
||||
supports ethernet, wifi, sound, and i915 graphics by default in addition to
|
||||
common PC input devices, busses, and so on.
|
||||
|
||||
|
@ -83,26 +83,18 @@ straightforward with a caveat for USB devices. The following examples assume the
|
|||
target boot device is /dev/sdb, be sure to verify this and use the correct
|
||||
device as the following commands are run as root and are not reversable.
|
||||
|
||||
Hard Disk:
|
||||
1. Build a directdisk image format. This will generate proper partition tables
|
||||
that will in turn be written to the physical media. For example:
|
||||
|
||||
$ bitbake core-image-minimal-directdisk
|
||||
|
||||
2. Use the "dd" utility to write the image to the raw block device. For example:
|
||||
|
||||
# dd if=core-image-minimal-directdisk-atom-pc.hdddirect of=/dev/sdb
|
||||
|
||||
USB Device:
|
||||
1. Build an hddimg image format. This is a simple filesystem without partition
|
||||
tables and is suitable for USB keys. For example:
|
||||
1. Build a live image. This image type consists of a simple filesystem
|
||||
without a partition table, which is suitable for USB keys, and with the
|
||||
default setup for the atom-pc machine, this image type is built
|
||||
automatically for any image you build. For example:
|
||||
|
||||
$ bitbake core-image-minimal-live
|
||||
$ bitbake core-image-minimal
|
||||
|
||||
2. Use the "dd" utility to write the image to the raw block device. For
|
||||
example:
|
||||
|
||||
# dd if=core-image-minimal-live-atom-pc.hddimg of=/dev/sdb
|
||||
# dd if=core-image-minimal-atom-pc.hddimg of=/dev/sdb
|
||||
|
||||
If the device fails to boot with "Boot error" displayed, it is likely the BIOS
|
||||
cannot understand the physical layout of the disk (or rather it expects a
|
||||
|
@ -126,7 +118,7 @@ USB Device:
|
|||
|
||||
b. Copy the contents of the poky image to the USB-ZIP mode device:
|
||||
|
||||
# mount -o loop core-image-minimal-live-atom-pc.hddimg /tmp/image
|
||||
# mount -o loop core-image-minimal-atom-pc.hddimg /tmp/image
|
||||
# mount /dev/sdb4 /tmp/usbkey
|
||||
# cp -rf /tmp/image/* /tmp/usbkey
|
||||
|
||||
|
@ -150,7 +142,7 @@ faster CPU, more RAM, an ethernet port, more USB ports, microSD, and removes
|
|||
the NAND flash. The beagleboard MACHINE is tested on the following platforms:
|
||||
|
||||
o Beagleboard C4
|
||||
o Beagleboard xM Rev A
|
||||
o Beagleboard xM rev A & B
|
||||
|
||||
The Beagleboard C4 has NAND, while the xM does not. For the sake of simplicity,
|
||||
these instructions assume you have erased the NAND on the C4 so its boot
|
||||
|
|
|
@ -4,6 +4,10 @@ import os
|
|||
import sys
|
||||
import warnings
|
||||
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
|
||||
from bb import fetch2
|
||||
import logging
|
||||
|
||||
logger = logging.getLogger("BitBake")
|
||||
|
||||
try:
|
||||
import cPickle as pickle
|
||||
|
@ -16,13 +20,20 @@ class BBConfiguration(object):
|
|||
Manages build options and configurations for one run
|
||||
"""
|
||||
|
||||
def __init__(self, debug, debug_domains):
|
||||
setattr(self, "data", {})
|
||||
setattr(self, "file", [])
|
||||
setattr(self, "cmd", None)
|
||||
setattr(self, "dump_signatures", True)
|
||||
setattr(self, "debug", debug)
|
||||
setattr(self, "debug_domains", debug_domains)
|
||||
def __init__(self, **options):
|
||||
self.data = {}
|
||||
self.file = []
|
||||
self.cmd = None
|
||||
self.dump_signatures = True
|
||||
self.prefile = []
|
||||
self.postfile = []
|
||||
self.parse_only = True
|
||||
|
||||
def __getattr__(self, attribute):
|
||||
try:
|
||||
return super(BBConfiguration, self).__getattribute__(attribute)
|
||||
except AttributeError:
|
||||
return None
|
||||
|
||||
_warnings_showwarning = warnings.showwarning
|
||||
def _showwarning(message, category, filename, lineno, file=None, line=None):
|
||||
|
@ -39,82 +50,70 @@ warnings.showwarning = _showwarning
|
|||
warnings.simplefilter("ignore", DeprecationWarning)
|
||||
|
||||
import bb.event
|
||||
|
||||
# Need to map our I/O correctly. stdout is a pipe to the server expecting
|
||||
# events. We save this and then map stdout to stderr.
|
||||
|
||||
eventfd = os.dup(sys.stdout.fileno())
|
||||
bb.event.worker_pipe = os.fdopen(eventfd, 'w', 0)
|
||||
|
||||
# map stdout to stderr
|
||||
os.dup2(sys.stderr.fileno(), sys.stdout.fileno())
|
||||
|
||||
# Replace those fds with our own
|
||||
#logout = data.expand("${TMPDIR}/log/stdout.%s" % os.getpid(), self.cfgData, True)
|
||||
#mkdirhier(os.path.dirname(logout))
|
||||
#newso = open("/tmp/stdout.%s" % os.getpid(), 'w')
|
||||
#os.dup2(newso.fileno(), sys.stdout.fileno())
|
||||
#os.dup2(newso.fileno(), sys.stderr.fileno())
|
||||
|
||||
# Don't read from stdin from the parent
|
||||
si = file("/dev/null", 'r')
|
||||
os.dup2(si.fileno( ), sys.stdin.fileno( ))
|
||||
|
||||
# We don't want to see signals to our parent, e.g. Ctrl+C
|
||||
os.setpgrp()
|
||||
|
||||
# Save out the PID so that the event can include it the
|
||||
# events
|
||||
bb.event.worker_pid = os.getpid()
|
||||
bb.event.useStdout = False
|
||||
|
||||
hashfile = sys.argv[1]
|
||||
buildfile = sys.argv[2]
|
||||
taskname = sys.argv[3]
|
||||
|
||||
import bb.cooker
|
||||
|
||||
buildfile = sys.argv[1]
|
||||
taskname = sys.argv[2]
|
||||
if len(sys.argv) >= 4:
|
||||
dryrun = sys.argv[3]
|
||||
else:
|
||||
dryrun = False
|
||||
if len(sys.argv) >= 5:
|
||||
hashfile = sys.argv[4]
|
||||
p = pickle.Unpickler(file(hashfile, "rb"))
|
||||
hashdata = p.load()
|
||||
else:
|
||||
hashdata = None
|
||||
|
||||
debug = hashdata["msg-debug"]
|
||||
debug_domains = hashdata["msg-debug-domains"]
|
||||
verbose = hashdata["verbose"]
|
||||
handler = bb.event.LogHandler()
|
||||
logger.addHandler(handler)
|
||||
|
||||
bb.utils.init_logger(bb.msg, verbose, debug, debug_domains)
|
||||
#An example to make debug log messages show up
|
||||
#bb.msg.init_msgconfig(True, 3, [])
|
||||
|
||||
cooker = bb.cooker.BBCooker(BBConfiguration(debug, debug_domains), None)
|
||||
cooker.parseConfiguration()
|
||||
console = logging.StreamHandler(sys.stdout)
|
||||
format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
|
||||
bb.msg.addDefaultlogFilter(console)
|
||||
console.setFormatter(format)
|
||||
|
||||
cooker.bb_cache = bb.cache.init(cooker)
|
||||
cooker.status = bb.cache.CacheData()
|
||||
def worker_fire(event, d):
|
||||
if isinstance(event, logging.LogRecord):
|
||||
console.handle(event)
|
||||
bb.event.worker_fire = worker_fire
|
||||
bb.event.worker_pid = os.getpid()
|
||||
|
||||
(fn, cls) = cooker.bb_cache.virtualfn2realfn(buildfile)
|
||||
initialenv = os.environ.copy()
|
||||
config = BBConfiguration()
|
||||
|
||||
def register_idle_function(self, function, data):
|
||||
pass
|
||||
|
||||
cooker = bb.cooker.BBCooker(config, register_idle_function, initialenv)
|
||||
config_data = cooker.configuration.data
|
||||
cooker.status = config_data
|
||||
cooker.handleCollections(bb.data.getVar("BBFILE_COLLECTIONS", config_data, 1))
|
||||
|
||||
fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
|
||||
buildfile = cooker.matchFile(fn)
|
||||
fn = cooker.bb_cache.realfn2virtual(buildfile, cls)
|
||||
fn = bb.cache.Cache.realfn2virtual(buildfile, cls)
|
||||
|
||||
cooker.buildSetVars()
|
||||
|
||||
# Load data into the cache for fn and parse the loaded cache data
|
||||
the_data = cooker.bb_cache.loadDataFull(fn, cooker.get_file_appends(fn), cooker.configuration.data)
|
||||
cooker.bb_cache.setData(fn, buildfile, the_data)
|
||||
cooker.bb_cache.handle_data(fn, cooker.status)
|
||||
|
||||
#exportlist = bb.utils.preserved_envvars_export_list()
|
||||
#bb.utils.filter_environment(exportlist)
|
||||
the_data = bb.cache.Cache.loadDataFull(fn, cooker.get_file_appends(fn), cooker.configuration.data)
|
||||
|
||||
if taskname.endswith("_setscene"):
|
||||
the_data.setVarFlag(taskname, "quieterrors", "1")
|
||||
|
||||
if hashdata:
|
||||
bb.parse.siggen.set_taskdata(hashdata["hashes"], hashdata["deps"])
|
||||
|
||||
for h in hashdata["hashes"]:
|
||||
bb.data.setVar("BBHASH_%s" % h, hashdata["hashes"][h], the_data)
|
||||
for h in hashdata["deps"]:
|
||||
bb.data.setVar("BBHASHDEPS_%s" % h, hashdata["deps"][h], the_data)
|
||||
|
||||
ret = 0
|
||||
if sys.argv[4] != "True":
|
||||
if dryrun != "True":
|
||||
ret = bb.build.exec_task(fn, taskname, the_data)
|
||||
sys.exit(ret)
|
||||
|
||||
|
|
|
@ -149,8 +149,7 @@ def exec_func(func, d, dirs = None):
|
|||
adir = dirs[-1]
|
||||
else:
|
||||
adir = data.getVar('B', d, 1)
|
||||
if not os.path.exists(adir):
|
||||
adir = None
|
||||
bb.utils.mkdirhier(adir)
|
||||
|
||||
ispython = flags.get('python')
|
||||
if flags.get('fakeroot') and not flags.get('task'):
|
||||
|
@ -223,7 +222,7 @@ def exec_func_shell(function, d, runfile, cwd=None):
|
|||
|
||||
with open(runfile, 'w') as script:
|
||||
script.write('#!/bin/sh -e\n')
|
||||
if bb.msg.loggerVerbose:
|
||||
if bb.msg.loggerDefaultVerbose:
|
||||
script.write("set -x\n")
|
||||
data.emit_func(function, script, d)
|
||||
if cwd:
|
||||
|
@ -234,7 +233,7 @@ def exec_func_shell(function, d, runfile, cwd=None):
|
|||
|
||||
cmd = runfile
|
||||
|
||||
if bb.msg.loggerVerbose:
|
||||
if bb.msg.loggerDefaultVerbose:
|
||||
logfile = LogTee(logger, sys.stdout)
|
||||
else:
|
||||
logfile = sys.stdout
|
||||
|
|
|
@ -150,60 +150,27 @@ def parser_cache_savemerge(d):
|
|||
bb.utils.unlockfile(glf)
|
||||
|
||||
|
||||
Logger = logging.getLoggerClass()
|
||||
class BufferedLogger(Logger):
|
||||
def __init__(self, name, level=0, target=None):
|
||||
Logger.__init__(self, name)
|
||||
self.setLevel(level)
|
||||
self.buffer = []
|
||||
self.target = target
|
||||
|
||||
def handle(self, record):
|
||||
self.buffer.append(record)
|
||||
|
||||
def flush(self):
|
||||
for record in self.buffer:
|
||||
self.target.handle(record)
|
||||
self.buffer = []
|
||||
|
||||
class PythonParser():
|
||||
class ValueVisitor():
|
||||
"""Visitor to traverse a python abstract syntax tree and obtain
|
||||
the variables referenced via bitbake metadata APIs, and the external
|
||||
functions called.
|
||||
"""
|
||||
|
||||
getvars = ("d.getVar", "bb.data.getVar", "data.getVar")
|
||||
expands = ("d.expand", "bb.data.expand", "data.expand")
|
||||
execs = ("bb.build.exec_func", "bb.build.exec_task")
|
||||
execfuncs = ("bb.build.exec_func", "bb.build.exec_task")
|
||||
|
||||
@classmethod
|
||||
def _compare_name(cls, strparts, node):
|
||||
"""Given a sequence of strings representing a python name,
|
||||
where the last component is the actual Name and the prior
|
||||
elements are Attribute nodes, determine if the supplied node
|
||||
matches.
|
||||
"""
|
||||
|
||||
if not strparts:
|
||||
return True
|
||||
|
||||
current, rest = strparts[0], strparts[1:]
|
||||
if isinstance(node, ast.Attribute):
|
||||
if current == node.attr:
|
||||
return cls._compare_name(rest, node.value)
|
||||
elif isinstance(node, ast.Name):
|
||||
if current == node.id:
|
||||
return True
|
||||
return False
|
||||
|
||||
@classmethod
|
||||
def compare_name(cls, value, node):
|
||||
"""Convenience function for the _compare_node method, which
|
||||
can accept a string (which is split by '.' for you), or an
|
||||
iterable of strings, in which case it checks to see if any of
|
||||
them match, similar to isinstance.
|
||||
"""
|
||||
|
||||
if isinstance(value, basestring):
|
||||
return cls._compare_name(tuple(reversed(value.split("."))),
|
||||
node)
|
||||
else:
|
||||
return any(cls.compare_name(item, node) for item in value)
|
||||
|
||||
def __init__(self, value):
|
||||
self.var_references = set()
|
||||
self.var_execs = set()
|
||||
self.direct_func_calls = set()
|
||||
self.var_expands = set()
|
||||
self.value = value
|
||||
|
||||
@classmethod
|
||||
def warn(cls, func, arg):
|
||||
def warn(self, func, arg):
|
||||
"""Warn about calls of bitbake APIs which pass a non-literal
|
||||
argument for the variable name, as we're not able to track such
|
||||
a reference.
|
||||
|
@ -213,54 +180,49 @@ class PythonParser():
|
|||
funcstr = codegen.to_source(func)
|
||||
argstr = codegen.to_source(arg)
|
||||
except TypeError:
|
||||
logger.debug(2, 'Failed to convert function and argument to source form')
|
||||
self.log.debug(2, 'Failed to convert function and argument to source form')
|
||||
else:
|
||||
logger.debug(1, "Warning: in call to '%s', argument '%s' is "
|
||||
"not a literal", funcstr, argstr)
|
||||
self.log.debug(1, self.unhandled_message % (funcstr, argstr))
|
||||
|
||||
def visit_Call(self, node):
|
||||
if self.compare_name(self.getvars, node.func):
|
||||
name = self.called_node_name(node.func)
|
||||
if name in self.getvars:
|
||||
if isinstance(node.args[0], ast.Str):
|
||||
self.var_references.add(node.args[0].s)
|
||||
else:
|
||||
self.warn(node.func, node.args[0])
|
||||
elif self.compare_name(self.expands, node.func):
|
||||
if isinstance(node.args[0], ast.Str):
|
||||
self.warn(node.func, node.args[0])
|
||||
self.var_expands.update(node.args[0].s)
|
||||
elif isinstance(node.args[0], ast.Call) and \
|
||||
self.compare_name(self.getvars, node.args[0].func):
|
||||
pass
|
||||
else:
|
||||
self.warn(node.func, node.args[0])
|
||||
elif self.compare_name(self.execs, node.func):
|
||||
elif name in self.execfuncs:
|
||||
if isinstance(node.args[0], ast.Str):
|
||||
self.var_execs.add(node.args[0].s)
|
||||
else:
|
||||
self.warn(node.func, node.args[0])
|
||||
elif isinstance(node.func, ast.Name):
|
||||
self.direct_func_calls.add(node.func.id)
|
||||
elif isinstance(node.func, ast.Attribute):
|
||||
# We must have a qualified name. Therefore we need
|
||||
# to walk the chain of 'Attribute' nodes to determine
|
||||
# the qualification.
|
||||
attr_node = node.func.value
|
||||
identifier = node.func.attr
|
||||
while isinstance(attr_node, ast.Attribute):
|
||||
identifier = attr_node.attr + "." + identifier
|
||||
attr_node = attr_node.value
|
||||
if isinstance(attr_node, ast.Name):
|
||||
identifier = attr_node.id + "." + identifier
|
||||
self.direct_func_calls.add(identifier)
|
||||
elif name and isinstance(node.func, (ast.Name, ast.Attribute)):
|
||||
self.execs.add(name)
|
||||
|
||||
def __init__(self):
|
||||
#self.funcdefs = set()
|
||||
def called_node_name(self, node):
|
||||
"""Given a called node, return its original string form"""
|
||||
components = []
|
||||
while node:
|
||||
if isinstance(node, ast.Attribute):
|
||||
components.append(node.attr)
|
||||
node = node.value
|
||||
elif isinstance(node, ast.Name):
|
||||
components.append(node.id)
|
||||
return '.'.join(reversed(components))
|
||||
else:
|
||||
break
|
||||
|
||||
def __init__(self, name, log):
|
||||
self.var_references = set()
|
||||
self.var_execs = set()
|
||||
self.execs = set()
|
||||
#self.external_cmds = set()
|
||||
self.references = set()
|
||||
self.log = BufferedLogger('BitBake.Data.%s' % name, logging.DEBUG, log)
|
||||
|
||||
self.unhandled_message = "in call of %s, argument '%s' is not a string literal"
|
||||
self.unhandled_message = "while parsing %s, %s" % (name, self.unhandled_message)
|
||||
|
||||
def parse_python(self, node):
|
||||
|
||||
h = hash(str(node))
|
||||
|
||||
if h in pythonparsecache:
|
||||
|
@ -271,24 +233,25 @@ class PythonParser():
|
|||
code = compile(check_indent(str(node)), "<string>", "exec",
|
||||
ast.PyCF_ONLY_AST)
|
||||
|
||||
visitor = self.ValueVisitor(code)
|
||||
for n in ast.walk(code):
|
||||
if n.__class__.__name__ == "Call":
|
||||
visitor.visit_Call(n)
|
||||
self.visit_Call(n)
|
||||
|
||||
self.references.update(visitor.var_references)
|
||||
self.references.update(visitor.var_execs)
|
||||
self.execs = visitor.direct_func_calls
|
||||
self.references.update(self.var_references)
|
||||
self.references.update(self.var_execs)
|
||||
|
||||
pythonparsecache[h] = {}
|
||||
pythonparsecache[h]["refs"] = self.references
|
||||
pythonparsecache[h]["execs"] = self.execs
|
||||
|
||||
class ShellParser():
|
||||
def __init__(self):
|
||||
def __init__(self, name, log):
|
||||
self.funcdefs = set()
|
||||
self.allexecs = set()
|
||||
self.execs = set()
|
||||
self.log = BufferedLogger('BitBake.Data.%s' % name, logging.DEBUG, log)
|
||||
self.unhandled_template = "unable to handle non-literal command '%s'"
|
||||
self.unhandled_template = "while parsing %s, %s" % (name, self.unhandled_template)
|
||||
|
||||
def parse_shell(self, value):
|
||||
"""Parse the supplied shell code in a string, returning the external
|
||||
|
@ -403,8 +366,7 @@ class ShellParser():
|
|||
|
||||
cmd = word[1]
|
||||
if cmd.startswith("$"):
|
||||
logger.debug(1, "Warning: execution of non-literal "
|
||||
"command '%s'", cmd)
|
||||
self.log.debug(1, self.unhandled_template % cmd)
|
||||
elif cmd == "eval":
|
||||
command = " ".join(word for _, word in words[1:])
|
||||
self.parse_shell(command)
|
||||
|
|
|
@ -288,7 +288,9 @@ class BBCooker:
|
|||
self.status = bb.cache.CacheData(self.caches_array)
|
||||
self.handleCollections( bb.data.getVar("BBFILE_COLLECTIONS", self.configuration.data, 1) )
|
||||
|
||||
fn = self.matchFile(buildfile)
|
||||
fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
|
||||
fn = self.matchFile(fn)
|
||||
fn = bb.cache.Cache.realfn2virtual(fn, cls)
|
||||
elif len(pkgs_to_build) == 1:
|
||||
self.updateCache()
|
||||
|
||||
|
|
|
@ -49,6 +49,7 @@ from bb import data_smart
|
|||
from bb import codeparser
|
||||
import bb
|
||||
|
||||
logger = data_smart.logger
|
||||
_dict_type = data_smart.DataSmart
|
||||
|
||||
def init():
|
||||
|
@ -258,7 +259,7 @@ def emit_func(func, o=sys.__stdout__, d = init()):
|
|||
emit_var(key, o, d, False) and o.write('\n')
|
||||
|
||||
emit_var(func, o, d, False) and o.write('\n')
|
||||
newdeps = bb.codeparser.ShellParser().parse_shell(d.getVar(func, True))
|
||||
newdeps = bb.codeparser.ShellParser(func, logger).parse_shell(d.getVar(func, True))
|
||||
seen = set()
|
||||
while newdeps:
|
||||
deps = newdeps
|
||||
|
@ -267,39 +268,45 @@ def emit_func(func, o=sys.__stdout__, d = init()):
|
|||
for dep in deps:
|
||||
if bb.data.getVarFlag(dep, "func", d):
|
||||
emit_var(dep, o, d, False) and o.write('\n')
|
||||
newdeps |= bb.codeparser.ShellParser().parse_shell(d.getVar(dep, True))
|
||||
newdeps |= bb.codeparser.ShellParser(dep, logger).parse_shell(d.getVar(dep, True))
|
||||
newdeps -= seen
|
||||
|
||||
def update_data(d):
|
||||
"""Performs final steps upon the datastore, including application of overrides"""
|
||||
d.finalize()
|
||||
|
||||
def build_dependencies(key, keys, shelldeps, d):
|
||||
def build_dependencies(key, keys, shelldeps, vardepvals, d):
|
||||
deps = set()
|
||||
vardeps = d.getVarFlag(key, "vardeps", True)
|
||||
try:
|
||||
if d.getVarFlag(key, "func"):
|
||||
value = d.getVar(key, False)
|
||||
if key in vardepvals:
|
||||
value = d.getVarFlag(key, "vardepvalue", True)
|
||||
elif d.getVarFlag(key, "func"):
|
||||
if d.getVarFlag(key, "python"):
|
||||
parsedvar = d.expandWithRefs(d.getVar(key, False), key)
|
||||
parser = bb.codeparser.PythonParser()
|
||||
parsedvar = d.expandWithRefs(value, key)
|
||||
parser = bb.codeparser.PythonParser(key, logger)
|
||||
parser.parse_python(parsedvar.value)
|
||||
deps = deps | parser.references
|
||||
else:
|
||||
parsedvar = d.expandWithRefs(d.getVar(key, False), key)
|
||||
parser = bb.codeparser.ShellParser()
|
||||
parsedvar = d.expandWithRefs(value, key)
|
||||
parser = bb.codeparser.ShellParser(key, logger)
|
||||
parser.parse_shell(parsedvar.value)
|
||||
deps = deps | shelldeps
|
||||
if vardeps is None:
|
||||
parser.log.flush()
|
||||
deps = deps | parsedvar.references
|
||||
deps = deps | (keys & parser.execs) | (keys & parsedvar.execs)
|
||||
else:
|
||||
parser = d.expandWithRefs(d.getVar(key, False), key)
|
||||
parser = d.expandWithRefs(value, key)
|
||||
deps |= parser.references
|
||||
deps = deps | (keys & parser.execs)
|
||||
deps |= set((d.getVarFlag(key, "vardeps", True) or "").split())
|
||||
deps |= set((vardeps or "").split())
|
||||
deps -= set((d.getVarFlag(key, "vardepsexclude", True) or "").split())
|
||||
except:
|
||||
bb.note("Error expanding variable %s" % key)
|
||||
raise
|
||||
return deps
|
||||
return deps, value
|
||||
#bb.note("Variable %s references %s and calls %s" % (key, str(deps), str(execs)))
|
||||
#d.setVarFlag(key, "vardeps", deps)
|
||||
|
||||
|
@ -307,12 +314,14 @@ def generate_dependencies(d):
|
|||
|
||||
keys = set(key for key in d.keys() if not key.startswith("__"))
|
||||
shelldeps = set(key for key in keys if d.getVarFlag(key, "export") and not d.getVarFlag(key, "unexport"))
|
||||
vardepvals = set(key for key in keys if d.getVarFlag(key, "vardepvalue"))
|
||||
|
||||
deps = {}
|
||||
values = {}
|
||||
|
||||
tasklist = bb.data.getVar('__BBTASKS', d) or []
|
||||
for task in tasklist:
|
||||
deps[task] = build_dependencies(task, keys, shelldeps, d)
|
||||
deps[task], values[task] = build_dependencies(task, keys, shelldeps, vardepvals, d)
|
||||
newdeps = deps[task]
|
||||
seen = set()
|
||||
while newdeps:
|
||||
|
@ -321,11 +330,11 @@ def generate_dependencies(d):
|
|||
newdeps = set()
|
||||
for dep in nextdeps:
|
||||
if dep not in deps:
|
||||
deps[dep] = build_dependencies(dep, keys, shelldeps, d)
|
||||
deps[dep], values[dep] = build_dependencies(dep, keys, shelldeps, vardepvals, d)
|
||||
newdeps |= deps[dep]
|
||||
newdeps -= seen
|
||||
#print "For %s: %s" % (task, str(taskdeps[task]))
|
||||
return tasklist, deps
|
||||
return tasklist, deps, values
|
||||
|
||||
def inherits_class(klass, d):
|
||||
val = getVar('__inherit_cache', d) or []
|
||||
|
|
|
@ -68,8 +68,14 @@ class VariableParse:
|
|||
code = match.group()[3:-1]
|
||||
codeobj = compile(code.strip(), self.varname or "<expansion>", "eval")
|
||||
|
||||
parser = bb.codeparser.PythonParser()
|
||||
parser = bb.codeparser.PythonParser(self.varname, logger)
|
||||
parser.parse_python(code)
|
||||
if self.varname:
|
||||
vardeps = self.d.getVarFlag(self.varname, "vardeps", True)
|
||||
if vardeps is None:
|
||||
parser.log.flush()
|
||||
else:
|
||||
parser.log.flush()
|
||||
self.references |= parser.references
|
||||
self.execs |= parser.execs
|
||||
|
||||
|
|
|
@ -197,6 +197,7 @@ def uri_replace(ud, uri_find, uri_replace, d):
|
|||
uri_decoded = list(decodeurl(ud.url))
|
||||
uri_find_decoded = list(decodeurl(uri_find))
|
||||
uri_replace_decoded = list(decodeurl(uri_replace))
|
||||
logger.debug(2, "For url %s comparing %s to %s" % (uri_decoded, uri_find_decoded, uri_replace_decoded))
|
||||
result_decoded = ['', '', '', '', '', {}]
|
||||
for i in uri_find_decoded:
|
||||
loc = uri_find_decoded.index(i)
|
||||
|
@ -209,12 +210,18 @@ def uri_replace(ud, uri_find, uri_replace, d):
|
|||
result_decoded[loc] = re.sub(i, uri_replace_decoded[loc], uri_decoded[loc])
|
||||
if uri_find_decoded.index(i) == 2:
|
||||
if ud.mirrortarball:
|
||||
result_decoded[loc] = os.path.join(os.path.dirname(result_decoded[loc]), os.path.basename(ud.mirrortarball))
|
||||
if result_decoded[loc].endswith("/"):
|
||||
result_decoded[loc] = os.path.dirname(result_decoded[loc])
|
||||
result_decoded[loc] = os.path.join(result_decoded[loc], os.path.basename(ud.mirrortarball))
|
||||
elif ud.localpath:
|
||||
result_decoded[loc] = os.path.join(os.path.dirname(result_decoded[loc]), os.path.basename(ud.localpath))
|
||||
if result_decoded[loc].endswith("/"):
|
||||
result_decoded[loc] = os.path.dirname(result_decoded[loc])
|
||||
result_decoded[loc] = os.path.join(result_decoded[loc], os.path.basename(ud.localpath))
|
||||
else:
|
||||
return ud.url
|
||||
return encodeurl(result_decoded)
|
||||
result = encodeurl(result_decoded)
|
||||
logger.debug(2, "For url %s returning %s" % (ud.url, result))
|
||||
return result
|
||||
|
||||
methods = []
|
||||
urldata_cache = {}
|
||||
|
@ -385,7 +392,8 @@ def runfetchcmd(cmd, d, quiet = False, cleanup = []):
|
|||
exportvars = ['PATH', 'GIT_PROXY_COMMAND', 'GIT_PROXY_HOST',
|
||||
'GIT_PROXY_PORT', 'GIT_CONFIG', 'http_proxy', 'ftp_proxy',
|
||||
'https_proxy', 'no_proxy', 'ALL_PROXY', 'all_proxy',
|
||||
'SSH_AUTH_SOCK', 'SSH_AGENT_PID', 'HOME']
|
||||
'SSH_AUTH_SOCK', 'SSH_AGENT_PID', 'HOME',
|
||||
'GIT_PROXY_IGNORE', 'SOCKS5_USER', 'SOCKS5_PASSWD']
|
||||
|
||||
for var in exportvars:
|
||||
val = bb.data.getVar(var, d, True)
|
||||
|
|
|
@ -190,7 +190,7 @@ class Git(FetchMethod):
|
|||
logger.debug(1, "No Origin")
|
||||
|
||||
runfetchcmd("%s remote add --mirror=fetch origin %s" % (ud.basecmd, repourl), d)
|
||||
fetch_cmd = "%s fetch --prune %s refs/*:refs/*" % (ud.basecmd, repourl)
|
||||
fetch_cmd = "%s fetch -f --prune %s refs/*:refs/*" % (ud.basecmd, repourl)
|
||||
bb.fetch2.check_network_access(d, fetch_cmd, ud.url)
|
||||
runfetchcmd(fetch_cmd, d)
|
||||
runfetchcmd("%s prune-packed" % ud.basecmd, d)
|
||||
|
@ -220,7 +220,7 @@ class Git(FetchMethod):
|
|||
if os.path.exists(destdir):
|
||||
bb.utils.prunedir(destdir)
|
||||
|
||||
runfetchcmd("git clone -s -n %s %s" % (ud.clonedir, destdir), d)
|
||||
runfetchcmd("git clone -s -n %s/ %s" % (ud.clonedir, destdir), d)
|
||||
if not ud.nocheckout:
|
||||
os.chdir(destdir)
|
||||
if subdir != "":
|
||||
|
|
|
@ -50,9 +50,6 @@ class Local(FetchMethod):
|
|||
path = url.split("://")[1]
|
||||
path = path.split(";")[0]
|
||||
newpath = path
|
||||
dldirfile = os.path.join(data.getVar("DL_DIR", d, True), os.path.basename(path))
|
||||
if os.path.exists(dldirfile):
|
||||
return dldirfile
|
||||
if path[0] != "/":
|
||||
filespath = data.getVar('FILESPATH', d, True)
|
||||
if filespath:
|
||||
|
@ -62,6 +59,7 @@ class Local(FetchMethod):
|
|||
if filesdir:
|
||||
newpath = os.path.join(filesdir, path)
|
||||
if not os.path.exists(newpath) and path.find("*") == -1:
|
||||
dldirfile = os.path.join(data.getVar("DL_DIR", d, True), os.path.basename(path))
|
||||
return dldirfile
|
||||
return newpath
|
||||
|
||||
|
|
|
@ -106,8 +106,8 @@ def init_msgconfig(verbose, debug, debug_domains = []):
|
|||
"""
|
||||
Set default verbosity and debug levels config the logger
|
||||
"""
|
||||
bb.msg.loggerDebugLevel = debug
|
||||
bb.msg.loggerVerbose = verbose
|
||||
bb.msg.loggerDefaultDebugLevel = debug
|
||||
bb.msg.loggerDefaultVerbose = verbose
|
||||
bb.msg.loggerDefaultDomains = debug_domains
|
||||
|
||||
def addDefaultlogFilter(handler):
|
||||
|
|
|
@ -148,7 +148,7 @@ def handle(fn, d, include):
|
|||
|
||||
# DONE WITH PARSING... time to evaluate
|
||||
if ext != ".bbclass":
|
||||
data.setVar('FILE', fn, d)
|
||||
data.setVar('FILE', abs_fn, d)
|
||||
|
||||
statements.eval(d)
|
||||
|
||||
|
|
|
@ -102,7 +102,7 @@ def handle(fn, data, include):
|
|||
feeder(lineno, s, fn, statements)
|
||||
|
||||
# DONE WITH PARSING... time to evaluate
|
||||
bb.data.setVar('FILE', fn, data)
|
||||
bb.data.setVar('FILE', abs_fn, data)
|
||||
statements.eval(data)
|
||||
if oldfile:
|
||||
bb.data.setVar('FILE', oldfile, data)
|
||||
|
|
|
@ -47,9 +47,10 @@ if hasattr(sqlite3, 'enable_shared_cache'):
|
|||
@total_ordering
|
||||
class SQLTable(collections.MutableMapping):
|
||||
"""Object representing a table/domain in the database"""
|
||||
def __init__(self, cursor, table):
|
||||
self.cursor = cursor
|
||||
def __init__(self, cachefile, table):
|
||||
self.cachefile = cachefile
|
||||
self.table = table
|
||||
self.cursor = connect(self.cachefile)
|
||||
|
||||
self._execute("CREATE TABLE IF NOT EXISTS %s(key TEXT, value TEXT);"
|
||||
% table)
|
||||
|
@ -63,6 +64,8 @@ class SQLTable(collections.MutableMapping):
|
|||
except sqlite3.OperationalError as exc:
|
||||
if 'database is locked' in str(exc) and count < 500:
|
||||
count = count + 1
|
||||
self.cursor.close()
|
||||
self.cursor = connect(self.cachefile)
|
||||
continue
|
||||
raise
|
||||
|
||||
|
@ -188,7 +191,7 @@ class PersistData(object):
|
|||
del self.data[domain][key]
|
||||
|
||||
def connect(database):
|
||||
return sqlite3.connect(database, timeout=30, isolation_level=None)
|
||||
return sqlite3.connect(database, timeout=5, isolation_level=None)
|
||||
|
||||
def persist(domain, d):
|
||||
"""Convenience factory for SQLTable objects based upon metadata"""
|
||||
|
@ -201,5 +204,4 @@ def persist(domain, d):
|
|||
|
||||
bb.utils.mkdirhier(cachedir)
|
||||
cachefile = os.path.join(cachedir, "bb_persist_data.sqlite3")
|
||||
connection = connect(cachefile)
|
||||
return SQLTable(connection, domain)
|
||||
return SQLTable(cachefile, domain)
|
||||
|
|
|
@ -1203,8 +1203,14 @@ class RunQueueExecuteTasks(RunQueueExecute):
|
|||
if task in self.rq.scenequeue_covered:
|
||||
continue
|
||||
if len(self.rqdata.runq_revdeps[task]) > 0 and self.rqdata.runq_revdeps[task].issubset(self.rq.scenequeue_covered):
|
||||
self.rq.scenequeue_covered.add(task)
|
||||
ok = True
|
||||
for revdep in self.rqdata.runq_revdeps[task]:
|
||||
if self.rqdata.runq_fnid[task] != self.rqdata.runq_fnid[revdep]:
|
||||
ok = False
|
||||
break
|
||||
if ok:
|
||||
found = True
|
||||
self.rq.scenequeue_covered.add(task)
|
||||
|
||||
# Detect when the real task needs to be run anyway by looking to see
|
||||
# if any of its dependencies within the same package are scheduled
|
||||
|
@ -1227,9 +1233,6 @@ class RunQueueExecuteTasks(RunQueueExecute):
|
|||
|
||||
logger.debug(1, 'Full skip list %s', self.rq.scenequeue_covered)
|
||||
|
||||
for task in self.rq.scenequeue_covered:
|
||||
self.task_skip(task)
|
||||
|
||||
event.fire(bb.event.StampUpdate(self.rqdata.target_pairs, self.rqdata.dataCache.stamp), self.cfgData)
|
||||
|
||||
schedulers = self.get_schedulers()
|
||||
|
@ -1323,8 +1326,14 @@ class RunQueueExecuteTasks(RunQueueExecute):
|
|||
task = self.sched.next()
|
||||
if task is not None:
|
||||
fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
|
||||
|
||||
taskname = self.rqdata.runq_task[task]
|
||||
|
||||
if task in self.rq.scenequeue_covered:
|
||||
logger.debug(2, "Setscene covered task %s (%s)", task,
|
||||
self.rqdata.get_user_idstring(task))
|
||||
self.task_skip(task)
|
||||
return True
|
||||
|
||||
if self.rq.check_stamp_task(task, taskname):
|
||||
logger.debug(2, "Stamp current task %s (%s)", task,
|
||||
self.rqdata.get_user_idstring(task))
|
||||
|
@ -1412,18 +1421,20 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
|
|||
sq_revdeps.append(copy.copy(self.rqdata.runq_revdeps[task]))
|
||||
sq_revdeps_new.append(set())
|
||||
if (len(self.rqdata.runq_revdeps[task]) == 0) and task not in self.rqdata.runq_setscene:
|
||||
endpoints[task] = None
|
||||
endpoints[task] = set()
|
||||
|
||||
for task in self.rqdata.runq_setscene:
|
||||
for dep in self.rqdata.runq_depends[task]:
|
||||
endpoints[dep] = task
|
||||
if dep not in endpoints:
|
||||
endpoints[dep] = set()
|
||||
endpoints[dep].add(task)
|
||||
|
||||
def process_endpoints(endpoints):
|
||||
newendpoints = {}
|
||||
for point, task in endpoints.items():
|
||||
tasks = set()
|
||||
if task:
|
||||
tasks.add(task)
|
||||
tasks |= task
|
||||
if sq_revdeps_new[point]:
|
||||
tasks |= sq_revdeps_new[point]
|
||||
sq_revdeps_new[point] = set()
|
||||
|
@ -1448,6 +1459,28 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
|
|||
elif len(sq_revdeps_new[task]) != 0:
|
||||
bb.msg.fatal("RunQueue", "Something went badly wrong during scenequeue generation, aborting. Please report this problem.")
|
||||
|
||||
# Resolve setscene inter-task dependencies
|
||||
# e.g. do_sometask_setscene[depends] = "targetname:do_someothertask_setscene"
|
||||
# Note that anything explicitly depended upon will have its reverse dependencies removed to avoid circular dependencies
|
||||
for task in self.rqdata.runq_setscene:
|
||||
realid = self.rqdata.taskData.gettask_id(self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]], self.rqdata.runq_task[task] + "_setscene", False)
|
||||
idepends = self.rqdata.taskData.tasks_idepends[realid]
|
||||
for (depid, idependtask) in idepends:
|
||||
if depid not in self.rqdata.taskData.build_targets:
|
||||
continue
|
||||
|
||||
depdata = self.rqdata.taskData.build_targets[depid][0]
|
||||
if depdata is None:
|
||||
continue
|
||||
dep = self.rqdata.taskData.fn_index[depdata]
|
||||
taskid = self.rqdata.get_task_id(self.rqdata.taskData.getfn_id(dep), idependtask.replace("_setscene", ""))
|
||||
if taskid is None:
|
||||
bb.msg.fatal("RunQueue", "Task %s depends upon nonexistant task %s:%s" % (self.rqdata.taskData.tasks_name[realid], dep, idependtask))
|
||||
|
||||
sq_revdeps_squash[self.rqdata.runq_setscene.index(task)].add(self.rqdata.runq_setscene.index(taskid))
|
||||
# Have to zero this to avoid circular dependencies
|
||||
sq_revdeps_squash[self.rqdata.runq_setscene.index(taskid)] = set()
|
||||
|
||||
#for task in xrange(len(sq_revdeps_squash)):
|
||||
# print "Task %s: %s.%s is %s " % (task, self.taskData.fn_index[self.runq_fnid[self.runq_setscene[task]]], self.runq_task[self.runq_setscene[task]] + "_setscene", sq_revdeps_squash[task])
|
||||
|
||||
|
@ -1506,8 +1539,9 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
|
|||
|
||||
for task in xrange(len(self.sq_revdeps)):
|
||||
if task not in valid_new and task not in noexec:
|
||||
realtask = self.rqdata.runq_setscene[task]
|
||||
logger.debug(2, 'No package found, so skipping setscene task %s',
|
||||
self.rqdata.get_user_idstring(task))
|
||||
self.rqdata.get_user_idstring(realtask))
|
||||
self.task_failoutright(task)
|
||||
|
||||
logger.info('Executing SetScene Tasks')
|
||||
|
@ -1580,7 +1614,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
|
|||
taskname = self.rqdata.runq_task[realtask] + "_setscene"
|
||||
if self.rq.check_stamp_task(realtask, self.rqdata.runq_task[realtask]):
|
||||
logger.debug(2, 'Stamp for underlying task %s(%s) is current, so skipping setscene variant',
|
||||
task, self.rqdata.get_user_idstring(task))
|
||||
task, self.rqdata.get_user_idstring(realtask))
|
||||
self.task_failoutright(task)
|
||||
return True
|
||||
|
||||
|
@ -1622,7 +1656,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
|
|||
for task in oldcovered:
|
||||
self.rq.scenequeue_covered.add(self.rqdata.runq_setscene[task])
|
||||
|
||||
logger.debug(1, 'We can skip tasks %s', self.rq.scenequeue_covered)
|
||||
logger.debug(1, 'We can skip tasks %s', sorted(self.rq.scenequeue_covered))
|
||||
|
||||
self.rq.state = runQueueRunInit
|
||||
return True
|
||||
|
|
|
@ -72,11 +72,10 @@ class SignatureGeneratorBasic(SignatureGenerator):
|
|||
|
||||
def _build_data(self, fn, d):
|
||||
|
||||
tasklist, gendeps = bb.data.generate_dependencies(d)
|
||||
tasklist, gendeps, lookupcache = bb.data.generate_dependencies(d)
|
||||
|
||||
taskdeps = {}
|
||||
basehash = {}
|
||||
lookupcache = {}
|
||||
|
||||
for task in tasklist:
|
||||
data = d.getVar(task, False)
|
||||
|
@ -101,6 +100,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
|
|||
alldeps = seen - self.basewhitelist
|
||||
|
||||
for dep in sorted(alldeps):
|
||||
data = data + dep
|
||||
if dep in lookupcache:
|
||||
var = lookupcache[dep]
|
||||
else:
|
||||
|
@ -135,7 +135,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
|
|||
k = fn + "." + task
|
||||
data = dataCache.basetaskhash[k]
|
||||
self.runtaskdeps[k] = []
|
||||
for dep in sorted(deps):
|
||||
for dep in sorted(deps, key=clean_basepath):
|
||||
# We only manipulate the dependencies for packages not in the whitelist
|
||||
if self.twl and not self.twl.search(dataCache.pkg_fn[fn]):
|
||||
# then process the actual dependencies
|
||||
|
@ -159,7 +159,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
|
|||
k = fn + "." + task
|
||||
if runtime == "customfile":
|
||||
sigfile = stampbase
|
||||
elif runtime:
|
||||
elif runtime and k in self.taskhash:
|
||||
sigfile = stampbase + "." + task + ".sigdata" + "." + self.taskhash[k]
|
||||
else:
|
||||
sigfile = stampbase + "." + task + ".sigbasedata" + "." + self.basehash[k]
|
||||
|
@ -180,7 +180,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
|
|||
data['gendeps'][dep] = self.gendeps[fn][dep]
|
||||
data['varvals'][dep] = self.lookupcache[fn][dep]
|
||||
|
||||
if runtime:
|
||||
if runtime and k in self.taskhash:
|
||||
data['runtaskdeps'] = self.runtaskdeps[k]
|
||||
data['runtaskhashes'] = {}
|
||||
for dep in data['runtaskdeps']:
|
||||
|
@ -217,19 +217,32 @@ def dump_this_task(outfile, d):
|
|||
task = "do_" + d.getVar("BB_CURRENTTASK", True)
|
||||
bb.parse.siggen.dump_sigtask(fn, task, outfile, "customfile")
|
||||
|
||||
def clean_basepath(a):
|
||||
if a.startswith("virtual:"):
|
||||
b = a.rsplit(":", 1)[0] + a.rsplit("/", 1)[1]
|
||||
else:
|
||||
b = a.rsplit("/", 1)[1]
|
||||
return b
|
||||
|
||||
def clean_basepaths(a):
|
||||
b = {}
|
||||
for x in a:
|
||||
b[clean_basepath(x)] = a[x]
|
||||
return b
|
||||
|
||||
def compare_sigfiles(a, b):
|
||||
p1 = pickle.Unpickler(file(a, "rb"))
|
||||
a_data = p1.load()
|
||||
p2 = pickle.Unpickler(file(b, "rb"))
|
||||
b_data = p2.load()
|
||||
|
||||
def dict_diff(a, b):
|
||||
def dict_diff(a, b, whitelist=set()):
|
||||
sa = set(a.keys())
|
||||
sb = set(b.keys())
|
||||
common = sa & sb
|
||||
changed = set()
|
||||
for i in common:
|
||||
if a[i] != b[i]:
|
||||
if a[i] != b[i] and i not in whitelist:
|
||||
changed.add(i)
|
||||
added = sa - sb
|
||||
removed = sb - sa
|
||||
|
@ -237,20 +250,23 @@ def compare_sigfiles(a, b):
|
|||
|
||||
if 'basewhitelist' in a_data and a_data['basewhitelist'] != b_data['basewhitelist']:
|
||||
print "basewhitelist changed from %s to %s" % (a_data['basewhitelist'], b_data['basewhitelist'])
|
||||
print "changed items: %s" % a_data['basewhitelist'].symmetric_difference(b_data['basewhitelist'])
|
||||
|
||||
if 'taskwhitelist' in a_data and a_data['taskwhitelist'] != b_data['taskwhitelist']:
|
||||
print "taskwhitelist changed from %s to %s" % (a_data['taskwhitelist'], b_data['taskwhitelist'])
|
||||
print "changed items: %s" % a_data['taskwhitelist'].symmetric_difference(b_data['taskwhitelist'])
|
||||
|
||||
if a_data['taskdeps'] != b_data['taskdeps']:
|
||||
print "Task dependencies changed from %s to %s" % (sorted(a_data['taskdeps']), sorted(b_data['taskdeps']))
|
||||
print "Task dependencies changed from:\n%s\nto:\n%s" % (sorted(a_data['taskdeps']), sorted(b_data['taskdeps']))
|
||||
|
||||
if a_data['basehash'] != b_data['basehash']:
|
||||
print "basehash changed from %s to %s" % (a_data['basehash'], b_data['basehash'])
|
||||
|
||||
changed, added, removed = dict_diff(a_data['gendeps'], b_data['gendeps'])
|
||||
changed, added, removed = dict_diff(a_data['gendeps'], b_data['gendeps'], a_data['basewhitelist'] & b_data['basewhitelist'])
|
||||
if changed:
|
||||
for dep in changed:
|
||||
print "List of dependencies for variable %s changed from %s to %s" % (dep, a_data['gendeps'][dep], b_data['gendeps'][dep])
|
||||
print "changed items: %s" % a_data['gendeps'][dep].symmetric_difference(b_data['gendeps'][dep])
|
||||
if added:
|
||||
for dep in added:
|
||||
print "Dependency on variable %s was added" % (dep)
|
||||
|
@ -265,7 +281,9 @@ def compare_sigfiles(a, b):
|
|||
print "Variable %s value changed from %s to %s" % (dep, a_data['varvals'][dep], b_data['varvals'][dep])
|
||||
|
||||
if 'runtaskhashes' in a_data and 'runtaskhashes' in b_data:
|
||||
changed, added, removed = dict_diff(a_data['runtaskhashes'], b_data['runtaskhashes'])
|
||||
a = clean_basepaths(a_data['runtaskhashes'])
|
||||
b = clean_basepaths(b_data['runtaskhashes'])
|
||||
changed, added, removed = dict_diff(a, b)
|
||||
if added:
|
||||
for dep in added:
|
||||
print "Dependency on task %s was added" % (dep)
|
||||
|
@ -274,9 +292,10 @@ def compare_sigfiles(a, b):
|
|||
print "Dependency on task %s was removed" % (dep)
|
||||
if changed:
|
||||
for dep in changed:
|
||||
print "Hash for dependent task %s changed from %s to %s" % (dep, a_data['runtaskhashes'][dep], b_data['runtaskhashes'][dep])
|
||||
print "Hash for dependent task %s changed from %s to %s" % (dep, a[dep], b[dep])
|
||||
elif 'runtaskdeps' in a_data and 'runtaskdeps' in b_data and sorted(a_data['runtaskdeps']) != sorted(b_data['runtaskdeps']):
|
||||
print "Tasks this task depends on changed from %s to %s" % (sorted(a_data['runtaskdeps']), sorted(b_data['runtaskdeps']))
|
||||
print "changed items: %s" % a_data['runtaskdeps'].symmetric_difference(b_data['runtaskdeps'])
|
||||
|
||||
def dump_sigfile(a):
|
||||
p1 = pickle.Unpickler(file(a, "rb"))
|
||||
|
|
|
@ -88,6 +88,8 @@ class HobHandler(gobject.GObject):
|
|||
deploy_dir = self.server.runCommand(["getVariable", "DEPLOY_DIR"])
|
||||
self.image_out_dir = os.path.join(deploy_dir, "images")
|
||||
self.image_output_types = self.server.runCommand(["getVariable", "IMAGE_FSTYPES"]).split(" ")
|
||||
self.bbpath = self.server.runCommand(["getVariable", "BBPATH"])
|
||||
self.bbfiles = self.server.runCommand(["getVariable", "BBFILES"])
|
||||
|
||||
def run_next_command(self):
|
||||
if self.current_command and not self.generating:
|
||||
|
@ -263,8 +265,7 @@ class HobHandler(gobject.GObject):
|
|||
self.build_queue = targets
|
||||
|
||||
if not self.bbpath_ok:
|
||||
bbpath = self.server.runCommand(["getVariable", "BBPATH"])
|
||||
if self.image_dir in bbpath.split(":"):
|
||||
if self.image_dir in self.bbpath.split(":"):
|
||||
self.bbpath_ok = True
|
||||
else:
|
||||
nbbp = self.image_dir
|
||||
|
@ -272,8 +273,8 @@ class HobHandler(gobject.GObject):
|
|||
if not self.bbfiles_ok:
|
||||
import re
|
||||
pattern = "%s/\*.bb" % self.image_dir
|
||||
bbfiles = self.server.runCommand(["getVariable", "BBFILES"]).split(" ")
|
||||
for files in bbfiles:
|
||||
|
||||
for files in self.bbfiles.split(" "):
|
||||
if re.match(pattern, files):
|
||||
self.bbfiles_ok = True
|
||||
|
||||
|
@ -327,7 +328,7 @@ class HobHandler(gobject.GObject):
|
|||
return self.image_output_types
|
||||
|
||||
def get_image_deploy_dir(self):
|
||||
return self.img_out_dir
|
||||
return self.image_out_dir
|
||||
|
||||
def make_temp_dir(self):
|
||||
bb.utils.mkdirhier(self.image_dir)
|
||||
|
|
|
@ -39,6 +39,7 @@ class HobPrefs(gtk.Dialog):
|
|||
self.selected_image_types = handler.remove_image_output_type(ot)
|
||||
|
||||
self.configurator.setConfVar('IMAGE_FSTYPES', "%s" % " ".join(self.selected_image_types).lstrip(" "))
|
||||
self.reload_required = True
|
||||
|
||||
def sdk_machine_combo_changed_cb(self, combo, handler):
|
||||
sdk_mach = combo.get_active_text()
|
||||
|
|
|
@ -179,6 +179,10 @@ class RunningBuild (gobject.GObject):
|
|||
# that we need to attach to a task.
|
||||
self.tasks_to_iter[(package, task)] = i
|
||||
|
||||
# If we don't handle these the GUI does not proceed
|
||||
elif isinstance(event, bb.build.TaskInvalid):
|
||||
return
|
||||
|
||||
elif isinstance(event, bb.build.TaskBase):
|
||||
current = self.tasks_to_iter[(package, task)]
|
||||
parent = self.tasks_to_iter[(package, None)]
|
||||
|
|
|
@ -304,13 +304,11 @@ class MainWindow (gtk.Window):
|
|||
self.image_combo.disconnect(self.image_combo_id)
|
||||
self.image_combo_id = None
|
||||
self.model.set_selected_image(self.selected_image)
|
||||
self.selected_image = None
|
||||
if not self.image_combo_id:
|
||||
self.image_combo_id = self.image_combo.connect("changed", self.image_changed_cb)
|
||||
|
||||
if self.selected_packages:
|
||||
self.model.set_selected_packages(self.selected_packages)
|
||||
self.selected_packages = None
|
||||
|
||||
def reset_clicked_cb(self, button):
|
||||
lbl = "<b>Reset your selections?</b>\n\nAny new changes you have made will be lost"
|
||||
|
@ -398,11 +396,13 @@ class MainWindow (gtk.Window):
|
|||
gtk.RESPONSE_OK))
|
||||
response = chooser.run()
|
||||
rep = BuildRep(None, None, None)
|
||||
recipe = chooser.get_filename()
|
||||
if response == gtk.RESPONSE_OK:
|
||||
rep.loadRecipe(chooser.get_filename())
|
||||
chooser.destroy()
|
||||
rep.loadRecipe(recipe)
|
||||
self.save_path = recipe
|
||||
self.model.load_image_rep(rep)
|
||||
self.dirty = False
|
||||
chooser.destroy()
|
||||
|
||||
def bake_clicked_cb(self, button):
|
||||
build_image = True
|
||||
|
|
|
@ -443,7 +443,7 @@ def lockfile(name, shared=False, retry=True):
|
|||
return lf
|
||||
lf.close()
|
||||
except Exception:
|
||||
continue
|
||||
pass
|
||||
if not retry:
|
||||
return None
|
||||
|
||||
|
@ -505,7 +505,6 @@ def preserved_envvars_exported():
|
|||
'SHELL',
|
||||
'TERM',
|
||||
'USER',
|
||||
'USERNAME',
|
||||
]
|
||||
|
||||
def preserved_envvars_exported_interactive():
|
||||
|
|
|
@ -1,7 +1,8 @@
|
|||
# This is a single Makefile to handle all generated Yocto Project documents.
|
||||
# The Makefile needs to live in the documents directory and all figures used
|
||||
# in any manuals must be PNG files and live in the individual book's figures
|
||||
# directory.
|
||||
# in any manuals must be .PNG files and live in the individual book's figures
|
||||
# directory. Note that the figures for the Yocto Project Development Manual
|
||||
# differ between the 'master' and 'edison' branches.
|
||||
#
|
||||
# The Makefile has these targets:
|
||||
#
|
||||
|
@ -14,35 +15,47 @@
|
|||
#
|
||||
# The Makefile generates an HTML and PDF version of every document except the
|
||||
# Yocto Project Quick Start. The Quick Start is in HTML form only. The variable
|
||||
# The command-line argument DOC represents the folder name in which a particular
|
||||
# document is stored. The command-line argument VER represents the distro
|
||||
# version of the Yocto Release for which the manuals are being generated.
|
||||
# DOC is used to indicate the folder name for a given manual. The variable
|
||||
# VER represents the distro version of the Yocto Release for which the manuals
|
||||
# are being generated. The variable BRANCH is used to indicate the 'edison'
|
||||
# branch and is used only when DOC=dev-manual (making the YP Development
|
||||
# Manual).
|
||||
#
|
||||
# To build the HTML and PDF versions of the manual you must invoke the Makefile
|
||||
# with the DOC argument. If you are going to publish the manual then you
|
||||
# you must invoke the Makefile with both the DOC and the VER argument.
|
||||
# If you are building the 'edison' version of the YP DEvelopment Manual then
|
||||
# you must use the DOC and BRANCH arguments.
|
||||
#
|
||||
# Examples:
|
||||
#
|
||||
# make DOC=bsp-guide
|
||||
# make DOC=yocto-project-qs
|
||||
# make pdf DOC=poky-ref-manual
|
||||
# make DOC=dev-manual BRANCH=edison
|
||||
#
|
||||
# The first example generates the HTML and PDF versions of the BSP Guide.
|
||||
# The second example generates the HTML version only of the Quick Start. Note that
|
||||
# the Quick Start only has an HTML version available. The third example generates
|
||||
# both the PDF and HTML versions of the Yocto Project Reference Manual.
|
||||
# both the PDF and HTML versions of the Yocto Project Reference Manual. The
|
||||
# last example generates both the PDF and HTML 'edison' versions of the YP
|
||||
# Development Manual.
|
||||
#
|
||||
# Use the publish target to push the generated manuals to the Yocto Project
|
||||
# website. All files needed for the manual's HTML form are pushed as well as the
|
||||
# PDF version (if applicable).
|
||||
# Examples:
|
||||
#
|
||||
# make publish DOC=bsp-guide VER=1.1
|
||||
# make publish DOC=adt-manual VER=1.1
|
||||
# make publish DOC=bsp-guide VER=1.2
|
||||
# make publish DOC=adt-manual VER=1.2
|
||||
# make publish DOC=dev-manual VER=1.1.1 BRANCH=edison
|
||||
# make publish DOC=dev-manual VER=1.2
|
||||
#
|
||||
# The first example publishes the 1.1 version of both the PDF and HTML versions of
|
||||
# the BSP Guide. The second example publishes the 1.1 version of both the PDF and
|
||||
# HTML versions of the ADT Manual.
|
||||
# The first example publishes the 1.2 version of both the PDF and HTML versions of
|
||||
# the BSP Guide. The second example publishes the 1.2 version of both the PDF and
|
||||
# HTML versions of the ADT Manual. The third example publishes the PDF and HTML
|
||||
# 'edison' versions of the YP Development Manual. Finally, the last example publishes
|
||||
# the PDF and HTML 'master' versions of the YP Development Manual.
|
||||
#
|
||||
|
||||
ifeq ($(DOC),bsp-guide)
|
||||
|
@ -66,10 +79,32 @@ XSLTOPTS = --stringparam html.stylesheet style.css \
|
|||
--stringparam section.label.includes.component.label 1 \
|
||||
--xinclude
|
||||
ALLPREQ = html pdf tarball
|
||||
TARFILES = style.css dev-manual.html dev-manual.pdf figures/bsp-dev-flow.png figures/dev-title.png \
|
||||
#
|
||||
# Note that the tarfile might produce the "Cannot stat: No such file or directory" error
|
||||
# message for .PNG files that are not present when building a particular branch. The
|
||||
# list of files is all-inclusive for all branches.
|
||||
#
|
||||
|
||||
ifeq ($(BRANCH),edison)
|
||||
TARFILES = style.css dev-manual.html dev-manual.pdf \
|
||||
figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
|
||||
figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
|
||||
figures/kernel-example-repos.png figures/kernel-overview-1.png figures/kernel-overview-2.png \
|
||||
figures/kernel-overview-3.png figures/source-repos.png figures/yp-download.png
|
||||
figures/kernel-example-repos-edison.png \
|
||||
figures/kernel-overview-1.png figures/kernel-overview-2.png \
|
||||
figures/kernel-overview-3-edison.png \
|
||||
figures/source-repos.png figures/yp-download.png \
|
||||
figures/wip.png
|
||||
else
|
||||
TARFILES = style.css dev-manual.html dev-manual.pdf \
|
||||
figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
|
||||
figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
|
||||
figures/kernel-example-repos.png \
|
||||
figures/kernel-overview-1.png figures/kernel-overview-2.png \
|
||||
figures/kernel-overview-3.png \
|
||||
figures/source-repos.png figures/yp-download.png \
|
||||
figures/wip.png
|
||||
endif
|
||||
|
||||
MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
|
||||
FIGURES = figures
|
||||
STYLESHEET = $(DOC)/*.css
|
||||
|
|
|
@ -12,9 +12,9 @@
|
|||
Toolchain Tarball)</link>".
|
||||
And, that sourcing your architecture-specific environment setup script
|
||||
initializes a suitable cross-toolchain development environment.
|
||||
This setup occurs by adding the compiler, QEMU scripts, QEMU binary,
|
||||
During the setup, locations for the compiler, QEMU scripts, QEMU binary,
|
||||
a special version of <filename>pkgconfig</filename> and other useful
|
||||
utilities to the <filename>PATH</filename> variable.
|
||||
utilities are added to the <filename>PATH</filename> variable.
|
||||
Variables to assist <filename>pkgconfig</filename> and <filename>autotools</filename>
|
||||
are also defined so that,
|
||||
for example, <filename>configure.sh</filename> can find pre-generated
|
||||
|
@ -28,7 +28,7 @@
|
|||
<title>Autotools-Based Projects</title>
|
||||
|
||||
<para>
|
||||
For an autotools-based project, you can use the cross-toolchain by just
|
||||
For an Autotools-based project, you can use the cross-toolchain by just
|
||||
passing the appropriate host option to <filename>configure.sh</filename>.
|
||||
The host option you use is derived from the name of the environment setup
|
||||
script in <filename>/opt/poky</filename> resulting from unpacking the
|
||||
|
@ -47,6 +47,20 @@
|
|||
This single command updates your project and rebuilds it using the appropriate
|
||||
cross-toolchain tools.
|
||||
</para>
|
||||
<note>
|
||||
If <filename>configure</filename> script results in problems recognizing the
|
||||
<filename>--with-libtool-sysroot=<sysroot-dir></filename> option,
|
||||
regenerate the script to enable the support by doing the following and then
|
||||
re-running the script:
|
||||
<literallayout class='monospaced'>
|
||||
$ libtoolize --automake
|
||||
$ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
|
||||
[-I <dir_containing_your_project-specific_m4_macros>]
|
||||
$ autoconf
|
||||
$ autoheader
|
||||
$ automake -a
|
||||
</literallayout>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section id='makefile-based-projects'>
|
||||
|
|
|
@ -29,8 +29,7 @@
|
|||
<para>
|
||||
To develop within the Eclipse IDE, you need to do the following:
|
||||
<orderedlist>
|
||||
<listitem><para>Be sure the optimal version of the Eclipse IDE
|
||||
is installed.</para></listitem>
|
||||
<listitem><para>Install the optimal version of the Eclipse IDE.</para></listitem>
|
||||
<listitem><para>Configure the Eclipse IDE.</para></listitem>
|
||||
<listitem><para>Install the Eclipse Yocto Plug-in.</para></listitem>
|
||||
<listitem><para>Configure the Eclipse Yocto Plug-in.</para></listitem>
|
||||
|
@ -54,10 +53,12 @@
|
|||
<para>
|
||||
Once you have downloaded the tarball, extract it into a clean
|
||||
directory.
|
||||
For example, the following command unpacks and installs the Eclipse IDE
|
||||
into a clean directory named <filename>eclipse</filename>:
|
||||
For example, the following commands unpack and install the Eclipse IDE
|
||||
tarball found in the <filename>Downloads</filename> area
|
||||
into a clean directory using the default name <filename>eclipse</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ tar -xzvf ~/Downloads/Eclipse-SDK-3.7-linux-gtk-x86_64.tar.gz
|
||||
$ cd ~
|
||||
$ tar -xzvf ~/Downloads/eclipse-SDK-3.7.1-linux-gtk-x86_64.tar.gz
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
@ -96,16 +97,18 @@
|
|||
Follow these general steps to configure Eclipse:
|
||||
<orderedlist>
|
||||
<listitem><para>Start the Eclipse IDE.</para></listitem>
|
||||
<listitem><para>Select "Install New Software" from the "Help" pull-down menu.
|
||||
<listitem><para>Make sure you are in your Workbench and select
|
||||
"Install New Software" from the "Help" pull-down menu.
|
||||
</para></listitem>
|
||||
<listitem><para>Select <filename>Indego - http://download.eclipse.org/releases/indego</filename>
|
||||
<listitem><para>Select <filename>indigo - http://download.eclipse.org/releases/indigo</filename>
|
||||
from the "Work with:" pull-down menu.</para></listitem>
|
||||
<listitem><para>Expand the box next to <filename>Programming Languages</filename>
|
||||
and select the <filename>Autotools Support for CDT (incubation)</filename>
|
||||
and <filename>C/C++ Development Tools</filename> boxes.</para></listitem>
|
||||
<listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
|
||||
<listitem><para>Select "Install New Software" from the "Help" pull-down menu.</para></listitem>
|
||||
<listitem><para>After the Eclipse IDE restarts, click the
|
||||
<listitem><para>After the Eclipse IDE restarts and from the Workbench, select
|
||||
"Install New Software" from the "Help" pull-down menu.</para></listitem>
|
||||
<listitem><para>Click the
|
||||
"Available Software Sites" link.</para></listitem>
|
||||
<listitem><para>Check the box next to
|
||||
<filename>http://download.eclipse.org/tm/updates/3.3</filename>
|
||||
|
@ -118,12 +121,13 @@
|
|||
and select every item except <filename>RSE Unit Tests</filename> and
|
||||
<filename>RSE WinCE Services (incubation)</filename>.</para></listitem>
|
||||
<listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
|
||||
<listitem><para>After the Eclipse IDE restarts, click the
|
||||
"Available Software Sites" link.</para></listitem>
|
||||
<listitem><para>Check the box next to
|
||||
<filename>http://download.eclipse.org/tools/cdt/releases/indego</filename>
|
||||
<listitem><para>If necessary, select
|
||||
"Install New Software" from the "Help" pull-down menu so you can click the
|
||||
"Available Software Sites" link again.</para></listitem>
|
||||
<listitem><para>After clicking "Available Software Sites", check the box next to
|
||||
<filename>http://download.eclipse.org/tools/cdt/releases/indigo</filename>
|
||||
and click "OK".</para></listitem>
|
||||
<listitem><para>Select <filename>http://download.eclipse.org/tools/cdt/releases/indego</filename>
|
||||
<listitem><para>Select <filename>http://download.eclipse.org/tools/cdt/releases/indigo</filename>
|
||||
from the "Work with:" pull-down menu.</para></listitem>
|
||||
<listitem><para>Check the box next to <filename>CDT Main Features</filename>.
|
||||
</para></listitem>
|
||||
|
@ -136,40 +140,135 @@
|
|||
</section>
|
||||
|
||||
<section id='installing-the-eclipse-yocto-plug-in'>
|
||||
<title>Installing the Eclipse Yocto Plug-in</title>
|
||||
<title>Installing or Accessing the Eclipse Yocto Plug-in</title>
|
||||
|
||||
<para>
|
||||
To install the Eclipse Yocto Plug-in, follow these special steps.
|
||||
The steps are WIP and are not final.
|
||||
Once they are final they will be replaced with the actual steps:
|
||||
You can install the Eclipse Yocto Plug-in into the Eclipse application
|
||||
one of two ways: using the Eclipse IDE and installing the plug-in as new software, or
|
||||
using a built zip file.
|
||||
If you don't want to permanently install the plug-in but just want to try it out
|
||||
within the Eclipse environment, you can import the plug-in project from the
|
||||
Yocto Project source repositories.
|
||||
</para>
|
||||
|
||||
<section id='new-software'>
|
||||
<title>Installing the Plug-in as New Software</title>
|
||||
|
||||
<para>
|
||||
To install the Eclipse Yocto Plug-in as new software directly into the Eclipse IDE,
|
||||
follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Start up the Eclipse IDE.</para></listitem>
|
||||
<listitem><para>In Eclipse, select "Install New Software" from the "Help" menu.</para></listitem>
|
||||
<listitem><para>Click "Add..." in the "Work with:" area.</para></listitem>
|
||||
<listitem><para>Enter
|
||||
<filename>http://downloads.yoctoproject.org/releases/eclipse-plugin/1.1.1</filename>
|
||||
in the URL field and provide a meaningful name in the "Name" field.</para></listitem>
|
||||
<listitem><para>Click "OK" to have the entry added to the "Work with:"
|
||||
drop-down list.</para></listitem>
|
||||
<listitem><para>Select the entry for the plug-in from the "Work with:" drop-down
|
||||
list.</para></listitem>
|
||||
<listitem><para>Check the box next to <filename>Development tools and SDKs for Yocto Linux</filename>.
|
||||
</para></listitem>
|
||||
<listitem><para>Complete the remaining software installation steps and
|
||||
then restart the Eclipse IDE to finish the installation of the plug-in.
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='zip-file-method'>
|
||||
<title>Installing the Plug-in from a Zip File</title>
|
||||
<para>
|
||||
To install the Eclipse Yocto Plug-in by building and installing a plug-in
|
||||
zip file, follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Open a shell and create a Git repository with:
|
||||
<literallayout class='monospaced'>
|
||||
$ git clone git://git.yoctoproject.org/yocto-eclipse yocto-eclipse
|
||||
$ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse
|
||||
</literallayout>
|
||||
For this example, the repository is named
|
||||
<filename>~/yocto-eclipse</filename>.</para></listitem>
|
||||
<listitem><para>Locate the <filename>build.sh</filename> script in the
|
||||
Git repository you created in the previous step.
|
||||
The script is located in the <filename>scripts</filename>.</para></listitem>
|
||||
<listitem><para>Be sure to set and export the <filename>ECLIPSE_HOME</filename> environment
|
||||
variable to the top-level directory in which you installed the Indigo
|
||||
version of Eclipse.
|
||||
For example, if your Eclipse directory is <filename>$HOME/eclipse</filename>,
|
||||
use the following:
|
||||
<literallayout class='monospaced'>
|
||||
$ export ECLIPSE_HOME=$HOME/eclipse
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para>In Eclipse, select "Import" from the "File" menu.</para></listitem>
|
||||
<listitem><para>Expand the "General" box and pick "existing projects into workspace".
|
||||
<listitem><para>Run the <filename>build.sh</filename> script and provide the
|
||||
name of the Git branch along with the Yocto Project release you are
|
||||
using.
|
||||
Here is an example that uses the <filename>master</filename> Git repository
|
||||
and the <filename>1.1.1</filename> release:
|
||||
<literallayout class='monospaced'>
|
||||
$ scripts/build.sh master 1.1.1
|
||||
</literallayout>
|
||||
After running the script, the file
|
||||
<filename>org.yocto.sdk-<release>-<date>-archive.zip</filename>
|
||||
is in the current directory.</para></listitem>
|
||||
<listitem><para>If necessary, start the Eclipse IDE and be sure you are in the
|
||||
Workbench.</para></listitem>
|
||||
<listitem><para>Select "Install New Software" from the "Help" pull-down menu.
|
||||
</para></listitem>
|
||||
<listitem><para>Click "Add".</para></listitem>
|
||||
<listitem><para>Provide anything you want in the "Name" field.</para></listitem>
|
||||
<listitem><para>Click "Archive" and browse to the ZIP file you built
|
||||
in step four.
|
||||
This ZIP file should not be "unzipped", and must be the
|
||||
<filename>*archive.zip</filename> file created by running the
|
||||
<filename>build.sh</filename> script.</para></listitem>
|
||||
<listitem><para>Check the box next to the new entry in the installation window and complete
|
||||
the installation.</para></listitem>
|
||||
<listitem><para>Restart the Eclipse IDE if necessary.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
At this point you should be able to configure the Eclipse Yocto Plug-in as described in the
|
||||
"<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>"
|
||||
section.</para>
|
||||
</section>
|
||||
|
||||
<section id='yocto-project-source'>
|
||||
<title>Importing the Plug-in Project into the Eclipse Environment</title>
|
||||
<para>
|
||||
Importing the Eclipse Yocto Plug-in project from the Yocto Project source repositories
|
||||
is useful when you want to try out the latest plug-in from the tip of plug-in's
|
||||
development tree.
|
||||
It is important to understand when you import the plug-in you are not installing
|
||||
it into the Eclipse application.
|
||||
Rather, you are importing the project and just using it.
|
||||
To import the plug-in project, follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Open a shell and create a Git repository with:
|
||||
<literallayout class='monospaced'>
|
||||
$ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse
|
||||
</literallayout>
|
||||
For this example, the repository is named
|
||||
<filename>~/yocto-eclipse</filename>.</para></listitem>
|
||||
<listitem><para>In Eclipse, select "Import" from the "File" menu.</para></listitem>
|
||||
<listitem><para>Expand the "General" box and select "existing projects into workspace"
|
||||
and then click "Next".</para></listitem>
|
||||
<listitem><para>Select the root directory and browse to "~/yocto-eclipse/plugins".
|
||||
</para></listitem>
|
||||
<listitem><para>There will be three things there.
|
||||
Select each one and install one at a time.
|
||||
Do all three.</para></listitem>
|
||||
<listitem><para>Restart everything.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
At this point I should be able to invoke Eclipse from the shell using the following:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/eclipse
|
||||
$ ./eclipse -vmargs -XX:PermSize=256M
|
||||
</literallayout>
|
||||
What is shown is the default projects in the left pane.
|
||||
I should be able to right-click on one of these and run as an Eclipse application to
|
||||
bring up the Eclipse instance again with the Eclipse Yocto Plug-in working.
|
||||
The left navigation pane in the Eclipse application shows the default projects.
|
||||
Right-click on one of these projects and run it as an Eclipse application.
|
||||
This brings up a second instance of Eclipse IDE that has the Yocto Plug-in.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='configuring-the-eclipse-yocto-plug-in'>
|
||||
<title>Configuring the Eclipse Yocto Plug-in</title>
|
||||
|
@ -186,7 +285,7 @@
|
|||
To start, you need to do the following from within the Eclipse IDE:
|
||||
<itemizedlist>
|
||||
<listitem><para>Choose <filename>Windows -> Preferences</filename> to display
|
||||
the Preferences Dialog</para></listitem>
|
||||
the <filename>Preferences</filename> Dialog</para></listitem>
|
||||
<listitem><para>Click <filename>Yocto ADT</filename></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
@ -223,12 +322,12 @@
|
|||
</para></listitem>
|
||||
<listitem><para><emphasis>Point to the Toolchain:</emphasis>
|
||||
If you are using a stand-alone pre-built toolchain, you should be pointing to the
|
||||
<filename>/opt/poky/$SDKVERSION</filename> directory.
|
||||
<filename>/opt/poky/1.1.1</filename> directory.
|
||||
This is the location for toolchains installed by the ADT Installer or by hand.
|
||||
Sections <link linkend='configuring-and-running-the-adt-installer-script'>
|
||||
Configuring and Running the ADT Installer Script</link> and
|
||||
<link linkend='using-an-existing-toolchain-tarball'>
|
||||
Using a Cross-Toolchain Tarball</link> describe two ways to install
|
||||
Sections "<link linkend='configuring-and-running-the-adt-installer-script'>Configuring
|
||||
and Running the ADT Installer Script</link>" and
|
||||
"<link linkend='using-an-existing-toolchain-tarball'>Using a Cross-Toolchain
|
||||
Tarball</link>" describe two ways to install
|
||||
a stand-alone cross-toolchain in the
|
||||
<filename>/opt/poky</filename> directory.
|
||||
<note>It is possible to install a stand-alone cross-toolchain in a directory
|
||||
|
@ -237,8 +336,8 @@
|
|||
<para>If you are using a system-derived toolchain, the path you provide
|
||||
for the <filename>Toolchain Root Location</filename>
|
||||
field is the Yocto Project's build directory.
|
||||
See section <link linkend='using-the-toolchain-from-within-the-build-tree'>
|
||||
Using BitBake and the Yocto Project Build Tree</link> for
|
||||
See section "<link linkend='using-the-toolchain-from-within-the-build-tree'>Using
|
||||
BitBake and the Yocto Project Build Tree</link>" for
|
||||
information on how to install the toolchain into the Yocto
|
||||
Project build tree.</para></listitem>
|
||||
<listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
|
||||
|
@ -255,10 +354,8 @@
|
|||
The pull-down menu should have the supported architectures.
|
||||
If the architecture you need is not listed in the menu, you
|
||||
will need to build the image.
|
||||
See the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'> Building an Image</ulink> section of the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
The Yocto Project Quick Start</ulink> for more information.</para></listitem>
|
||||
See the "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section
|
||||
of The Yocto Project Quick Start for more information.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -350,28 +447,33 @@
|
|||
<title>Configuring the Cross-Toolchains</title>
|
||||
|
||||
<para>
|
||||
The previous section, "<link linkend='configuring-the-eclipse-yocto-plug-in'>
|
||||
Configuring the Eclipse Yocto Plug-in</link>", set up the default project
|
||||
The earlier section, "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring
|
||||
the Eclipse Yocto Plug-in</link>", sets up the default project
|
||||
configurations.
|
||||
You can change these settings for a given project by following these steps:
|
||||
You can override these settings for a given project by following these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Select <filename>Window -> Preferences</filename>:
|
||||
This selection brings up the <filename>Preferences</filename> Dialog.
|
||||
If the Yocto ADT Preferences are not automatically displayed, you can navigate to
|
||||
that dialog by selection <filename>Yocto ADT</filename> in the left-hand
|
||||
panel.</para>
|
||||
<para>Yocto ADT Settings are inherited from the default project configuration.
|
||||
The information in this dialog is identical to that chosen earlier
|
||||
for the Cross Compiler Options and Target Options as described in
|
||||
<link linkend='configuring-the-eclipse-yocto-plug-in'>
|
||||
Configuring the Eclipse Yocto Plug-in</link> section.</para></listitem>
|
||||
<listitem><para>Select <filename>Project -> Change Yocto Project Settings</filename>:
|
||||
This selection brings up the <filename>Project Yocto Settings</filename> Dialog
|
||||
and allows you to make changes specific to an individual project.
|
||||
</para>
|
||||
<para>By default, the Cross Compiler Options and Target Options for a project
|
||||
are inherited from settings you provide using the <filename>Preferences</filename>
|
||||
Dialog as described earlier
|
||||
in the "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse
|
||||
Yocto Plug-in</link>" section.
|
||||
The <filename>Project Yocto Settings</filename>
|
||||
Dialog allows you to override those default settings
|
||||
for a given project.</para></listitem>
|
||||
<listitem><para>Make your configurations for the project and click "OK".</para></listitem>
|
||||
<listitem><para>Select <filename>Project -> Reconfigure Project</filename>:
|
||||
This selection reconfigures the project by running
|
||||
<filename>autogen.sh</filename> in the workspace for your project.
|
||||
The script also runs <filename>libtoolize</filename>, <filename>aclocal</filename>,
|
||||
<filename>autoconf</filename>, <filename>autoheader</filename>,
|
||||
<filename>automake --a</filename>, and
|
||||
<filename>./configure</filename>.</para></listitem>
|
||||
<filename>./configure</filename>.
|
||||
Click on the <filename>Console</filename> tab beneath your source code to
|
||||
see the results of reconfiguring your project.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -391,20 +493,20 @@
|
|||
<para>
|
||||
To start the QEMU emulator from within Eclipse, follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Expose the <filename>Run -> External Tools -> External Tools
|
||||
Configurations...</filename> menu.
|
||||
<listitem><para>Expose the <filename>Run -> External Tools</filename> menu.
|
||||
Your image should appear as a selectable menu item.
|
||||
</para></listitem>
|
||||
<listitem><para>Select your image from the menu.
|
||||
Doing so launches a new window.</para></listitem>
|
||||
<listitem><para>Enter your host root password in the shell window at the prompt.
|
||||
<listitem><para>Select your image from the menu to launch the
|
||||
emulator in a new window.</para></listitem>
|
||||
<listitem><para>If needed, enter your host root password in the shell window at the prompt.
|
||||
This sets up a <filename>Tap 0</filename> connection needed for running in user-space
|
||||
NFS mode.</para></listitem>
|
||||
<listitem><para>Wait for QEMU to launch.</para></listitem>
|
||||
<listitem><para>Once QEMU launches you need to determine the IP Address
|
||||
for the user-space NFS.
|
||||
You can do that by going to a terminal in the QEMU and entering the
|
||||
<filename>ifconfig</filename> command.</para></listitem>
|
||||
<listitem><para>Once QEMU launches, you can begin operating within that
|
||||
environment.
|
||||
For example, you could determine the IP Address
|
||||
for the user-space NFS by using the <filename>ifconfig</filename> command.
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -413,8 +515,8 @@
|
|||
<title>Deploying and Debugging the Application</title>
|
||||
|
||||
<para>
|
||||
Once the QEMU emulator is running the image, you can deploy your application and use the emulator
|
||||
to perform debugging.
|
||||
Once the QEMU emulator is running the image, using the Eclipse IDE
|
||||
you can deploy your application and use the emulator to perform debugging.
|
||||
Follow these steps to deploy the application.
|
||||
<orderedlist>
|
||||
<listitem><para>Select <filename>Run -> Debug Configurations...</filename></para></listitem>
|
||||
|
@ -435,8 +537,8 @@
|
|||
<listitem><para>Click <filename>Next</filename>.</para></listitem>
|
||||
<listitem><para>Clear out the <filename>host name</filename> field and enter the IP Address
|
||||
determined earlier.</para></listitem>
|
||||
<listitem><para>Click <filename>Finish</filename> to close the new connections
|
||||
Dialog.</para></listitem>
|
||||
<listitem><para>Click <filename>Finish</filename> to close the
|
||||
<filename>New Connections</filename> Dialog.</para></listitem>
|
||||
<listitem><para>Use the drop-down menu now in the <filename>Connection</filename> field and pick
|
||||
the IP Address you entered.</para></listitem>
|
||||
<listitem><para>Click <filename>Debug</filename> to bring up a login screen
|
||||
|
@ -454,7 +556,7 @@
|
|||
your development experience.
|
||||
These tools are aids in developing and debugging applications and images.
|
||||
You can run these user-space tools from within the Eclipse IDE through the
|
||||
<filename>Window -> YoctoTools</filename> menu.
|
||||
<filename>YoctoTools</filename> menu.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
|
@ -114,7 +114,7 @@
|
|||
<listitem><para><emphasis>Perf:</emphasis> Performance counters for Linux used
|
||||
to keep track of certain types of hardware and software events.
|
||||
For more information on these types of counters see
|
||||
<ulink url='https://perf.wiki.kernel.org/index.php'></ulink> and click
|
||||
<ulink url='https://perf.wiki.kernel.org/'></ulink> and click
|
||||
on “Perf tools.”</para></listitem>
|
||||
<listitem><para><emphasis>SystemTap:</emphasis> A free software infrastructure
|
||||
that simplifies information gathering about a running Linux system.
|
||||
|
|
|
@ -31,17 +31,27 @@
|
|||
<revision>
|
||||
<revnumber>1.0</revnumber>
|
||||
<date>6 April 2011</date>
|
||||
<revremark>Initial Document released with Yocto Project 1.0 on 6 April 2011.</revremark>
|
||||
<revremark>Released with the Yocto Project 1.0 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.0.1</revnumber>
|
||||
<date>23 May 2011</date>
|
||||
<revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
|
||||
<revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1</revnumber>
|
||||
<date>6 October 2011</date>
|
||||
<revremark>Released with the Yocto Project 1.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1.1</revnumber>
|
||||
<date>15 March 2012</date>
|
||||
<revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<copyright>
|
||||
<year>2010-2011</year>
|
||||
<year>2010-2012</year>
|
||||
<holder>Linux Foundation</holder>
|
||||
</copyright>
|
||||
|
||||
|
@ -53,7 +63,7 @@
|
|||
<note>
|
||||
Due to production processes, there could be differences between the Yocto Project
|
||||
documentation bundled in the release tarball and the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
|
||||
Application Developer's Toolkit (ADT) User's Guide</ulink> on
|
||||
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
|
||||
For the latest version of this manual, see the manual on the website.
|
||||
|
|
|
@ -54,9 +54,7 @@
|
|||
|
||||
<note>
|
||||
For build performance information related to the PMS, see
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>
|
||||
in <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
The Yocto Project Reference Manual</ulink>.
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> in The Yocto Project Reference Manual.
|
||||
</note>
|
||||
|
||||
<para>
|
||||
|
|
|
@ -9,60 +9,9 @@
|
|||
In order to use the ADT, you must install it, <filename>source</filename> a script to set up the
|
||||
environment, and be sure both the kernel and filesystem image specific to the target architecture
|
||||
exist.
|
||||
This chapter describes how to be sure you meet the ADT requirements.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This chapter describes two important terms and how to be sure you meet the ADT requirements.
|
||||
</para>
|
||||
|
||||
<section id='yocto-project-files'>
|
||||
<title>Yocto Project Files and Build Areas</title>
|
||||
|
||||
<para>
|
||||
Before learning how to prepare your system for the ADT, you need to understand
|
||||
two important terms used throughout this manual:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>The Yocto Project Files:</emphasis>
|
||||
This term refers to the directory structure created as a result of downloading
|
||||
and unpacking a Yocto Project release tarball or setting up a Git repository
|
||||
by cloning <filename>git://git.yoctoproject.org/poky</filename>.</para>
|
||||
<para>The Yocto Project files contain BitBake, Documentation, metadata and
|
||||
other files that all support the development environment.
|
||||
Consequently, you must have the Yocto Project files in place on your development
|
||||
system in order to do any development using the Yocto Project.</para>
|
||||
<para>The name of the top-level directory of the Yocto Project file structure
|
||||
is derived from the Yocto Project release tarball.
|
||||
For example, downloading and unpacking <filename>poky-edison-6.0.tar.bz2</filename>
|
||||
results in a Yocto Project source tree whose Yocto Project source directory is named
|
||||
<filename>poky-edison-6.0</filename>.
|
||||
If you create a Git repository, then you can name the repository anything you like.</para>
|
||||
<para>You can find instruction on how to set up the Yocto Project files on your
|
||||
host development system by reading the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-setup'>
|
||||
Getting Setup</ulink> section in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
|
||||
The Yocto Project Development Manual</ulink>.</para></listitem>
|
||||
<listitem><para><emphasis>Yocto Project Build Tree:</emphasis>
|
||||
This term refers to the area where the Yocto Project builds images.
|
||||
The area is created when you <filename>source</filename> the Yocto Project setup
|
||||
environment script that is found in the Yocto Project files area.
|
||||
(e.g. <filename>oe-init-build-env</filename>).
|
||||
You can create the Yocto Project build tree anywhere you want on your
|
||||
development system.
|
||||
Here is an example that creates the tree in <filename>mybuilds</filename>
|
||||
and names the Yocto Project build directory <filename>YP-6.0</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ source poky-edison-6.0/oe-init-build-env $HOME/mybuilds/YP-6.0
|
||||
</literallayout>
|
||||
If you don't specifically name the build directory, then BitBake creates it
|
||||
in the current directory and uses the name <filename>build</filename>.
|
||||
Also, if you supply an existing directory, then BitBake uses that
|
||||
directory as the Yocto Project build directory and populates the build tree
|
||||
beneath it.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='installing-the-adt'>
|
||||
<title>Installing the ADT</title>
|
||||
|
||||
|
@ -70,7 +19,8 @@
|
|||
The following list describes how you can install the ADT, which includes the cross-toolchain.
|
||||
Regardless of the installation you choose, you must <filename>source</filename> the cross-toolchain
|
||||
environment setup script before you use the toolchain.
|
||||
See the "<link linkend='setting-up-the-environment'>Setting Up the Environment</link>"
|
||||
See the "<link linkend='setting-up-the-cross-development-environment'>Setting Up the
|
||||
Cross-Development Environment</link>"
|
||||
section for more information.
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Use the ADT Installer Script:</emphasis>
|
||||
|
@ -85,8 +35,8 @@
|
|||
If you use this method, you just get the cross-toolchain and QEMU - you do not
|
||||
get any of the other mentioned benefits had you run the ADT Installer script.</para></listitem>
|
||||
<listitem><para><emphasis>Use the Toolchain from within a Yocto Project Build Tree:</emphasis>
|
||||
If you already have a Yocto Project build tree, you can install the cross-toolchain
|
||||
using that tree.
|
||||
If you already have a Yocto Project build tree, you can build the cross-toolchain
|
||||
within tree.
|
||||
However, like the previous method mentioned, you only get the cross-toolchain and QEMU - you
|
||||
do not get any of the other benefits without taking separate steps.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
@ -105,15 +55,18 @@
|
|||
|
||||
<para>
|
||||
The ADT Installer is contained in the ADT Installer tarball.
|
||||
You can download the tarball into any directory from
|
||||
<ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.1/adt-installer/'></ulink>.
|
||||
You can download the tarball into any directory from the
|
||||
<ulink url='http://downloads.yoctoproject.org/releases'>Index of Releases</ulink>, specifically
|
||||
at
|
||||
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/adt_installer'></ulink>.
|
||||
Or, you can use BitBake to generate the tarball inside the existing Yocto Project
|
||||
build tree.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you use BitBake to generate the ADT Installer tarball, you must
|
||||
<filename>source</filename> the Yocto Project environment setup script located
|
||||
<filename>source</filename> the Yocto Project environment setup script
|
||||
(<filename>oe-init-build-env</filename>) located
|
||||
in the Yocto Project file structure before running the <filename>bitbake</filename>
|
||||
command that creates the tarball.
|
||||
</para>
|
||||
|
@ -128,9 +81,9 @@
|
|||
$ cd ~
|
||||
$ mkdir yocto-project
|
||||
$ cd yocto-project
|
||||
$ wget http://www.yoctoproject.org/downloads/poky/poky-edison-6.0.tar.bz2
|
||||
$ tar xjf poky-edison-6.0.tar.bz2
|
||||
$ source poky-edison-6.0/oe-init-build-env
|
||||
$ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/poky-edison-6.0.1.tar.bz2
|
||||
$ tar xjf poky-edison-6.0.1.tar.bz2
|
||||
$ source poky-edison-6.0.1/oe-init-build-env
|
||||
$ bitbake adt-installer
|
||||
</literallayout>
|
||||
</para>
|
||||
|
@ -142,6 +95,14 @@
|
|||
<para>
|
||||
Before running the ADT Installer script, you need to unpack the tarball.
|
||||
You can unpack the tarball in any directory you wish.
|
||||
For example, this command copies the ADT Installer tarball from where
|
||||
it was built into the home directory and then unpacks the tarball into
|
||||
a top-level directory named <filename>adt-installer</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~
|
||||
$ cp ~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
|
||||
$ tar -xjf adt_installer.tar.bz2
|
||||
</literallayout>
|
||||
Unpacking it creates the directory <filename>adt-installer</filename>,
|
||||
which contains the ADT Installer script (<filename>adt_installer</filename>)
|
||||
and its configuration file (<filename>adt_installer.conf</filename>).
|
||||
|
@ -204,18 +165,19 @@
|
|||
|
||||
<para>
|
||||
After you have configured the <filename>adt_installer.conf</filename> file,
|
||||
run the installer using the following command:
|
||||
run the installer for this example using the following commands:
|
||||
<literallayout class='monospaced'>
|
||||
$ adt_installer
|
||||
$ cd ~/adt-installer
|
||||
$ ./adt_installer
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<note>
|
||||
The ADT Installer requires the <filename>libtool</filename> package to complete.
|
||||
If you install the recommended packages as described in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>
|
||||
Packages</ulink> section of
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>Packages</ulink>"
|
||||
section of
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
The Yocto Project Quick Start</ulink>, then you will have libtool installed.
|
||||
</note>
|
||||
|
||||
|
@ -230,7 +192,7 @@
|
|||
<para>
|
||||
Once the installation completes, the ADT, which includes the cross-toolchain, is installed.
|
||||
You will notice environment setup files for the cross-toolchain in
|
||||
<filename>/opt/poky/$SDKVERSION</filename>,
|
||||
<filename>/opt/poky/1.1.1</filename>,
|
||||
and image tarballs in the <filename>adt-installer</filename>
|
||||
directory according to your installer configurations, and the target sysroot located
|
||||
according to the <filename>YOCTOADT_TARGET_SYSROOT_LOC_<arch></filename> variable
|
||||
|
@ -245,64 +207,76 @@
|
|||
<para>
|
||||
If you want to simply install the cross-toolchain by hand, you can do so by using an existing
|
||||
cross-toolchain tarball.
|
||||
If you install the cross-toolchain by hand, you will have to set up the target sysroot separately.
|
||||
If you use this method to install the cross-toolchain and you still need to install the target
|
||||
sysroot, you will have to install sysroot separately.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Go to
|
||||
<ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.1/toolchain'></ulink>
|
||||
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/toolchain'></ulink>
|
||||
and find the folder that matches your host development system
|
||||
(i.e. <filename>i686</filename> for 32-bit machines or
|
||||
<filename>x86_64</filename> for 64-bit machines).</para></listitem>
|
||||
<listitem><para>Go into that folder and download the toolchain tarball whose name
|
||||
includes the appropriate target architecture.
|
||||
For example, if your host development system is an Intel-based 64-bit system and
|
||||
you are going to use your cross-toolchain for an ARM-based target, go into the
|
||||
you are going to use your cross-toolchain for an Intel-based 32-bit target, go into the
|
||||
<filename>x86_64</filename> folder and download the following tarball:
|
||||
<literallayout class='monospaced'>
|
||||
yocto-eglibc-x86_64-arm-toolchain-gmae-1.1.tar.bz2
|
||||
poky-eglibc-x86_64-i586-toolchain-1.1.1.tar.bz2
|
||||
</literallayout>
|
||||
<note>As an alternative to steps one and two, you can build the toolchain tarball
|
||||
<note><para>As an alternative to steps one and two, you can build the toolchain tarball
|
||||
if you have a Yocto Project build tree.
|
||||
Use the <filename>bitbake meta-toolchain</filename> command after you have
|
||||
sourced the <filename>oe-build-init script</filename> located in the Yocto
|
||||
If you need GMAE, you should use the <filename>bitbake meta-toolchain-gmae</filename>
|
||||
command.
|
||||
The resulting tarball will support such development.
|
||||
However, if you are not concerned with GMAE,
|
||||
you can generate the tarball using <filename>bitbake meta-toolchain</filename>.</para>
|
||||
<para>Use the appropriate <filename>bitbake</filename> command only after you have
|
||||
sourced the <filename>oe-build-init-env</filename> script located in the Yocto
|
||||
Project files.
|
||||
When the <filename>bitbake</filename> command completes, the toolchain tarball will
|
||||
When the <filename>bitbake</filename> command completes, the tarball will
|
||||
be in <filename>tmp/deploy/sdk</filename> in the Yocto Project build tree.
|
||||
</note></para></listitem>
|
||||
</para></note></para></listitem>
|
||||
<listitem><para>Make sure you are in the root directory with root privileges and then expand
|
||||
the tarball.
|
||||
The tarball expands into <filename>/opt/poky/$SDKVERSION</filename>.
|
||||
Once the tarball in unpacked, the cross-toolchain is installed.
|
||||
The tarball expands into <filename>/opt/poky/1.1.1</filename>.
|
||||
Once the tarball is expanded, the cross-toolchain is installed.
|
||||
You will notice environment setup files for the cross-toolchain in the directory.
|
||||
Here is an example where the tarball exists in the user's <filename>Downloads</filename>
|
||||
directory:
|
||||
<literallayout class='monospaced'>
|
||||
# cd /
|
||||
# tar -xjf /home/scottrif/Downloads/poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
After installing the toolchain, you must locate the target sysroot tarball and unpack it
|
||||
into a location of your choice.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='using-the-toolchain-from-within-the-build-tree'>
|
||||
<title>Using BitBake and the Yocto Project Build Tree</title>
|
||||
|
||||
<para>
|
||||
A final way of installing just the cross-toolchain is to use BitBake within an existing
|
||||
Yocto Project build tree.
|
||||
Follow these steps:
|
||||
A final way of installing just the cross-toolchain is to use BitBake to build the
|
||||
toolchain within an existing Yocto Project build tree.
|
||||
This method does not install the toolchain into the <filename>/opt</filename> directory.
|
||||
As with the previous method, if you need to install the target sysroot, you must
|
||||
do this separately.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Follow these steps to build and install the toolchain into the build tree:
|
||||
<orderedlist>
|
||||
<listitem><para>Source the environment setup script located in the Yocto Project
|
||||
files.
|
||||
The script has the string <filename>init-build-env</filename>
|
||||
as part of the name.</para></listitem>
|
||||
<listitem><para>Source the environment setup script
|
||||
<filename>oe-init-build-env</filename> located in the Yocto Project
|
||||
files.</para></listitem>
|
||||
<listitem><para>At this point, you should be sure that the
|
||||
<filename>MACHINE</filename> variable
|
||||
in the <filename>local.conf</filename> file found in the Yocto Project
|
||||
file structure's <filename>conf</filename> directory
|
||||
in the <filename>local.conf</filename> file found in the
|
||||
<filename>conf</filename> directory of the Yocto Project build directory
|
||||
is set for the target architecture.
|
||||
Comments within the <filename>local.conf</filename> file list the values you
|
||||
can use for the <filename>MACHINE</filename> variable.
|
||||
|
@ -313,83 +287,168 @@
|
|||
command.</note></para></listitem>
|
||||
<listitem><para>Run <filename>bitbake meta-ide-support</filename> to complete the
|
||||
cross-toolchain installation.
|
||||
<note>If you change your working directory after you
|
||||
<note>If you change out of your working directory after you
|
||||
<filename>source</filename> the environment setup script and before you run
|
||||
the BitBake command, the command will not work.
|
||||
the <filename>bitbake</filename> command, the command might not work.
|
||||
Be sure to run the <filename>bitbake</filename> command immediately
|
||||
after checking or editing the <filename>local.conf</filename> but without
|
||||
changing your working directory.</note>
|
||||
Once BitBake finishes, the cross-toolchain is installed.
|
||||
changing out of your working directory.</note>
|
||||
Once the <filename>bitbake</filename> command finishes,
|
||||
the tarball for the cross-toolchain is generated within the Yocto Project build tree.
|
||||
You will notice environment setup files for the cross-toolchain in the
|
||||
Yocto Project build tree in the <filename>tmp</filename> directory.
|
||||
Setup script filenames contain the strings <filename>environment-setup</filename>.
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
After installing the toolchain, you must locate the target sysroot tarball and unpack
|
||||
it in a directory of your choice.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='setting-up-the-environment'>
|
||||
<title>Setting Up the Environment</title>
|
||||
<section id='setting-up-the-cross-development-environment'>
|
||||
<title>Setting Up the Cross-Development Environment</title>
|
||||
|
||||
<para>
|
||||
Before you can use the cross-toolchain, you need to set up the toolchain environment by
|
||||
sourcing the environment setup script.
|
||||
Before you can develop using the cross-toolchain, you need to set up the
|
||||
cross-development environment by sourcing the toolchain's environment setup script.
|
||||
If you used the ADT Installer or used an existing ADT tarball to install the ADT,
|
||||
then you can find this script in the <filename>/opt/poky/$SDKVERSION</filename>
|
||||
then you can find this script in the <filename>/opt/poky/1.1.1</filename>
|
||||
directory.
|
||||
If you used BitBake and the Yocto Project Build Tree to install the cross-toolchain,
|
||||
then you can find the environment setup scripts in in the Yocto Project build tree
|
||||
in the <filename>tmp</filename> directory.
|
||||
If you installed the toolchain in the build tree, you can find the environment setup
|
||||
script for the toolchain in the Yocto Project build tree's <filename>tmp</filename> directory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Be sure to run the environment setup script that matches the architecture for
|
||||
Be sure to source the environment setup script that matches the architecture for
|
||||
which you are developing.
|
||||
Environment setup scripts begin with the string “<filename>environment-setup</filename>”
|
||||
and include as part of their name the architecture.
|
||||
For example, the environment setup script for a 64-bit IA-based architecture would
|
||||
be the following:
|
||||
For example, the command to source the toolchain environment setup script
|
||||
for a 64-bit IA-based machine would be the following:
|
||||
<literallayout class='monospaced'>
|
||||
/opt/poky/1.1/environment-setup-x86_64-poky-linux
|
||||
$ source /opt/poky/1.1.1/environment-setup-x86_64-poky-linux
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='kernels-and-filesystem-images'>
|
||||
<title>Kernels and Filesystem Images</title>
|
||||
<section id='securing-kernel-and-filesystem-images'>
|
||||
<title>Securing Kernel and Filesystem Images</title>
|
||||
|
||||
<para>
|
||||
You will need to have a kernel and filesystem image to boot using your
|
||||
hardware or the QEMU emulator.
|
||||
That means you either have to build them or know where to get them.
|
||||
You can find a quick example of how to build an image in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
|
||||
Building an Image</ulink> section of
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
The Yocto Project Quick Start</ulink>.
|
||||
<note><para>
|
||||
The Yocto Project provides basic kernels and filesystem images for several
|
||||
Furthermore, if you plan on booting your image using NFS or you want to use the root filesystem
|
||||
as the target sysroot, you need to extract the root filesystem.
|
||||
</para>
|
||||
|
||||
<section id='getting-the-images'>
|
||||
<title>Getting the Images</title>
|
||||
|
||||
<para>
|
||||
To get the kernel and filesystem images, you either have to build them or download
|
||||
pre-built versions.
|
||||
You can find examples for both these situations in the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#test-run'>A
|
||||
Quick Test Run</ulink>" section of The Yocto Project Quick Start.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Yocto Project provides basic kernel and filesystem images for several
|
||||
architectures (<filename>x86</filename>, <filename>x86-64</filename>,
|
||||
<filename>mips</filename>, <filename>powerpc</filename>, and <filename>arm</filename>)
|
||||
that you can use unaltered in the QEMU emulator.
|
||||
These kernels and filesystem images reside in the Yocto Project release
|
||||
area - <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.1/machines/'></ulink>
|
||||
and are ideal for experimentation within Yocto Project.</para>
|
||||
<para>If you plan on remotely deploying and debugging your application from within the
|
||||
Eclipse IDE, you must have an image that supports Sato.
|
||||
For information on the image types you can build using the Yocto Project, see
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
|
||||
Reference: Images</ulink> in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
The Yocto Project Reference Manual</ulink>.</para>
|
||||
</note>
|
||||
These kernel images reside in the Yocto Project release
|
||||
area - <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'></ulink>
|
||||
and are ideal for experimentation within Yocto Project.
|
||||
For information on the image types you can build using the Yocto Project, see the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" appendix in The Yocto Project Reference Manual.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you plan on remotely deploying and debugging your application from within the
|
||||
Eclipse IDE, you must have an image that contains the Yocto Target Communication
|
||||
Framework (TCF) agent (<filename>tcf-agent</filename>).
|
||||
By default, the Yocto Project provides only one type pre-built image that contains the
|
||||
<filename>tcf-agent</filename>.
|
||||
And, those images are SDK (e.g.<filename>core-image-sato-sdk</filename>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you want to use a different image type that contains the <filename>tcf-agent</filename>,
|
||||
you can do so one of two ways:
|
||||
<itemizedlist>
|
||||
<listitem><para>Modify the <filename>conf/local.conf</filename> configuration file in
|
||||
the Yocto Project build directory and then rebuild the image.
|
||||
With this method, you need to modify the <filename>EXTRA_IMAGE_FEATURES</filename>
|
||||
variable to have the value of "tools-debug" before rebuilding the image.
|
||||
Once the image is rebuilt, the <filename>tcf-agent</filename> will be included
|
||||
in the image and is launched automatically after the boot.</para></listitem>
|
||||
<listitem><para>Manually build the <filename>tcf-agent</filename>.
|
||||
To build the agent, follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Be sure the ADT is installed as described in the
|
||||
"<link linkend='installing-the-adt'>Installing the ADT</link>" section.
|
||||
</para></listitem>
|
||||
<listitem><para>Set up the cross-development environment as described in the
|
||||
"<link linkend='setting-up-the-cross-development-environment'>Setting
|
||||
Up the Cross-Development Environment</link>" section.</para></listitem>
|
||||
<listitem><para>Get the <filename>tcf-agent</filename> source code, which is
|
||||
stored using the Subversion SCM, using the following command:
|
||||
<literallayout class='monospaced'>
|
||||
$ svn checkout svn://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent \
|
||||
<-r #rev_number>
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para>Modify the <filename>Makefile.inc</filename> file
|
||||
for the cross-compilation environment by setting the
|
||||
<filename>OPSYS</filename> and <filename>MACHINE</filename>
|
||||
variables according to your target.</para></listitem>
|
||||
<listitem><para>Use the cross-development tools to build the
|
||||
<filename>tcf-agent</filename>.
|
||||
Before you "Make" the file, be sure your cross-tools are set up first.
|
||||
See the "<link linkend='makefile-based-projects'>Makefile-Based Projects</link>"
|
||||
section for information on how to make sure the cross-tools are set up
|
||||
correctly.</para>
|
||||
<para>If the build is successful, the <filename>tcf-agent</filename> output will
|
||||
be <filename>obj/$(OPSYS)/$(MACHINE)/Debug/agent</filename>.</para></listitem>
|
||||
<listitem><para>Deploy the agent into the image's root filesystem.</para></listitem>
|
||||
</orderedlist>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='extracting-the-root-filesystem'>
|
||||
<title>Extracting the Root Filesystem</title>
|
||||
|
||||
<para>
|
||||
You must extract the root filesystem if you want to boot the image using NFS
|
||||
or you want to use the root filesystem as the target sysroot.
|
||||
For example, the Eclipse IDE environment with the Eclipse Yocto Plug-in installed allows you
|
||||
to use QEMU to boot under NFS.
|
||||
Another example is if you want to develop your target application using the
|
||||
root filesystem as the target sysroot.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To extract the root filesystem, first <filename>source</filename>
|
||||
the cross-development environment setup script and then
|
||||
use the <filename>runqemu-extract-sdk</filename> command on the
|
||||
filesystem image tarball.
|
||||
For example, the following commands set up the environment by sourcing
|
||||
the setup script from within the build directory and then extracting
|
||||
the root filesystem from a previously built filesystem image tarball named
|
||||
<filename>core-image-sato-sdk-qemux86.tar.bz2</filename>.
|
||||
The example extracts the root filesystem into the <filename>$HOME/qemux86-sato</filename>
|
||||
directory:
|
||||
<literallayout class='monospaced'>
|
||||
$ source $HOME/poky/build/tmp/environment-setup-i586-poky-linux
|
||||
$ runqemu-extract-sdk \
|
||||
tmp/deploy/images/core-image-sato-sdk-qemux86.tar.bz2 \
|
||||
$HOME/qemux86-sato
|
||||
</literallayout>
|
||||
In this case, you could now point to the target sysroot at
|
||||
<filename>$HOME/qemux86-sato</filename>.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
|
|
|
@ -19,10 +19,17 @@
|
|||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Richard</firstname> <surname>Purdie</surname>
|
||||
<firstname>Tom</firstname> <surname>Zanussi</surname>
|
||||
<affiliation>
|
||||
<orgname>Intel Corporation</orgname>
|
||||
</affiliation>
|
||||
<email>tom.zanussi@intel.com</email>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Richard</firstname> <surname>Purdie</surname>
|
||||
<affiliation>
|
||||
<orgname>Linux Foundation</orgname>
|
||||
</affiliation>
|
||||
<email>richard.purdie@linuxfoundation.org</email>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
@ -30,24 +37,33 @@
|
|||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>0.9</revnumber>
|
||||
<date>27 October 2010</date>
|
||||
<revremark>This manual revision is the initial manual and corresponds to the
|
||||
Yocto Project 0.9 Release.</revremark>
|
||||
<date>24 November 2010</date>
|
||||
<revremark>The initial document draft released with the Yocto Project 0.9 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.0</revnumber>
|
||||
<date>6 April 2011</date>
|
||||
<revremark>This manual revision corresponds to the Yocto Project 1.0 Release.</revremark>
|
||||
<revremark>Released with the Yocto Project 1.0 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.0.1</revnumber>
|
||||
<date>23 May 2011</date>
|
||||
<revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
|
||||
<revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1</revnumber>
|
||||
<date>6 October 2011</date>
|
||||
<revremark>Released with the Yocto Project 1.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1.1</revnumber>
|
||||
<date>15 March 2012</date>
|
||||
<revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<copyright>
|
||||
<year>2010-2011</year>
|
||||
<year>2010-2012</year>
|
||||
<holder>Linux Foundation</holder>
|
||||
</copyright>
|
||||
|
||||
|
@ -59,7 +75,7 @@
|
|||
<note>
|
||||
Due to production processes, there could be differences between the Yocto Project
|
||||
documentation bundled in the release tarball and the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
|
||||
Board Support Package (BSP) Developer's Guide</ulink> on
|
||||
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
|
||||
For the latest version of this manual, see the manual on the website.
|
||||
|
|
|
@ -30,9 +30,9 @@
|
|||
<note>
|
||||
The information here does not provide an example of how to create a BSP.
|
||||
For examples on how to create a BSP, see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
|
||||
BSP Development Example</ulink> in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
|
||||
The Yocto Project Development Manual</ulink>.
|
||||
You can also see the
|
||||
<ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
|
||||
|
@ -100,10 +100,9 @@
|
|||
"
|
||||
</literallayout>
|
||||
For more detailed information on layers, see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html#usingpoky-changes-layers'>
|
||||
BitBake Layers</ulink> section of the Yocto Project Reference Manual.
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-changes-layers'>BitBake Layers</ulink>" section of the Yocto Project Reference Manual.
|
||||
You can also see the detailed examples in the appendices of
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
|
||||
The Yocto Project Development Manual</ulink>.
|
||||
</para>
|
||||
|
||||
|
@ -145,12 +144,12 @@
|
|||
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig
|
||||
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/
|
||||
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/machconfig
|
||||
meta-crownbay/recipes-core
|
||||
meta-crownbay/recipes-core/tasks
|
||||
meta-crownbay/recipes-core/tasks/task-core-tools.bbappend
|
||||
meta-crownbay/recipes-graphics/
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.6.bb
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin-1.6/
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin-1.6/.gitignore
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
|
||||
|
@ -371,6 +370,24 @@
|
|||
</para></note>
|
||||
</section>
|
||||
|
||||
<section id='bsp-filelayout-core-recipes'>
|
||||
<title>Core Recipe Files</title>
|
||||
<para>
|
||||
You can find these files in the Yocto Project file's directory structure at:
|
||||
<literallayout class='monospaced'>
|
||||
meta-<bsp_name>/recipes-core/*
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This directory contains recipe files for the core.
|
||||
For example, in the Crown Bay BSP there is the
|
||||
<filename>task-core-tools.bbappend</filename> file, which is an append file used
|
||||
to recommend that the SystemTap package be included as a package when the image
|
||||
is built.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='bsp-filelayout-recipes-graphics'>
|
||||
<title>Display Support Files</title>
|
||||
<para>
|
||||
|
@ -387,7 +404,6 @@
|
|||
For example, the Crown Bay BSP contains the following files that support
|
||||
building a BSP that supports and does not support the Intel EMGD:
|
||||
<literallayout class='monospaced'>
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.6.bb
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
|
||||
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/xorg.conf
|
||||
|
@ -445,11 +461,11 @@
|
|||
KMACHINE_crownbay-noemgd = "yocto/standard/crownbay"
|
||||
KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"
|
||||
|
||||
SRCREV_machine_pn-linux-yocto_crownbay ?= "6b4b9acde5fb0ff66ae58fa98274bfe631501499"
|
||||
SRCREV_meta_pn-linux-yocto_crownbay ?= "5b535279e61197cb194bb2dfceb8b7a04128387c"
|
||||
SRCREV_machine_pn-linux-yocto_crownbay ?= "2247da9131ea7e46ed4766a69bb1353dba22f873"
|
||||
SRCREV_meta_pn-linux-yocto_crownbay ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
|
||||
|
||||
SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "6b4b9acde5fb0ff66ae58fa98274bfe631501499"
|
||||
SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "5b535279e61197cb194bb2dfceb8b7a04128387c"
|
||||
SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "2247da9131ea7e46ed4766a69bb1353dba22f873"
|
||||
SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
|
||||
</literallayout>
|
||||
This append file contains statements used to support the Crown Bay BSP for both
|
||||
Intel EMGD and non-EMGD.
|
||||
|
@ -464,8 +480,8 @@
|
|||
KMACHINE_crownbay = "yocto/standard/crownbay"
|
||||
KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"
|
||||
|
||||
SRCREV_machine_pn-linux-yocto_crownbay ?= "6b4b9acde5fb0ff66ae58fa98274bfe631501499"
|
||||
SRCREV_meta_pn-linux-yocto_crownbay ?= "5b535279e61197cb194bb2dfceb8b7a04128387c"
|
||||
SRCREV_machine_pn-linux-yocto_crownbay ?= "2247da9131ea7e46ed4766a69bb1353dba22f873"
|
||||
SRCREV_meta_pn-linux-yocto_crownbay ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
|
||||
</literallayout>
|
||||
The append file defines <filename>crownbay</filename> as the compatible machine,
|
||||
defines the <filename>KMACHINE</filename>, points to some configuration fragments
|
||||
|
@ -522,7 +538,7 @@
|
|||
The configuration options will likely end up in that location anyway if the BSP gets
|
||||
added to the Yocto Project.
|
||||
For information on how to add these configurations directly, see
|
||||
<ulink url='http://yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
|
||||
<ulink url='http://yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
|
||||
The Yocto Project Kernel Architecture and Use Manual</ulink>.</para>
|
||||
<para>
|
||||
In general, however, the Yocto Project maintainers take care of moving the
|
||||
|
|
|
@ -10,8 +10,11 @@
|
|||
The example assumes the following:
|
||||
<itemizedlist>
|
||||
<listitem><para>No previous preparation or use of the Yocto Project.</para></listitem>
|
||||
<listitem><para>Use of the Crown Bay Board Support Package (BSP) as a base BSP from
|
||||
which to work from.</para></listitem>
|
||||
<listitem><para>Use of the Crown Bay Board Support Package (BSP) as a "base" BSP from
|
||||
which to work.
|
||||
The example begins with the Crown Bay BSP as the starting point
|
||||
but ends by building a new 'atom-pc' BSP, which was based on the Crown Bay BSP.
|
||||
</para></listitem>
|
||||
<listitem><para>Shell commands assume <filename>bash</filename></para></listitem>
|
||||
<listitem><para>Example was developed on an Intel-based Core i7 platform running
|
||||
Ubuntu 10.04 LTS released in April of 2010.</para></listitem>
|
||||
|
@ -25,10 +28,29 @@
|
|||
You need to have the Yocto Project files available on your host system.
|
||||
You can get files through tarball extraction or by cloning the <filename>poky</filename>
|
||||
Git repository.
|
||||
See the bulleted item
|
||||
<link linkend='local-yp-release'>Yocto Project Release</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
|
||||
for information on how to get these files.
|
||||
The following paragraphs describe both methods.
|
||||
For additional information, see the bulleted item
|
||||
"<link linkend='local-yp-release'>Yocto Project Release</link>".
|
||||
</para>
|
||||
|
||||
<para>
|
||||
As mentioned, one way to get the Yocto Project files is to use Git to clone the
|
||||
<filename>poky</filename> repository:
|
||||
<literallayout class='monospaced'>
|
||||
$ git clone git://git.yoctoproject.org/poky
|
||||
$ cd poky
|
||||
</literallayout>
|
||||
Alternatively, you can start with the downloaded Poky "edison" tarball:
|
||||
<literallayout class='monospaced'>
|
||||
$ tar xfj poky-edison-6.0.1.tar.bz2
|
||||
$ cd poky
|
||||
</literallayout>
|
||||
<note>If you're using the tarball method, you can ignore all the following steps that
|
||||
ask you to carry out Git operations.
|
||||
You already have the results of those operations
|
||||
in the form of the edison release tarballs.
|
||||
Consequently, there is nothing left to do other than extract those tarballs into the
|
||||
proper locations.</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -40,14 +62,13 @@
|
|||
$ git branch -a
|
||||
$ git tag -l
|
||||
</literallayout>
|
||||
For this example we are going to use the Yocto Project 1.1 Release,
|
||||
which maps to the <filename>1.1</filename> branch in the repository.
|
||||
These commands create a local branch named <filename>1.1</filename>
|
||||
For this example we are going to use the Yocto Project 1.1.1 Release, which is code
|
||||
named "edison".
|
||||
These commands create a local branch named <filename>edison</filename>
|
||||
that tracks the remote branch of the same name.
|
||||
<literallayout class='monospaced'>
|
||||
$ cd poky
|
||||
$ git checkout -b 1.1 origin/1.1
|
||||
Switched to a new branch '1.1'
|
||||
$ git checkout -b edison origin/edison
|
||||
Switched to a new branch 'edison'
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -56,15 +77,20 @@
|
|||
<title>Choosing a Base BSP</title>
|
||||
|
||||
<para>
|
||||
For this example, the base BSP is the Intel Atom Processor E660 with Intel Platform
|
||||
For this example, the base BSP is the <trademark class='registered'>Intel</trademark>
|
||||
<trademark class='trade'>Atom</trademark> Processor E660 with Intel Platform
|
||||
Controller Hub EG20T Development Kit, which is otherwise referred to as "Crown Bay."
|
||||
The BSP layer is <filename>meta-crownbay</filename>.
|
||||
The base BSP is simply the BSP
|
||||
we will be using as a starting point, so don't worry if you don't actually have Crown Bay
|
||||
hardware.
|
||||
The remainder of the example transforms the base BSP into a BSP that should be
|
||||
able to boot on generic atom-pc (netbook) hardware.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For information on how to choose a base BSP, see
|
||||
<xref linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</xref>
|
||||
earlier in this manual.
|
||||
"<link linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</link>".
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -73,30 +99,55 @@
|
|||
|
||||
<para>
|
||||
You need to have the base BSP layer on your development system.
|
||||
Like the local Yocto Project files, you can get the BSP
|
||||
layer one of two ways:
|
||||
Similar to the local Yocto Project files, you can get the BSP
|
||||
layer a couple of different ways:
|
||||
download the BSP tarball and extract it, or set up a local Git repository that
|
||||
has the Yocto Project BSP layers.
|
||||
You should use the same method that you used to get the local Yocto Project files earlier.
|
||||
See <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
|
||||
for information on how to get the BSP files.
|
||||
See "<link linkend='getting-setup'>Getting Setup</link>" for information on how to get
|
||||
the BSP files.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This example assumes a local <filename>meta-intel</filename> Git repository
|
||||
inside the local <filename>poky</filename> Git repository.
|
||||
The <filename>meta-intel</filename> Git repository contains all the metadata
|
||||
This example assumes the BSP layer will be located within a directory named
|
||||
<filename>meta-intel</filename> contained within the <filename>poky</filename>
|
||||
parent directory.
|
||||
The following steps will automatically create the
|
||||
<filename>meta-intel</filename> directory and the contained meta-crownbay
|
||||
starting point in both the Git and the tarball cases.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you're using the Git method, you could do the following to create
|
||||
the starting layout after you have made sure you are in the <filename>poky</filename>
|
||||
directory created in the previous steps:
|
||||
<literallayout class='monospaced'>
|
||||
$ git clone git://git.yoctoproject.org/meta-intel.git
|
||||
$ cd meta-intel
|
||||
</literallayout>
|
||||
Alternatively, you can start with the downloaded <filename>meta-intel</filename>
|
||||
edison tarball.
|
||||
Again, be sure that you are already in the <filename>poky</filename> directory
|
||||
as described previously:
|
||||
<literallayout class='monospaced'>
|
||||
$ tar xfj crownbay-noemgd-edison-6.0.1.tar.bz2
|
||||
$ cd meta-intel
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>meta-intel</filename> directory contains all the metadata
|
||||
that supports BSP creation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you're using the Git method, the following
|
||||
step will switch to the edison metadata.
|
||||
If you're using the tarball method, you already have the correct metadata and can
|
||||
skip to the next step.
|
||||
Because <filename>meta-intel</filename> is its own Git repository, you will want
|
||||
to be sure you are in the appropriate branch for your work.
|
||||
For this example we are going to use the <filename>1.1</filename> branch.
|
||||
For this example we are going to use the <filename>edison</filename> branch.
|
||||
<literallayout class='monospaced'>
|
||||
$ cd meta-intel
|
||||
$ git checkout -b 1.1 origin/1.1
|
||||
Switched to a new branch 'bernard'
|
||||
$ git checkout -b edison origin/edison
|
||||
Switched to a new branch 'edison'
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -105,23 +156,20 @@
|
|||
<title>Making a Copy of the Base BSP to Create Your New BSP Layer</title>
|
||||
|
||||
<para>
|
||||
Now that you have the local Yocto Project files and the base BSP files you need to create a
|
||||
Now that you have the local Yocto Project files and the base BSP files, you need to create a
|
||||
new layer for your BSP.
|
||||
To create your BSP layer you simply copy the <filename>meta-crownbay</filename>
|
||||
To create your BSP layer, you simply copy the <filename>meta-crownbay</filename>
|
||||
layer to a new layer.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For this example the new layer will be named <filename>meta-mymachine</filename>.
|
||||
The name must follow the BSP layer naming convention, which is
|
||||
For this example, the new layer will be named <filename>meta-mymachine</filename>.
|
||||
The name should follow the BSP layer naming convention, which is
|
||||
<filename>meta-<name></filename>.
|
||||
The following example assumes your working directory is <filename>meta-intel</filename>
|
||||
The following assumes your working directory is <filename>meta-intel</filename>
|
||||
inside the local Yocto Project files.
|
||||
If you downloaded and expanded a Crown Bay tarball then you simply copy the resulting
|
||||
<filename>meta-crownbay</filename> directory structure to a location of your choice.
|
||||
Good practice for a Git repository, however, is to just copy the new layer alongside
|
||||
the existing
|
||||
BSP layers in the <filename>meta-intel</filename> Git repository:
|
||||
To start your new layer, just copy the new layer alongside the existing
|
||||
BSP layers in the <filename>meta-intel</filename> directory:
|
||||
<literallayout class='monospaced'>
|
||||
$ cp -a meta-crownbay/ meta-mymachine
|
||||
</literallayout>
|
||||
|
@ -148,7 +196,7 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
First, since in this example the new BSP will not support EMGD we will get rid of the
|
||||
First, since in this example the new BSP will not support EMGD, we will get rid of the
|
||||
<filename>crownbay.conf</filename> file and then rename the
|
||||
<filename>crownbay-noemgd.conf</filename> file to <filename>mymachine.conf</filename>.
|
||||
Much of what we do in the configuration directory is designed to help the Yocto Project
|
||||
|
@ -163,25 +211,32 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
The next step makes changes to <filename>mymachine.conf</filename> itself.
|
||||
The only changes needed for this example are changes to the comment lines.
|
||||
Here we simply substitute the Crown Bay name with an appropriate name.
|
||||
Next, we need to make changes to the <filename>mymachine.conf</filename> itself.
|
||||
The only changes we want to make for this example are to the comment lines.
|
||||
Changing comments, of course, is never strictly necessary, but it's alway good form to make
|
||||
them reflect reality as much as possible.
|
||||
|
||||
Here, simply substitute the Crown Bay name with an appropriate name for the BSP
|
||||
(<filename>mymachine</filename> in this case) and change the description to
|
||||
something that describes your hardware.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note that inside the <filename>mymachine.conf</filename> is the
|
||||
<filename>PREFERRED_PROVIDER_virtual/kernel</filename> statement.
|
||||
This statement identifies the kernel that the BSP is going to use.
|
||||
In this case the BSP is using <filename>linux-yocto</filename>, which is the
|
||||
In this case, the BSP is using <filename>linux-yocto</filename>, which is the
|
||||
current Linux Yocto kernel based on the Linux 3.0 release.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The next configuration file in the new BSP layer we need to edit is <filename>layer.conf</filename>.
|
||||
The next configuration file in the new BSP layer we need to edit is
|
||||
<filename>meta-mymachine/conf/layer.conf</filename>.
|
||||
This file identifies build information needed for the new layer.
|
||||
You can see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>
|
||||
Layer Configuration File</ulink> section in the Board Support Packages (BSP) Development Guide
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>Layer Configuration File</ulink>" section in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>The Board
|
||||
Support Packages (BSP) Development Guide</ulink>
|
||||
for more information on this configuration file.
|
||||
Basically, we are changing the existing statements to work with our BSP.
|
||||
</para>
|
||||
|
@ -212,10 +267,10 @@
|
|||
<para>
|
||||
Now we will take a look at the recipes in your new layer.
|
||||
The standard BSP structure has areas for BSP, graphics, core, and kernel recipes.
|
||||
When you create a BSP you use these areas for appropriate recipes and append files.
|
||||
When you create a BSP, you use these areas for appropriate recipes and append files.
|
||||
Recipes take the form of <filename>.bb</filename> files.
|
||||
If you want to leverage the existing recipes the Yocto Project build system uses
|
||||
but change those recipes you can use <filename>.bbappend</filename> files.
|
||||
but change those recipes, you can use <filename>.bbappend</filename> files.
|
||||
All new recipes and append files for your layer must go in the layer’s
|
||||
<filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>,
|
||||
<filename>recipes-core</filename>, and
|
||||
|
@ -232,7 +287,7 @@
|
|||
the remaining one that doesn't support EMGD.
|
||||
These commands take care of the <filename>recipes-bsp</filename> recipes:
|
||||
<literallayout class='monospaced'>
|
||||
$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/*emgd*
|
||||
$ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay
|
||||
$ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ \
|
||||
meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
|
||||
</literallayout>
|
||||
|
@ -248,7 +303,6 @@
|
|||
be sure to rename remaining directories appropriately.
|
||||
The following commands clean up the <filename>recipes-graphics</filename> directory:
|
||||
<literallayout class='monospaced'>
|
||||
$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-emgd*
|
||||
$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
|
||||
$ mv meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd \
|
||||
meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/mymachine
|
||||
|
@ -304,13 +358,17 @@
|
|||
The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename>
|
||||
statements point to the exact commits used by the Yocto Project development team
|
||||
in their source repositories that identify the right kernel for our hardware.
|
||||
In other words, the <filename>SRCREV</filename> values are simply Git commit
|
||||
IDs that identify which commit on each
|
||||
of the kernel branches (machine and meta) will be checked out and used to build
|
||||
the kernel.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
However, in the <filename>meta-mymachine</filename> layer in
|
||||
<filename>recipes-kernel/linux</filename> resides a <filename>.bbappend</filename>
|
||||
file named <filename>linux-yocto_3.0.bbappend</filename> that
|
||||
is appended to the recipe of the same name in <filename>meta/recipes-kernel/link</filename>.
|
||||
is appended to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>.
|
||||
Thus, the <filename>SRCREV</filename> statements in the "append" file override
|
||||
the more general statements found in <filename>meta</filename>.
|
||||
</para>
|
||||
|
@ -321,14 +379,14 @@
|
|||
Here are the statements:
|
||||
<literallayout class='monospaced'>
|
||||
SRCREV_machine_pn-linux-yocto_crownbay ?= \
|
||||
"372c0ab135978bd8ca3a77c88816a25c5ed8f303"
|
||||
"2247da9131ea7e46ed4766a69bb1353dba22f873"
|
||||
SRCREV_meta_pn-linux-yocto_crownbay ?= \
|
||||
"d5d3c6480d61f83503ccef7fbcd765f7aca8b71b"
|
||||
"d05450e4aef02c1b7137398ab3a9f8f96da74f52"
|
||||
|
||||
SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \
|
||||
"372c0ab135978bd8ca3a77c88816a25c5ed8f303"
|
||||
"2247da9131ea7e46ed4766a69bb1353dba22f873"
|
||||
SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \
|
||||
"d5d3c6480d61f83503ccef7fbcd765f7aca8b71b"
|
||||
"d05450e4aef02c1b7137398ab3a9f8f96da74f52"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
@ -343,30 +401,54 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>
|
||||
To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>,
|
||||
we delete the two <filename>SRCREV</filename> statements that support
|
||||
EMGD (the top pair).
|
||||
We also change the remaining pair to specify <filename>mymachine</filename>
|
||||
and insert the commit identifiers to identify the kernel in which we
|
||||
are interested, which will be based on the <filename>atom-pc-standard</filename>
|
||||
kernel.
|
||||
In this case, because we're working with the edison branch of everything, we
|
||||
need to use the <filename>SRCREV</filename> values for the atom-pc branch
|
||||
that are associated with the edison release.
|
||||
To find those values, we need to find the <filename>SRCREV</filename>
|
||||
values that edison uses for the atom-pc branch, which we find in the
|
||||
<filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
|
||||
file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The machine <filename>SRCREV</filename> we want is in the
|
||||
<filename>SRCREV_machine_atom-pc</filename> variable.
|
||||
The meta <filename>SRCREV</filename> isn't specified in this file, so it must be
|
||||
specified in the base kernel recipe in the
|
||||
<filename>poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb</filename>
|
||||
file, in the <filename>SRCREV_meta variable</filename> found there.
|
||||
It happens to be the same as the value we already inherited from the
|
||||
<filename>meta-crownbay</filename> BSP.
|
||||
Here are the final <filename>SRCREV</filename> statements:
|
||||
<literallayout class='monospaced'>
|
||||
SRCREV_machine_pn-linux-yocto_mymachine ?= \
|
||||
"fce17f046d3756045e4dfb49221d1cf60fcae329"
|
||||
"1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
|
||||
SRCREV_meta_pn-linux-yocto_mymachine ?= \
|
||||
"84f1a422d7e21fbc23a687035bdf9d42471f19e0"
|
||||
"d05450e4aef02c1b7137398ab3a9f8f96da74f52"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you are familiar with Git repositories you probably won’t have trouble locating the
|
||||
In this example, we're using the <filename>SRCREV</filename> values we
|
||||
found already captured in the edison release because we're creating a BSP based on
|
||||
edison.
|
||||
If, instead, we had based our BSP on the master branches, we would want to use
|
||||
the most recent <filename>SRCREV</filename> values taken directly from the kernel repo.
|
||||
We will not be doing that for this example.
|
||||
However, if you do base a future BSP on master and
|
||||
if you are familiar with Git repositories, you probably won’t have trouble locating the
|
||||
exact commit strings in the Yocto Project source repositories you need to change
|
||||
the <filename>SRCREV</filename> statements.
|
||||
You can find all the <filename>machine</filename> and <filename>meta</filename>
|
||||
branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel
|
||||
<ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37'>here</ulink>
|
||||
[WRITER's NOTE: Need new link to the 3.0 source repo area when it is available].
|
||||
branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel at
|
||||
<ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0'></ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -395,19 +477,25 @@
|
|||
Because we are not interested in supporting EMGD those three can be deleted.
|
||||
The remaining three must be changed so that <filename>mymachine</filename> replaces
|
||||
<filename>crownbay-noemgd</filename> and <filename>crownbay</filename>.
|
||||
Because we are using the atom-pc branch for this new BSP, we can also find
|
||||
the exact branch we need for the KMACHINE variable in our new BSP from the value
|
||||
we find in the
|
||||
<filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
|
||||
file we looked at in a previous step.
|
||||
In this case, the value we want is in the KMACHINE_atom-pc variable in that file.
|
||||
Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all
|
||||
the edits:
|
||||
<literallayout class='monospaced'>
|
||||
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
||||
|
||||
COMPATIBLE_MACHINE_mymachine = "mymachine"
|
||||
KMACHINE_mymachine = "yocto/standard/mymachine"
|
||||
KMACHINE_mymachine = "yocto/standard/common-pc/atom-pc"
|
||||
KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"
|
||||
|
||||
SRCREV_machine_pn-linux-yocto_mymachine ?= \
|
||||
"fce17f046d3756045e4dfb49221d1cf60fcae329"
|
||||
"1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
|
||||
SRCREV_meta_pn-linux-yocto_mymachine ?= \
|
||||
"84f1a422d7e21fbc23a687035bdf9d42471f19e0"
|
||||
"d05450e4aef02c1b7137398ab3a9f8f96da74f52"
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -486,14 +574,14 @@
|
|||
|
||||
<para>
|
||||
The appendix
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
|
||||
Reference: Variables Glossary</ulink> in the Yocto Project Reference Manual has more information
|
||||
on configuration variables.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='building-the-image-app'>
|
||||
<title>Building the Image</title>
|
||||
<title>Building and Booting the Image</title>
|
||||
|
||||
<para>
|
||||
To build the image for our <filename>meta-mymachine</filename> BSP enter the following command
|
||||
|
@ -502,7 +590,7 @@
|
|||
For example, moving your working directory around could cause problems.
|
||||
Here is the command for this example:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake –k core-image-sato-live
|
||||
$ bitbake -k core-image-sato
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
@ -514,6 +602,65 @@
|
|||
If the build results in any type of error you should check for misspellings in the
|
||||
files you changed or problems with your host development environment such as missing packages.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, once you have an image, you can try booting it from a device
|
||||
(e.g. a USB device).
|
||||
To prepare a bootable USB device, insert a USB flash drive into your build system and
|
||||
copy the <filename>.hddimage</filename>, located in the
|
||||
<filename>poky/build/tmp/deploy/images</filename>
|
||||
directory after a successful build to the flash drive.
|
||||
Assuming the USB flash drive takes device <filename>/dev/sdc</filename>,
|
||||
use <filename>dd</filename> to copy the live image to it.
|
||||
For example:
|
||||
<literallayout class='monospaced'>
|
||||
# dd if=core-image-sato-mymachine-20120111232235.hddimg of=/dev/sdc
|
||||
# sync
|
||||
# eject /dev/sdc
|
||||
</literallayout>
|
||||
You should now have a bootable USB flash device.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Insert the device
|
||||
into a bootable USB socket on the target, and power it on.
|
||||
The system should boot to the Sato graphical desktop.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For reference, the sato image produced by the previous steps for edison
|
||||
should look like the following in terms of size.
|
||||
If your sato image is much different from this,
|
||||
you probably made a mistake in one of the above steps:
|
||||
<literallayout class='monospaced'>
|
||||
358709248 2012-01-11 20:43 core-image-sato-mymachine-20120111232235.hddimg
|
||||
</literallayout>
|
||||
<note>The previous instructions are also present in the README that was copied
|
||||
from meta-crownbay, which should also be updated to reflect the specifics of your
|
||||
new BSP.
|
||||
That file and the <filename>README.hardware</filename> file in the top-level
|
||||
<filename>poky</filename> directory
|
||||
also provides some suggestions for things to try if booting fails and produces
|
||||
strange error messages.</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Because this new image is not in any way tailored to the system you're
|
||||
booting it on, which is assumed to be some sort of atom-pc (netbook) system for this
|
||||
example, it might not be completely functional though it should at least boot to a text
|
||||
prompt.
|
||||
Specifically, it might fail to boot into graphics without some tweaking.
|
||||
If this ends up being the case, a possible next step would be to replace the
|
||||
<filename>mymachine.conf</filename>
|
||||
contents with the contents of <filename>atom-pc.conf</filename> and replace
|
||||
<filename>xorg.conf</filename> with <filename>atom-pc xorg.conf</filename>
|
||||
in <filename>meta-yocto</filename> and see if it fares any better.
|
||||
In any case, following the previous steps should
|
||||
probably give you a buildable and bootable image.
|
||||
Getting things working like you want
|
||||
them to for your hardware will normally require some amount of experimentation with
|
||||
configuration settings.
|
||||
</para>
|
||||
</section>
|
||||
</appendix>
|
||||
|
||||
|
|
|
@ -4,29 +4,26 @@
|
|||
<chapter id='dev-manual-intro'>
|
||||
|
||||
<title>The Yocto Project Development Manual</title>
|
||||
|
||||
<para>
|
||||
WRITER NOTE: The goal of this manual is to provide an over-arching development guide for using the Yocto Project.
|
||||
The intent is to give the reader the “big picture” around development.
|
||||
Much of the information in the manual will be detailed in other manuals.
|
||||
For example, detailed information on Git, repositories and open-source in general can be found in many places.
|
||||
Another example is getting set up to use the Yocto Project, which our Yocto Project Quick Start covers.
|
||||
However, this manual needs to at least address it.
|
||||
One might ask “What becomes of the Poky Reference Manual?”
|
||||
This manual, over time, needs to develop into a pure reference manual where all procedural information
|
||||
eventually ends up in an appropriate guide.
|
||||
A good example of information perfect for the Poky Reference Manual is the appendix on variable
|
||||
definitions (glossary).
|
||||
</para>
|
||||
|
||||
<section id='intro'>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
Welcome to the Yocto Project Development Guide!
|
||||
This guide provides a general view of the development process using the Yocto Project.
|
||||
This guide is just that – a guide.
|
||||
It helps you understand the bigger picture involving development using the Yocto Project.
|
||||
Welcome to the Yocto Project Development Manual!
|
||||
This manual gives you an idea of how to use the Yocto Project to develop embedded Linux
|
||||
images and user-space applications to run on targeted devices.
|
||||
Reading this manual gives you an overview of image, kernel, and user-space application development
|
||||
using the Yocto Project.
|
||||
Because much of the information in this manual is general, it contains many references to other
|
||||
sources where you can find more detail.
|
||||
For example, detailed information on Git, repositories and open-source in general
|
||||
can be found in many places.
|
||||
Another example is how to get set up to use the Yocto Project, which our Yocto Project Quick Start covers.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Yocto Project Development Manual, however, does provide detailed examples on how to create a
|
||||
Board Support Package (BSP), change the kernel source code, and re-configure the kernel.
|
||||
You can find this information in the appendices of the manual.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -46,13 +43,13 @@
|
|||
applications.</para></listitem>
|
||||
<listitem><para>An overview and understanding of the emulation environment used with
|
||||
the Yocto Project (QEMU).</para></listitem>
|
||||
<listitem><para>A discussion of target-level analysis techniques, tools, tips,
|
||||
<!-- <listitem><para>A discussion of target-level analysis techniques, tools, tips,
|
||||
and tricks.</para></listitem>
|
||||
<listitem><para>Considerations for deploying your final product.</para></listitem>
|
||||
<listitem><para>Considerations for deploying your final product.</para></listitem> -->
|
||||
<listitem><para>An understanding of basic kernel architecture and
|
||||
concepts.</para></listitem>
|
||||
<listitem><para>Information that will help you migrate an existing project to the
|
||||
Yocto Project development environment.</para></listitem>
|
||||
<!-- <listitem><para>Information that will help you migrate an existing project to the
|
||||
Yocto Project development environment.</para></listitem> -->
|
||||
<listitem><para>Many references to other sources of related information.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
@ -67,10 +64,13 @@
|
|||
<listitem><para>Step-by-step instructions if those instructions exist in other Yocto
|
||||
Project documentation.
|
||||
For example, The Application Development Toolkit (ADT) User’s Guide contains detailed
|
||||
instruction on how to obtain and configure the Eclipse Yocto Plug-in.</para></listitem>
|
||||
instruction on how to obtain and configure the
|
||||
<trademark class='trade'>Eclipse</trademark> Yocto Plug-in.</para></listitem>
|
||||
<listitem><para>Reference material.
|
||||
This type of material resides in an appropriate reference manual.
|
||||
For example, system variables are documented in the Poky Reference Manual.</para></listitem>
|
||||
For example, system variables are documented in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
Yocto Project Reference Manual</ulink>.</para></listitem>
|
||||
<listitem><para>Detailed public information that is not specific to the Yocto Project.
|
||||
For example, exhaustive information on how to use Git is covered better through the
|
||||
Internet than in this manual.</para></listitem>
|
||||
|
@ -90,27 +90,27 @@
|
|||
</emphasis> The home page for the Yocto Project provides lots of information on the project
|
||||
as well as links to software and documentation.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
The Yocto Project Quick Start</ulink>:</emphasis> This short document lets you get started
|
||||
with the Yocto Project quickly and start building an image.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
The Yocto Project Reference Manual</ulink>:</emphasis> This manual is a reference
|
||||
guide to the Yocto Project build component known as "Poky."
|
||||
The manual also contains a reference chapter on Board Support Package (BSP)
|
||||
layout.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
|
||||
The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>:</emphasis>
|
||||
This guide provides information that lets you get going with the ADT to
|
||||
develop projects using the Yocto Project.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
|
||||
The Yocto Project Board Support Package (BSP) Developer's Guide</ulink>:</emphasis>
|
||||
This guide defines the structure for BSP components.
|
||||
Having a commonly understood structure encourages standardization.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
|
||||
The Yocto Project Kernel Architecture and Use Manual</ulink>:</emphasis>
|
||||
This manual describes the architecture of the Yocto Project kernel and provides
|
||||
some work flow examples.</para></listitem>
|
||||
|
@ -136,9 +136,9 @@
|
|||
lists, click on the following URLs and follow the instructions:
|
||||
<itemizedlist>
|
||||
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> for a
|
||||
Yocto Discussions mailing list.</para></listitem>
|
||||
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a
|
||||
Yocto Project Discussions mailing list.</para></listitem>
|
||||
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a
|
||||
Yocto Project Discussions mailing list about the Poky build system.</para></listitem>
|
||||
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink>
|
||||
for a mailing list to receive offical Yocto Project announcements for developments and
|
||||
as well as Yocto Project milestones.</para></listitem>
|
||||
|
@ -172,11 +172,10 @@
|
|||
primarily for handheld and mobile devices.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<ulink url='http://wiki.qemu.org/Index.html'>QEMU</ulink>:
|
||||
</emphasis> An open source machine emulator and virtualizer.</para></listitem>
|
||||
</emphasis> An open-source machine emulator and virtualizer.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
|
|
|
@ -47,7 +47,7 @@
|
|||
<listitem><para>The <filename>poky-extras</filename> Git repository placed
|
||||
within the local Yocto Project files Git repository</para></listitem>
|
||||
<listitem><para>A bare clone of the Linux Yocto kernel upstream Git
|
||||
repository that you want to modify
|
||||
repository to which you want to push your modifications.
|
||||
</para></listitem>
|
||||
<listitem><para>A copy of that bare clone in which you make your source
|
||||
modifcations</para></listitem>
|
||||
|
@ -56,15 +56,16 @@
|
|||
|
||||
<para>
|
||||
The following figure summarizes these four areas.
|
||||
Within each rectangular that represents a data structure an URL appears at the
|
||||
Within each rectangular that represents a data structure, a
|
||||
host development directory pathname appears at the
|
||||
lower left-hand corner of the box.
|
||||
These URLs are the locations used in this example.
|
||||
These pathnames are the locations used in this example.
|
||||
The figure also provides key statements and commands used during the kernel
|
||||
modification process:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<imagedata fileref="figures/kernel-example-repos.png" width="7in" depth="5in"
|
||||
<imagedata fileref="figures/kernel-example-repos-edison.png" width="7in" depth="5in"
|
||||
align="center" scale="100" />
|
||||
</para>
|
||||
|
||||
|
@ -74,13 +75,13 @@
|
|||
<listitem><para><emphasis>Local Yocto Project Files Git Repository:</emphasis>
|
||||
This area contains all the metadata that supports building images in the
|
||||
Yocto Project build environment - the local Yocto Project files.
|
||||
The Local Yocto Project files Git repository also contains the build directory
|
||||
and a configuration directory that let you control the build.
|
||||
Note also that in this example the repository also contains the
|
||||
In this example, the local Yocto Project files Git repository also
|
||||
contains the build directory, which contains the configuration directory
|
||||
that lets you control the build.
|
||||
In this example, the repository also contains the
|
||||
<filename>poky-extras</filename> Git repository.</para>
|
||||
<para>See the bulleted item
|
||||
<link linkend='local-yp-release'>Yocto Project Release</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
|
||||
"<link linkend='local-yp-release'>Yocto Project Release</link>"
|
||||
for information on how to get these files.</para></listitem>
|
||||
<listitem><para><emphasis><filename>poky-extras</filename> Git Repository:</emphasis>
|
||||
This area contains the <filename>meta-kernel-dev</filename> layer,
|
||||
|
@ -91,9 +92,8 @@
|
|||
(or really any) kernel recipes that faciliate the creation and development
|
||||
of kernel features, BSPs or configurations.</para>
|
||||
<para>See the bulleted item
|
||||
<link linkend='poky-extras-repo'>The
|
||||
<filename>poky-extras</filename> Git Repository</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
|
||||
"<link linkend='poky-extras-repo'>The
|
||||
<filename>poky-extras</filename> Git Repository</link>"
|
||||
for information on how to get these files.</para></listitem>
|
||||
<listitem><para><emphasis>Bare Clone of the Linux Yocto kernel:</emphasis>
|
||||
This bare Git repository tracks the upstream Git repository of the Linux
|
||||
|
@ -105,8 +105,7 @@
|
|||
<filename>poky-extras</filename> repository points to the bare clone
|
||||
so that the build process can locate the locally changed source files.</para>
|
||||
<para>See the bulleted item
|
||||
<link linkend='local-kernel-files'>Linux Yocto Kernel</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
|
||||
"<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
|
||||
for information on how to set up the bare clone.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Copy of the Linux Yocto Kernel Bare Clone:</emphasis>
|
||||
|
@ -114,9 +113,14 @@
|
|||
Any changes you make to files in this location need to ultimately be pushed
|
||||
to the bare clone using the <filename>git push</filename> command.</para>
|
||||
<para>See the bulleted item
|
||||
<link linkend='local-kernel-files'>Linux Yocto Kernel</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
|
||||
"<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
|
||||
for information on how to set up the bare clone.
|
||||
<note>Typically, Git workflows follow a scheme where changes made to a local area
|
||||
are pulled into a Git repository.
|
||||
However, because the <filename>git pull</filename> command does not work
|
||||
with bare clones, this workflow pushes changes to the
|
||||
repository even though you could use other more complicated methods to
|
||||
get changes into the bare clone.</note>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
@ -131,8 +135,7 @@
|
|||
This example uses <filename>poky</filename> as the root directory of the
|
||||
local Yocto Project files Git repository.
|
||||
See the bulleted item
|
||||
<link linkend='local-yp-release'>Yocto Project Release</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
|
||||
"<link linkend='local-yp-release'>Yocto Project Release</link>"
|
||||
for information on how to get these files.
|
||||
</para>
|
||||
|
||||
|
@ -146,14 +149,14 @@
|
|||
$ git branch -a
|
||||
$ git tag -l
|
||||
</literallayout>
|
||||
This example uses the Yocto Project 1.1_M3 Release,
|
||||
which maps to the <filename>1.1_M3</filename> branch in the repository.
|
||||
The following commands create and checkout the local <filename>1.1_M3</filename>
|
||||
This example uses the Yocto Project 1.1.1 Release code named "edison",
|
||||
which maps to the <filename>edison</filename> branch in the repository.
|
||||
The following commands create and checkout the local <filename>edison</filename>
|
||||
branch:
|
||||
<literallayout class='monospaced'>
|
||||
$ git checkout -b 1.1_M3 origin/1.1_M3
|
||||
Branch 1.1_M3 set up to track remote branch 1.1_M3 from origin.
|
||||
Switched to a new branch '1.1_M3'
|
||||
$ git checkout -b edison origin/edison
|
||||
Branch edison set up to track remote branch edison from origin.
|
||||
Switched to a new branch 'edison'
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -165,23 +168,42 @@
|
|||
This example places the <filename>poky-extras</filename> Git repository inside
|
||||
of <filename>poky</filename>.
|
||||
See the bulleted item
|
||||
<link linkend='poky-extras-repo'>The
|
||||
<filename>poky-extras</filename> Git Repository</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
|
||||
"<link linkend='poky-extras-repo'>The
|
||||
<filename>poky-extras</filename> Git Repository</link>"
|
||||
for information on how to get the <filename>poky-extras</filename> repository.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Once you have the repository set up,
|
||||
you have many development branches from which you can work.
|
||||
From inside the repository you can see the branch names and the tag names used
|
||||
in the Git repository using either of the following two commands:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd poky
|
||||
$ git branch -a
|
||||
$ git tag -l
|
||||
</literallayout>
|
||||
This example uses the Yocto Project 1.1.1 Release code named "edison",
|
||||
which maps to the <filename>edison</filename> branch in the repository.
|
||||
The following commands create and checkout the local <filename>edison</filename>
|
||||
branch:
|
||||
<literallayout class='monospaced'>
|
||||
$ git checkout -b edison origin/edison
|
||||
Branch edison set up to track remote branch edison from origin.
|
||||
Switched to a new branch 'edison'
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='setting-up-the-bare-clone-and-its-copy'>
|
||||
<title>Setting Up the Bare Clone and its Copy</title>
|
||||
|
||||
<para>
|
||||
This example modifies the <filename>linux-yocto-3.0</filename> kernel.
|
||||
This example modifies the <filename>linux-yocto-3.0-1.1.x</filename> kernel.
|
||||
Thus, you need to create a bare clone of that kernel and then make a copy of the
|
||||
bare clone.
|
||||
See the bulleted item
|
||||
<link linkend='local-kernel-files'>Linux Yocto Kernel</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
|
||||
"<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
|
||||
for information on how to do that.
|
||||
</para>
|
||||
|
||||
|
@ -189,14 +211,16 @@
|
|||
The bare clone exists for the kernel build tools and simply as the receiving end
|
||||
of <filename>git push</filename>
|
||||
commands after you make edits and commits inside the copy of the clone.
|
||||
The copy (<filename>linux-yocto-3.0</filename> in this example) has to have
|
||||
The copy (<filename>my-linux-yocto-3.0-1.1.x-work</filename> in this example) has to have
|
||||
a local branch created and checked out for your work.
|
||||
This example uses <filename>common-pc-base</filename> as the local branch.
|
||||
The following commands create and checkout the branch:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/linux-yocto-3.0
|
||||
$ cd ~/my-linux-yocto-3.0-1.1.x-work
|
||||
$ git checkout -b common-pc-base origin/yocto/standard/common-pc/base
|
||||
Branch common-pc-base set up to track remote branch yocto/standard/common-pc/base from origin.
|
||||
Checking out files: 100% (7289/7289), done.
|
||||
Branch common-pc-base set up to track remote branch
|
||||
yocto/standard/common-pc/base from origin.
|
||||
Switched to a new branch 'common-pc-base'
|
||||
</literallayout>
|
||||
</para>
|
||||
|
@ -224,7 +248,9 @@
|
|||
of cores your machine supports and set <filename>PARALLEL_MAKE</filename> to one and
|
||||
a half times the number of cores your machine supports.
|
||||
</note>
|
||||
The following commands build the default <filename>qemux86</filename> image:
|
||||
The following two commands <filename>source</filename> the build environment setup script
|
||||
and build the default <filename>qemux86</filename> image.
|
||||
If necessary, the script creates the build directory:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/poky
|
||||
$ source oe-init-build-env
|
||||
|
@ -242,15 +268,14 @@
|
|||
meta-ide-support
|
||||
|
||||
You can also run generated qemu images with a command like 'runqemu qemux86'
|
||||
|
||||
$ bitbake -k core-image-minimal
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>source</filename> command sets up the build environment and,
|
||||
if necessary, creates the build directory.
|
||||
The following <filename>bitbake</filename> command starts the build.
|
||||
The following <filename>bitbake</filename> command starts the build:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake -k core-image-minimal
|
||||
</literallayout>
|
||||
<note>Be sure to check the settings in the <filename>local.conf</filename>
|
||||
before starting the build.</note>
|
||||
</para>
|
||||
|
@ -287,7 +312,7 @@
|
|||
|
||||
<para>
|
||||
The file you change in this example is named <filename>calibrate.c</filename>
|
||||
and is located in the <filename>linux-yocto-3.0</filename> Git repository
|
||||
and is located in the <filename>my-linux-yocto-3.0-1.1.x-work</filename> Git repository
|
||||
(the copy of the bare clone) in <filename>init</filename>.
|
||||
This example simply inserts several <filename>printk</filename> statements
|
||||
at the beginning of the <filename>calibrate_delay</filename> function.
|
||||
|
@ -298,8 +323,7 @@
|
|||
<literallayout class='monospaced'>
|
||||
void __cpuinit calibrate_delay(void)
|
||||
{
|
||||
unsigned long ticks, loopbit;
|
||||
int lps_precision = LPS_PREC;
|
||||
unsigned long lpj;
|
||||
static bool printed;
|
||||
|
||||
if (preset_lpj) {
|
||||
|
@ -315,8 +339,7 @@
|
|||
<literallayout class='monospaced'>
|
||||
void __cpuinit calibrate_delay(void)
|
||||
{
|
||||
unsigned long ticks, loopbit;
|
||||
int lps_precision = LPS_PREC;
|
||||
unsigned long lpj;
|
||||
static bool printed;
|
||||
printk("*************************************\n");
|
||||
printk("* *\n");
|
||||
|
@ -374,15 +397,16 @@
|
|||
change the target architecture of the machine you are building or you move
|
||||
the bare clone, copy of the clone, or the <filename>poky-extras</filename> repository:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Build for the Correct Target Architecture</emphasis> - The
|
||||
<listitem><para><emphasis>Build for the Correct Target Architecture:</emphasis> The
|
||||
<filename>local.conf</filename> file in the build directory defines the build's
|
||||
target architecture.
|
||||
By default, <filename>MACHINE</filename> is set to
|
||||
<filename>qemux86</filename>, which specifies a 32-bit Intel Architecture
|
||||
<filename>qemux86</filename>, which specifies a 32-bit
|
||||
<trademark class='registered'>Intel</trademark> Architecture
|
||||
target machine suitable for the QEMU emulator.
|
||||
In this example, <filename>MACHINE</filename> is correctly configured.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Optimize Build Time</emphasis> - Also in the
|
||||
<listitem><para><emphasis>Optimize Build Time:</emphasis> Also in the
|
||||
<filename>local.conf</filename> file are two variables that can speed your
|
||||
build time if your host supports multi-core and multi-thread capabilities:
|
||||
<filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>.
|
||||
|
@ -391,7 +415,7 @@
|
|||
cores and setting <filename>PARALLEL_MAKE</filename> to one and a half times the
|
||||
number of cores.</para></listitem>
|
||||
<listitem><para><emphasis>Identify Your <filename>meta-kernel-dev</filename>
|
||||
Layer</emphasis> - The <filename>BBLAYERS</filename> variable in the
|
||||
Layer:</emphasis> The <filename>BBLAYERS</filename> variable in the
|
||||
<filename>bblayers.conf</filename> file found in the
|
||||
<filename>poky/build/conf</filename> directory needs to have the path to your local
|
||||
<filename>meta-kernel-dev</filename> layer.
|
||||
|
@ -408,20 +432,20 @@
|
|||
/home/scottrif/poky/poky-extras/meta-kernel-dev \
|
||||
"
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>Identify Your Source Files</emphasis> - In the
|
||||
<listitem><para><emphasis>Identify Your Source Files:</emphasis> In the
|
||||
<filename>linux-yocto_3.0.bbappend</filename> file located in the
|
||||
<filename>poky-extras/meta-kernel-dev/recipes-kernel/linux</filename>
|
||||
directory, you need to identify the location of the
|
||||
local source code, which in this example is the bare clone named
|
||||
<filename>linux-yocto-3.0.git</filename>.
|
||||
<filename>linux-yocto-3.0-1.1.x.git</filename>.
|
||||
To do this, set the <filename>KSRC_linux_yocto</filename> variable to point to your
|
||||
local <filename>linux-yocto-3.0.git</filename> Git repository by adding the
|
||||
local <filename>linux-yocto-3.0-1.1.x.git</filename> Git repository by adding the
|
||||
following statement.
|
||||
Be sure to substitute your user information in the statement:
|
||||
<literallayout class='monospaced'>
|
||||
KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0.git
|
||||
KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0-1.1.x.git
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>Specify the Kernel Machine</emphasis> - Also in the
|
||||
<listitem><para><emphasis>Specify the Kernel Machine:</emphasis> Also in the
|
||||
<filename>linux-yocto_3.0.bbappend</filename> file, you need to specify
|
||||
the kernel machine with the following statement:
|
||||
<literallayout class='monospaced'>
|
||||
|
@ -436,7 +460,8 @@
|
|||
Because all the kernel <filename>.bbappend</filename> files are parsed during the
|
||||
build process regardless of whether you are using them or not, you should either
|
||||
comment out the <filename>COMPATIBLE_MACHINE</filename> statements in all
|
||||
<filename>.bbappend</filename> files, or you should simply remove all the files
|
||||
unused <filename>.bbappend</filename> files.
|
||||
Alternatively, you can simply remove all the files
|
||||
except the one your are using for the build
|
||||
(i.e. <filename>linux-yocto_3.0.bbappend</filename> in this example).
|
||||
</note>
|
||||
|
@ -451,14 +476,15 @@
|
|||
<orderedlist>
|
||||
<listitem><para>Your environment should be set up since you previously sourced
|
||||
the <filename>oe-init-build-env</filename> script.
|
||||
If it isn't, source the script again from <filename>poky</filename>
|
||||
If it isn't, source the script again from <filename>poky</filename>.
|
||||
</para></listitem>
|
||||
<listitem><para>Be sure old images are cleaned out by running the
|
||||
<filename>cleanall</filename> BitBake task as follows:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/poky
|
||||
$ bitbake -c cleanall linux-yocto
|
||||
</literallayout></para>
|
||||
<para><note>Never remove by hand any files from the <filename>tmp/deploy</filename>
|
||||
<para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
|
||||
directory insided the local Yocto Project files build directory.
|
||||
Always use the BitBake <filename>cleanall</filename> task to clear
|
||||
out previous builds.</note></para></listitem>
|
||||
|
@ -466,14 +492,12 @@
|
|||
<literallayout class='monospaced'>
|
||||
$ bitbake -k core-image-minimal
|
||||
</literallayout></para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, boot the modified image in the QEMU emulator using this command:
|
||||
<listitem><para>Finally, boot the modified image in the QEMU emulator
|
||||
using this command:
|
||||
<literallayout class='monospaced'>
|
||||
$ runqemu qemux86
|
||||
</literallayout>
|
||||
</literallayout></para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -495,8 +519,8 @@
|
|||
<title>Changing the Kernel Configuration</title>
|
||||
|
||||
<para>
|
||||
This example changes the default behavior (off) of the Symmetric Multi-processing Support
|
||||
(<filename>CONFIG_SMP</filename>) to on.
|
||||
This example changes the default behavior, which is "off", of the Symmetric
|
||||
Multi-processing Support (<filename>CONFIG_SMP</filename>) to "on".
|
||||
It is a simple example that demonstrates how to reconfigure the kernel.
|
||||
</para>
|
||||
|
||||
|
@ -505,33 +529,96 @@
|
|||
|
||||
<para>
|
||||
If you took the time to work through the example that modifies the kernel source code
|
||||
in <xref linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
|
||||
Code</xref> you are set up to quickly work through this example.
|
||||
If not, then work through the following list to prepare:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Understand the development environment:</emphasis>
|
||||
See <xref linkend='understanding-the-files-you-need'>
|
||||
Understanding the Files You Need</xref> for information.</para></listitem>
|
||||
<listitem><para><emphasis>Set up the local Yocto Project files Git
|
||||
repository:</emphasis>
|
||||
See <xref linkend='setting-up-the-local-yocto-project-files-git-repository'>
|
||||
Setting Up the Local Yocto Project Files Git Repository</xref> for
|
||||
information.</para></listitem>
|
||||
<listitem><para><emphasis>Set up the <filename>poky-extras</filename> Git
|
||||
repository:</emphasis>
|
||||
See <xref linkend='setting-up-the-poky-extras-git-repository'>
|
||||
Setting Up <filename>poky-extras</filename> Git repository</xref> for
|
||||
information.</para></listitem>
|
||||
<listitem><para><emphasis>Set up the the bare clone and its copy:</emphasis>
|
||||
See <xref linkend='setting-up-the-bare-clone-and-its-copy'>
|
||||
Setting Up the Bare Clone and its Copy</xref> for information.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Build the default QEMU kernel image:</emphasis>
|
||||
See <xref linkend='building-and-booting-the-default-qemu-kernel-image'>
|
||||
Building and Booting the Default QEMU Kernel image</xref>
|
||||
for information.
|
||||
Do not boot the image in the QEMU emulator at this point.</para></listitem>
|
||||
</itemizedlist>
|
||||
in "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
|
||||
Code</link>" you should already have the Yocto Project files set up on your
|
||||
host machine.
|
||||
If this is the case, go to then next section titled
|
||||
"<link linkend='examining-the-default-config-smp-behavior'>Examining the Default
|
||||
<filename>CONFIG_SMP</filename> Behavior</link>" and continue with the
|
||||
example.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you don't have the Yocto Project files established on your system,
|
||||
you can get them through tarball extraction or by
|
||||
cloning the <filename>poky</filename> Git repository.
|
||||
This example uses <filename>poky</filename> as the root directory of the
|
||||
local Yocto Project files Git repository.
|
||||
See the bulleted item
|
||||
"<link linkend='local-yp-release'>Yocto Project Release</link>"
|
||||
for information on how to get these files.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Once you have the repository set up,
|
||||
you have many development branches from which you can work.
|
||||
From inside the repository you can see the branch names and the tag names used
|
||||
in the Git repository using either of the following two commands:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd poky
|
||||
$ git branch -a
|
||||
$ git tag -l
|
||||
</literallayout>
|
||||
This example uses the Yocto Project 1.1.1 Release code named "edison",
|
||||
which maps to the <filename>edison</filename> branch in the repository.
|
||||
The following commands create and checkout the local <filename>edison</filename>
|
||||
branch:
|
||||
<literallayout class='monospaced'>
|
||||
$ git checkout -b edison origin/edison
|
||||
Branch edison set up to track remote branch edison from origin.
|
||||
Switched to a new branch 'edison'
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Next, you need to build the default <filename>qemux86</filename> image that you
|
||||
can boot using QEMU.
|
||||
<note>
|
||||
Because a full build can take hours, you should check two variables in the
|
||||
<filename>build</filename> directory that is created after you source the
|
||||
<filename>oe-init-build-env</filename> script.
|
||||
You can find these variables
|
||||
<filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
|
||||
in the <filename>build/conf</filename> directory in the
|
||||
<filename>local.conf</filename> configuration file.
|
||||
By default, these variables are commented out.
|
||||
If your host development system supports multi-core and multi-thread capabilities,
|
||||
you can uncomment these statements and set the variables to significantly shorten
|
||||
the full build time.
|
||||
As a guideline, set <filename>BB_NUMBER_THREADS</filename> to twice the number
|
||||
of cores your machine supports and set <filename>PARALLEL_MAKE</filename> to one and
|
||||
a half times the number of cores your machine supports.
|
||||
</note>
|
||||
The following two commands <filename>source</filename> the build environment setup script
|
||||
and build the default <filename>qemux86</filename> image.
|
||||
If necessary, the script creates the build directory:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/poky
|
||||
$ source oe-init-build-env
|
||||
|
||||
### Shell environment set up for builds. ###
|
||||
|
||||
You can now run 'bitbake <target>'
|
||||
|
||||
Common targets are:
|
||||
core-image-minimal
|
||||
core-image-sato
|
||||
meta-toolchain
|
||||
meta-toolchain-sdk
|
||||
adt-installer
|
||||
meta-ide-support
|
||||
|
||||
You can also run generated qemu images with a command like 'runqemu qemux86'
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following <filename>bitbake</filename> command starts the build:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake -k core-image-minimal
|
||||
</literallayout>
|
||||
<note>Be sure to check the settings in the <filename>local.conf</filename>
|
||||
before starting the build.</note>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -540,10 +627,10 @@
|
|||
|
||||
<para>
|
||||
By default, <filename>CONFIG_SMP</filename> supports single processor machines.
|
||||
To see this default setting from within the QEMU emulator boot your image using
|
||||
To see this default setting from within the QEMU emulator, boot your image using
|
||||
the emulator as follows:
|
||||
<literallayout class='monospaced'>
|
||||
$ runqemu qemux86
|
||||
$ runqemu qemux86 qemuparams="-smp 2"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
@ -557,6 +644,8 @@
|
|||
processor : 0
|
||||
#
|
||||
</literallayout>
|
||||
Logout of the emulator using the <filename>exit</filename> command and
|
||||
then close it down.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -566,7 +655,7 @@
|
|||
<para>
|
||||
The <filename>menuconfig</filename> tool provides an interactive method with which
|
||||
to set kernel configurations.
|
||||
You need to run <filename>menuconfig</filename> inside the BitBake environment.
|
||||
You need to run <filename>menuconfig</filename> inside the Yocto BitBake environment.
|
||||
Thus, the environment must be set up using the <filename>oe-init-build-env</filename>
|
||||
script found in the Yocto Project files Git repository build directory.
|
||||
If you have not sourced this script do so with the following commands:
|
||||
|
@ -579,7 +668,7 @@
|
|||
<para>
|
||||
After setting up the environment to run <filename>menuconfig</filename>, you are ready
|
||||
to use the tool to interactively change the kernel configuration.
|
||||
In this example we are basing our changes on the <filename>linux-yocto-3.0</filename>
|
||||
In this example, we are basing our changes on the <filename>linux-yocto-3.0-1.1.x</filename>
|
||||
kernel.
|
||||
The Yocto Project build environment recognizes this kernel as
|
||||
<filename>linux-yocto</filename>.
|
||||
|
@ -596,23 +685,29 @@
|
|||
You can find it at <filename>Processor Type and Features</filename>.
|
||||
The configuration selection is
|
||||
<filename>Symmetric Multi-processing Support</filename>.
|
||||
After using the arrow keys to highlight this selection, press "y" to select it.
|
||||
Then, exit out and save your selections.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Once you save the selection the <filename>.config</filename> configuration file
|
||||
Once you save the selection, the <filename>.config</filename> configuration file
|
||||
is updated.
|
||||
This is the file that the build system uses to configure the Linux Yocto kernel
|
||||
when it is built.
|
||||
You can find and examine this file in the Yocto Project files Git repository in
|
||||
the build directory.
|
||||
This example uses the following:
|
||||
This example uses the following.
|
||||
Note that this example directory is artificially split and many of the characters
|
||||
in the actually filename are omitted in order to make it more
|
||||
readable:
|
||||
<literallayout class='monospaced'>
|
||||
~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-2.6.37+git1+84f...r20/linux-qemux86-standard-build
|
||||
~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.10+git1+d38...
|
||||
...3a9ac596f7a-r3/linux-qemux86-standard-build
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Within the <filename>.config</filename> you can see the following setting:
|
||||
Within the <filename>.config</filename> file, you can see the following setting:
|
||||
<literallayout class='monospaced'>
|
||||
CONFIG_SMP=y
|
||||
</literallayout>
|
||||
|
@ -621,13 +716,19 @@
|
|||
<para>
|
||||
A good method to isolate changed configurations is to use a combination of the
|
||||
<filename>menuconfig</filename> tool and simple shell commands.
|
||||
Before changing configurations with <filename>menuconfig</filename> simply rename
|
||||
the default <filename>.config</filename>, use <filename>menuconfig</filename> to make
|
||||
Before changing configurations with <filename>menuconfig</filename>, copy the
|
||||
existing <filename>.config</filename> and rename it to something else,
|
||||
use <filename>menuconfig</filename> to make
|
||||
as many changes an you want and save them, then compare the renamed configuration
|
||||
file against the newly created file.
|
||||
You can use the resulting differences as your base to create configuration fragments
|
||||
to permanently save in your kernel layer.
|
||||
For an example of this procedure, see [WRITER'S NOTE: need forwarding link to section].
|
||||
<note>
|
||||
Be sure to make a copy of the <filename>.config</filename> and don't just
|
||||
rename it.
|
||||
The Yocto Project build system needs an existing <filename>.config</filename>
|
||||
from which to work.
|
||||
</note>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -635,7 +736,7 @@
|
|||
<title>Recompiling the Kernel and Testing the New Configuration</title>
|
||||
|
||||
<para>
|
||||
At this point you are ready to recompile your kernel image with
|
||||
At this point, you are ready to recompile your kernel image with
|
||||
the new setting in effect using the BitBake commands below:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake linux-yocto -c compile -f
|
||||
|
@ -646,7 +747,7 @@
|
|||
<para>
|
||||
Now run the QEMU emulator:
|
||||
<literallayout class='monospaced'>
|
||||
$ runqemu qemux86
|
||||
$ runqemu qemux86 qemuparams="-smp 2"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
@ -662,7 +763,7 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
From the output you can see that you have successfully reconfigured the kernel.
|
||||
From the output, you can see that you have successfully reconfigured the kernel.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
@ -671,12 +772,13 @@
|
|||
<title>Adding Kernel Recipes</title>
|
||||
|
||||
<para>
|
||||
This section presents an example that adds kernel recipes, which provide
|
||||
A future release of this manual will present an example that adds kernel recipes, which provide
|
||||
new functionality to the kernel.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
[Example to be supplied]
|
||||
<imagedata fileref="figures/wip.png"
|
||||
width="2in" depth="3in" align="center" scalefit="1" />
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
|
@ -9,16 +9,23 @@
|
|||
Many development models exist for which you can use the Yocto Project.
|
||||
However, for the purposes of this manual we are going to focus on two common ones:
|
||||
System Development and User Application Development.
|
||||
System Development covers Board Support Package (BSP) development and kernel modification.
|
||||
System Development covers Board Support Package (BSP) development and kernel modification
|
||||
or configuration.
|
||||
User Application Development covers development of applications that you intend to run on some
|
||||
target hardware.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This chapter presents overviews of both system and application models.
|
||||
If you want to reference specific examples of these development models,
|
||||
see <xref linkend='dev-manual-bsp-appendix'>BSP Development Example</xref> and
|
||||
<xref linkend='dev-manual-kernel-appendix'>Kernel Modification Example</xref>.
|
||||
If you want to examine specific examples of the system development models,
|
||||
see the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>"
|
||||
appendix and the
|
||||
"<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>" appendix.
|
||||
For a user-space application development example that uses the
|
||||
<trademark class='trade'>Eclipse</trademark> IDE,
|
||||
see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
|
||||
The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>.
|
||||
</para>
|
||||
|
||||
<section id='system-development-model'>
|
||||
|
@ -27,7 +34,7 @@
|
|||
<para>
|
||||
System development involves modification or creation of an image that you want to run on
|
||||
a specific hardware target.
|
||||
Usually when you want to create an image that runs on embedded hardware the image does
|
||||
Usually, when you want to create an image that runs on embedded hardware, the image does
|
||||
not require the same amount of features that a full-fledged Linux distribution provides.
|
||||
Thus, you can create a much smaller image that is designed to just use the hardware
|
||||
features for your particular hardware.
|
||||
|
@ -35,33 +42,33 @@
|
|||
|
||||
<para>
|
||||
To help you understand how system development works in the Yocto Project, this section
|
||||
covers two types of image development: BSP creation and kernel modification
|
||||
(see <xref linkend='kernel-spot'></xref>).
|
||||
covers two types of image development: BSP creation and kernel modification or
|
||||
configuration.
|
||||
</para>
|
||||
|
||||
<section id='developing-a-board-support-package-bsp'>
|
||||
<title>Developing a Board Support Package (BSP)</title>
|
||||
|
||||
<para>
|
||||
A BSP is a package of recipes that when applied during a build results in
|
||||
A BSP is a package of recipes that, when applied, during a build results in
|
||||
an image you can run on a particular board.
|
||||
Thus, the package, when compiled into the new image, supports the operation of the board.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
For a brief list of terms used when describing the development process in the Yocto Project,
|
||||
see <xref linkend='yocto-project-terms'>Yocto Project Terms</xref> in this manual.
|
||||
see the "<link linkend='yocto-project-terms'>Yocto Project Terms</link>" section.
|
||||
</note>
|
||||
|
||||
<para>
|
||||
The remainder of this section presents the basic steps to create a BSP basing it on an
|
||||
existing BSP that ships with the Yocto Project.
|
||||
You can reference <xref linkend='dev-manual-bsp-appendix'>BSP Development Example</xref>
|
||||
for a detailed example that uses the Crown Bay BSP as a base BSP from which to start.
|
||||
You can reference the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>"
|
||||
appendix for a detailed example that uses the Crown Bay BSP as a base BSP from which to start.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This illustration and the following list summarizes the BSP creation general workflow.
|
||||
The following illustration and list summarize the BSP creation general workflow.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -71,37 +78,38 @@
|
|||
<para>
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Set up your host development system to support
|
||||
development using the Yocto Project</emphasis>: See
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>
|
||||
The Linux Distributions</ulink> section and
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>
|
||||
The Packages</ulink> section both
|
||||
development using the Yocto Project</emphasis>: See the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
|
||||
in the Yocto Project Quick Start for requirements.</para></listitem>
|
||||
<listitem><para><emphasis>Establish a local copy of the Yocto Project files on your
|
||||
system</emphasis>: You need to have the Yocto Project files available on your host system.
|
||||
Having the Yocto Project files on your system gives you access to the build
|
||||
process and tools you need.
|
||||
For information on how to get these files, see the
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> section in this manual.</para></listitem>
|
||||
"<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
|
||||
<listitem><para><emphasis>Establish a local copy of the base BSP files</emphasis>: Having
|
||||
the BSP files on your system gives you access to the build
|
||||
process and tools you need.
|
||||
For information on how to get these files, see
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.</para></listitem>
|
||||
process and tools you need for creating a BSP.
|
||||
For information on how to get these files, see the
|
||||
"<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
|
||||
<listitem><para><emphasis>Choose a Yocto Project-supported BSP as your base BSP</emphasis>:
|
||||
The Yocto Project ships with several BSPs that support various hardware.
|
||||
It is best to base your new BSP on an existing BSP rather than create all the
|
||||
recipes and configuration files from scratch.
|
||||
While it is possible to create everything from scratch, basing your new BSP
|
||||
on something that is close is much easier.
|
||||
Or, at a minimum, it gives you some structure with which to start.</para>
|
||||
Or, at a minimum, leveraging off an existing BSP
|
||||
gives you some structure with which to start.</para>
|
||||
<para>At this point you need to understand your target hardware well enough to determine which
|
||||
existing BSP it most closely matches.
|
||||
Things to consider are your hardware’s on-board features such as CPU type and graphics support.
|
||||
Things to consider are your hardware’s on-board features, such as CPU type and graphics support.
|
||||
You should look at the README files for supported BSPs to get an idea of which one
|
||||
you could use.
|
||||
A generic Atom-based BSP to consider is the Crown Bay that does not support
|
||||
the Intel® Embedded Media Graphics Driver (EMGD).
|
||||
A generic <trademark class='registered'>Intel</trademark>
|
||||
<trademark class='trade'>Atom</trademark>-based BSP to consider is the
|
||||
Crown Bay that does not support the <trademark class='registered'>Intel</trademark>
|
||||
Embedded Media Graphics Driver (EMGD).
|
||||
The remainder of this example uses that base BSP.</para>
|
||||
<para>To see the supported BSPs, go to the Yocto Project
|
||||
<ulink url='http://www.yoctoproject.org/download'>download page</ulink> and click
|
||||
|
@ -110,35 +118,34 @@
|
|||
isolating and storing work for a given piece of hardware.
|
||||
A layer is really just a location or area in which you place the recipes for your BSP.
|
||||
In fact, a BSP is, in itself, a special type of layer.
|
||||
Consider an application as another example that illustrates a layer.
|
||||
Another example that illustrates a layer is an application.
|
||||
Suppose you are creating an application that has library or other dependencies in
|
||||
order for it to compile and run.
|
||||
The layer, in this case, would be where all the recipes that define those dependencies
|
||||
are kept. The key point for a layer is that it is an isolated area that contains
|
||||
are kept.
|
||||
The key point for a layer is that it is an isolated area that contains
|
||||
all the relevant information for the project that the Yocto Project build
|
||||
system knows about.</para>
|
||||
<note>The Yocto Project supports four BSPs that are part of the
|
||||
Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>,
|
||||
<filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.
|
||||
The recipes and configurations for these four BSPs are located and dispersed
|
||||
within local Yocto Project files.
|
||||
within the local Yocto Project files.
|
||||
Consequently, they are not totally isolated in the spirit of layers unless you think
|
||||
of <filename>meta-yocto</filename> as a layer itself.
|
||||
On the other hand, BSP layers for Crown Bay, Emenlow, Jasper Forest,
|
||||
N450, and Sugar Bay are isolated.</note>
|
||||
<para>When you set up a layer for a new BSP you should follow a standard layout.
|
||||
This layout is described in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout'>
|
||||
Example Filesystem Layout</ulink> section of the Board Support Package (BSP) Development
|
||||
Guide.
|
||||
In the standard layout you will notice a suggested structure for recipes and
|
||||
<para>When you set up a layer for a new BSP, you should follow a standard layout.
|
||||
This layout is described in the section
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html#bsp-filelayout'>Example Filesystem Layout</ulink>" section of the Board Support Package (BSP) Development Guide.
|
||||
In the standard layout, you will notice a suggested structure for recipes and
|
||||
configuration information.
|
||||
You can see the standard layout for the Crown Bay BSP in this example by examining the
|
||||
directory structure of the <filename>meta-crownbay</filename> layer inside the
|
||||
local Yocto Project files.</para></listitem>
|
||||
<listitem><para><emphasis>Make configuration changes to your new BSP
|
||||
layer</emphasis>: The standard BSP layer structure organizes the files you need to edit in
|
||||
<filename>conf</filename> and several <filename>recipes-*</filename> within the
|
||||
<filename>conf</filename> and several <filename>recipes-*</filename> directories within the
|
||||
BSP layer.
|
||||
Configuration changes identify where your new layer is on the local system
|
||||
and identify which kernel you are going to use.
|
||||
|
@ -148,24 +155,22 @@
|
|||
recipes you don't use, and adding new recipes that you need to support your hardware.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Prepare for the build</emphasis>: Once you have made all the
|
||||
changes to your BSP layer there remains a few things
|
||||
changes to your BSP layer, there remains a few things
|
||||
you need to do for the Yocto Project build system in order for it to create your image.
|
||||
You need to get the build environment ready by sourcing an environment setup script
|
||||
and you need to be sure two key configuration files are configured appropriately.</para>
|
||||
<para>The entire process for building an image is overviewed in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
|
||||
Building an Image</ulink> section of the Yocto Project Quick Start.
|
||||
<para>The entire process for building an image is overviewed in the section
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.
|
||||
You might want to reference this information.</para></listitem>
|
||||
<listitem><para><emphasis>Build the image</emphasis>: The Yocto Project uses the BitBake
|
||||
tool to build images based on the type of image you want to create.
|
||||
You can find more information on BitBake
|
||||
<ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
|
||||
<para>The build process supports several types of images to satisfy different needs.
|
||||
See
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
|
||||
Reference: Images</ulink> in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
Yocto Project Reference Manual</ulink>for information on supported images.</para></listitem>
|
||||
See the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
|
||||
appendix in The Yocto Project Reference Manual for information on
|
||||
supported images.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
|
@ -173,11 +178,11 @@
|
|||
You can view a video presentation on "Building Custom Embedded Images with Yocto"
|
||||
at <ulink url='http://free-electrons.com/blog/elc-2011-videos'>Free Electrons</ulink>.
|
||||
You can also find supplemental information in
|
||||
<ulink url='http://yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
|
||||
<ulink url='http://yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
|
||||
The Board Support Package (BSP) Development Guide</ulink>.
|
||||
Finally, there is wiki page write up of the example located
|
||||
Finally, there is wiki page write up of the example also located
|
||||
<ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
|
||||
here</ulink> you might find helpful.
|
||||
here</ulink> that you might find helpful.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -196,9 +201,10 @@
|
|||
The remainder of this section presents a high-level overview of the Linux Yocto
|
||||
kernel architecture and the steps to modify the Linux Yocto kernel.
|
||||
For a complete discussion of the kernel, see
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
|
||||
The Yocto Project Kernel Architecture and Use Manual</ulink>.
|
||||
You can reference <xref linkend='dev-manual-kernel-appendix'>Kernel Modification Example</xref>
|
||||
You can reference the appendix
|
||||
"<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>"
|
||||
for a detailed example that changes the configuration of a kernel.
|
||||
</para>
|
||||
|
||||
|
@ -210,6 +216,7 @@
|
|||
of files that contain kernel patches.
|
||||
The Yocto Project, however, employs mechanisims, that in a sense, result in a kernel source
|
||||
generator.
|
||||
By the end of this section, this analogy will become clearer.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -224,8 +231,12 @@
|
|||
stable Linux Yocto kernel that is based on the Linux 2.6.34 release.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-2.6.37</filename></emphasis> - The
|
||||
stable Linux Yocto kernel that is based on the Linux 2.6.37 release.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The current
|
||||
Linux Yocto kernel that is based on the Linux 3.0 release.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The
|
||||
stable Linux Yocto kernel to use with the Yocto Project current (master) development.
|
||||
This kernel is based on the Linux 3.0 release.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-3.0-1.1.x</filename></emphasis> - The
|
||||
stable Linux Yocto kernel to use with the Yocto Project Release 1.1.x.
|
||||
This kernel is based on the Linux 3.0 release.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
|
||||
kernel based on the latest upstream release candidate available.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
@ -304,7 +315,7 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
<imagedata fileref="figures/kernel-overview-3.png"
|
||||
<imagedata fileref="figures/kernel-overview-3-edison.png"
|
||||
width="6in" depth="4in" align="center" scale="100" />
|
||||
</para>
|
||||
|
||||
|
@ -342,7 +353,7 @@
|
|||
<para>
|
||||
Again, for a complete discussion of the Yocto Project kernel's architcture and its
|
||||
branching strategy,
|
||||
see the <ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
|
||||
see the <ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
|
||||
The Yocto Project Kernel Architecture and Use Manual</ulink>.
|
||||
Also, you can reference
|
||||
<xref linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</xref>
|
||||
|
@ -358,24 +369,22 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
<imagedata fileref="figures/kernel-dev-flow.png" width="6in" depth="7in" align="center" scalefit="1" />
|
||||
<imagedata fileref="figures/kernel-dev-flow.png"
|
||||
width="6in" depth="7.5in" align="center" scalefit="1" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Set up your host development system to support
|
||||
development using the Yocto Project</emphasis>: See
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>
|
||||
The Linux Distributions</ulink> section and
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>
|
||||
The Packages</ulink> section both
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
|
||||
in the Yocto Project Quick Start for requirements.</para></listitem>
|
||||
<listitem><para><emphasis>Establish a local copy of the Yocto Project files on your
|
||||
system</emphasis>: Having the Yocto Project files on your system gives you access to
|
||||
the build process and tools you need.
|
||||
For information on how to get these files, see the bulleted item
|
||||
<link linkend='local-yp-release'>Yocto Project Release</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.
|
||||
"<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Set up the <filename>poky-extras</filename> Git
|
||||
repository</emphasis>: This repository is the area for your configuration
|
||||
|
@ -384,85 +393,85 @@
|
|||
It is good practice to set this repository up inside the local Yocto
|
||||
Project files Git repository.
|
||||
For information on how to get these files, see the bulleted item
|
||||
<link linkend='poky-extras-repo'>The
|
||||
<filename>poky-extras</filename> Git Repository</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.
|
||||
</para></listitem>
|
||||
"<link linkend='poky-extras-repo'>The <filename>poky-extras</filename> Git Repository</link>"
|
||||
earlier in this manual.</para></listitem>
|
||||
<listitem><para><emphasis>Establish a local copy of the Linux Yocto kernel files on your
|
||||
system</emphasis>: In order to make modifications to the kernel you need two things:
|
||||
a bare clone of the Linux Yocto kernel you are modifying and a copy of that
|
||||
bare clone.
|
||||
a bare clone of the Linux Yocto kernel you are modifying and
|
||||
a copy of that bare clone.
|
||||
The bare clone is required by the build process and is the area to which you
|
||||
push your kernel source changes.
|
||||
push your kernel source changes (pulling does not work with bare clones).
|
||||
The copy of the bare clone is a local Git repository that contains all the kernel's
|
||||
source files.
|
||||
You make your changes to the files in this copy of the bare clone.
|
||||
For information on how to set these two items up, see the bulleted item
|
||||
<link linkend='local-kernel-files'>Linux Yocto Kernel</link> in
|
||||
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.
|
||||
</para></listitem>
|
||||
"<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
|
||||
earlier in this manual.</para></listitem>
|
||||
<listitem><para><emphasis>Make changes to the kernel source code if
|
||||
applicable</emphasis>: Modifying the kernel does not always mean directly
|
||||
changing source files.
|
||||
However, if you have to do this then you make the changes in the local
|
||||
However, if you have to do this, you make the changes in the local
|
||||
Git repository you set up to hold the source files (i.e. the copy of the
|
||||
bare clone).
|
||||
Once the changes are made you need to use Git commands to commit the changes
|
||||
Once the changes are made, you need to use Git commands to commit the changes
|
||||
and then push them to the bare clone.</para></listitem>
|
||||
<listitem><para><emphasis>Make kernel configuration changes
|
||||
to your local kernel layer if applicable</emphasis>:
|
||||
If your situation calls for changing the kernel's configuration you can
|
||||
If your situation calls for changing the kernel's configuration, you can
|
||||
use <filename>menuconfig</filename>
|
||||
to enable and disable kernel configurations.
|
||||
Using <filename>menuconfig</filename> allows you to develop and test the
|
||||
configuration changes you are making to the kernel.</para></listitem>
|
||||
Using <filename>menuconfig</filename> allows you to interactively develop and test the
|
||||
configuration changes you are making to the kernel.
|
||||
When saved, changes using <filename>menuconfig</filename> update the kernel's
|
||||
<filename>.config</filename>.
|
||||
As an alternative method to changing the kernel's configuration, you can simply
|
||||
edit the <filename>.config</filename> found in the Yocto Project build
|
||||
directory at <filename>tmp/sysroots/<machine-name>/kernel</filename>
|
||||
directly.</para></listitem>
|
||||
<listitem><para><emphasis>Add new kernel recipes if applicable</emphasis>: The standard
|
||||
layer structure organizes recipe files inside the
|
||||
<filename>meta-kernel-dev</filename> layer that is within the
|
||||
<filename>poky-extras</filename> Git repository.
|
||||
If you need to add new kernel recipes you add them within this layer.
|
||||
Also within this area you will find the <filename>.bbappend</filename>
|
||||
If you need to add new kernel recipes, you add them within this layer.
|
||||
Also within this area, you will find the <filename>.bbappend</filename>
|
||||
file that appends information to the kernel's recipe file used during the
|
||||
build.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Prepare for the build</emphasis>: Once you have made all the
|
||||
changes to your kernel (configurations, source code changes, recipe additions,
|
||||
or recipe changes) there remains a few things
|
||||
you need to do for the Yocto Project build system in order for it to create your image.
|
||||
If you have not done so you need to get the build environment ready by sourcing
|
||||
or recipe changes), there remains a few things
|
||||
you need to do in order for the Yocto Project build system to create your image.
|
||||
If you have not done so, you need to get the build environment ready by sourcing
|
||||
the environment setup script described earlier.
|
||||
You also need to be sure two key configuration files
|
||||
(<filename>local.conf</filename> and <filename>bblayers.conf</filename>)
|
||||
are configured appropriately.</para>
|
||||
<para>The entire process for building an image is overviewed in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
|
||||
Building an Image</ulink> section of the Yocto Project Quick Start.
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.
|
||||
You might want to reference this information.
|
||||
Also, you should look at the detailed examples found in the appendices at
|
||||
end of this manual.</para></listitem>
|
||||
<listitem><para><emphasis>Build the image</emphasis>: The Yocto Project uses the BitBake
|
||||
at the end of this manual.</para></listitem>
|
||||
<listitem><para><emphasis>Build the image</emphasis>: The Yocto Project
|
||||
build system Poky uses the BitBake
|
||||
tool to build images based on the type of image you want to create.
|
||||
You can find more information on BitBake
|
||||
<ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
|
||||
<para>The build process supports several types of images to satisfy different needs.
|
||||
See
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
|
||||
Reference: Images</ulink> in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
Yocto Project Reference Manual</ulink> for information on supported
|
||||
images.</para></listitem>
|
||||
See the appendix
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
|
||||
in The Yocto Project Reference Manual for information on supported images.</para></listitem>
|
||||
<listitem><para><emphasis>Make your configuration changes available
|
||||
in the kernel layer</emphasis>: Up to this point all the configuration changes to the
|
||||
in the kernel layer</emphasis>: Up to this point, all the configuration changes to the
|
||||
kernel have been done and tested iteratively.
|
||||
Once they are tested and ready to go you can move them into the kernel layer,
|
||||
which allows you to distribute the layer.
|
||||
[WRITER'S NOTE: Not sure if the layer is meta-kernel-dev or if it would be
|
||||
a new layer copied from the work done there.]</para></listitem>
|
||||
<listitem><para><emphasis>Push your configuration and recipe changes upstream to the
|
||||
linux Yocto Git repository (in-tree changes)</emphasis>: If the changes you made
|
||||
are suited for all Linux Yocto users you might want to push the changes up into
|
||||
the Linux Yocto Git repository so that they become part of the kernel tree
|
||||
and available to everyone using the kernel.</para></listitem>
|
||||
Once they are tested and ready to go, you can move them into the kernel layer,
|
||||
which allows you to distribute the layer.</para></listitem>
|
||||
<listitem><para><emphasis>If applicable, share your in-tree changes</emphasis>:
|
||||
If the changes you made
|
||||
are suited for all Linux Yocto users, you might want to push the changes to a
|
||||
contribution area for the Linux Yocto Git repository.
|
||||
Once the changes are pushed, you can request that they
|
||||
be pulled into the master branch of the kernel tree.
|
||||
Doing so makes them available to everyone using the kernel.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -470,11 +479,194 @@
|
|||
</section>
|
||||
|
||||
<section id='place-holder-section-two'>
|
||||
<title>Place-Holder Section For Application Development</title>
|
||||
<title>Application Development Workflow</title>
|
||||
|
||||
<para>
|
||||
Text needed here.
|
||||
Application development involves creation of an application that you want to be able
|
||||
to run on your target hardware, which is running a Linux Yocto image.
|
||||
The Yocto Project provides an Application Development Toolkit (ADT) that
|
||||
facilitates quick development and integration of your application into its run-time environment.
|
||||
Using the ADT you can employ cross-development toolchains designed for your target hardware
|
||||
to compile and link your application.
|
||||
You can then deploy your application to the actual hardware or to the QEMU emulator for testing.
|
||||
If you are familiar with the popular Eclipse IDE, you can use an Eclipse Yocto Plug-in to
|
||||
allow you to develop, deploy, and test your application all from within Eclipse.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
While we strongly suggest using the Yocto Project ADT to develop your application, you might
|
||||
not want to.
|
||||
If this is the case, you can still use pieces of the Yocto Project for your development process.
|
||||
However, because the process can vary greatly, this manual does not provide detail on the process.
|
||||
</para>
|
||||
|
||||
<section id='workflow-using-the-adt-and-eclipse'>
|
||||
<title>Workflow Using the ADT and <trademark class='trade'>Eclipse</trademark></title>
|
||||
|
||||
<para>
|
||||
To help you understand how application development works in the Yocto Project ADT
|
||||
environment, this section
|
||||
provides an overview of the general development process.
|
||||
If you want to see a detailed example of the process as it is used from within the Eclipse
|
||||
IDE, see
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
|
||||
The Application Development Toolkit (ADT) User's Manual</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This illustration and the following list summarizes the application development general workflow.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<imagedata fileref="figures/app-dev-flow.png"
|
||||
width="7in" depth="8in" align="center" scale="100" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Prepare the Host System for the Yocto Project</emphasis>:
|
||||
See
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
|
||||
in the Yocto Project Quick Start for requirements.</para></listitem>
|
||||
|
||||
<!--
|
||||
WRITER NOTE: The areas to get the kernel and root filesystem are located in the Index of
|
||||
downloads. There are many forms of each. The files that have "rootfs" are just the
|
||||
target root filesystems. The file that is very small and starts with bzImage is just
|
||||
the kernel image isolated so that it can be written to a special on-board area of
|
||||
flash memory. Some systems require this. In the machines directory there are
|
||||
files that combine the kernel image and the root filesystem. These files are the ISO
|
||||
and HDDIMG files. ISO images are designed to be deployed on a DVD or CD. The ISO
|
||||
images are designed to be deployed on a USB stick. There might be some relics in
|
||||
the machine directory. For example, there is the "emenlow-bernard-5.0.0.tar.bz2"
|
||||
file. Nobody seems to know what this is. If a developer needs the image and the
|
||||
root filesystem I think that they want the small kernel image and a matching root
|
||||
filesystem. Although, Paul Eggleton says that the HDDIMG types could be used to
|
||||
develop on. I am not sure that we can use one of those in the ADT though as they
|
||||
want you to point to the kernel image and the target root filesystem. Maybe you
|
||||
could just point to the same spot. I am not sure.
|
||||
-->
|
||||
|
||||
<listitem><para><emphasis>Secure the Linux Yocto Kernel Target Image</emphasis>:
|
||||
You must have a target kernel image that has been built using the Yocto Project.</para>
|
||||
<para>Depending on whether the Yocto Project has a pre-built image that matches your target
|
||||
architecture and where you are going to run the image while you develop your application
|
||||
(QEMU or real hardware), the area you get the image from differs.
|
||||
<itemizedlist>
|
||||
<listitem><para>Download the image from
|
||||
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'>
|
||||
<filename>machines</filename></ulink> if your target architecture is supported
|
||||
and you are going to develop and test your application on actual hardware.
|
||||
</para></listitem>
|
||||
<listitem><para>Download the image from the
|
||||
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu/'>
|
||||
<filename>machines/qemu</filename></ulink> if your target architecture is supported
|
||||
and you are going to develop and test your application using the QEMU
|
||||
emulator.</para></listitem>
|
||||
<listitem><para>Build your image if you cannot find a pre-built image that matches
|
||||
your target architecture.
|
||||
If your target architecture is similar to a supported architecture, you can
|
||||
modify the kernel image before you build it.
|
||||
See the
|
||||
"<link linkend='kernel-modification-workflow'>Kernel Modification Workflow</link>"
|
||||
section earlier in this manual for information on how to create a modified
|
||||
Linux Yocto kernel.</para></listitem>
|
||||
</itemizedlist></para>
|
||||
<para>For information on pre-built kernel image naming schemes for images
|
||||
that can run on the QEMU emulator, see the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
|
||||
section in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
The Yocto Project Quick Start</ulink>.</para></listitem>
|
||||
<listitem><para><emphasis>Install the ADT</emphasis>:
|
||||
The ADT provides a target-specific cross-development toolchain, the root filesystem,
|
||||
the QEMU emulator, and other tools that can help you develop your application.
|
||||
While it is possible to get these pieces separately, the Yocto Project provides an
|
||||
easy method.
|
||||
You can get these pieces by running an ADT installer script, which is configurable.
|
||||
For information on how to install the ADT, see the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-the-adt-installer'>Using the ADT Installer</ulink>" section in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project
|
||||
Application Development (ADT) User's Manual</ulink>.</para></listitem>
|
||||
<listitem><para><emphasis>If Applicable, Secure the Target Root Filesystem</emphasis>:
|
||||
If you choose not to install the ADT using the ADT Installer,
|
||||
you need to find and download the
|
||||
appropriate root filesystems.
|
||||
You can find these tarballs in the same areas used for the kernel images.
|
||||
Depending on the type of image you are running, the root filesystem you need differs.
|
||||
For example, if you are developing an application that runs on an image that
|
||||
supports Sato, you need to get root filesystem that supports Sato.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Create and Build your Application</emphasis>:
|
||||
At this point, you need to have source files for your application.
|
||||
Once you have the files, you can use the Eclipse IDE to import them and build the
|
||||
project.
|
||||
If you are not using Eclipse, you need to use the cross-development tools you have
|
||||
installed to create the image.</para></listitem>
|
||||
<listitem><para><emphasis>Deploy the Image with the Application</emphasis>:
|
||||
If you are using the Eclipse IDE, you can deploy your image to the hardware or to
|
||||
QEMU through the project's preferences.
|
||||
If you are not using the Eclipse IDE, then you need to deploy the application using
|
||||
other methods to the hardware.
|
||||
Or, if you are using QEMU, you need to use that tool and load your image in for testing.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Test and Debug the Application</emphasis>:
|
||||
Once your application is deployed, you need to test it.
|
||||
Within the Eclipse IDE, you can use the debubbing environment along with the
|
||||
set of user-space tools installed along with the ADT to debug your application.
|
||||
Of course, the same user-space tools are available separately to use if you choose
|
||||
not to use the Eclipse IDE.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='workflow-without-adt'>
|
||||
<title>Workflow Without ADT</title>
|
||||
|
||||
<para>
|
||||
If you want to develop an application outside of the Yocto Project ADT environment, you
|
||||
can still employ the cross-development toolchain, the QEMU emulator, and a number of supported
|
||||
target image files.
|
||||
You just need to follow these general steps:
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Install the cross-development toolchain for your target hardware:</emphasis>
|
||||
For information on how to install the toolchain, see the
|
||||
"<ulink url='http://www.yoctoproject/docs/1.1.1/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" section in
|
||||
<ulink url='http://www.yoctoproject/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project
|
||||
Application Development (ADT) User's Manual</ulink>.</para></listitem>
|
||||
<listitem><para><emphasis>Download the Target Image:</emphasis> The Yocto Project supports
|
||||
several target architectures and has many pre-built kernel images and root filesystem
|
||||
images.</para>
|
||||
<para>If you are going to develop your application on hardware, go to the
|
||||
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'>
|
||||
<filename>machines</filename></ulink> download area and choose a target machine area
|
||||
from which to download the kernel image and root filesystem.
|
||||
This download area could have several files in it that support development using
|
||||
actual hardware.
|
||||
For example, the area might contain <filename>.hddimg</filename> files that combine the
|
||||
kernel image with the filesystem, boot loaders, etc.
|
||||
Be sure to get the files you need for your particular development process.</para>
|
||||
<para>If you are going to develop your application and then run and test it using the QEMU
|
||||
emulator, go to the
|
||||
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu/'>
|
||||
<filename>machines/qemu</filename></ulink> download area.
|
||||
From this area, go down into the directory for your target architecture
|
||||
(e.g. <filename>qemux86_64</filename> for an
|
||||
<trademark class='registered'>Intel</trademark>-based 64-bit architecture).
|
||||
Download kernel, root filesystem, and any other files you need for your process.
|
||||
<note>In order to use the root filesystem in QEMU, you need to extract it.
|
||||
See the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>" section for information on how to extract the
|
||||
root filesystem.</note></para></listitem>
|
||||
<listitem><para><emphasis>Develop and Test your Application:</emphasis> At this point,
|
||||
you have the tools to develop your application.
|
||||
If you need to separately install and use the QEMU emulator, you can go to
|
||||
<ulink url='http://www.qemu.org'>QEMU Home Page</ulink> to download and learn about the
|
||||
emulator.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
|
|
|
@ -7,12 +7,12 @@
|
|||
|
||||
<para>
|
||||
This chapter helps you understand the Yocto Project as an open source development project.
|
||||
In general, working in an open-source environment is very different than working in a
|
||||
In general, working in an open source environment is very different as compared to working in a
|
||||
proprietary environment.
|
||||
Additionally, the Yocto Project uses specific tools and constructs as part of its development
|
||||
environment.
|
||||
The chapter specifically addresses open source philosophy, licensing issues, code repositories,
|
||||
the open source distributed version control system Git, and best practices using Yocto Project.
|
||||
the open source distributed version control system Git, and best practices using the Yocto Project.
|
||||
</para>
|
||||
|
||||
<section id='open-source-philosophy'>
|
||||
|
@ -33,23 +33,21 @@
|
|||
stake in the software project.
|
||||
The open source environment contains new copyright, licensing, domain, and consumer issues
|
||||
that differ from the more traditional development environment.
|
||||
In an open source environment the end-product, source material, and documentation are
|
||||
In an open source environment, the end-product, source material, and documentation are
|
||||
all available to the public at no cost.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A benchmark example of an open source project is the Linux Kernel, which was initially conceived
|
||||
and created by Finnish computer science student Linus Torvalds in 1991.
|
||||
Conversely, a good example of a non-open source project is the Windows family of operating
|
||||
systems developed by Microsoft Corporation.
|
||||
Conversely, a good example of a non-open source project is the
|
||||
<trademark class='registered'>Windows</trademark> family of operating
|
||||
systems developed by <trademark class='registered'>Microsoft</trademark> Corporation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Wikipedia has a good historical description of the Open Source Philosophy
|
||||
<ulink url='http://en.wikipedia.org/wiki/Open_source'>here</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can also find helpful information on how to participate in the Linux Community
|
||||
<ulink url='http://ldn.linuxfoundation.org/book/how-participate-linux-community'>here</ulink>.
|
||||
</para>
|
||||
|
@ -66,21 +64,21 @@
|
|||
From the interface, you can click on any particular item in the "Name" column and
|
||||
see the URL at the bottom of the page that you need to set up a Git repository for
|
||||
that particular item.
|
||||
The ability to create Git repositories of the Yocto Project source allows you to
|
||||
Having a local Git repository of the Yocto Project files allows you to
|
||||
make changes, contribute to the history, and ultimately enhance the Yocto Project's
|
||||
tools, Board Support Packages, and so forth.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Conversely, if you are a developer that is not interested in contributing back to the
|
||||
Yocto Project you have the ability to simply download and extract release tarballs
|
||||
Yocto Project, you have the ability to simply download and extract release tarballs
|
||||
and use them within the Yocto Project environment.
|
||||
All that is required is a particular release of Yocto Project, a kernel, and
|
||||
your application source code.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For any supported release of Yocto Project you can go to the Yocto Project website’s
|
||||
For any supported release of Yocto Project, you can go to the Yocto Project website’s
|
||||
<ulink url='http://www.yoctoproject.org/download'>download page</ulink> and get a
|
||||
tarball of the release.
|
||||
You can also go to this site to download any supported BSP tarballs.
|
||||
|
@ -103,12 +101,13 @@
|
|||
<para>
|
||||
<imagedata fileref="figures/source-repos.png" align="center" width="6in" depth="4in" />
|
||||
</para></listitem>
|
||||
<listitem><para><anchor id='index-downloads' /><emphasis><ulink url='http://autobuilder.yoctoproject.org/downloads/'>Index of /downloads:</ulink></emphasis>
|
||||
This area contains an index of the Eclipse-plugin, miscellaneous support, poky, pseudo, and
|
||||
all released versions of Yocto Project in the form of images or tarballs.
|
||||
<listitem><para><anchor id='index-downloads' /><emphasis><ulink url='http://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink></emphasis>
|
||||
This area contains an index releases such as
|
||||
the <trademark class='trade'>Eclipse</trademark>
|
||||
Yocto Plug-in, miscellaneous support, Poky, pseudo, cross-development toolchains,
|
||||
and all released versions of Yocto Project in the form of images or tarballs.
|
||||
Downloading and extracting these files does not produce a Git repository but rather
|
||||
a snapshot of a particular release or image.
|
||||
[WRITER NOTE: link will be http://downloads.yoctoproject.org.]</para>
|
||||
a snapshot of a particular release or image.</para>
|
||||
<para>
|
||||
<imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="4in" />
|
||||
</para></listitem>
|
||||
|
@ -116,7 +115,7 @@
|
|||
This page on the Yocto Project website allows you to download any Yocto Project
|
||||
release or Board Support Package (BSP) in tarball form.
|
||||
The tarballs are similar to those found in the
|
||||
<ulink url='http://autobuilder.yoctoproject.org/downloads/'>Index of /downloads:</ulink> area.</para>
|
||||
<ulink url='http://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink> area.</para>
|
||||
<para>
|
||||
<imagedata fileref="figures/yp-download.png" align="center" width="6in" depth="4in" />
|
||||
</para></listitem>
|
||||
|
@ -130,77 +129,119 @@
|
|||
<para>
|
||||
Following is a list of terms and definitions users new to the Yocto Project development
|
||||
environment might find helpful.
|
||||
Some terms are universal but are included here just in case:
|
||||
While some of these terms are universal, the list includes them just in case:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Image</emphasis> - An image is the result produced when
|
||||
<listitem><para><emphasis>Append Files:</emphasis> Files that append build information to
|
||||
a recipe file.
|
||||
Information in append files override the information in the similarly-named recipe file.
|
||||
Append files use the <filename>.bbappend</filename> filename suffix.</para></listitem>
|
||||
<listitem><para><emphasis>BitBake:</emphasis> The task executor and scheduler used by
|
||||
the Yocto Project to build images.
|
||||
For more information on BitBake, see the <ulink url='http://bitbake.berlios.de/manual/'>
|
||||
BitBake documentation</ulink>.</para></listitem>
|
||||
<listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
|
||||
and inheritance allowing commonly used patterns to be defined once and easily used
|
||||
in multiple recipes.
|
||||
Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem>
|
||||
<listitem><para><emphasis>Configuration File:</emphasis> Configuration information in the
|
||||
<filename>.conf</filename> files provides global definitions of variables.
|
||||
The <filename>conf/local.conf</filename> configuration file in the Yocto Project
|
||||
build directory defines user-defined variables that affect each build.
|
||||
The <filename>distro/poky.conf</filename> configuration file also in the
|
||||
build directory defines Yocto ‘distro’ configuration
|
||||
variables used only when building with this policy.
|
||||
Machine configuration files, which
|
||||
are located throughout the Yocto Project file structure, define
|
||||
variables for specific hardware and are only used when building for that target
|
||||
(e.g. the <filename>machine/beagleboard.conf</filename> configuration file defines
|
||||
variables for the Texas Instruments ARM Cortex-A8 development board).
|
||||
Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem>
|
||||
<listitem><para><emphasis>Cross-Development Toolchain:</emphasis> A collection of software development
|
||||
tools and utilities that allow you to develop software for targeted architectures.
|
||||
This toolchain contains cross-compilers, linkers, and debuggers that are specific to
|
||||
an architecure.
|
||||
You can use the Yocto Project to build cross-development toolchains in tarball form that when
|
||||
unpacked contain the development tools you need to cross-compile and test your software.
|
||||
The Yocto Project ships with images that contain toolchains for supported architectures
|
||||
as well.
|
||||
Sometimes this toolchain is referred to as the meta-toolchain.</para></listitem>
|
||||
<listitem><para><emphasis>Image:</emphasis> An image is the result produced when
|
||||
BitBake processes a given collection of recipes and related metadata.
|
||||
Images are the binary output that runs on specific hardware and for specific
|
||||
use cases.
|
||||
For a list of the supported image types that the Yocto Project provides, see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
|
||||
Reference: Images</ulink> appendix in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
|
||||
appendix in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
The Yocto Project Reference Manual</ulink>.</para></listitem>
|
||||
<listitem><para><emphasis>Recipe</emphasis> - A set of instructions for building packages.
|
||||
A recipe describes where you get source code and which patches to apply.
|
||||
Recipes describe dependencies for libraries or for other recipes and they
|
||||
also contain configuration and compilation options.
|
||||
Recipes contain the logical unit of execution, the software/images to build, and
|
||||
use the <filename>.bb</filename> file extension.</para></listitem>
|
||||
<listitem><para><emphasis>BitBake</emphasis> - The task executor and scheduler used by Yocto Project
|
||||
to build images.
|
||||
For more information on BitBake, see the <ulink url='http://bitbake.berlios.de/manual/'>
|
||||
BitBake documentation</ulink>.</para></listitem>
|
||||
<listitem><para><emphasis>Package</emphasis> - The packaged output from a baked recipe.
|
||||
A package is generally the compiled binaries produced from the recipe's sources.
|
||||
You ‘bake’ something by running it through BitBake.</para></listitem>
|
||||
<listitem><para><emphasis>Layer</emphasis> - A collection of recipes representing the core,
|
||||
<listitem><para><emphasis>Layer:</emphasis> A collection of recipes representing the core,
|
||||
a BSP, or an application stack.</para></listitem>
|
||||
<listitem><para><emphasis>Metadata</emphasis> - A term used throughout the Yocto Project
|
||||
documentation that refers to the files that BitBake parses when building an image.
|
||||
<listitem><para><emphasis>Metadata:</emphasis> The files that BitBake parses when building an image.
|
||||
Metadata includes recipes, classes, and configuration files.</para></listitem>
|
||||
<listitem><para><emphasis>Meta-Toolchain</emphasis> - A collection of software development
|
||||
tools and utilities that allow you to develop software for targeted architectures.
|
||||
These toolchains contain cross-compilers, linkers, and debuggers that are specific to
|
||||
an architecure.
|
||||
You can use the Yocto Project to build meta-toolchains in tarball form that when
|
||||
unpacked contain the development tools you need to cross-compile and test your software.
|
||||
The Yocto Project ships with images that contain toolchains for supported architectures
|
||||
as well.</para></listitem>
|
||||
<listitem><para><emphasis>Configuration File</emphasis>: Configuration information in the
|
||||
<filename>.conf</filename> files provides global definitions of variables.
|
||||
The <filename>build/conf/local.conf</filename> configuration file defines user-defined variables
|
||||
that effect each build.
|
||||
The <filename>distro/poky.conf</filename> configuration file defines Yocto ‘distro’ configuration
|
||||
variables used only when building with this policy.
|
||||
The <filename>machine/beagleboard.conf</filename> configuration file defines variables
|
||||
for the Beagleboard and are only used when building for that target
|
||||
(i.e. Texas Instruments ARM Cortex-A8 development board).
|
||||
Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem>
|
||||
<listitem><para><emphasis>Classes</emphasis> - Files that provide for logic encapsulation
|
||||
and inheritance allowing commonly used patterns to be defined once and easily used
|
||||
in multiple recipes.
|
||||
Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem>
|
||||
<listitem><para><emphasis>Append Files</emphasis> - Files that append build information to
|
||||
a recipe file.
|
||||
Information in append files override the information in the similarly-named recipe file.
|
||||
Append files use the <filename>.bbappend</filename> filename suffix.</para></listitem>
|
||||
<listitem><para><emphasis>Tasks</emphasis> - Arbitrary groups of software Recipes.
|
||||
You simply use Tasks to hold recipes that when built usually accomplish a single task.
|
||||
For example, a task could contain the recipes for a company’s proprietary or value-add software.
|
||||
Or the task could contain the recipes that enable graphics.
|
||||
A task is really just another recipe.
|
||||
Because task files are recipes, they end with the <filename>.bb</filename> filename
|
||||
extension.</para></listitem>
|
||||
<listitem><para><emphasis>OE-Core</emphasis> - A core set of metadata originating
|
||||
<listitem><para><emphasis>OE-Core:</emphasis> A core set of metadata originating
|
||||
with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
|
||||
This metadata is found in the <filename>meta</filename> directory of the Yocto Project
|
||||
files.</para></listitem>
|
||||
<listitem><para><emphasis>Upstream</emphasis> - A reference to source code or repositories
|
||||
<listitem><para><emphasis>Package:</emphasis> The packaged output from a baked recipe.
|
||||
A package is generally the compiled binaries produced from the recipe's sources.
|
||||
You ‘bake’ something by running it through BitBake.</para></listitem>
|
||||
<listitem><para><emphasis>Poky:</emphasis> The build tool that the Yocto Project
|
||||
uses to create images.</para></listitem>
|
||||
<listitem><para><emphasis>Recipe:</emphasis> A set of instructions for building packages.
|
||||
A recipe describes where you get source code and which patches to apply.
|
||||
Recipes describe dependencies for libraries or for other recipes, and they
|
||||
also contain configuration and compilation options.
|
||||
Recipes contain the logical unit of execution, the software/images to build, and
|
||||
use the <filename>.bb</filename> file extension.</para></listitem>
|
||||
<listitem><para><emphasis>Tasks:</emphasis> Arbitrary groups of software Recipes.
|
||||
You simply use Tasks to hold recipes that, when built, usually accomplish a single task.
|
||||
For example, a task could contain the recipes for a company’s proprietary or value-add software.
|
||||
Or, the task could contain the recipes that enable graphics.
|
||||
A task is really just another recipe.
|
||||
Because task files are recipes, they end with the <filename>.bb</filename> filename
|
||||
extension.</para></listitem>
|
||||
<listitem><para><emphasis>Upstream:</emphasis> A reference to source code or repositories
|
||||
that are not local to the development system but located in a master area that is controlled
|
||||
by the maintainer of the source code.
|
||||
For example, in order for a developer to work on a particular piece of code they need to
|
||||
For example, in order for a developer to work on a particular piece of code, they need to
|
||||
first get a copy of it from an "upstream" source.</para></listitem>
|
||||
<listitem><para><emphasis>Yocto Project Files:</emphasis>
|
||||
This term refers to the directory structure created as a result of downloading
|
||||
and unpacking a Yocto Project release tarball or setting up a Git repository
|
||||
by cloning <filename>git://git.yoctoproject.org/poky</filename>.
|
||||
Sometimes the term "the Yocto Project Files structure" is used as well.</para>
|
||||
<para>The Yocto Project files contain BitBake, Documentation, metadata and
|
||||
other files that all support the development environment.
|
||||
Consequently, you must have the Yocto Project files in place on your development
|
||||
system in order to do any development using the Yocto Project.</para>
|
||||
<para>The name of the top-level directory of the Yocto Project file structure
|
||||
is derived from the Yocto Project release tarball.
|
||||
For example, downloading and unpacking <filename>poky-edison-6.0.1.tar.bz2</filename>
|
||||
results in a Yocto Project file structure whose Yocto Project source directory is named
|
||||
<filename>poky-edison-6.0.1</filename>.
|
||||
If you create a Git repository, then you can name the repository anything you like.</para>
|
||||
<para>You can find instruction on how to set up the Yocto Project files on your
|
||||
host development system by reading
|
||||
the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-setup'>Getting
|
||||
Setup</ulink>" section.</para></listitem>
|
||||
<listitem><para><emphasis>Yocto Project Build Directory:</emphasis>
|
||||
This term refers to the area used by the Yocto Project for builds.
|
||||
The area is created when you <filename>source</filename> the Yocto Project setup
|
||||
environment script that is found in the Yocto Project files area.
|
||||
(e.g. <filename>oe-init-build-env</filename>).
|
||||
You can create the Yocto Project build directory anywhere you want on your
|
||||
development system.
|
||||
Here is an example that creates the directory in <filename>mybuilds</filename>
|
||||
and names the Yocto Project build directory <filename>YP-6.0.1</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ source poky-edison-6.0.1/oe-init-build-env $HOME/mybuilds/YP-6.0.1
|
||||
</literallayout>
|
||||
If you don't specifically name the directory, BitBake creates it
|
||||
in the current directory and uses the name <filename>build</filename>.
|
||||
Also, if you supply an existing directory, then BitBake uses that
|
||||
directory as the Yocto Project build directory and populates the build hierarchy
|
||||
beneath it.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -209,9 +250,9 @@
|
|||
<title>Licensing</title>
|
||||
|
||||
<para>
|
||||
Because open source projects are open to the public they have different licensing structures in place.
|
||||
Because open source projects are open to the public, they have different licensing structures in place.
|
||||
License evolution for both Open Source and Free Software has an interesting history.
|
||||
If you are interested in the history you can find basic information here:
|
||||
If you are interested in this history, you can find basic information here:
|
||||
<itemizedlist>
|
||||
<listitem><para><ulink url='http://en.wikipedia.org/wiki/Open-source_license'>Open source license history</ulink>
|
||||
</para></listitem>
|
||||
|
@ -236,14 +277,19 @@
|
|||
<para>
|
||||
When you build an image using Yocto Project, the build process uses a known list of licenses to
|
||||
ensure compliance.
|
||||
Once the build completes, the list of all licenses found and used during the build are
|
||||
kept in the resulting build directory at
|
||||
<filename><build_directory>/tmp/deploy/images/licenses</filename>.
|
||||
You can find this list in the Yocto Project files directory at
|
||||
<filename>meta/files/common-licenses</filename>.
|
||||
Once the build completes, the list of all licenses found and used during that build are
|
||||
kept in the Yocto Project build directory at
|
||||
<filename>tmp/deploy/images/licenses</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If a module requires a license that is not in the base list, the build process
|
||||
generates a warning during the build.
|
||||
These tools make it easier for a developer to be certain of the licenses with which
|
||||
their shipped products must comply.
|
||||
However, it is still up to the developer to resolve potential licensing issues.
|
||||
However, even with these tools it is still up to the developer to resolve potential licensing issues.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -254,14 +300,13 @@
|
|||
for a standard format for communicating the components, licenses, and copyrights
|
||||
associated with a software package.
|
||||
<ulink url='http://opensource.org'>OSI</ulink> is a corporation dedicated to the Open Source
|
||||
Definition and the effort for reviewing
|
||||
and approving licenses that are OSD-conformant.
|
||||
Definition and the effort for reviewing and approving licenses that are OSD-conformant.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can find a list of the combined SPDX and OSI licenses that the Yocto Project uses
|
||||
<ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>.
|
||||
The wiki page discusses the license infrastructure used by the Yocto Project.
|
||||
This wiki page discusses the license infrastructure used by the Yocto Project.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -282,7 +327,7 @@
|
|||
You do not have to be an expert in Git to be functional.
|
||||
A good place to look for instruction on a minimal set of Git commands is
|
||||
<ulink url='http://git-scm.com/documentation'>here</ulink>.
|
||||
If you need to download Git you can do so
|
||||
If you need to download Git, you can do so
|
||||
<ulink url='http://git-scm.com/download'>here</ulink>.
|
||||
</para>
|
||||
|
||||
|
@ -294,7 +339,7 @@
|
|||
This methodology also allows for an environment in which you can do lots of
|
||||
experimentation on your project as you develop changes or new features.
|
||||
For example, you can create a “branch”, experiment with some feature, and then
|
||||
if you like the feature you incorporate the branch into the tree.
|
||||
if you like the feature, you incorporate the branch into the tree.
|
||||
If you don’t, you cut the branch off by deleting it.
|
||||
</para>
|
||||
|
||||
|
@ -309,55 +354,63 @@
|
|||
omits the many arguments they support.
|
||||
See the Git documentation for complete descriptions and strategies on how to use these commands:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis><filename>git init</filename></emphasis> – Initializes an empty Git repository.
|
||||
<listitem><para><emphasis><filename>git init</filename>:</emphasis> Initializes an empty Git repository.
|
||||
You cannot use Git commands unless you have a <filename>.git</filename> repository.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git clone</filename></emphasis> – Creates a clone of a repository.
|
||||
During collaboration this command allows you to create a local repository that is on
|
||||
<listitem><para><emphasis><filename>git clone</filename>:</emphasis> Creates a clone of a repository.
|
||||
During collaboration, this command allows you to create a local repository that is on
|
||||
equal footing with a fellow developer’s repository.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git add</filename></emphasis> – Adds updated file contents to the index that
|
||||
<listitem><para><emphasis><filename>git add</filename>:</emphasis> Adds updated file contents
|
||||
to the index that
|
||||
Git uses to track changes.
|
||||
All files that have changed must be added before they can be committed.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git commit</filename></emphasis> – Creates a “commit” that documents
|
||||
You must add all files that have changed before you can commit them.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git commit</filename>:</emphasis> Creates a “commit” that documents
|
||||
the changes you made.
|
||||
Commits are used for historical purposes, for determining if a maintainer of a project
|
||||
will allow the change, and for ultimately pushing the change from your local Git repository
|
||||
into the project’s upstream (or master) repository.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git status</filename></emphasis> – Reports any modified files that
|
||||
<listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that
|
||||
possibly need added and committed.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git checkout <branch-name></filename></emphasis> - Changes
|
||||
your working branch. This command is analogous to “cd”.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git checkout –b <working-branch></filename></emphasis> - Creates
|
||||
<listitem><para><emphasis><filename>git checkout <branch-name></filename>:</emphasis> Changes
|
||||
your working branch.
|
||||
This command is analogous to “cd”.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git checkout –b <working-branch></filename>:</emphasis> Creates
|
||||
a working branch on your local machine where you can isolate work.
|
||||
It is a good idea to use local branches when adding specific features or changes.
|
||||
This way if you don’t like what you have done you can easily get rid of the work.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git branch</filename></emphasis> – Reports existing branches and
|
||||
<listitem><para><emphasis><filename>git branch</filename>:</emphasis> Reports existing branches and
|
||||
tells you which branch in which you are currently working.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git branch -D <branch-name></filename></emphasis> –
|
||||
Deletes an existing branch. You need to be in a branch other than the one you are deleting
|
||||
<listitem><para><emphasis><filename>git branch -D <branch-name></filename>:</emphasis>
|
||||
Deletes an existing branch.
|
||||
You need to be in a branch other than the one you are deleting
|
||||
in order to delete <branch-name>.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git pull</filename></emphasis> – Retrieves information from an upstream Git
|
||||
<listitem><para><emphasis><filename>git pull</filename>:</emphasis> Retrieves information
|
||||
from an upstream Git
|
||||
repository and places it in your local Git repository.
|
||||
You use this command to make sure you are synchronized with the upstream repository
|
||||
from which the project’s maintainer uses to pull changes into the master repository.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git push</filename></emphasis> – Sends all your local changes you
|
||||
have committed to an upstream Git repository.
|
||||
You use this command to make sure you are synchronized with the repository
|
||||
from which you are basing changes (.e.g. the master repository).</para></listitem>
|
||||
<listitem><para><emphasis><filename>git push</filename>:</emphasis> Sends all your local changes you
|
||||
have committed to an upstream Git repository (e.g. a contribution repository).
|
||||
The maintainer of the project draws from these repositories when adding your changes to the
|
||||
project’s master repository.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git merge</filename></emphasis> – Combines or adds changes from one
|
||||
<listitem><para><emphasis><filename>git merge</filename>:</emphasis> Combines or adds changes from one
|
||||
local branch of your repository with another branch.
|
||||
When you create a local Git repository the default branch is named “master”.
|
||||
When you create a local Git repository, the default branch is named “master”.
|
||||
A typical workflow is to create a temporary branch for isolated work, make and commit your
|
||||
changes, switch to the master branch, merge the changes from the temporary branch into the
|
||||
master branch, and then delete the temporary branch</para></listitem>
|
||||
<listitem><para><emphasis><filename>git cherry-pick</filename></emphasis> – Choose and apply specific
|
||||
changes, switch to your local master branch, merge the changes from the temporary branch into the
|
||||
local master branch, and then delete the temporary branch.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git cherry-pick</filename>:</emphasis> Choose and apply specific
|
||||
commits from one branch into another branch.
|
||||
There are times when you might not be able to merge all the changes in one branch with
|
||||
another but need to pick out certain ones.</para></listitem>
|
||||
<listitem><para><emphasis><filename>gitk</filename></emphasis> – Provides a GUI view of the branches
|
||||
<listitem><para><emphasis><filename>gitk</filename>:</emphasis> Provides a GUI view of the branches
|
||||
and changes in your local Git repository.
|
||||
This command is a good way to see where things have diverged in your local repository.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git log</filename></emphasis> – Reports a history of your changes to the
|
||||
This command is a good way to graphically see where things have diverged in your
|
||||
local repository.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git log</filename>:</emphasis> Reports a history of your changes to the
|
||||
repository.</para></listitem>
|
||||
<listitem><para><emphasis><filename>git diff</filename>:</emphasis> Displays line-by-line differences
|
||||
between your local working files and the same files in the upstream Git repository that your
|
||||
branch currently tracks.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -369,17 +422,22 @@
|
|||
This section provides some overview on workflows using Git.
|
||||
In particular, the information covers basic practices that describe roles and actions in a
|
||||
collaborative development environment.
|
||||
Again, if you are familiar with this type of development environment you might want to just skip the section.
|
||||
Again, if you are familiar with this type of development environment, you might want to just
|
||||
skip the section.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Yocto Project files are maintained using Git in a "master" branch whose Git history
|
||||
tracks every change and whose structure provides branches for all diverging functionality.
|
||||
Although there is no need to use Git, This practice is typical for open-source projects.
|
||||
For the Yocto Project a key individual called the "maintainer" is responsible for "master".
|
||||
Although there is no need to use Git, many open source projects do so.
|
||||
For the Yocto Project, a key individual called the "maintainer" is responsible for the "master"
|
||||
branch of the Git repository.
|
||||
The "master" branch is the “upstream” repository where the final builds of the project occur.
|
||||
The maintainer is responsible for allowing changes in from other developers and for
|
||||
organizing the underlying branch structure to reflect release strategies and so forth.
|
||||
<note>You can see who is the maintainer for Yocto Project files by examining the
|
||||
<filename>distro_tracking_fields</filename> file in the Yocto Project
|
||||
<filename>meta/conf/distro/include</filename> directory.</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -394,7 +452,7 @@
|
|||
Developers (including contributing community members) create and maintain cloned repositories
|
||||
of the upstream "master" branch.
|
||||
These repositories are local to their development platforms and are used to develop changes.
|
||||
When a developer is satisfied with a particular feature or change they “push” the changes
|
||||
When a developer is satisfied with a particular feature or change, they “push” the changes
|
||||
to the appropriate "contrib" repository.
|
||||
</para>
|
||||
|
||||
|
@ -428,41 +486,41 @@
|
|||
While each development environment is unique, there are some best practices or methods
|
||||
that help development run smoothly.
|
||||
The following list describes some of these practices.
|
||||
For more detailed information about these strategies see
|
||||
<ulink url='http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html'>Git Workflows</ulink>.
|
||||
For more information about Git workflows, see the workflow topics in the
|
||||
<ulink url='http://book.git-scm.com'>Git Community Book</ulink>.
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Make Small Changes</emphasis> - It is best to keep your changes you commit
|
||||
<listitem><para><emphasis>Make Small Changes:</emphasis> It is best to keep your changes you commit
|
||||
small as compared to bundling many disparate changes into a single commit.
|
||||
This practice not only keeps things manageable but also allows the maintainer
|
||||
to more easily include or refuse changes.</para>
|
||||
<para>It is also good practice to leave the repository in a state that allows you to
|
||||
still successfully build your project.</para></listitem>
|
||||
<listitem><para><emphasis>Use Branches Liberally</emphasis> - It is very easy to create, use, and
|
||||
<listitem><para><emphasis>Use Branches Liberally:</emphasis> It is very easy to create, use, and
|
||||
delete local branches in your working Git repository.
|
||||
You can name these branches anything you like.
|
||||
It is helpful to give them names associated with the particular feature or change
|
||||
on which you are working.
|
||||
Once you are done with a feature or change you simply discard the branch.</para></listitem>
|
||||
<listitem><para><emphasis>Merge Changes</emphasis> - The <filename>git merge</filename>
|
||||
Once you are done with a feature or change, simply discard the branch.</para></listitem>
|
||||
<listitem><para><emphasis>Merge Changes:</emphasis> The <filename>git merge</filename>
|
||||
command allows you to take the
|
||||
changes from one branch and fold them into another branch.
|
||||
This process is especially helpful when more than a single developer might be working
|
||||
on different parts of the same feature.
|
||||
Merging changes also automatically identifies any collisions or “conflicts”
|
||||
that might happen resulting from the same lines of code being altered by two different
|
||||
that might happen as a result of the same lines of code being altered by two different
|
||||
developers.</para></listitem>
|
||||
<listitem><para><emphasis>Manage Branches</emphasis> - Because branches are easy to use, you should
|
||||
<listitem><para><emphasis>Manage Branches:</emphasis> Because branches are easy to use, you should
|
||||
use a system where branches indicate varying levels of code readiness.
|
||||
For example, you can have a “work” branch to develop in, a “test” branch where the code or
|
||||
change is tested, a “stage” branch where changes are ready to be committed, and so forth.
|
||||
As your project develops, you can merge code across the branches to reflect ever-increasing
|
||||
stable states of the development.</para></listitem>
|
||||
<listitem><para><emphasis>Use Push and Pull</emphasis> - The push-pull workflow is based on the
|
||||
<listitem><para><emphasis>Use Push and Pull:</emphasis> The push-pull workflow is based on the
|
||||
concept of developers “pushing” local commits to a remote repository, which is
|
||||
usually a contribution repository.
|
||||
It is also based on the developers “pulling” known states of the project down into their
|
||||
This workflow is also based on developers “pulling” known states of the project down into their
|
||||
local development repositories.
|
||||
This workflow easily allows you to pull changes submitted by other developers from the
|
||||
The workflow easily allows you to pull changes submitted by other developers from the
|
||||
upstream repository into your work area ensuring that you have the most recent software
|
||||
on which to develop.
|
||||
The Yocto Project has two scripts named <filename>create-pull-request</filename> and
|
||||
|
@ -470,7 +528,7 @@
|
|||
workflow.
|
||||
You can find these scripts in the local Yocto Project files Git repository in
|
||||
<filename>scripts</filename>.</para></listitem>
|
||||
<listitem><para><emphasis>Patch Workflow</emphasis> - This workflow allows you to notify the
|
||||
<listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the
|
||||
maintainer through an email that you have a change (or patch) you would like considered
|
||||
for the "master" branch of the Git repository.
|
||||
To send this type of change you format the patch and then send the email using the Git commands
|
||||
|
@ -484,44 +542,59 @@
|
|||
<title>Tracking Bugs</title>
|
||||
|
||||
<para>
|
||||
The Yocto Project uses <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.
|
||||
This bug-tracking application works well for group development because it tracks bugs and code
|
||||
The Yocto Project uses its own implementation of
|
||||
<ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.
|
||||
Implementations of Bugzilla work well for group development because they track bugs and code
|
||||
changes, can be used to communicate changes and problems with developers, can be used to
|
||||
submit and review patches, and can be used to manage quality assurance.
|
||||
You can find a good overview of Bugzilla <ulink url='http://www.bugzilla.org/about/'>here</ulink>.
|
||||
The home page for the Yocto Project implementation of Bugzilla is
|
||||
<ulink url='http://bugzilla.yoctoproject.org'>http://bugzilla.yoctoproject.org</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Sometimes it is helpful to submit, investigate, or track a bug against the Yocto Project itself
|
||||
such as when discovering an issue with some component of the build system that acts contrary
|
||||
to the documentation or expectations.
|
||||
You can find information
|
||||
for Bugzilla configuration and bug tracking procedures specific to the Yocto Project
|
||||
to the documentation or your expectations.
|
||||
Following is the general procedure for submitting a new bug using the Yocto Project
|
||||
Bugzilla.
|
||||
You can find more information on defect management, bug tracking, and feature request
|
||||
processes all accomplished through the Yocto Project Bugzilla on the wiki page
|
||||
<ulink url='https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking'>here</ulink>.
|
||||
<orderedlist>
|
||||
<listitem><para>Always use the Yocto Project implementation of Bugzilla to submit
|
||||
a bug.</para></listitem>
|
||||
<listitem><para>When submitting a new bug, be sure to choose the appropriate
|
||||
Classification, Product, and Component for which the issue was found.
|
||||
Defects for Yocto Project fall into one of four classifications: Yocto Projects,
|
||||
Infrastructure, Poky, and Yocto Metadata Layers.
|
||||
Each of these Classifications break down into multiple Products and, in some
|
||||
cases, multiple Components.</para></listitem>
|
||||
<listitem><para>Use the bug form to choose the correct Hardware and Architecture
|
||||
for which the bug applies.</para></listitem>
|
||||
<listitem><para>Indicate the Yocto Project version you were using when the issue
|
||||
occurred.</para></listitem>
|
||||
<listitem><para>Be sure to indicate the Severity of the bug.
|
||||
Severity communicates how the bug impacted your work.</para></listitem>
|
||||
<listitem><para>Provide a brief summary of the issue.
|
||||
Try to limit your summary to just a line or two and be sure to capture the
|
||||
essence of the issue.</para></listitem>
|
||||
<listitem><para>Provide a detailed description of the issue.
|
||||
You should provide as much detail as you can about the context, behavior, output,
|
||||
and so forth that surround the issue.
|
||||
You can even attach supporting files for output or log by using the "Add an attachment"
|
||||
button.</para></listitem>
|
||||
<listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Yocto Project uses its own version of the Bugzilla application.
|
||||
You can find the home page <ulink url='http://bugzilla.yoctoproject.org'>here</ulink>.
|
||||
You need to use this implementation of Bugzilla when logging a defect against anything released
|
||||
by the Yocto Project team.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here are some things to remember when dealing with bugs against the Yocto Project:
|
||||
<itemizedlist>
|
||||
<listitem><para>The Yocto Project follows a naming bug-naming convention:
|
||||
<note>
|
||||
Bugs in the Yocto Project Bugzilla follow naming convention:
|
||||
<filename>[YOCTO #<number>]</filename>, where <filename><number></filename> is the
|
||||
assigned defect ID used in Bugzilla.
|
||||
So, for example, a valid way to refer to a defect when creating a commit comment
|
||||
would be <filename>[YOCTO 1011]</filename>.
|
||||
So, for example, a valid way to refer to a defect would be <filename>[YOCTO #1011]</filename>.
|
||||
This convention becomes important if you are submitting patches against the Yocto Project
|
||||
code itself.
|
||||
See the following section for more information.</para></listitem>
|
||||
<listitem><para>Defects for Yocto Project fall into one of four classifications: Yocto Projects,
|
||||
Infrastructure, Poky, and Yocto Metadata Layers.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section id='how-to-submit-a-change'>
|
||||
|
@ -529,9 +602,35 @@
|
|||
|
||||
<para>
|
||||
Contributions to the Yocto Project are very welcome.
|
||||
You should send patches to the Yocto Project mailing list to get it in front of the
|
||||
Yocto Project Maintainer.
|
||||
When you send your patch, be sure to include a "signed-off-by:"
|
||||
You should send patches to the appropriate Yocto Project mailing list to get them
|
||||
in front of the Yocto Project Maintainer.
|
||||
For a list of the Yocto Project mailing lists, see the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#resources-mailinglist'>Mailing lists</ulink>" section in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'> The
|
||||
Yocto Project Reference Manual</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Following is some guidance on which mailing list to use for what type of defect:
|
||||
<itemizedlist>
|
||||
<listitem><para>For defects against the Yocto Project build system Poky, send
|
||||
your patch to the
|
||||
<ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> mailing list.
|
||||
This mailing list corresponds to issues that are not specific to the Yocto Project but
|
||||
are part of the OE-core.
|
||||
For example, a defect against anything in the <filename>meta</filename> layer
|
||||
or the BitBake Manual could be sent to this mailing list.</para></listitem>
|
||||
<listitem><para>For defects against Yocto-specific layers, tools, and Yocto Project
|
||||
documentation use the
|
||||
<ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> mailing list.
|
||||
This mailing list corresponds to Yocto-specific areas such as
|
||||
<filename>meta-yocto</filename>, <filename>meta-intel</filename>,
|
||||
<filename>linux-yocto</filename>, and <filename>documentation</filename>.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When you send a patch, be sure to include a "signed-off-by:"
|
||||
line in the same style as required by the Linux kernel.
|
||||
Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1
|
||||
as follows:
|
||||
|
@ -573,15 +672,45 @@
|
|||
<para>
|
||||
In a collaborative environment, it is necessary to have some sort of standard
|
||||
or method through which you submit changes.
|
||||
Otherwise, things would get quite chaotic.
|
||||
Otherwise, things could get quite chaotic.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When you submit a change or patch to the Yocto Project, you must follow certain procedures.
|
||||
In particular, the headers in patches and the commit messages must follow a certain standard.
|
||||
The general process is the same as described earlier in this chapter.
|
||||
For complete details on how to create proper commit messages and patch headers see
|
||||
[WRITER NOTE: I need the link to Mark's wiki page here that describes the process.]
|
||||
When you form a commit, you must follow certain standards established by the
|
||||
Yocto Project development team.
|
||||
For each commit, you must provide a single-line summary of the change and you
|
||||
almost always provide a more detailed description of what you did (i.e. the body
|
||||
of the commit).
|
||||
The only exceptions for not providing a detailed description would be if your
|
||||
change is a simple, self-explanatory change that needs no description.
|
||||
Here are the Yocto Project commit message guidelines:
|
||||
<itemizedlist>
|
||||
<listitem><para>Provide a single-line, short summary of the change.
|
||||
This summary is typically viewable by source control systems.
|
||||
Thus, providing something short and descriptive that gives the reader
|
||||
a summary of the change is useful when viewing a list of many commits.
|
||||
</para></listitem>
|
||||
<listitem><para>For the body of the commit message, provide detailed information
|
||||
that describes what you changed, why you made the change, and the approach
|
||||
you used.
|
||||
Provide as much detail as you can in the body of the commit message.
|
||||
</para></listitem>
|
||||
<listitem><para>If the change addresses a specific bug or issue that is
|
||||
associated with a bug-tracking ID, prefix your detailed description
|
||||
with the bug or issue ID.
|
||||
For example, the Yocto Project tracks bugs using a bug-naming convention.
|
||||
Any commits that address a bug must start with the bug ID in the description
|
||||
as follows:
|
||||
<literallayout class='monospaced'>
|
||||
YOCTO #<bug-id>: <Detailed description of commit>
|
||||
</literallayout></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can find more guidance on creating well-formed commit messages at this OpenEmbedded
|
||||
wiki page:
|
||||
<ulink url='http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines'></ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -589,7 +718,7 @@
|
|||
</para>
|
||||
|
||||
<section id='pushing-a-change-upstream'>
|
||||
<title>Pushing a Change Upstream</title>
|
||||
<title>Pushing a Change Upstream and Requesting a Pull</title>
|
||||
|
||||
<para>
|
||||
The basic flow for pushing a change to an upstream "contrib" Git repository is as follows:
|
||||
|
@ -598,41 +727,89 @@
|
|||
<listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
|
||||
command.</para></listitem>
|
||||
<listitem><para>Commit the change by using the <filename>git commit</filename>
|
||||
command and push it to the upstream "contrib" repository.
|
||||
Be sure to provide a commit message that follows the project’s commit standards.</para></listitem>
|
||||
<listitem><para>Notify the maintainer that you have pushed a change.</para></listitem>
|
||||
command and push it to the "contrib" repository.
|
||||
Be sure to provide a commit message that follows the project’s commit standards
|
||||
as described earlier.</para></listitem>
|
||||
<listitem><para>Notify the maintainer that you have pushed a change by making a pull
|
||||
request.
|
||||
The Yocto Project provides two scripts that conveniently let you generate and send
|
||||
pull requests to the Yocto Project.
|
||||
These scripts are <filename>create-pull-request</filename> and
|
||||
<filename>send-pull-request</filename>.
|
||||
You can find these scripts in the <filename>scripts</filename> directory of the
|
||||
Yocto Project file structure.</para>
|
||||
<para>For help on using these scripts, simply provide the
|
||||
<filename>--help</filename> argument as follows:
|
||||
<literallayout class='monospaced'>
|
||||
$ ~/poky/scripts/create-pull-request --help
|
||||
$ ~/poky/scripts/send-pull-request --help
|
||||
</literallayout></para></listitem>
|
||||
</itemizedlist>
|
||||
You can find general Git information on how to push a change upstream
|
||||
<ulink url='http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#Developing-With-git'>
|
||||
here</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can find general Git information on how to push a change upstream in the
|
||||
<ulink url='http://book.git-scm.com/3_distributed_workflows.html'>Git Community Book</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='submitting-a-patch'>
|
||||
<title>Submitting a Patch</title>
|
||||
<title>Submitting a Patch Through Email</title>
|
||||
|
||||
<para>
|
||||
If you have a just a few changes you can commit them and then submit them as an email to the maintainer.
|
||||
If you have a just a few changes, you can commit them and then submit them as an
|
||||
email to the maintainer.
|
||||
Here is a general procedure:
|
||||
<itemizedlist>
|
||||
<listitem><para>Make your changes in your local Git repository.</para></listitem>
|
||||
<listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
|
||||
command.</para></listitem>
|
||||
<listitem><para>Commit the change by using the <filename>git commit</filename> command.
|
||||
Be sure to provide a commit message that follows the project’s commit standards.</para></listitem>
|
||||
<listitem><para>Format the commit by using the <filename>git format-patch</filename>
|
||||
command.
|
||||
This step produces a numbered series of files in the current directory – one for
|
||||
each commit.</para></listitem>
|
||||
<listitem><para>Commit the change by using the
|
||||
<filename>git commit --signoff</filename> command.
|
||||
Using the <filename>--signoff</filename> option identifies you as the person
|
||||
making the change and also satisfies the Developer's Certificate of
|
||||
Origin (DCO) shown earlier.</para>
|
||||
<para>When you form a commit you must follow certain standards established by the
|
||||
Yocto Project development team.
|
||||
See the earlier section
|
||||
"<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
|
||||
for Yocto Project commit message standards.</para></listitem>
|
||||
<listitem><para>Format the commit into an email messsage.
|
||||
To format commits, use the <filename>git format-patch</filename> command.
|
||||
When you provide the command, you must include a revision list or a number of patches
|
||||
as part of the command.
|
||||
For example, these two commands each take the most recent single commit and
|
||||
format it as an email message in the current directory:
|
||||
<literallayout class='monospaced'>
|
||||
$ git format-patch -1
|
||||
$ git format-patch HEAD~
|
||||
</literallayout></para>
|
||||
<para>After the command is run, the current directory contains a
|
||||
numbered <filename>.patch</filename> file for the commit.</para>
|
||||
<para>If you provide several commits as part of the command,
|
||||
the <filename>git format-patch</filename> command produces a numbered
|
||||
series of files in the current directory – one for each commit.
|
||||
For information on the <filename>git format-patch</filename> command,
|
||||
see <filename>GIT_FORMAT_PATCH(1)</filename> displayed using the
|
||||
<filename>man git-format-patch</filename> command.</para></listitem>
|
||||
<listitem><para>Import the files into your mail client by using the
|
||||
<filename>git-send-email</filename> command.</para></listitem>
|
||||
<listitem><para>Send the email by hand to the maintainer.</para></listitem>
|
||||
<filename>git send-email</filename> command.
|
||||
<note>In order to use <filename>git send-email</filename>, you must have the
|
||||
the proper Git packages installed.
|
||||
For Ubuntu and Fedora the package is <filename>git-email</filename>.</note></para>
|
||||
<para>The <filename>git send-email</filename> command sends email by using a local
|
||||
or remote Mail Transport Agent (MTA) such as
|
||||
<filename>msmtp</filename>, <filename>sendmail</filename>, or through a direct
|
||||
<filename>smtp</filename> configuration in your Git <filename>config</filename>
|
||||
file.</para>
|
||||
<para>The <filename>git send-email</filename> command is the preferred method
|
||||
for sending your patches since there is no risk of compromising whitespace
|
||||
in the body of the message, which can occur when you use your own mail client.
|
||||
The command also has several options that let you
|
||||
specify recipients and perform further editing of the email message.
|
||||
For information on how to use the <filename>git send-email</filename> command,
|
||||
use the <filename>man git-send-email</filename> command.</para></listitem>
|
||||
</itemizedlist>
|
||||
Be aware that there could be protocols and standards that you need to follow for your particular
|
||||
project.
|
||||
You can find general Git information for submitting a patch
|
||||
<ulink url='http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#sharing-development'>
|
||||
here</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
@ -7,16 +7,15 @@
|
|||
|
||||
<para>
|
||||
This chapter introduces the Yocto Project and gives you an idea of what you need to get started.
|
||||
You can find enough information to set your development host up and build or use images for
|
||||
hardware supported by the Yocto Project by reading the
|
||||
<ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html'>
|
||||
Yocto Project Quick Start</ulink> located on the <ulink url='http://www.yoctoproject.org'>
|
||||
Yocto Project website</ulink>.
|
||||
You can find enough information to set up your development host and build or use images for
|
||||
hardware supported by the Yocto Project by reading
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
The Yocto Project Quick Start</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The remainder of this chapter summarizes what is in the Yocto Project Quick Start and provides
|
||||
some higher level concepts you might want to consider.
|
||||
some higher-level concepts you might want to consider.
|
||||
</para>
|
||||
|
||||
<section id='introducing-the-yocto-project'>
|
||||
|
@ -24,8 +23,8 @@
|
|||
|
||||
<para>
|
||||
The Yocto Project is an open-source collaboration project focused on embedded Linux development.
|
||||
The project currently provides a build system and various ancillary tools suitable for the
|
||||
embedded developer.
|
||||
The project currently provides a build system, which is sometimes referred to as "Poky",
|
||||
and provides various ancillary tools suitable for the embedded developer.
|
||||
The Yocto Project also features the Sato reference User Interface, which is optimized for
|
||||
stylus driven, low-resolution screens.
|
||||
</para>
|
||||
|
@ -37,7 +36,8 @@
|
|||
While the Yocto Project does not provide a strict testing framework,
|
||||
it does provide or generate for you artifacts that let you perform target-level and
|
||||
emulated testing and debugging.
|
||||
And, if you are an Eclipse user, you can install an Eclipse Yocto Plug-in to allow you to
|
||||
And, if you are an <trademark class='trade'>Eclipse</trademark>
|
||||
IDE user, you can install an Eclipse Yocto Plug-in to allow you to
|
||||
develop within that familiar environment.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -51,103 +51,102 @@
|
|||
<listitem><para><emphasis>Host System:</emphasis> You should have a reasonably current
|
||||
Linux-based host system.
|
||||
You will have the best results with a recent release of Fedora,
|
||||
OpenSUSE, or Ubuntu as these releases are frequently tested and officially supported
|
||||
host systems.
|
||||
OpenSUSE, or Ubuntu as these releases are frequently tested against the Yocto Project
|
||||
and officially supported.
|
||||
You should also have about 100 gigabytes of free disk space for building images.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Packages:</emphasis> The Yocto Project requires certain packages
|
||||
exist on your development system (e.g. Python 2.6 or 2.7).
|
||||
See <ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html#packages'>
|
||||
The Packages</ulink> section in the Yocto Project Quick start for the exact package
|
||||
requirements and the installation commands for the supported distributions.</para></listitem>
|
||||
See "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>"
|
||||
section in the Yocto Project Quick start for the exact package
|
||||
requirements and the installation commands to install them
|
||||
for the supported distributions.</para></listitem>
|
||||
<listitem id='local-yp-release'><para><emphasis>Yocto Project Release:</emphasis>
|
||||
You need a release of the Yocto Project.
|
||||
You can get set up with local Yocto Project files one of two ways depending on whether you
|
||||
are going to be contributing back into the Yocto Project source repository or not.
|
||||
<note>
|
||||
Regardless of the method you use, this manual will refer to the resulting
|
||||
hierarchical set of files as "the local Yocto Project files."
|
||||
Regardless of the method you use, this manual refers to the resulting
|
||||
hierarchical set of files as "the Yocto Project files" or "the Yocto Project file
|
||||
structure."
|
||||
</note>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Tarball Extraction:</emphasis> If you are not going to contribute
|
||||
back into the Yocto Project you can simply download the Yocto Project release you want
|
||||
back into the Yocto Project, you can simply download the Yocto Project release you want
|
||||
from the website’s <ulink url='http://yoctoproject.org/download'>download page</ulink>.
|
||||
Once you have the tarball, just extract it into a directory of your choice.</para>
|
||||
|
||||
<para>For example, the following command extracts the Yocto Project 1.1 release tarball
|
||||
into the current working directory and sets up a file structure whose top-level
|
||||
directory is named <filename>poky-1.1</filename>:
|
||||
<para>For example, the following command extracts the Yocto Project 1.1.1 release tarball
|
||||
into the current working directory and sets up the Yocto Project file structure
|
||||
with a top-level directory named <filename>poky-edison-6.0.1</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ tar xfj poky-1.1.tar.bz2
|
||||
$ tar xfj poky-edison-6.0.1.tar.bz2
|
||||
</literallayout></para>
|
||||
<para>This method does not produce a <filename>poky</filename> Git repository.
|
||||
You end up simply with a local snapshot of Yocto Project files that are based on the
|
||||
particular release in the tarball.</para></listitem>
|
||||
<para>This method does not produce a Git repository.
|
||||
Instead, you simply end up with a local snapshot of the
|
||||
Yocto Project files that are based on the particular release in the
|
||||
tarball.</para></listitem>
|
||||
<listitem><para><emphasis>Git Repository Method:</emphasis> If you are going to be contributing
|
||||
back into the Yocto Project you should use Git commands to set up a local
|
||||
<filename>poky</filename> Git repository of the Yocto Project.
|
||||
back into the Yocto Project, you should use Git commands to set up a local
|
||||
Git repository of the Yocto Project files.
|
||||
Doing so creates a Git repository with a complete history of changes and allows
|
||||
you to easily submit your changes upstream to the project.</para>
|
||||
|
||||
<para>The following transcript shows how to clone the <filename>poky</filename>
|
||||
<para>The following transcript shows how to clone the Yocto Project files'
|
||||
Git repository into the current working directory.
|
||||
The command creates the repository in a directory named <filename>poky</filename>.
|
||||
For information on the Yocto Project and Git, see
|
||||
<xref linkend='git'>Git</xref> in
|
||||
<xref linkend='dev-manual-newbie'>Working with Open Source Code</xref>.
|
||||
For information on the Yocto Project and Git, see the
|
||||
"<link linkend='git'>Git</link>" section.
|
||||
<literallayout class='monospaced'>
|
||||
$ git clone git://git.yoctoproject.org/poky
|
||||
Initialized empty Git repository in /home/scottrif/poky/.git/
|
||||
remote: Counting objects: 107624, done.
|
||||
remote: Compressing objects: 100% (37128/37128), done.
|
||||
remote: Total 107624 (delta 73393), reused 99851 (delta 67287)
|
||||
Receiving objects: 100% (107624/107624), 69.74 MiB | 483 KiB/s, done.
|
||||
Resolving deltas: 100% (73393/73393), done.
|
||||
</literallayout></para>
|
||||
|
||||
<para>For another example of how to set up your own local Git repositories see this
|
||||
remote: Counting objects: 116882, done.
|
||||
remote: Compressing objects: 100% (35987/35987), done.
|
||||
remote: Total 116882 (delta 80651), reused 113045 (delta 77578)
|
||||
Receiving objects: 100% (116882/116882), 72.13 MiB | 2.68 MiB/s, done.
|
||||
Resolving deltas: 100% (80651/80651), done. </literallayout></para>
|
||||
<para>For another example of how to set up your own local Git repositories, see this
|
||||
<ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
|
||||
wiki page</ulink>, which describes how to create both <filename>poky</filename>
|
||||
and <filename>meta-intel</filename> Git repositories.</para></listitem>
|
||||
</itemizedlist></para></listitem>
|
||||
<listitem id='local-kernel-files'><para><emphasis>Linux Yocto Kernel:</emphasis>
|
||||
If you are going to be making modifications to a supported Linux Yocto kernel you
|
||||
need to get set up so that you can edit local copies of the source.
|
||||
If you are going to be making modifications to a supported Linux Yocto kernel, you
|
||||
need to establish local copies of the source.
|
||||
This setup involves creating a bare clone of the Linux Yocto kernel and then cloning
|
||||
that repository.
|
||||
You can create the bare clone and the copy of the bare clone anywhere you like.
|
||||
For simplicity, it is recommended that you create these structures outside of the
|
||||
Yocto Project files Git repository.</para>
|
||||
Yocto Project files' Git repository.</para>
|
||||
<para>As an example, the following transcript shows how to create the bare clone
|
||||
of the <filename>linux-yocto-3.0</filename> kernel and then create a copy of
|
||||
of the <filename>linux-yocto-3.0-1.1.x</filename> kernel and then create a copy of
|
||||
that clone.
|
||||
<note>If you currently have a local Linux Yocto kernel Git repository, you can
|
||||
reference this local repository rather than the upstream Git repository as
|
||||
<note>When you have a local Linux Yocto kernel Git repository, you can
|
||||
reference that repository rather than the upstream Git repository as
|
||||
part of the <filename>clone</filename> command.
|
||||
Doing so can speed up the process.</note>
|
||||
The bare clone is named <filename>linux-yocto-3.0.git</filename>, while the
|
||||
copy is named <filename>linux-yocto-3.0</filename>:
|
||||
In the following example, the bare clone is named
|
||||
<filename>linux-yocto-3.0-1.1.x.git</filename>, while the
|
||||
copy is named <filename>my-linux-yocto-3.0-1.1.x-work</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ git clone --bare git://git.yoctoproject.org/linux-yocto-3.0 linux-yocto-3.0.git
|
||||
Initialized empty Git repository in /home/scottrif/poky/linux-yocto-3.0.git/
|
||||
remote: Counting objects: 1886034, done.
|
||||
remote: Compressing objects: 100% (314326/314326), done.
|
||||
remote: Total 1886034 (delta 1570200), reused 1870337 (delta 1554798)
|
||||
Receiving objects: 100% (1886034/1886034), 401.51 MiB | 3.27 MiB/s, done.
|
||||
Resolving deltas: 100% (1570200/1570200), done.
|
||||
$ git clone --bare git://git.yoctoproject.org/linux-yocto-3.0-1.1.x linux-yocto-3.0-1.1.x.git
|
||||
Initialized empty Git repository in /home/scottrif/linux-yocto-3.0-1.1.x.git/
|
||||
remote: Counting objects: 2259181, done.
|
||||
remote: Compressing objects: 100% (373259/373259), done.
|
||||
remote: Total 2259181 (delta 1892638), reused 2231556 (delta 1865300)
|
||||
Receiving objects: 100% (2259181/2259181), 482.44 MiB | 580 KiB/s, done.
|
||||
Resolving deltas: 100% (1892638/1892638), done.
|
||||
</literallayout></para>
|
||||
<para>Now create a clone of the bare clone just created:
|
||||
<literallayout class='monospaced'>
|
||||
$ git clone linux-yocto-3.0.git linux-yocto-3.0
|
||||
Initialized empty Git repository in /home/scottrif/poky/linux-yocto-3.0/.git/
|
||||
Checking out files: 100% (35188/35188), done.
|
||||
$ git clone linux-yocto-3.0-1.1.x.git my-linux-yocto-3.0-1.1.x-work
|
||||
Initialized empty Git repository in /home/scottrif/my-linux-yocto-3.0-1.1.x/.git/
|
||||
Checking out files: 100% (36898/36898), done.
|
||||
</literallayout></para></listitem>
|
||||
<listitem id='poky-extras-repo'><para><emphasis>
|
||||
The <filename>poky-extras</filename> Git Repository</emphasis>:
|
||||
The <filename>poky-extras</filename> Git repository contains metadata needed to
|
||||
build the kernel image.
|
||||
In particular, it contains the kernel <filename>.bbappend</filename> files that you
|
||||
edit to point to your locally modified kernel source files and to build kernel
|
||||
edit to point to your locally modified kernel source files and to build the kernel
|
||||
image.
|
||||
Pointing to these local files is much more efficient than requiring a download of the
|
||||
source files from upstream each time you make changes to the kernel.</para>
|
||||
|
@ -160,14 +159,14 @@
|
|||
$ cd ~/poky
|
||||
$ git clone git://git.yoctoproject.org/poky-extras poky-extras
|
||||
Initialized empty Git repository in /home/scottrif/poky/poky-extras/.git/
|
||||
remote: Counting objects: 531, done.
|
||||
remote: Compressing objects: 100% (471/471), done.
|
||||
remote: Total 531 (delta 138), reused 307 (delta 39)
|
||||
Receiving objects: 100% (531/531), 517.86 KiB, done.
|
||||
Resolving deltas: 100% (138/138), done.
|
||||
remote: Counting objects: 561, done.
|
||||
remote: Compressing objects: 100% (501/501), done.
|
||||
remote: Total 561 (delta 159), reused 306 (delta 39)
|
||||
Receiving objects: 100% (561/561), 519.96 KiB | 479 KiB/s, done.
|
||||
Resolving deltas: 100% (159/159), done.
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>Supported Board Support Packages (BSPs):</emphasis> The same considerations
|
||||
exist for BSPs.
|
||||
<listitem><para><emphasis>Supported Board Support Packages (BSPs):</emphasis>
|
||||
Similar considerations exist for BSPs.
|
||||
You can get set up for BSP development one of two ways: tarball extraction or
|
||||
with a local Git repository.
|
||||
Regardless of the method you use, the Yocto Project uses the following BSP layer
|
||||
|
@ -185,16 +184,16 @@
|
|||
<itemizedlist>
|
||||
<listitem><para><emphasis>Tarball Extraction:</emphasis> You can download any released
|
||||
BSP tarball from the same
|
||||
<ulink url='http://yoctoproject.org/download'>download site</ulink>.
|
||||
Once you have the tarball just extract it into a directory of your choice.
|
||||
<ulink url='http://yoctoproject.org/download'>download site</ulink> used
|
||||
to get the Yocto Project release.
|
||||
Once you have the tarball, just extract it into a directory of your choice.
|
||||
Again, this method just produces a snapshot of the BSP layer in the form
|
||||
of a hierarchical directory structure.</para></listitem>
|
||||
<listitem><para><emphasis>Git Repository Method:</emphasis> If you are working
|
||||
with a <filename>poky</filename> Git repository you should also set up a
|
||||
with a Yocto Project files Git repository, you should also set up a
|
||||
<filename>meta-intel</filename> Git repository.
|
||||
Typically, you set up the <filename>meta-intel</filename> Git repository inside
|
||||
the <filename>poky</filename> Git repository.</para>
|
||||
|
||||
the Yocto Project files Git repository.</para>
|
||||
<para>For example, the following transcript shows the steps to clone the
|
||||
<filename>meta-intel</filename>
|
||||
Git repository inside the <filename>poky</filename> Git repository.
|
||||
|
@ -202,24 +201,23 @@
|
|||
$cd poky
|
||||
$ git clone git://git.yoctoproject.org/meta-intel.git
|
||||
Initialized empty Git repository in /home/scottrif/poky/meta-intel/.git/
|
||||
remote: Counting objects: 1325, done.
|
||||
remote: Compressing objects: 100% (1078/1078), done.
|
||||
remote: Total 1325 (delta 546), reused 85 (delta 27)
|
||||
Receiving objects: 100% (1325/1325), 1.56 MiB | 330 KiB/s, done.
|
||||
Resolving deltas: 100% (546/546), done.
|
||||
remote: Counting objects: 3279, done.
|
||||
remote: Compressing objects: 100% (2708/2708), done.
|
||||
remote: Total 3279 (delta 1761), reused 194 (delta 105)
|
||||
Receiving objects: 100% (3279/3279), 1.75 MiB | 377 KiB/s, done.
|
||||
Resolving deltas: 100% (1761/1761), done.
|
||||
</literallayout></para>
|
||||
|
||||
<para>The same
|
||||
<ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
|
||||
wiki page</ulink> referenced earlier covers how to
|
||||
set up the <filename>meta-intel</filename> Git repository.</para></listitem>
|
||||
</itemizedlist></para></listitem>
|
||||
<listitem><para><emphasis>Eclipse Yocto Plug-in:</emphasis> If you are developing
|
||||
applications using the
|
||||
Eclipse Integrated Development Environment (IDE) you will need this plug-in.
|
||||
applications using the Eclipse Integrated Development Environment (IDE),
|
||||
you will need this plug-in.
|
||||
See the
|
||||
<ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html#setting-up-the-eclipse-ide'>
|
||||
Setting up the Eclipse IDE</ulink> section in the Yocto Application Development Toolkit (ADT)
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</ulink>"
|
||||
section in the Yocto Application Development Toolkit (ADT)
|
||||
User’s Guide for more information.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
@ -231,8 +229,8 @@
|
|||
<para>
|
||||
The build process creates an entire Linux distribution, including the toolchain, from source.
|
||||
For more information on this topic, see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html#building-image'>
|
||||
Building an Image</ulink> section in the Yocto Project Quick Start.
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>"
|
||||
section in the Yocto Project Quick Start.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -244,7 +242,7 @@
|
|||
script.</para></listitem>
|
||||
<listitem><para>Optionally ensure the <filename>conf/local.conf</filename> configuration file is set
|
||||
up how you want it.
|
||||
This file defines the target machine architecture and and other build options.</para></listitem>
|
||||
This file defines the target machine architecture and other build options.</para></listitem>
|
||||
<listitem><para>Build the image using the BitBake command.
|
||||
If you want information on Bitbake, see the user manual at
|
||||
<ulink url='http://docs.openembedded.org/bitbake/html'></ulink>.</para></listitem>
|
||||
|
@ -260,16 +258,17 @@
|
|||
<para>
|
||||
Another option you have to get started is to use pre-built binaries.
|
||||
This scenario is ideal for developing software applications to run on your target hardware.
|
||||
To do this you need to install the stand-alone Yocto toolchain tarball and then download the
|
||||
pre-built kernel that you will boot using the QEMU emulator.
|
||||
Next, you must download the filesystem for your target machine’s architecture.
|
||||
Finally, you set up the environment to emulate the hardware then start the emulator.
|
||||
To do this, you need to install the stand-alone Yocto Project cross-toolchain tarball and
|
||||
then download the pre-built kernel that you will boot in the QEMU emulator.
|
||||
Next, you must download and extract the target root filesystem for your target
|
||||
machine’s architecture.
|
||||
Finally, you set up the environment to emulate the hardware and then start the QEMU emulator.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can find details on all these steps in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html#using-pre-built'>
|
||||
Using Pre-Built Binaries and QEMU</ulink> section in the Yocto Project Quick Start.
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
|
||||
section of the Yocto Project Quick Start.
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
|
|
@ -30,14 +30,18 @@
|
|||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>1.1</revnumber>
|
||||
<date>TBD 2011</date>
|
||||
<revremark>This revision is the initial document draft and corresponds with
|
||||
the Yocto Project 1.1 Release.</revremark>
|
||||
<date>6 October 2011</date>
|
||||
<revremark>The initial document released with the Yocto Project 1.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1.1</revnumber>
|
||||
<date>15 March 2012</date>
|
||||
<revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<copyright>
|
||||
<year>2010-2011</year>
|
||||
<year>2010-2012</year>
|
||||
<holder>Linux Foundation</holder>
|
||||
</copyright>
|
||||
|
||||
|
@ -52,7 +56,7 @@
|
|||
<note>
|
||||
Due to production processes, there could be differences between the Yocto Project
|
||||
documentation bundled in the release tarball and
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
|
||||
The Yocto Project Development Manual</ulink> on
|
||||
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
|
||||
For the latest version of this manual, see the manual on the website.
|
||||
|
|
After Width: | Height: | Size: 51 KiB |
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 96 KiB After Width: | Height: | Size: 57 KiB |
Before Width: | Height: | Size: 61 KiB After Width: | Height: | Size: 60 KiB |
After Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 24 KiB |
After Width: | Height: | Size: 30 KiB |
Before Width: | Height: | Size: 28 KiB |
After Width: | Height: | Size: 34 KiB |
|
@ -46,12 +46,14 @@
|
|||
the baseline kernel is the most stable official release.</para></listitem>
|
||||
<listitem><para>Include major technological features as part of Yocto Project's up-rev
|
||||
strategy.</para></listitem>
|
||||
<listitem><para>Present a Git tree, that just like the upstream kernel.org tree, has a
|
||||
clear and continuous history.</para></listitem>
|
||||
<listitem><para>Present a kernel Git repository that, similar to the upstream
|
||||
<filename>kernel.org</filename> tree,
|
||||
has a clear and continuous history.</para></listitem>
|
||||
<listitem><para>Deliver a key set of supported kernel types, where each type is tailored
|
||||
to a specific use case (i.e. networking, consumer, devices, and so forth).</para></listitem>
|
||||
<listitem><para>Employ a Git branching strategy that from a customer's point of view
|
||||
results in a linear path from the baseline kernel.org, through a select group of features and
|
||||
to a specific use case (e.g. networking, consumer, devices, and so forth).</para></listitem>
|
||||
<listitem><para>Employ a Git branching strategy that, from a developer's point of view,
|
||||
results in a linear path from the baseline <filename>kernel.org</filename>,
|
||||
through a select group of features and
|
||||
ends with their BSP-specific commits.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
@ -60,27 +62,29 @@
|
|||
<section id='kernel-big-picture'>
|
||||
<title>Yocto Project Kernel Development and Maintenance Overview</title>
|
||||
<para>
|
||||
Yocto Project kernel, like other kernels, is based off the Linux kernel release
|
||||
The Yocto Project kernel, like other kernels, is based off the Linux kernel release
|
||||
from <ulink url='http://www.kernel.org'></ulink>.
|
||||
At the beginning of our major development cycle, we choose our Yocto Project kernel
|
||||
based on factors like release timing, the anticipated release timing of "final" (i.e. non "rc")
|
||||
upstream kernel.org versions, and Yocto Project feature requirements.
|
||||
Typically this will be a kernel that is in the
|
||||
final stages of development by the community (i.e. still in the release
|
||||
candidate or "rc" phase) and not yet a final release.
|
||||
But by being in the final stages of external development, we know that the
|
||||
kernel.org final release will clearly land within the early stages of
|
||||
At the beginning of a major development cycle, the Yocto Project team
|
||||
chooses its Yocto Project kernel
|
||||
based on factors like release timing, the anticipated release timing of final
|
||||
upstream <filename>kernel.org</filename> versions, and Yocto Project feature requirements.
|
||||
Typically, the kernel chosen is in the
|
||||
final stages of development by the community.
|
||||
In other words, the kernel is in the release
|
||||
candidate or "rc" phase and not yet a final release.
|
||||
But, by being in the final stages of external development, the team knows that the
|
||||
<filename>kernel.org</filename> final release will clearly be within the early stages of
|
||||
the Yocto Project development window.
|
||||
</para>
|
||||
<para>
|
||||
This balance allows us to deliver the most up-to-date kernel
|
||||
as possible, while still ensuring that we have a stable official release as
|
||||
our baseline kernel version.
|
||||
This balance allows the team to deliver the most up-to-date kernel
|
||||
as possible, while still ensuring that the team has a stable official release as
|
||||
the baseline kernel version.
|
||||
</para>
|
||||
<para>
|
||||
The ultimate source for the Yocto Project kernel is a released kernel
|
||||
from kernel.org.
|
||||
In addition to a foundational kernel from kernel.org the released
|
||||
from <filename>kernel.org</filename>.
|
||||
In addition to a foundational kernel from <filename>kernel.org</filename>, the released
|
||||
Yocto Project kernel contains a mix of important new mainline
|
||||
developments, non-mainline developments (when there is no alternative),
|
||||
Board Support Package (BSP) developments,
|
||||
|
@ -88,37 +92,21 @@
|
|||
These additions result in a commercially released Yocto Project kernel that caters
|
||||
to specific embedded designer needs for targeted hardware.
|
||||
</para>
|
||||
<!-- <para>
|
||||
The following figure represents the overall place the Yocto Project kernel fills.
|
||||
</para>
|
||||
<para>
|
||||
<imagedata fileref="figures/kernel-big-picture.png" width="6in" depth="6in" align="center" scale="100" />
|
||||
</para>
|
||||
<para>
|
||||
In the figure the ultimate source for the Yocto Project kernel is a released kernel
|
||||
from kernel.org.
|
||||
In addition to a foundational kernel from kernel.org the commercially released
|
||||
Yocto Project kernel contains a mix of important new mainline
|
||||
developments, non-mainline developments, Board Support Package (BSP) developments,
|
||||
and custom features.
|
||||
These additions result in a commercially released Yocto Project kernel that caters
|
||||
to specific embedded designer needs for targeted hardware.
|
||||
</para> -->
|
||||
<para>
|
||||
Once a Yocto Project kernel is officially released the Yocto Project team goes into
|
||||
their next development cycle, or "uprev" cycle while continuing maintenance on the
|
||||
Once a Yocto Project kernel is officially released, the Yocto Project team goes into
|
||||
their next development cycle, or "uprev" cycle, while still continuing maintenance on the
|
||||
released kernel.
|
||||
It is important to note that the most sustainable and stable way
|
||||
to include feature development upstream is through a kernel uprev process.
|
||||
Back-porting of hundreds of individual fixes and minor features from various
|
||||
Back-porting hundreds of individual fixes and minor features from various
|
||||
kernel versions is not sustainable and can easily compromise quality.
|
||||
</para>
|
||||
<para>
|
||||
During the uprev cycle, the Yocto Project team uses an ongoing analysis of
|
||||
kernel development, BSP support, and release timing to select the best
|
||||
possible kernel.org version.
|
||||
possible <filename>kernel.org</filename> version.
|
||||
The team continually monitors community kernel
|
||||
development to look for significant features of interest.
|
||||
<!-- The illustration depicts this by showing the team looking back to kernel.org for new features,
|
||||
BSP features, and significant bug fixes. -->
|
||||
The team does consider back-porting large features if they have a significant advantage.
|
||||
User or community demand can also trigger a back-port or creation of new
|
||||
functionality in the Yocto Project baseline kernel during the uprev cycle.
|
||||
|
@ -130,7 +118,7 @@
|
|||
It is the Yocto Project team's policy to not back-port minor features to the released kernel.
|
||||
They only consider back-porting significant technological jumps - and, that is done
|
||||
after a complete gap analysis.
|
||||
The reason for this policy is that simply back-porting any small to medium sized change
|
||||
The reason for this policy is that back-porting any small to medium sized change
|
||||
from an evolving kernel can easily create mismatches, incompatibilities and very
|
||||
subtle errors.
|
||||
</para>
|
||||
|
@ -163,18 +151,23 @@
|
|||
As mentioned earlier, a key goal of Yocto Project is to present the developer with
|
||||
a kernel that has a clear and continuous history that is visible to the user.
|
||||
The architecture and mechanisms used achieve that goal in a manner similar to the
|
||||
upstream kernel.org.
|
||||
|
||||
upstream <filename>kernel.org</filename>.
|
||||
</para>
|
||||
<para>
|
||||
You can think of the Yocto Project kernel as consisting of a baseline kernel with
|
||||
added features logically structured on top of the baseline.
|
||||
The features are tagged and organized by way of a branching strategy implemented by the
|
||||
source code manager (SCM) Git.
|
||||
For information on Git as applied to the Yocto Project, see the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
|
||||
section in <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The
|
||||
Yocto Project Development Manual</ulink>.
|
||||
</para>
|
||||
<para>
|
||||
The result is that the user has the ability to see the added features and
|
||||
the commits that make up those features.
|
||||
In addition to being able to see added features, the user can also view the history of what
|
||||
made up the baseline kernel as well.
|
||||
made up the baseline kernel.
|
||||
</para>
|
||||
<para>
|
||||
The following illustration shows the conceptual Yocto Project kernel.
|
||||
|
@ -183,18 +176,20 @@
|
|||
<imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" />
|
||||
</para>
|
||||
<para>
|
||||
In the illustration, the "kernel.org Branch Point" marks the specific spot (or release) from
|
||||
which the Yocto Project kernel is created. From this point "up" in the tree features and
|
||||
differences are organized and tagged.
|
||||
In the illustration, the "<filename>kernel.org</filename> Branch Point"
|
||||
marks the specific spot (or release) from
|
||||
which the Yocto Project kernel is created.
|
||||
From this point "up" in the tree, features and differences are organized and tagged.
|
||||
</para>
|
||||
<para>
|
||||
The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel
|
||||
type and BSP that is organized further up the tree. Placing these common features in the
|
||||
type and BSP that is organized further up the tree.
|
||||
Placing these common features in the
|
||||
tree this way means features don't have to be duplicated along individual branches of the
|
||||
structure.
|
||||
</para>
|
||||
<para>
|
||||
From the Yocto Project Baseline Kernel branch points represent specific functionality
|
||||
From the Yocto Project Baseline Kernel, branch points represent specific functionality
|
||||
for individual BSPs as well as real-time kernels.
|
||||
The illustration represents this through three BSP-specific branches and a real-time
|
||||
kernel branch.
|
||||
|
@ -209,8 +204,9 @@
|
|||
kernel as they apply to a given BSP.
|
||||
</para>
|
||||
<para>
|
||||
The resulting tree structure presents a clear path of markers (or branches) to the user
|
||||
that for all practical purposes is the kernel needed for any given set of requirements.
|
||||
The resulting tree structure presents a clear path of markers (or branches) to the
|
||||
developer that, for all practical purposes, is the kernel needed for any given set
|
||||
of requirements.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -221,50 +217,52 @@
|
|||
no longer shared and thus, needs to be isolated.
|
||||
For example, board-specific incompatibilities would require different functionality
|
||||
and would require a branch to separate the features.
|
||||
Likewise, for specific kernel features the same branching strategy is used.
|
||||
Likewise, for specific kernel features, the same branching strategy is used.
|
||||
</para>
|
||||
<para>
|
||||
This branching strategy results in a tree that has features organized to be specific
|
||||
for particular functionality, single kernel types, or a subset of kernel types.
|
||||
This strategy results in not having to store the same feature twice internally in the
|
||||
tree.
|
||||
Rather we store the unique differences required to apply the feature onto the kernel type
|
||||
in question.
|
||||
</para>
|
||||
<note><para>
|
||||
This strategy also results in not having to store the same feature twice
|
||||
internally in the tree.
|
||||
Rather, the kernel team stores the unique differences required to apply the
|
||||
feature onto the kernel type in question.
|
||||
<note>
|
||||
The Yocto Project team strives to place features in the tree such that they can be
|
||||
shared by all boards and kernel types where possible.
|
||||
However, during development cycles or when large features are merged this practice
|
||||
cannot always be followed.
|
||||
In those cases isolated branches are used for feature merging.
|
||||
</para></note>
|
||||
However, during development cycles or when large features are merged,
|
||||
the team cannot always follow this practice.
|
||||
In those cases, the team uses isolated branches to merge features.
|
||||
</note>
|
||||
</para>
|
||||
<para>
|
||||
BSP-specific code additions are handled in a similar manner to kernel-specific additions.
|
||||
Some BSPs only make sense given certain kernel types.
|
||||
So, for these types, we create branches off the end of that kernel type for all
|
||||
So, for these types, the team creates branches off the end of that kernel type for all
|
||||
of the BSPs that are supported on that kernel type.
|
||||
From the perspective of the tools that create the BSP branch, the BSP is really no
|
||||
different than a feature.
|
||||
Consequently, the same branching strategy applies to BSPs as it does to features.
|
||||
So again, rather than store the BSP twice, only the unique differences for the BSP across
|
||||
the supported multiple kernels are uniquely stored.
|
||||
So again, rather than store the BSP twice, the team only stores the unique
|
||||
differences for the BSP across the supported multiple kernels.
|
||||
</para>
|
||||
<para>
|
||||
While this strategy can result in a tree with a significant number of branches, it is
|
||||
important to realize that from the user's point of view, there is a linear
|
||||
path that travels from the baseline kernel.org, through a select group of features and
|
||||
ends with their BSP-specific commits.
|
||||
important to realize that from the developer's point of view, there is a linear
|
||||
path that travels from the baseline <filename>kernel.org</filename>, through a select
|
||||
group of features and ends with their BSP-specific commits.
|
||||
In other words, the divisions of the kernel are transparent and are not relevant
|
||||
to the developer on a day-to-day basis.
|
||||
From the user's perspective, this is the "master" branch.
|
||||
They do not need not be aware of the existence of any other branches at all.
|
||||
Of course there is value in the existence of these branches
|
||||
From the developer's perspective, this path is the "master" branch.
|
||||
The developer does not need not be aware of the existence of any other branches at all.
|
||||
Of course, there is value in the existence of these branches
|
||||
in the tree, should a person decide to explore them.
|
||||
For example, a comparison between two BSPs at either the commit level or at the line-by-line
|
||||
code diff level is now a trivial operation.
|
||||
code <filename>diff</filename> level is now a trivial operation.
|
||||
</para>
|
||||
<para>
|
||||
Working with the kernel as a structured tree follows recognized community best practices.
|
||||
In particular, the kernel as shipped with the product should be
|
||||
considered an 'upstream source' and viewed as a series of
|
||||
In particular, the kernel as shipped with the product, should be
|
||||
considered an "upstream source" and viewed as a series of
|
||||
historical and documented modifications (commits).
|
||||
These modifications represent the development and stabilization done
|
||||
by the Yocto Project kernel development team.
|
||||
|
@ -273,7 +271,7 @@
|
|||
Because commits only change at significant release points in the product life cycle,
|
||||
developers can work on a branch created
|
||||
from the last relevant commit in the shipped Yocto Project kernel.
|
||||
As mentioned previously, the structure is transparent to the user
|
||||
As mentioned previously, the structure is transparent to the developer
|
||||
because the kernel tree is left in this state after cloning and building the kernel.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -281,20 +279,26 @@
|
|||
<section id='source-code-manager-git'>
|
||||
<title>Source Code Manager - Git</title>
|
||||
<para>
|
||||
The Source Code Manager (SCM) is Git and it is the obvious mechanism for meeting the
|
||||
previously mentioned goals.
|
||||
Not only is it the SCM for kernel.org but Git continues to grow in popularity and
|
||||
supports many different work flows, front-ends and management techniques.
|
||||
The Source Code Manager (SCM) is Git.
|
||||
This SCM is the obvious mechanism for meeting the previously mentioned goals.
|
||||
Not only is it the SCM for <filename>kernel.org</filename> but,
|
||||
Git continues to grow in popularity and supports many different work flows,
|
||||
front-ends and management techniques.
|
||||
</para>
|
||||
<para>
|
||||
You can find documentation on Git at <ulink url='http://git-scm.com/documentation'></ulink>.
|
||||
Also, the Yocto Project Development manual has an introduction to Git and describes a
|
||||
minimal set of commands that allow you to be functional with Git.
|
||||
You can also get an introduction to Git as it applies to the Yocto Project in the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
|
||||
section in <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The
|
||||
Yocto Project Development Manual</ulink>.
|
||||
This section overviews Git and describes a minimal set of commands that allow you to be
|
||||
functional using Git.
|
||||
<note>
|
||||
You can use as much, or as little, of what Git has to offer to accomplish what
|
||||
you need for your project.
|
||||
You do not have to be a "Git Master" in order to use it with the Yocto Project.
|
||||
</note>
|
||||
</para>
|
||||
<note><para>
|
||||
It should be noted that you can use as much, or as little, of what Git has to offer
|
||||
as is appropriate to your project.
|
||||
</para></note>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
|
@ -307,17 +311,19 @@
|
|||
present a simplified view of the kernel for ease of use.
|
||||
</para>
|
||||
<para>
|
||||
The fundamental properties of the tools that manage and construct the
|
||||
Yocto Project kernel are:
|
||||
Fundamentally, the kernel tools that manage and construct the
|
||||
Yocto Project kernel accomplish the following:
|
||||
<itemizedlist>
|
||||
<listitem><para>Group patches into named, reusable features.</para></listitem>
|
||||
<listitem><para>Allow top down control of included features.</para></listitem>
|
||||
<listitem><para>Bind kernel configuration to kernel patches and features.</para></listitem>
|
||||
<listitem><para>Allow top-down control of included features.</para></listitem>
|
||||
<listitem><para>Bind kernel configurations to kernel patches and features.</para></listitem>
|
||||
<listitem><para>Present a seamless Git repository that blends Yocto Project value
|
||||
with the kernel.org history and development.</para></listitem>
|
||||
with the <filename>kernel.org</filename> history and development.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<!--<para>
|
||||
WRITER NOTE: Put this in for post 1.1 if possible:
|
||||
|
||||
The tools that construct a kernel tree will be discussed later in this
|
||||
document. The following tools form the foundation of the Yocto Project
|
||||
kernel toolkit:
|
||||
|
|
|
@ -20,17 +20,20 @@
|
|||
on its history, organization, benefits, and use.
|
||||
The manual consists of two sections:
|
||||
<itemizedlist>
|
||||
<listitem><para>Concepts - Describes concepts behind the kernel.
|
||||
<listitem><para><emphasis>Concepts:</emphasis> Describes concepts behind the kernel.
|
||||
You will understand how the kernel is organized and why it is organized in
|
||||
the way it is. You will understand the benefits of the kernel's organization
|
||||
and the mechanisms used to work with the kernel and how to apply it in your
|
||||
design process.</para></listitem>
|
||||
<listitem><para>Using the Kernel - Describes best practices and "how-to" information
|
||||
that lets you put the kernel to practical use. Some examples are "How to Build a
|
||||
Project Specific Tree", "How to Examine Changes in a Branch", and "Saving Kernel
|
||||
Modifications."</para></listitem>
|
||||
<listitem><para><emphasis>Using the Kernel:</emphasis> Describes best practices
|
||||
and "how-to" information
|
||||
that lets you put the kernel to practical use.
|
||||
Some examples are "How to Build a
|
||||
Project Specific Tree", "How to Examine Changes in a Branch", and "How to
|
||||
Save Kernel Modifications."</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more information on the kernel, see the following links:
|
||||
<itemizedlist>
|
||||
|
@ -38,10 +41,19 @@
|
|||
<listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem>
|
||||
<listitem><para><ulink url='http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/HOWTO;hb=HEAD'></ulink></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
You can find more information on Yocto Project by visiting the website at
|
||||
<ulink url='http://www.yoctoproject.org'></ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more discussion on the Yocto Project kernel, you can also see the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#kernel-overview'>Kernel Overview</ulink>",
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#kernel-modification-workflow'>Kernel Modification Workflow</ulink>", and
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-kernel-appendix'>Kernel Modification Example</ulink>" sections all in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto Project Development Manual</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For general information on the Yocto Project, visit the website at
|
||||
<ulink url='http://www.yoctoproject.org'></ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
|
@ -31,23 +31,32 @@
|
|||
<revision>
|
||||
<revnumber>0.9</revnumber>
|
||||
<date>24 November 2010</date>
|
||||
<revremark>This revision is the initial document draft and corresponds with
|
||||
the Yocto Project 0.9 Release.</revremark>
|
||||
<revremark>The initial document draft released with the Yocto Project 0.9 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.0</revnumber>
|
||||
<date>6 April 2011</date>
|
||||
<revremark>This revision corresponds with the Yocto Project 1.0 Release.</revremark>
|
||||
<revremark>Released with the Yocto Project 1.0 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.0.1</revnumber>
|
||||
<date>23 May 2011</date>
|
||||
<revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
|
||||
<revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1</revnumber>
|
||||
<date>6 October 2011</date>
|
||||
<revremark>Released with the Yocto Project 1.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1.1</revnumber>
|
||||
<date>15 March 2012</date>
|
||||
<revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<copyright>
|
||||
<year>2010-2011</year>
|
||||
<year>2010-2012</year>
|
||||
<holder>Linux Foundation</holder>
|
||||
</copyright>
|
||||
|
||||
|
@ -59,7 +68,7 @@
|
|||
<note>
|
||||
Due to production processes, there could be differences between the Yocto Project
|
||||
documentation bundled in the release tarball and
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
|
||||
The Yocto Project Kernel Architecture and Use Manual</ulink> on
|
||||
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
|
||||
For the latest version of this manual, see the manual on the website.
|
||||
|
|
|
@ -91,9 +91,9 @@
|
|||
with other plug-ins installed into the Eclipse IDE.
|
||||
Once you have your environment setup you need to configure the Eclipse plug-in.
|
||||
For information on how to install and configure the Eclipse plug-in, see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html#adt-eclipse'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#adt-eclipse'>
|
||||
"Working Within Eclipse"</ulink> chapter in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
|
||||
"Application Development Toolkit (ADT) User's Guide."</ulink>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -102,7 +102,7 @@
|
|||
<title>External Development Using the QEMU Emulator</title>
|
||||
<para>
|
||||
Running Poky QEMU images is covered in the
|
||||
<ulink url="http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html">
|
||||
<ulink url="http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html">
|
||||
Yocto Project Quick Start</ulink> in the "A Quick Test Run" section.
|
||||
</para>
|
||||
<para>
|
||||
|
|
|
@ -3,13 +3,14 @@
|
|||
|
||||
<chapter id='extendpoky'>
|
||||
|
||||
<title>Extending the Yocto Project</title>
|
||||
<title>Common Tasks</title>
|
||||
<para>
|
||||
This chapter provides information about how to extend the functionality
|
||||
already present in the Yocto Project.
|
||||
The chapter also documents standard tasks such as adding new
|
||||
This chapter describes standard tasks such as adding new
|
||||
software packages, extending or customizing images or porting the Yocto Project to
|
||||
new hardware (adding a new machine).
|
||||
The chapter also describes ways to modify package source code, combine multiple
|
||||
versions of library files into a single image, track license changes, and handle
|
||||
a package name alias.
|
||||
Finally, the chapter contains advice about how to make changes to the
|
||||
Yocto Project to achieve the best results.
|
||||
</para>
|
||||
|
@ -79,7 +80,8 @@
|
|||
By default, the <filename>helloworld</filename>, <filename>helloworld-dbg</filename>,
|
||||
and <filename>helloworld-dev</filename> packages are built.
|
||||
For information on how to customize the packaging process, see the
|
||||
<link linkend='usingpoky-extend-addpkg-files'>Controlling Package Content</link> section.
|
||||
"<link linkend='splitting-an-application-into-multiple-packages'>Splitting an Application
|
||||
into Multiple Packages</link>" section.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -174,8 +176,8 @@
|
|||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-extend-addpkg-files'>
|
||||
<title>Controlling Package Content</title>
|
||||
<section id='splitting-an-application-into-multiple-packages'>
|
||||
<title>Splitting an Application into Multiple Packages</title>
|
||||
|
||||
<para>
|
||||
You can use the variables <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename> and
|
||||
|
@ -222,6 +224,59 @@
|
|||
</para>
|
||||
</section>
|
||||
|
||||
<section id='including-static-library-files'>
|
||||
<title>Including Static Library Files</title>
|
||||
|
||||
<para>
|
||||
If you are building a library and the library offers static linking, you can control
|
||||
which static library files (<filename>*.a</filename> files) get included in the
|
||||
built library.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>PACKAGES</filename> and <filename>FILES_*</filename> variables in the
|
||||
<filename>meta/conf/bitbake.conf</filename> configuration file define how files installed
|
||||
by the <filename>do_install</filename> task are packaged.
|
||||
By default, the <filename>PACKAGES</filename> variable contains
|
||||
<filename>${PN}-staticdev</filename>, which includes all static library files.
|
||||
<note>
|
||||
Previously released versions of the Yocto Project defined the static library files
|
||||
through <filename>${PN}-dev</filename>.
|
||||
</note>
|
||||
Following, is part of the BitBake configuration file.
|
||||
You can see where the static library files are defined:
|
||||
<literallayout class='monospaced'>
|
||||
PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-locale"
|
||||
PACKAGES_DYNAMIC = "${PN}-locale-*"
|
||||
FILES = ""
|
||||
|
||||
FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
|
||||
${sysconfdir} ${sharedstatedir} ${localstatedir} \
|
||||
${base_bindir}/* ${base_sbindir}/* \
|
||||
${base_libdir}/*${SOLIBS} \
|
||||
${datadir}/${BPN} ${libdir}/${BPN}/* \
|
||||
${datadir}/pixmaps ${datadir}/applications \
|
||||
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
|
||||
${libdir}/bonobo/servers"
|
||||
|
||||
FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
|
||||
${datadir}/gnome/help"
|
||||
SECTION_${PN}-doc = "doc"
|
||||
|
||||
FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
|
||||
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
|
||||
${datadir}/aclocal ${base_libdir}/*.o"
|
||||
SECTION_${PN}-dev = "devel"
|
||||
ALLOW_EMPTY_${PN}-dev = "1"
|
||||
RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
|
||||
|
||||
FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a"
|
||||
SECTION_${PN}-staticdev = "devel"
|
||||
RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-extend-addpkg-postinstalls'>
|
||||
<title>Post Install Scripts</title>
|
||||
|
||||
|
@ -303,7 +358,7 @@
|
|||
It is important to use the correct names of packages in the
|
||||
<filename><link linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></filename> variable.
|
||||
You must use the OpenEmbedded notation and not the Debian notation for the names
|
||||
(e.g. <filename>glibc-dev</filename> instead of <filename>libc6-dev</filename>).
|
||||
(e.g. <filename>eglibc-dev</filename> instead of <filename>libc6-dev</filename>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -470,16 +525,16 @@
|
|||
The information covers adding machines similar to those the Yocto Project already supports.
|
||||
Although well within the capabilities of the Yocto Project, adding a totally new architecture
|
||||
might require
|
||||
changes to <filename>gcc/glibc</filename> and to the site information, which is
|
||||
changes to <filename>gcc/eglibc</filename> and to the site information, which is
|
||||
beyond the scope of this manual.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For a complete example that shows how to add a new machine to the Yocto Project,
|
||||
see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
|
||||
BSP Development Example</ulink> in Appendix A of
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
|
||||
The Yocto Project Development Manual</ulink>.
|
||||
</para>
|
||||
|
||||
|
@ -604,6 +659,412 @@
|
|||
</section>
|
||||
</section>
|
||||
|
||||
<section id="usingpoky-modifing-packages">
|
||||
<title>Modifying Package Source Code</title>
|
||||
<para>
|
||||
Although the Yocto Project is usually used to build software, you can use it to modify software.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
During a build, source is available in the
|
||||
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename> directory.
|
||||
The actual location depends on the type of package and the architecture of the target device.
|
||||
For a standard recipe not related to
|
||||
<filename><link linkend='var-MACHINE'>MACHINE</link></filename>, the location is
|
||||
<filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>.
|
||||
For target device-dependent packages, you should use the <filename>MACHINE</filename>
|
||||
variable instead of
|
||||
<filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>
|
||||
in the directory name.
|
||||
</para>
|
||||
|
||||
<tip>
|
||||
Be sure the package recipe sets the
|
||||
<filename><link linkend='var-S'>S</link></filename> variable to something
|
||||
other than the standard <filename>WORKDIR/PN-PV/</filename> value.
|
||||
</tip>
|
||||
|
||||
<para>
|
||||
After building a package, you can modify the package source code without problems.
|
||||
The easiest way to test your changes is by calling the
|
||||
<filename>compile</filename> task as shown in the following example:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake -c compile -f NAME_OF_PACKAGE
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>-f</filename> or <filename>--force</filename>
|
||||
option forces re-execution of the specified task.
|
||||
You can call other tasks this way as well.
|
||||
But note that all the modifications in
|
||||
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>
|
||||
are gone once you execute <filename>-c clean</filename> for a package.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="usingpoky-modifying-packages-quilt">
|
||||
<title>Modifying Package Source Code with Quilt</title>
|
||||
|
||||
<para>
|
||||
By default Poky uses <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>
|
||||
to manage patches in the <filename>do_patch</filename> task.
|
||||
This is a powerful tool that you can use to track all modifications to package sources.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Before modifying source code, it is important to notify Quilt so it can track the changes
|
||||
into the new patch file:
|
||||
<literallayout class='monospaced'>
|
||||
$ quilt new NAME-OF-PATCH.patch
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
After notifying Quilt, add all modified files into that patch:
|
||||
<literallayout class='monospaced'>
|
||||
$ quilt add file1 file2 file3
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can now start editing.
|
||||
Once you are done editing, you need to use Quilt to generate the final patch that
|
||||
will contain all your modifications.
|
||||
<literallayout class='monospaced'>
|
||||
$ quilt refresh
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can find the resulting patch file in the
|
||||
<filename>patches/</filename> subdirectory of the source
|
||||
(<filename><link linkend='var-S'>S</link></filename>) directory.
|
||||
For future builds, you should copy the patch into the Yocto Project metadata and add it into the
|
||||
<filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> of a recipe.
|
||||
Here is an example:
|
||||
<literallayout class='monospaced'>
|
||||
SRC_URI += "file://NAME-OF-PATCH.patch"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, don't forget to 'bump' the
|
||||
<filename><link linkend='var-PR'>PR</link></filename> value in the same recipe since
|
||||
the resulting packages have changed.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="building-multiple-architecture-libraries-into-one-image">
|
||||
<title>Combining Multiple Versions of Library Files into One Image</title>
|
||||
|
||||
<para>
|
||||
The build system offers the ability to build libraries with different
|
||||
target optimizations or architecture formats and combine these together
|
||||
into one system image.
|
||||
You can link different binaries in the image
|
||||
against the different libraries as needed for specific use cases.
|
||||
This feature is called "Multilib."
|
||||
</para>
|
||||
|
||||
<para>
|
||||
An example would be where you have most of a system compiled in 32-bit
|
||||
mode using 32-bit libraries, but you have something large, like a database
|
||||
engine, that needs to be a 64-bit application and use 64-bit libraries.
|
||||
Multilib allows you to get the best of both 32-bit and 64-bit libraries.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
While the Multilib feature is most commonly used for 32 and 64-bit differences,
|
||||
the approach the build system uses facilitates different target optimizations.
|
||||
You could compile some binaries to use one set of libraries and other binaries
|
||||
to use other different sets of libraries.
|
||||
The libraries could differ in architecture, compiler options, or other
|
||||
optimizations.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This section overviews the Multilib process only.
|
||||
For more details on how to implement Multilib, see the
|
||||
<ulink url='https://wiki.yoctoproject.org/wiki/Multilib'>Multilib</ulink> wiki
|
||||
page.
|
||||
</para>
|
||||
|
||||
<section id='preparing-to-use-multilib'>
|
||||
<title>Preparing to use Multilib</title>
|
||||
|
||||
<para>
|
||||
User-specific requirements drive the Multilib feature,
|
||||
Consequently, there is no one "out-of-the-box" configuration that likely
|
||||
exists to meet your needs.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In order to enable Multilib, you first need to ensure your recipe is
|
||||
extended to support multiple libraries.
|
||||
Many standard recipes are already extended and support multiple libraries.
|
||||
You can check in the <filename>meta/conf/multilib.conf</filename>
|
||||
configuration file in the Yocto Project files directory to see how this is
|
||||
done using the <filename>BBCLASSEXTEND</filename> variable.
|
||||
Eventually, all recipes will be covered and this list will be unneeded.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For the most part, the Multilib class extension works automatically to
|
||||
extend the package name from <filename>${PN}</filename> to
|
||||
<filename>${MLPREFIX}${PN}</filename>, where <filename>MLPREFIX</filename>
|
||||
is the particular multilib (e.g. "lib32-" or "lib64-").
|
||||
Standard variables such as <filename>DEPENDS</filename>,
|
||||
<filename>RDEPENDS</filename>, <filename>RPROVIDES</filename>,
|
||||
<filename>RRECOMMENDS</filename>, <filename>PACKAGES</filename>, and
|
||||
<filename>PACKAGES_DYNAMIC</filename> are automatically extended by the system.
|
||||
If you are extending any manual code in the recipe, you can use the
|
||||
<filename>${MLPREFIX}</filename> variable to ensure those names are extended
|
||||
correctly.
|
||||
This automatic extension code resides in <filename>multilib.bbclass</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='using-multilib'>
|
||||
<title>Using Multilib</title>
|
||||
|
||||
<para>
|
||||
After you have set up the recipes, you need to define the actual
|
||||
combination of multiple libraries you want to build.
|
||||
You accomplish this through your <filename>local.conf</filename>
|
||||
configuration file in the Yocto Project build directory.
|
||||
An example configuration would be as follows:
|
||||
<literallayout class='monospaced'>
|
||||
MACHINE = "qemux86-64"
|
||||
require conf/multilib.conf
|
||||
MULTILIBS = "multilib:lib32"
|
||||
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
|
||||
MULTILIB_IMAGE_INSTALL = "lib32-connman"
|
||||
</literallayout>
|
||||
This example enables an
|
||||
additional library named <filename>lib32</filename> alongside the
|
||||
normal target packages.
|
||||
When combining these "lib32" alternatives, the example uses "x86" for tuning.
|
||||
For information on this particular tuning, see
|
||||
<filename>meta/conf/machine/include/ia32/arch-ia32.inc</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The example then includes <filename>lib32-connman</filename>
|
||||
in all the images, which illustrates one method of including a
|
||||
multiple library dependency.
|
||||
You can use a normal image build to include this dependency,
|
||||
for example:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake core-image-sato
|
||||
</literallayout>
|
||||
You can also build Multilib packages specifically with a command like this:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake lib32-connman
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='additional-implementation-details'>
|
||||
<title>Additional Implementation Details</title>
|
||||
|
||||
<para>
|
||||
Different packaging systems have different levels of native Multilib
|
||||
support.
|
||||
For the RPM Package Management System, the following implementation details
|
||||
exist:
|
||||
<itemizedlist>
|
||||
<listitem><para>A unique architecture is defined for the Multilib packages,
|
||||
along with creating a unique deploy folder under
|
||||
<filename>tmp/deploy/rpm</filename> in the Yocto
|
||||
Project build directory.
|
||||
For example, consider <filename>lib32</filename> in a
|
||||
<filename>qemux86-64</filename> image.
|
||||
The possible architectures in the system are "all", "qemux86_64",
|
||||
"lib32_qemux86_64", and "lib32_x86".</para></listitem>
|
||||
<listitem><para>The <filename>${MLPREFIX}</filename> variable is stripped from
|
||||
<filename>${PN}</filename> during RPM packaging.
|
||||
The naming for a normal RPM package and a Multilib RPM package in a
|
||||
<filename>qemux86-64</filename> system resolves to something similar to
|
||||
<filename>bash-4.1-r2.x86_64.rpm</filename> and
|
||||
<filename>bash-4.1.r2.lib32_x86.rpm</filename>, respectively.
|
||||
</para></listitem>
|
||||
<listitem><para>When installing a Multilib image, the RPM backend first
|
||||
installs the base image and then installs the Multilib libraries.
|
||||
</para></listitem>
|
||||
<listitem><para>The build system relies on RPM to resolve the identical files in the
|
||||
two (or more) Multilib packages.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For the IPK Package Management System, the following implementation details exist:
|
||||
<itemizedlist>
|
||||
<listitem><para>The <filename>${MLPREFIX}</filename> is not stripped from
|
||||
<filename>${PN}</filename> during IPK packaging.
|
||||
The naming for a normal RPM package and a Multilib IPK package in a
|
||||
<filename>qemux86-64</filename> system resolves to something like
|
||||
<filename>bash_4.1-r2.x86_64.ipk</filename> and
|
||||
<filename>lib32-bash_4.1-rw_x86.ipk</filename>, respectively.
|
||||
</para></listitem>
|
||||
<listitem><para>The IPK deploy folder is not modified with
|
||||
<filename>${MLPREFIX}</filename> because packages with and without
|
||||
the Multilib feature can exist in the same folder due to the
|
||||
<filename>${PN}</filename> differences.</para></listitem>
|
||||
<listitem><para>IPK defines a sanity check for Multilib installation
|
||||
using certain rules for file comparison, overridden, etc.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="usingpoky-configuring-LIC_FILES_CHKSUM">
|
||||
<title>Tracking License Changes</title>
|
||||
|
||||
<para>
|
||||
The license of an upstream project might change in the future. In order to prevent these changes
|
||||
going unnoticed, the Yocto Project provides a
|
||||
<filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
|
||||
variable to track changes to the license text. The checksums are validated at the end of the
|
||||
configure step, and if the checksums do not match, the build will fail.
|
||||
</para>
|
||||
|
||||
<section id="usingpoky-specifying-LIC_FILES_CHKSUM">
|
||||
<title>Specifying the <filename>LIC_FILES_CHKSUM</filename> Variable</title>
|
||||
|
||||
<para>
|
||||
The <filename>LIC_FILES_CHKSUM</filename>
|
||||
variable contains checksums of the license text in the source code for the recipe.
|
||||
Following is an example of how to specify <filename>LIC_FILES_CHKSUM</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
|
||||
file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
|
||||
file://licfile2.txt;endline=50;md5=zzzz \
|
||||
..."
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Yocto Project uses the
|
||||
<filename><link linkend='var-S'>S</link></filename> variable as the
|
||||
default directory used when searching files listed in
|
||||
<filename>LIC_FILES_CHKSUM</filename>.
|
||||
The previous example employs the default directory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can also use relative paths as shown in the following example:
|
||||
<literallayout class='monospaced'>
|
||||
LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\
|
||||
md5=bb14ed3c4cda583abc85401304b5cd4e"
|
||||
LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In this example, the first line locates a file in
|
||||
<filename><link linkend='var-S'>S</link>/src/ls.c</filename>.
|
||||
The second line refers to a file in
|
||||
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, which is the parent
|
||||
of <filename>S</filename>.
|
||||
</para>
|
||||
<para>
|
||||
Note that this variable is mandatory for all recipes, unless the
|
||||
<filename>LICENSE</filename> variable is set to "CLOSED".
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">
|
||||
<title>Explanation of Syntax</title>
|
||||
<para>
|
||||
As mentioned in the previous section, the
|
||||
<filename>LIC_FILES_CHKSUM</filename> variable lists all the
|
||||
important files that contain the license text for the source code.
|
||||
It is possible to specify a checksum for an entire file, or a specific section of a
|
||||
file (specified by beginning and ending line numbers with the "beginline" and "endline"
|
||||
parameters, respectively).
|
||||
The latter is useful for source files with a license notice header,
|
||||
README documents, and so forth.
|
||||
If you do not use the "beginline" parameter, then it is assumed that the text begins on the
|
||||
first line of the file.
|
||||
Similarly, if you do not use the "endline" parameter, it is assumed that the license text
|
||||
ends with the last line of the file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The "md5" parameter stores the md5 checksum of the license text.
|
||||
If the license text changes in any way as compared to this parameter
|
||||
then a mismatch occurs.
|
||||
This mismatch triggers a build failure and notifies the developer.
|
||||
Notification allows the developer to review and address the license text changes.
|
||||
Also note that if a mismatch occurs during the build, the correct md5
|
||||
checksum is placed in the build log and can be easily copied to the recipe.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There is no limit to how many files you can specify using the
|
||||
<filename>LIC_FILES_CHKSUM</filename> variable.
|
||||
Generally, however, every project requires a few specifications for license tracking.
|
||||
Many projects have a "COPYING" file that stores the license information for all the source
|
||||
code files.
|
||||
This practice allows you to just track the "COPYING" file as long as it is kept up to date.
|
||||
</para>
|
||||
|
||||
<tip>
|
||||
If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match
|
||||
error and displays the correct "md5" parameter value during the build.
|
||||
The correct parameter is also captured in the build log.
|
||||
</tip>
|
||||
|
||||
<tip>
|
||||
If the whole file contains only license text, you do not need to use the "beginline" and
|
||||
"endline" parameters.
|
||||
</tip>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="usingpoky-configuring-DISTRO_PN_ALIAS">
|
||||
<title>Handling a Package Name Alias</title>
|
||||
<para>
|
||||
Sometimes a package name you are using might exist under an alias or as a similarly named
|
||||
package in a different distribution.
|
||||
The Yocto Project implements a <filename>distro_check</filename>
|
||||
task that automatically connects to major distributions
|
||||
and checks for these situations.
|
||||
If the package exists under a different name in a different distribution, you get a
|
||||
<filename>distro_check</filename> mismatch.
|
||||
You can resolve this problem by defining a per-distro recipe name alias using the
|
||||
<filename><link linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></filename> variable.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Following is an example that shows how you specify the <filename>DISTRO_PN_ALIAS</filename>
|
||||
variable:
|
||||
<literallayout class='monospaced'>
|
||||
DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \
|
||||
distro2=package_name_alias2 \
|
||||
distro3=package_name_alias3 \
|
||||
..."
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you have more than one distribution alias, separate them with a space.
|
||||
Note that the Yocto Project currently automatically checks the
|
||||
Fedora, OpenSuSE, Debian, Ubuntu,
|
||||
and Mandriva distributions for source package recipes without having to specify them
|
||||
using the <filename>DISTRO_PN_ALIAS</filename> variable.
|
||||
For example, the following command generates a report that lists the Linux distributions
|
||||
that include the sources for each of the Yocto Project recipes.
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake world -f -c distro_check
|
||||
</literallayout>
|
||||
The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename>
|
||||
file found in the Yocto Project files area.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="usingpoky-changes">
|
||||
<title>Making and Maintaining Changes</title>
|
||||
<para>
|
||||
|
@ -860,7 +1321,7 @@
|
|||
Experience shows that buildbot is a good fit for this role.
|
||||
What works well is to configure buildbot to make two types of builds:
|
||||
incremental and full (from scratch).
|
||||
See <ulink url='http://autobuilder.yoctoproject.org:8010'>the buildbot for the
|
||||
See <ulink url='http://www.yoctoproject.org:8010'>the buildbot for the
|
||||
Yocto Project</ulink> for an example implementation that uses buildbot.
|
||||
</para>
|
||||
|
||||
|
@ -922,247 +1383,6 @@
|
|||
</section>
|
||||
</section>
|
||||
|
||||
<section id="usingpoky-modifing-packages">
|
||||
<title>Modifying Package Source Code</title>
|
||||
<para>
|
||||
Although the Yocto Project is usually used to build software, you can use it to modify software.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
During a build, source is available in the
|
||||
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename> directory.
|
||||
The actual location depends on the type of package and the architecture of the target device.
|
||||
For a standard recipe not related to
|
||||
<filename><link linkend='var-MACHINE'>MACHINE</link></filename>, the location is
|
||||
<filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>.
|
||||
For target device-dependent packages, you should use the <filename>MACHINE</filename>
|
||||
variable instead of
|
||||
<filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>
|
||||
in the directory name.
|
||||
</para>
|
||||
|
||||
<tip>
|
||||
Be sure the package recipe sets the
|
||||
<filename><link linkend='var-S'>S</link></filename> variable to something
|
||||
other than the standard <filename>WORKDIR/PN-PV/</filename> value.
|
||||
</tip>
|
||||
|
||||
<para>
|
||||
After building a package, you can modify the package source code without problems.
|
||||
The easiest way to test your changes is by calling the
|
||||
<filename>compile</filename> task as shown in the following example:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake -c compile -f NAME_OF_PACKAGE
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>-f</filename> or <filename>--force</filename>
|
||||
option forces re-execution of the specified task.
|
||||
You can call other tasks this way as well.
|
||||
But note that all the modifications in
|
||||
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>
|
||||
are gone once you execute <filename>-c clean</filename> for a package.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="usingpoky-modifying-packages-quilt">
|
||||
<title>Modifying Package Source Code with Quilt</title>
|
||||
|
||||
<para>
|
||||
By default Poky uses <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>
|
||||
to manage patches in the <filename>do_patch</filename> task.
|
||||
This is a powerful tool that you can use to track all modifications to package sources.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Before modifying source code, it is important to notify Quilt so it can track the changes
|
||||
into the new patch file:
|
||||
<literallayout class='monospaced'>
|
||||
$ quilt new NAME-OF-PATCH.patch
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
After notifying Quilt, add all modified files into that patch:
|
||||
<literallayout class='monospaced'>
|
||||
$ quilt add file1 file2 file3
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can now start editing.
|
||||
Once you are done editing, you need to use Quilt to generate the final patch that
|
||||
will contain all your modifications.
|
||||
<literallayout class='monospaced'>
|
||||
$ quilt refresh
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can find the resulting patch file in the
|
||||
<filename>patches/</filename> subdirectory of the source
|
||||
(<filename><link linkend='var-S'>S</link></filename>) directory.
|
||||
For future builds, you should copy the patch into the Yocto Project metadata and add it into the
|
||||
<filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> of a recipe.
|
||||
Here is an example:
|
||||
<literallayout class='monospaced'>
|
||||
SRC_URI += "file://NAME-OF-PATCH.patch"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, don't forget to 'bump' the
|
||||
<filename><link linkend='var-PR'>PR</link></filename> value in the same recipe since
|
||||
the resulting packages have changed.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="usingpoky-configuring-LIC_FILES_CHKSUM">
|
||||
<title>Tracking License Changes</title>
|
||||
|
||||
<para>
|
||||
The license of an upstream project might change in the future. In order to prevent these changes
|
||||
going unnoticed, the Yocto Project provides a
|
||||
<filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
|
||||
variable to track changes to the license text. The checksums are validated at the end of the
|
||||
configure step, and if the checksums do not match, the build will fail.
|
||||
</para>
|
||||
|
||||
<section id="usingpoky-specifying-LIC_FILES_CHKSUM">
|
||||
<title>Specifying the <filename>LIC_FILES_CHKSUM</filename> Variable</title>
|
||||
|
||||
<para>
|
||||
The <filename>LIC_FILES_CHKSUM</filename>
|
||||
variable contains checksums of the license text in the source code for the recipe.
|
||||
Following is an example of how to specify <filename>LIC_FILES_CHKSUM</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
|
||||
file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
|
||||
file://licfile2.txt;endline=50;md5=zzzz \
|
||||
..."
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Yocto Project uses the
|
||||
<filename><link linkend='var-S'>S</link></filename> variable as the
|
||||
default directory used when searching files listed in
|
||||
<filename>LIC_FILES_CHKSUM</filename>.
|
||||
The previous example employs the default directory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can also use relative paths as shown in the following example:
|
||||
<literallayout class='monospaced'>
|
||||
LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\
|
||||
md5=bb14ed3c4cda583abc85401304b5cd4e"
|
||||
LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In this example, the first line locates a file in
|
||||
<filename><link linkend='var-S'>S</link>/src/ls.c</filename>.
|
||||
The second line refers to a file in
|
||||
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, which is the parent
|
||||
of <filename>S</filename>.
|
||||
</para>
|
||||
<para>
|
||||
Note that this variable is mandatory for all recipes, unless the
|
||||
<filename>LICENSE</filename> variable is set to "CLOSED".
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">
|
||||
<title>Explanation of Syntax</title>
|
||||
<para>
|
||||
As mentioned in the previous section, the
|
||||
<filename>LIC_FILES_CHKSUM</filename> variable lists all the
|
||||
important files that contain the license text for the source code.
|
||||
It is possible to specify a checksum for an entire file, or a specific section of a
|
||||
file (specified by beginning and ending line numbers with the "beginline" and "endline"
|
||||
parameters respectively).
|
||||
The latter is useful for source files with a license notice header,
|
||||
README documents, and so forth.
|
||||
If you do not use the "beginline" parameter, then it is assumed that the text begins on the
|
||||
first line of the file.
|
||||
Similarly, if you do not use the "endline" parameter, it is assumed that the license text
|
||||
ends with the last line of the file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The "md5" parameter stores the md5 checksum of the license text.
|
||||
If the license text changes in any way as compared to this parameter
|
||||
then a mismatch occurs.
|
||||
This mismatch triggers a build failure and notifies the developer.
|
||||
Notification allows the developer to review and address the license text changes.
|
||||
Also note that if a mismatch occurs during the build, the correct md5
|
||||
checksum is placed in the build log and can be easily copied to the recipe.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There is no limit to how many files you can specify using the
|
||||
<filename>LIC_FILES_CHKSUM</filename> variable.
|
||||
Generally, however, every project requires a few specifications for license tracking.
|
||||
Many projects have a "COPYING" file that stores the license information for all the source
|
||||
code files.
|
||||
This practice allows you to just track the "COPYING" file as long as it is kept up to date.
|
||||
</para>
|
||||
|
||||
<tip>
|
||||
If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match
|
||||
error and displays the correct "md5" parameter value during the build.
|
||||
The correct parameter is also captured in the build log.
|
||||
</tip>
|
||||
|
||||
<tip>
|
||||
If the whole file contains only license text, you do not need to use the "beginline" and
|
||||
"endline" parameters.
|
||||
</tip>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="usingpoky-configuring-DISTRO_PN_ALIAS">
|
||||
<title>Handling a Package Name Alias</title>
|
||||
<para>
|
||||
Sometimes a package name you are using might exist under an alias or as a similarly named
|
||||
package in a different distribution.
|
||||
The Yocto Project implements a <filename>distro_check</filename>
|
||||
task that automatically connects to major distributions
|
||||
and checks for these situations.
|
||||
If the package exists under a different name in a different distribution, you get a
|
||||
<filename>distro_check</filename> mismatch.
|
||||
You can resolve this problem by defining a per-distro recipe name alias using the
|
||||
<filename><link linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></filename> variable.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Following is an example that shows how you specify the <filename>DISTRO_PN_ALIAS</filename>
|
||||
variable:
|
||||
<literallayout class='monospaced'>
|
||||
DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \
|
||||
distro2=package_name_alias2 \
|
||||
distro3=package_name_alias3 \
|
||||
..."
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you have more than one distribution alias, separate them with a space.
|
||||
Note that the Yocto Project currently automatically checks the
|
||||
Fedora, OpenSuSE, Debian, Ubuntu,
|
||||
and Mandriva distributions for source package recipes without having to specify them
|
||||
using the <filename>DISTRO_PN_ALIAS</filename> variable.
|
||||
For example, the following command generates a report that lists the Linux distributions
|
||||
that include the sources for each of the Yocto Project recipes.
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake world -f -c distro_check
|
||||
</literallayout>
|
||||
The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename>
|
||||
file found in the Yocto Project files area.
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
|
|
|
@ -14,7 +14,7 @@
|
|||
<para>
|
||||
Poky is the Yocto Project build system that was derived from <ulink
|
||||
url='http://www.openembedded.org/'>OpenEmbedded</ulink>.
|
||||
Poky is a stable, smaller subset focused on the GNOME Mobile environment.
|
||||
Poky is a stable, smaller subset focused on the mobile environment.
|
||||
Development in the Yocto Project using Poky is closely tied to OpenEmbedded with
|
||||
features being merged regularly between the two for mutual benefit.
|
||||
</para>
|
||||
|
@ -33,8 +33,8 @@
|
|||
You can use a stand-alone tarball to provide Python 2.6.
|
||||
You can find pre-built 32 and 64-bit versions of Python 2.6 at the following locations:
|
||||
<itemizedlist>
|
||||
<listitem><para><ulink url='http://autobuilder.yoctoproject.org/downloads/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-i686.tar.bz2'>32-bit tarball</ulink></para></listitem>
|
||||
<listitem><para><ulink url='http://autobuilder.yoctoproject.org/downloads/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-x86_64.tar.bz2'>64-bit tarball</ulink></para></listitem>
|
||||
<listitem><para><ulink url='http://downloads.yoctoproject.org/releases/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-i686.tar.bz2'>32-bit tarball</ulink></para></listitem>
|
||||
<listitem><para><ulink url='http://downloads.yoctoproject.org/releases/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-x86_64.tar.bz2'>64-bit tarball</ulink></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
|
@ -237,7 +237,7 @@
|
|||
<question>
|
||||
<para>
|
||||
I see lots of 404 responses for files on
|
||||
<filename>http://autobuilder.yoctoproject.org/sources/*</filename>. Is something wrong?
|
||||
<filename>http://www.yoctoproject.org/sources/*</filename>. Is something wrong?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
|
@ -520,10 +520,10 @@
|
|||
configuration file:
|
||||
<literallayout class='monospaced'>
|
||||
PREMIRRORS_prepend = "\
|
||||
git://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
|
||||
ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
|
||||
http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
|
||||
https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n"
|
||||
git://.*/.* http://www.yoctoproject.org/sources/ \n \
|
||||
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
|
||||
http://.*/.* http://www.yoctoproject.org/sources/ \n \
|
||||
https://.*/.* http://www.yoctoproject.org/sources/ \n"
|
||||
</literallayout>
|
||||
</para>
|
||||
<para>
|
||||
|
@ -564,9 +564,9 @@
|
|||
configuration file as long as the PREMIRROR server is up to date:
|
||||
<literallayout class='monospaced'>
|
||||
PREMIRRORS_prepend = "\
|
||||
ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
|
||||
http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
|
||||
https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n"
|
||||
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
|
||||
http://.*/.* http://www.yoctoproject.org/sources/ \n \
|
||||
https://.*/.* http://www.yoctoproject.org/sources/ \n"
|
||||
BB_FETCH_PREMIRRORONLY = "1"
|
||||
</literallayout>
|
||||
These changes would cause Poky to successfully fetch source over HTTP and
|
||||
|
|
|
@ -15,8 +15,11 @@
|
|||
construct complete Linux images.
|
||||
You can find complete introductory and getting started information on the Yocto Project
|
||||
by reading the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
Yocto Project Quick Start</ulink>.
|
||||
For task-based information using the Yocto Project, see
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html'>
|
||||
The Yocto Project Development Manual</ulink>.
|
||||
You can also find lots of information on the Yocto Project on the
|
||||
<ulink url="http://www.yoctoproject.org">Yocto Project website</ulink>.
|
||||
</para>
|
||||
|
@ -36,6 +39,11 @@
|
|||
<link linkend='extendpoky'>Extending the Yocto Project</link>:</emphasis> This chapter
|
||||
provides information about how to extend and customize the Yocto Project
|
||||
along with advice on how to manage these changes.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='technical-details'>Technical Details</link>:</emphasis>
|
||||
This chapter describes fundamental Yocto Project components as well as an explanation
|
||||
behind how the Yocto Project uses shared state (sstate) cache to speed build time.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='bsp'>Board Support Packages (BSP) - Developer's Guide</link>:</emphasis>
|
||||
This chapter describes the example filesystem layout for BSP development and
|
||||
|
@ -90,9 +98,9 @@
|
|||
<title>System Requirements</title>
|
||||
<para>
|
||||
For system Yocto Project system requirements, see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#resources'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#resources'>
|
||||
What You Need and How You Get It</ulink> section in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
Yocto Project Quick Start</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -104,9 +112,9 @@
|
|||
of methods:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Releases:</emphasis> Stable, tested releases are available through
|
||||
<ulink url='http://yoctoproject.org/downloads/poky/'/>.</para></listitem>
|
||||
<ulink url='http://downloads.yoctoproject.org/releases/yocto/'/>.</para></listitem>
|
||||
<listitem><para><emphasis>Nightly Builds:</emphasis> These releases are available at
|
||||
<ulink url='http://autobuilder.yoctoproject.org/'/>.
|
||||
<ulink url='http://autobuilder.yoctoproject.org/nightly'/>.
|
||||
These builds include Yocto Project releases, meta-toolchain tarballs, and
|
||||
experimental builds.</para></listitem>
|
||||
<listitem><para><emphasis>Yocto Project Website:</emphasis> You can find releases
|
||||
|
@ -125,9 +133,9 @@
|
|||
You can get these files by downloading a Yocto Project release tarball and unpacking it,
|
||||
or by establishing a Git repository of the files.
|
||||
For information on both these methods, see
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-setup'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-setup'>
|
||||
Getting Setup</ulink> section in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
|
||||
The Yocto Project Development Manual</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
|
|
@ -26,7 +26,7 @@
|
|||
<email>richard.purdie@linuxfoundation.org</email>
|
||||
</author>
|
||||
|
||||
<author>
|
||||
<!-- <author>
|
||||
<firstname>Tomas</firstname> <surname>Frydrych</surname>
|
||||
<affiliation>
|
||||
<orgname>Intel Corporation</orgname>
|
||||
|
@ -38,29 +38,39 @@
|
|||
</author>
|
||||
<author>
|
||||
<firstname>Dodji</firstname> <surname>Seketeli</surname>
|
||||
</author>
|
||||
</author> -->
|
||||
</authorgroup>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>4.0+git</revnumber>
|
||||
<date>24 November 2010</date>
|
||||
<revremark>Poky Master Documentation</revremark>
|
||||
<revremark>Released with the Yocto Project 0.9 Release</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>5.0+git</revnumber>
|
||||
<revnumber>1.0</revnumber>
|
||||
<date>6 April 2011</date>
|
||||
<revremark>Released with Yocto Project 1.0 (Bernard 5.0).</revremark>
|
||||
<revremark>Released with the Yocto Project 1.0 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.0.1</revnumber>
|
||||
<date>23 May 2011</date>
|
||||
<revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
|
||||
<revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1</revnumber>
|
||||
<date>6 October 2011</date>
|
||||
<revremark>Released with the Yocto Project 1.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1.1</revnumber>
|
||||
<date>15 March 2012</date>
|
||||
<revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<copyright>
|
||||
<year>2007-2011</year>
|
||||
<year>2007-2012</year>
|
||||
<holder>Linux Foundation</holder>
|
||||
</copyright>
|
||||
|
||||
|
@ -72,7 +82,7 @@
|
|||
<note>
|
||||
Due to production processes, there could be differences between the Yocto Project
|
||||
documentation bundled in the release tarball and
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
The Yocto Project Reference Manual</ulink> on
|
||||
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
|
||||
For the latest version of this manual, see the manual on the website.
|
||||
|
@ -87,6 +97,8 @@
|
|||
|
||||
<xi:include href="extendpoky.xml"/>
|
||||
|
||||
<xi:include href="technical-details.xml"/>
|
||||
|
||||
<xi:include href="../bsp-guide/bsp.xml"/>
|
||||
|
||||
<xi:include href="development.xml"/>
|
||||
|
|
|
@ -122,7 +122,7 @@
|
|||
<filename>task-base.bb</filename>,
|
||||
which in turn leads to packages like <filename>Contacts</filename>,
|
||||
<filename>Dates</filename> and <filename>BusyBox</filename>.
|
||||
These packages in turn depend on glibc and the toolchain.
|
||||
These packages in turn depend on <filename>eglibc</filename> and the toolchain.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -207,9 +207,9 @@
|
|||
It is worth noting that you can greatly speed up the build time by properly setting
|
||||
the <filename>BB_NUMBER_THREADS</filename> variable.
|
||||
See the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
|
||||
Building an Image</ulink> section in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
Yocto Project Quick Start</ulink> for more information.
|
||||
</para>
|
||||
|
||||
|
@ -260,8 +260,50 @@
|
|||
<para>
|
||||
Once all the tasks have been completed BitBake exits.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<para>
|
||||
When running a task, BitBake tightly controls the execution environment
|
||||
of the build tasks to make sure unwanted contamination from the build machine
|
||||
cannot influence the build.
|
||||
Consequently, if you do want something to get passed into the build
|
||||
task's environment, you must take a few steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Tell BitBake to load what you want from the environment
|
||||
into the data store.
|
||||
You can do so through the <filename>BB_ENV_WHITELIST</filename>
|
||||
variable.
|
||||
For example, assume you want to prevent the build system from
|
||||
accessing your <filename>$HOME/.ccache</filename> directory.
|
||||
The following command tells BitBake to load
|
||||
<filename>CCACHE_DIR</filename> from the environment into the data
|
||||
store:
|
||||
<literallayout class='monospaced'>
|
||||
export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR"
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para>Tell BitBake to export what you have loaded into the
|
||||
environment store to the task environment of every running task.
|
||||
Loading something from the environment into the data store
|
||||
(previous step) only makes it available in the datastore.
|
||||
To export it to the task environment of every running task,
|
||||
use a command similar to the following in your
|
||||
<filename>local.conf</filename> or distro configuration file:
|
||||
<literallayout class='monospaced'>
|
||||
export CCACHE_DIR
|
||||
</literallayout></para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<note>
|
||||
A side effect of the previous steps is that BitBake records the variable
|
||||
as a dependency of the build process in things like the shared state
|
||||
checksums.
|
||||
If doing so results in unnecessary rebuilds of tasks, you can whitelist the
|
||||
variable so that the shared state code ignores the dependency when it creates
|
||||
checksums.
|
||||
For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename>
|
||||
example in <xref linkend='checksums'>Checksums (Signatures)</xref>.
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section id='ref-bitbake-commandline'>
|
||||
<title>BitBake Command Line</title>
|
||||
|
|
|
@ -152,8 +152,8 @@
|
|||
|
||||
<para>
|
||||
This class renames packages so that they follow the Debian naming
|
||||
policy (i.e. <filename>glibc</filename> becomes <filename>libc6</filename>
|
||||
and <filename>glibc-devel</filename> becomes <filename>libc6-dev</filename>.
|
||||
policy (i.e. <filename>eglibc</filename> becomes <filename>libc6</filename>
|
||||
and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -387,10 +387,91 @@
|
|||
<para>
|
||||
This class adds a step to the package generation process that sanity checks the
|
||||
packages generated by the Yocto Project.
|
||||
An ever-increasing range of checks are performed that check for
|
||||
common problems that break builds.
|
||||
A range of checks are performed that check the build's output
|
||||
for common problems that show up during runtime.
|
||||
Distribution policy usually dictates whether to include this class as the Yocto Project does.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can configure the sanity checks so that specific test failures either raise a warning or
|
||||
an error message.
|
||||
Typically, failures for new tests generate a warning.
|
||||
Subsequent failures for the same test would then generate an error message
|
||||
once the metadata is in a known and good condition.
|
||||
You use the <filename>WARN_QA</filename> variable to specify tests for which you
|
||||
want to generate a warning message on failure.
|
||||
You use the <filename>ERROR_QA</filename> variable to specify tests for which you
|
||||
want to generate an error message on failure.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following list shows the tests you can list with the <filename>WARN_QA</filename>
|
||||
and <filename>ERROR_QA</filename> variables:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis><filename>ldflags:</filename></emphasis>
|
||||
Ensures that the binaries were linked with the
|
||||
<filename>LDFLAGS</filename> options provided by the build system.
|
||||
If this test fails, check that the <filename>LDFLAGS</filename> variable
|
||||
is being passed to the linker command.</para></listitem>
|
||||
<listitem><para><emphasis><filename>useless-rpaths:</filename></emphasis>
|
||||
Checks for dynamic library load paths (rpaths) in the binaries that
|
||||
by default on a standard system are searched by the linker (e.g.
|
||||
<filename>/lib</filename> and <filename>/usr/lib</filename>).
|
||||
While these paths will not cause any breakage, they do waste space and
|
||||
are unnecessary.</para></listitem>
|
||||
<listitem><para><emphasis><filename>rpaths:</filename></emphasis>
|
||||
Checks for rpaths in the binaries that contain build system paths such
|
||||
as <filename>TMPDIR</filename>.
|
||||
If this test fails, bad <filename>-rpath</filename> options are being
|
||||
passed to the linker commands and your binaries have potential security
|
||||
issues.</para></listitem>
|
||||
<listitem><para><emphasis><filename>dev-so:</filename></emphasis>
|
||||
Checks that the <filename>.so</filename> symbolic links are in the
|
||||
<filename>-dev</filename> package and not in any of the other packages.
|
||||
In general, these symlinks are only useful for development purposes.
|
||||
Thus, the <filename>-dev</filename> package is the correct location for
|
||||
them.
|
||||
Some very rare cases do exist for dynamically loaded modules where
|
||||
these symlinks are needed instead in the main package.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><filename>debug-files:</filename></emphasis>
|
||||
Checks for <filename>.debug</filename> directories in anything but the
|
||||
<filename>-dbg</filename> package.
|
||||
The debug files should all be in the <filename>-dbg</filename> package.
|
||||
Thus, anything packaged elsewhere is incorrect packaging.</para></listitem>
|
||||
<listitem><para><emphasis><filename>arch:</filename></emphasis>
|
||||
Checks the Executable and Linkable Format (ELF) type, bit size and endianness
|
||||
of any binaries to ensure it matches the target architecture.
|
||||
This test fails if any binaries don't match the type since there would be an
|
||||
incompatibility.
|
||||
Sometimes software, like bootloaders, might need to bypass this check.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><filename>debug-deps:</filename></emphasis>
|
||||
Checks that <filename>-dbg</filename> packages only depend on other
|
||||
<filename>-dbg</filename> packages and not on any other types of packages,
|
||||
which would cause a packaging bug.</para></listitem>
|
||||
<listitem><para><emphasis><filename>dev-deps:</filename></emphasis>
|
||||
Checks that <filename>-dev</filename> packages only depend on other
|
||||
<filename>-dev</filename> packages and not on any other types of packages,
|
||||
which would be a packaging bug.</para></listitem>
|
||||
<listitem><para><emphasis><filename>pkgconfig:</filename></emphasis>
|
||||
Checks <filename>.pc</filename> files for any
|
||||
<filename>TMPDIR/WORKDIR</filename> paths.
|
||||
Any <filename>.pc</filename> file containing these paths is incorrect
|
||||
since <filename>pkg-config</filename> itself adds the correct sysroot prefix
|
||||
when the files are accessed.</para></listitem>
|
||||
<listitem><para><emphasis><filename>la:</filename></emphasis>
|
||||
Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
|
||||
paths.
|
||||
Any <filename>.la</filename> file continaing these paths is incorrect since
|
||||
<filename>libtool</filename> adds the correct sysroot prefix when using the
|
||||
files automatically itself.</para></listitem>
|
||||
<listitem><para><emphasis><filename>desktop:</filename></emphasis>
|
||||
Runs the <filename>desktop-file-validate</filename> program against any
|
||||
<filename>.desktop</filename> files to validate their contents against
|
||||
the specification for <filename>.desktop</filename> files.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-siteinfo'>
|
||||
|
@ -403,7 +484,7 @@
|
|||
still make the correct values available.
|
||||
The <filename><link linkend='structure-meta-site'>meta/site directory</link></filename>
|
||||
contains test results sorted into different categories such as architecture, endianness, and
|
||||
the libc used.
|
||||
the <filename>libc</filename> used.
|
||||
Site information provides a list of files containing data relevant to
|
||||
the current build in the
|
||||
<filename><link linkend='var-CONFIG_SITE'>CONFIG_SITE</link></filename> variable
|
||||
|
@ -422,6 +503,21 @@
|
|||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-useradd'>
|
||||
<title>Adding Users - <filename>useradd.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
If you have packages that install files that are owned by custom users or groups,
|
||||
you can use this class to specify those packages and associate the users and groups
|
||||
with those packages.
|
||||
The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename>
|
||||
recipe in the Yocto Project Files provides a simple exmample that shows how to add three
|
||||
users and groups to two packages.
|
||||
See the <filename>useradd-example.bb</filename> for more information on how to
|
||||
use this class.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-others'>
|
||||
<title>Other Classes</title>
|
||||
|
||||
|
@ -436,44 +532,71 @@
|
|||
</section>
|
||||
|
||||
<!-- Undocumented classes are:
|
||||
base_srpm.bbclass
|
||||
allarch.bbclass
|
||||
binconfig.bbclass
|
||||
bootimg.bbclass
|
||||
buildstats.bbclass
|
||||
ccache.inc
|
||||
ccdv.bbclass
|
||||
cmake.bbclass
|
||||
cml1.bbclass
|
||||
cross.bbclass
|
||||
flow-lossage.bbclass
|
||||
cross-canadian.bbclass
|
||||
deploy.bbclass
|
||||
distrodata.bbclass
|
||||
gconf.bbclass
|
||||
gettext.bbclass
|
||||
gnome.bbclass
|
||||
gtk-doc.bbclass
|
||||
gtk-icon-cache.bbclass
|
||||
icecc.bbclass
|
||||
image-mklibs.bbclass
|
||||
image-prelink.bbclass
|
||||
image-swab.bbclass
|
||||
imagetest-dummy.bbclass
|
||||
imagetest-qemu.bbclass
|
||||
insserv.bbclass
|
||||
lib_package.bbclass
|
||||
license.bbclass
|
||||
logging.bbclass
|
||||
meta.bbclass
|
||||
metadata_scm.bbclass
|
||||
mirrors.bbclass
|
||||
mozilla.bbclass
|
||||
multimachine.bbclass
|
||||
multilib*.bbclass
|
||||
native.bbclass
|
||||
nativesdk.bbclass
|
||||
oelint.bbclass
|
||||
own-mirrors.bbclass
|
||||
packagedata.bbclass
|
||||
packagehistory.bbclass
|
||||
patch.bbclass
|
||||
patcher.bbclass
|
||||
perlnative.bbclass
|
||||
pkg_distribute.bbclass
|
||||
pkg_metainfo.bbclass
|
||||
poky.bbclass
|
||||
populate_sdk*.bbclass
|
||||
prserv.bbclass
|
||||
python-dir.bbclass
|
||||
qemu.bbclass
|
||||
qmake*.bbclass
|
||||
qt4*.bbclass
|
||||
recipe_sanity.bbclass
|
||||
relocatable.bbclass
|
||||
rm_work.bbclass
|
||||
rpm_core.bbclass
|
||||
scons.bbclass
|
||||
sdk.bbclass
|
||||
sdl.bbclass
|
||||
setuptools.bbclass
|
||||
sip.bbclass
|
||||
siteconfig.bbclass
|
||||
sourcepkg.bbclass
|
||||
srec.bbclass
|
||||
sstate.bbclass
|
||||
staging.bbclass
|
||||
syslinux.bbclass
|
||||
task.bbclass
|
||||
terminal.bbclass
|
||||
tinderclient.bbclass
|
||||
tmake.bbclass
|
||||
toolchain-scripts.bbclass
|
||||
typecheck.bbclass
|
||||
utility-tasks.bbclass
|
||||
utils.bbclass
|
||||
xfce.bbclass
|
||||
xlibs.bbclass
|
||||
-->
|
||||
|
||||
|
||||
|
|
|
@ -14,9 +14,9 @@
|
|||
|
||||
<para>
|
||||
For information on how to establish the Yocto Project files on your local development system, see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-started'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-started'>
|
||||
Getting Setup</ulink> section in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
|
||||
The Yocto Project Development Manual</ulink>.
|
||||
</para>
|
||||
|
||||
|
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
<para>
|
||||
<link linkend='var-AUTHOR'>A</link>
|
||||
<link linkend='var-BB_NUMBER_THREADS'>B</link>
|
||||
<link linkend='var-BAD_RECOMMENDATIONS'>B</link>
|
||||
<link linkend='var-CFLAGS'>C</link>
|
||||
<link linkend='var-D'>D</link>
|
||||
<link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>E</link>
|
||||
|
@ -25,7 +25,7 @@
|
|||
<link linkend='var-HOMEPAGE'>H</link>
|
||||
<link linkend='var-IMAGE_FEATURES'>I</link>
|
||||
<!-- <link linkend='var-glossary-j'>J</link> -->
|
||||
<link linkend='var-KERNEL_IMAGETYPE'>K</link>
|
||||
<link linkend='var-KERNEL_FEATURES'>K</link>
|
||||
<link linkend='var-LAYERDIR'>L</link>
|
||||
<link linkend='var-MACHINE'>M</link>
|
||||
<!-- <link linkend='var-glossary-n'>N</link> -->
|
||||
|
@ -64,6 +64,14 @@
|
|||
|
||||
<glossdiv id='var-glossary-b'><title>B</title>
|
||||
|
||||
<glossentry id='var-BAD_RECOMMENDATIONS'><glossterm>BAD_RECOMMENDATIONS</glossterm>
|
||||
<glossdef>
|
||||
<para>A list of packages not to install despite being recommended by a recipe.
|
||||
Support for this variable exists only for images that use the
|
||||
<filename>ipkg</filename> packaging system.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
|
||||
<glossdef>
|
||||
<para>The maximum number of tasks BitBake should run in parallel at any one time.
|
||||
|
@ -277,6 +285,7 @@
|
|||
|
||||
<glossentry id='var-DISTRO_EXTRA_RRECOMMENDS'><glossterm>DISTRO_EXTRA_RRECOMMENDS</glossterm>
|
||||
<glossdef>
|
||||
<para></para>
|
||||
<para>The list of packages which extend usability of the image.
|
||||
Those packages will automatically be installed but can be removed by user.</para>
|
||||
</glossdef>
|
||||
|
@ -320,7 +329,8 @@
|
|||
|
||||
<glossentry id='var-ENABLE_BINARY_LOCALE_GENERATION'><glossterm>ENABLE_BINARY_LOCALE_GENERATION</glossterm>
|
||||
<glossdef>
|
||||
<para>Variable that controls which locales for <filename>glibc</filename> are
|
||||
<para></para>
|
||||
<para>Variable that controls which locales for <filename>eglibc</filename> are
|
||||
to be generated during the build (useful if the target device has 64Mbytes
|
||||
of RAM or less).</para>
|
||||
</glossdef>
|
||||
|
@ -360,10 +370,12 @@
|
|||
|
||||
"debug-tweaks" - Makes an image suitable for development.
|
||||
For example, ssh root access has a blank
|
||||
password. There are other application
|
||||
targets too, see
|
||||
meta/classes/poky-image.bbclass
|
||||
and meta/packages/tasks/task-poky.bb
|
||||
password. You should remove this feature
|
||||
before you produce a production image.
|
||||
|
||||
There are other application targets too, see
|
||||
<filename>meta/classes/poky-image.bbclass</filename>
|
||||
and <filename>meta/packages/tasks/task-poky.bb</filename>
|
||||
for more details.
|
||||
</literallayout>
|
||||
</glossdef>
|
||||
|
@ -397,6 +409,37 @@
|
|||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-FILESYSTEM_PERMS_TABLES'><glossterm>FILESYSTEM_PERMS_TABLES</glossterm>
|
||||
<glossdef>
|
||||
<para>Allows you to define your own file permissions settings table as part of
|
||||
your configuration for the packaging process.
|
||||
For example, suppose you need a consistent set of custom permissions for
|
||||
a set of groups and users across an entire work project.
|
||||
It is best to do this in the packages themselves but this is not always
|
||||
possible.
|
||||
</para>
|
||||
<para>
|
||||
By default, the Yocto Project uses the <filename>fs-perms.txt</filename>, which
|
||||
is located in the <filename>meta/files</filename> directory of the Yocto Project
|
||||
files directory.
|
||||
If you create your own file permissions setting table, you should place it in your
|
||||
layer or the distros layer.
|
||||
</para>
|
||||
<para>
|
||||
You define the <filename>FILESYSTEM_PERMS_TABLES</filename> variable in the
|
||||
<filename>conf/local.conf</filename> file, which is found in the Yocto Project's
|
||||
build directory, to point to your custom <filename>fs-perms.txt</filename>.
|
||||
You can specify more than a single file permissions setting table.
|
||||
The paths you specify to these files must be defined within the
|
||||
<filename>BBPATH</filename> variable.
|
||||
</para>
|
||||
<para>
|
||||
For guidance on how to create your own file permissions settings table file,
|
||||
examine the existing <filename>fs-perms.txt</filename>.
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-FULL_OPTIMIZATION'><glossterm>FULL_OPTIMIZATION</glossterm>
|
||||
<glossdef>
|
||||
<para>
|
||||
|
@ -539,6 +582,34 @@
|
|||
|
||||
<glossdiv id='var-glossary-k'><title>K</title>
|
||||
|
||||
<glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
|
||||
<glossdef>
|
||||
<para>Includes additional metadata from the Linux Yocto kernel Git repository.
|
||||
In the Yocto Project build system, the default Board Support Packages (BSPs)
|
||||
metadata is provided through
|
||||
the <filename>KMACHINE</filename> and <filename>KBRANCH</filename> variables.
|
||||
You can use the <filename>KERNEL_FEATURES</filename> variable to further
|
||||
add metadata for all BSPs.</para>
|
||||
<para>The metadata you add through this variable includes config fragments and
|
||||
features descriptions,
|
||||
which usually includes patches as well as config fragments.
|
||||
You typically override the <filename>KERNEL_FEATURES</filename> variable
|
||||
for a specific machine.
|
||||
In this way, you can provide validated, but optional, sets of kernel
|
||||
configurations and features.</para>
|
||||
<para>For example, the following adds <filename>netfilter</filename> to all
|
||||
the Linux Yocto kernels and adds sound support to the <filename>qemux86</filename>
|
||||
machine:
|
||||
<literallayout class='monospaced'>
|
||||
# Add netfilter to all linux-yocto kernels
|
||||
KERNEL_FEATURES="features/netfilter"
|
||||
|
||||
# Add sound support to the qemux86 machine
|
||||
KERNEL_FEATURES_append_qemux86="cfg/sound"
|
||||
</literallayout></para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-KERNEL_IMAGETYPE'><glossterm>KERNEL_IMAGETYPE</glossterm>
|
||||
<glossdef>
|
||||
<para>The type of kernel to build for a device, usually set by the
|
||||
|
@ -622,29 +693,155 @@
|
|||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-MACHINE_ESSENTIAL_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_RDEPENDS</glossterm>
|
||||
<glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</glossterm>
|
||||
<glossdef>
|
||||
<para>Specifies the list of packages required to boot the device.</para>
|
||||
<para></para>
|
||||
<para>
|
||||
A list of required packages to install as part of the package being
|
||||
built.
|
||||
The build process depends on these packages being present.
|
||||
Furthermore, because this is a "machine essential" variable, the list of
|
||||
packages are essential for the machine to boot.
|
||||
The impact of this variable affects images based on <filename>task-core-boot</filename>,
|
||||
including the <filename>core-image-minimal</filename> image.
|
||||
</para>
|
||||
<para>
|
||||
This variable is similar to the
|
||||
<link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link>
|
||||
variable with the exception that the package being built has a build
|
||||
dependency on the variable's list of packages.
|
||||
In other words, the image will not build if a file in this list is not found.
|
||||
</para>
|
||||
<para>
|
||||
For example, suppose you are building a runtime package that depends
|
||||
on a certain disk driver.
|
||||
In this case, you would use the following:
|
||||
<literallayout class='monospaced'>
|
||||
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "<disk_driver>"
|
||||
</literallayout>
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-MACHINE_ESSENTIAL_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_RRECOMMENDS</glossterm>
|
||||
<glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</glossterm>
|
||||
<glossdef>
|
||||
<para>Specifies the list of packages required to boot the device (usually
|
||||
additional kernel modules).</para>
|
||||
<para></para>
|
||||
<para>
|
||||
A list of recommended packages to install as part of the package being
|
||||
built.
|
||||
The build process does not depend on these packages being present.
|
||||
Furthermore, because this is a "machine essential" variable, the list of
|
||||
packages are essential for the machine to boot.
|
||||
The impact of this variable affects images based on <filename>task-core-boot</filename>,
|
||||
including the <filename>core-image-minimal</filename> image.
|
||||
</para>
|
||||
<para>
|
||||
This variable is similar to the
|
||||
<link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link>
|
||||
variable with the exception that the package being built does not have a build
|
||||
dependency on the variable's list of packages.
|
||||
In other words, the image will build if a file in this list is not found.
|
||||
However, because this is one of the "essential" variables, the resulting image
|
||||
might not boot on the machine.
|
||||
Or, if the machine does boot using the image, the machine might not be fully
|
||||
functional.
|
||||
</para>
|
||||
<para>
|
||||
Consider an example where you have a custom kernel with a disk driver
|
||||
built into the kernel itself, rather than using the driver built as a module.
|
||||
If you include the package that has the driver module as part of
|
||||
the variable's list, the
|
||||
build process will not find that package.
|
||||
However, because these packages are "recommends" packages, the build will
|
||||
not fail due to the missing package.
|
||||
Not accounting for any other problems, the custom kernel would still boot the machine.
|
||||
</para>
|
||||
<para>
|
||||
Some example packages of these machine essentials are flash, screen, keyboard, mouse,
|
||||
or touchscreen drivers (depending on the machine).
|
||||
</para>
|
||||
<para>
|
||||
For example, suppose you are building a runtime package that depends
|
||||
on a mouse driver.
|
||||
In this case, you would use the following:
|
||||
<literallayout class='monospaced'>
|
||||
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "<mouse_driver>"
|
||||
</literallayout>
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-MACHINE_EXTRA_RDEPENDS'><glossterm>MACHINE_EXTRA_RDEPENDS</glossterm>
|
||||
<glossdef>
|
||||
<para>Specifies the list of packages required to use the devices</para>
|
||||
<para>
|
||||
A list of optional but non-machine essential packages to install as
|
||||
part of the package being built.
|
||||
Even though these packages are not essential for the machine to boot,
|
||||
the build process depends on them being present.
|
||||
The impact of this variable affects all images based on
|
||||
<filename>task-base</filename>, which does not include the
|
||||
<filename>core-image-minimal</filename> or <filename>core-image-basic</filename>
|
||||
images.
|
||||
</para>
|
||||
<para>
|
||||
This variable is similar to the
|
||||
<link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link>
|
||||
variable with the exception that the package being built has a build
|
||||
dependency on the variable's list of packages.
|
||||
In other words, the image will not build if a file in this list is not found.
|
||||
</para>
|
||||
<para>
|
||||
An example is a machine that might or might not have a WiFi card.
|
||||
The package containing the WiFi support is not essential for the
|
||||
machine to boot the image.
|
||||
If it is not there, the machine will boot but not be able to use the
|
||||
WiFi functionality.
|
||||
However, if you include the package with the WiFi support as part of the
|
||||
variable's package list, the build
|
||||
process depends on finding the package.
|
||||
In this case, you would use the following:
|
||||
<literallayout class='monospaced'>
|
||||
MACHINE_EXTRA_RDEPENDS += "<wifi_driver>"
|
||||
</literallayout>
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-MACHINE_EXTRA_RRECOMMENDS'><glossterm>MACHINE_EXTRA_RRECOMMENDS</glossterm>
|
||||
<glossdef>
|
||||
<para>Specifies the list of packages useful to use the device (e.g.
|
||||
additional kernel modules)</para>
|
||||
<para></para>
|
||||
<para>
|
||||
A list of optional but non-machine essential packages to install as
|
||||
part of the package being built.
|
||||
The package being built has no build dependency on the list of packages
|
||||
with this variable.
|
||||
The impact of this variable affects only images based on
|
||||
<filename>task-base</filename>, which does not include the
|
||||
<filename>core-image-minimal</filename> or <filename>core-image-basic</filename>
|
||||
images.
|
||||
</para>
|
||||
<para>
|
||||
This variable is similar to the
|
||||
<link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link>
|
||||
variable with the exception that the package being built does not have a build
|
||||
dependency on the variable's list of packages.
|
||||
In other words, the image will build if a file in this list is not found.
|
||||
</para>
|
||||
<para>
|
||||
An example is a machine that might or might not have a WiFi card.
|
||||
The package containing the WiFi support is not essential for the
|
||||
machine to boot the image.
|
||||
If it is not there, the machine will boot but not be able to use the
|
||||
WiFi functionality.
|
||||
You are free to either include or not include the
|
||||
the package with the WiFi support as part of the
|
||||
variable's package list, the build
|
||||
process does not depend on finding the package.
|
||||
If you include the package, you would use the following:
|
||||
<literallayout class='monospaced'>
|
||||
MACHINE_EXTRA_RRECOMMENDS += "<wifi_driver>"
|
||||
</literallayout>
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
|
@ -781,10 +978,18 @@
|
|||
|
||||
<glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm>
|
||||
<glossdef>
|
||||
<para>If multiple recipes provide an item, this variable
|
||||
<para>
|
||||
If multiple recipes provide an item, this variable
|
||||
determines which recipe should be given preference.
|
||||
The variable should be set to the <filename>$PN</filename> of the recipe
|
||||
to which you want to give precedence.</para>
|
||||
The variable must always be suffixed with the name of the
|
||||
provided item, and should be set to the
|
||||
<filename>$PN</filename> of the recipe
|
||||
to which you want to give precedence.
|
||||
Here is an example:
|
||||
<literallayout class='monospaced'>
|
||||
PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
|
||||
</literallayout>
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
|
@ -793,8 +998,18 @@
|
|||
<para>
|
||||
If there are multiple versions of recipes available, this
|
||||
variable determines which recipe should be given preference.
|
||||
The variable should be set to the <filename>$PV</filename> of the recipe
|
||||
to whichy you want to give precedence.
|
||||
The variable must always be suffixed with the <filename>$PN</filename>
|
||||
for which to select, and should be set to the
|
||||
<filename>$PV</filename> to which you want to give precedence.
|
||||
You can use the "<filename>%</filename>" character as a wildcard
|
||||
to match any number of characters, which can be useful when
|
||||
specifying versions that contain long revision number that could
|
||||
potentially change.
|
||||
Here are two examples:
|
||||
<literallayout class='monospaced'>
|
||||
PREFERRED_VERSION_python = "2.6.6"
|
||||
PREFERRED_VERSION_linux-yocto = "3.0+git%"
|
||||
</literallayout>
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
@ -809,19 +1024,19 @@
|
|||
|
||||
<glossentry id='var-POKYLIBC'><glossterm>POKYLIBC</glossterm>
|
||||
<glossdef>
|
||||
<para>The <filename>libc</filename> implementation selector.
|
||||
You can select <filename>glibc</filename>, <filename>eglibc</filename>,
|
||||
or <filename>uclibc</filename>.</para>
|
||||
<para>
|
||||
This variable is no longer supported and has been replaced by the
|
||||
<link linkend='var-TCLIBC'><filename>TCLIBC</filename></link> variable.
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-POKYMODE'><glossterm>POKYMODE</glossterm>
|
||||
<glossdef>
|
||||
<para>The toolchain selector.
|
||||
This variable has been replaced by <filename>TCMODE</filename>.
|
||||
The <filename>POKYMODE</filename> would select the external toolchain
|
||||
built from the Yocto Project or a few supported combinations of
|
||||
upstream GCC or CodeSourcery Labs toolchain.</para>
|
||||
<para>
|
||||
This variable is no longer supported and has been replaced by the
|
||||
<link linkend='var-TCMODE'><filename>TCMODE</filename></link> variable.
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
|
@ -843,18 +1058,48 @@
|
|||
<glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
|
||||
<glossdef>
|
||||
<para>
|
||||
A list of run-time dependencies for a package.
|
||||
These packages need to be installed alongside the package to which
|
||||
they apply.
|
||||
This enables the package to run correctly.
|
||||
For example, consider a Perl script, which depends on the Perl package.
|
||||
Since this variable applies to
|
||||
output packages, there would usually be an override attached
|
||||
to this variable such as <filename>RDEPENDS_${PN}-dev</filename>.
|
||||
Names in this field must appear as they appear in the
|
||||
A list of packages that must be installed as part of a package being built.
|
||||
The package being built has a runtime dependency on the packages in the
|
||||
variable's list.
|
||||
In other words, in order for the package being built to run correctly,
|
||||
it depends on these listed packages.
|
||||
If a package in this list cannot be found during the build, the build
|
||||
will not complete.
|
||||
</para>
|
||||
<para>
|
||||
Because the <filename>RDEPENDS</filename> variable applies to packages
|
||||
being built, you should
|
||||
always attach an override to the variable to specify the particular runtime package
|
||||
that has the dependency.
|
||||
For example, suppose you are building a development package that depends
|
||||
on the <filename>perl</filename> package.
|
||||
In this case, you would use the following <filename>RDEPENDS</filename>
|
||||
statement:
|
||||
<literallayout class='monospaced'>
|
||||
RDEPENDS_${PN}-dev += "perl"
|
||||
</literallayout>
|
||||
In the example, the package name (<filename>${PN}-dev</filename>) must
|
||||
appear as it would in the
|
||||
<filename><link linkend='var-PACKAGES'>PACKAGES</link></filename> namespace before any
|
||||
renaming of the output package by classes like <filename>debian.bbclass</filename>.
|
||||
</para>
|
||||
<para>
|
||||
Some automatic handling occurs around the <filename>RDEPENDS</filename>
|
||||
variable:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis><filename>shlibdeps</filename></emphasis>: If a runtime
|
||||
package contains a shared library (<filename>.so</filename>), the build
|
||||
processes the library in order to determine other libraries to which it
|
||||
is dynamically linked.
|
||||
The build process adds these libraries to <filename>RDEPENDS</filename>
|
||||
to create the runtime package.</para></listitem>
|
||||
<listitem><para><emphasis><filename>pcdeps</filename></emphasis>: If the package
|
||||
ships a <filename>pkg-config</filename> information file, the build process
|
||||
uses this file to add items to the <filename>RDEPENDS</filename>
|
||||
variable to create the runtime packages.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
|
@ -866,8 +1111,37 @@
|
|||
|
||||
<glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
|
||||
<glossdef>
|
||||
<para>The list of packages that extend usability of the package.
|
||||
The packages are automatically installed but can be removed by user.</para>
|
||||
<para>
|
||||
A list of packages that extend the usability of a package being
|
||||
built.
|
||||
The package being built does not depend on this list of packages in
|
||||
order to successfully build, but needs them for the extended usability.
|
||||
To specify runtime dependencies for packages, see the
|
||||
<link linkend='var-RDEPENDS'>RDEPENDS</link> variable.
|
||||
</para>
|
||||
<para>
|
||||
The Yocto Project build process automatically installs the list of packages
|
||||
as part of the built package.
|
||||
However, you can remove them later if you want.
|
||||
If, during the build, a package from the list cannot be found, the build
|
||||
process continues without an error.
|
||||
</para>
|
||||
<para>
|
||||
Because the <filename>RRECOMMENDS</filename> variable applies to packages
|
||||
being built, you should
|
||||
always attach an override to the variable to specify the particular package
|
||||
whose usability is being extended.
|
||||
For example, suppose you are building a development package that is extended
|
||||
to support wireless functionality.
|
||||
In this case, you would use the following:
|
||||
<literallayout class='monospaced'>
|
||||
RRECOMMENDS_${PN}-dev += "<wireless_package_name>"
|
||||
</literallayout>
|
||||
In the example, the package name (<filename>${PN}-dev</filename>) must
|
||||
appear as it would in the
|
||||
<filename><link linkend='var-PACKAGES'>PACKAGES</link></filename> namespace before any
|
||||
renaming of the output package by classes like <filename>debian.bbclass</filename>.
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
|
@ -961,6 +1235,7 @@
|
|||
|
||||
<glossentry id='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'><glossterm>SRC_URI_OVERRIDES_PACKAGE_ARCH</glossterm>
|
||||
<glossdef>
|
||||
<para></para>
|
||||
<para>
|
||||
By default, the Yocto Project automatically detects whether
|
||||
<filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>
|
||||
|
@ -1057,23 +1332,51 @@
|
|||
<glossentry id='var-TARGET_OS'><glossterm>TARGET_OS</glossterm>
|
||||
<glossdef>
|
||||
<para>Specifies the target's operating system.
|
||||
The variable can be set to "linux" for <filename>glibc</filename>-based systems and
|
||||
"linux-uclibc" for <filename>uClibc</filename>.
|
||||
The variable can be set to "linux" for <filename>eglibc</filename>-based systems and
|
||||
to "linux-uclibc" for <filename>uclibc</filename>.
|
||||
For ARM/EABI targets, there are also "linux-gnueabi" and
|
||||
"linux-uclibc-gnueabi" values possible.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
|
||||
<glossdef>
|
||||
<para>
|
||||
Specifies which variant of the GNU standard C library (<filename>libc</filename>)
|
||||
to use during the build process.
|
||||
This variable replaces <filename>POKYLIBC</filename>, which is no longer
|
||||
supported.
|
||||
</para>
|
||||
<para>
|
||||
You can select <filename>eglibc</filename> or <filename>uclibc</filename>.
|
||||
<note>
|
||||
This release of the Yocto Project does not support the
|
||||
<filename>glibc</filename> implementation of <filename>libc</filename>.
|
||||
</note>
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-TCMODE'><glossterm>TCMODE</glossterm>
|
||||
<glossdef>
|
||||
<para>The toolchain selector.
|
||||
This variable replaces <filename>POKYMODE</filename>.
|
||||
<para>
|
||||
The toolchain selector.
|
||||
This variable replaces <filename>POKYMODE</filename>, which is no longer
|
||||
supported.
|
||||
</para>
|
||||
<para>
|
||||
The <filename>TCMODE</filename> variable selects the external toolchain
|
||||
built from the Yocto Project or a few supported combinations of
|
||||
the upstream GCC or CodeSourcery Labs toolchain.
|
||||
The variable determines which of the files in
|
||||
<filename>meta/conf/distro/include/tcmode-*</filename> is used.
|
||||
</para>
|
||||
<para>
|
||||
By default, <filename>TCMODE</filename> is set to "default", which
|
||||
chooses <filename>tcmode-default.inc</filename>.</para>
|
||||
<para>The variable is similar to <filename>TCLIBC</filename>, which controls the
|
||||
<filename>libc</filename> used: <filename>eglibc</filename> or <filename>uclibc</filename>.
|
||||
chooses <filename>tcmode-default.inc</filename>.
|
||||
The variable is similar to <filename>TCLIBC</filename>, which controls
|
||||
the variant of the GNU standard C library (<filename>libc</filename>)
|
||||
used during the build process: <filename>eglibc</filename> or <filename>uclibc</filename>.
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
|
|
@ -71,10 +71,10 @@
|
|||
</link></filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS
|
||||
</link></filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_RDEPENDS'>MACHINE_ESSENTIAL_RDEPENDS
|
||||
<listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS
|
||||
</link></filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_RRECOMMENDS'>
|
||||
MACHINE_ESSENTIAL_RRECOMMENDS</link></filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>
|
||||
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
|
|
@ -10,9 +10,9 @@
|
|||
The Yocto Project team is happy for people to experiment with the Yocto Project.
|
||||
A number of places exist to find help if you run into difficulties or find bugs.
|
||||
To find out how to download source code,
|
||||
see the <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#local-yp-release'>
|
||||
see the <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-yp-release'>
|
||||
Yocto Project Release</ulink> list item in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The Yocto
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto
|
||||
Project Development Manual</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -32,13 +32,16 @@
|
|||
<para>
|
||||
To subscribe to the Yocto Project mailing lists, click on the following URLs and follow the instructions:
|
||||
<itemizedlist>
|
||||
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> for a
|
||||
Yocto Discussions mailing list.</para></listitem>
|
||||
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a
|
||||
Yocto Project Discussions mailing list.</para></listitem>
|
||||
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink> for a
|
||||
mailing list to receive offical Yocto Project announcements for developments and
|
||||
as well as Yocto Project milestones.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink></emphasis>:
|
||||
Use this list to receive offical Yocto Project announcements for developments and
|
||||
to learn about Yocto Project milestones.</para></listitem>
|
||||
<listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink></emphasis>:
|
||||
Use this list to monitor Yocto Project development discussions, ask questions, and
|
||||
get help.</para></listitem>
|
||||
<listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink></emphasis>:
|
||||
Use this list to monitor discussions about the Yocto Project build system Poky,
|
||||
ask questions, and get help.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -90,44 +93,14 @@
|
|||
<title>Contributions</title>
|
||||
|
||||
<para>
|
||||
Contributions to the Yocto Project are very welcome.
|
||||
You should send patches to the Yocto Project mailing list along with a "signed-off-by:"
|
||||
line in the same style as required by the Linux kernel.
|
||||
Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1
|
||||
as follows:
|
||||
<literallayout class='monospaced'>
|
||||
Developer's Certificate of Origin 1.1
|
||||
|
||||
By making a contribution to this project, I certify that:
|
||||
|
||||
(a) The contribution was created in whole or in part by me and I
|
||||
have the right to submit it under the open source license
|
||||
indicated in the file; or
|
||||
|
||||
(b) The contribution is based upon previous work that, to the best
|
||||
of my knowledge, is covered under an appropriate open source
|
||||
license and I have the right under that license to submit that
|
||||
work with modifications, whether created in whole or in part
|
||||
by me, under the same open source license (unless I am
|
||||
permitted to submit under a different license), as indicated
|
||||
in the file; or
|
||||
|
||||
(c) The contribution was provided directly to me by some other
|
||||
person who certified (a), (b) or (c) and I have not modified
|
||||
it.
|
||||
|
||||
(d) I understand and agree that this project and the contribution
|
||||
are public and that a record of the contribution (including all
|
||||
personal information I submit with it, including my sign-off) is
|
||||
maintained indefinitely and may be redistributed consistent with
|
||||
this project or the open source license(s) involved.
|
||||
</literallayout>
|
||||
A Poky contributions tree (<filename>poky-contrib</filename>,
|
||||
<filename>git://git.yoctoproject.org/poky-contrib.git</filename>)
|
||||
exists for contributors to stage contributions.
|
||||
If people desire such access, please ask on the mailing list.
|
||||
Usually, the Yocto Project team will grant access to anyone with a proven track
|
||||
record of good patches.
|
||||
The Yocto Project gladly accepts contributions.
|
||||
You can submit changes to the project either by creating and sending pull requests,
|
||||
or by submitting patches through email.
|
||||
For information on how to do both, see
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#how-to-submit-a-change'>
|
||||
How to Submit a Change</ulink> in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
|
||||
The Yocto Project Development Manual</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
|
@ -0,0 +1,574 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||||
<chapter id='technical-details'>
|
||||
<title>Technical Details</title>
|
||||
|
||||
<para>
|
||||
This chapter provides technical details for various parts of the Yocto Project.
|
||||
Currently, topics include Yocto Project components and shared state (sstate) cache.
|
||||
</para>
|
||||
|
||||
<section id='usingpoky-components'>
|
||||
<title>Yocto Project Components</title>
|
||||
|
||||
<para>
|
||||
The BitBake task executor together with various types of configuration files form the
|
||||
Yocto Project core.
|
||||
This section overviews the BitBake task executor and the
|
||||
configuration files by describing what they are used for and how they interact.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
BitBake handles the parsing and execution of the data files.
|
||||
The data itself is of various types:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Recipes:</emphasis> Provides details about particular
|
||||
pieces of software</para></listitem>
|
||||
<listitem><para><emphasis>Class Data:</emphasis> An abstraction of common build
|
||||
information (e.g. how to build a Linux kernel).</para></listitem>
|
||||
<listitem><para><emphasis>Configuration Data:</emphasis> Defines machine-specific settings,
|
||||
policy decisions, etc.
|
||||
Configuration data acts as the glue to bind everything together.</para></listitem>
|
||||
</itemizedlist>
|
||||
For more information on data, see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html#yocto-project-terms'>
|
||||
Yocto Project Terms</ulink> section in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html'>
|
||||
The Yocto Project Development Manual</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
BitBake knows how to combine multiple data sources together and refers to each data source
|
||||
as a "<link linkend='usingpoky-changes-layers'>layer</link>".
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Following are some brief details on these core components.
|
||||
For more detailed information on these components see the
|
||||
<link linkend='ref-structure'>'Reference: Directory Structure'</link>
|
||||
appendix.
|
||||
</para>
|
||||
|
||||
<section id='usingpoky-components-bitbake'>
|
||||
<title>BitBake</title>
|
||||
|
||||
<para>
|
||||
BitBake is the tool at the heart of the Yocto Project and is responsible
|
||||
for parsing the metadata, generating a list of tasks from it,
|
||||
and then executing those tasks.
|
||||
To see a list of the options BitBake supports, use the following help command:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake --help
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The most common usage for BitBake is <filename>bitbake <packagename></filename>, where
|
||||
<filename>packagename</filename> is the name of the package you want to build
|
||||
(referred to as the "target" in this manual).
|
||||
The target often equates to the first part of a <filename>.bb</filename> filename.
|
||||
So, to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you
|
||||
might type the following:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake matchbox-desktop
|
||||
</literallayout>
|
||||
Several different versions of <filename>matchbox-desktop</filename> might exist.
|
||||
BitBake chooses the one selected by the distribution configuration.
|
||||
You can get more details about how BitBake chooses between different
|
||||
target versions and providers in the
|
||||
<link linkend='ref-bitbake-providers'>Preferences and Providers</link> section.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
BitBake also tries to execute any dependent tasks first.
|
||||
So for example, before building <filename>matchbox-desktop</filename>, BitBake
|
||||
would build a cross compiler and <filename>eglibc</filename> if they had not already
|
||||
been built.
|
||||
<note>This release of the Yocto Project does not support the <filename>glibc</filename>
|
||||
GNU version of the Unix standard C library. By default, the Yocto Project builds with
|
||||
<filename>eglibc</filename>.</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A useful BitBake option to consider is the <filename>-k</filename> or
|
||||
<filename>--continue</filename> option.
|
||||
This option instructs BitBake to try and continue processing the job as much
|
||||
as possible even after encountering an error.
|
||||
When an error occurs, the target that
|
||||
failed and those that depend on it cannot be remade.
|
||||
However, when you use this option other dependencies can still be processed.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-components-metadata'>
|
||||
<title>Metadata (Recipes)</title>
|
||||
|
||||
<para>
|
||||
The <filename>.bb</filename> files are usually referred to as "recipes."
|
||||
In general, a recipe contains information about a single piece of software.
|
||||
The information includes the location from which to download the source patches
|
||||
(if any are needed), which special configuration options to apply,
|
||||
how to compile the source files, and how to package the compiled output.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The term "package" can also be used to describe recipes.
|
||||
However, since the same word is used for the packaged output from the Yocto
|
||||
Project (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
|
||||
this document avoids using the term "package" when refering to recipes.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-components-classes'>
|
||||
<title>Classes</title>
|
||||
|
||||
<para>
|
||||
Class files (<filename>.bbclass</filename>) contain information that is useful to share
|
||||
between metadata files.
|
||||
An example is the Autotools class, which contains
|
||||
common settings for any application that Autotools uses.
|
||||
The <link linkend='ref-classes'>Reference: Classes</link> appendix provides details
|
||||
about common classes and how to use them.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-components-configuration'>
|
||||
<title>Configuration</title>
|
||||
|
||||
<para>
|
||||
The configuration files (<filename>.conf</filename>) define various configuration variables
|
||||
that govern the Yocto Project build process.
|
||||
These files fall into several areas that define machine configuration options,
|
||||
distribution configuration options, compiler tuning options, general common configuration
|
||||
options and user configuration options (<filename>local.conf</filename>, which is found
|
||||
in the Yocto Project files build directory).
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="shared-state-cache">
|
||||
<title>Shared State Cache</title>
|
||||
|
||||
<para>
|
||||
By design, the Yocto Project build system builds everything from scratch unless
|
||||
BitBake can determine that parts don't need to be rebuilt.
|
||||
Fundamentally, building from scratch is attractive as it means all parts are
|
||||
built fresh and there is no possibility of stale data causing problems.
|
||||
When developers hit problems, they typically default back to building from scratch
|
||||
so they know the state of things from the start.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Building an image from scratch is both an advantage and a disadvantage to the process.
|
||||
As mentioned in the previous paragraph, building from scratch ensures that
|
||||
everything is current and starts from a known state.
|
||||
However, building from scratch also takes much longer as it generally means
|
||||
rebuiding things that don't necessarily need rebuilt.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Yocto Project implements shared state code that supports incremental builds.
|
||||
The implementation of the shared state code answers the following questions that
|
||||
were fundamental roadblocks within the Yocto Project incremental build support system:
|
||||
<itemizedlist>
|
||||
<listitem>What pieces of the system have changed and what pieces have not changed?</listitem>
|
||||
<listitem>How are changed pieces of software removed and replaced?</listitem>
|
||||
<listitem>How are pre-built components that don't need to be rebuilt from scratch
|
||||
used when they are available?</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For the first question, the build system detects changes in the "inputs" to a given task by
|
||||
creating a checksum (or signature) of the task's inputs.
|
||||
If the checksum changes, the system assumes the inputs have changed and the task needs to be
|
||||
rerun.
|
||||
For the second question, the shared state (sstate) code tracks which tasks add which output
|
||||
to the build process.
|
||||
This means the output from a given task can be removed, upgraded or otherwise manipulated.
|
||||
The third question is partly addressed by the solution for the second question
|
||||
assuming the build system can fetch the sstate objects from remote locations and
|
||||
install them if they are deemed to be valid.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The rest of this section goes into detail about the overall incremental build
|
||||
architecture, the checksums (signatures), shared state, and some tips and tricks.
|
||||
</para>
|
||||
|
||||
<section id='overall-architecture'>
|
||||
<title>Overall Architecture</title>
|
||||
|
||||
<para>
|
||||
When determining what parts of the system need to be built, BitBake
|
||||
uses a per-task basis and does not use a per-recipe basis.
|
||||
You might wonder why using a per-task basis is preferred over a per-recipe basis.
|
||||
To help explain, consider having the IPK packaging backend enabled and then switching to DEB.
|
||||
In this case, <filename>do_install</filename> and <filename>do_package</filename>
|
||||
output are still valid.
|
||||
However, with a per-recipe approach, the build would not include the
|
||||
<filename>.deb</filename> files.
|
||||
Consequently, you would have to invalidate the whole build and rerun it.
|
||||
Rerunning everything is not the best situation.
|
||||
Also in this case, the core must be "taught" much about specific tasks.
|
||||
This methodology does not scale well and does not allow users to easily add new tasks
|
||||
in layers or as external recipes without touching the packaged-staging core.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='checksums'>
|
||||
<title>Checksums (Signatures)</title>
|
||||
|
||||
<para>
|
||||
The shared state code uses a checksum, which is a unique signature of a task's
|
||||
inputs, to determine if a task needs to be run again.
|
||||
Because it is a change in a task's inputs that triggers a rerun, the process
|
||||
needs to detect all the inputs to a given task.
|
||||
For shell tasks, this turns out to be fairly easy because
|
||||
the build process generates a "run" shell script for each task and
|
||||
it is possible to create a checksum that gives you a good idea of when
|
||||
the task's data changes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To complicate the problem, there are things that should not be included in
|
||||
the checksum.
|
||||
First, there is the actual specific build path of a given task -
|
||||
the <filename>WORKDIR</filename>.
|
||||
It does not matter if the working directory changes because it should not
|
||||
affect the output for target packages.
|
||||
Also, the build process has the objective of making native/cross packages relocatable.
|
||||
The checksum therefore needs to exclude <filename>WORKDIR</filename>.
|
||||
The simplistic approach for excluding the worknig directory is to set
|
||||
<filename>WORKDIR</filename> to some fixed value and create the checksum
|
||||
for the "run" script.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Another problem results from the "run" scripts containing functions that
|
||||
might or might not get called.
|
||||
The incremental build solution contains code that figures out dependencies
|
||||
between shell functions.
|
||||
This code is used to prune the "run" scripts down to the minimum set,
|
||||
thereby alleviating this problem and making the "run" scripts much more
|
||||
readable as a bonus.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
So far we have solutions for shell scripts.
|
||||
What about python tasks?
|
||||
The same approach applies even though these tasks are more difficult.
|
||||
The process needs to figure out what variables a python function accesses
|
||||
and what functions it calls.
|
||||
Again, the incremental build solution contains code that first figures out
|
||||
the variable and function dependencies, and then creates a checksum for the data
|
||||
used as the input to the task.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Like the <filename>WORKDIR</filename> case, situations exist where dependencies
|
||||
should be ignored.
|
||||
For these cases, you can instruct the build process to ignore a dependency
|
||||
by using a line like the following:
|
||||
<literallayout class='monospaced'>
|
||||
PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
|
||||
</literallayout>
|
||||
This example ensures that the <filename>PACKAGE_ARCHS</filename> variable does not
|
||||
depend on the value of <filename>MACHINE</filename>, even if it does reference it.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Equally, there are cases where we need to add dependencies BitBake is not able to find.
|
||||
You can accomplish this by using a line like the following:
|
||||
<literallayout class='monospaced'>
|
||||
PACKAGE_ARCHS[vardeps] = "MACHINE"
|
||||
</literallayout>
|
||||
This example explicitly adds the <filename>MACHINE</filename> variable as a
|
||||
dependency for <filename>PACKAGE_ARCHS</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Consider a case with inline python, for example, where BitBake is not
|
||||
able to figure out dependencies.
|
||||
When running in debug mode (i.e. using <filename>-DDD</filename>), BitBake
|
||||
produces output when it discovers something for which it cannot figure out
|
||||
dependencies.
|
||||
The Yocto Project team has currently not managed to cover those dependencies
|
||||
in detail and is aware of the need to fix this situation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Thus far, this section has limited discussion to the direct inputs into a task.
|
||||
Information based on direct inputs is referred to as the "basehash" in the code.
|
||||
However, there is still the question of a task's indirect inputs, the things that
|
||||
were already built and present in the build directory.
|
||||
The checksum (or signature) for a particular task needs to add the hashes of all the
|
||||
tasks on which the particular task depends.
|
||||
Choosing which dependencies to add is a policy decision.
|
||||
However, the effect is to generate a master checksum that combines the
|
||||
basehash and the hashes of the task's dependencies.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
While figuring out the dependencies and creating these checksums is good,
|
||||
what does the Yocto Project build system do with the checksum information?
|
||||
The build system uses a signature handler that is responsible for
|
||||
processing the checksum information.
|
||||
By default, there is a dummy "noop" signature handler enabled in BitBake.
|
||||
This means that behaviour is unchanged from previous versions.
|
||||
OECore uses the "basic" signature handler through this setting in the
|
||||
<filename>bitbake.conf</filename> file:
|
||||
<literallayout class='monospaced'>
|
||||
BB_SIGNATURE_HANDLER ?= "basic"
|
||||
</literallayout>
|
||||
Also within the BitBake configuration file, we can give BitBake
|
||||
some extra information to help it handle this information.
|
||||
The following statements effectively result in a list of global
|
||||
variable dependency excludes - variables never included in
|
||||
any checksum:
|
||||
<literallayout class='monospaced'>
|
||||
BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH"
|
||||
BB_HASHBASE_WHITELIST += "DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS"
|
||||
BB_HASHBASE_WHITELIST += "FILE_DIRNAME HOME LOGNAME SHELL TERM USER"
|
||||
BB_HASHBASE_WHITELIST += "FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET"
|
||||
BB_HASHTASK_WHITELIST += "(.*-cross$|.*-native$|.*-cross-initial$| \
|
||||
.*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)"
|
||||
</literallayout>
|
||||
This example is actually where <filename>WORKDIR</filename>
|
||||
is excluded since <filename>WORKDIR</filename> is constructed as a
|
||||
path within <filename>TMPDIR</filename>, which is on the whitelist.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>BB_HASHTASK_WHITELIST</filename> covers dependent tasks and
|
||||
excludes certain kinds of tasks from the dependency chains.
|
||||
The effect of the previous example is to isolate the native, target,
|
||||
and cross-components.
|
||||
So, for example, toolchain changes do not force a rebuild of the whole system.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The end result of the "basic" handler is to make some dependency and
|
||||
hash information available to the build.
|
||||
This includes:
|
||||
<literallayout class='monospaced'>
|
||||
BB_BASEHASH_task-<taskname> - the base hashes for each task in the recipe
|
||||
BB_BASEHASH_<filename:taskname> - the base hashes for each dependent task
|
||||
BBHASHDEPS_<filename:taskname> - The task dependencies for each task
|
||||
BB_TASKHASH - the hash of the currently running task
|
||||
</literallayout>
|
||||
There is also a "basichash" <filename>BB_SIGNATURE_HANDLER</filename>,
|
||||
which is the same as the basic version but adds the task hash to the stamp files.
|
||||
This results in any metadata change that changes the task hash,
|
||||
automatically causing the task to be run again.
|
||||
This removes the need to bump <filename>PR</filename>
|
||||
values and changes to metadata automatically ripple across the build.
|
||||
Currently, this behavior is not the default behavior.
|
||||
However, it is likely that the Yocto Project team will go forward with this
|
||||
behavior in the future since all the functionality exists.
|
||||
The reason for the delay is the potential impact to the distribution feed
|
||||
creation as they need increasing <filename>PR</filename> fields
|
||||
and the Yocto Project currently lacks a mechanism to automate incrementing
|
||||
this field.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='shared-state'>
|
||||
<title>Shared State</title>
|
||||
|
||||
<para>
|
||||
Checksums and dependencies, as discussed in the previous section, solve half the
|
||||
problem.
|
||||
The other part of the problem is being able to use checksum information during the build
|
||||
and being able to reuse or rebuild specific components.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The shared state class (<filename>sstate.bbclass</filename>)
|
||||
is a relatively generic implementation of how to "capture" a snapshot of a given task.
|
||||
The idea is that the build process does not care about the source of a task's output.
|
||||
Output could be freshly built or it could be downloaded and unpacked from
|
||||
somewhere - the build process doesn't need to worry about its source.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There are two types of output, one is just about creating a directory
|
||||
in <filename>WORKDIR</filename>.
|
||||
A good example is the output of either <filename>do_install</filename> or
|
||||
<filename>do_package</filename>.
|
||||
The other type of output occurs when a set of data is merged into a shared directory
|
||||
tree such as the sysroot.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Yocto Project team has tried to keep the details of the implementation hidden in
|
||||
<filename>sstate.bbclass</filename>.
|
||||
From a user's perspective, adding shared state wrapping to a task
|
||||
is as simple as this <filename>do_deploy</filename> example taken from
|
||||
<filename>do_deploy.bbclass</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
|
||||
SSTATETASKS += "do_deploy"
|
||||
do_deploy[sstate-name] = "deploy"
|
||||
do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
|
||||
do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
|
||||
|
||||
python do_deploy_setscene () {
|
||||
sstate_setscene(d)
|
||||
}
|
||||
addtask do_deploy_setscene
|
||||
</literallayout>
|
||||
In the example, we add some extra flags to the task, a name field ("deploy"), an
|
||||
input directory where the task sends data, and the output
|
||||
directory where the data from the task should eventually be copied.
|
||||
We also add a <filename>_setscene</filename> variant of the task and add the task
|
||||
name to the <filename>SSTATETASKS</filename> list.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you have a directory whose contents you need to preserve, you can do this with
|
||||
a line like the following:
|
||||
<literallayout class='monospaced'>
|
||||
do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
|
||||
</literallayout>
|
||||
This method, as well as the following example, also works for mutliple directories.
|
||||
<literallayout class='monospaced'>
|
||||
do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
|
||||
do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
|
||||
do_package[sstate-lockfile] = "${PACKAGELOCK}"
|
||||
</literallayout>
|
||||
These methods also include the ability to take a lockfile when manipulating
|
||||
shared state directory structures since some cases are sensitive to file
|
||||
additions or removals.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Behind the scenes, the shared state code works by looking in
|
||||
<filename>SSTATE_DIR</filename> and
|
||||
<filename>SSTATE_MIRRORS</filename> for shared state files.
|
||||
Here is an example:
|
||||
<literallayout class='monospaced'>
|
||||
SSTATE_MIRRORS ?= "\
|
||||
file://.* http://someserver.tld/share/sstate/ \n \
|
||||
file://.* file:///some/local/dir/sstate/"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The shared state package validity can be detected just by looking at the
|
||||
filename since the filename contains the task checksum (or signature) as
|
||||
described earlier in this section.
|
||||
If a valid shared state package is found, the build process downloads it
|
||||
and uses it to accelerate the task.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The build processes uses the <filename>*_setscene</filename> tasks
|
||||
for the task acceleration phase.
|
||||
BitBake goes through this phase before the main execution code and tries
|
||||
to accelerate any tasks for which it can find shared state packages.
|
||||
If a shared state package for a task is available, the shared state
|
||||
package is used.
|
||||
This means the task and any tasks on which it is dependent are not
|
||||
executed.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
As a real world example, the aim is when building an IPK-based image,
|
||||
only the <filename>do_package_write_ipk</filename> tasks would have their
|
||||
shared state packages fetched and extracted.
|
||||
Since the sysroot is not used, it would never get extracted.
|
||||
This is another reason why a task-based approach is preferred over a
|
||||
recipe-based approach, which would have to install the output from every task.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='tips-and-tricks'>
|
||||
<title>Tips and Tricks</title>
|
||||
|
||||
<para>
|
||||
The code in the Yocto Project that supports incremental builds is not
|
||||
simple code.
|
||||
This section presents some tips and tricks that help you work around
|
||||
issues related to shared state code.
|
||||
</para>
|
||||
|
||||
<section id='debugging'>
|
||||
<title>Debugging</title>
|
||||
|
||||
<para>
|
||||
When things go wrong, debugging needs to be straightforward.
|
||||
Because of this, the Yocto Project team included strong debugging
|
||||
tools:
|
||||
<itemizedlist>
|
||||
<listitem><para>Whenever a shared state package is written out, so is a
|
||||
corresponding <filename>.siginfo</filename> file.
|
||||
This practice results in a pickled python database of all
|
||||
the metadata that went into creating the hash for a given shared state
|
||||
package.</para></listitem>
|
||||
<listitem><para>If BitBake is run with the <filename>--dump-signatures</filename>
|
||||
(or <filename>-S</filename>) option, BitBake dumps out
|
||||
<filename>.siginfo</filename> files in
|
||||
the stamp directory for every task it would have executed instead of
|
||||
building the specified target package.</para></listitem>
|
||||
<listitem><para>There is a <filename>bitbake-diffsigs</filename> command that
|
||||
can process these <filename>.siginfo</filename> files.
|
||||
If one file is specified, it will dump out the dependency
|
||||
information in the file.
|
||||
If two files are specified, it will compare the two files and dump out
|
||||
the differences between the two.
|
||||
This allows the question of "What changed between X and Y?" to be
|
||||
answered easily.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='invalidating-shared-state'>
|
||||
<title>Invalidating Shared State</title>
|
||||
|
||||
<para>
|
||||
The shared state code uses checksums and shared state memory
|
||||
cache to avoid unnecessarily rebuilding tasks.
|
||||
As with all schemes, this one has some drawbacks.
|
||||
It is possible that you could make implicit changes that are not factored
|
||||
into the checksum calculation, but do affect a task's output.
|
||||
A good example is perhaps when a tool changes its output.
|
||||
Let's say that the output of <filename>rpmdeps</filename> needed to change.
|
||||
The result of the change should be that all the "package", "package_write_rpm",
|
||||
and "package_deploy-rpm" shared state cache items would become invalid.
|
||||
But, because this is a change that is external to the code and therefore implicit,
|
||||
the associated shared state cache items do not become invalidated.
|
||||
In this case, the build process would use the cached items rather than running the
|
||||
task again.
|
||||
Obviously, these types of implicit changes can cause problems.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To avoid these problems during the build, you need to understand the effects of any
|
||||
change you make.
|
||||
Note that any changes you make directly to a function automatically are factored into
|
||||
the checksum calculation and thus, will invalidate the associated area of sstate cache.
|
||||
You need to be aware of any implicit changes that are not obvious changes to the
|
||||
code and could affect the output of a given task.
|
||||
Once you are aware of such a change, you can take steps to invalidate the cache
|
||||
and force the task to run.
|
||||
The step to take is as simple as changing a function's comments in the source code.
|
||||
For example, to invalidate package shared state files, change the comment statments
|
||||
of <filename>do_package</filename> or the comments of one of the functions it calls.
|
||||
The change is purely cosmetic, but it causes the checksum to be recalculated and
|
||||
forces the task to be run again.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
For an example of a commit that makes a cosmetic change to invalidate
|
||||
a shared state, see this
|
||||
<ulink url='http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>.
|
||||
</note>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
|
@ -4,164 +4,33 @@
|
|||
<title>Using the Yocto Project</title>
|
||||
|
||||
<para>
|
||||
This section gives an overview of the components that make up the Yocto Project
|
||||
followed by information about Yocto Project builds and dealing with any
|
||||
problems that might arise.
|
||||
This chapter describes common usage for the Yocto Project.
|
||||
The information is introductory in nature as other manuals in the Yocto Project
|
||||
provide more details on how to use the Yocto Project.
|
||||
</para>
|
||||
|
||||
<section id='usingpoky-components'>
|
||||
<title>Yocto Project Components</title>
|
||||
|
||||
<para>
|
||||
The BitBake task executor together with various types of configuration files form the
|
||||
Yocto Project core.
|
||||
This section overviews the BitBake task executor and the
|
||||
configuration files by describing what they are used for and they they interact.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
BitBake handles the parsing and execution of the data files.
|
||||
The data itself is of various types:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Recipes:</emphasis> Provides details about particular
|
||||
pieces of software</para></listitem>
|
||||
<listitem><para><emphasis>Class Data:</emphasis> An abstraction of common build
|
||||
information (e.g. how to build a Linux kernel).</para></listitem>
|
||||
<listitem><para><emphasis>Configuration Data:</emphasis> Defines machine-specific settings,
|
||||
policy decisions, etc.
|
||||
Configuration data acts a the glue to bind everything together.</para></listitem>
|
||||
</itemizedlist>
|
||||
For more information on data, see the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#yocto-project-terms'>
|
||||
Yocto Project Terms</ulink> section in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
|
||||
The Yocto Project Development Manual</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
BitBake knows how to combine multiple data sources together and refers to each data source
|
||||
as a <link linkend='usingpoky-changes-layers'>'layer'</link>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Following are some brief details on these core components.
|
||||
For more detailed information on these components see the
|
||||
<link linkend='ref-structure'>'Reference: Directory Structure'</link>
|
||||
appendix.
|
||||
</para>
|
||||
|
||||
<section id='usingpoky-components-bitbake'>
|
||||
<title>BitBake</title>
|
||||
|
||||
<para>
|
||||
BitBake is the tool at the heart of the Yocto Project and is responsible
|
||||
for parsing the metadata, generating a list of tasks from it,
|
||||
and then executing those tasks.
|
||||
To see a list of the options BitBake supports, use the following help command:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake --help
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The most common usage for BitBake is <filename>bitbake <packagename></filename>, where
|
||||
<filename>packagename</filename> is the name of the package you want to build
|
||||
(referred to as the "target" in this manual).
|
||||
The target often equates to the first part of a <filename>.bb</filename> filename.
|
||||
So, to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you
|
||||
might type the following:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake matchbox-desktop
|
||||
</literallayout>
|
||||
Several different versions of <filename>matchbox-desktop</filename> might exist.
|
||||
BitBake chooses the one selected by the distribution configuration.
|
||||
You can get more details about how BitBake chooses between different
|
||||
target versions and providers in the
|
||||
<link linkend='ref-bitbake-providers'>Preferences and Providers</link> section.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
BitBake also tries to execute any dependent tasks first.
|
||||
So for example, before building <filename>matchbox-desktop</filename>, BitBake
|
||||
would build a cross compiler and <filename>glibc</filename> if they had not already
|
||||
been built.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A useful BitBake option to consider is the <filename>-k</filename> or
|
||||
<filename>--continue</filename> option.
|
||||
This option instructs BitBake to try and continue processing the job as much
|
||||
as possible even after encountering an error.
|
||||
When an error occurs, the target that
|
||||
failed and those that depend on it cannot be remade.
|
||||
However, when you use this option other dependencies can still be processed.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-components-metadata'>
|
||||
<title>Metadata (Recipes)</title>
|
||||
|
||||
<para>
|
||||
The <filename>.bb</filename> files are usually referred to as "recipes."
|
||||
In general, a recipe contains information about a single piece of software.
|
||||
The information includes the location from which to download the source patches
|
||||
(if any are needed), which special configuration options to apply,
|
||||
how to compile the source files, and how to package the compiled output.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The term "package" can also be used to describe recipes.
|
||||
However, since the same word is used for the packaged output from the Yocto
|
||||
Project (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
|
||||
this document avoids using the term "package" to refer to recipes.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-components-classes'>
|
||||
<title>Classes</title>
|
||||
|
||||
<para>
|
||||
Class files (<filename>.bbclass</filename>) contain information that is useful to share
|
||||
between metadata files.
|
||||
An example is the Autotools class, which contains
|
||||
common settings for any application that Autotools uses.
|
||||
The <link linkend='ref-classes'>Reference: Classes</link> appendix provides details
|
||||
about common classes and how to use them.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-components-configuration'>
|
||||
<title>Configuration</title>
|
||||
|
||||
<para>
|
||||
The configuration files (<filename>.conf</filename>) define various configuration variables
|
||||
that govern the Yocto Project build process.
|
||||
These files fall into several areas that define machine configuration options,
|
||||
distribution configuration options, compiler tuning options, general common configuration
|
||||
options and user configuration options (<filename>local.conf</filename>, which is found
|
||||
in the Yocto Project files build directory).
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
|
||||
<section id='usingpoky-build'>
|
||||
<title>Running a Build</title>
|
||||
|
||||
<para>
|
||||
You can find information on how to build an image using the Yocto Project in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
|
||||
You can find general information on how to build an image using the
|
||||
Yocto Project in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
|
||||
Building an Image</ulink> section of the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
Yocto Project Quick Start</ulink>.
|
||||
This section provides a quick overview.
|
||||
This section provides a summary of the build process and provides information
|
||||
for less obvious aspects of the build process.
|
||||
</para>
|
||||
|
||||
<section id='build-overview'>
|
||||
<title>Build Overview</title>
|
||||
|
||||
<para>
|
||||
The first thing you need to do is set up the Yocto Project build environment by sourcing
|
||||
the environment setup script as follows:
|
||||
<literallayout class='monospaced'>
|
||||
$ source oe-init-build-env [build_dir];
|
||||
$ source oe-init-build-env [build_dir]
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
@ -169,7 +38,7 @@
|
|||
The <filename>build_dir</filename> is optional and specifies the directory Yocto Project
|
||||
uses for the build.
|
||||
If you do not specify a build directory it defaults to <filename>build</filename>
|
||||
in the Yocto Project files directory structure.
|
||||
in your current working directory.
|
||||
A common practice is to use a different build directory for different targets.
|
||||
For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
|
||||
target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
|
||||
|
@ -200,14 +69,19 @@
|
|||
only supported for minimal and base images.
|
||||
See <link linkend='ref-images'>'Reference: Images'</link> for more information.
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<note>
|
||||
<section id='building-an-image-using-gpl-components'>
|
||||
<title>Building an Image Using GPL Components</title>
|
||||
|
||||
<para>
|
||||
When building an image using GPL components, you need to maintain your original
|
||||
settings and not switch back and forth applying different versions of the GNU
|
||||
Public License.
|
||||
If you rebuild using different versions of GPL, dependency errors might occur
|
||||
due to some components not being rebuilt.
|
||||
</note>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-install'>
|
||||
|
@ -219,9 +93,9 @@
|
|||
<filename class="directory">tmp/deploy/images</filename>.
|
||||
For information on how to run pre-built images such as <filename>qemux86</filename>
|
||||
and <filename>qemuarm</filename>, see the
|
||||
<ulink url='http://www.yoctoproject.org//docs/yocto-quick-start/yocto-project-qs.html#using-pre-built'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>
|
||||
Using Pre-Built Binaries and QEMU</ulink> section in the
|
||||
<ulink url='http://www.yoctoproject.org//docs/yocto-quick-start/yocto-project-qs.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
Yocto Project Quick Start</ulink>.
|
||||
For information about how to install these images, see the documentation for your
|
||||
particular board/machine.
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
|
||||
<section id='fake-title'>
|
||||
<title>Yocto Project Quick Start</title>
|
||||
<para>Copyright © 2010-2011 Linux Foundation</para>
|
||||
<para>Copyright © 2010-2012 Linux Foundation</para>
|
||||
</section>
|
||||
|
||||
<section id='welcome'>
|
||||
|
@ -21,7 +21,7 @@
|
|||
<para>
|
||||
This short document will give you some basic information about the environment as well
|
||||
as let you experience it in its simplest form.
|
||||
After reading this document you will have a basic understanding of what the Yocto Project is
|
||||
After reading this document, you will have a basic understanding of what the Yocto Project is
|
||||
and how to use some of its core components.
|
||||
This document steps you through a simple example showing you how to build a small image
|
||||
and run it using the QEMU emulator.
|
||||
|
@ -29,20 +29,21 @@
|
|||
<para>
|
||||
For complete information on the Yocto Project, you should check out the
|
||||
<ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>.
|
||||
You can find the latest builds, breaking news, full development documentation, and a
|
||||
Through the website, you can find the latest builds, breaking news, full development
|
||||
documentation, and a
|
||||
rich Yocto Project Development Community into which you can tap.
|
||||
</para>
|
||||
<para>
|
||||
Finally, you might find the Frequently Asked Questions (FAQ) for the Yocto Project
|
||||
at <ulink url='https://wiki.yoctoproject.org/wiki/FAQ'>Yocto Project FAQ</ulink> and
|
||||
the FAQ appendix located in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
|
||||
Yocto Project Reference Manual</ulink> helpful.
|
||||
the FAQ appendix located in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
The Yocto Project Reference Manual</ulink> helpful.
|
||||
</para>
|
||||
<note>
|
||||
Due to production processes, there could be differences between the Yocto Project
|
||||
documentation bundled in the release tarball and the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
|
||||
Yocto Project Quick Start</ulink> on
|
||||
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
|
||||
For the latest version of this manual, see the manual on the website.
|
||||
|
@ -74,7 +75,7 @@
|
|||
</mediaobject>
|
||||
|
||||
<para>
|
||||
Yocto Project:
|
||||
Here are some highlights for the Yocto Project:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
@ -85,7 +86,7 @@
|
|||
<para>Makes available system components such as X11, Matchbox, GTK+, Pimlico, Clutter,
|
||||
GuPNP and Qt (among others) so you can create a richer user interface experience on
|
||||
devices that use displays or have a GUI.
|
||||
For devices that don't have a GUI or display you simply would not employ these
|
||||
For devices that don't have a GUI or display, you simply would not employ these
|
||||
components.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -100,9 +101,9 @@
|
|||
|
||||
<para>
|
||||
The Yocto Project can generate images for many kinds of devices.
|
||||
However, the standard example machines target QEMU full system emulation for x86, ARM, MIPS,
|
||||
and PPC-based architectures as well as specific hardware such as the Intel Desktop Board
|
||||
DH55TC.
|
||||
However, the standard example machines target QEMU full-system emulation for x86, x86-64, ARM, MIPS,
|
||||
and PPC-based architectures as well as specific hardware such as the
|
||||
<trademark class='registered'>Intel</trademark> Desktop Board DH55TC.
|
||||
Because an image developed with the Yocto Project can boot inside a QEMU emulator, the
|
||||
development environment works nicely as a test platform for developing embedded software.
|
||||
</para>
|
||||
|
@ -113,7 +114,7 @@
|
|||
restricted screen sizes, sits neatly on top of a device using the
|
||||
GNOME Mobile Stack and provides a well-defined user experience.
|
||||
Implemented in its own layer, it makes it clear to developers how they can implement
|
||||
their own UIs on top of Yocto Linux.
|
||||
their own user interface on top of Yocto Linux.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -128,11 +129,10 @@
|
|||
<listitem>
|
||||
<para>A host system running a supported Linux distribution (i.e. recent releases of
|
||||
Fedora, openSUSE, Debian, and Ubuntu).
|
||||
<note>
|
||||
For notes about using the Yocto Project on development systems that use
|
||||
older Linux distributions see
|
||||
<ulink url='https://wiki.yoctoproject.org/wiki/BuildingOnRHEL4'></ulink>
|
||||
</note></para>
|
||||
If the host system supports multiple cores and threads, you can configure the
|
||||
Yocto Project build system to decrease the time needed to build images
|
||||
significantly.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The right packages.</para>
|
||||
|
@ -146,15 +146,23 @@
|
|||
<title>The Linux Distribution</title>
|
||||
|
||||
<para>
|
||||
The Yocto Project has been tested and is known to work on the current releases minus one
|
||||
of the following distributions.
|
||||
Follow this <ulink url='https://wiki.pokylinux.org/wiki/Distro_Test'>link </ulink> for more
|
||||
information on distribution testing.
|
||||
The Yocto Project team is continually verifying more and more Linux
|
||||
distributions with each release.
|
||||
In general, if you have the current release minus one of the following
|
||||
distributions you should have no problems.
|
||||
<itemizedlist>
|
||||
<listitem><para>Ubuntu</para></listitem>
|
||||
<listitem><para>Fedora</para></listitem>
|
||||
<listitem><para>openSUSE</para></listitem>
|
||||
</itemizedlist>
|
||||
For a list of the distributions under validation and their status, see the
|
||||
<ulink url='https://wiki.yoctoproject.org/wiki/Distribution_Support'>Distribution
|
||||
Support</ulink> wiki page.
|
||||
<note>
|
||||
For notes about using the Yocto Project on a RHEL 4-based host, see the
|
||||
<ulink url='https://wiki.yoctoproject.org/wiki/BuildingOnRHEL4'>BuildingOnRHEL4</ulink>
|
||||
wiki page.
|
||||
</note>
|
||||
</para>
|
||||
<para>
|
||||
The build system should be able to run on any modern distribution with Python 2.6 or 2.7.
|
||||
|
@ -183,16 +191,24 @@
|
|||
<para>
|
||||
Packages and package installation vary depending on your development system.
|
||||
In general, you need to have root access and then install the required packages.
|
||||
The next few sections show you how to get set up with the right packages for
|
||||
Ubuntu, Fedora, and openSUSE.
|
||||
</para>
|
||||
|
||||
<note><para>
|
||||
If you are using a Fedora version prior to version 15 you will need to take some
|
||||
extra steps to enable <filename>sudo</filename>.
|
||||
See <ulink url='https://fedoraproject.org/wiki/Configuring_Sudo'></ulink> for details.
|
||||
</para></note>
|
||||
<section id='ubuntu'>
|
||||
<title>Ubuntu</title>
|
||||
|
||||
<para>
|
||||
The packages you need for a Debian-based host are shown in the following command:
|
||||
If your distribution is Ubuntu, you need to be running the bash shell.
|
||||
You can be sure you are running this shell by entering the following command and
|
||||
selecting "No" at the prompt:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo dpkg-reconfigure dash
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The packages you need for a supported Ubuntu distribution are shown in the following command:
|
||||
</para>
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
|
@ -202,10 +218,14 @@
|
|||
g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
|
||||
mercurial autoconf automake groff libtool xterm
|
||||
</literallayout>
|
||||
</section>
|
||||
|
||||
<section id='fedora'>
|
||||
<title>Fedora</title>
|
||||
|
||||
<para>
|
||||
The packages you need for an RPM-based host like Fedora and openSUSE,
|
||||
respectively, are as follows:
|
||||
The packages you need for a supported Fedora distribution are shown in the following
|
||||
commands:
|
||||
</para>
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
|
@ -213,26 +233,43 @@
|
|||
$ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
|
||||
unzip python-psyco perl texinfo texi2html diffstat openjade \
|
||||
docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
|
||||
docbook-utils sed bc glibc-devel ccache pcre pcre-devel quilt \
|
||||
docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
|
||||
groff linuxdoc-tools patch linuxdoc-tools cmake help2man \
|
||||
perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
|
||||
SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
|
||||
autoconf automake libtool xterm
|
||||
</literallayout>
|
||||
|
||||
<note><para>
|
||||
If you are using a Fedora version prior to version 15, you will need to take some
|
||||
extra steps to enable <filename>sudo</filename>, or you will need to run
|
||||
the commands as root user.
|
||||
See the <ulink url='https://fedoraproject.org/wiki/Configuring_Sudo'>Configuring Sudo</ulink>
|
||||
wiki page for details.
|
||||
</para></note>
|
||||
</section>
|
||||
|
||||
<section id='opensuse'>
|
||||
<title>openSUSE</title>
|
||||
|
||||
<para>
|
||||
The packages you need for a supported openSUSE distribution are shown in the following
|
||||
command:
|
||||
</para>
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo zypper install python gcc gcc-c++ libtool \
|
||||
subversion git chrpath automake \
|
||||
help2man diffstat texinfo mercurial wget
|
||||
subversion git chrpath automake make wget help2man \
|
||||
diffstat texinfo mercurial freeglut-devel libSDL-devel
|
||||
</literallayout>
|
||||
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='releases'>
|
||||
<title>Yocto Project Release</title>
|
||||
|
||||
<para>
|
||||
You can download the latest release images for the Yocto Project on the
|
||||
You can download the latest Yocto Project release by going to the
|
||||
<ulink url="http://yoctoproject.org/download">Yocto Project Download page</ulink>.
|
||||
Just go to the page and click the "Yocto Downloads" link found in the "Download"
|
||||
navigation pane to the right to view all available Yocto Project releases.
|
||||
|
@ -242,6 +279,17 @@
|
|||
<ulink url="http://autobuilder.yoctoproject.org/nightly/"></ulink>.
|
||||
However, for this document a released version of Yocto Project is used.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can also get the Yocto Project files by setting up a Git repository on your host
|
||||
development system.
|
||||
Doing so allows you to contribute back to the project.
|
||||
For information on how to get set up using this method, see the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-yp-release'>Yocto
|
||||
Project Release</ulink>" item in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto Project
|
||||
Development Manual</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
|
@ -249,16 +297,16 @@
|
|||
<title>A Quick Test Run</title>
|
||||
|
||||
<para>
|
||||
Now that you have your system requirements in order you can give Yocto Project a try.
|
||||
Now that you have your system requirements in order, you can give Yocto Project a try.
|
||||
This section presents some steps that let you do the following:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Build an image and run it in the emulator</para>
|
||||
<para>Build an image and run it in the QEMU emulator</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Or, use a pre-built image and run it in the emulator</para>
|
||||
<para>Use a pre-built image and run it in the QEMU emulator</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
@ -266,7 +314,8 @@
|
|||
<title>Building an Image</title>
|
||||
|
||||
<para>
|
||||
In the development environment you will need to build an image whenever you change hardware support, add or change system libraries, or add or change services that have dependencies.
|
||||
In the development environment you will need to build an image whenever you change hardware
|
||||
support, add or change system libraries, or add or change services that have dependencies.
|
||||
</para>
|
||||
|
||||
<mediaobject>
|
||||
|
@ -295,22 +344,23 @@
|
|||
through a set of locations.
|
||||
If you encounter problems with the Yocto Project finding and downloading source code, see
|
||||
the FAQ entry "How does Poky obtain source code and will it work behind my
|
||||
firewall or proxy server?" in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
|
||||
Yocto Project Reference Manual</ulink>.
|
||||
firewall or proxy server?" in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
The Yocto Project Reference Manual</ulink>.
|
||||
</para></note>
|
||||
|
||||
<para>
|
||||
<literallayout class='monospaced'>
|
||||
$ wget http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2
|
||||
$ tar xjf poky-bernard-5.0.1.tar.bz2
|
||||
$ source poky-bernard-5.0.1/poky-init-build-env poky-5.0.1-build
|
||||
$ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/poky-edison-6.0.1.tar.bz2
|
||||
$ tar xjf poky-edison-6.0.1.tar.bz2
|
||||
$ source poky-edison-6.0.1/oe-init-build-env edison-6.0.1-build
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<tip><para>
|
||||
To help conserve disk space during builds you can add the following statement
|
||||
to your <filename>local.conf</filename> file.
|
||||
To help conserve disk space during builds, you can add the following statement
|
||||
to your project's configuration file, which for this example
|
||||
is <filename>edison-6.0.1-build/conf/local.conf</filename>.
|
||||
Adding this statement deletes the work directory used for building a package
|
||||
once the package is built.
|
||||
<literallayout class='monospaced'>
|
||||
|
@ -319,25 +369,53 @@
|
|||
</para></tip>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>The first two commands extract the Yocto Project files from the
|
||||
release tarball and place them into a subdirectory of your current directory.</para></listitem>
|
||||
<listitem><para>The <command>source</command> command creates the
|
||||
<filename>poky-5.0.1-build</filename> directory and executes the <command>cd</command>
|
||||
command to make <filename>poky-5.0.1-build</filename> the working directory.
|
||||
The resulting build directory contains all the files created during the build.
|
||||
By default the target architecture is qemux86.
|
||||
To change this default, edit the value of the MACHINE variable in the
|
||||
<filename>conf/local.conf</filename> file.</para></listitem>
|
||||
<listitem><para>In the previous example, the first command retrieves the Yocto Project
|
||||
release tarball from the source repositories using the
|
||||
<filename>wget</filename> command.
|
||||
Alternatively, you can go to the
|
||||
<ulink url='http://www.yoctoproject.org/download'>Yocto Project website</ulink>
|
||||
Downloads page to retrieve the tarball.</para></listitem>
|
||||
<listitem><para>The second command extracts the files from the tarball and places
|
||||
them into a directory named <filename>poky-edison-6.0.1</filename> in the current
|
||||
directory.</para></listitem>
|
||||
<listitem><para>The third command runs the Yocto Project environment setup script.
|
||||
Running this script defines Yocto Project build environment settings needed to
|
||||
complete the build.
|
||||
The script also creates the Yocto Project
|
||||
build directory, which is <filename>edison-6.0.1-build</filename> in this case.
|
||||
After the script runs, your current working directory is set
|
||||
to the build directory.
|
||||
Later, when the build completes, the build directory contains all the files
|
||||
created during the build.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
Take some time to examine your <filename>conf/local.conf</filename> file found in the
|
||||
Yocto Project file's <filename>conf</filename>.
|
||||
The defaults should work fine.
|
||||
However, if you have a multi-core CPU you might want to set the variable
|
||||
BB_NUMBER_THREADS equal to twice the number of processor cores your system has.
|
||||
And, set the variable PARALLEL_MAKE equal to the number of processor cores.
|
||||
Setting these variables can significantly shorten your build time.
|
||||
Take some time to examine your <filename>local.conf</filename> file
|
||||
in your project's configuration directory.
|
||||
The defaults in that file should work fine.
|
||||
However, there are some variables of interest at which you might look.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
By default, the target architecture for the build is <filename>qemux86</filename>,
|
||||
which produces an image that can be used in the QEMU emulator and is targeted at an
|
||||
<trademark class='registered'>Intel</trademark> 32-bit based architecture.
|
||||
To change this default, edit the value of the <filename>MACHINE</filename> variable
|
||||
in the configuration file before launching the build.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Another couple of variables of interest are the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink> and the
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> variables.
|
||||
By default, these variables are commented out.
|
||||
However, if you have a multi-core CPU you might want to uncomment
|
||||
the lines and set the variable
|
||||
<filename>BB_NUMBER_THREADS</filename> equal to twice the number of your
|
||||
host's processor cores.
|
||||
Also, you could set the variable <filename>PARALLEL_MAKE</filename> equal to
|
||||
1.5 times the number of processor cores.
|
||||
Setting these variables can significantly shorten your build time.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -345,28 +423,28 @@
|
|||
the image.
|
||||
By default, the Yocto Project build system uses the RPM package manager.
|
||||
You can control this configuration by using the
|
||||
<filename><ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_CLASSES'>PACKAGE_CLASSES</ulink></filename> variable.
|
||||
<filename><ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.
|
||||
For additional package manager selection information, see
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>" in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
The Yocto Project Reference Manual</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Continue with the following command to build an OS image for the target, which is
|
||||
<filename>core-image-sato</filename> in this example.
|
||||
For information on the <filename>‐k</filename> option use the
|
||||
<filename>bitbake --help</filename> command or see
|
||||
<ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html#usingpoky-components-bitbake'>
|
||||
BitBake</ulink> section in the Yocto Project Reference Manual.
|
||||
For information on the <filename>-k</filename> option use the
|
||||
<filename>bitbake --help</filename> command or see the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-components-bitbake'>BitBake</ulink>" section in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>The Yocto Project Reference Manual</ulink>.
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake -k core-image-sato
|
||||
</literallayout>
|
||||
<note><para>
|
||||
BitBake requires Python 2.6 or 2.7. For more information on this requirement,
|
||||
see the FAQ appendix in the
|
||||
<ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
|
||||
Yocto Project Reference Manual</ulink>.
|
||||
see the FAQ appendix in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
|
||||
The Yocto Project Reference Manual</ulink>.
|
||||
</para></note>
|
||||
The final command runs the image:
|
||||
<literallayout class='monospaced'>
|
||||
|
@ -383,16 +461,13 @@
|
|||
|
||||
<section id='using-pre-built'>
|
||||
<title>Using Pre-Built Binaries and QEMU</title>
|
||||
|
||||
<para>
|
||||
If hardware, libraries and services are stable you can get started by using a pre-built binary
|
||||
of the image, kernel and toolchain and run it using the emulator QEMU.
|
||||
If hardware, libraries and services are stable, you can get started by using a pre-built binary
|
||||
of the filesystem image, kernel, and toolchain and run it using the QEMU emulator.
|
||||
This scenario is useful for developing application software.
|
||||
</para>
|
||||
|
||||
<para></para>
|
||||
<para></para>
|
||||
<para></para>
|
||||
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="figures/using-a-pre-built-image.png" format="PNG" align='center' scalefit='1'/>
|
||||
|
@ -403,43 +478,28 @@
|
|||
</mediaobject>
|
||||
|
||||
<para>
|
||||
For this scenario you need to do several things:
|
||||
For this scenario, you need to do several things:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Install the stand-alone Yocto toolchain tarball.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Download the pre-built kernel that will boot with QEMU.
|
||||
<listitem><para>Install the stand-alone Yocto toolchain tarball.</para></listitem>
|
||||
<listitem><para>Download the pre-built image that will boot with QEMU.
|
||||
You need to be sure to get the QEMU image that matches your target machine’s
|
||||
architecture (e.g. x86, ARM, etc.).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Download the filesystem image for your target machine's architecture.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Set up the environment to emulate the hardware and then start the QEMU emulator.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
architecture (e.g. x86, ARM, etc.).</para></listitem>
|
||||
<listitem><para>Download the filesystem image for your target machine's architecture.
|
||||
</para></listitem>
|
||||
<listitem><para>Set up the environment to emulate the hardware and then start the QEMU emulator.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<section id='installing-the-toolchain'>
|
||||
<title>Installing the Toolchain</title>
|
||||
<para>
|
||||
You can download the pre-built toolchain, which includes the <filename>runqemu</filename>
|
||||
script and support files, from
|
||||
<ulink url='http://yoctoproject.org/downloads/yocto-1.0/toolchain/'></ulink>.
|
||||
script and support files, from the appropriate directory under
|
||||
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/toolchain/'></ulink>.
|
||||
Toolchains are available for 32-bit and 64-bit development systems from the
|
||||
<filename>i686</filename> and <filename>x86_64</filename> folders, respectively.
|
||||
<filename>i686</filename> and <filename>x86_64</filename> directories, respectively.
|
||||
Each type of development system supports five target architectures.
|
||||
The tarball files are named such that a string representing the host system appears
|
||||
first in the filename and then is immediately followed by a string representing
|
||||
|
@ -447,7 +507,7 @@
|
|||
</para>
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
yocto-eglibc<<emphasis>host_system</emphasis>>-<<emphasis>arch</emphasis>>-toolchain-gmae-<<emphasis>release</emphasis>>.tar.bz2
|
||||
poky-eglibc<<emphasis>host_system</emphasis>>-<<emphasis>arch</emphasis>>-toolchain-gmae-<<emphasis>release</emphasis>>.tar.bz2
|
||||
|
||||
Where:
|
||||
<<emphasis>host_system</emphasis>> is a string representing your development system:
|
||||
|
@ -465,7 +525,7 @@
|
|||
</para>
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
yocto-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
|
||||
poky-eglibc-x86_64-i586-toolchain-gmae-1.1.1.tar.bz2
|
||||
</literallayout>
|
||||
|
||||
<para>
|
||||
|
@ -478,19 +538,26 @@
|
|||
<para>
|
||||
<literallayout class='monospaced'>
|
||||
$ cd /
|
||||
$ sudo tar -xvjf ~/toolchains/yocto-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
|
||||
$ sudo tar -xvjf ~/toolchains/poky-eglibc-x86_64-i586-toolchain-gmae-1.1.1.tar.bz2
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more information on how to install tarballs, see the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" and
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Yocto Project Build Tree</ulink>" sections in
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project
|
||||
Application Development Toolkit (ADT) User's Guide</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='downloading-the-pre-built-linux-kernel'>
|
||||
<title>Downloading the Pre-Built Linux Kernel</title>
|
||||
|
||||
<para>
|
||||
You can download the pre-built Linux kernel and the filesystem image suitable for
|
||||
running in the emulator QEMU from
|
||||
<ulink url='http://yoctoproject.org/downloads/yocto-1.0/machines/qemu'></ulink>.
|
||||
Be sure to use the kernel and filesystem image that matches the architecture you want
|
||||
to simulate.
|
||||
You can download the pre-built Linux kernel suitable for running in the QEMU emulator from
|
||||
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu'></ulink>.
|
||||
Be sure to use the kernel that matches the architecture you want to simulate.
|
||||
Download areas exist for the five supported machine architectures:
|
||||
<filename>qemuarm</filename>, <filename>qemumips</filename>, <filename>qemuppc</filename>,
|
||||
<filename>qemux86</filename>, and <filename>qemux86_64</filename>.
|
||||
|
@ -498,25 +565,34 @@
|
|||
|
||||
<para>
|
||||
Most kernel files have one of the following forms:
|
||||
</para>
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
*zImage-<<emphasis>kernel-rev</emphasis>>-qemu<<emphasis>arch</emphasis>>-<<emphasis>release</emphasis>>*.bin
|
||||
vmlinux-<<emphasis>kernel-rev</emphasis>>-qemu<<emphasis>arch</emphasis>>-<<emphasis>release</emphasis>>*.bin
|
||||
*zImage-qemu<<emphasis>arch</emphasis>>.bin
|
||||
vmlinux-qemu<<emphasis>arch</emphasis>>.bin
|
||||
|
||||
Where:
|
||||
<<emphasis>kernel-rev</emphasis>> is the base Linux kernel revision
|
||||
(e.g. 2.6.37).
|
||||
|
||||
<<emphasis>arch</emphasis>> is a string representing the target architecture:
|
||||
x86, x86-64, ppc, mips, or arm.
|
||||
|
||||
<<emphasis>release</emphasis>> is the version of Yocto Project.
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can learn more about downloading a Yocto Project kernel in the
|
||||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-kernel-files'>Linux Yocto Kernel</ulink>" section of
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The
|
||||
Yocto Project Development Manual</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='downloading-the-filesystem'>
|
||||
<title>Downloading the Filesystem</title>
|
||||
|
||||
<para>
|
||||
You can also download the filesystem image suitable for your target architecture from
|
||||
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu'></ulink>.
|
||||
Again, be sure to use the filesystem that matches the architecture you want
|
||||
to simulate.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The filesystem image has two tarball forms: <filename>ext3</filename> and
|
||||
<filename>tar</filename>.
|
||||
|
@ -524,34 +600,30 @@
|
|||
QEMU emulator.
|
||||
The <filename>tar</filename> form can be flattened out in your host development system
|
||||
and used for Yocto Project build purposes.
|
||||
</para>
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
yocto-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>-<<emphasis>release</emphasis>>.rootfs.ext3.bz2
|
||||
yocto-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>-<<emphasis>release</emphasis>>.rootfs.tar.bz2
|
||||
core-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>.ext3
|
||||
core-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>.tar.bz2
|
||||
|
||||
Where:
|
||||
<<emphasis>profile</emphasis>> is the filesystem image's profile:
|
||||
lsb, lsb-dev, lsb-sdk, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
|
||||
lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
|
||||
For information on these types of image profiles, see
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual.
|
||||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual.
|
||||
|
||||
<<emphasis>arch</emphasis>> is a string representing the target architecture:
|
||||
x86, x86-64, ppc, mips, or arm.
|
||||
|
||||
<<emphasis>release</emphasis>> is the version of Yocto Project.
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='setting-up-the-environment-and-starting-the-qemu-emulator'>
|
||||
<title>Setting Up the Environment and Starting the QEMU Emulator</title>
|
||||
<para>
|
||||
Before you start the QEMU emulator you need to set up the emulation environment.
|
||||
The following command form sets up the emulation environment.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Before you start the QEMU emulator, you need to set up the emulation environment.
|
||||
The following command form sets up the emulation environment.
|
||||
<literallayout class='monospaced'>
|
||||
$ source /opt/poky/1.1/environment-setup-<<emphasis>arch</emphasis>>-poky-linux-<<emphasis>if</emphasis>>
|
||||
$ source /opt/poky/1.1.1/environment-setup-<<emphasis>arch</emphasis>>-poky-linux-<<emphasis>if</emphasis>>
|
||||
|
||||
Where:
|
||||
<<emphasis>arch</emphasis>> is a string representing the target architecture:
|
||||
|
@ -560,11 +632,10 @@
|
|||
<<emphasis>if</emphasis>> is a string representing an embedded application binary interface.
|
||||
Not all setup scripts include this string.
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, this command form invokes the QEMU emulator
|
||||
</para>
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
$ runqemu <<emphasis>qemuarch</emphasis>> <<emphasis>kernel-image</emphasis>> <<emphasis>filesystem-image</emphasis>>
|
||||
|
||||
|
@ -577,31 +648,31 @@
|
|||
<<emphasis>filesystem-image</emphasis>> is the .ext3 filesystem image.
|
||||
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Continuing with the example, the following two commands setup the emulation
|
||||
environment and launch QEMU.
|
||||
This example assumes the root filesystem tarball has been downloaded and expanded, and
|
||||
This example assumes the toolchain tarball has been downloaded and expanded
|
||||
into <filename>/opt/poky</filename> and
|
||||
that the kernel and filesystem are for a 32-bit target architecture.
|
||||
</para>
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
$ source /opt/poky/1.1/environment-setup-i686-poky-linux
|
||||
$ runqemu qemux86 bzImage-3.0-qemux86-1.1.bin \
|
||||
yocto-image-sato-qemux86-1.1.rootfs.ext3
|
||||
$ source /opt/poky/1.1.1/environment-setup-i586-poky-linux
|
||||
$ runqemu qemux86 bzImage-3.0-qemux86-1.1.1.bin \
|
||||
core-image-sato-qemux86.ext3
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The environment in which QEMU launches varies depending on the filesystem image and on the
|
||||
target architecture. For example, if you source the environment for the ARM target
|
||||
target architecture.
|
||||
For example, if you source the environment for the ARM target
|
||||
architecture and then boot the minimal QEMU image, the emulator comes up in a new
|
||||
shell in command-line mode. However, if you boot the SDK image QEMU comes up with
|
||||
a GUI.
|
||||
shell in command-line mode.
|
||||
However, if you boot the SDK image, QEMU comes up with a GUI.
|
||||
<note>Booting the PPC image results in QEMU launching in the same shell in
|
||||
command-line mode.</note>
|
||||
</para>
|
||||
|
||||
<note><para>
|
||||
Booting the PPC image results in QEMU launching in the same shell in command-line mode.
|
||||
</para></note>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
@ -17,13 +17,12 @@ PACKAGES =+ "${PN}-user3"
|
|||
|
||||
inherit useradd
|
||||
|
||||
# Specify which package(s) should include the user/group code.
|
||||
# Make sure that any packages which install files owned by custom
|
||||
# users/groups are included here. The code which adds users and
|
||||
# groups is idempotent.
|
||||
# You must set USERADD_PACKAGES when you inherit useradd. This
|
||||
# lists which output packages will include the user/group
|
||||
# creation code.
|
||||
USERADD_PACKAGES = "${PN} ${PN}-user3"
|
||||
|
||||
# You *must* set USERADD_PARAM and/or GROUPADD_PARAM when
|
||||
# You must also set USERADD_PARAM and/or GROUPADD_PARAM when
|
||||
# you inherit useradd.
|
||||
|
||||
# USERADD_PARAM specifies command line options to pass to the
|
||||
|
|
|
@ -0,0 +1 @@
|
|||
*.sw?
|
|
@ -0,0 +1,14 @@
|
|||
# This file is for getting archiving packages with configured sources(archive 's' after configure stage),logs(archive 'temp' after package_write_rpm),dump data
|
||||
# and creating diff file(get all environment variables and functions in building and mapping all content in 's' including patches to xxx.diff.gz.
|
||||
# All archived packages will be deployed in ${DEPLOY_DIR}/sources
|
||||
|
||||
inherit archiver
|
||||
|
||||
# Get archiving package with configured sources including patches
|
||||
do_configure[postfuncs] += "do_archive_configured_sources "
|
||||
|
||||
# Get archiving package with temp(logs) and scripts(.bb and inc files)
|
||||
do_package_write_rpm[prefuncs] += "do_archive_scripts_logs "
|
||||
|
||||
# Get dump date and create diff file
|
||||
do_package_write_rpm[postfuncs] += "do_dumpdata_create_diff_gz "
|
|
@ -0,0 +1,14 @@
|
|||
# This file is for getting archiving packages with original sources(archive 's' after unpack stage),patches,logs(archive 'temp' after package_write_rpm),dump data and
|
||||
# creating diff file(get all environment variables and functions in building and mapping all content in 's' including patches to xxx.diff.gz.
|
||||
# All archived packages will be deployed in ${DEPLOY_DIR}/sources
|
||||
|
||||
inherit archiver
|
||||
|
||||
# Get original sources archiving package with patches
|
||||
do_unpack[postfuncs] += "do_archive_original_sources_patches "
|
||||
|
||||
# Get archiving package with temp(logs) and scripts(.bb and inc files)
|
||||
do_package_write_rpm[prefuncs] += "do_archive_scripts_logs "
|
||||
|
||||
# Get dump date and create diff file
|
||||
do_package_write_rpm[postfuncs] += "do_dumpdata_create_diff_gz "
|
|
@ -0,0 +1,14 @@
|
|||
# This file is for getting archiving packages with patched sources(archive 's' before do_patch stage),logs(archive 'temp' after package_write_rpm),dump data and
|
||||
# creating diff file(get all environment variables and functions in building and mapping all content in 's' including patches to xxx.diff.gz.
|
||||
# All archived packages will be deployed in ${DEPLOY_DIR}/sources
|
||||
|
||||
inherit archiver
|
||||
|
||||
# Get archiving package with patched sources including patches
|
||||
do_patch[postfuncs] += "do_archive_patched_sources "
|
||||
|
||||
# Get archiving package with logs(temp) and scripts(.bb and .inc files)
|
||||
do_package_write_rpm[prefuncs] += "do_archive_scripts_logs "
|
||||
|
||||
# Get dump date and create diff file
|
||||
do_package_write_rpm[postfuncs] += "do_dumpdata_create_diff_gz "
|
|
@ -0,0 +1,450 @@
|
|||
# This file is used for archiving sources ,patches,and logs to tarball.
|
||||
# It also output building environment to xxx.dump.data and create xxx.diff.gz to record
|
||||
# all content in ${S} to a diff file.
|
||||
|
||||
ARCHIVE_EXCLUDE_FROM ?= ".pc autom4te.cache"
|
||||
ARCHIVE_TYPE ?= "TAR SRPM"
|
||||
DISTRO ?= "poky"
|
||||
PATCHES_ARCHIVE_WITH_SERIES = 'TRUE'
|
||||
|
||||
def get_bb_inc(d):
|
||||
'''create a directory "script-logs" including .bb and .inc file in ${WORKDIR}'''
|
||||
import re
|
||||
import os
|
||||
import shutil
|
||||
|
||||
bbinc = []
|
||||
pat=re.compile('require\s*([^\s]*\.*)(.*)')
|
||||
work_dir = d.getVar('WORKDIR', True)
|
||||
bbfile = d.getVar('FILE', True)
|
||||
bbdir = os.path.dirname(bbfile)
|
||||
script_logs = os.path.join(work_dir,'script-logs')
|
||||
bb_inc = os.path.join(script_logs,'bb_inc')
|
||||
bb.mkdirhier(script_logs)
|
||||
bb.mkdirhier(bb_inc)
|
||||
|
||||
def find_file(dir,file):
|
||||
for root, dirs, files in os.walk(dir):
|
||||
if file in files:
|
||||
return os.path.join(root,file)
|
||||
|
||||
def get_inc (file):
|
||||
f = open(file,'r')
|
||||
for line in f.readlines():
|
||||
if 'require' not in line:
|
||||
bbinc.append(file)
|
||||
else:
|
||||
try:
|
||||
incfile = pat.match(line).group(1)
|
||||
incfile = bb.data.expand(os.path.basename(incfile),d)
|
||||
abs_incfile = find_file(bbdir,incfile)
|
||||
if abs_incfile:
|
||||
bbinc.append(abs_incfile)
|
||||
get_inc(abs_incfile)
|
||||
except AttributeError:
|
||||
pass
|
||||
get_inc(bbfile)
|
||||
bbinc = list(set(bbinc))
|
||||
for bbincfile in bbinc:
|
||||
shutil.copy(bbincfile,bb_inc)
|
||||
|
||||
try:
|
||||
bb.mkdirhier(os.path.join(script_logs,'temp'))
|
||||
oe.path.copytree(os.path.join(work_dir,'temp'), os.path.join(script_logs,'temp'))
|
||||
except (IOError,AttributeError):
|
||||
pass
|
||||
return script_logs
|
||||
|
||||
def get_series(d):
|
||||
'''copy patches and series file to a pointed directory which will be archived to tarball in ${WORKDIR}'''
|
||||
import shutil
|
||||
|
||||
src_patches=[]
|
||||
pf = d.getVar('PF', True)
|
||||
work_dir = d.getVar('WORKDIR', True)
|
||||
s = d.getVar('S',True)
|
||||
dest = os.path.join(work_dir, pf + '-series')
|
||||
shutil.rmtree(dest, ignore_errors=True)
|
||||
bb.mkdirhier(dest)
|
||||
|
||||
src_uri = d.getVar('SRC_URI', True).split()
|
||||
fetch = bb.fetch2.Fetch(src_uri, d)
|
||||
locals = (fetch.localpath(url) for url in fetch.urls)
|
||||
for local in locals:
|
||||
src_patches.append(local)
|
||||
if not cmp(work_dir,s):
|
||||
tmp_list = src_patches
|
||||
else:
|
||||
tmp_list = src_patches[1:]
|
||||
|
||||
for patch in tmp_list:
|
||||
try:
|
||||
shutil.copy(patch,dest)
|
||||
except IOError:
|
||||
if os.path.isdir(patch):
|
||||
bb.mkdirhier(os.path.join(dest,patch))
|
||||
oe.path.copytree(patch, os.path.join(dest,patch))
|
||||
return dest
|
||||
|
||||
def get_applying_patches(d):
|
||||
"""only copy applying patches to a pointed directory which will be archived to tarball"""
|
||||
import os
|
||||
import shutil
|
||||
|
||||
|
||||
pf = d.getVar('PF', True)
|
||||
work_dir = d.getVar('WORKDIR', True)
|
||||
dest = os.path.join(work_dir, pf + '-patches')
|
||||
shutil.rmtree(dest, ignore_errors=True)
|
||||
bb.mkdirhier(dest)
|
||||
|
||||
|
||||
patches = src_patches(d)
|
||||
for patch in patches:
|
||||
_, _, local, _, _, parm = bb.decodeurl(patch)
|
||||
if local:
|
||||
shutil.copy(local,dest)
|
||||
return dest
|
||||
|
||||
def not_tarball(d):
|
||||
'''packages including key words 'work-shared','native', 'task-' will be passed'''
|
||||
import os
|
||||
|
||||
workdir = d.getVar('WORKDIR',True)
|
||||
s = d.getVar('S',True)
|
||||
if 'work-shared' in s or 'task-' in workdir or 'native' in workdir:
|
||||
return True
|
||||
else:
|
||||
return False
|
||||
|
||||
def get_source_from_downloads(d,stage_name):
|
||||
'''copy tarball of $P to $WORKDIR when this tarball exists in $DL_DIR'''
|
||||
if stage_name in 'patched' 'configured':
|
||||
return
|
||||
pf = d.getVar('PF', True)
|
||||
dl_dir = d.getVar('DL_DIR',True)
|
||||
try:
|
||||
source = os.path.join(dl_dir,os.path.basename(d.getVar('SRC_URI', True).split()[0]))
|
||||
if os.path.exists(source) and not os.path.isdir(source):
|
||||
return source
|
||||
except (IndexError, OSError):
|
||||
pass
|
||||
return ''
|
||||
|
||||
def do_tarball(workdir,srcdir,tarname):
|
||||
'''tar "srcdir" under "workdir" to "tarname"'''
|
||||
import tarfile
|
||||
|
||||
sav_dir = os.getcwd()
|
||||
os.chdir(workdir)
|
||||
if (len(os.listdir(srcdir))) != 0:
|
||||
tar = tarfile.open(tarname, "w:gz")
|
||||
tar.add(srcdir)
|
||||
tar.close()
|
||||
else:
|
||||
tarname = ''
|
||||
os.chdir(sav_dir)
|
||||
return tarname
|
||||
|
||||
def archive_sources_from_directory(d,stage_name):
|
||||
'''archive sources codes tree to tarball when tarball of $P doesn't exist in $DL_DIR'''
|
||||
import shutil
|
||||
|
||||
s = d.getVar('S',True)
|
||||
work_dir=d.getVar('WORKDIR', True)
|
||||
PF = d.getVar('PF',True)
|
||||
tarname = PF + '-' + stage_name + ".tar.gz"
|
||||
|
||||
if os.path.exists(s) and work_dir in s:
|
||||
try:
|
||||
source_dir = os.path.join(work_dir,[ i for i in s.replace(work_dir,'').split('/') if i][0])
|
||||
except IndexError:
|
||||
if not cmp(s,work_dir):
|
||||
return ''
|
||||
else:
|
||||
return ''
|
||||
source = os.path.basename(source_dir)
|
||||
return do_tarball(work_dir,source,tarname)
|
||||
|
||||
def archive_sources(d,stage_name):
|
||||
'''copy tarball from $DL_DIR to $WORKDIR if have tarball, archive source codes tree in $WORKDIR if $P is directory instead of tarball'''
|
||||
import shutil
|
||||
work_dir = d.getVar('WORKDIR',True)
|
||||
file = get_source_from_downloads(d,stage_name)
|
||||
if file:
|
||||
shutil.copy(file,work_dir)
|
||||
file = os.path.basename(file)
|
||||
else:
|
||||
file = archive_sources_from_directory(d,stage_name)
|
||||
return file
|
||||
|
||||
|
||||
def archive_patches(d,patchdir,series):
|
||||
'''archive patches to tarball and also include series files if 'series' is True'''
|
||||
import shutil
|
||||
|
||||
s = d.getVar('S',True)
|
||||
work_dir = d.getVar('WORKDIR', True)
|
||||
patch_dir = os.path.basename(patchdir)
|
||||
tarname = patch_dir + ".tar.gz"
|
||||
if series == 'all' and os.path.exists(os.path.join(s,'patches/series')):
|
||||
shutil.copy(os.path.join(s,'patches/series'),patchdir)
|
||||
tarname = do_tarball(work_dir,patch_dir,tarname)
|
||||
shutil.rmtree(patchdir, ignore_errors=True)
|
||||
return tarname
|
||||
|
||||
def select_archive_patches(d,option):
|
||||
'''select to archive all patches including non-applying and series or applying patches '''
|
||||
if option == "all":
|
||||
patchdir = get_series(d)
|
||||
elif option == "applying":
|
||||
patchdir = get_applying_patches(d)
|
||||
try:
|
||||
os.rmdir(patchdir)
|
||||
except OSError:
|
||||
tarpatch = archive_patches(d,patchdir,option)
|
||||
return tarpatch
|
||||
return
|
||||
|
||||
def archive_logs(d,logdir,bbinc=False):
|
||||
'''archive logs in temp to tarball and .bb and .inc files if bbinc is True '''
|
||||
import shutil
|
||||
|
||||
pf = d.getVar('PF',True)
|
||||
work_dir = d.getVar('WORKDIR',True)
|
||||
log_dir = os.path.basename(logdir)
|
||||
tarname = pf + '-' + log_dir + ".tar.gz"
|
||||
tarname = do_tarball(work_dir,log_dir,tarname)
|
||||
if bbinc:
|
||||
shutil.rmtree(logdir, ignore_errors=True)
|
||||
return tarname
|
||||
|
||||
def get_licenses(d):
|
||||
'''get licenses for running .bb file'''
|
||||
licenses = d.getVar('LICENSE', 1).replace('&', '|')
|
||||
licenses = licenses.replace('(', '').replace(')', '')
|
||||
clean_licenses = ""
|
||||
for x in licenses.split():
|
||||
if x.strip() == '' or x == 'CLOSED':
|
||||
continue
|
||||
if x != "|":
|
||||
clean_licenses += x
|
||||
if '|' in clean_licenses:
|
||||
clean_licenses = clean_licenses.replace('|','')
|
||||
return clean_licenses
|
||||
|
||||
|
||||
def move_tarball_deploy(d,tarball_list):
|
||||
'''move tarball in location to ${DEPLOY_DIR}/sources'''
|
||||
import shutil
|
||||
|
||||
if tarball_list is []:
|
||||
return
|
||||
target_sys = d.getVar('TARGET_SYS', True)
|
||||
pf = d.getVar('PF', True)
|
||||
licenses = get_licenses(d)
|
||||
work_dir = d.getVar('WORKDIR',True)
|
||||
tar_sources = d.getVar('DEPLOY_DIR', True) + '/sources/' + target_sys + '/' + licenses + '/' + pf
|
||||
if not os.path.exists(tar_sources):
|
||||
bb.mkdirhier(tar_sources)
|
||||
for source in tarball_list:
|
||||
if source:
|
||||
if os.path.exists(os.path.join(tar_sources, source)):
|
||||
os.remove(os.path.join(tar_sources,source))
|
||||
shutil.move(os.path.join(work_dir,source),tar_sources)
|
||||
|
||||
def check_archiving_type(d):
|
||||
'''check the type for archiving package('tar' or 'srpm')'''
|
||||
try:
|
||||
if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True).upper() not in d.getVar('ARCHIVE_TYPE', True).split():
|
||||
raise AttributeError
|
||||
except AttributeError:
|
||||
bb.fatal("\"SOURCE_ARCHIVE_PACKAGE_TYPE\" is \'tar\' or \'srpm\', no other types")
|
||||
|
||||
def store_package(d,package_name):
|
||||
'''store tarbablls name to file "tar-package"'''
|
||||
try:
|
||||
f = open(os.path.join(d.getVar('WORKDIR',True),'tar-package'),'a')
|
||||
f.write(package_name + ' ')
|
||||
f.close()
|
||||
except IOError:
|
||||
pass
|
||||
|
||||
def get_package(d):
|
||||
'''get tarballs name from "tar-package"'''
|
||||
work_dir = (d.getVar('WORKDIR', True))
|
||||
tarpackage = os.path.join(work_dir,'tar-package')
|
||||
try:
|
||||
f = open(tarpackage,'r')
|
||||
line = list(set(f.readline().replace('\n','').split()))
|
||||
except IOError:
|
||||
pass
|
||||
f.close()
|
||||
return line
|
||||
|
||||
|
||||
def archive_sources_patches(d,stage_name):
|
||||
'''archive sources and patches to tarball. stage_name will append strings ${stage_name} to ${PR} as middle name. for example, zlib-1.4.6-prepatch(stage_name).tar.gz '''
|
||||
import shutil
|
||||
|
||||
check_archiving_type(d)
|
||||
if not_tarball(d):
|
||||
return
|
||||
|
||||
source_tar_name = archive_sources(d,stage_name)
|
||||
if stage_name == "prepatch":
|
||||
if d.getVar('PATCHES_ARCHIVE_WITH_SERIES',True).upper() == 'TRUE':
|
||||
patch_tar_name = select_archive_patches(d,"all")
|
||||
elif d.getVar('PATCHES_ARCHIVE_WITH_SERIES',True).upper() == 'FALSE':
|
||||
patch_tar_name = select_archive_patches(d,"applying")
|
||||
else:
|
||||
bb.fatal("Please define 'PATCHES_ARCHIVE_WITH_SERIES' is strings 'True' or 'False' ")
|
||||
else:
|
||||
patch_tar_name = ''
|
||||
|
||||
if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True).upper() not in 'SRPM':
|
||||
move_tarball_deploy(d,[source_tar_name,patch_tar_name])
|
||||
else:
|
||||
tarpackage = os.path.join(d.getVar('WORKDIR', True),'tar-package')
|
||||
if os.path.exists(tarpackage):
|
||||
os.remove(tarpackage)
|
||||
for package in os.path.basename(source_tar_name), patch_tar_name:
|
||||
if package:
|
||||
store_package(d,str(package) + ' ')
|
||||
|
||||
def archive_scripts_logs(d):
|
||||
'''archive scripts and logs. scripts include .bb and .inc files and logs include stuff in "temp".'''
|
||||
|
||||
work_dir = d.getVar('WORKDIR', True)
|
||||
temp_dir = os.path.join(work_dir,'temp')
|
||||
source_archive_log_with_scripts = d.getVar('SOURCE_ARCHIVE_LOG_WITH_SCRIPTS', True)
|
||||
if source_archive_log_with_scripts == 'logs_with_scripts':
|
||||
logdir = get_bb_inc(d)
|
||||
tarlog = archive_logs(d,logdir,True)
|
||||
elif source_archive_log_with_scripts == 'logs':
|
||||
if os.path.exists(temp_dir):
|
||||
tarlog = archive_logs(d,temp_dir,False)
|
||||
else:
|
||||
return
|
||||
|
||||
if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True).upper() not in 'SRPM':
|
||||
move_tarball_deploy(d,[tarlog])
|
||||
|
||||
else:
|
||||
store_package(d,tarlog)
|
||||
|
||||
def dumpdata(d):
|
||||
'''dump environment to "${P}-${PR}.showdata.dump" including all kinds of variables and functions when running a task'''
|
||||
workdir = bb.data.getVar('WORKDIR', d, 1)
|
||||
distro = bb.data.getVar('DISTRO', d, 1)
|
||||
s = d.getVar('S', True)
|
||||
pf = d.getVar('PF', True)
|
||||
target_sys = d.getVar('TARGET_SYS', True)
|
||||
licenses = get_licenses(d)
|
||||
dumpdir = d.getVar('DEPLOY_DIR', True) + '/sources/' + target_sys + '/' + licenses + '/' + pf
|
||||
if not os.path.exists(dumpdir):
|
||||
bb.mkdirhier(dumpdir)
|
||||
|
||||
dumpfile = os.path.join(dumpdir, bb.data.expand("${P}-${PR}.showdata.dump",d))
|
||||
|
||||
bb.note("Dumping metadata into '%s'" % dumpfile)
|
||||
f = open(dumpfile, "w")
|
||||
# emit variables and shell functions
|
||||
bb.data.emit_env(f, d, True)
|
||||
# emit the metadata which isnt valid shell
|
||||
for e in d.keys():
|
||||
if bb.data.getVarFlag(e, 'python', d):
|
||||
f.write("\npython %s () {\n%s}\n" % (e, bb.data.getVar(e, d, 1)))
|
||||
f.close()
|
||||
|
||||
def create_diff_gz(d):
|
||||
'''creating .diff.gz in ${DEPLOY_DIR_SRC}/${P}-${PR}.diff.g gz for mapping all content in 's' including patches to xxx.diff.gz'''
|
||||
import shutil
|
||||
|
||||
work_dir = d.getVar('WORKDIR', True)
|
||||
exclude_from = d.getVar('ARCHIVE_EXCLUDE_FROM', True).split()
|
||||
pf = d.getVar('PF', True)
|
||||
licenses = get_licenses(d)
|
||||
target_sys = d.getVar('TARGET_SYS', True)
|
||||
diff_dir = d.getVar('DEPLOY_DIR', True) + '/sources/' + target_sys + '/' + licenses + '/' + pf
|
||||
diff_file = os.path.join(diff_dir, bb.data.expand("${P}-${PR}.diff.gz",d))
|
||||
|
||||
f = open(os.path.join(work_dir,'temp/exclude-from-file'), 'a')
|
||||
for i in exclude_from:
|
||||
f.write(i)
|
||||
f.write("\n")
|
||||
f.close()
|
||||
|
||||
s=d.getVar('S', True)
|
||||
distro = d.getVar('DISTRO',True)
|
||||
dest = s + '/' + distro + '/files'
|
||||
if not os.path.exists(dest):
|
||||
bb.mkdirhier(dest)
|
||||
for i in os.listdir(os.getcwd()):
|
||||
if os.path.isfile(i):
|
||||
try:
|
||||
shutil.copy(i, dest)
|
||||
except IOError:
|
||||
os.system('fakeroot cp -rf ' + i + " " + dest )
|
||||
|
||||
bb.note("Creating .diff.gz in ${DEPLOY_DIR_SRC}/${P}-${PR}.diff.gz")
|
||||
cmd = "LC_ALL=C TZ=UTC0 diff --exclude-from=" + work_dir + "/temp/exclude-from-file -Naur " + s + '.org' + ' ' + s + " | gzip -c > " + diff_file
|
||||
d.setVar('DIFF', cmd + "\n")
|
||||
d.setVarFlag('DIFF', 'func', '1')
|
||||
bb.build.exec_func('DIFF', d)
|
||||
shutil.rmtree(s + '.org', ignore_errors=True)
|
||||
|
||||
# This function will run when user want to get tarball for sources and patches after do_unpack
|
||||
python do_archive_original_sources_patches(){
|
||||
archive_sources_patches(d,'prepatch')
|
||||
}
|
||||
|
||||
# This function will run when user want to get tarball for patched sources after do_patch
|
||||
python do_archive_patched_sources(){
|
||||
archive_sources_patches(d,'patched')
|
||||
}
|
||||
|
||||
# This function will run when user want to get tarball for configured sources after do_configure
|
||||
python do_archive_configured_sources(){
|
||||
archive_sources_patches(d,'configured')
|
||||
}
|
||||
|
||||
# This function will run when user want to get tarball for logs or both logs and scripts(.bb and .inc files)
|
||||
python do_archive_scripts_logs(){
|
||||
archive_scripts_logs(d)
|
||||
}
|
||||
|
||||
# This function will run when user want to know what variable and functions in a running task are and also can get a diff file including
|
||||
# all content a package should include.
|
||||
python do_dumpdata_create_diff_gz(){
|
||||
dumpdata(d)
|
||||
create_diff_gz(d)
|
||||
}
|
||||
|
||||
# This functions prepare for archiving "linux-yocto" because this package create directory 's' before do_patch instead of after do_unpack.
|
||||
# This is special control for archiving linux-yocto only.
|
||||
python do_archive_linux_yocto(){
|
||||
s = d.getVar('S', True)
|
||||
if 'linux-yocto' in s:
|
||||
source_tar_name = archive_sources(d,'')
|
||||
if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True).upper() not in 'SRPM':
|
||||
move_tarball_deploy(d,[source_tar_name,''])
|
||||
}
|
||||
do_kernel_checkout[postfuncs] += "do_archive_linux_yocto "
|
||||
|
||||
# remove tarball for sources, patches and logs after creating srpm.
|
||||
python do_remove_tarball(){
|
||||
if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True).upper() == 'SRPM':
|
||||
work_dir = d.getVar('WORKDIR', True)
|
||||
try:
|
||||
for file in os.listdir(os.getcwd()):
|
||||
if file in get_package(d):
|
||||
os.remove(file)
|
||||
os.remove(os.path.join(work_dir,'tar-package'))
|
||||
except (TypeError,OSError):
|
||||
pass
|
||||
}
|
||||
do_remove_taball[deptask] = "do_archive_scripts_logs"
|
||||
do_package_write_rpm[postfuncs] += "do_remove_tarball "
|
||||
export get_licenses
|
||||
export get_package
|
|
@ -0,0 +1,4 @@
|
|||
# This will set BTS_HW_VERSION depending on the machine
|
||||
PACKAGE_ARCH = "${MACHINE_ARCH}"
|
||||
BTS_HW_VERSION_sysmobts-v1 = "-DHW_SYSMOBTS_V1"
|
||||
BTS_HW_VERSION_sysmobts-v2 = "-DHW_SYSMOBTS_V2"
|
|
@ -0,0 +1,20 @@
|
|||
# I add another image type for the sysmoBTS family
|
||||
|
||||
UBI_VOLNAME ?= "${MACHINE}-rootfs"
|
||||
|
||||
IMAGE_CMD_ubi-sysmo () {
|
||||
echo \[kernel\] >> ubinize_sysmo.cfg
|
||||
echo mode=ubi >> ubinize_sysmo.cfg
|
||||
echo image=${DEPLOY_DIR_IMAGE}/uImage-${MACHINE}.bin >> ubinize_sysmo.cfg
|
||||
echo vol_id=0 >> ubinize_sysmo.cfg
|
||||
echo vol_type=static >> ubinize_sysmo.cfg
|
||||
echo vol_name=${MACHINE}-backup-kernel >> ubinize_sysmo.cfg
|
||||
echo \[ubifs\] >> ubinize_sysmo.cfg
|
||||
echo mode=ubi >> ubinize_sysmo.cfg
|
||||
echo image=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs-sysmo >> ubinize_sysmo.cfg
|
||||
echo vol_id=1 >> ubinize_sysmo.cfg
|
||||
echo vol_type=dynamic >> ubinize_sysmo.cfg
|
||||
echo vol_name=${UBI_VOLNAME} >> ubinize_sysmo.cfg
|
||||
echo vol_flags=autoresize >> ubinize_sysmo.cfg
|
||||
mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs-sysmo ${MKUBIFS_ARGS} && ubinize -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubi-sysmo ${UBINIZE_ARGS} ubinize_sysmo.cfg
|
||||
}
|
|
@ -0,0 +1,3 @@
|
|||
PYTHON="${STAGING_BINDIR_NATIVE}/python-native/python"
|
||||
EXTRANATIVEPATH += "python-native"
|
||||
DEPENDS += " python-native "
|
|
@ -0,0 +1,13 @@
|
|||
# We have a conf and classes directory, add to BBPATH
|
||||
BBPATH := "${BBPATH}:${LAYERDIR}"
|
||||
|
||||
# We have a packages directory, add to BBFILES
|
||||
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
|
||||
BBFILES := "${BBFILES} ${LAYERDIR}/yocto-shared/*.bbappend"
|
||||
BBFILES := "${BBFILES} ${LAYERDIR}/yocto-edison/*.bbappend"
|
||||
#BBFILES := "${BBFILES} ${LAYERDIR}/yocto-master/*.bbappend"
|
||||
|
||||
BBFILE_COLLECTIONS += "sysmocom-bsp"
|
||||
BBFILE_PATTERN_sysmocom-bsp := "^${LAYERDIR}/"
|
||||
BBFILE_PRIORITY_sysmocom-bsp = "1"
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
SOC_FAMILY = "dm6446"
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
TARGET_ARCH = "arm"
|
||||
|
||||
PREFERRED_PROVIDER_virtual/kernel = "linux-sysmocom"
|
||||
PREFERRED_PROVIDERS += "virtual/${TARGET_PREFIX}depmod:module-init-tools-cross"
|
||||
|
||||
PREFERRED_VERSION_u-boot = "git"
|
||||
|
||||
KERNEL_IMAGETYPE = "uImage"
|
||||
|
||||
UBOOT_ENTRYPOINT = "0x80008000"
|
||||
UBOOT_LOADADDRESS = "0x80008000"
|
||||
|
||||
SERIAL_CONSOLE ?= "115200 ttyS0"
|
||||
EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x20000 -n"
|
||||
|
||||
#ROOT_FLASH_SIZE = "29"
|
||||
|
||||
MACHINE_FEATURES = "kernel26 serial"
|
||||
|
||||
MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "\
|
||||
busybox-ifplugd \
|
||||
watchdog \
|
||||
kernel \
|
||||
kernel-module-davinci-wdt \
|
||||
kernel-module-dspdl \
|
||||
kernel-module-dspdl-dm644x \
|
||||
kernel-module-fpgadl \
|
||||
kernel-module-fpgadl-par \
|
||||
kernel-module-leds-gpio \
|
||||
kernel-module-msgqueue \
|
||||
kernel-module-nls-ascii \
|
||||
kernel-module-nls-utf8 \
|
||||
kernel-module-rtfifo "
|
||||
|
||||
IMAGE_FSTYPES ?= "tar.bz2 cpio.gz ubifs ubi jffs2"
|
||||
|
||||
MACHINE_EXTRA_RDEPENDS = "task-sysmocom-bts sysmobts-firmware watchdog"
|
||||
#MACHINE_EXTRA_RRECOMMENDS = "dsplink-module"
|
||||
|
||||
require conf/machine/include/tune-arm926ejs.inc
|
||||
require conf/machine/include/dm6446.inc
|
|
@ -0,0 +1,13 @@
|
|||
DEFAULTTUNE ?= "geode"
|
||||
TUNE_PKGARCH ?= "${@bb.utils.contains('TUNE_FEATURES', 'm32', 'geode', '', d)}"
|
||||
|
||||
require conf/machine/include/tune-i586.inc
|
||||
|
||||
# Extra tune features
|
||||
TUNEVALID[geode] = "Enable geode specific processor optimizations"
|
||||
TUNE_CCARGS += "${@bb.utils.contains('TUNE_FEATURES', 'geode', '-march=geode -mtune=geode', '', d)}"
|
||||
|
||||
# Extra tune selections
|
||||
TUNE_FEATURES_tune-geode ?= "${TUNE_FEATURES_tune-x86} geode"
|
||||
BASE_LIB_tune-geode ?= "lib"
|
||||
PACKAGE_EXTRA_ARCHS_tune-geode = "${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486 i586 geode"
|
|
@ -0,0 +1,16 @@
|
|||
#@TYPE: Machine
|
||||
#@NAME: sysmoBTS 2050
|
||||
#@DESCRIPTION: sysmocom GmbH sysmoBTS 2050 family
|
||||
|
||||
require sysmobts-v2.conf
|
||||
|
||||
MACHINEOVERRIDES = "${MACHINE}:sysmobts-v2"
|
||||
|
||||
# we are disabling the serial console for now, as it may interfere with
|
||||
# the MSP430 service processor communication until proper filtering/splitting
|
||||
# of the serial stream is implemented in the kernel
|
||||
SERIAL_CONSOLE = ""
|
||||
|
||||
# we don't want a different UBIfs volume name, as this is compiled into u-boot,
|
||||
# and thus would require a different u-boot image in turn.
|
||||
UBI_VOLNAME="sysmobts-v2-rootfs"
|
|
@ -0,0 +1,14 @@
|
|||
#@TYPE: Machine
|
||||
#@NAME: sysmocom - systems for mobile communications GmbH GSM BTS
|
||||
#@DESCRIPTION: sysmocom - systems for mobile communications GmbH GSM BTS
|
||||
|
||||
# Make sure we build these too
|
||||
EXTRA_IMAGEDEPENDS = "dvnixload-native ubl u-boot sysmobts-firmware"
|
||||
EXTRA_IMAGECMD_jffs2 = "--little-endian --eraseblock=0x20000 --pagesize=0x800 --no-cleanmarkers --pad=0x2000000 -n"
|
||||
|
||||
# ubifs config
|
||||
MKUBIFS_ARGS = "-m 2048 -e 129024 -c 400"
|
||||
UBINIZE_ARGS = "-m 2048 -p 128KiB -s 512"
|
||||
|
||||
require conf/machine/include/sysmobts.inc
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
#@TYPE: Machine
|
||||
#@NAME: sysmocom - systems for mobile communications GmbH GSM Superfemto
|
||||
#@DESCRIPTION: sysmocom - systems for mobile communications GmbH GSM Superfemto
|
||||
|
||||
# Make sure we build these too
|
||||
EXTRA_IMAGEDEPENDS = "dvnixload-native ubl u-boot sysmobts-firmware"
|
||||
EXTRA_IMAGECMD_jffs2 = "--little-endian --eraseblock=0x20000 --pagesize=0x800 --no-cleanmarkers --pad=0x2000000 -n"
|
||||
|
||||
# ubifs config
|
||||
MKUBIFS_ARGS ?= "-m 2048 -e 129024 -c 999"
|
||||
UBINIZE_ARGS ?= "-m 2048 -p 128KiB -s 512"
|
||||
|
||||
|
||||
require conf/machine/include/sysmobts.inc
|
|
@ -0,0 +1,10 @@
|
|||
#@TYPE: Machine
|
||||
#@NAME: common_pc
|
||||
#@DESCRIPTION: Machine configuration for running a common x86
|
||||
|
||||
require sysmocom-bsc.conf
|
||||
|
||||
MACHINEOVERRIDES = "${MACHINE}:sysmocom-bsc"
|
||||
SERIAL_CONSOLE = "19200 ttyS0"
|
||||
MACHINE_CONSOLE = "console=ttyS0,19200n8"
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
#@TYPE: Machine
|
||||
#@NAME: common_pc
|
||||
#@DESCRIPTION: Machine configuration for running a common x86
|
||||
|
||||
TARGET_ARCH = "i586"
|
||||
|
||||
PREFERRED_PROVIDER_virtual/libgl = "mesa-dri"
|
||||
PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
|
||||
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite"
|
||||
PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xf86-dri-lite"
|
||||
PREFERRED_PROVIDER_virtual/kernel = "linux"
|
||||
|
||||
require conf/machine/include/tune-geode.inc
|
||||
|
||||
MACHINE_FEATURES += "kernel26 x86 usbhost pci acpi"
|
||||
|
||||
KERNEL_IMAGETYPE = "bzImage"
|
||||
|
||||
IMAGE_FSTYPES ?= "tar.gz ext3"
|
||||
|
||||
SERIAL_CONSOLE = "38400 ttyS0"
|
||||
MACHINE_CONSOLE = "console=ttyS0,38400n8"
|
||||
|
||||
# We bypass swrast but we need it to be present for X to load correctly
|
||||
XSERVER ?= "xserver-xf86-dri-lite \
|
||||
mesa-dri-driver-swrast \
|
||||
xf86-input-vmmouse \
|
||||
xf86-input-keyboard \
|
||||
xf86-input-evdev \
|
||||
xf86-video-vmware"
|
||||
|
||||
GLIBC_ADDONS = "nptl"
|
||||
GLIBC_EXTRA_OECONF = "--with-tls"
|
||||
|
||||
#MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
|
||||
MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "\
|
||||
busybox-ifplugd "
|
|
@ -0,0 +1,19 @@
|
|||
SYSMOCOM := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
|
||||
FILESEXTRAPATHS_prepend := "${SYSMOCOM}/files:"
|
||||
PRINC = "15"
|
||||
|
||||
SRC_URI += "file://busybox-ifplugd.sh \
|
||||
file://ifplugd.sh"
|
||||
|
||||
PACKAGES =+ "${PN}-ifplugd"
|
||||
|
||||
FILES_${PN}-ifplugd = "${sysconfdir}/ifplugd.sh ${sysconfdir}/init.d/busybox-ifplugd.sh"
|
||||
|
||||
INITSCRIPT_PACKAGES += "${PN}-ifplugd"
|
||||
INITSCRIPT_NAME = "busybox-ifplugd.sh"
|
||||
|
||||
|
||||
do_install_append() {
|
||||
install -m 0755 ${WORKDIR}/ifplugd.sh ${D}${sysconfdir}/
|
||||
install -m 0755 ${WORKDIR}/busybox-ifplugd.sh ${D}${sysconfdir}/init.d/
|
||||
}
|
|
@ -0,0 +1,36 @@
|
|||
#!/bin/sh
|
||||
DAEMON=/usr/bin/ifplugd
|
||||
NAME=ifplugd
|
||||
DESC="Busybox ifplugd Server"
|
||||
ARGS=" -i eth0 -M -I -r /etc/ifplugd.sh"
|
||||
|
||||
test -f $DAEMON || exit 1
|
||||
|
||||
set -e
|
||||
|
||||
case "$1" in
|
||||
start)
|
||||
echo -n "starting $DESC: $NAME... "
|
||||
/sbin/start-stop-daemon -S -b -n $NAME -a $DAEMON -- $ARGS
|
||||
echo "done."
|
||||
;;
|
||||
stop)
|
||||
echo -n "stopping $DESC: $NAME... "
|
||||
/sbin/start-stop-daemon -K -n $NAME
|
||||
echo "done."
|
||||
;;
|
||||
restart)
|
||||
echo "Not restarting $DESC: $NAME... "
|
||||
;;
|
||||
reload)
|
||||
echo -n "reloading $DESC: $NAME... "
|
||||
killall -HUP $(basename ${DAEMON})
|
||||
echo "done."
|
||||
;;
|
||||
*)
|
||||
echo "Usage: $0 {start|stop|restart|reload}"
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
exit 0
|
|
@ -0,0 +1,924 @@
|
|||
#
|
||||
# Automatically generated make config: don't edit
|
||||
# Busybox version: 1.16.2
|
||||
# Tue Oct 26 15:07:52 2010
|
||||
#
|
||||
CONFIG_HAVE_DOT_CONFIG=y
|
||||
|
||||
#
|
||||
# Busybox Settings
|
||||
#
|
||||
|
||||
#
|
||||
# General Configuration
|
||||
#
|
||||
# CONFIG_DESKTOP is not set
|
||||
# CONFIG_EXTRA_COMPAT is not set
|
||||
# CONFIG_INCLUDE_SUSv2 is not set
|
||||
# CONFIG_USE_PORTABLE_CODE is not set
|
||||
CONFIG_FEATURE_BUFFERS_USE_MALLOC=y
|
||||
# CONFIG_FEATURE_BUFFERS_GO_ON_STACK is not set
|
||||
# CONFIG_FEATURE_BUFFERS_GO_IN_BSS is not set
|
||||
CONFIG_SHOW_USAGE=y
|
||||
# CONFIG_FEATURE_VERBOSE_USAGE is not set
|
||||
CONFIG_FEATURE_COMPRESS_USAGE=y
|
||||
# CONFIG_FEATURE_INSTALLER is not set
|
||||
CONFIG_LOCALE_SUPPORT=y
|
||||
# CONFIG_FEATURE_ASSUME_UNICODE is not set
|
||||
# CONFIG_FEATURE_CHECK_UNICODE_IN_ENV is not set
|
||||
CONFIG_LONG_OPTS=y
|
||||
CONFIG_FEATURE_DEVPTS=y
|
||||
# CONFIG_FEATURE_CLEAN_UP is not set
|
||||
CONFIG_FEATURE_PIDFILE=y
|
||||
CONFIG_FEATURE_SUID=y
|
||||
CONFIG_FEATURE_SUID_CONFIG=y
|
||||
CONFIG_FEATURE_SUID_CONFIG_QUIET=y
|
||||
# CONFIG_SELINUX is not set
|
||||
# CONFIG_FEATURE_PREFER_APPLETS is not set
|
||||
CONFIG_BUSYBOX_EXEC_PATH="/proc/self/exe"
|
||||
CONFIG_FEATURE_SYSLOG=y
|
||||
CONFIG_FEATURE_HAVE_RPC=y
|
||||
|
||||
#
|
||||
# Build Options
|
||||
#
|
||||
# CONFIG_STATIC is not set
|
||||
# CONFIG_PIE is not set
|
||||
# CONFIG_NOMMU is not set
|
||||
# CONFIG_BUILD_LIBBUSYBOX is not set
|
||||
# CONFIG_FEATURE_INDIVIDUAL is not set
|
||||
# CONFIG_FEATURE_SHARED_BUSYBOX is not set
|
||||
CONFIG_LFS=y
|
||||
CONFIG_CROSS_COMPILER_PREFIX=""
|
||||
CONFIG_EXTRA_CFLAGS=""
|
||||
|
||||
#
|
||||
# Debugging Options
|
||||
#
|
||||
# CONFIG_DEBUG is not set
|
||||
# CONFIG_DEBUG_PESSIMIZE is not set
|
||||
# CONFIG_WERROR is not set
|
||||
CONFIG_NO_DEBUG_LIB=y
|
||||
# CONFIG_DMALLOC is not set
|
||||
# CONFIG_EFENCE is not set
|
||||
|
||||
#
|
||||
# Installation Options
|
||||
#
|
||||
# CONFIG_INSTALL_NO_USR is not set
|
||||
CONFIG_INSTALL_APPLET_SYMLINKS=y
|
||||
# CONFIG_INSTALL_APPLET_HARDLINKS is not set
|
||||
# CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS is not set
|
||||
# CONFIG_INSTALL_APPLET_DONT is not set
|
||||
# CONFIG_INSTALL_SH_APPLET_SYMLINK is not set
|
||||
# CONFIG_INSTALL_SH_APPLET_HARDLINK is not set
|
||||
# CONFIG_INSTALL_SH_APPLET_SCRIPT_WRAPPER is not set
|
||||
CONFIG_PREFIX="./_install"
|
||||
|
||||
#
|
||||
# Busybox Library Tuning
|
||||
#
|
||||
CONFIG_PASSWORD_MINLEN=6
|
||||
CONFIG_MD5_SIZE_VS_SPEED=2
|
||||
CONFIG_FEATURE_FAST_TOP=y
|
||||
# CONFIG_FEATURE_ETC_NETWORKS is not set
|
||||
CONFIG_FEATURE_EDITING=y
|
||||
CONFIG_FEATURE_EDITING_MAX_LEN=1024
|
||||
# CONFIG_FEATURE_EDITING_VI is not set
|
||||
CONFIG_FEATURE_EDITING_HISTORY=15
|
||||
CONFIG_FEATURE_EDITING_SAVEHISTORY=y
|
||||
CONFIG_FEATURE_TAB_COMPLETION=y
|
||||
CONFIG_FEATURE_USERNAME_COMPLETION=y
|
||||
CONFIG_FEATURE_EDITING_FANCY_PROMPT=y
|
||||
# CONFIG_FEATURE_EDITING_ASK_TERMINAL is not set
|
||||
CONFIG_FEATURE_NON_POSIX_CP=y
|
||||
# CONFIG_FEATURE_VERBOSE_CP_MESSAGE is not set
|
||||
CONFIG_FEATURE_COPYBUF_KB=4
|
||||
CONFIG_MONOTONIC_SYSCALL=y
|
||||
CONFIG_IOCTL_HEX2STR_ERROR=y
|
||||
CONFIG_FEATURE_HWIB=y
|
||||
|
||||
#
|
||||
# Applets
|
||||
#
|
||||
|
||||
#
|
||||
# Archival Utilities
|
||||
#
|
||||
CONFIG_FEATURE_SEAMLESS_LZMA=y
|
||||
CONFIG_FEATURE_SEAMLESS_BZ2=y
|
||||
CONFIG_FEATURE_SEAMLESS_GZ=y
|
||||
CONFIG_FEATURE_SEAMLESS_Z=y
|
||||
CONFIG_AR=y
|
||||
# CONFIG_FEATURE_AR_LONG_FILENAMES is not set
|
||||
CONFIG_BUNZIP2=y
|
||||
# CONFIG_BZIP2 is not set
|
||||
CONFIG_CPIO=y
|
||||
# CONFIG_FEATURE_CPIO_O is not set
|
||||
# CONFIG_FEATURE_CPIO_P is not set
|
||||
# CONFIG_DPKG is not set
|
||||
# CONFIG_DPKG_DEB is not set
|
||||
# CONFIG_FEATURE_DPKG_DEB_EXTRACT_ONLY is not set
|
||||
CONFIG_GUNZIP=y
|
||||
CONFIG_GZIP=y
|
||||
# CONFIG_FEATURE_GZIP_LONG_OPTIONS is not set
|
||||
# CONFIG_LZOP is not set
|
||||
# CONFIG_LZOP_COMPR_HIGH is not set
|
||||
# CONFIG_RPM2CPIO is not set
|
||||
# CONFIG_RPM is not set
|
||||
CONFIG_TAR=y
|
||||
CONFIG_FEATURE_TAR_CREATE=y
|
||||
CONFIG_FEATURE_TAR_AUTODETECT=y
|
||||
CONFIG_FEATURE_TAR_FROM=y
|
||||
CONFIG_FEATURE_TAR_OLDGNU_COMPATIBILITY=y
|
||||
# CONFIG_FEATURE_TAR_OLDSUN_COMPATIBILITY is not set
|
||||
CONFIG_FEATURE_TAR_GNU_EXTENSIONS=y
|
||||
# CONFIG_FEATURE_TAR_LONG_OPTIONS is not set
|
||||
# CONFIG_FEATURE_TAR_UNAME_GNAME is not set
|
||||
# CONFIG_FEATURE_TAR_NOPRESERVE_TIME is not set
|
||||
# CONFIG_UNCOMPRESS is not set
|
||||
# CONFIG_UNLZMA is not set
|
||||
# CONFIG_FEATURE_LZMA_FAST is not set
|
||||
CONFIG_UNZIP=y
|
||||
|
||||
#
|
||||
# Coreutils
|
||||
#
|
||||
CONFIG_BASENAME=y
|
||||
# CONFIG_CAL is not set
|
||||
CONFIG_CAT=y
|
||||
# CONFIG_CATV is not set
|
||||
CONFIG_CHGRP=y
|
||||
CONFIG_CHMOD=y
|
||||
CONFIG_CHOWN=y
|
||||
# CONFIG_FEATURE_CHOWN_LONG_OPTIONS is not set
|
||||
CONFIG_CHROOT=y
|
||||
# CONFIG_CKSUM is not set
|
||||
# CONFIG_COMM is not set
|
||||
CONFIG_CP=y
|
||||
# CONFIG_FEATURE_CP_LONG_OPTIONS is not set
|
||||
CONFIG_CUT=y
|
||||
CONFIG_DATE=y
|
||||
# CONFIG_FEATURE_DATE_ISOFMT is not set
|
||||
CONFIG_FEATURE_DATE_COMPAT=y
|
||||
CONFIG_DD=y
|
||||
CONFIG_FEATURE_DD_SIGNAL_HANDLING=y
|
||||
# CONFIG_FEATURE_DD_THIRD_STATUS_LINE is not set
|
||||
# CONFIG_FEATURE_DD_IBS_OBS is not set
|
||||
CONFIG_DF=y
|
||||
# CONFIG_FEATURE_DF_FANCY is not set
|
||||
CONFIG_DIRNAME=y
|
||||
# CONFIG_DOS2UNIX is not set
|
||||
# CONFIG_UNIX2DOS is not set
|
||||
CONFIG_DU=y
|
||||
CONFIG_FEATURE_DU_DEFAULT_BLOCKSIZE_1K=y
|
||||
CONFIG_ECHO=y
|
||||
CONFIG_FEATURE_FANCY_ECHO=y
|
||||
CONFIG_ENV=y
|
||||
CONFIG_FEATURE_ENV_LONG_OPTIONS=y
|
||||
# CONFIG_EXPAND is not set
|
||||
# CONFIG_FEATURE_EXPAND_LONG_OPTIONS is not set
|
||||
CONFIG_EXPR=y
|
||||
# CONFIG_EXPR_MATH_SUPPORT_64 is not set
|
||||
CONFIG_FALSE=y
|
||||
# CONFIG_FOLD is not set
|
||||
# CONFIG_FSYNC is not set
|
||||
CONFIG_HEAD=y
|
||||
# CONFIG_FEATURE_FANCY_HEAD is not set
|
||||
# CONFIG_HOSTID is not set
|
||||
CONFIG_ID=y
|
||||
# CONFIG_INSTALL is not set
|
||||
# CONFIG_FEATURE_INSTALL_LONG_OPTIONS is not set
|
||||
# CONFIG_LENGTH is not set
|
||||
CONFIG_LN=y
|
||||
CONFIG_LOGNAME=y
|
||||
CONFIG_LS=y
|
||||
CONFIG_FEATURE_LS_FILETYPES=y
|
||||
CONFIG_FEATURE_LS_FOLLOWLINKS=y
|
||||
CONFIG_FEATURE_LS_RECURSIVE=y
|
||||
CONFIG_FEATURE_LS_SORTFILES=y
|
||||
CONFIG_FEATURE_LS_TIMESTAMPS=y
|
||||
CONFIG_FEATURE_LS_USERNAME=y
|
||||
CONFIG_FEATURE_LS_COLOR=y
|
||||
# CONFIG_FEATURE_LS_COLOR_IS_DEFAULT is not set
|
||||
CONFIG_MD5SUM=y
|
||||
CONFIG_MKDIR=y
|
||||
CONFIG_FEATURE_MKDIR_LONG_OPTIONS=y
|
||||
CONFIG_MKFIFO=y
|
||||
CONFIG_MKNOD=y
|
||||
CONFIG_MV=y
|
||||
# CONFIG_FEATURE_MV_LONG_OPTIONS is not set
|
||||
# CONFIG_NICE is not set
|
||||
CONFIG_NOHUP=y
|
||||
CONFIG_OD=y
|
||||
# CONFIG_PRINTENV is not set
|
||||
CONFIG_PRINTF=y
|
||||
CONFIG_PWD=y
|
||||
CONFIG_READLINK=y
|
||||
CONFIG_FEATURE_READLINK_FOLLOW=y
|
||||
CONFIG_REALPATH=y
|
||||
CONFIG_RM=y
|
||||
CONFIG_RMDIR=y
|
||||
# CONFIG_FEATURE_RMDIR_LONG_OPTIONS is not set
|
||||
CONFIG_SEQ=y
|
||||
# CONFIG_SHA1SUM is not set
|
||||
# CONFIG_SHA256SUM is not set
|
||||
# CONFIG_SHA512SUM is not set
|
||||
CONFIG_SLEEP=y
|
||||
CONFIG_FEATURE_FANCY_SLEEP=y
|
||||
# CONFIG_FEATURE_FLOAT_SLEEP is not set
|
||||
CONFIG_SORT=y
|
||||
CONFIG_FEATURE_SORT_BIG=y
|
||||
# CONFIG_SPLIT is not set
|
||||
# CONFIG_FEATURE_SPLIT_FANCY is not set
|
||||
# CONFIG_STAT is not set
|
||||
# CONFIG_FEATURE_STAT_FORMAT is not set
|
||||
CONFIG_STTY=y
|
||||
# CONFIG_SUM is not set
|
||||
CONFIG_SYNC=y
|
||||
# CONFIG_TAC is not set
|
||||
CONFIG_TAIL=y
|
||||
CONFIG_FEATURE_FANCY_TAIL=y
|
||||
CONFIG_TEE=y
|
||||
# CONFIG_FEATURE_TEE_USE_BLOCK_IO is not set
|
||||
CONFIG_TEST=y
|
||||
# CONFIG_FEATURE_TEST_64 is not set
|
||||
CONFIG_TOUCH=y
|
||||
CONFIG_TR=y
|
||||
CONFIG_FEATURE_TR_CLASSES=y
|
||||
# CONFIG_FEATURE_TR_EQUIV is not set
|
||||
CONFIG_TRUE=y
|
||||
CONFIG_TTY=y
|
||||
CONFIG_UNAME=y
|
||||
# CONFIG_UNEXPAND is not set
|
||||
# CONFIG_FEATURE_UNEXPAND_LONG_OPTIONS is not set
|
||||
CONFIG_UNIQ=y
|
||||
CONFIG_USLEEP=y
|
||||
# CONFIG_UUDECODE is not set
|
||||
# CONFIG_UUENCODE is not set
|
||||
CONFIG_WC=y
|
||||
# CONFIG_FEATURE_WC_LARGE is not set
|
||||
CONFIG_WHO=y
|
||||
CONFIG_WHOAMI=y
|
||||
CONFIG_YES=y
|
||||
|
||||
#
|
||||
# Common options for cp and mv
|
||||
#
|
||||
# CONFIG_FEATURE_PRESERVE_HARDLINKS is not set
|
||||
|
||||
#
|
||||
# Common options for ls, more and telnet
|
||||
#
|
||||
CONFIG_FEATURE_AUTOWIDTH=y
|
||||
|
||||
#
|
||||
# Common options for df, du, ls
|
||||
#
|
||||
CONFIG_FEATURE_HUMAN_READABLE=y
|
||||
|
||||
#
|
||||
# Common options for md5sum, sha1sum, sha256sum, sha512sum
|
||||
#
|
||||
CONFIG_FEATURE_MD5_SHA1_SUM_CHECK=y
|
||||
|
||||
#
|
||||
# Console Utilities
|
||||
#
|
||||
CONFIG_CHVT=y
|
||||
CONFIG_CLEAR=y
|
||||
CONFIG_DEALLOCVT=y
|
||||
CONFIG_DUMPKMAP=y
|
||||
# CONFIG_KBD_MODE is not set
|
||||
CONFIG_LOADFONT=y
|
||||
CONFIG_LOADKMAP=y
|
||||
CONFIG_OPENVT=y
|
||||
CONFIG_RESET=y
|
||||
# CONFIG_RESIZE is not set
|
||||
# CONFIG_FEATURE_RESIZE_PRINT is not set
|
||||
CONFIG_SETCONSOLE=y
|
||||
# CONFIG_FEATURE_SETCONSOLE_LONG_OPTIONS is not set
|
||||
# CONFIG_SETFONT is not set
|
||||
# CONFIG_FEATURE_SETFONT_TEXTUAL_MAP is not set
|
||||
CONFIG_DEFAULT_SETFONT_DIR=""
|
||||
# CONFIG_SETKEYCODES is not set
|
||||
# CONFIG_SETLOGCONS is not set
|
||||
# CONFIG_SHOWKEY is not set
|
||||
|
||||
#
|
||||
# Debian Utilities
|
||||
#
|
||||
CONFIG_MKTEMP=y
|
||||
# CONFIG_PIPE_PROGRESS is not set
|
||||
CONFIG_RUN_PARTS=y
|
||||
CONFIG_FEATURE_RUN_PARTS_LONG_OPTIONS=y
|
||||
# CONFIG_FEATURE_RUN_PARTS_FANCY is not set
|
||||
CONFIG_START_STOP_DAEMON=y
|
||||
CONFIG_FEATURE_START_STOP_DAEMON_FANCY=y
|
||||
CONFIG_FEATURE_START_STOP_DAEMON_LONG_OPTIONS=y
|
||||
CONFIG_WHICH=y
|
||||
|
||||
#
|
||||
# Editors
|
||||
#
|
||||
CONFIG_AWK=y
|
||||
# CONFIG_FEATURE_AWK_LIBM is not set
|
||||
CONFIG_CMP=y
|
||||
CONFIG_DIFF=y
|
||||
# CONFIG_FEATURE_DIFF_LONG_OPTIONS is not set
|
||||
CONFIG_FEATURE_DIFF_DIR=y
|
||||
# CONFIG_ED is not set
|
||||
CONFIG_PATCH=y
|
||||
CONFIG_SED=y
|
||||
CONFIG_VI=y
|
||||
CONFIG_FEATURE_VI_MAX_LEN=1024
|
||||
CONFIG_FEATURE_VI_8BIT=y
|
||||
CONFIG_FEATURE_VI_COLON=y
|
||||
CONFIG_FEATURE_VI_YANKMARK=y
|
||||
CONFIG_FEATURE_VI_SEARCH=y
|
||||
CONFIG_FEATURE_VI_USE_SIGNALS=y
|
||||
# CONFIG_FEATURE_VI_DOT_CMD is not set
|
||||
# CONFIG_FEATURE_VI_READONLY is not set
|
||||
# CONFIG_FEATURE_VI_SETOPTS is not set
|
||||
# CONFIG_FEATURE_VI_SET is not set
|
||||
CONFIG_FEATURE_VI_WIN_RESIZE=y
|
||||
CONFIG_FEATURE_VI_OPTIMIZE_CURSOR=y
|
||||
CONFIG_FEATURE_ALLOW_EXEC=y
|
||||
|
||||
#
|
||||
# Finding Utilities
|
||||
#
|
||||
CONFIG_FIND=y
|
||||
CONFIG_FEATURE_FIND_PRINT0=y
|
||||
CONFIG_FEATURE_FIND_MTIME=y
|
||||
CONFIG_FEATURE_FIND_MMIN=y
|
||||
CONFIG_FEATURE_FIND_PERM=y
|
||||
CONFIG_FEATURE_FIND_TYPE=y
|
||||
CONFIG_FEATURE_FIND_XDEV=y
|
||||
CONFIG_FEATURE_FIND_MAXDEPTH=y
|
||||
CONFIG_FEATURE_FIND_NEWER=y
|
||||
# CONFIG_FEATURE_FIND_INUM is not set
|
||||
CONFIG_FEATURE_FIND_EXEC=y
|
||||
CONFIG_FEATURE_FIND_USER=y
|
||||
CONFIG_FEATURE_FIND_GROUP=y
|
||||
CONFIG_FEATURE_FIND_NOT=y
|
||||
CONFIG_FEATURE_FIND_DEPTH=y
|
||||
CONFIG_FEATURE_FIND_PAREN=y
|
||||
CONFIG_FEATURE_FIND_SIZE=y
|
||||
CONFIG_FEATURE_FIND_PRUNE=y
|
||||
# CONFIG_FEATURE_FIND_DELETE is not set
|
||||
CONFIG_FEATURE_FIND_PATH=y
|
||||
CONFIG_FEATURE_FIND_REGEX=y
|
||||
# CONFIG_FEATURE_FIND_CONTEXT is not set
|
||||
# CONFIG_FEATURE_FIND_LINKS is not set
|
||||
CONFIG_GREP=y
|
||||
CONFIG_FEATURE_GREP_EGREP_ALIAS=y
|
||||
CONFIG_FEATURE_GREP_FGREP_ALIAS=y
|
||||
CONFIG_FEATURE_GREP_CONTEXT=y
|
||||
CONFIG_XARGS=y
|
||||
# CONFIG_FEATURE_XARGS_SUPPORT_CONFIRMATION is not set
|
||||
# CONFIG_FEATURE_XARGS_SUPPORT_QUOTES is not set
|
||||
# CONFIG_FEATURE_XARGS_SUPPORT_TERMOPT is not set
|
||||
# CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM is not set
|
||||
|
||||
#
|
||||
# Init Utilities
|
||||
#
|
||||
# CONFIG_INIT is not set
|
||||
# CONFIG_FEATURE_USE_INITTAB is not set
|
||||
# CONFIG_FEATURE_KILL_REMOVED is not set
|
||||
CONFIG_FEATURE_KILL_DELAY=0
|
||||
# CONFIG_FEATURE_INIT_SCTTY is not set
|
||||
# CONFIG_FEATURE_INIT_SYSLOG is not set
|
||||
# CONFIG_FEATURE_EXTRA_QUIET is not set
|
||||
# CONFIG_FEATURE_INIT_COREDUMPS is not set
|
||||
# CONFIG_FEATURE_INITRD is not set
|
||||
CONFIG_HALT=y
|
||||
# CONFIG_FEATURE_CALL_TELINIT is not set
|
||||
CONFIG_TELINIT_PATH=""
|
||||
# CONFIG_MESG is not set
|
||||
|
||||
#
|
||||
# Login/Password Management Utilities
|
||||
#
|
||||
# CONFIG_FEATURE_SHADOWPASSWDS is not set
|
||||
# CONFIG_USE_BB_PWD_GRP is not set
|
||||
# CONFIG_USE_BB_SHADOW is not set
|
||||
CONFIG_USE_BB_CRYPT=y
|
||||
# CONFIG_USE_BB_CRYPT_SHA is not set
|
||||
# CONFIG_ADDGROUP is not set
|
||||
# CONFIG_FEATURE_ADDGROUP_LONG_OPTIONS is not set
|
||||
# CONFIG_FEATURE_ADDUSER_TO_GROUP is not set
|
||||
# CONFIG_DELGROUP is not set
|
||||
# CONFIG_FEATURE_DEL_USER_FROM_GROUP is not set
|
||||
# CONFIG_FEATURE_CHECK_NAMES is not set
|
||||
# CONFIG_ADDUSER is not set
|
||||
# CONFIG_FEATURE_ADDUSER_LONG_OPTIONS is not set
|
||||
CONFIG_FIRST_SYSTEM_ID=0
|
||||
CONFIG_LAST_SYSTEM_ID=0
|
||||
# CONFIG_DELUSER is not set
|
||||
# CONFIG_GETTY is not set
|
||||
CONFIG_FEATURE_UTMP=y
|
||||
# CONFIG_FEATURE_WTMP is not set
|
||||
# CONFIG_LOGIN is not set
|
||||
# CONFIG_PAM is not set
|
||||
# CONFIG_LOGIN_SCRIPTS is not set
|
||||
# CONFIG_FEATURE_NOLOGIN is not set
|
||||
# CONFIG_FEATURE_SECURETTY is not set
|
||||
# CONFIG_PASSWD is not set
|
||||
# CONFIG_FEATURE_PASSWD_WEAK_CHECK is not set
|
||||
# CONFIG_CRYPTPW is not set
|
||||
# CONFIG_CHPASSWD is not set
|
||||
# CONFIG_SU is not set
|
||||
# CONFIG_FEATURE_SU_SYSLOG is not set
|
||||
# CONFIG_FEATURE_SU_CHECKS_SHELLS is not set
|
||||
# CONFIG_SULOGIN is not set
|
||||
# CONFIG_VLOCK is not set
|
||||
|
||||
#
|
||||
# Linux Ext2 FS Progs
|
||||
#
|
||||
CONFIG_CHATTR=y
|
||||
CONFIG_FSCK=y
|
||||
# CONFIG_LSATTR is not set
|
||||
|
||||
#
|
||||
# Linux Module Utilities
|
||||
#
|
||||
# CONFIG_MODPROBE_SMALL is not set
|
||||
# CONFIG_FEATURE_MODPROBE_SMALL_OPTIONS_ON_CMDLINE is not set
|
||||
# CONFIG_FEATURE_MODPROBE_SMALL_CHECK_ALREADY_LOADED is not set
|
||||
CONFIG_INSMOD=y
|
||||
CONFIG_RMMOD=y
|
||||
CONFIG_LSMOD=y
|
||||
# CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT is not set
|
||||
CONFIG_MODPROBE=y
|
||||
CONFIG_FEATURE_MODPROBE_BLACKLIST=y
|
||||
# CONFIG_DEPMOD is not set
|
||||
|
||||
#
|
||||
# Options common to multiple modutils
|
||||
#
|
||||
# CONFIG_FEATURE_2_4_MODULES is not set
|
||||
# CONFIG_FEATURE_INSMOD_TRY_MMAP is not set
|
||||
# CONFIG_FEATURE_INSMOD_VERSION_CHECKING is not set
|
||||
# CONFIG_FEATURE_INSMOD_KSYMOOPS_SYMBOLS is not set
|
||||
# CONFIG_FEATURE_INSMOD_LOADINKMEM is not set
|
||||
# CONFIG_FEATURE_INSMOD_LOAD_MAP is not set
|
||||
# CONFIG_FEATURE_INSMOD_LOAD_MAP_FULL is not set
|
||||
CONFIG_FEATURE_CHECK_TAINTED_MODULE=y
|
||||
CONFIG_FEATURE_MODUTILS_ALIAS=y
|
||||
CONFIG_FEATURE_MODUTILS_SYMBOLS=y
|
||||
CONFIG_DEFAULT_MODULES_DIR="/lib/modules"
|
||||
CONFIG_DEFAULT_DEPMOD_FILE="modules.dep"
|
||||
|
||||
#
|
||||
# Linux System Utilities
|
||||
#
|
||||
# CONFIG_ACPID is not set
|
||||
# CONFIG_FEATURE_ACPID_COMPAT is not set
|
||||
# CONFIG_BLKID is not set
|
||||
CONFIG_DMESG=y
|
||||
CONFIG_FEATURE_DMESG_PRETTY=y
|
||||
CONFIG_FBSET=y
|
||||
CONFIG_FEATURE_FBSET_FANCY=y
|
||||
CONFIG_FEATURE_FBSET_READMODE=y
|
||||
# CONFIG_FDFLUSH is not set
|
||||
# CONFIG_FDFORMAT is not set
|
||||
CONFIG_FDISK=y
|
||||
CONFIG_FDISK_SUPPORT_LARGE_DISKS=y
|
||||
CONFIG_FEATURE_FDISK_WRITABLE=y
|
||||
# CONFIG_FEATURE_AIX_LABEL is not set
|
||||
# CONFIG_FEATURE_SGI_LABEL is not set
|
||||
# CONFIG_FEATURE_SUN_LABEL is not set
|
||||
# CONFIG_FEATURE_OSF_LABEL is not set
|
||||
# CONFIG_FEATURE_FDISK_ADVANCED is not set
|
||||
# CONFIG_FINDFS is not set
|
||||
# CONFIG_FREERAMDISK is not set
|
||||
CONFIG_FSCK_MINIX=y
|
||||
# CONFIG_MKFS_EXT2 is not set
|
||||
CONFIG_MKFS_MINIX=y
|
||||
|
||||
#
|
||||
# Minix filesystem support
|
||||
#
|
||||
CONFIG_FEATURE_MINIX2=y
|
||||
# CONFIG_MKFS_REISER is not set
|
||||
# CONFIG_MKFS_VFAT is not set
|
||||
# CONFIG_GETOPT is not set
|
||||
# CONFIG_FEATURE_GETOPT_LONG is not set
|
||||
CONFIG_HEXDUMP=y
|
||||
# CONFIG_FEATURE_HEXDUMP_REVERSE is not set
|
||||
# CONFIG_HD is not set
|
||||
CONFIG_HWCLOCK=y
|
||||
CONFIG_FEATURE_HWCLOCK_LONG_OPTIONS=y
|
||||
CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS=y
|
||||
# CONFIG_IPCRM is not set
|
||||
# CONFIG_IPCS is not set
|
||||
CONFIG_LOSETUP=y
|
||||
# CONFIG_LSPCI is not set
|
||||
# CONFIG_LSUSB is not set
|
||||
# CONFIG_MDEV is not set
|
||||
# CONFIG_FEATURE_MDEV_CONF is not set
|
||||
# CONFIG_FEATURE_MDEV_RENAME is not set
|
||||
# CONFIG_FEATURE_MDEV_RENAME_REGEXP is not set
|
||||
# CONFIG_FEATURE_MDEV_EXEC is not set
|
||||
# CONFIG_FEATURE_MDEV_LOAD_FIRMWARE is not set
|
||||
CONFIG_MKSWAP=y
|
||||
# CONFIG_FEATURE_MKSWAP_UUID is not set
|
||||
CONFIG_MORE=y
|
||||
CONFIG_FEATURE_USE_TERMIOS=y
|
||||
# CONFIG_VOLUMEID is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_EXT is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_BTRFS is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_REISERFS is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_FAT is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_HFS is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_JFS is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_XFS is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_NTFS is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_ISO9660 is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_UDF is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_LUKS is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_LINUXSWAP is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_CRAMFS is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_ROMFS is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_SYSV is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_OCFS2 is not set
|
||||
# CONFIG_FEATURE_VOLUMEID_LINUXRAID is not set
|
||||
CONFIG_MOUNT=y
|
||||
# CONFIG_FEATURE_MOUNT_FAKE is not set
|
||||
# CONFIG_FEATURE_MOUNT_VERBOSE is not set
|
||||
# CONFIG_FEATURE_MOUNT_HELPERS is not set
|
||||
# CONFIG_FEATURE_MOUNT_LABEL is not set
|
||||
CONFIG_FEATURE_MOUNT_NFS=y
|
||||
CONFIG_FEATURE_MOUNT_CIFS=y
|
||||
CONFIG_FEATURE_MOUNT_FLAGS=y
|
||||
CONFIG_FEATURE_MOUNT_FSTAB=y
|
||||
CONFIG_PIVOT_ROOT=y
|
||||
CONFIG_RDATE=y
|
||||
# CONFIG_RDEV is not set
|
||||
# CONFIG_READPROFILE is not set
|
||||
# CONFIG_RTCWAKE is not set
|
||||
# CONFIG_SCRIPT is not set
|
||||
# CONFIG_SCRIPTREPLAY is not set
|
||||
# CONFIG_SETARCH is not set
|
||||
CONFIG_SWAPONOFF=y
|
||||
# CONFIG_FEATURE_SWAPON_PRI is not set
|
||||
CONFIG_SWITCH_ROOT=y
|
||||
CONFIG_UMOUNT=y
|
||||
CONFIG_FEATURE_UMOUNT_ALL=y
|
||||
|
||||
#
|
||||
# Common options for mount/umount
|
||||
#
|
||||
CONFIG_FEATURE_MOUNT_LOOP=y
|
||||
# CONFIG_FEATURE_MTAB_SUPPORT is not set
|
||||
|
||||
#
|
||||
# Miscellaneous Utilities
|
||||
#
|
||||
# CONFIG_ADJTIMEX is not set
|
||||
# CONFIG_BBCONFIG is not set
|
||||
# CONFIG_BEEP is not set
|
||||
CONFIG_FEATURE_BEEP_FREQ=0
|
||||
CONFIG_FEATURE_BEEP_LENGTH_MS=0
|
||||
# CONFIG_CHAT is not set
|
||||
# CONFIG_FEATURE_CHAT_NOFAIL is not set
|
||||
# CONFIG_FEATURE_CHAT_TTY_HIFI is not set
|
||||
# CONFIG_FEATURE_CHAT_IMPLICIT_CR is not set
|
||||
# CONFIG_FEATURE_CHAT_SWALLOW_OPTS is not set
|
||||
# CONFIG_FEATURE_CHAT_SEND_ESCAPES is not set
|
||||
# CONFIG_FEATURE_CHAT_VAR_ABORT_LEN is not set
|
||||
# CONFIG_FEATURE_CHAT_CLR_ABORT is not set
|
||||
# CONFIG_CHRT is not set
|
||||
# CONFIG_CROND is not set
|
||||
# CONFIG_FEATURE_CROND_D is not set
|
||||
# CONFIG_FEATURE_CROND_CALL_SENDMAIL is not set
|
||||
CONFIG_FEATURE_CROND_DIR=""
|
||||
# CONFIG_CRONTAB is not set
|
||||
CONFIG_DC=y
|
||||
# CONFIG_FEATURE_DC_LIBM is not set
|
||||
# CONFIG_DEVFSD is not set
|
||||
# CONFIG_DEVFSD_MODLOAD is not set
|
||||
# CONFIG_DEVFSD_FG_NP is not set
|
||||
# CONFIG_DEVFSD_VERBOSE is not set
|
||||
# CONFIG_FEATURE_DEVFS is not set
|
||||
# CONFIG_DEVMEM is not set
|
||||
# CONFIG_EJECT is not set
|
||||
# CONFIG_FEATURE_EJECT_SCSI is not set
|
||||
# CONFIG_FBSPLASH is not set
|
||||
# CONFIG_FLASHCP is not set
|
||||
# CONFIG_FLASH_LOCK is not set
|
||||
# CONFIG_FLASH_UNLOCK is not set
|
||||
# CONFIG_FLASH_ERASEALL is not set
|
||||
# CONFIG_IONICE is not set
|
||||
# CONFIG_INOTIFYD is not set
|
||||
# CONFIG_LAST is not set
|
||||
# CONFIG_FEATURE_LAST_SMALL is not set
|
||||
# CONFIG_FEATURE_LAST_FANCY is not set
|
||||
CONFIG_LESS=y
|
||||
CONFIG_FEATURE_LESS_MAXLINES=9999999
|
||||
CONFIG_FEATURE_LESS_BRACKETS=y
|
||||
CONFIG_FEATURE_LESS_FLAGS=y
|
||||
# CONFIG_FEATURE_LESS_MARKS is not set
|
||||
# CONFIG_FEATURE_LESS_REGEXP is not set
|
||||
# CONFIG_FEATURE_LESS_WINCH is not set
|
||||
# CONFIG_FEATURE_LESS_DASHCMD is not set
|
||||
# CONFIG_FEATURE_LESS_LINENUMS is not set
|
||||
# CONFIG_HDPARM is not set
|
||||
# CONFIG_FEATURE_HDPARM_GET_IDENTITY is not set
|
||||
# CONFIG_FEATURE_HDPARM_HDIO_SCAN_HWIF is not set
|
||||
# CONFIG_FEATURE_HDPARM_HDIO_UNREGISTER_HWIF is not set
|
||||
# CONFIG_FEATURE_HDPARM_HDIO_DRIVE_RESET is not set
|
||||
# CONFIG_FEATURE_HDPARM_HDIO_TRISTATE_HWIF is not set
|
||||
# CONFIG_FEATURE_HDPARM_HDIO_GETSET_DMA is not set
|
||||
# CONFIG_MAKEDEVS is not set
|
||||
# CONFIG_FEATURE_MAKEDEVS_LEAF is not set
|
||||
# CONFIG_FEATURE_MAKEDEVS_TABLE is not set
|
||||
# CONFIG_MAN is not set
|
||||
CONFIG_MICROCOM=y
|
||||
# CONFIG_MOUNTPOINT is not set
|
||||
# CONFIG_MT is not set
|
||||
# CONFIG_RAIDAUTORUN is not set
|
||||
# CONFIG_READAHEAD is not set
|
||||
# CONFIG_RUNLEVEL is not set
|
||||
# CONFIG_RX is not set
|
||||
# CONFIG_SETSID is not set
|
||||
CONFIG_STRINGS=y
|
||||
# CONFIG_TASKSET is not set
|
||||
# CONFIG_FEATURE_TASKSET_FANCY is not set
|
||||
CONFIG_TIME=y
|
||||
# CONFIG_TIMEOUT is not set
|
||||
# CONFIG_TTYSIZE is not set
|
||||
# CONFIG_VOLNAME is not set
|
||||
# CONFIG_WALL is not set
|
||||
# CONFIG_WATCHDOG is not set
|
||||
|
||||
#
|
||||
# Networking Utilities
|
||||
#
|
||||
CONFIG_FEATURE_IPV6=y
|
||||
# CONFIG_FEATURE_UNIX_LOCAL is not set
|
||||
CONFIG_FEATURE_PREFER_IPV4_ADDRESS=y
|
||||
# CONFIG_VERBOSE_RESOLUTION_ERRORS is not set
|
||||
# CONFIG_ARP is not set
|
||||
# CONFIG_ARPING is not set
|
||||
# CONFIG_BRCTL is not set
|
||||
# CONFIG_FEATURE_BRCTL_FANCY is not set
|
||||
# CONFIG_FEATURE_BRCTL_SHOW is not set
|
||||
# CONFIG_DNSD is not set
|
||||
# CONFIG_ETHER_WAKE is not set
|
||||
# CONFIG_FAKEIDENTD is not set
|
||||
# CONFIG_FTPD is not set
|
||||
# CONFIG_FEATURE_FTP_WRITE is not set
|
||||
# CONFIG_FEATURE_FTPD_ACCEPT_BROKEN_LIST is not set
|
||||
# CONFIG_FTPGET is not set
|
||||
# CONFIG_FTPPUT is not set
|
||||
# CONFIG_FEATURE_FTPGETPUT_LONG_OPTIONS is not set
|
||||
CONFIG_HOSTNAME=y
|
||||
# CONFIG_HTTPD is not set
|
||||
# CONFIG_FEATURE_HTTPD_RANGES is not set
|
||||
# CONFIG_FEATURE_HTTPD_USE_SENDFILE is not set
|
||||
# CONFIG_FEATURE_HTTPD_SETUID is not set
|
||||
# CONFIG_FEATURE_HTTPD_BASIC_AUTH is not set
|
||||
# CONFIG_FEATURE_HTTPD_AUTH_MD5 is not set
|
||||
# CONFIG_FEATURE_HTTPD_CGI is not set
|
||||
# CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR is not set
|
||||
# CONFIG_FEATURE_HTTPD_SET_REMOTE_PORT_TO_ENV is not set
|
||||
# CONFIG_FEATURE_HTTPD_ENCODE_URL_STR is not set
|
||||
# CONFIG_FEATURE_HTTPD_ERROR_PAGES is not set
|
||||
# CONFIG_FEATURE_HTTPD_PROXY is not set
|
||||
CONFIG_IFCONFIG=y
|
||||
CONFIG_FEATURE_IFCONFIG_STATUS=y
|
||||
# CONFIG_FEATURE_IFCONFIG_SLIP is not set
|
||||
# CONFIG_FEATURE_IFCONFIG_MEMSTART_IOADDR_IRQ is not set
|
||||
CONFIG_FEATURE_IFCONFIG_HW=y
|
||||
# CONFIG_FEATURE_IFCONFIG_BROADCAST_PLUS is not set
|
||||
# CONFIG_IFENSLAVE is not set
|
||||
CONFIG_IFPLUGD=y
|
||||
CONFIG_IFUPDOWN=y
|
||||
CONFIG_IFUPDOWN_IFSTATE_PATH="/var/run/ifstate"
|
||||
# CONFIG_FEATURE_IFUPDOWN_IP is not set
|
||||
# CONFIG_FEATURE_IFUPDOWN_IP_BUILTIN is not set
|
||||
CONFIG_FEATURE_IFUPDOWN_IFCONFIG_BUILTIN=y
|
||||
CONFIG_FEATURE_IFUPDOWN_IPV4=y
|
||||
CONFIG_FEATURE_IFUPDOWN_IPV6=y
|
||||
CONFIG_FEATURE_IFUPDOWN_MAPPING=y
|
||||
# CONFIG_FEATURE_IFUPDOWN_EXTERNAL_DHCP is not set
|
||||
# CONFIG_INETD is not set
|
||||
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_ECHO is not set
|
||||
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DISCARD is not set
|
||||
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_TIME is not set
|
||||
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DAYTIME is not set
|
||||
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_CHARGEN is not set
|
||||
# CONFIG_FEATURE_INETD_RPC is not set
|
||||
CONFIG_IP=y
|
||||
CONFIG_FEATURE_IP_ADDRESS=y
|
||||
CONFIG_FEATURE_IP_LINK=y
|
||||
CONFIG_FEATURE_IP_ROUTE=y
|
||||
CONFIG_FEATURE_IP_TUNNEL=y
|
||||
# CONFIG_FEATURE_IP_RULE is not set
|
||||
# CONFIG_FEATURE_IP_SHORT_FORMS is not set
|
||||
# CONFIG_FEATURE_IP_RARE_PROTOCOLS is not set
|
||||
# CONFIG_IPADDR is not set
|
||||
# CONFIG_IPLINK is not set
|
||||
# CONFIG_IPROUTE is not set
|
||||
# CONFIG_IPTUNNEL is not set
|
||||
# CONFIG_IPRULE is not set
|
||||
# CONFIG_IPCALC is not set
|
||||
# CONFIG_FEATURE_IPCALC_FANCY is not set
|
||||
# CONFIG_FEATURE_IPCALC_LONG_OPTIONS is not set
|
||||
# CONFIG_NAMEIF is not set
|
||||
# CONFIG_FEATURE_NAMEIF_EXTENDED is not set
|
||||
CONFIG_NC=y
|
||||
# CONFIG_NC_SERVER is not set
|
||||
# CONFIG_NC_EXTRA is not set
|
||||
CONFIG_NETSTAT=y
|
||||
# CONFIG_FEATURE_NETSTAT_WIDE is not set
|
||||
# CONFIG_FEATURE_NETSTAT_PRG is not set
|
||||
CONFIG_NSLOOKUP=y
|
||||
# CONFIG_NTPD is not set
|
||||
# CONFIG_FEATURE_NTPD_SERVER is not set
|
||||
CONFIG_PING=y
|
||||
CONFIG_PING6=y
|
||||
CONFIG_FEATURE_FANCY_PING=y
|
||||
# CONFIG_PSCAN is not set
|
||||
CONFIG_ROUTE=y
|
||||
# CONFIG_SLATTACH is not set
|
||||
CONFIG_TELNET=y
|
||||
# CONFIG_FEATURE_TELNET_TTYPE is not set
|
||||
CONFIG_FEATURE_TELNET_AUTOLOGIN=y
|
||||
# CONFIG_TELNETD is not set
|
||||
# CONFIG_FEATURE_TELNETD_STANDALONE is not set
|
||||
# CONFIG_FEATURE_TELNETD_INETD_WAIT is not set
|
||||
CONFIG_TFTP=y
|
||||
# CONFIG_TFTPD is not set
|
||||
CONFIG_FEATURE_TFTP_GET=y
|
||||
CONFIG_FEATURE_TFTP_PUT=y
|
||||
# CONFIG_FEATURE_TFTP_BLOCKSIZE is not set
|
||||
# CONFIG_FEATURE_TFTP_PROGRESS_BAR is not set
|
||||
# CONFIG_TFTP_DEBUG is not set
|
||||
CONFIG_TRACEROUTE=y
|
||||
# CONFIG_TRACEROUTE6 is not set
|
||||
# CONFIG_FEATURE_TRACEROUTE_VERBOSE is not set
|
||||
# CONFIG_FEATURE_TRACEROUTE_SOURCE_ROUTE is not set
|
||||
# CONFIG_FEATURE_TRACEROUTE_USE_ICMP is not set
|
||||
CONFIG_UDHCPD=y
|
||||
# CONFIG_DHCPRELAY is not set
|
||||
CONFIG_DUMPLEASES=y
|
||||
# CONFIG_FEATURE_UDHCPD_WRITE_LEASES_EARLY is not set
|
||||
CONFIG_DHCPD_LEASES_FILE="/var/lib/misc/udhcpd.leases"
|
||||
CONFIG_UDHCPC=y
|
||||
CONFIG_FEATURE_UDHCPC_ARPING=y
|
||||
# CONFIG_FEATURE_UDHCP_PORT is not set
|
||||
CONFIG_UDHCP_DEBUG=0
|
||||
# CONFIG_FEATURE_UDHCP_RFC3397 is not set
|
||||
CONFIG_UDHCPC_DEFAULT_SCRIPT="/usr/share/udhcpc/default.script"
|
||||
CONFIG_UDHCPC_SLACK_FOR_BUGGY_SERVERS=80
|
||||
CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -n"
|
||||
# CONFIG_VCONFIG is not set
|
||||
CONFIG_WGET=y
|
||||
CONFIG_FEATURE_WGET_STATUSBAR=y
|
||||
CONFIG_FEATURE_WGET_AUTHENTICATION=y
|
||||
CONFIG_FEATURE_WGET_LONG_OPTIONS=y
|
||||
# CONFIG_ZCIP is not set
|
||||
# CONFIG_TCPSVD is not set
|
||||
# CONFIG_TUNCTL is not set
|
||||
# CONFIG_FEATURE_TUNCTL_UG is not set
|
||||
# CONFIG_UDPSVD is not set
|
||||
|
||||
#
|
||||
# Print Utilities
|
||||
#
|
||||
# CONFIG_LPD is not set
|
||||
# CONFIG_LPR is not set
|
||||
# CONFIG_LPQ is not set
|
||||
|
||||
#
|
||||
# Mail Utilities
|
||||
#
|
||||
# CONFIG_MAKEMIME is not set
|
||||
CONFIG_FEATURE_MIME_CHARSET=""
|
||||
# CONFIG_POPMAILDIR is not set
|
||||
# CONFIG_FEATURE_POPMAILDIR_DELIVERY is not set
|
||||
# CONFIG_REFORMIME is not set
|
||||
# CONFIG_FEATURE_REFORMIME_COMPAT is not set
|
||||
# CONFIG_SENDMAIL is not set
|
||||
|
||||
#
|
||||
# Process Utilities
|
||||
#
|
||||
CONFIG_FREE=y
|
||||
CONFIG_FUSER=y
|
||||
CONFIG_KILL=y
|
||||
CONFIG_KILLALL=y
|
||||
# CONFIG_KILLALL5 is not set
|
||||
# CONFIG_NMETER is not set
|
||||
# CONFIG_PGREP is not set
|
||||
CONFIG_PIDOF=y
|
||||
# CONFIG_FEATURE_PIDOF_SINGLE is not set
|
||||
# CONFIG_FEATURE_PIDOF_OMIT is not set
|
||||
# CONFIG_PKILL is not set
|
||||
CONFIG_PS=y
|
||||
CONFIG_FEATURE_PS_WIDE=y
|
||||
# CONFIG_FEATURE_PS_TIME is not set
|
||||
# CONFIG_FEATURE_PS_ADDITIONAL_COLUMNS is not set
|
||||
# CONFIG_FEATURE_PS_UNUSUAL_SYSTEMS is not set
|
||||
CONFIG_RENICE=y
|
||||
CONFIG_BB_SYSCTL=y
|
||||
CONFIG_TOP=y
|
||||
CONFIG_FEATURE_TOP_CPU_USAGE_PERCENTAGE=y
|
||||
CONFIG_FEATURE_TOP_CPU_GLOBAL_PERCENTS=y
|
||||
# CONFIG_FEATURE_TOP_SMP_CPU is not set
|
||||
# CONFIG_FEATURE_TOP_DECIMALS is not set
|
||||
# CONFIG_FEATURE_TOP_SMP_PROCESS is not set
|
||||
# CONFIG_FEATURE_TOPMEM is not set
|
||||
# CONFIG_FEATURE_SHOW_THREADS is not set
|
||||
CONFIG_UPTIME=y
|
||||
CONFIG_WATCH=y
|
||||
|
||||
#
|
||||
# Runit Utilities
|
||||
#
|
||||
# CONFIG_RUNSV is not set
|
||||
# CONFIG_RUNSVDIR is not set
|
||||
# CONFIG_FEATURE_RUNSVDIR_LOG is not set
|
||||
# CONFIG_SV is not set
|
||||
CONFIG_SV_DEFAULT_SERVICE_DIR=""
|
||||
# CONFIG_SVLOGD is not set
|
||||
# CONFIG_CHPST is not set
|
||||
# CONFIG_SETUIDGID is not set
|
||||
# CONFIG_ENVUIDGID is not set
|
||||
# CONFIG_ENVDIR is not set
|
||||
# CONFIG_SOFTLIMIT is not set
|
||||
# CONFIG_CHCON is not set
|
||||
# CONFIG_FEATURE_CHCON_LONG_OPTIONS is not set
|
||||
# CONFIG_GETENFORCE is not set
|
||||
# CONFIG_GETSEBOOL is not set
|
||||
# CONFIG_LOAD_POLICY is not set
|
||||
# CONFIG_MATCHPATHCON is not set
|
||||
# CONFIG_RESTORECON is not set
|
||||
# CONFIG_RUNCON is not set
|
||||
# CONFIG_FEATURE_RUNCON_LONG_OPTIONS is not set
|
||||
# CONFIG_SELINUXENABLED is not set
|
||||
# CONFIG_SETENFORCE is not set
|
||||
# CONFIG_SETFILES is not set
|
||||
# CONFIG_FEATURE_SETFILES_CHECK_OPTION is not set
|
||||
# CONFIG_SETSEBOOL is not set
|
||||
# CONFIG_SESTATUS is not set
|
||||
|
||||
#
|
||||
# Shells
|
||||
#
|
||||
CONFIG_FEATURE_SH_IS_ASH=y
|
||||
# CONFIG_FEATURE_SH_IS_HUSH is not set
|
||||
# CONFIG_FEATURE_SH_IS_NONE is not set
|
||||
CONFIG_ASH=y
|
||||
CONFIG_ASH_BASH_COMPAT=y
|
||||
CONFIG_ASH_JOB_CONTROL=y
|
||||
CONFIG_ASH_ALIAS=y
|
||||
CONFIG_ASH_GETOPTS=y
|
||||
CONFIG_ASH_BUILTIN_ECHO=y
|
||||
CONFIG_ASH_BUILTIN_PRINTF=y
|
||||
CONFIG_ASH_BUILTIN_TEST=y
|
||||
# CONFIG_ASH_CMDCMD is not set
|
||||
# CONFIG_ASH_MAIL is not set
|
||||
CONFIG_ASH_OPTIMIZE_FOR_SIZE=y
|
||||
# CONFIG_ASH_RANDOM_SUPPORT is not set
|
||||
CONFIG_ASH_EXPAND_PRMT=y
|
||||
# CONFIG_HUSH is not set
|
||||
# CONFIG_HUSH_BASH_COMPAT is not set
|
||||
# CONFIG_HUSH_HELP is not set
|
||||
# CONFIG_HUSH_INTERACTIVE is not set
|
||||
# CONFIG_HUSH_JOB is not set
|
||||
# CONFIG_HUSH_TICK is not set
|
||||
# CONFIG_HUSH_IF is not set
|
||||
# CONFIG_HUSH_LOOPS is not set
|
||||
# CONFIG_HUSH_CASE is not set
|
||||
# CONFIG_HUSH_FUNCTIONS is not set
|
||||
# CONFIG_HUSH_LOCAL is not set
|
||||
# CONFIG_HUSH_EXPORT_N is not set
|
||||
# CONFIG_HUSH_RANDOM_SUPPORT is not set
|
||||
# CONFIG_LASH is not set
|
||||
# CONFIG_MSH is not set
|
||||
CONFIG_SH_MATH_SUPPORT=y
|
||||
# CONFIG_SH_MATH_SUPPORT_64 is not set
|
||||
CONFIG_FEATURE_SH_EXTRA_QUIET=y
|
||||
# CONFIG_FEATURE_SH_STANDALONE is not set
|
||||
# CONFIG_FEATURE_SH_NOFORK is not set
|
||||
# CONFIG_CTTYHACK is not set
|
||||
|
||||
#
|
||||
# System Logging Utilities
|
||||
#
|
||||
CONFIG_SYSLOGD=y
|
||||
CONFIG_FEATURE_ROTATE_LOGFILE=y
|
||||
CONFIG_FEATURE_REMOTE_LOG=y
|
||||
# CONFIG_FEATURE_SYSLOGD_DUP is not set
|
||||
CONFIG_FEATURE_IPC_SYSLOG=y
|
||||
CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=16
|
||||
CONFIG_LOGREAD=y
|
||||
CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y
|
||||
CONFIG_KLOGD=y
|
||||
CONFIG_LOGGER=y
|
|
@ -0,0 +1,12 @@
|
|||
#!/bin/sh
|
||||
|
||||
case $2 in
|
||||
up)
|
||||
echo "UP"
|
||||
/sbin/ifup $1
|
||||
;;
|
||||
down)
|
||||
echo "DOWN"
|
||||
/sbin/ifdown $1
|
||||
;;
|
||||
esac
|
|
@ -0,0 +1,77 @@
|
|||
#! /bin/sh
|
||||
### BEGIN INIT INFO
|
||||
# Provides: sysklogd
|
||||
# Required-Start: $remote_fs $time
|
||||
# Required-Stop: $remote_fs $time
|
||||
# Default-Start: 2 3 4 5
|
||||
# Default-Stop: 0 1 6
|
||||
# Short-Description: System logger
|
||||
### END INIT INFO
|
||||
|
||||
set -e
|
||||
|
||||
if [ -f /etc/syslog.conf ]; then
|
||||
. /etc/syslog.conf
|
||||
LOG_LOCAL=0
|
||||
LOG_REMOTE=0
|
||||
for D in $DESTINATION; do
|
||||
if [ "$D" = "buffer" ]; then
|
||||
SYSLOG_ARGS="$SYSLOG_ARGS -C$BUFFERSIZE"
|
||||
LOG_LOCAL=1
|
||||
elif [ "$D" = "file" ]; then
|
||||
if [ -n "$LOGFILE" ]; then
|
||||
SYSLOG_ARGS="$SYSLOG_ARGS -O $LOGFILE"
|
||||
fi
|
||||
if [ -n "$ROTATESIZE" ]; then
|
||||
SYSLOG_ARGS="$SYSLOG_ARGS -s $ROTATESIZE"
|
||||
fi
|
||||
if [ -n "$ROTATEGENS" ]; then
|
||||
SYSLOG_ARGS="$SYSLOG_ARGS -b $ROTATEGENS"
|
||||
fi
|
||||
LOCAL=0
|
||||
elif [ "$D" = "remote" ]; then
|
||||
SYSLOG_ARGS="$SYSLOG_ARGS -R $REMOTE"
|
||||
LOG_REMOTE=1
|
||||
fi
|
||||
done
|
||||
if [ "$LOG_LOCAL" = "1" -a "$LOG_REMOTE" = "1" ]; then
|
||||
SYSLOG_ARGS="$SYSLOG_ARGS -L"
|
||||
fi
|
||||
if [ "$REDUCE" = "yes" ]; then
|
||||
SYSLOG_ARGS="$SYSLOG_ARGS -S"
|
||||
fi
|
||||
if [ "$DROPDUPLICATES" = "yes" ]; then
|
||||
SYSLOG_ARGS="$SYSLOG_ARGS -D"
|
||||
fi
|
||||
if [ -n "$LOGLEVEL" ]; then
|
||||
SYSLOG_ARGS="$SYSLOG_ARGS -l $LOGLEVEL"
|
||||
fi
|
||||
else
|
||||
# default: log to 16K shm circular buffer
|
||||
SYSLOG_ARGS="-C"
|
||||
fi
|
||||
|
||||
case "$1" in
|
||||
start)
|
||||
echo -n "Starting syslogd/klogd: "
|
||||
start-stop-daemon -S -b -n syslogd -a /sbin/syslogd -- -n $SYSLOG_ARGS
|
||||
start-stop-daemon -S -b -n klogd -a /sbin/klogd -- -n
|
||||
echo "done"
|
||||
;;
|
||||
stop)
|
||||
echo -n "Stopping syslogd/klogd: "
|
||||
start-stop-daemon -K -n syslogd
|
||||
start-stop-daemon -K -n klogd
|
||||
echo "done"
|
||||
;;
|
||||
restart)
|
||||
$0 stop
|
||||
$0 start
|
||||
;;
|
||||
*)
|
||||
echo "Usage: syslog { start | stop | restart }" >&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
exit 0
|
|
@ -0,0 +1,22 @@
|
|||
DESTINATION="buffer" # log destinations (buffer file remote)
|
||||
MARKINT=20 # intervall between --mark-- entries
|
||||
LOGFILE=/var/log/messages # where to log (file)
|
||||
REMOTE=loghost:514 # where to log (syslog remote)
|
||||
REDUCE=no # reduce-size logging
|
||||
#ROTATESIZE=0 # rotate log if grown beyond X [kByte] (incompatible with busybox)
|
||||
#ROTATEGENS=3 # keep X generations of rotated logs (incompatible with busybox)
|
||||
BUFFERSIZE=64 # size of circular buffer [kByte]
|
||||
FOREGROUND=no # run in foreground (don't use!)
|
||||
LOGLEVEL=6
|
||||
|
||||
# magic when a MMC card is mounted
|
||||
USING_MMC_CARD=`/bin/mount | grep /media/mmcblk0p1 | wc -l`
|
||||
if [ 1 -eq $USING_MMC_CARD ] ; then
|
||||
if [ -e /media/mmcblk0p1/log ] ; then
|
||||
echo "Using mmc card"
|
||||
LOGFILE=/media/mmcblk0p1/log/messages
|
||||
DESTINATION="file"
|
||||
ROTATESIZE=2048
|
||||
ROTATEGENS=20
|
||||
fi
|
||||
fi
|
|
@ -0,0 +1,13 @@
|
|||
DESCRIPTION = "sysmocom BSC/E1 image"
|
||||
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
|
||||
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
|
||||
|
||||
LICENSE = "MIT"
|
||||
|
||||
inherit boot-directdisk
|
||||
|
||||
|
||||
ROOTFS = "${DEPLOY_DIR_IMAGE}/sysmocom-bsc-e1-image-${MACHINE}.ext3"
|
||||
do_bootdirectdisk[depends] += "sysmocom-bsc-e1-image:do_rootfs"
|
||||
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${ROOTFS_PKGMANAGE} task-osmocom task-sysmocom \
|
||||
task-sysmocom-debug task-sysmocom-tools task-sysmocom-e1 task-gprscore \
|
||||
e2fsprogs-mke2fs e2fsprogs-tune2fs e2fsprogs-e2fsck e2fsprogs-fsck \
|
||||
kernel-module-nls-iso8859-1 kernel-module-nls-cp437"
|
||||
IMAGE_LINGUAS = " "
|
||||
LICENSE = "MIT"
|
||||
|
||||
inherit core-image
|
||||
|
||||
IMAGE_ROOTFS_SIZE = "524288"
|
|
@ -0,0 +1,8 @@
|
|||
require sysmocom-image.inc
|
||||
|
||||
# This variant of the image will run osmo-bts and osmo-bsc
|
||||
activate_bsc() {
|
||||
echo "NO_START=0" > ${IMAGE_ROOTFS}/etc/default/osmo-bsc
|
||||
}
|
||||
|
||||
IMAGE_PREPROCESS_COMMAND += "activate_bsc; "
|
|
@ -0,0 +1,13 @@
|
|||
DESCRIPTION = "sysmocom BSC/IP image"
|
||||
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
|
||||
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
|
||||
|
||||
LICENSE = "MIT"
|
||||
|
||||
inherit boot-directdisk
|
||||
|
||||
|
||||
ROOTFS = "${DEPLOY_DIR_IMAGE}/sysmocom-bsc-ip-image-${MACHINE}.ext3"
|
||||
do_bootdirectdisk[depends] += "sysmocom-bsc-ip-image:do_rootfs"
|
||||
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${ROOTFS_PKGMANAGE} task-osmocom task-sysmocom task-sysmocom-debug task-sysmocom-tools task-gprscore sysmocom-udhcpd-config busybox-udhcpd"
|
||||
IMAGE_LINGUAS = " "
|
||||
LICENSE = "MIT"
|
||||
|
||||
inherit core-image
|
||||
|
||||
IMAGE_ROOTFS_SIZE = "262144"
|
|
@ -0,0 +1,10 @@
|
|||
IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} task-osmocom task-sysmocom"
|
||||
IMAGE_LINGUAS = " "
|
||||
LICENSE = "MIT"
|
||||
|
||||
inherit core-image
|
||||
|
||||
IMAGE_ROOTFS_SIZE = "8192"
|
||||
|
||||
# remove not needed ipkg informations
|
||||
ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; "
|
|
@ -0,0 +1 @@
|
|||
require sysmocom-image.inc
|
|
@ -0,0 +1,19 @@
|
|||
DEPENDS = "${MACHINE_EXTRA_RDEPENDS}"
|
||||
IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${ROOTFS_PKGMANAGE} task-osmocom task-sysmocom task-sysmocom-debug task-sysmocom-tools ${MACHINE_EXTRA_RDEPENDS} "
|
||||
IMAGE_LINGUAS = " "
|
||||
LICENSE = "MIT"
|
||||
|
||||
inherit core-image
|
||||
|
||||
IMAGE_ROOTFS_SIZE = "32768"
|
||||
|
||||
|
||||
link_uimage() {
|
||||
echo "Linking the current uImage to /boot/uImage"
|
||||
OLD_PWD=$PWD
|
||||
cd ${IMAGE_ROOTFS}/boot
|
||||
ln -s uImage-* uImage || true
|
||||
cd $OLD_PWD
|
||||
}
|
||||
|
||||
IMAGE_PREPROCESS_COMMAND += "link_uimage; "
|
|
@ -0,0 +1,8 @@
|
|||
require sysmocom-image.inc
|
||||
|
||||
# This variant of the image will run osmo-bts and osmo-nitb
|
||||
activate_nitb() {
|
||||
echo "NO_START=0" > ${IMAGE_ROOTFS}/etc/default/osmo-nitb
|
||||
}
|
||||
|
||||
IMAGE_PREPROCESS_COMMAND += "activate_nitb; "
|
|
@ -0,0 +1,57 @@
|
|||
#!/bin/sh
|
||||
|
||||
|
||||
# Make sure to look at sysmocom-restore to check if the file would
|
||||
# be restored right. Currently only some dirs get restored.
|
||||
FILES="\
|
||||
etc/hostname \
|
||||
etc/ifplugd.sh \
|
||||
etc/network/interfaces \
|
||||
etc/openvpn
|
||||
etc/osmocom/osmo-bsc-mgcp.cfg \
|
||||
etc/osmocom/osmo-bsc.cfg \
|
||||
etc/osmocom/osmo-bts.cfg \
|
||||
etc/osmocom/osmo-nitb.cfg \
|
||||
etc/osmocom/osmo-pcu.cfg \
|
||||
etc/osmocom/osmo-sgsn.cfg \
|
||||
etc/ggsn.conf \
|
||||
etc/default \
|
||||
var/lib/osmocom/hlr.sqlite3 \
|
||||
"
|
||||
DATE=`date +%Y%m%d`
|
||||
|
||||
|
||||
do_backup_files() {
|
||||
BACKUP_FILE="/home/root/sysmocom-backup_$DATE.tar"
|
||||
|
||||
# 0. Sanity checking
|
||||
if [ -e $BACKUP_FILE ]; then
|
||||
echo "The backup file '$BACKUP_FILE' already exists. Exiting!"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 1. Create an empty archive..
|
||||
tar -cf $BACKUP_FILE --files-from=/dev/null
|
||||
|
||||
# 2. Add all the files... we need
|
||||
for file in $FILES;
|
||||
do
|
||||
if [ -e "/$file" ]; then
|
||||
tar -rf $BACKUP_FILE --transform='s,^,content/,' -C / $file
|
||||
fi
|
||||
done
|
||||
|
||||
# 3. Generate more information
|
||||
NAME="/tmp/backup.$RANDOM"
|
||||
mkdir $NAME
|
||||
opkg list_installed > $NAME/installed_packages
|
||||
/sbin/ifconfig | grep HWaddr | cut -d ' ' -f 11 > $NAME/mac_addr
|
||||
|
||||
# 4. Add the more information
|
||||
tar -rf $BACKUP_FILE --transform='s,^,info/,' -C $NAME installed_packages mac_addr
|
||||
|
||||
# 5.
|
||||
echo "The backup was stored to $BACKUP_FILE"
|
||||
}
|
||||
|
||||
do_backup_files
|
|
@ -0,0 +1,26 @@
|
|||
#!/bin/sh
|
||||
|
||||
do_extract() {
|
||||
# List the files and check if grep hits something
|
||||
SEARCH=`tar -tvf $1 | grep $2`
|
||||
RES=$?
|
||||
if [ $RES = 0 ]; then
|
||||
tar -C / -xvf $1 --strip=1 $2
|
||||
else
|
||||
echo "Directory '$2' is not in backup '$1'."
|
||||
fi
|
||||
}
|
||||
|
||||
do_restore_files() {
|
||||
BACKUP_FILE=$1
|
||||
if [ ! -e "$BACKUP_FILE" ] ; then
|
||||
echo "The backup file '$BACKUP_FILE' does not exist. Exiting!"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "Going to extract files from the backup '$BACKUP_FILE'"
|
||||
do_extract $BACKUP_FILE content/etc
|
||||
do_extract $BACKUP_FILE content/var/lib/osmocom
|
||||
}
|
||||
|
||||
do_restore_files $1
|