| /openbmc/openbmc/poky/documentation/dev-manual/ |
| H A D | custom-distribution.rst | 3 Creating Your Own Distribution
16 your own distribution.
18 To create your own distribution, the basic steps consist of creating
19 your own distribution layer, creating your own distribution
23 - *Create a layer for your new distro:* Create your distribution layer
24 so that you can keep your Metadata and code for the distribution
25 separate. It is strongly recommended that you create and use your own
26 layer for configuration and code. Using your own layer as compared to
35 directory of your layer. You need to name it using your distribution
40 The :term:`DISTRO` variable in your ``local.conf`` file determines the
[all …]
|
| H A D | securing-images.rst | 22 When securing your image is of concern, there are steps, tools, and
24 need for your particular device. Not all situations are identical when
27 your image more secure.
33 securing your custom OS. It is strongly recommended that you also
41 You should consider the following suggestions to make your device
64 especially applies when your device is network-enabled.
69 - Regularly update your version of Poky and OE-Core from their upstream
82 - Enable hardware support for secure boot functionality when your
89 your build output more secure. The security flags are in the
90 ``meta/conf/distro/include/security_flags.inc`` file in your
[all …]
|
| H A D | layers.rst | 14 Creating Your Own Layer
19 It is very easy to create your own layers to use with the OpenEmbedded
29 Follow these general steps to create your layer without using tools:
38 #. *Create a Directory:* Create the directory for your layer. When you
55 you trouble later when tools, components, or variables "assume" your
61 #. *Create a Layer Configuration File:* Inside your new layer folder,
63 an existing layer configuration file and copy that to your layer's
68 demonstrates the required syntax. For your layer, you need to replace
69 "yoctobsp" with a unique identifier for your layer (e.g. "machinexyz"
95 configuration filenames in your custom layer.
[all …]
|
| H A D | building.rst | 27 ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`"
40 places it in your :term:`Build Directory` under ``tmp/deploy/images``. For
50 #. *Set up Your Host Development System to Support Development Using the
61 uses ``build`` as the default :term:`Build Directory` in your current work
71 somewhere outside of your source directory.
73 #. *Make Sure Your* ``local.conf`` *File is Correct*: Ensure the
111 for your particular board or machine.
133 multiple configuration builds in your ``local.conf`` file.
176 variable in your ``conf/local.conf`` configuration file to specify
187 the variables coming from your ``local.conf``
[all …]
|
| /openbmc/openbmc/poky/documentation/ |
| H A D | transitioning-to-a-custom-environment.rst | 14 now, as you are starting your own project, it isn't exactly straightforward what
19 that will be part of your project**.
21 things, and adding them to your configuration. (See #3)
23 #. **Set up your board support**.
26 architecture as your custom hardware. Knowing the board already has a
30 #. **Find and acquire the best BSP for your target**.
33 Layer Index <>` to find and acquire the best BSP for your
35 best place to get your first BSP is from your silicon manufacturer or board
43 (which is reference embedded distribution) and then add your newly chosen
47 #. **Based on the layers you've chosen, make needed changes in your
[all …]
|
| /openbmc/linux/Documentation/process/ |
| H A D | maintainer-pgp-guide.rst | 66 Your distro should already have GnuPG installed by default, you just
93 edit your ``~/.gnupg/gpg-agent.conf`` file to set your own values::
102 beginning of your shell session. You may want to check your rc files
108 Protect your PGP key
116 You should also make a new key if your current one is weaker than 2048
143 private key on your chain.
150 3. A single subkey may have multiple capabilities (e.g. your **[C]** key
151 can also be your **[S]** key).
167 If you used the default parameters when generating your key, then that
176 The long line under the ``sec`` entry is your key fingerprint --
[all …]
|
| H A D | 6.Followthrough.rst | 7 addition of your own engineering skills, have posted a perfect series of
17 kernel community to ensure that your code is up to the kernel's quality
19 prevent the inclusion of your patches into the mainline.
31 - If you have explained your patch well, reviewers will understand its
48 agendas at the expense of your own. Kernel developers often expect to
55 and requests to factor out some of your code to shared parts of
57 the same. Sometimes this means that the clever hack in your driver
63 making. Do not let their form of expression or your own pride keep that
70 reviewers. If you believe that the reviewer has misunderstood your code,
72 suggested change, describe it and justify your solution to the problem. If
[all …]
|
| H A D | botching-up-ioctls.rst | 46 conversion or worse, fiddle the raw __u64 through your code since that
60 * Have a clear way for userspace to figure out whether your new ioctl or ioctl
73 and reject the ioctl if that's not the case. Otherwise your nice plan for
99 * Have simple testcases for every input validation failure case in your ioctl.
100 Check that the error code matches your expectations. And finally make sure
106 * Make all your ioctls restartable. First X really loves signals and second
108 interrupting your main test suite constantly with signals. Thanks to X's
109 love for signal you'll get an excellent base coverage of all your error
117 killable. GPUs just die and your users won't like you more if you hang their
122 * Have testcases for the really tricky corner cases in your error recovery code
[all …]
|
| /openbmc/docs/development/ |
| H A D | gerrit-setup.md | 3 **Document Purpose:** Walkthrough configuring your workstation and a Gerrit
14 - `git config --global --add user.name "Your name" (eg. John Smith)`
15 - `git config --global --add user.email "youremail@your-domain" (eg. jsmith@somedomain.com)`
21 Create keys: `ssh-keygen -t ed25519 -C "your_email@your-domain"`
23 - Recommended to use the defaults instead of picking your own directory/file
28 - <https://help.github.com/articles/adding-a-new-ssh-key-to-your-github-account/>
32 - Login to [Gerrit](https://gerrit.openbmc.org/) with your GitHub account.
34 - Your information should be auto-filled, so click "Next".
41 - Enter your public SSH key created before in Settings -> SSH Keys -> New SSH
44 - If succesfull you should see your public key added and with the status "Valid"
[all …]
|
| H A D | devtool-hello-world.md | 12 you to extract a targeted repositories source code into your local bitbake
36 Your diff should look something like this:
53 3. Rebuild the flash image which will now include your change
56 from your previous build, only building what is new.
62 Follow the steps in the first tutorial to load your new image into a QEMU
65 4. Confirm your "Hello World" made it into the new image
67 After you login to your QEMU session, verify the message is in the journal
88 1. Modify your hello world
94 Change your cout to "Hello World Again"
100 phosphor-state-manager repo to pick up your new hello world change.
[all …]
|
| H A D | web-ui.md | 36 to learn how to create custom builds to meet your branding and customization
52 2. Assuming you used the default of 2443 for the HTTPS port in your QEMU
53 session, you will point your web browser to https://localhost:2443.
58 **Note** You will need to approve the security exception in your browser to
90 or your own system assuming you install the required packages noted in the
95 Kill your npm run from the previous step using Ctrl^C. Grab a png that you
96 will use to represent your customized version of OpenBMC. Feel free to use
103 Copy your new .png into the appropriate directory
117 Start up the server with your change
123 Load web browser at https://localhost:8080 and verify your new image is on
[all …]
|
| /openbmc/linux/arch/arm/mach-orion5x/ |
| H A D | Kconfig | 28 Say 'Y' here if you want your kernel to support the
36 Say 'Y' here if you want your kernel to support the Marvell
44 Say 'Y' here if you want your kernel to support the
52 Say 'Y' here if you want your kernel to support the
59 Say 'Y' here if you want your kernel to support the
66 Say 'Y' here if you want your kernel to support the
74 Say 'Y' here if you want your kernel to support the
82 Say 'Y' here if you want your kernel to support the
89 Say 'Y' here if you want your kernel to support the
96 Say 'Y' here if you want your kernel to support the
[all …]
|
| /openbmc/linux/Documentation/hwmon/ |
| H A D | submitting-patches.rst | 1 How to Get Your Patch Accepted Into the Hwmon Subsystem
6 increase the chances of your change being accepted.
18 * Please run your patch through 'checkpatch --strict'. There should be no
26 * If your patch generates checkpatch errors, warnings, or check messages,
32 * Please test your patch thoroughly. We are not your test group.
38 * If your patch (or the driver) is affected by configuration options such as
51 your patch into a cleanup part and the actual addition. This makes it easier
52 to review your changes, and to bisect any resulting problems.
60 * Running your patch or driver file(s) through checkpatch does not mean its
61 formatting is clean. If unsure about formatting in your new driver, run it
[all …]
|
| /openbmc/linux/Documentation/admin-guide/ |
| H A D | quickly-build-trimmed-linux.rst | 20 If your system uses techniques like Secure Boot, prepare it to permit starting
22 building Linux; make sure to have 12 Gigabyte free space in your home directory.
24 you then use to configure, build and install your own kernel::
30 # Hint: it's recommended to tag your build at this point. See below for details.
57 Compiling your own Linux kernel is easy in principle. There are various ways to
93 ensure the system will permit your self-compiled kernel to boot later. The
115 sources and build artifacts 12 Gigabyte in your home directory should
117 section for the step that explains adjusting your kernels build
161 If you deepened your clone, you instead of ``origin/master`` can specify the
186 * If you patched your kernel or have one of the same version installed already,
[all …]
|
| /openbmc/openbmc/poky/documentation/contributor-guide/ |
| H A D | submit-changes.rst | 63 use to identify your commits::
88 Then, create a new branch in your local Git repository
89 for your changes, starting from the reference branch in the upstream
101 In each branch, you should group your changes into small, controlled and
108 …e <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes>`__
116 #. *Stage Your Changes:* Stage your changes by using the ``git add``
120 #. *Commit Your Changes:* This is when you can create separate commits. For
131 to your commit message. There is the same requirement for contributing
134 …<https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-develop…
194 with a bug-tracking ID, include a reference to that ID in your
[all …]
|
| /openbmc/qemu/docs/devel/ |
| H A D | submitting-a-patch.rst | 9 help make our task of contribution review easier and your change is
21 * - Patches contain Signed-off-by: Your Name <author@email>
35 to allow your address.
37 The larger your contribution is, or if you plan on becoming a long-term
47 Writing your Patches
78 line ``Based-on: $MESSAGE_ID`` to your cover letter to make the series
139 same patch as your bug fix.
159 description of the patch, another blank and your Signed-off-by: line.
160 Please do not use lines that are longer than 76 characters in your
164 The body of the commit message is a good place to document why your
[all …]
|
| /openbmc/openbmc/poky/documentation/kernel-dev/ |
| H A D | common.rst | 8 with the Yocto Project Linux kernel. These tasks include preparing your
11 kernel, iterative development, working with your own sources, and
22 Before you can do any kernel development, you need to be sure your build
27 :term:`Source Directory` (``poky``) on your system. Follow the steps in the
29 section in the Yocto Project Development Tasks Manual to set up your
35 create your local branch by checking out a specific tag to get the
42 :ref:`devtool <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
69 #. *Prepare Your local.conf File:* By default, the :term:`MACHINE` variable
72 :term:`MACHINE` variable appropriately in your ``conf/local.conf`` file
93 Add your new layer with 'bitbake-layers add-layer ../../meta-mylayer'
[all …]
|
| /openbmc/linux/arch/arm/mach-ep93xx/ |
| H A D | Kconfig | 32 Say 'Y' here if you want your kernel to support the
42 Say 'Y' here if you want your kernel to support the Cirrus
49 Say 'Y' here if you want your kernel to support the Cirrus
56 Say 'Y' here if you want your kernel to support the Cirrus
63 Say 'Y' here if you want your kernel to support the Cirrus
70 Say 'Y' here if you want your kernel to support the Cirrus
77 Say 'Y' here if you want your kernel to support the Cirrus
84 Say 'Y' here if you want your kernel to support the Cirrus
91 Say 'Y' here if you want your kernel to support the Cirrus
97 Say 'Y' here if you want your kernel to support the
[all …]
|
| /openbmc/openbmc/poky/meta/files/common-licenses/ |
| H A D | PolyForm-Small-Business-1.0.0 | 9 your licenses.
25 to distribute copies of the software. Your license
59 Use of the software for the benefit of your company is use for
60 a permitted purpose if your company has fewer than 100 total
71 your licenses to anyone else, or prevent the licensor from
78 contributes to infringement of any patent, your patent license
80 your company makes such a claim, your patent license ends
81 immediately for work on behalf of your company.
87 not covered by your licenses, your licenses can nonetheless
90 32 days of receiving notice. Otherwise, all your licenses
[all …]
|
| /openbmc/linux/Documentation/driver-api/ |
| H A D | uio-howto.rst | 62 If you use UIO for your card's driver, here's what you get:
66 - develop the main part of your driver in user space, with all the
69 - bugs in your driver won't crash the kernel.
71 - updates of your driver can take place without recompiling the kernel.
82 :c:func:`mmap()` to access registers or RAM locations of your card.
112 To handle interrupts properly, your custom kernel module can provide its
130 - ``name``: The name of your device. It is recommended to use the name
131 of your kernel module for this.
133 - ``version``: A version string defined by your driver. This allows the
134 user space part of your driver to deal with different versions of the
[all …]
|
| /openbmc/openbmc-tools/ |
| H A D | README.md | 6 It's highly likely the scripts don't meet your needs - they could be
12 - Some hacking on your part is to be expected
16 Then this repository aims to be the default destination for your otherwise
26 Do note that you will need to be party to the OpenBMC CLA before your
30 ## What we will do once we have your patches
32 So long as your patches look sane with a cursory glance you can expect them to
36 ## What you must have in your patches
39 [Signed-off-by](https://developercertificate.org/), use SPDX markers in your
40 source files and put your work under an Apache 2.0 compatible license.
45 the repository to your PATH might be a bit of a dice-roll. We may also move or
|
| /openbmc/openbmc/poky/documentation/toaster-manual/ |
| H A D | intro.rst | 9 enables you to configure and run your builds. Information about builds
20 configure and start your builds. Builds started using the Toaster web
29 that are available in your project (e.g. the OpenEmbedded Layer Index at
34 - Import your own layers for building.
36 - Add and remove layers from your configuration.
42 - Start your builds.
44 Toaster also allows you to configure and run your builds from the
50 information about your builds. Toaster collects data for builds you
62 installed into your final image.
64 - Browse the directory structure of your image.
[all …]
|
| /openbmc/u-boot/doc/driver-model/ |
| H A D | serial-howto.txt | 13 Here is a suggested approach for converting your serial driver over to driver
14 model. Please feel free to update this file with your ideas and suggestions.
16 - #ifdef out all your own serial driver code (#ifndef CONFIG_DM_SERIAL)
17 - Define CONFIG_DM_SERIAL for your board, vendor or architecture
19 - Your board should then build, but will not boot since there will be no serial
23 - Implement each of the driver methods, perhaps by calling your old methods
35 This may be a good time to move your board to use device tree also. Mostly
39 - add your device tree files to arch/<arch>/dts
41 - Add stdout-path to your /chosen device tree node if it is not already there
43 - Your drivers can now use device tree
|
| H A D | i2c-howto.txt | 23 Here is a suggested approach for converting your I2C driver over to driver
24 model. Please feel free to update this file with your ideas and suggestions.
26 - #ifdef out all your own I2C driver code (#ifndef CONFIG_DM_I2C)
27 - Define CONFIG_DM_I2C for your board, vendor or architecture
29 - Your board should then build, but will not work fully since there will be
33 - Implement each of the driver methods, perhaps by calling your old methods
45 This may be a good time to move your board to use device tree also. Mostly
49 - add your device tree files to arch/<arch>/dts
51 - Add stdout-path to your /chosen device tree node if it is not already there
53 - Your drivers can now use device tree
|
| /openbmc/phosphor-host-ipmid/docs/ |
| H A D | testing.md | 3 ## Setting Up Your Environment
7 of your machine setup. It also offers a strong guarantee that you're testing the
16 in your organization. But the
39 basic idea is that it's like having a second copy of your repo - but the second
40 copy is in sync with your main copy, knows about your local branches, and
43 Your new worktree doesn't know about any untracked files you have in your main
48 your testing worktree, it's easy to update a commit with those.)
50 Note the placeholders in the following steps; modify the commands to match your
61 convenience, since you can't check out a branch in your worktree that's already
64 However, Git won't be able to figure out how to get to your main worktree
[all …]
|