| Message ID | 1360097491-20121-1-git-send-email-contact@team-ard.com |
|---|---|
| State | Changes Requested |
| Headers | show |
Hi Willy, 2013/2/5 Willy Lambert <lambert.willy@gmail.com>: > From: "A.R.D" <contact@team-ard.com> > > > Signed-off-by: A.R.D <contact@team-ard.com> > --- > docs/manual/beyond-buildroot.txt | 83 ++++++++++++++++++++++++++++++----- > docs/manual/customize-toolchain.txt | 45 ++++++++++++++++--- > docs/manual/make-tips.txt | 12 +++++ > docs/manual/manual.txt | 4 +- > 4 files changed, 125 insertions(+), 19 deletions(-) > > diff --git a/docs/manual/beyond-buildroot.txt b/docs/manual/beyond-buildroot.txt > index a87b584..d9bdd32 100644 > --- a/docs/manual/beyond-buildroot.txt > +++ b/docs/manual/beyond-buildroot.txt > @@ -3,17 +3,77 @@ > Beyond Buildroot > ================ > > -Boot the generated images > -------------------------- > +After having run Buildroot, you will have a brand new filesystem for your target exported in buildroot/output/images. The content of this folder depends of the option you choosed during buildroot configuration in the "Filesystem images" section. Please wrap your line at +/- 80 characters. > > -NFS boot > -~~~~~~~~ > +So what's next ? You will probably want to : > > -To achieve NFS-boot, enable _tar root filesystem_ in the _Filesystem > -images_ menu. > +* generate a virtual disk to dump to real system or to use in virtualisation systems (http://wiki.qemu.org/Main_Page[Qemu], https://www.virtualbox.org/[VirtualBox],...) Technically speaking, qemu can boot any ext2-filesystem built by Buildroot out-of-box. However, AFAIK, VirtualBox or VMWare stuff mostly (only?) concerns x86/x86_64 targets. > + > +* test your kernel and your rootfs in virtualisation systems > + > +* install your rootfs on the target to test it > + > +This stuff is really depending on each project and hardware, so we cannot describe every solution here, and this is where Buildroot's work ends. The following section aims at guiding new user on what to do next to avoid staying in the dark. It is *not* an exact guide on how to precisely do what is described. Please take the time to have a look to refered projets to get those details. s/refered projets/referred projects/ > + > +Generate a bootable raw disk file > +--------------------------------- > + > +If you plan to use virtual machines, or to copy a binary bootable image to your target, you will need to create a "virtual disk". To create a bootable raw disk file you will need to : > + > +* create an empty file with "dd" > + > +* partition the file as a disk with "fdisk" > + > +* set the MBR > + > +* create virtual devices in /dev pointing to your virtual disk partitions (as you will have with /dev/sda, /dev/sda1, /dev/sda2,...) with http://robert.penz.name/73/kpartx-a-tool-for-mounting-partitions-within-an-image-file/[kpartx] > + > +* mount one (or several) partition of your virtual disk with "mount" > + > +* extract your rootfs, boot folder,home directory, ... into them. > + > +Network boot > +------------- > + > +Some device doesn't have external memory and need to be booted to be able to install the rootfs. A nice way of doing this is to boot from the network. If your device allows you to do that you will be able to : > + > +* test the in-progress-rootfs without installing it on your system (it prevents ruining flash memories) > + > +* create a second buildroot project with a minimalist installer that will install your production rootfs on the target. > + > + > +Network bootloaders (PXE,iPXE) > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +To fully boot on the network you need a network bootloader. This is optionnal and you could use your classic bootloader to mount a NFS rootfs. > + > +http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf[PXE] is a specification that has been implemented at least by http://www.syslinux.org/wiki/index.php/PXELINUX[PXELINUX] and http://ipxe.org/[iPXE]. > + > +The main idea is to have a DHCP server that provide a link to a generic boot ROM that is accessible from a simple FTP server (TFTP). Then your target boots with it and come back to the TFTP server to get the specific stuff (for instance it's boot menu). > + > +Here is some hints on how to setup this : > +http://www.digitalpeer.com/id/linuxnfs > + > + > +NFS rootfs mount on "/" > +~~~~~~~~~~~~~~~~~~~~~~~ > + > +The idea is to mount "/" with a network shared folder from a http://tldp.org/HOWTO/NFS-HOWTO/index.html[NFS] server (in general your dev host). To enable the NFS-boot, you shall activate the _tar root filesystem_ option in the _Filesystem images_ menu. > + > +Your embedded kernel need at least the following option : > + > +* NFS filesystem support (CONFIG_NFS_FS). > + > +* Root file system on NFS (CONFIG_ROOT_NFS). > + > +* Ethernet (CONFIG_NET_ETHERNET). > + > +* The ethernet driver for the embedded network card. > + > +* IP: kernel level autoconfiguration (CONFIG_IP_PNP, CONFIG_IP_PNP_BOOTTP, CONFIG_IP_PNP_DHCP). > > After a complete build, just run the following commands to setup the > -NFS-root directory: > +NFS-root directory of the server : > > ------------------- > sudo tar -xavf /path/to/output_dir/rootfs.tar -C /path/to/nfs_root_dir > @@ -21,10 +81,13 @@ sudo tar -xavf /path/to/output_dir/rootfs.tar -C /path/to/nfs_root_dir > > Remember to add this path to +/etc/exports+. > > -Then, you can execute a NFS-boot from your target. > +Then, you can execute a NFS-boot from your target. Here is a documentation hints : > + Some links should be here, no? > + > + > > -Chroot > ------- > +Chroot into generated image > +--------------------------- > > If you want to chroot in a generated image, then there are few thing > you should be aware of: > diff --git a/docs/manual/customize-toolchain.txt b/docs/manual/customize-toolchain.txt > index 2b24412..1f146ad 100644 > --- a/docs/manual/customize-toolchain.txt > +++ b/docs/manual/customize-toolchain.txt > @@ -16,6 +16,18 @@ generate it. > It also requires to set the Buildroot settings according to the toolchain ones > (see xref:external-toolchain[]). > > +Using the Crosstool-NG backend > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +The http://crosstool-ng.org[crosstool-NG] toolchain backend enables a rather > +limited set of settings under the Buildroot +Toolchain+ menu: > + > +* The http://crosstool-ng.org[crosstool-NG] configuration file > + > +* Gdb and some toolchain options > + > +Then, the toolchain can be fine-tuned by invoking +make ctng-menuconfig+. > + > Using the internal Buildroot toolchain backend > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > @@ -33,14 +45,33 @@ However, it allows to tune major settings, such as: > These settings are available after selecting the +Buildroot toolchain+ type in > the menu +Toolchain+. > > -Using the Crosstool-NG backend > -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > -The http://crosstool-ng.org[crosstool-NG] toolchain backend enables a rather > -limited set of settings under the Buildroot +Toolchain+ menu: > +The common use case is to have a buildroot setup where you disable everything from the following menus: > > -* The http://crosstool-ng.org[crosstool-NG] configuration file > +* System configuration > > -* Gdb and some toolchain options > +* Package Selection for the target > + > +* Filesystem images > + > +* Bootloaders > + > +* Kernel > + > +And build this out of sources with : > +--------------------------------------- > + $ make menuconfig O=/path/to/somewhere > +--------------------------------------- > + > +Then configure your working configuration with : > + > +* Toolchain type (External toolchain) > + > +* Toolchain (Custom toolchain) > + > +* Toolchain origin (Pre-installed toolchain) > + > +* (/path/to/somewhere/host/usr) Toolchain path > + > +Note that builroot toolchains are *not* relocable, so if you plan to share it with other machines, you will *have to* install it in the same position ("/path/to/somewhere") s/relocable/relocatable/ > > -Then, the toolchain can be fine-tuned by invoking +make ctng-menuconfig+. > diff --git a/docs/manual/make-tips.txt b/docs/manual/make-tips.txt > index 8cd77c0..80574bd 100644 > --- a/docs/manual/make-tips.txt > +++ b/docs/manual/make-tips.txt > @@ -53,6 +53,18 @@ and target trees, the images and the toolchain): > $ make clean > -------------------- > > + > +The present manual sources are in the buildroot/docs/manual folder. You may compile them with : here, I think you can drop the leading "buildroot/" in the path. > + > +--------------------------------- > + $ make manual-clean > + $ make manual > +--------------------------------- > + > +The output documentation is provided in the buildroot/output/docs/manual folder. > + > +*Note* : asciidoc is required to build it. There is a known issue that you can't build it under Dedian Squeeze. > + > To delete all build products as well as the configuration: > > -------------------- > diff --git a/docs/manual/manual.txt b/docs/manual/manual.txt > index c34e0ca..2f49674 100644 > --- a/docs/manual/manual.txt > +++ b/docs/manual/manual.txt > @@ -17,6 +17,8 @@ include::starting-up.txt[] > > include::working-with.txt[] > > +include::beyond-buildroot.txt[] > + > include::faq-troubleshooting.txt[] > > include::going-further.txt[] > @@ -25,8 +27,6 @@ include::developer-guide.txt[] > > include::legal-notice.txt[] > > -include::beyond-buildroot.txt[] > - > include::get-involved.txt[] > > include::contribute.txt[] > -- > 1.7.9.5 > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot Regards,
Hi Willy, When there are review comments you want to integrate, you should still send it as a single patch. You can update an existing patch by doing 'git commit --amend' instead of a single commit. Or, if you committed it in pieces, you can use 'git rebase -i origin/master'. That will give you an editor where you can tell git what to do with each patch. Select 'reword' for the first patch, and 'fixup' for the subsequent patches. The patch comment should be wrapped at 75 columns. It should look more or less as follows: <<<<<< manual: extend "Beyond buildroot" section * Explain how to create a bootable disk image for PC. * Explain how to use PXE + NFS-root Signed-off-by: ... --- v3: [new things in v3] v2: [new things in v2] >>>>>> In other words: a title that fits on a 75-column line, then one or more paragraphs of explanation, then your Sob, then a line with three dashes, and then any other comments that shouldn't go into the git history, e.g. your patch changelog. The text after the three dashes is removed automatically when the patch is applied by git-am. As someone else noted before on the list, this patch is doing three things so it should really be three patches. Splitting a patch is a bit more complex in git, but here goes. git log --oneline -1 # This prints something like: # 123abcd manual: extend "Beyond buildroot" section # note the commit ID (123abcd in this example). git reset HEAD^ # Now you have undone the commit. git add -p # This allows you to interactively select which things you want to have # committed in this patch. Use '?' for help. git commit -c 123abcd # commit ID you noted before # This makes a commit and reuses the commit message you had before. git add -p git commit ... I'm not going to comment on the patch itself, it's too difficult when it has such long lines and with the extra 'review modifications'. I will comment when you resend, though. Regards, Arnout
2013/2/7 Arnout Vandecappelle <arnout@mind.be>: > Hi Willy, > > When there are review comments you want to integrate, you should still send > it as a single patch. You can update an existing patch by doing 'git commit > --amend' instead of a single commit. Or, if you committed it in pieces, you > can use 'git rebase -i origin/master'. That will give you an editor where > you can tell git what to do with each patch. Select 'reword' for the first > patch, and 'fixup' for the subsequent patches. > > The patch comment should be wrapped at 75 columns. It should look more or > less as follows: > > <<<<<< > manual: extend "Beyond buildroot" section > > * Explain how to create a bootable disk image for PC. > * Explain how to use PXE + NFS-root > > Signed-off-by: ... > --- > v3: [new things in v3] > v2: [new things in v2] >>>>>>> > > In other words: a title that fits on a 75-column line, then one or more > paragraphs of explanation, then your Sob, then a line with three dashes, and > then any other comments that shouldn't go into the git history, e.g. your > patch changelog. The text after the three dashes is removed automatically > when the patch is applied by git-am. > > As someone else noted before on the list, this patch is doing three things > so it should really be three patches. Splitting a patch is a bit more > complex in git, but here goes. > > git log --oneline -1 > # This prints something like: > # 123abcd manual: extend "Beyond buildroot" section > # note the commit ID (123abcd in this example). > git reset HEAD^ > # Now you have undone the commit. > git add -p > # This allows you to interactively select which things you want to have > # committed in this patch. Use '?' for help. > git commit -c 123abcd # commit ID you noted before > # This makes a commit and reuses the commit message you had before. > git add -p > git commit > ... > > > I'm not going to comment on the patch itself, it's too difficult when it > has such long lines and with the extra 'review modifications'. I will > comment when you resend, though. > > > Regards, > Arnout > -- > Arnout Vandecappelle arnout at mind be > Senior Embedded Software Architect +32-16-286500 > Essensium/Mind http://www.mind.be > G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven > LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle > GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F Thaks a lot for details, it'll help. Sorry for the noise, but I'm trying hard with git.
On 08/02/13 09:47, Willy Lambert wrote: [snip] > Thaks a lot for details, it'll help. Sorry for the noise, but I'm > trying hard with git. No need to apologize, it's better that you send something imperfect than nothing at all. Regards, Arnout
diff --git a/docs/manual/beyond-buildroot.txt b/docs/manual/beyond-buildroot.txt index a87b584..d9bdd32 100644 --- a/docs/manual/beyond-buildroot.txt +++ b/docs/manual/beyond-buildroot.txt @@ -3,17 +3,77 @@ Beyond Buildroot ================ -Boot the generated images -------------------------- +After having run Buildroot, you will have a brand new filesystem for your target exported in buildroot/output/images. The content of this folder depends of the option you choosed during buildroot configuration in the "Filesystem images" section. -NFS boot -~~~~~~~~ +So what's next ? You will probably want to : -To achieve NFS-boot, enable _tar root filesystem_ in the _Filesystem -images_ menu. +* generate a virtual disk to dump to real system or to use in virtualisation systems (http://wiki.qemu.org/Main_Page[Qemu], https://www.virtualbox.org/[VirtualBox],...) + +* test your kernel and your rootfs in virtualisation systems + +* install your rootfs on the target to test it + +This stuff is really depending on each project and hardware, so we cannot describe every solution here, and this is where Buildroot's work ends. The following section aims at guiding new user on what to do next to avoid staying in the dark. It is *not* an exact guide on how to precisely do what is described. Please take the time to have a look to refered projets to get those details. + +Generate a bootable raw disk file +--------------------------------- + +If you plan to use virtual machines, or to copy a binary bootable image to your target, you will need to create a "virtual disk". To create a bootable raw disk file you will need to : + +* create an empty file with "dd" + +* partition the file as a disk with "fdisk" + +* set the MBR + +* create virtual devices in /dev pointing to your virtual disk partitions (as you will have with /dev/sda, /dev/sda1, /dev/sda2,...) with http://robert.penz.name/73/kpartx-a-tool-for-mounting-partitions-within-an-image-file/[kpartx] + +* mount one (or several) partition of your virtual disk with "mount" + +* extract your rootfs, boot folder,home directory, ... into them. + +Network boot +------------- + +Some device doesn't have external memory and need to be booted to be able to install the rootfs. A nice way of doing this is to boot from the network. If your device allows you to do that you will be able to : + +* test the in-progress-rootfs without installing it on your system (it prevents ruining flash memories) + +* create a second buildroot project with a minimalist installer that will install your production rootfs on the target. + + +Network bootloaders (PXE,iPXE) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To fully boot on the network you need a network bootloader. This is optionnal and you could use your classic bootloader to mount a NFS rootfs. + +http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf[PXE] is a specification that has been implemented at least by http://www.syslinux.org/wiki/index.php/PXELINUX[PXELINUX] and http://ipxe.org/[iPXE]. + +The main idea is to have a DHCP server that provide a link to a generic boot ROM that is accessible from a simple FTP server (TFTP). Then your target boots with it and come back to the TFTP server to get the specific stuff (for instance it's boot menu). + +Here is some hints on how to setup this : +http://www.digitalpeer.com/id/linuxnfs + + +NFS rootfs mount on "/" +~~~~~~~~~~~~~~~~~~~~~~~ + +The idea is to mount "/" with a network shared folder from a http://tldp.org/HOWTO/NFS-HOWTO/index.html[NFS] server (in general your dev host). To enable the NFS-boot, you shall activate the _tar root filesystem_ option in the _Filesystem images_ menu. + +Your embedded kernel need at least the following option : + +* NFS filesystem support (CONFIG_NFS_FS). + +* Root file system on NFS (CONFIG_ROOT_NFS). + +* Ethernet (CONFIG_NET_ETHERNET). + +* The ethernet driver for the embedded network card. + +* IP: kernel level autoconfiguration (CONFIG_IP_PNP, CONFIG_IP_PNP_BOOTTP, CONFIG_IP_PNP_DHCP). After a complete build, just run the following commands to setup the -NFS-root directory: +NFS-root directory of the server : ------------------- sudo tar -xavf /path/to/output_dir/rootfs.tar -C /path/to/nfs_root_dir @@ -21,10 +81,13 @@ sudo tar -xavf /path/to/output_dir/rootfs.tar -C /path/to/nfs_root_dir Remember to add this path to +/etc/exports+. -Then, you can execute a NFS-boot from your target. +Then, you can execute a NFS-boot from your target. Here is a documentation hints : + + + -Chroot ------- +Chroot into generated image +--------------------------- If you want to chroot in a generated image, then there are few thing you should be aware of: diff --git a/docs/manual/customize-toolchain.txt b/docs/manual/customize-toolchain.txt index 2b24412..1f146ad 100644 --- a/docs/manual/customize-toolchain.txt +++ b/docs/manual/customize-toolchain.txt @@ -16,6 +16,18 @@ generate it. It also requires to set the Buildroot settings according to the toolchain ones (see xref:external-toolchain[]). +Using the Crosstool-NG backend +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The http://crosstool-ng.org[crosstool-NG] toolchain backend enables a rather +limited set of settings under the Buildroot +Toolchain+ menu: + +* The http://crosstool-ng.org[crosstool-NG] configuration file + +* Gdb and some toolchain options + +Then, the toolchain can be fine-tuned by invoking +make ctng-menuconfig+. + Using the internal Buildroot toolchain backend ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -33,14 +45,33 @@ However, it allows to tune major settings, such as: These settings are available after selecting the +Buildroot toolchain+ type in the menu +Toolchain+. -Using the Crosstool-NG backend -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The http://crosstool-ng.org[crosstool-NG] toolchain backend enables a rather -limited set of settings under the Buildroot +Toolchain+ menu: +The common use case is to have a buildroot setup where you disable everything from the following menus: -* The http://crosstool-ng.org[crosstool-NG] configuration file +* System configuration -* Gdb and some toolchain options +* Package Selection for the target + +* Filesystem images + +* Bootloaders + +* Kernel + +And build this out of sources with : +--------------------------------------- + $ make menuconfig O=/path/to/somewhere +--------------------------------------- + +Then configure your working configuration with : + +* Toolchain type (External toolchain) + +* Toolchain (Custom toolchain) + +* Toolchain origin (Pre-installed toolchain) + +* (/path/to/somewhere/host/usr) Toolchain path + +Note that builroot toolchains are *not* relocable, so if you plan to share it with other machines, you will *have to* install it in the same position ("/path/to/somewhere") -Then, the toolchain can be fine-tuned by invoking +make ctng-menuconfig+. diff --git a/docs/manual/make-tips.txt b/docs/manual/make-tips.txt index 8cd77c0..80574bd 100644 --- a/docs/manual/make-tips.txt +++ b/docs/manual/make-tips.txt @@ -53,6 +53,18 @@ and target trees, the images and the toolchain): $ make clean -------------------- + +The present manual sources are in the buildroot/docs/manual folder. You may compile them with : + +--------------------------------- + $ make manual-clean + $ make manual +--------------------------------- + +The output documentation is provided in the buildroot/output/docs/manual folder. + +*Note* : asciidoc is required to build it. There is a known issue that you can't build it under Dedian Squeeze. + To delete all build products as well as the configuration: -------------------- diff --git a/docs/manual/manual.txt b/docs/manual/manual.txt index c34e0ca..2f49674 100644 --- a/docs/manual/manual.txt +++ b/docs/manual/manual.txt @@ -17,6 +17,8 @@ include::starting-up.txt[] include::working-with.txt[] +include::beyond-buildroot.txt[] + include::faq-troubleshooting.txt[] include::going-further.txt[] @@ -25,8 +27,6 @@ include::developer-guide.txt[] include::legal-notice.txt[] -include::beyond-buildroot.txt[] - include::get-involved.txt[] include::contribute.txt[]