| /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 | 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.
138 variable to ``"1"`` in your ``local.conf`` configuration file and set the
155 #. *Build the Kernel Image and the Initramfs Image:* Build your kernel
213 <dev-manual/layers:Appending Other Layers Metadata With Your Layer>` on the
[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 …]
|
| /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/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/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/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 …]
|
| H A D | Elastic-2.0 | 37 the software. If you or your company make any written claim that the software
38 infringes or contributes to infringement of any patent, your patent license for
39 the software granted under these terms ends immediately. If your company makes
40 such a claim, your patent license ends immediately for work on behalf of your
59 and your licenses will automatically terminate. If the licensor provides you
60 with a notice of your violation, and you cease all violation of this license no
61 later than 30 days after you receive that notice, your licenses will be
63 reinstatement, any additional violation of these terms will cause your licenses
81 **your company** is any legal entity, sole proprietorship, or other kind of
88 **your licenses** are all the licenses granted to you for the software under
[all …]
|
| H A D | PolyForm-Noncommercial-1.0.0 | 9 your licenses.
25 to distribute copies of the software. Your license
81 your licenses to anyone else, or prevent the licensor from
88 contributes to infringement of any patent, your patent license
90 your company makes such a claim, your patent license ends
91 immediately for work on behalf of your company.
97 not covered by your licenses, your licenses can nonetheless
100 32 days of receiving notice. Otherwise, all your licenses
119 **Your company** is any legal entity, sole proprietorship,
127 **Your licenses** are all the licenses granted to you for the
[all …]
|
| H A D | 3D-Slicer-1.0 | 15 Your contribution of software and/or data to Slicer (including prior
21 terms and conditions, you have no right to contribute your
39 respect to such Contribution; (ii) if your Contribution includes
43 Accountability Act (HIPAA) and its regulations, and your disclosure
51 right, title and interest in your Contribution.
56 display and distribute the Contribution. If your Contribution is
59 royalty-free, irrevocable license under your interest in patent
61 otherwise transfer your Contribution, alone or in combination with
64 5. You acknowledge and agree that Brigham may incorporate your
70 your breach of any of the terms of this Agreement.
[all …]
|
| H A D | CDLA-Permissive-1.0 | 3 …ent by each of the Data Providers. Your exercise of any of the rights and permissions granted bel…
9 1.1 “Add” means to supplement Data with Your own or someone else’s Data, resulting in Your “Additio…
11 1.2 “Computational Use” means Your analysis (through the use of computational devices or otherwise)…
15 …Data on behalf of such Entity) that Publishes Data under this Agreement prior to Your Receiving it.
17 1.5 “Enhanced Data” means the subset of Data that You Publish and that is composed of (a) Your Addi…
23 1.8 “Publish” means to make all or a subset of Data (including Your Enhanced Data) available in any…
27 1.10 “Results” means the outcomes or outputs that You obtain from Your Computational Use of Data. …
33 1.13 “You” or “Your” means any Entity that Receives Data under this Agreement.
47 (a) You may do so under a license of Your choice provided that You give anyone who Receives the Dat…
53 …r for any combination of Data and Enhanced Data as a whole, provided that Your Use and Publication…
[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/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/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/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 …]
|
| H A D | intro.rst | 12 set up your build host to support kernel development, introduces the
45 patches, or work with your own kernel sources.
53 This efficiency reduces your maintenance effort and allows you to
54 further separate your configuration in ways that make sense for your
56 your kernels might support the ``proc`` and ``sys`` filesystems, but
62 If you do not maintain your own kernel sources and need to make only
64 base upon which to layer your changes. Doing so allows you to benefit
70 you have a way to use the Yocto Project Linux kernel tools with your
86 workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
111 #. *Set up Your Host Development System to Support Development Using the
[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/docs/designs/ |
| H A D | design-template.md | 23 - You should get your design reviewed and merged before writing your code.
30 - Your spec should be in Markdown format, like this template.
37 - To view your .md file, see: https://stackedit.io/
39 - If you would like to provide a diagram with your spec, ASCII diagrams are
72 sources (other docs or Wikipedia), rather than writing your own explanations.
74 glossary if necessary. Note: this is background; do not write about your design,
81 is the scope of this effort? Your job here is to quickly educate others about
82 the details you know about the problem space, so they can help review your
89 (2-5 paragraphs) A short and sweet overview of your implementation ideas. If you
91 This should not contain every detail of your implementation, and do not include
[all …]
|
| /openbmc/bmcweb/docs/ |
| H A D | TESTING.md | 36 useful depending on your testing. Leaving them will drastically increase your
39 - Copy your bmcweb daemon you want to test to /tmp/ in QEMU
46 reaches the QEMU session you set up in your development environment as
49 - Stop bmcweb service within your QEMU session
58 testing. In QEMU you would need to open up port 18080 when starting QEMU. Your
76 - Link to your new bmcweb daemon in /tmp/
82 - Test your changes. bmcweb will be started automatically upon your first REST
112 passing makes your CL less likely to be rolled back while bumping SRCREV of
140 Your change should not introduce any new validator errors. Please include
141 something to the effect of "Redfish service validator passing" in your commit
[all …]
|
| /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 …]
|
| /openbmc/openbmc-test-automation/lib/ |
| H A D | gen_robot_utils.py | 18 path The path to your resource file.
32 "utils_x.robot" BEFORE your command line parms are processed, as one
33 might expect. On the other hand, if one of your python library files
35 "utils_x.robot" AFTER your program parms are processed. Let's suppose
41 If your program is invoked like this:
45 And if your program has a python library file that invokes
51 This function will remedy that problem by keeping your -v parms intact.
54 from your file_x.robot "** Variables **" section. Namely, they may get
|