SDK Generator: Difference between revisions
(Created page with 'SDK Userspace NFS Use Scenarios and Workflow == Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image == Sally is an embedded application developer who wor…') |
No edit summary |
||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
==SDK documentation== | |||
== | Official documentation for the SDK Generator will be posted and an announcement made on the yocto-announce mailing list when it is released. | ||
Sally is an embedded application developer who works for a large corporation which locks-down its developer workstations and does not allow developers root access. | You can also see the http://yoctoproject.org/projects/sdk-generator page on the website for more information on this project. | ||
==SDK Userspace NFS Use Scenarios and Workflow== | |||
=== Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image === | |||
Sally is an embedded application developer who works for a large corporation which locks-down its developer workstations and does not allow developers root access. | |||
Sally's System Administrator set up her workstation for Poky development by doing the following: | Sally's System Administrator set up her workstation for Poky development by doing the following: | ||
| Line 8: | Line 14: | ||
# Extracting the output from a meta-toolchain build (poky-glibc-x86_64-i586-toolchain-XYZ.tar.bz2) into /opt/poky | # Extracting the output from a meta-toolchain build (poky-glibc-x86_64-i586-toolchain-XYZ.tar.bz2) into /opt/poky | ||
# Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work) | # Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work) | ||
# Run the poky- | # Run the poky-gen-tapdevs to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Sally is a member of. | ||
Sally then sources the meta-toolchain environment file (source /opt/poky/environment-setup-i586-poky-linux), which adds the toolchain's usr/bin directory into her $PATH and sets some other build-related environment variables. | Sally then sources the meta-toolchain environment file (source /opt/poky/environment-setup-i586-poky-linux), which adds the toolchain's usr/bin directory into her $PATH and sets some other build-related environment variables. | ||
| Line 20: | Line 26: | ||
She then can run QEMU to automatically boot to this nfsroot with the following command: | She then can run QEMU to automatically boot to this nfsroot with the following command: | ||
poky-qemu {machine-type} <kernel> <rootfs-dir> | |||
Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from /opt/poky and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/ | Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from /opt/poky and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/ | ||
| Line 29: | Line 35: | ||
poky-export-rootfs stop <path to rootfs> | poky-export-rootfs stop <path to rootfs> | ||
Roger is an embedded developer who, like Sally, works for a large corporation which locks-down its developer workstations and does not allow developers root access. | === Scenario 2: In-tree Poky setup with a QEMU SDK image === | ||
Roger is an embedded developer who, like Sally, works for a large corporation which locks-down its developer workstations and does not allow developers root access. | |||
Roger's System Administrator sets up his workstation for Poky development by doing the following: | Roger's System Administrator sets up his workstation for Poky development by doing the following: | ||
# Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work) | # Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work) | ||
# Run the poky- | # Run the poky-gen-tapdevs to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Roger is a member of. | ||
Thus, the only difference is that Roger doesn't need the cross-toolchain installed in /opt/poky. That is because Roger is willing to do full Poky builds, and has the Poky tarball extracted in some area he prefers to work (e.g, ~/poky). | Thus, the only difference is that Roger doesn't need the cross-toolchain installed in /opt/poky. That is because Roger is willing to do full Poky builds, and has the Poky tarball extracted in some area he prefers to work (e.g, ~/poky). | ||
| Line 49: | Line 55: | ||
and then starts QEMU to boot to this using: | and then starts QEMU to boot to this using: | ||
poky-qemu {machine-type} <kernel> <rootfs-dir> | |||
Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from the automatically detected Poky native sysroot and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/ | Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from the automatically detected Poky native sysroot and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/ | ||
| Line 59: | Line 65: | ||
poky-export-rootfs stop <path to rootfs> | poky-export-rootfs stop <path to rootfs> | ||
== Scenario 3: Exporting a rootfs to a non-QEMU target == | === Scenario 3: Exporting a rootfs to a non-QEMU target === | ||
This allows developers to export a rootfs to non-qemu targets (i.e, real hardware). | This allows developers to export a rootfs to non-qemu targets (i.e, real hardware). | ||
Latest revision as of 17:02, 26 October 2010
SDK documentation
Official documentation for the SDK Generator will be posted and an announcement made on the yocto-announce mailing list when it is released.
You can also see the http://yoctoproject.org/projects/sdk-generator page on the website for more information on this project.
SDK Userspace NFS Use Scenarios and Workflow
Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image
Sally is an embedded application developer who works for a large corporation which locks-down its developer workstations and does not allow developers root access.
Sally's System Administrator set up her workstation for Poky development by doing the following:
- Extracting the output from a meta-toolchain build (poky-glibc-x86_64-i586-toolchain-XYZ.tar.bz2) into /opt/poky
- Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
- Run the poky-gen-tapdevs to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Sally is a member of.
Sally then sources the meta-toolchain environment file (source /opt/poky/environment-setup-i586-poky-linux), which adds the toolchain's usr/bin directory into her $PATH and sets some other build-related environment variables.
She then downloads a poky-image-sdk tarball and a QEMU kernel. Sally can copy the kernel and extract the SDK image tarball to an arbitrary work area, but she must extract the SDK image tarball using the following script:
poky-extract-sdk <poky-sdk-tarball> <extract-dir>
The documentation may recommend standard directories (e.g, ~/qemukernels/<kernel> ~/rootfs/<machinetype>), but Sally is free to choose another directory if that suits her needs better.
She then can run QEMU to automatically boot to this nfsroot with the following command:
poky-qemu {machine-type} <kernel> <rootfs-dir>
Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from /opt/poky and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/
It would then start up QEMU with the next available tap network device and mount its rootfs.
When Sally shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Sally could also forcefully shut down the NFS server and networking with the following command:
poky-export-rootfs stop <path to rootfs>
Scenario 2: In-tree Poky setup with a QEMU SDK image
Roger is an embedded developer who, like Sally, works for a large corporation which locks-down its developer workstations and does not allow developers root access.
Roger's System Administrator sets up his workstation for Poky development by doing the following:
- Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
- Run the poky-gen-tapdevs to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Roger is a member of.
Thus, the only difference is that Roger doesn't need the cross-toolchain installed in /opt/poky. That is because Roger is willing to do full Poky builds, and has the Poky tarball extracted in some area he prefers to work (e.g, ~/poky).
Roger sources the poky-init-build-env script, which sets up his environment for Poky builds. He then bitbakes a poky-image-sdk image, which creates a qemu kernel and SDK image tarball in his ~/poky/build/tmp/deploy/images/ directory.
Roger then extracts the SDK image tarball with:
poky-extract-sdk <poky-sdk-tarball> <extract-dir>
and then starts QEMU to boot to this using:
poky-qemu {machine-type} <kernel> <rootfs-dir>
Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from the automatically detected Poky native sysroot and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/
It would then start up QEMU with the next available tap network device and mount its rootfs.
When Roger shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Roger could also forcefully shut down the NFS server and networking with the following command:
poky-export-rootfs stop <path to rootfs>
Scenario 3: Exporting a rootfs to a non-QEMU target
This allows developers to export a rootfs to non-qemu targets (i.e, real hardware).
First, the rootfs must be created using the poky-extract-sdk script, which creates the filesystem tree using pseudo:
poky-extract-sdk <poky-sdk-tarball> <extract-dir>
Then they can start/stop/restart the unfs server with:
poky-export-rootfs {start|stop|restart} <path to rootfs>
The developer would then configure their hardware to boot using a kernel accessed over tftp and with a rootfs pointed at the hosts's IP and exported directory.
