SDK Generator - Revision history

134.134.139.72 at 17:02, 26 October 2010

2010-10-26T17:02:47Z

← Older revision		Revision as of 17:02, 26 October 2010
Line 1:		Line 1:
	==SDK documentation==		==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.		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==		==SDK Userspace NFS Use Scenarios and Workflow==

134.134.139.72: /* Scenario 2: In-tree Poky setup with a QEMU SDK image */

2010-10-23T03:29:49Z

Scenario 2: In-tree Poky setup with a QEMU SDK image

← Older revision		Revision as of 03:29, 23 October 2010
Line 41:		Line 41:

	# 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-~~qemu~~-~~ifup command N times~~ 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.		# 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 53:		Line 53:
	and then starts QEMU to boot to this using:		and then starts QEMU to boot to this using:

	~~runqemu~~-~~nfs~~ {machine-type} <kernel> <rootfs-dir>		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/

134.134.139.72: /* Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image */

2010-10-23T03:27:34Z

Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image

← Older revision		Revision as of 03:27, 23 October 2010
Line 24:		Line 24:
	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:

	~~runqemu~~-~~nfs~~ {machine-type} <kernel> <rootfs-dir>		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/

134.134.139.72: /* Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image */

2010-10-23T03:27:03Z

Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image

← Older revision		Revision as of 03:27, 23 October 2010
Line 12:		Line 12:
	# 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-~~qemu~~-~~ifup command N times~~ 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.		# 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.

Davest at 01:34, 23 October 2010

2010-10-23T01:34:16Z

← Older revision		Revision as of 01:34, 23 October 2010
Line 1:		Line 1:
	==SDK documentation==		==SDK documentation==
	~~Please goto[https://oldwiki~~.~~pokylinux.org/share/SDK_docs]~~		Official documentation for the SDK Generator will be posted and an announcement made on the yocto-announce mailing list when it is released.

	==SDK Userspace NFS Use Scenarios and Workflow==		==SDK Userspace NFS Use Scenarios and Workflow==
Line 6:		Line 6:
	=== Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image ===		=== 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 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 36:		Line 36:
	=== Scenario 2: In-tree Poky setup with a QEMU SDK image ===		=== 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 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:

Scottrif at 21:42, 22 October 2010

2010-10-22T21:42:53Z

← Older revision		Revision as of 21:42, 22 October 2010
Line 1:		Line 1:
	SDK ~~Userspace NFS Use Scenarios and Workflow~~		==SDK documentation==
			Please goto[https://oldwiki.pokylinux.org/share/SDK_docs]

	== Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image ==		==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 is an embedded application developer who works for a large corporation which locks-down its developer workstations and does not allow developers root access. :(
Line 31:		Line 34:
	poky-export-rootfs stop <path to rootfs>		poky-export-rootfs stop <path to rootfs>

	== Scenario 2: In-tree Poky setup with a QEMU SDK image ==		=== 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 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. :(
Line 60:		Line 63:
	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).

Scottrif at 20:36, 22 October 2010

2010-10-22T20:36:09Z

← Older revision		Revision as of 20:36, 22 October 2010
Line 1:		Line 1:
	SDK Userspace NFS Use Scenarios and Workflow		SDK Userspace NFS Use Scenarios and Workflow
	==Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image==
			== 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 is an embedded application developer who works for a large corporation which locks-down its developer workstations and does not allow developers root access. :(
Line 29:		Line 30:

	poky-export-rootfs stop <path to rootfs>		poky-export-rootfs stop <path to rootfs>

	==Scenario 2: In-tree Poky setup with a QEMU SDK image==		== 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 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. :(
Line 59:		Line 60:
	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).

Scottrif at 20:24, 22 October 2010

2010-10-22T20:24:10Z

← Older revision		Revision as of 20:24, 22 October 2010
Line 1:		Line 1:
	SDK Userspace NFS Use Scenarios and Workflow		SDK Userspace NFS Use Scenarios and Workflow
	== Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image ==		==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 is an embedded application developer who works for a large corporation which locks-down its developer workstations and does not allow developers root access. :(
Line 30:		Line 30:
	poky-export-rootfs stop <path to rootfs>		poky-export-rootfs stop <path to rootfs>

	== Scenario 2: In-tree Poky setup with a QEMU SDK image ==		==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 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. :(
Line 59:		Line 59:
	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).

Scottrif: 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…'

2010-10-22T20:22:19Z

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…'

New page

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-qemu-ifup command N times 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:

runqemu-nfs {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-qemu-ifup command N times 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:

runqemu-nfs {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.