summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat
-rw-r--r--documentation/bsp-guide/bsp.xml860
1 files changed, 429 insertions, 431 deletions
diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index e4a113a3f2..df1a557a5d 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -754,454 +754,452 @@
754 You must eventually rebuild the image if you want to remove this restriction. 754 You must eventually rebuild the image if you want to remove this restriction.
755 </note> 755 </note>
756 </section> 756 </section>
757 <section id='yocto-bsp-tools'> 757
758 <title>Using the Yocto BSP Tools</title> 758 <section id='using-the-yocto-projects-bsp-tools'>
759 <para> 759 <title>Using the Yocto Project's BSP Tools</title>
760 The Yocto Project includes a couple of tools that enable 760
761 you to create a BSP from scratch 761 <para>
762 (<filename>yocto-bsp</filename>) and do basic 762 The Yocto Project includes a couple of tools that enable
763 configuration and maintenance of the kernel 763 you to create a <link linkend='bsp-layers'>BSP layer</link>
764 (<filename>yocto-kernel</filename>) without ever looking at 764 from scratch and do basic configuration and maintenance
765 a Yocto metadata file. 765 of the kernel without ever looking at a Yocto Project metadata file.
766 </para> 766 These tools are <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename>,
767 <para> 767 respectively.
768 The following sections describe each of those tools in
769 detail, but there are some features common to both that
770 will be useful to describe before delving into the
771 details of either.
772 </para>
773 <para>
774 First, a word about how the tools are structured.
775 Designed to have a 'git-like' command interface, each
776 tool is structured as a set of sub-commands under a
777 'top-level' command. The top-level command
778 (<filename>yocto-bsp</filename>
779 or <filename>yocto-kernel</filename>) itself does
780 nothing but invoke or provide help on the sub-commands
781 it supports.
782 </para>
783 <para>
784 Secondly, since the tools themselves live in
785 the <filename>scripts/</filename> subdirectory, in order
786 to use them, you need to 'source' the environment just
787 as you would when invoking a build:
788 <literallayout class='monospaced'>
789 $ source oe-init-build-env [build_dir]
790 </literallayout>
791 </para>
792 <para>
793 With that in mind, the most immediately useful function
794 to describe is the built-in help system common to both
795 tools.
796 </para>
797 <para>
798 The built-in help system makes it easy to drill down at
799 any time and remind oneself of the syntax required for
800 any specific command.
801 </para>
802 <para>
803 Simply entering the name of the command, or the command
804 along with 'help' will display a list of the available
805 sub-commands. For example:
806 </para>
807 <para>
808 <literallayout class='monospaced'>
809 $ yocto-bsp
810 $ yocto-bsp help
811
812 Usage:
813
814 Create a customized Yocto BSP layer.
815
816 usage: yocto-bsp [--version] [--help] COMMAND [ARGS]
817
818 The most commonly used 'yocto-bsp' commands are:
819 create Create a new Yocto BSP
820 list List available values for options and BSP properties
821
822 See 'yocto-bsp help COMMAND' for more information on a specific command.
823
824
825 Options:
826 --version show program's version number and exit
827 -h, --help show this help message and exit
828 -D, --debug output debug information
829 </literallayout>
830 </para>
831 <para>
832 Similarly, entering just the name of a sub-command will
833 show the detailed usage for that sub-command:
834 </para>
835 <para>
836 <literallayout class='monospaced'>
837 $ yocto-bsp create
838
839 Usage:
840
841 Create a new Yocto BSP
842 usage: yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
843 [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
844
845 This command creates a Yocto BSP based on the specified parameters.
846 The new BSP will be a new Yocto BSP layer contained by default within
847 the top-level directory specified as 'meta-bsp-name'. The -o option
848 can be used to place the BSP layer in a directory with a different
849 name and location.
850
851 ...
852 </literallayout>
853 </para>
854 <para>
855 For any sub-command, you can also use the word 'help'
856 just before the sub-command to get more extensive
857 documentation on the sub-command:
858 </para> 768 </para>
859 <para> 769
860 <literallayout class='monospaced'> 770 <para>
861 $ yocto-bsp help create 771 The following sections describe the common location and help features as well
862 772 as details for the <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename>
863 NAME 773 tools.
864 yocto-bsp create - Create a new Yocto BSP 774 </para>
865 775
866 SYNOPSIS 776 <section id='common-features'>
867 yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;] 777 <title>Common Features</title>
868 [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;] 778
869 779 <para>
870 DESCRIPTION 780 Designed to have a command interface somewhat like
871 This command creates a Yocto BSP based on the specified 781 <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>, each
872 parameters. The new BSP will be a new Yocto BSP layer contained 782 tool is structured as a set of sub-commands under a
873 by default within the top-level directory specified as 783 top-level command.
874 'meta-bsp-name'. The -o option can be used to place the BSP layer 784 The top-level command (<filename>yocto-bsp</filename>
875 in a directory with a different name and location. 785 or <filename>yocto-kernel</filename>) itself does
786 nothing but invoke or provide help on the sub-commands
787 it supports.
788 </para>
789
790 <para>
791 Both tools reside in the <filename>scripts/</filename> subdirectory
792 of the <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project
793 Files</ulink>.
794 Consequently, to use the scripts, you must <filename>source</filename> the
795 environment just as you would when invoking a build:
796 <literallayout class='monospaced'>
797 $ source oe-init-build-env [build_dir]
798 </literallayout>
799 </para>
800
801 <para>
802 The most immediately useful function is to get help on both tools.
803 The built-in help system makes it easy to drill down at
804 any time and view the syntax required for any specific command.
805 Simply enter the name of the command, or the command along with
806 <filename>help</filename> to display a list of the available sub-commands.
807 Here is an example:
808 <literallayout class='monospaced'>
809 $ yocto-bsp
810 $ yocto-bsp help
811
812 Usage:
813
814 Create a customized Yocto BSP layer.
815
816 usage: yocto-bsp [--version] [--help] COMMAND [ARGS]
817
818 The most commonly used 'yocto-bsp' commands are:
819 create Create a new Yocto BSP
820 list List available values for options and BSP properties
821
822 See 'yocto-bsp help COMMAND' for more information on a specific command.
823
824
825 Options:
826 --version show program's version number and exit
827 -h, --help show this help message and exit
828 -D, --debug output debug information
829 </literallayout>
830 </para>
831
832 <para>
833 Similarly, entering just the name of a sub-command shows the detailed usage
834 for that sub-command:
835 <literallayout class='monospaced'>
836 $ yocto-bsp create
837
838 Usage:
839
840 Create a new Yocto BSP
841 usage: yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
842 [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
843
844 This command creates a Yocto BSP based on the specified parameters.
845 The new BSP will be a new Yocto BSP layer contained by default within
846 the top-level directory specified as 'meta-bsp-name'. The -o option
847 can be used to place the BSP layer in a directory with a different
848 name and location.
849
850 ...
851 </literallayout>
852 </para>
853
854 <para>
855 For any sub-command, you can also use the word 'help' just before the
856 sub-command to get more extensive documentation:
857 <literallayout class='monospaced'>
858 $ yocto-bsp help create
859
860 NAME
861 yocto-bsp create - Create a new Yocto BSP
862
863 SYNOPSIS
864 yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
865 [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
866
867 DESCRIPTION
868 This command creates a Yocto BSP based on the specified
869 parameters. The new BSP will be a new Yocto BSP layer contained
870 by default within the top-level directory specified as
871 'meta-bsp-name'. The -o option can be used to place the BSP layer
872 in a directory with a different name and location.
876 873
877 The value of the 'karch' parameter determines the set of files 874 The value of the 'karch' parameter determines the set of files
878 that will be generated for the BSP, along with the specific set of 875 that will be generated for the BSP, along with the specific set of
879 'properties' that will be used to fill out the BSP-specific 876 'properties' that will be used to fill out the BSP-specific
880 portions of the BSP. 877 portions of the BSP.
881 878
882 ... 879 ...
883 880
884 NOTE: Once created, you should add your new layer to your 881 NOTE: Once created, you should add your new layer to your
885 bblayers.conf file in order for it to be subsquently seen and 882 bblayers.conf file in order for it to be subsquently seen and
886 modified by the yocto-kernel tool. 883 modified by the yocto-kernel tool.
887 884
888 NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the 885 NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
889 presence of the of the meta-intel layer, so you should also have a 886 presence of the of the meta-intel layer, so you should also have a
890 meta-intel layer present and added to your bblayers.conf as well. 887 meta-intel layer present and added to your bblayers.conf as well.
891 </literallayout> 888 </literallayout>
892 </para> 889 </para>
893 <para> 890
894 With the knowledge that there are two 891 <para>
895 commands, <filename>yocto-bsp</filename> 892 Now that you know where these two commands reside and how to access information
896 and <filename>yocto-kernel</filename> and a built-in 893 on them, you should find it relatively straightforward to discover the commands
897 help system available for each, it should be relatively 894 necessary to create a BSP and perform basic kernel maintainence on that BSP using
898 straightforward to discover the commands necessary to 895 the tools.
899 create a BSP and do basic kernel maintainence of that 896 The next sections provide a concrete starting point to expand on a few points that
900 BSP using the tools. The following sections are 897 might not be immediately obvious or that could use further explanation.
901 provided, however, in order to serve as a concrete 898 </para>
902 starting point and to expand on a few points that may 899 </section>
903 not be immediately obvious or that could use further 900
904 explanation. 901
905 </para> 902 <section id='creating-a-new-bsp-layer-using-the-yocto-bsp-script'>
906 <section id='using-yocto-bsp'> 903 <title>Creating a new BSP Layer Using the yocto-bsp Script</title>
907 <title>Creating a new BSP using <filename>yocto-bsp</filename></title> 904
908 <para> 905 <para>
909 <filename>yocto-bsp</filename> is a Yocto script that 906 The <filename>yocto-bsp</filename> script creates a new
910 allows you to create a new Yocto BSP for any 907 <link linkend='bsp-layers'>BSP layer</link> for any architecture supported
911 architecture supported Yocto, as well as qemu versions 908 by the Yocto Project, as well as QEMU versions of the same.
912 of the same. The default mode of operation when invoked 909 The default mode of the script's operation is to prompt you for information needed
913 from the command-line is to prompt the user for 910 to generate the BSP layer.
914 information needed to generate the BSP. For the current 911 For the current set of BSPs, the script prompts you for various important
915 set of BSPs, the user is prompted for various important 912 parameters such as:
916 parameters such as which kernel to use, which branch of 913 <itemizedlist>
917 that kernel to use (or re-use), whether or not to use X, 914 <listitem><para>which kernel to use</para></listitem>
918 and if so, which drivers to use, whether to turn on SMP, 915 <listitem><para>which branch of that kernel to use (or re-use)</para></listitem>
919 whether the BSP has a keyboard, touchscreen, or anything 916 <listitem><para>whether or not to use X, and if so, which drivers to use</para></listitem>
920 that happens to be configurable and has an associated 917 <listitem><para>whether to turn on SMP</para></listitem>
921 input prompt. 918 <listitem><para>whether the BSP has a keyboard</para></listitem>
922 </para> 919 <listitem><para>whether the BSP has a touchscreen</para></listitem>
923 <para> 920 <listitem><para>any remaining configurable items associated with the BSP</para></listitem>
924 The <filename>yocto-bsp create</filename> sub-command is 921 </itemizedlist>
925 the sub-command you use to create a new BSP. It 922 </para>
926 requires you to specify a particular architecture to 923
927 base the BSP on. You can use the <filename>yocto-bsp 924 <para>
928 list karch</filename> sub-command to list the 925 You use the <filename>yocto-bsp create</filename> sub-command to create
929 architectures available for BSP creation: 926 a new BSP layer.
930 </para> 927 This command requires you to specify a particular architecture on which to
931 <para> 928 base the BSP.
932 Assuming you've sourced the environment, you can invoke 929 Assuming you have sourced the environment, you can use the
933 the <filename>yocto-bsp create</filename> command to 930 <filename>yocto-bsp list karch</filename> sub-command to list the
934 create the BSP. The example below uses 'myarm' as the 931 architectures available for BSP creation as follows:
935 machine name, and tells it to use the 'qemu' 932 <literallayout class='monospaced'>
936 architecture (the specific qemu machine architecture to 933 $ yocto-bsp list karch
937 use will be prompted for). You can use the 'yocto-bsp 934 Architectures available:
938 list karch' command to list the aviailable architectures 935 arm
939 for BSP creation: 936 powerpc
940 </para> 937 i386
941 <para> 938 mips
942 <literallayout class='monospaced'> 939 x86_64
943 $ yocto-bsp list karch 940 qemu
944 Architectures available: 941 </literallayout>
945 arm 942 </para>
946 powerpc 943
947 i386 944 <para>
948 mips 945 The remainder of this section presents an example that uses
949 x86_64 946 <filename>myarm</filename> as the machine name and <filename>qemu</filename>
950 qemu 947 as the machine architecture.
951 </literallayout> 948 Of the available architectures, <filename>qemu</filename> is the only architecture
952 </para> 949 that causes the script to prompt you further for an actual architecture.
953 <para> 950 In every other way, this architecture is representative of how creating a BSP for
954 For the example output below, we'll use the 'qemu' 951 a 'real' machine would work.
955 architecture, which is a special architecture that is 952 The reason the example uses this architecture is because it is an emulated architecture
956 the only one of the supported architectures that will 953 and can easily be followed without requireing actual hardware.
957 prompt you further for a 'real' architecture. In every 954 </para>
958 other way, it's representative of how creating a BSP for 955
959 a 'real' machine would work; the reason we're using it 956 <para>
960 here as an example is that since it's an emulated 957 As the <filename>yocto-bsp create</filename> command runs, default values for
961 architecture, it's easy for readers to try out 958 the prompts appear in brackets.
962 themselves without having any special hardware 959 Pressing enter without supplying anything on the command line or pressing enter
963 requirements. 960 and providing an invalid response causes the script to accept the default value.
964 </para> 961 </para>
965 <para> 962
966 The 'yocto-bsp create' command for the qemu architecture 963 <para>
967 will display the following prompts along the way to 964 Following is the complete example:
968 gather the input required for BSP generation. Each 965 <literallayout class='monospaced'>
969 prompt asks for input, but has a default value [in 966 $ yocto-bsp create myarm qemu
970 brackets]. If you press 'enter' (or any invalid value), 967 Which qemu architecture would you like to use? [default: x86]
971 the default value will automatically be used. 968 1) common 32-bit x86
972 </para> 969 2) common 64-bit x86
973 <para> 970 3) common 32-bit ARM
974 In the case of the qemu architecture, the first prompt 971 4) common 32-bit PowerPC
975 asks which emulated architecture to use. In this 972 5) common 32-bit MIPS
976 example, we'll use the 'arm' qemu architecture. 973 3
977 </para> 974 Would you like to use the default (3.2) kernel? (Y/n)
978 <para> 975 Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [Y/n]
979 It then asks if the default kernel (3.2) is ok, and we 976 Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.2...
980 press enter, essentially telling it 'yes'. If we had 977 Please choose a machine branch to base this BSP on => [default: standard/default/common-pc]
981 entered 'n', we would have been prompted to choose a 978 1) base
982 different kernel from a list of available kernels (3.0, 979 2) standard/base
983 3.2_preempt-rt, etc). 980 3) standard/default/arm-versatile-926ejs
984 </para> 981 4) standard/default/base
985 <para> 982 5) standard/default/beagleboard
986 Once we've selected the kernel, the next prompt asks 983 6) standard/default/cedartrailbsp (copy).xml
987 whether we'd like to have a new branch in the Yocto 984 7) standard/default/common-pc-64/base
988 kernel git repository created especially for this BSP, 985 8) standard/default/common-pc-64/jasperforest
989 or whether we'll just re-use an existing branch. If we 986 9) standard/default/common-pc-64/romley
990 say 'yes', which is the default, the BSP code generated 987 10) standard/default/common-pc-64/sugarbay
991 will create a new branch specifically for the BSP rather 988 11) standard/default/common-pc/atom-pc
992 than a common shared branch; this is the branch that any 989 12) standard/default/common-pc/base
993 patches we add later would be committed. The reason 990 13) standard/default/crownbay
994 creating a new branch is the default is that typically 991 14) standard/default/emenlow
995 new BSPs do require BSP-specific patches and so the BSP 992 15) standard/default/fishriver
996 tool assumes that most of time a new branch will be 993 16) standard/default/fri2
997 required. Note that in the current implementation it 994 17) standard/default/fsl-mpc8315e-rdb
998 doesn't actually matter, since the generated BSPs assume 995 18) standard/default/mti-malta32-be
999 that patches and configuration live in recipe-space, 996 19) standard/default/mti-malta32-le
1000 which is something that can be done with or without a 997 20) standard/default/preempt-rt
1001 dedicated branch. The BSP that's generated, however, 998 21) standard/default/qemu-ppc32
1002 will be different, and this difference will become 999 22) standard/default/routerstationpro
1003 significant once 'publish' functionality is implemented. 1000 23) standard/preempt-rt/base
1004 </para> 1001 24) standard/preempt-rt/qemu-ppc32
1005 <para> 1002 25) standard/preempt-rt/routerstationpro
1006 Regardless of which choice we made in the previous step, 1003 26) standard/tiny
1007 we're then given the opportunity to select a particular 1004 3
1008 machine branch to base our new BSP-specific machine 1005 Do you need SMP support? (Y/n)
1009 branch on (or re-use if we elected not to create a new 1006 Does your BSP have a touchscreen? (y/N)
1010 branch). Because we're generating an arm BSP, we choose 1007 Does your BSP have a keyboard? (Y/n)
1011 #3 at that prompt to select the arm-versatile branch. 1008 New qemu BSP created in meta-myarm
1012 The rest of the prompts are routine, and once all the 1009 </literallayout>
1013 questions have been completed, the BSP is generated 1010 Let's take a closer look at the example now:
1014 along with a message telling you so. The output of the 1011 <orderedlist>
1015 complete session is shown below: 1012 <listitem><para>For the <filename>qemu</filename> architecture,
1016 </para> 1013 the script first prompts you for which emulated architecture to use.
1017 <para> 1014 In the example, we use the <filename>arm</filename> architecture.
1018 <literallayout class='monospaced'> 1015 </para></listitem>
1019$ yocto-bsp create myarm qemu 1016 <listitem><para>The script then prompts you for the kernel.
1020Which qemu architecture would you like to use? [default: x86] 1017 The default kernel is 3.2 and is acceptable.
1021 1) common 32-bit x86 1018 So, the example accepts the default.
1022 2) common 64-bit x86 1019 If you enter 'n', the script prompts you to further enter the kernel
1023 3) common 32-bit ARM 1020 you do want to use (e.g. 3.0, 3.2_preempt-rt, etc.).</para></listitem>
1024 4) common 32-bit PowerPC 1021 <listitem><para>Next, the script asks whether you would like to have a new
1025 5) common 32-bit MIPS 1022 branch created especially for your BSPin the local
10263 1023 <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>
1027Would you like to use the default (3.2) kernel? (Y/n) 1024 Git repository .
1028Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [Y/n] 1025 If not, then the script re-uses an existing branch.</para>
1029Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.2... 1026 <para>In this example, the default (or 'yes') is accepted.
1030Please choose a machine branch to base this BSP on => [default: standard/default/common-pc] 1027 Thus, a new branch is created for the BSP rather than using a common, shared
1031 1) base 1028 branch.
1032 2) standard/base 1029 The new branch is the branch committed to for any patches you might later add.
1033 3) standard/default/arm-versatile-926ejs 1030 The reason a new branch is the default is that typically
1034 4) standard/default/base 1031 new BSPs do require BSP-specific patches.
1035 5) standard/default/beagleboard 1032 The tool thus assumes that most of time a new branch is required.
1036 6) standard/default/cedartrail 1033 <note>In the current implementation, creation or re-use of a branch does
1037 7) standard/default/common-pc-64/base 1034 not actually matter.
1038 8) standard/default/common-pc-64/jasperforest 1035 The reason is because the generated BSPs assume that patches and
1039 9) standard/default/common-pc-64/romley 1036 configurations live in recipe-space, which is something that can be done
1040 10) standard/default/common-pc-64/sugarbay 1037 with or without a dedicated branch.
1041 11) standard/default/common-pc/atom-pc 1038 Generated BSPs, however, are different.
1042 12) standard/default/common-pc/base 1039 This difference becomes significant once the tool's 'publish' functionality
1043 13) standard/default/crownbay 1040 is implemented.</note></para></listitem>
1044 14) standard/default/emenlow 1041 <listitem><para>Regardless of which choice is made in the previous step,
1045 15) standard/default/fishriver 1042 you are now given the opportunity to select a particular machine branch on
1046 16) standard/default/fri2 1043 which to base your new BSP-specific machine branch on
1047 17) standard/default/fsl-mpc8315e-rdb 1044 (or to re-use if you had elected to not create a new branch).
1048 18) standard/default/mti-malta32-be 1045 Because this example is generating an <filename>arm</filename> BSP, the example
1049 19) standard/default/mti-malta32-le 1046 uses <filename>#3</filename> at the prompt, which selects the arm-versatile branch.
1050 20) standard/default/preempt-rt 1047 </para></listitem>
1051 21) standard/default/qemu-ppc32 1048 <listitem><para>The remainder of the prompts are routine.
1052 22) standard/default/routerstationpro 1049 Defaults are accepted for each.</para></listitem>
1053 23) standard/preempt-rt/base 1050 <listitem><para>By default, the script creates the new BSP Layer in the
1054 24) standard/preempt-rt/qemu-ppc32 1051 <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project
1055 25) standard/preempt-rt/routerstationpro 1052 Build Directory</ulink>.</para></listitem>
1056 26) standard/tiny 1053 </orderedlist>
10573 1054 </para>
1058Do you need SMP support? (Y/n) 1055
1059Does your BSP have a touchscreen? (y/N) 1056 <para>
1060Does your BSP have a keyboard? (Y/n) 1057 Once the BSP Layer is created, you must add it to your
1061New qemu BSP created in meta-myarm 1058 <filename>bblayers.conf</filename> file.
1062 </literallayout> 1059 Here is an example:
1063 </para> 1060 <literallayout class='monospaced'>
1064 <para>
1065 Now that we have our BSP created, we need to add it to
1066 our bblayers.conf. This of course is required in order
1067 to build the BSP, but it's also required in order for
1068 the <filename>yocto-kernel</filename> tool to be able to
1069 find the layer and other metadata it needs to operate
1070 on.
1071 <literallayout class='monospaced'>
1072 BBLAYERS = " \ 1061 BBLAYERS = " \
1073 /usr/local/src/yocto/meta \ 1062 /usr/local/src/yocto/meta \
1074 /usr/local/src/yocto/meta-yocto \ 1063 /usr/local/src/yocto/meta-yocto \
1075 /usr/local/src/yocto/meta-myarm \ 1064 /usr/local/src/yocto/meta-myarm \
1076 " 1065 "
1077 </literallayout> 1066 </literallayout>
1078 </para> 1067 Adding the layer to this file allows the build system to build the BSP and
1068 the <filename>yocto-kernel</filename> tool to be able to find the layer and
1069 other metadata it needs on which to operate.
1070 </para>
1079 </section> 1071 </section>
1080 <section id='using-yocto-kernel'>
1081 <title>Managing Kernel Patches and Config Items
1082 with <filename>yocto-kernel</filename></title>
1083 <para>
1084 Assuming we've created a Yocto BSP layer
1085 using <filename>yocto-bsp</filename> and added it to our
1086 BBLAYERS, we can now use
1087 the <filename>yocto-kernel</filename> command to add
1088 patches and config items to the BSP's
1089 kernel. <filename>yocto-kernel</filename> is a Yocto
1090 script that allows you to add, remove, and list patches
1091 and kernel config settings to a Yocto BSP's kernel
1092 .bbappend file. The easiest way to see exactly what
1093 sub-commands are available
1094 using <filename>yocto-kernel</filename> is again to make
1095 use of the built-in help:
1096 </para>
1097 <para>
1098 <literallayout class='monospaced'>
1099$ yocto-kernel
1100Usage:
1101 1072
1102 Modify and list Yocto BSP kernel config items and patches. 1073 <section id='managing-kernel-patches-and-config-items-with-yocto-kernel'>
1074 <title>Managing Kernel Patches and Config Items with yocto-kernel</title>
1103 1075
1104 usage: yocto-kernel [--version] [--help] COMMAND [ARGS] 1076 <para>
1077 Assuming you have created a Yocto Project
1078 <link linkend='bsp-layers'>BSP Layer</link> using
1079 <link linkend='creating-a-new-bsp-layer-using-the-yocto-bsp-script'>
1080 <filename>yocto-bsp</filename></link> and you added it to your
1081 <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
1082 variable in the <filename>bblayers.conf</filename> file, you can now use
1083 the <filename>yocto-kernel</filename> script to add patches and configuration
1084 items to the BSP's kernel.
1085 </para>
1105 1086
1106 The most commonly used 'yocto-kernel' commands are: 1087 <para>
1107 config list List the modifiable set of bare kernel config options for a BSP 1088 The <filename>yocto-kernel</filename> script allows you to add, remove, and list patches
1108 config add Add or modify bare kernel config options for a BSP 1089 and kernel config settings to a Yocto Project BSP's kernel
1109 config rm Remove bare kernel config options from a BSP 1090 <filename>.bbappend</filename> file.
1110 patch list List the patches associated with a BSP 1091 All you need to do is use the appropriate sub-command.
1111 patch add Patch the Yocto kernel for a BSP 1092 Recall that the easiest way to see exactly what sub-commands are available
1112 patch rm Remove patches from a BSP 1093 is to use the <filename>yocto-kernel</filename> built-in help as follows:
1094 <literallayout class='monospaced'>
1095 $ yocto-kernel
1096 Usage:
1097
1098 Modify and list Yocto BSP kernel config items and patches.
1099
1100 usage: yocto-kernel [--version] [--help] COMMAND [ARGS]
1101
1102 The most commonly used 'yocto-kernel' commands are:
1103 config list List the modifiable set of bare kernel config options for a BSP
1104 config add Add or modify bare kernel config options for a BSP
1105 config rm Remove bare kernel config options from a BSP
1106 patch list List the patches associated with a BSP
1107 patch add Patch the Yocto kernel for a BSP
1108 patch rm Remove patches from a BSP
1109
1110 See 'yocto-kernel help COMMAND' for more information on a specific command.
1111 </literallayout>
1112 </para>
1113 1113
1114 See 'yocto-kernel help COMMAND' for more information on a specific command. 1114 <para>
1115 </literallayout> 1115 The <filename>yocto-kernel patch add</filename> sub-command allows you to add a
1116 </para> 1116 patch to a BSP.
1117 <para> 1117 The following example adds two patches to the <filename>myarm</filename> BSP:
1118 The <filename>yocto-kernel patch add</filename> 1118 <literallayout class='monospaced'>
1119 sub-command allows us to add a patch to a BSP. The 1119 $ yocto-kernel patch add myarm ~/test.patch
1120 following commands add a couple of patches to the 1120 Added patches:
1121 'myarm' BSP: 1121 test.patch
1122 <literallayout class='monospaced'> 1122
1123$ yocto-kernel patch add myarm ~/test.patch 1123 $ yocto-kernel patch add myarm ~/yocto-testmod.patch
1124Added patches: 1124 Added patches:
1125 test.patch 1125 yocto-testmod.patch
1126 </literallayout>
1127 <note>Although the previous example adds patches one at a time, it is possible
1128 to add multiple patches at the same time.</note>
1129 </para>
1126 1130
1127$ yocto-kernel patch add myarm ~/yocto-testmod.patch 1131 <para>
1128Added patches: 1132 You can verify patches have been added by using the
1129 yocto-testmod.patch 1133 <filename>yocto-kernel patch list</filename> sub-command.
1130 </literallayout> 1134 Here is an example:
1131 Note that though we added patches one by one above, we 1135 <literallayout class='monospaced'>
1132 could also add multiple patches at the same time if we 1136 $ yocto-kernel patch list myarm
1133 wanted to. 1137 The current set of machine-specific patches for myarm is:
1134 </para> 1138 1) test.patch
1135 <para> 1139 2) yocto-testmod.patch
1136 We can verify that the patches were added by using 1140 </literallayout>
1137 the <filename>yocto-kernel patch list</filename> 1141 </para>
1138 sub-command:
1139 <literallayout class='monospaced'>
1140$ yocto-kernel patch list myarm
1141The current set of machine-specific patches for myarm is:
1142 1) test.patch
1143 2) yocto-testmod.patch
1144 </literallayout>
1145 </para>
1146 <para>
1147 We can also use <filename>yocto-kernel</filename> to
1148 remove a patch using the <filename>yocto-kernel patch
1149 rm</filename> sub-command:
1150 <literallayout class='monospaced'>
1151$ yocto-kernel patch rm myarm
1152Specify the patches to remove:
1153 1) test.patch
1154 2) yocto-testmod.patch
11551
1156Removed patches:
1157 test.patch
1158 </literallayout>
1159 </para>
1160 <para>
1161 Again using <filename>yocto-kernel patch list</filename>
1162 we can verify that it was in fact removed:
1163 <literallayout class='monospaced'>
1164$ yocto-kernel patch list myarm
1165The current set of machine-specific patches for myarm is:
1166 1) yocto-testmod.patch
1167 </literallayout>
1168 </para>
1169 <para>
1170 In a completely similar way, we can use
1171 the <filename>yocto-kernel config add</filename>
1172 sub-command to add one or more kernel config item
1173 settings to a BSP. The following commands add a couple
1174 of config items to the 'myarm' BSP:
1175 <literallayout class='monospaced'>
1176$ yocto-kernel config add myarm CONFIG_MISC_DEVICES=y
1177Added items:
1178 CONFIG_MISC_DEVICES=y
1179 1142
1180$ yocto-kernel config add myarm KCONFIG_YOCTO_TESTMOD=y 1143 <para>
1181Added items: 1144 You can also use the <filename>yocto-kernel</filename> script to
1182 CONFIG_YOCTO_TESTMOD=y 1145 remove a patch using the <filename>yocto-kernel patch rm</filename> sub-command.
1183 </literallayout> 1146 Here is an example:
1184 Note that though we added config items one by one 1147 <literallayout class='monospaced'>
1185 above, we could also add multiple configuration 1148 $ yocto-kernel patch rm myarm
1186 settings at the same time if we wanted to. 1149 Specify the patches to remove:
1187 </para> 1150 1) test.patch
1188 <para> 1151 2) yocto-testmod.patch
1189 Finally, we can list the config items now associated 1152 1
1190 with the BSP and see the config items we added along 1153 Removed patches:
1191 with some others. 1154 test.patch
1192 <literallayout class='monospaced'> 1155 </literallayout>
1193$ yocto-kernel config list myarm 1156 </para>
1194The current set of machine-specific kernel config items for myarm is: 1157
1195 1) CONFIG_MISC_DEVICES=y 1158 <para>
1196 2) CONFIG_YOCTO_TESTMOD=y 1159 Again, using the <filename>yocto-kernel patch list</filename> sub-command,
1197 </literallayout> 1160 you can verify that the patch was in fact removed:
1198 </para> 1161 <literallayout class='monospaced'>
1199 <para> 1162 $ yocto-kernel patch list myarm
1200 Similarly, we can remove one or more config items using 1163 The current set of machine-specific patches for myarm is:
1201 <filename>yocto-kernel config rm</filename> in a manner 1164 1) yocto-testmod.patch
1202 completely analogous to <filename>yocto-kernel patch 1165 </literallayout>
1203 rm</filename>. 1166 </para>
1204 </para> 1167
1168 <para>
1169 In a completely similar way, you can use the <filename>yocto-kernel config add</filename>
1170 sub-command to add one or more kernel config item settings to a BSP.
1171 The following commands add a couple of config items to the
1172 <filename>myarm</filename> BSP:
1173 <literallayout class='monospaced'>
1174 $ yocto-kernel config add myarm CONFIG_MISC_DEVICES=y
1175 Added items:
1176 CONFIG_MISC_DEVICES=y
1177
1178 $ yocto-kernel config add myarm KCONFIG_YOCTO_TESTMOD=y
1179 Added items:
1180 CONFIG_YOCTO_TESTMOD=y
1181 </literallayout>
1182 <note>Although the previous example adds config items one at a time, it is possible
1183 to add multiple config items at the same time.</note>
1184 </para>
1185
1186 <para>
1187 You can list the config items now associated with the BSP.
1188 Doing so shows you the config items you added as well as others associated
1189 with the BSP:
1190 <literallayout class='monospaced'>
1191 $ yocto-kernel config list myarm
1192 The current set of machine-specific kernel config items for myarm is:
1193 1) CONFIG_MISC_DEVICES=y
1194 2) CONFIG_YOCTO_TESTMOD=y
1195 </literallayout>
1196 </para>
1197
1198 <para>
1199 Finally, you can remove one or more config items using the
1200 <filename>yocto-kernel config rm</filename> sub-command in a manner
1201 completely analogous to <filename>yocto-kernel patch rm</filename>.
1202 </para>
1205 </section> 1203 </section>
1206 </section> 1204 </section>
1207</chapter> 1205</chapter>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-16 20:43:18 +0000