[Buildroot] [pull request] Pull request for branch sma/doc-update

[Buildroot] [pull request] Pull request for branch sma/doc-update

[Samuel Martin]

All,


Here is a couple of fixes (patches 1 to 3, 5 and 7) and
enhancements (patches 4, 6, 8 and 9) for the maunal.


Yours,

Samuel


The following changes since commit 8a67c54c77782936b69fd062d49aa590f4f97bb3:

  netatalk: disable dtrace (2013-10-05 21:12:44 +0200)

are available in the git repository at:

  git at github.com:tSed/buildroot.git sma/doc-update

for you to fetch changes up to a2cb1b7caaa580f341abbb3788d18323c3e2e7c3:

  manual: rework Deploying images chapter (2013-10-05 21:35:55 +0200)

----------------------------------------------------------------
Samuel Martin (9):
      manual: minor update in manual generation
      manual: developer-guide.txt: cleanup non-existing source
      manual: update dependency list to build the documentation
      manual: add information about buildroot toolchain not being relocable and put some hints to use it
      manual: configure: add deprecation warning for Crosstool-NG toolchain backend
      manual: introduction.txt: enhance Buildroot presentation
      manual: get-involved.txt: fix event order
      manual: update get-involved section
      manual: rework Deploying images chapter

 docs/manual/beyond-buildroot.txt    |  41 -----
 docs/manual/configure.txt           |   9 ++
 docs/manual/customize-toolchain.txt |  72 +++++++--
 docs/manual/deploying-images.txt    | 290 ++++++++++++++++++++++++++++++++++++
 docs/manual/developer-guide.txt     |   2 -
 docs/manual/get-involved.txt        | 147 ++++++++++++++++--
 docs/manual/introduction.txt        |  40 +++++
 docs/manual/manual.mk               |  13 +-
 docs/manual/manual.txt              |   4 +-
 docs/manual/prerequisite.txt        |   5 +-
 docs/manual/using.txt               |   3 +-
 support/scripts/gen-manual-lists.py |   9 +-
 12 files changed, 552 insertions(+), 83 deletions(-)
 delete mode 100644 docs/manual/beyond-buildroot.txt
 create mode 100644 docs/manual/deploying-images.txt

[Buildroot] [PATCH 1/9] manual: minor update in manual generation

[Samuel Martin]

* minor refactoring in gen-manual-list.py
* generate manual in the build tree

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 docs/manual/manual.mk               | 13 +++++++------
 support/scripts/gen-manual-lists.py |  9 ++++-----
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/docs/manual/manual.mk b/docs/manual/manual.mk
index d092d3f..84acaae 100644
--- a/docs/manual/manual.mk
+++ b/docs/manual/manual.mk
@@ -1,6 +1,8 @@
+MANUAL_BUILDDIR = $(BUILD_DIR)/buildroot-manual
 manual-update-lists:
 	$(Q)$(call MESSAGE,"Updating the manual lists...")
-	$(Q)BR2_DEFCONFIG="" TOPDIR=$(TOPDIR) O=$(O)/docs/manual/.build \
+	$(Q)mkdir -p $(MANUAL_BUILDDIR)
+	$(Q)BR2_DEFCONFIG="" TOPDIR=$(TOPDIR) O=$(MANUAL_BUILDDIR) \
 		$(TOPDIR)/support/scripts/gen-manual-lists.py
 
 ################################################################################
@@ -26,11 +28,10 @@ $$(O)/docs/$(1)/$(1).$(4): docs/$(1)/$(1).txt \
 			   $$($(call UPPERCASE,$(1))_SOURCES) \
 			   manual-update-lists
 	$(Q)$(call MESSAGE,"Generating $(5) $(1)...")
-	$(Q)mkdir -p $$(@D)/.build
-	$(Q)rsync -au docs/$(1)/*.txt $$(@D)/.build
+	$(Q)mkdir -p $$(@D) $(MANUAL_BUILDDIR)
+	$(Q)rsync -au docs/$(1)/*.txt $(MANUAL_BUILDDIR)
 	$(Q)a2x $(6) -f $(2) -d book -L -r $(TOPDIR)/docs/images \
-	        -D $$(@D) $$(@D)/.build/$(1).txt
-	-$(Q)rm -rf $$(@D)/.build
+		-D $$(@D) $(MANUAL_BUILDDIR)/$(1).txt
 endef
 
 ################################################################################
@@ -49,7 +50,7 @@ $(call GENDOC_INNER,$(1),text,txt,text,text)
 $(call GENDOC_INNER,$(1),epub,epub,epub,ePUB)
 clean: $(1)-clean
 $(1)-clean:
-	$(Q)$(RM) -rf $(O)/docs/$(1)
+	$(Q)$(RM) -rf $(O)/docs/$(1) $(MANUAL_BUILDDIR)
 .PHONY: $(1) $(1)-clean manual-update-lists
 endef
 
diff --git a/support/scripts/gen-manual-lists.py b/support/scripts/gen-manual-lists.py
index 3568843..5c81e1d 100755
--- a/support/scripts/gen-manual-lists.py
+++ b/support/scripts/gen-manual-lists.py
@@ -107,7 +107,7 @@ def get_symbol_parents(item, root=None, enable_choice=False):
         parent = parent.get_parent()
     if isinstance(root, kconfiglib.Menu) or \
             (enable_choice and isinstance(root, kconfiglib.Choice)):
-        parents.append("") # Dummy empty parrent to get a leading arrow ->
+        parents.append("") # Dummy empty parent to get a leading arrow ->
     parents.reverse()
     return parents
 
@@ -126,15 +126,14 @@ def format_asciidoc_table(root, get_label_func, filter_func=lambda x: True,
     :param sub_menu:       Output the column with the sub-menu path
 
     """
-    def _format_entry(label, parents, sub_menu):
+    def _format_entry(item, parents, sub_menu):
         """ Format an asciidoc table entry.
 
         """
         if sub_menu:
-            return "| {0:<40} <| {1}\n".format(label, " -> ".join(parents))
+            return "| {0:<40} <| {1}\n".format(item, " -> ".join(parents))
         else:
-            return "| {0:<40}\n".format(label)
-
+            return "| {0:<40}\n".format(item)
     lines = []
     for item in get_symbol_subset(root, filter_func):
         if not item.is_symbol() or not item.prompts:
-- 
1.8.4

[Buildroot] [PATCH 1/9] manual: minor update in manual generation

[Thomas Petazzoni]

Dear Samuel Martin,

On Sat,  5 Oct 2013 21:49:06 +0200, Samuel Martin wrote:
> * minor refactoring in gen-manual-list.py
> * generate manual in the build tree

Why? This is breaking the "release:" target of the main Makefile, which
assumes that the manual is generated in $(O)/docs/manual.

> diff --git a/support/scripts/gen-manual-lists.py b/support/scripts/gen-manual-lists.py
> index 3568843..5c81e1d 100755
> --- a/support/scripts/gen-manual-lists.py
> +++ b/support/scripts/gen-manual-lists.py
> @@ -107,7 +107,7 @@ def get_symbol_parents(item, root=None, enable_choice=False):
>          parent = parent.get_parent()
>      if isinstance(root, kconfiglib.Menu) or \
>              (enable_choice and isinstance(root, kconfiglib.Choice)):
> -        parents.append("") # Dummy empty parrent to get a leading arrow ->
> +        parents.append("") # Dummy empty parent to get a leading arrow ->
>      parents.reverse()
>      return parents
>  
> @@ -126,15 +126,14 @@ def format_asciidoc_table(root, get_label_func, filter_func=lambda x: True,
>      :param sub_menu:       Output the column with the sub-menu path
>  
>      """
> -    def _format_entry(label, parents, sub_menu):
> +    def _format_entry(item, parents, sub_menu):
>          """ Format an asciidoc table entry.
>  
>          """
>          if sub_menu:
> -            return "| {0:<40} <| {1}\n".format(label, " -> ".join(parents))
> +            return "| {0:<40} <| {1}\n".format(item, " -> ".join(parents))
>          else:
> -            return "| {0:<40}\n".format(label)
> -
> +            return "| {0:<40}\n".format(item)
>      lines = []
>      for item in get_symbol_subset(root, filter_func):
>          if not item.is_symbol() or not item.prompts:

Also, why are those changes mixed with the change of building the
manual in $(O)/build ? They seem to be completely unrelated.

Sorry to be a bit harsh, but you're a regular contributor, so I'd
expect patches from you that are properly split in individual patches
for each feature or fix, with a more descriptive commit log. We've
already suggested you to write more detailed commit logs in the past, I
believe.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/9] manual: minor update in manual generation

[Samuel Martin]

Thomas,

2013/10/6 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

> Dear Samuel Martin,
>
> On Sat,  5 Oct 2013 21:49:06 +0200, Samuel Martin wrote:
> > * minor refactoring in gen-manual-list.py
> > * generate manual in the build tree
>
> Why? This is breaking the "release:" target of the main Makefile, which
> assumes that the manual is generated in $(O)/docs/manual.
>
No, it does not.
Sorry for having misleading in this log.

What does this part of this patch is just moving the manual source/build
directory in $(O)/build/
(currently this location is $(O)/docs/manual/.build/, which is removed at
this end of the
manual generation).

This location is used to:
- generate the package list files
- rsync the *.txt source from docs/manual/

The output manuals are still generated in $(O)/docs/manual/.

Moving this manual source/build directory is, IMHO, more consistent with
the rest of how
Buildroot works.
This also avoid to remove the *.txt that are generated and are actually
used by a2x,
this is very helpful for investigating asdciidoc/dblatex/texlive related
issues.


> > diff --git a/support/scripts/gen-manual-lists.py
> b/support/scripts/gen-manual-lists.py
> > index 3568843..5c81e1d 100755
> > --- a/support/scripts/gen-manual-lists.py
> > +++ b/support/scripts/gen-manual-lists.py
> > @@ -107,7 +107,7 @@ def get_symbol_parents(item, root=None,
> enable_choice=False):
> >          parent = parent.get_parent()
> >      if isinstance(root, kconfiglib.Menu) or \
> >              (enable_choice and isinstance(root, kconfiglib.Choice)):
> > -        parents.append("") # Dummy empty parrent to get a leading arrow
> ->
> > +        parents.append("") # Dummy empty parent to get a leading arrow
> ->
> >      parents.reverse()
> >      return parents
> >
> > @@ -126,15 +126,14 @@ def format_asciidoc_table(root, get_label_func,
> filter_func=lambda x: True,
> >      :param sub_menu:       Output the column with the sub-menu path
> >
> >      """
> > -    def _format_entry(label, parents, sub_menu):
> > +    def _format_entry(item, parents, sub_menu):
> >          """ Format an asciidoc table entry.
> >
> >          """
> >          if sub_menu:
> > -            return "| {0:<40} <| {1}\n".format(label, " ->
> ".join(parents))
> > +            return "| {0:<40} <| {1}\n".format(item, " ->
> ".join(parents))
> >          else:
> > -            return "| {0:<40}\n".format(label)
> > -
> > +            return "| {0:<40}\n".format(item)
> >      lines = []
> >      for item in get_symbol_subset(root, filter_func):
> >          if not item.is_symbol() or not item.prompts:
>
> Also, why are those changes mixed with the change of building the
> manual in $(O)/build ? They seem to be completely unrelated.
>
Right, sorry about that.


>
> Sorry to be a bit harsh, but you're a regular contributor,

Don't be.


> so I'd

expect patches from you that are properly split in individual patches
> for each feature or fix, with a more descriptive commit log. We've
> already suggested you to write more detailed commit logs in the past, I
> believe.
>
Buildroot rules/My mistakes... I'll repost this.

Regards,

-- 
Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131006/4fafdf56/attachment.html>

[Buildroot] [PATCH 2/9] manual: developer-guide.txt: cleanup non-existing source

[Samuel Martin]

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 docs/manual/developer-guide.txt | 2 --
 1 file changed, 2 deletions(-)

diff --git a/docs/manual/developer-guide.txt b/docs/manual/developer-guide.txt
index 43272f5..8125ad5 100644
--- a/docs/manual/developer-guide.txt
+++ b/docs/manual/developer-guide.txt
@@ -11,5 +11,3 @@ include::adding-packages.txt[]
 include::patch-policy.txt[]
 
 include::download-infra.txt[]
-
-include::board-support.txt[]
-- 
1.8.4

[Buildroot] [PATCH 2/9] manual: developer-guide.txt: cleanup non-existing source

[Thomas Petazzoni]

Dear Samuel Martin,

On Sat,  5 Oct 2013 21:49:07 +0200, Samuel Martin wrote:
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
>  docs/manual/developer-guide.txt | 2 --
>  1 file changed, 2 deletions(-)

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2/9] manual: developer-guide.txt: cleanup non-existing source

[Thomas De Schampheleire]

On Sat, Oct 5, 2013 at 9:49 PM, Samuel Martin <s.martin49@gmail.com> wrote:
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
>  docs/manual/developer-guide.txt | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/docs/manual/developer-guide.txt b/docs/manual/developer-guide.txt
> index 43272f5..8125ad5 100644
> --- a/docs/manual/developer-guide.txt
> +++ b/docs/manual/developer-guide.txt
> @@ -11,5 +11,3 @@ include::adding-packages.txt[]
>  include::patch-policy.txt[]
>
>  include::download-infra.txt[]
> -
> -include::board-support.txt[]
> --

Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

[Buildroot] [PATCH 3/9] manual: update dependency list to build the documentation

[Samuel Martin]

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 docs/manual/prerequisite.txt | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/docs/manual/prerequisite.txt b/docs/manual/prerequisite.txt
index 78ce436..74b6a6c 100644
--- a/docs/manual/prerequisite.txt
+++ b/docs/manual/prerequisite.txt
@@ -76,4 +76,7 @@ development context (further details: refer to xref:download-infra[]).
 ** The +jar+ tool
 
 * Documentation generation tools:
-** +asciidoc+
+** +asciidoc+ version 8.6.3 or later
+** +dblatex+
+** +w3m+
+** +python+ with +argparse+ module
-- 
1.8.4

[Buildroot] [PATCH 3/9] manual: update dependency list to build the documentation

[Thomas Petazzoni]

Dear Samuel Martin,

On Sat,  5 Oct 2013 21:49:08 +0200, Samuel Martin wrote:
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
>  docs/manual/prerequisite.txt | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 3/9] manual: update dependency list to build the documentation

[Thomas De Schampheleire]

On Sat, Oct 5, 2013 at 9:49 PM, Samuel Martin <s.martin49@gmail.com> wrote:
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
>  docs/manual/prerequisite.txt | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/docs/manual/prerequisite.txt b/docs/manual/prerequisite.txt
> index 78ce436..74b6a6c 100644
> --- a/docs/manual/prerequisite.txt
> +++ b/docs/manual/prerequisite.txt
> @@ -76,4 +76,7 @@ development context (further details: refer to xref:download-infra[]).
>  ** The +jar+ tool
>
>  * Documentation generation tools:
> -** +asciidoc+
> +** +asciidoc+ version 8.6.3 or later
> +** +dblatex+
> +** +w3m+
> +** +python+ with +argparse+ module
> --
> 1.8.4

This change is already part of my patch:
http://patchwork.ozlabs.org/patch/276855/
The patch is not yet committed though, but is in the to-be-applied
overview ThomasP sent today...

Best regards,
Thomas

[Buildroot] [PATCH 3/9] manual: update dependency list to build the documentation

[Samuel Martin]

2013/10/6 Thomas De Schampheleire <patrickdepinguin@gmail.com>

> On Sat, Oct 5, 2013 at 9:49 PM, Samuel Martin <s.martin49@gmail.com>
> wrote:
> > Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> > ---
> >  docs/manual/prerequisite.txt | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/docs/manual/prerequisite.txt b/docs/manual/prerequisite.txt
> > index 78ce436..74b6a6c 100644
> > --- a/docs/manual/prerequisite.txt
> > +++ b/docs/manual/prerequisite.txt
> > @@ -76,4 +76,7 @@ development context (further details: refer to
> xref:download-infra[]).
> >  ** The +jar+ tool
> >
> >  * Documentation generation tools:
> > -** +asciidoc+
> > +** +asciidoc+ version 8.6.3 or later
> > +** +dblatex+
> > +** +w3m+
> > +** +python+ with +argparse+ module
> > --
> > 1.8.4
>
> This change is already part of my patch:
> http://patchwork.ozlabs.org/patch/276855/
> The patch is not yet committed though, but is in the to-be-applied
> overview ThomasP sent today...
>
Well, and I did acked it, so forget this patch.

Regards,

-- 
Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131006/53dd171a/attachment.html>

[Buildroot] [PATCH 4/9] manual: add information about buildroot toolchain not being relocable and put some hints to use it

[Samuel Martin]

Signed-off-by: A.R.D. <contact@team-ard.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>

---
Changes v2 -> v3:
- rephrase how to use buildroot toochain as an external one

Changes v1 -> v2:
- rephrase commit message
- wrap line at 70-80 chars
- misc. typo and formating fixes
- misc. rewordings

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 docs/manual/customize-toolchain.txt | 72 +++++++++++++++++++++++++++++--------
 1 file changed, 57 insertions(+), 15 deletions(-)

diff --git a/docs/manual/customize-toolchain.txt b/docs/manual/customize-toolchain.txt
index 82ecc28..324afd2 100644
--- a/docs/manual/customize-toolchain.txt
+++ b/docs/manual/customize-toolchain.txt
@@ -31,28 +31,70 @@ set the environment variable BR_DEBUG_WRAPPER to either one of:
 Using the internal Buildroot toolchain backend
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The internal Buildroot toolchain backend *only* allows to generate
-*http://www.uclibc.org/[uClibc]-based toolchains*.
+The internal Buildroot toolchain backend allows to generate any C-library-based
+toolchains. 'eglibc' and 'glibc' -based toolchain generation support is still
+experimental in Buildroot
 
-However, it allows to tune major settings, such as:
+It allows to tune major settings, such as:
 
 * Linux headers version;
 
-* http://www.uclibc.org/[uClibc] configuration (see xref:uclibc-custom[uClibc]);
+* C library configuration (only available for
+  http://www.uclibc.org/[uClibc], see xref:uclibc-custom[uClibc]);
 
 * Binutils, GCC, Gdb and toolchain options.
 
 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 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+.
+It is possible to only build the toolchain by running:
+
+---------------------------------------
+make toolchain
+---------------------------------------
+
+To avoid to rebuild the toolchain (when using the 'internal Buildroot toolchain
+backend') after executing +make clean+, you can build the toolchain in some
+place, then use this prebuilt toolchain as an 'external toolchain' in another
+buildroot configuration.
+
+1. Configure the toolchain using the 'internal Buildroot toolchain backend'
+  to meet your needs:
++
+---------------------------------------
+make O=/path/to/somewhere menuconfig
+---------------------------------------
++
+1. Build the toolchain:
++
+---------------------------------------
+make O=/path/to/somewhere toolchain
+---------------------------------------
++
+1. Configure target configuration using the prebuilt toolchain as an
+   'external toolchain':
++
+---------------------------------------
+make O=/path/to/somewhere_else menuconfig
+---------------------------------------
++
+In the 'Toolchain' menu, set:
++
+* 'Toolchain type': +External toolchain+ (+BR2_TOOLCHAIN_EXTERNAL+)
+* 'Toolchain': +Custom toolchain+ (+BR2_TOOLCHAIN_EXTERNAL_CUSTOM+)
+* 'Toolchain origin': +Pre-installed toolchain+
+  (+BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED+)
+* 'Toolchain path': +/path/to/somewhere/host/usr+
+  (+BR2_TOOLCHAIN_EXTERNAL_PATH+)
+* and set the external toolchain properties accordingly to the ones set for
+  the prebuilt toolchain.
++
+1. Build the target binaries:
++
+---------------------------------------
+make O=/path/to/somewhere_else
+---------------------------------------
+
+Note that toolchains built using the 'internal Buildroot toolchain backend' are
+*not* relocable, so if you plan to share it with other machines, you will
+*have to* install it in the same location (i.e.: in +/path/to/somewhere+).
-- 
1.8.4

[Buildroot] [PATCH 4/9] manual: add information about buildroot toolchain not being relocable and put some hints to use it

[Thomas Petazzoni]

Dear Samuel Martin,

This commit is again mixing a number of different things: removing
details about Crosstool-NG, improving details about the Buildroot
backend, and adding informations on re-using a Buildroot built
toolchain as an external toolchain.

We'll need to synchronize on the Crosstool-NG bits, because I have a
patch series that removes the Crosstool-NG backend entirely, and which
includes the corresponding update to the manual.

On Sat,  5 Oct 2013 21:49:09 +0200, Samuel Martin wrote:

> +It is possible to only build the toolchain by running:
> +
> +---------------------------------------
> +make toolchain
> +---------------------------------------
> +
> +To avoid to rebuild the toolchain (when using the 'internal Buildroot toolchain
> +backend') after executing +make clean+, you can build the toolchain in some
> +place, then use this prebuilt toolchain as an 'external toolchain' in another
> +buildroot configuration.
> +
> +1. Configure the toolchain using the 'internal Buildroot toolchain backend'
> +  to meet your needs:
> ++
> +---------------------------------------
> +make O=/path/to/somewhere menuconfig
> +---------------------------------------
> ++
> +1. Build the toolchain:
> ++
> +---------------------------------------
> +make O=/path/to/somewhere toolchain
> +---------------------------------------
> ++
> +1. Configure target configuration using the prebuilt toolchain as an
> +   'external toolchain':
> ++
> +---------------------------------------
> +make O=/path/to/somewhere_else menuconfig
> +---------------------------------------
> ++
> +In the 'Toolchain' menu, set:
> ++
> +* 'Toolchain type': +External toolchain+ (+BR2_TOOLCHAIN_EXTERNAL+)
> +* 'Toolchain': +Custom toolchain+ (+BR2_TOOLCHAIN_EXTERNAL_CUSTOM+)
> +* 'Toolchain origin': +Pre-installed toolchain+
> +  (+BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED+)
> +* 'Toolchain path': +/path/to/somewhere/host/usr+
> +  (+BR2_TOOLCHAIN_EXTERNAL_PATH+)
> +* and set the external toolchain properties accordingly to the ones set for
> +  the prebuilt toolchain.
> ++
> +1. Build the target binaries:
> ++
> +---------------------------------------
> +make O=/path/to/somewhere_else
> +---------------------------------------
> +
> +Note that toolchains built using the 'internal Buildroot toolchain backend' are
> +*not* relocable, so if you plan to share it with other machines, you will
> +*have to* install it in the same location (i.e.: in +/path/to/somewhere+).

I am not sure this part should be in the "Customize toolchain" part.
I'm actually not sure where to put this information in the manual.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 4/9] manual: add information about buildroot toolchain not being relocable and put some hints to use it

[Samuel Martin]

Thomas,


2013/10/6 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

> Dear Samuel Martin,
>
> This commit is again mixing a number of different things: removing
> details about Crosstool-NG, improving details about the Buildroot
> backend, and adding informations on re-using a Buildroot built
> toolchain as an external toolchain.
>
Arf :( Sorry about that.


> We'll need to synchronize on the Crosstool-NG bits,

Indeed.

> because I have a
> patch series that removes the Crosstool-NG backend entirely, and which
> includes the corresponding update to the manual.
>
Well, I did this patch set WRT the current Buildroot tree state.
In case your series is merged soon, this part of the patch and the next one
(5/9) are useless.


>
> On Sat,  5 Oct 2013 21:49:09 +0200, Samuel Martin wrote:
>
> > +It is possible to only build the toolchain by running:
> > +
> > +---------------------------------------
> > +make toolchain
> > +---------------------------------------
> > +
> > +To avoid to rebuild the toolchain (when using the 'internal Buildroot
> toolchain
> > +backend') after executing +make clean+, you can build the toolchain in
> some
> > +place, then use this prebuilt toolchain as an 'external toolchain' in
> another
> > +buildroot configuration.
> > +
> > +1. Configure the toolchain using the 'internal Buildroot toolchain
> backend'
> > +  to meet your needs:
> > ++
> > +---------------------------------------
> > +make O=/path/to/somewhere menuconfig
> > +---------------------------------------
> > ++
> > +1. Build the toolchain:
> > ++
> > +---------------------------------------
> > +make O=/path/to/somewhere toolchain
> > +---------------------------------------
> > ++
> > +1. Configure target configuration using the prebuilt toolchain as an
> > +   'external toolchain':
> > ++
> > +---------------------------------------
> > +make O=/path/to/somewhere_else menuconfig
> > +---------------------------------------
> > ++
> > +In the 'Toolchain' menu, set:
> > ++
> > +* 'Toolchain type': +External toolchain+ (+BR2_TOOLCHAIN_EXTERNAL+)
> > +* 'Toolchain': +Custom toolchain+ (+BR2_TOOLCHAIN_EXTERNAL_CUSTOM+)
> > +* 'Toolchain origin': +Pre-installed toolchain+
> > +  (+BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED+)
> > +* 'Toolchain path': +/path/to/somewhere/host/usr+
> > +  (+BR2_TOOLCHAIN_EXTERNAL_PATH+)
> > +* and set the external toolchain properties accordingly to the ones set
> for
> > +  the prebuilt toolchain.
> > ++
> > +1. Build the target binaries:
> > ++
> > +---------------------------------------
> > +make O=/path/to/somewhere_else
> > +---------------------------------------
> > +
> > +Note that toolchains built using the 'internal Buildroot toolchain
> backend' are
> > +*not* relocable, so if you plan to share it with other machines, you
> will
> > +*have to* install it in the same location (i.e.: in
> +/path/to/somewhere+).
>
> I am not sure this part should be in the "Customize toolchain" part.
> I'm actually not sure where to put this information in the manual.
>
Hmm... I'm not entirely convinced myself by putting this here.
Could be included in the response of faq entry...

How about that?
"How to avoid rebuild toolchain after 'make clean'?"
Use a prebuilt toolchain with the external toolchain backend.
This prebuilt toolchain can be:
- one of the list BR already supports
- one retrieved by some other way
- one built outside BR  with crosstool-NG
- one built using the internal BR backend somewhere else (the above
solution)

Anyway, all opinion about this is welcome.


Regards,

-- 
Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131006/3426bc21/attachment.html>

[Buildroot] [PATCH 4/9] manual: add information about buildroot toolchain not being relocable and put some hints to use it

[Thomas De Schampheleire]

Hi Samuel,

Here are some comments on the current version of the patch. Maybe some
parts will be altered after the comments of ThomasP, but anyway...

On Sat, Oct 5, 2013 at 9:49 PM, Samuel Martin <s.martin49@gmail.com> wrote:
> Signed-off-by: A.R.D. <contact@team-ard.com>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
>
> ---
> Changes v2 -> v3:
> - rephrase how to use buildroot toochain as an external one
>
> Changes v1 -> v2:
> - rephrase commit message
> - wrap line at 70-80 chars
> - misc. typo and formating fixes
> - misc. rewordings
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
>  docs/manual/customize-toolchain.txt | 72 +++++++++++++++++++++++++++++--------
>  1 file changed, 57 insertions(+), 15 deletions(-)
>
> diff --git a/docs/manual/customize-toolchain.txt b/docs/manual/customize-toolchain.txt
> index 82ecc28..324afd2 100644
> --- a/docs/manual/customize-toolchain.txt
> +++ b/docs/manual/customize-toolchain.txt
> @@ -31,28 +31,70 @@ set the environment variable BR_DEBUG_WRAPPER to either one of:
>  Using the internal Buildroot toolchain backend
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> -The internal Buildroot toolchain backend *only* allows to generate
> -*http://www.uclibc.org/[uClibc]-based toolchains*.
> +The internal Buildroot toolchain backend allows to generate any C-library-based
> +toolchains. 'eglibc' and 'glibc' -based toolchain generation support is still
> +experimental in Buildroot

'any' is a bold statement. Apparently there now exists a musl C
library, and until Thomas' patches we did not have support for it. So
I would rephrase to:

The internal Buildroot toolchain backend allows to generate toolchains
based on uClibc, glibc and eglibc. Generation of (e)glibc-based
toolchains is still experimental in Buildroot.

(and when the musl patches are merged, we would add musl here too).

>
> -However, it allows to tune major settings, such as:
> +It allows to tune major settings, such as:
>
>  * Linux headers version;
>
> -* http://www.uclibc.org/[uClibc] configuration (see xref:uclibc-custom[uClibc]);
> +* C library configuration (only available for
> +  http://www.uclibc.org/[uClibc], see xref:uclibc-custom[uClibc]);
>
>  * Binutils, GCC, Gdb and toolchain options.
>
>  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 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+.
> +It is possible to only build the toolchain by running:
> +
> +---------------------------------------
> +make toolchain
> +---------------------------------------
> +
> +To avoid to rebuild the toolchain (when using the 'internal Buildroot toolchain
> +backend') after executing +make clean+, you can build the toolchain in some
> +place, then use this prebuilt toolchain as an 'external toolchain' in another
> +buildroot configuration.

I would rephrase as:
To avoid rebuilding the toolchain after executing +make clean+ (when
using the internal Buildroot toolchain backend), you can build the
toolchain in one location, then use this prebuilt toolchain ...

(note that I explicitly removed the apostrophes ' around internal
Buildroot toolchain backend; I don't think this is needed).

> +
> +1. Configure the toolchain using the 'internal Buildroot toolchain backend'

same comment on apostrophes

> +  to meet your needs:
> ++
> +---------------------------------------
> +make O=/path/to/somewhere menuconfig
> +---------------------------------------
> ++
> +1. Build the toolchain:
> ++
> +---------------------------------------
> +make O=/path/to/somewhere toolchain
> +---------------------------------------
> ++
> +1. Configure target configuration using the prebuilt toolchain as an
> +   'external toolchain':
> ++
> +---------------------------------------
> +make O=/path/to/somewhere_else menuconfig
> +---------------------------------------
> ++
> +In the 'Toolchain' menu, set:
> ++
> +* 'Toolchain type': +External toolchain+ (+BR2_TOOLCHAIN_EXTERNAL+)
> +* 'Toolchain': +Custom toolchain+ (+BR2_TOOLCHAIN_EXTERNAL_CUSTOM+)
> +* 'Toolchain origin': +Pre-installed toolchain+
> +  (+BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED+)
> +* 'Toolchain path': +/path/to/somewhere/host/usr+
> +  (+BR2_TOOLCHAIN_EXTERNAL_PATH+)
> +* and set the external toolchain properties accordingly to the ones set for
> +  the prebuilt toolchain.

according

> ++
> +1. Build the target binaries:
> ++
> +---------------------------------------
> +make O=/path/to/somewhere_else
> +---------------------------------------
> +
> +Note that toolchains built using the 'internal Buildroot toolchain backend' are

apostrophes

> +*not* relocable, so if you plan to share it with other machines, you will
> +*have to* install it in the same location (i.e.: in +/path/to/somewhere+).

relocatable

and I would rephrase as:
..., so if you plan to use these toolchains on different machines, you
will ...... in the same location (..) on every machine.

Best regards,
Thomas

[Buildroot] [PATCH 5/9] manual: configure: add deprecation warning for Crosstool-NG toolchain backend

[Samuel Martin]

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 docs/manual/configure.txt | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
index 56b0469..5d6df88 100644
--- a/docs/manual/configure.txt
+++ b/docs/manual/configure.txt
@@ -246,6 +246,15 @@ Drawbacks of this backend:
 Crosstool-NG toolchain backend
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
+[WARNING]
+The *_Crosstool-NG toolchain backend_ is deprecated* and its integration in
+Buildroot will be removed sooner or later.
+This deprecation is only due to the technical integration issues between
+Buildroot and http://crosstool-ng.org[Crosstool-NG] as a toolchain backend.
+Thus, *we highly recommend to use http://crosstool-ng.org[Crosstool-NG] to
+build the toolchain outside Buildroot, then use this toolchain as an _external
+toolchain_ in Buildroot* instead.
+
 The _Crosstool-NG toolchain backend_ integrates the
 http://crosstool-ng.org[Crosstool-NG] project with
 Buildroot. Crosstool-NG is a highly-configurable, versatile and
-- 
1.8.4

[Buildroot] [PATCH 6/9] manual: introduction.txt: enhance Buildroot presentation

[Samuel Martin]

* add a "What is Buildroot and what it is not" section
* add a "Buildroot's principles" section

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 docs/manual/introduction.txt | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/docs/manual/introduction.txt b/docs/manual/introduction.txt
index c014565..0838c48 100644
--- a/docs/manual/introduction.txt
+++ b/docs/manual/introduction.txt
@@ -25,3 +25,43 @@ comes with default configurations for several boards available
 off-the-shelf. Besides this, a number of third-party projects are based on,
 or develop their BSP footnote:[BSP: Board Support Package] or
 SDK footnote:[SDK: Software Development Kit] on top of Buildroot.
+
+What is Buildroot and what it is not
+------------------------------------
+
+Buildroot is:
+
+* a community-driven project
+* a tool uses in the industry
+* Buildroot targets embedded, rather small, often headless, devices
+
+
+Buildroot is *not*:
+
+* a _classic Linux-based distribution_, this means:
+
+** Buildroot root-filesystems are not managed by any package manager,
+   this means there is no way to update only one package of a root-filesystem
+   built by Buildroot without regenerating the whole root-filesystem;
+** Buildroot does not keep track of each package's content;
+** Buildroot does not provide as many packages as others distributions do;
+   so, some packages may be not available yet because the community does not
+   need them or think they are not suitable for embedded targets.
+
+* Root filesystem generated by Buildroot are not intend to be used for
+  native development; so they do not contain any development file (no header,
+  no static library, no native compiler for the target), nor documentation.
+
+Buildroot's principles
+----------------------
+
+* Easy to use
+* Quick build
+* Small footprint of the generated images footnote:[the smallness of the
+image footprint mostly depends on the target device and its application(s)]
+* Easy to hack
+* Being generic, but allowing customization:
+
+** Provide support for SoC, rather than board specific configuration (though
+Buildroot comes with a set of default configurations for a bunch of boards);
+** Provide default configuration that can be easily overriden.
-- 
1.8.4

[Buildroot] [PATCH 6/9] manual: introduction.txt: enhance Buildroot presentation

[Thomas De Schampheleire]

Hi Samuel,

On Sat, Oct 5, 2013 at 9:49 PM, Samuel Martin <s.martin49@gmail.com> wrote:
> * add a "What is Buildroot and what it is not" section
> * add a "Buildroot's principles" section
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
>  docs/manual/introduction.txt | 40 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>
> diff --git a/docs/manual/introduction.txt b/docs/manual/introduction.txt
> index c014565..0838c48 100644
> --- a/docs/manual/introduction.txt
> +++ b/docs/manual/introduction.txt
> @@ -25,3 +25,43 @@ comes with default configurations for several boards available
>  off-the-shelf. Besides this, a number of third-party projects are based on,
>  or develop their BSP footnote:[BSP: Board Support Package] or
>  SDK footnote:[SDK: Software Development Kit] on top of Buildroot.
> +
> +What is Buildroot and what it is not
> +------------------------------------

I think it should be ".. and what is it not" to match the first part
of the sentence.
An alternative would be "What Buildroot is and what it is not" but I
prefer the first one.

> +
> +Buildroot is:
> +
> +* a community-driven project
> +* a tool uses in the industry

used

> +* Buildroot targets embedded, rather small, often headless, devices

This does not match the list header:
Buildroot is Buildroot targets embedded, ...


But I'm not sure this part is very useful: 'buildroot is a tool used
in the industry', but a drilling machine is also a tool used in the
industry.

Moreover, there already is an explanation of what buildroot is in the
'about buildroot' section earlier in this file. The interesting part
is mainly what it is _not_.

> +
> +
> +Buildroot is *not*:
> +
> +* a _classic Linux-based distribution_, this means:
> +
> +** Buildroot root-filesystems are not managed by any package manager,

Is this technically the right way to put it?
What about:
Buildroot does not use any package manager to populate the root filesystem,

> +   this means there is no way to update only one package of a root-filesystem
> +   built by Buildroot without regenerating the whole root-filesystem;
> +** Buildroot does not keep track of each package's content;
> +** Buildroot does not provide as many packages as others distributions do;
> +   so, some packages may be not available yet because the community does not

may not be available

> +   need them or think they are not suitable for embedded targets.

(the community) thinks

> +
> +* Root filesystem generated by Buildroot are not intend to be used for

filesystems
intended

and you are currently mixing the spelling 'root-filesystem' and 'root
filesystem'. My personal preference is 'root filesystem' or if written
in short 'rootfs'.

> +  native development; so they do not contain any development file (no header,
> +  no static library, no native compiler for the target), nor documentation.

I would put this in plural:
... any development files (no headers, no static libraries, no native
compiler for the target), ...

> +
> +Buildroot's principles
> +----------------------
> +
> +* Easy to use
> +* Quick build

This could be 'Fast to build' to match the first and fourth item's composition.

> +* Small footprint of the generated images footnote:[the smallness of the
> +image footprint mostly depends on the target device and its application(s)]
> +* Easy to hack
> +* Being generic, but allowing customization:
> +
> +** Provide support for SoC, rather than board specific configuration (though
> +Buildroot comes with a set of default configurations for a bunch of boards);
> +** Provide default configuration that can be easily overriden.
> --


Best regards,
Thomas

[Buildroot] [PATCH 7/9] manual: get-involved.txt: fix event order

[Samuel Martin]

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 docs/manual/get-involved.txt | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/docs/manual/get-involved.txt b/docs/manual/get-involved.txt
index 8515d34..49ab54c 100644
--- a/docs/manual/get-involved.txt
+++ b/docs/manual/get-involved.txt
@@ -84,6 +84,12 @@ Currently, this page is mainly used as a _todo-list_.
 Events
 ------
 
+Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - Brussels)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+* Announcement & agenda thread: http://lists.busybox.net/pipermail/buildroot/2012-January/049340.html[]
+* Report: http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html[]
+
 Buildroot Developer Days aside ELC-E 2012 (November 3-4, 2012 - Barcelona)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -94,8 +100,4 @@ Buildroot presentation at LSM 2012 (July 12-14, 2012 - Geneva)
 
 * Announcement: http://lists.busybox.net/pipermail/buildroot/2012-May/053845.html[]
 
-Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - Brussels)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* Announcement & agenda thread: http://lists.busybox.net/pipermail/buildroot/2012-January/049340.html[]
-* Report: http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html[]
-- 
1.8.4

[Buildroot] [PATCH 7/9] manual: get-involved.txt: fix event order

[Thomas De Schampheleire]

Hi Samuel,

On Sat, Oct 5, 2013 at 9:49 PM, Samuel Martin <s.martin49@gmail.com> wrote:
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
>  docs/manual/get-involved.txt | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/docs/manual/get-involved.txt b/docs/manual/get-involved.txt
> index 8515d34..49ab54c 100644
> --- a/docs/manual/get-involved.txt
> +++ b/docs/manual/get-involved.txt
> @@ -84,6 +84,12 @@ Currently, this page is mainly used as a _todo-list_.
>  Events
>  ------
>
> +Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - Brussels)
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +* Announcement & agenda thread: http://lists.busybox.net/pipermail/buildroot/2012-January/049340.html[]
> +* Report: http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html[]
> +
>  Buildroot Developer Days aside ELC-E 2012 (November 3-4, 2012 - Barcelona)
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> @@ -94,8 +100,4 @@ Buildroot presentation at LSM 2012 (July 12-14, 2012 - Geneva)
>
>  * Announcement: http://lists.busybox.net/pipermail/buildroot/2012-May/053845.html[]
>
> -Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - Brussels)
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -* Announcement & agenda thread: http://lists.busybox.net/pipermail/buildroot/2012-January/049340.html[]
> -* Report: http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html[]
> --

What is the meaning of 'aside' here ?
For me, aside means 'next to' in a spatial context.
In this case, I think we are rather talking about time, in the sense
that BDD are before or after the mentioned conference. I'm not sure if
there exists a word like aside/adjacent that can be used in a time
context, but otherwise we could use:

... prior to ...
... after ...

Best regards,
Thomas

[Buildroot] [PATCH 7/9] manual: get-involved.txt: fix event order

[Arnout Vandecappelle]

On 10/08/13 11:31, Thomas De Schampheleire wrote:
> Hi Samuel,
>
> On Sat, Oct 5, 2013 at 9:49 PM, Samuel Martin <s.martin49@gmail.com> wrote:
>> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
>> ---
>>   docs/manual/get-involved.txt | 10 ++++++----
>>   1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/docs/manual/get-involved.txt b/docs/manual/get-involved.txt
>> index 8515d34..49ab54c 100644
>> --- a/docs/manual/get-involved.txt
>> +++ b/docs/manual/get-involved.txt
>> @@ -84,6 +84,12 @@ Currently, this page is mainly used as a _todo-list_.
>>   Events
>>   ------
>>
>> +Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - Brussels)
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +* Announcement & agenda thread: http://lists.busybox.net/pipermail/buildroot/2012-January/049340.html[]
>> +* Report: http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html[]
>> +
>>   Buildroot Developer Days aside ELC-E 2012 (November 3-4, 2012 - Barcelona)
>>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> @@ -94,8 +100,4 @@ Buildroot presentation at LSM 2012 (July 12-14, 2012 - Geneva)
>>
>>   * Announcement: http://lists.busybox.net/pipermail/buildroot/2012-May/053845.html[]
>>
>> -Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - Brussels)
>> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> -* Announcement & agenda thread: http://lists.busybox.net/pipermail/buildroot/2012-January/049340.html[]
>> -* Report: http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html[]
>> --
>
> What is the meaning of 'aside' here ?
> For me, aside means 'next to' in a spatial context.
> In this case, I think we are rather talking about time, in the sense
> that BDD are before or after the mentioned conference. I'm not sure if
> there exists a word like aside/adjacent that can be used in a time
> context, but otherwise we could use:
>
> ... prior to ...
> ... after ...

  I think "alongside" is correct. Any native English speaker who can confirm?

  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

[Buildroot] [PATCH 7/9] manual: get-involved.txt: fix event order

[Ryan Barnett]

Arnout, Thomas D., Samuel, All,

Arnout Vandecappelle <arnout@mind.be> wrote on 10/08/2013 01:04:13 PM:

> On 10/08/13 11:31, Thomas De Schampheleire wrote:
> > Hi Samuel,
> >
> > On Sat, Oct 5, 2013 at 9:49 PM, Samuel Martin <s.martin49@gmail.com> 
wrote:
> >> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> >> ---
> >>   docs/manual/get-involved.txt | 10 ++++++----
> >>   1 file changed, 6 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/docs/manual/get-involved.txt 
b/docs/manual/get-involved.txt
> >> index 8515d34..49ab54c 100644
> >> --- a/docs/manual/get-involved.txt
> >> +++ b/docs/manual/get-involved.txt
> >> @@ -84,6 +84,12 @@ Currently, this page is mainly used as a 
_todo-list_.
> >>   Events
> >>   ------
> >>
> >> +Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - 
Brussels)
> >> 
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> +
> >> +* Announcement & agenda thread: http://lists.busybox.net/
> pipermail/buildroot/2012-January/049340.html[]
> >> +* Report: http://lists.busybox.net/pipermail/buildroot/2012-
> February/050371.html[]
> >> +
> >>   Buildroot Developer Days aside ELC-E 2012 (November 3-4, 2012 - 
Barcelona)
> >> 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >> @@ -94,8 +100,4 @@ Buildroot presentation at LSM 2012 (July 12-14, 
> 2012 - Geneva)
> >>
> >>   * Announcement: http://lists.busybox.net/pipermail/buildroot/
> 2012-May/053845.html[]
> >>
> >> -Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - 
Brussels)
> >> 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >> -* Announcement & agenda thread: http://lists.busybox.net/
> pipermail/buildroot/2012-January/049340.html[]
> >> -* Report: http://lists.busybox.net/pipermail/buildroot/2012-
> February/050371.html[]
> >> --
> >
> > What is the meaning of 'aside' here ?
> > For me, aside means 'next to' in a spatial context.
> > In this case, I think we are rather talking about time, in the sense
> > that BDD are before or after the mentioned conference. I'm not sure if
> > there exists a word like aside/adjacent that can be used in a time
> > context, but otherwise we could use:
> >
> > ... prior to ...
> > ... after ...
> 
>   I think "alongside" is correct. Any native English speaker who can 
confirm?

"alongside" would be correct. However, I would consider using "following"
since technically speaking the BDD happens after FOSDEM is done.

Another option is to use "co-located", as SELinux Developer Summit uses to 

describe their conferences - http://selinuxproject.org/page/Conferences
 
>   Regards,
>   Arnout

Thanks,
-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131008/444431db/attachment-0001.html>

[Buildroot] [PATCH 8/9] manual: update get-involved section

[Samuel Martin]

* add events from the html page to the list
* add "Buildroot material" section. This new section references material
  (video, slides, posters, etc) used during presentations about Buildroot.

Signed-off-by: Samuel Martin <s.martin49@gmail.com>

---
Let me know if I miss some events, or if you have some unreferenced
material urls or url fixes.

TIA,

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 docs/manual/get-involved.txt | 145 ++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 135 insertions(+), 10 deletions(-)

diff --git a/docs/manual/get-involved.txt b/docs/manual/get-involved.txt
index 49ab54c..27603a9 100644
--- a/docs/manual/get-involved.txt
+++ b/docs/manual/get-involved.txt
@@ -84,20 +84,145 @@ Currently, this page is mainly used as a _todo-list_.
 Events
 ------
 
-Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - Brussels)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Upcoming events
+~~~~~~~~~~~~~~~
+
+* Buildroot Developer Days aside ELC-E 2013 (October 26-27 2013 - Edinburgh, UK)
++
+Announcement and draft agenda of the event can also be found on:
++
+** http://lists.busybox.net/pipermail/buildroot/2013-May/072645.html[]
+** http://lists.busybox.net/pipermail/buildroot/2013-August/076560.html[]
+** http://elinux.org/Buildroot:DeveloperDaysELCE2013[]
+
+Latest events
+~~~~~~~~~~~~~
+
+* Lightning talks about 'Build system and Buildroot' at Kernel Recipes 2013
+  (September 24-25, 2013 - Paris, France)
+
+* GSoC participation (Summer 2013)
++
+For the fisrt time of of its life, Builldroot will participate to the Google
+Summer of Code 2013, by mentoring one student.
++
+This GSoC will mainly deal with improving support for ARM SoC multimedia features.
++
+** GSoC topic ideas: http://elinux.org/Buildroot:GSoC2013Ideas[]
+** GSoC project presentation: http://www.google-melange.com/gsoc/org/google/gsoc2013/buildroot[]
+
+* Buildroot technical showcase at ELC 2013 (February 20-21, 2013 - San Francisco, US)
++
+** Poster: http://free-electrons.com/~thomas/pub/buildroot-poster.png[]
+** Slides: http://free-electrons.com/~thomas/pub/buildroot-slides.pdf[]
+
+* Buildroot Developer Days aside FOSDEM 2013 (February 4-5, 2012 - Brussels, Belgium)
++
+A report from the recent Buildroot Developers Meeting is now
+http://lists.busybox.net/pipermail/buildroot/2013-February/067105.html[available].
++
+http://emlinews.net[Embedded Linux News] also has a
+http://www.emlinews.net/2013/02/buildroot-developers-meeting-report[writeup
+about the event], including photos.
++
+Announcement and report of the event can alsobe found on the
+http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013[related Wiki page].
++
+Once again, thanks to all the participants and to http://www.google.com[Google]
+for sponsoring the event.
+
+* Buildroot Developer Days aside ELC-E 2012 (November 3-4, 2012 - Barcelona, Spain)
++
+A report from the recent _Buildroot Developer Days_ meeting in Barcelona,
+Spain is now
+http://lists.busybox.net/pipermail/buildroot/2012-November/061558.html[available].
++
+Many thanks to all the participants, and a special thanks to Arnout
+Vandecappelle from http://mind.be[mind] for taking notes and Thomas Petazzoni
+from http://free-electrons.com[Free Electrons] for handling all the practical
+arrangements, and naturally our sponsors, http://www.fluendo.com[Fluendo] and
+http://www.synopsys.com[Synopsis].
++
+Announcement and report and draft agenda of the event can alsobe found on:
++
+** http://elinux.org/Buildroot:DeveloperDaysELCE2012[]
+** http://elinux.org/Buildroot#Buildroot_Developers_Meeting.2C_3-4_November_2012.2C_Barcelona_Spain[]
+
+* Buildroot presentation at LSM 2012 (July 12-14, 2012 - Geneva, Switzerland)
++
+** Announcement: http://lists.busybox.net/pipermail/buildroot/2012-May/053845.html[]
+
+* Buildroot presentation at ELC 2012 (February 15-17, 2012 - San Francisco, US)
++
+** Slides: http://elinux.org/images/9/9e/Buildroot2.pdf[]
+** Video: http://video.linux.com/videos/buildroot-a-nice-simple-and-efficient-embedded-linux-build-system[]
+
+* Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - Brussels, Belgium)
++
+** Announcement:
+*** http://lists.busybox.net/pipermail/buildroot/2012-January/049340.html[]
+*** http://free-electrons.com/blog/bdd-2012-brussels[]
+** Report: http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html[]
+
+* Buildroot presentation at ELC-E 2011 (October 26-28, 2011- Prague, Czech)
++
+** Slides: http://elinux.org/images/2/2a/Using-buildroot-real-project.pdf[]
+** Video:
+http://free-electrons.com/pub/video/2011/elce/elce-2011-petazzoni-buildroot-for-real-project.webm[full HD],
+ http://free-electrons.com/pub/video/2011/elce/elce-2011-petazzoni-buildroot-for-real-project-450p.webm[450x800]
+
+* Buildroot Developer Day aside ELC-E 2010 (October 29, 2010 - Cambridge, UK)
++
+** Announcement: http://lists.busybox.net/pipermail/buildroot/2010-September/037930.html[]
+
+* Buildroot presentation at FOSDEM 2010 (May 2, 2010 - Brussels, Belgium)
++
+** Presentation: http://fosdem.org/2010/schedule/events/emb_cross_build[Build Systems:
+Present & Future]
+** Slides: http://send-patches.org/news/20100211-1-FOSDEM-Crossdev-Workshop.pdf[]
+** Video: http://free-electrons.com/pub/video/2010/fosdem/fosdem2010-workshop-cross-build-systems.ogv[]
+
+* Buildroot Developer Day aside ELC-E 2009 (October 17, 2009 - Grenoble, France)
++
+The first _Buildroot Developer Day_ took place on Saturday, October 17th in
+Grenoble, France, just the day after Embedded Linux Conference Europe.
++
+This _Developer Day_ aims at allowing Buildroot developers to meet and exchange
+ideas on the project and its future.
++
+This _Developer Day_ took place thanks to the sponsoring of
+http://www.calao-systems.com[Calao Systems] and
+http://www.free-electrons.com[Free Electrons].
+
+[[material]]
+Buildroot material
+------------------
+
+Some regular contributors give talks about their works with Buildroot.
+
+Hereafter is a list of videos or slides or orther material used during these
+presentations.
 
-* Announcement & agenda thread: http://lists.busybox.net/pipermail/buildroot/2012-January/049340.html[]
-* Report: http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html[]
+[WARNING]
+Keep in mind that the information given in these documents may be outdated,
+refers to this manual for the latest and up-to-date information.
 
-Buildroot Developer Days aside ELC-E 2012 (November 3-4, 2012 - Barcelona)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+* ELC 2013: Technical Showcase
+** http://free-electrons.com/~thomas/pub/buildroot-poster.png[Poster]
+** http://free-electrons.com/~thomas/pub/buildroot-slides.pdf[Slides]
 
-* Event page: http://elinux.org/Buildroot:DeveloperDaysELCE2012[]
+* ELC 2012: Buildroot: A nice, simple and efficient embedde Linux build system
+** http://elinux.org/images/9/9e/Buildroot2.pdf[Slides]
+** http://video.linux.com/videos/buildroot-a-nice-simple-and-efficient-embedded-linux-build-system[Video]
 
-Buildroot presentation at LSM 2012 (July 12-14, 2012 - Geneva)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+* ELC-E 2011: Using Buildroot in real projects
+** http://elinux.org/images/2/2a/Using-buildroot-real-project.pdf[Slides]
+** Videos:
+http://free-electrons.com/pub/video/2011/elce/elce-2011-petazzoni-buildroot-for-real-project.webm[full HD],
+ http://free-electrons.com/pub/video/2011/elce/elce-2011-petazzoni-buildroot-for-real-project-450p.webm[450x800]
 
-* Announcement: http://lists.busybox.net/pipermail/buildroot/2012-May/053845.html[]
+* FOSDEM 2010: Build Systems: Present & Future
+** http://send-patches.org/news/20100211-1-FOSDEM-Crossdev-Workshop.pdf[Slides]
+** http://free-electrons.com/pub/video/2010/fosdem/fosdem2010-workshop-cross-build-systems.ogv[Video]
 
 
-- 
1.8.4

[Buildroot] [PATCH 8/9] manual: update get-involved section

[Thomas De Schampheleire]

On Sat, Oct 5, 2013 at 9:49 PM, Samuel Martin <s.martin49@gmail.com> wrote:
> * add events from the html page to the list
> * add "Buildroot material" section. This new section references material
>   (video, slides, posters, etc) used during presentations about Buildroot.
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
>
> ---
> Let me know if I miss some events, or if you have some unreferenced
> material urls or url fixes.
>
> TIA,
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
>  docs/manual/get-involved.txt | 145 ++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 135 insertions(+), 10 deletions(-)
>
> diff --git a/docs/manual/get-involved.txt b/docs/manual/get-involved.txt
> index 49ab54c..27603a9 100644
> --- a/docs/manual/get-involved.txt
> +++ b/docs/manual/get-involved.txt
> @@ -84,20 +84,145 @@ Currently, this page is mainly used as a _todo-list_.
>  Events
>  ------
>
> -Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - Brussels)
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +Upcoming events
> +~~~~~~~~~~~~~~~
> +
> +* Buildroot Developer Days aside ELC-E 2013 (October 26-27 2013 - Edinburgh, UK)

comma before the year

> ++
> +Announcement and draft agenda of the event can also be found on:
> ++
> +** http://lists.busybox.net/pipermail/buildroot/2013-May/072645.html[]
> +** http://lists.busybox.net/pipermail/buildroot/2013-August/076560.html[]
> +** http://elinux.org/Buildroot:DeveloperDaysELCE2013[]
> +
> +Latest events
> +~~~~~~~~~~~~~
> +
> +* Lightning talks about 'Build system and Buildroot' at Kernel Recipes 2013
> +  (September 24-25, 2013 - Paris, France)
> +
> +* GSoC participation (Summer 2013)
> ++
> +For the fisrt time of of its life, Builldroot will participate to the Google

first
of of --> of
Buildroot

> +Summer of Code 2013, by mentoring one student.
> ++
> +This GSoC will mainly deal with improving support for ARM SoC multimedia features.
> ++
> +** GSoC topic ideas: http://elinux.org/Buildroot:GSoC2013Ideas[]
> +** GSoC project presentation: http://www.google-melange.com/gsoc/org/google/gsoc2013/buildroot[]
> +
> +* Buildroot technical showcase at ELC 2013 (February 20-21, 2013 - San Francisco, US)
> ++
> +** Poster: http://free-electrons.com/~thomas/pub/buildroot-poster.png[]
> +** Slides: http://free-electrons.com/~thomas/pub/buildroot-slides.pdf[]
> +
> +* Buildroot Developer Days aside FOSDEM 2013 (February 4-5, 2012 - Brussels, Belgium)
> ++
> +A report from the recent Buildroot Developers Meeting is now
> +http://lists.busybox.net/pipermail/buildroot/2013-February/067105.html[available].
> ++
> +http://emlinews.net[Embedded Linux News] also has a
> +http://www.emlinews.net/2013/02/buildroot-developers-meeting-report[writeup
> +about the event], including photos.
> ++
> +Announcement and report of the event can alsobe found on the

also be

> +http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013[related Wiki page].
> ++
> +Once again, thanks to all the participants and to http://www.google.com[Google]
> +for sponsoring the event.
> +
> +* Buildroot Developer Days aside ELC-E 2012 (November 3-4, 2012 - Barcelona, Spain)
> ++
> +A report from the recent _Buildroot Developer Days_ meeting in Barcelona,
> +Spain is now
> +http://lists.busybox.net/pipermail/buildroot/2012-November/061558.html[available].
> ++
> +Many thanks to all the participants, and a special thanks to Arnout
> +Vandecappelle from http://mind.be[mind] for taking notes and Thomas Petazzoni
> +from http://free-electrons.com[Free Electrons] for handling all the practical
> +arrangements, and naturally our sponsors, http://www.fluendo.com[Fluendo] and
> +http://www.synopsys.com[Synopsis].
> ++
> +Announcement and report and draft agenda of the event can alsobe found on:

Announcement, report and draft agenda
also be

> ++
> +** http://elinux.org/Buildroot:DeveloperDaysELCE2012[]
> +** http://elinux.org/Buildroot#Buildroot_Developers_Meeting.2C_3-4_November_2012.2C_Barcelona_Spain[]
> +
> +* Buildroot presentation at LSM 2012 (July 12-14, 2012 - Geneva, Switzerland)
> ++
> +** Announcement: http://lists.busybox.net/pipermail/buildroot/2012-May/053845.html[]
> +
> +* Buildroot presentation at ELC 2012 (February 15-17, 2012 - San Francisco, US)
> ++
> +** Slides: http://elinux.org/images/9/9e/Buildroot2.pdf[]
> +** Video: http://video.linux.com/videos/buildroot-a-nice-simple-and-efficient-embedded-linux-build-system[]
> +
> +* Buildroot Developer Days aside FOSDEM 2012 (February 3, 2012 - Brussels, Belgium)
> ++
> +** Announcement:
> +*** http://lists.busybox.net/pipermail/buildroot/2012-January/049340.html[]
> +*** http://free-electrons.com/blog/bdd-2012-brussels[]
> +** Report: http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html[]
> +
> +* Buildroot presentation at ELC-E 2011 (October 26-28, 2011- Prague, Czech)
> ++
> +** Slides: http://elinux.org/images/2/2a/Using-buildroot-real-project.pdf[]
> +** Video:
> +http://free-electrons.com/pub/video/2011/elce/elce-2011-petazzoni-buildroot-for-real-project.webm[full HD],
> + http://free-electrons.com/pub/video/2011/elce/elce-2011-petazzoni-buildroot-for-real-project-450p.webm[450x800]
> +
> +* Buildroot Developer Day aside ELC-E 2010 (October 29, 2010 - Cambridge, UK)
> ++
> +** Announcement: http://lists.busybox.net/pipermail/buildroot/2010-September/037930.html[]
> +
> +* Buildroot presentation at FOSDEM 2010 (May 2, 2010 - Brussels, Belgium)
> ++
> +** Presentation: http://fosdem.org/2010/schedule/events/emb_cross_build[Build Systems:
> +Present & Future]
> +** Slides: http://send-patches.org/news/20100211-1-FOSDEM-Crossdev-Workshop.pdf[]
> +** Video: http://free-electrons.com/pub/video/2010/fosdem/fosdem2010-workshop-cross-build-systems.ogv[]
> +
> +* Buildroot Developer Day aside ELC-E 2009 (October 17, 2009 - Grenoble, France)
> ++
> +The first _Buildroot Developer Day_ took place on Saturday, October 17th in
> +Grenoble, France, just the day after Embedded Linux Conference Europe.
> ++
> +This _Developer Day_ aims at allowing Buildroot developers to meet and exchange
> +ideas on the project and its future.
> ++
> +This _Developer Day_ took place thanks to the sponsoring of
> +http://www.calao-systems.com[Calao Systems] and
> +http://www.free-electrons.com[Free Electrons].
> +
> +[[material]]
> +Buildroot material
> +------------------
> +
> +Some regular contributors give talks about their works with Buildroot.

What exactly do you mean with 'their works'? I don't think this is
correct English.
Maybe you mean:
'about their experience with Buildroot'
or
'about how they use Buildroot at work'
?

> +
> +Hereafter is a list of videos or slides or orther material used during these
> +presentations.
>
> -* Announcement & agenda thread: http://lists.busybox.net/pipermail/buildroot/2012-January/049340.html[]
> -* Report: http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html[]
> +[WARNING]
> +Keep in mind that the information given in these documents may be outdated,
> +refers to this manual for the latest and up-to-date information.

refer

>
> -Buildroot Developer Days aside ELC-E 2012 (November 3-4, 2012 - Barcelona)
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +* ELC 2013: Technical Showcase
> +** http://free-electrons.com/~thomas/pub/buildroot-poster.png[Poster]
> +** http://free-electrons.com/~thomas/pub/buildroot-slides.pdf[Slides]
>
> -* Event page: http://elinux.org/Buildroot:DeveloperDaysELCE2012[]
> +* ELC 2012: Buildroot: A nice, simple and efficient embedde Linux build system

embedded

> +** http://elinux.org/images/9/9e/Buildroot2.pdf[Slides]
> +** http://video.linux.com/videos/buildroot-a-nice-simple-and-efficient-embedded-linux-build-system[Video]
>
> -Buildroot presentation at LSM 2012 (July 12-14, 2012 - Geneva)
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +* ELC-E 2011: Using Buildroot in real projects
> +** http://elinux.org/images/2/2a/Using-buildroot-real-project.pdf[Slides]
> +** Videos:
> +http://free-electrons.com/pub/video/2011/elce/elce-2011-petazzoni-buildroot-for-real-project.webm[full HD],
> + http://free-electrons.com/pub/video/2011/elce/elce-2011-petazzoni-buildroot-for-real-project-450p.webm[450x800]
>
> -* Announcement: http://lists.busybox.net/pipermail/buildroot/2012-May/053845.html[]
> +* FOSDEM 2010: Build Systems: Present & Future
> +** http://send-patches.org/news/20100211-1-FOSDEM-Crossdev-Workshop.pdf[Slides]
> +** http://free-electrons.com/pub/video/2010/fosdem/fosdem2010-workshop-cross-build-systems.ogv[Video]
>
>

Best regards,
Thomas

[Buildroot] [PATCH 9/9] manual: rework Deploying images chapter

[Samuel Martin]

Add details about how to deploy images generated by Buildroot on real
hardware, emulator or VM, over network (TFTP, NFS, PXE).

Signed-off-by: A.R.D. <contact@team-ard.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>

---
changes v2 -> v3:
- typos and minor rewordings (Thomas De S. and Arnout V.)
- typos + formating fixes + minor rewordings
- rename beyond-buildroot.txt -> deploying-images.txt
- move booting image chapter as chapter #4
- add missing NFS links
- enhance NFS boot section
- add section about TFTP boot
- add section about preparing custom disk image

changes v1 -> v2 (Samuel):
- split patch
- rephrase commit message
- wrap line at 70-80 chars
- misc. typo and formating fixes
- misc. rewordings
- re-order the "Network boot" section
- add a word about qemu targets
- enhance section about disk image generation
- enhance section about NFS boot + add links
- keep "Beyond Buildroot" at the end of the manual
- add cross-refs to "Beyond Buildroot"

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 docs/manual/beyond-buildroot.txt |  41 ------
 docs/manual/deploying-images.txt | 290 +++++++++++++++++++++++++++++++++++++++
 docs/manual/manual.txt           |   4 +-
 docs/manual/using.txt            |   3 +-
 4 files changed, 294 insertions(+), 44 deletions(-)
 delete mode 100644 docs/manual/beyond-buildroot.txt
 create mode 100644 docs/manual/deploying-images.txt

diff --git a/docs/manual/beyond-buildroot.txt b/docs/manual/beyond-buildroot.txt
deleted file mode 100644
index a0d4af0..0000000
--- a/docs/manual/beyond-buildroot.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-// -*- mode:doc; -*-
-// vim: set syntax=asciidoc:
-
-Beyond Buildroot
-================
-
-Boot the generated images
--------------------------
-
-NFS boot
-~~~~~~~~
-
-To achieve NFS-boot, enable _tar root filesystem_ in the _Filesystem
-images_ menu.
-
-After a complete build, just run the following commands to setup the
-NFS-root directory:
-
--------------------
-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.
-
-Chroot
-------
-
-If you want to chroot in a generated image, then there are few thing
-you should be aware of:
-
-* you should setup the new root from the _tar root filesystem_ image;
-
-* either the selected target architecture is compatible with your host
-  machine, or you should use some +qemu-*+ binary and correctly set it
-  within the +binfmt+ properties to be able to run the binaries built
-  for the target on your host machine;
-
-* Buildroot does not currently provide +host-qemu+ and +binfmt+
-  correctly built and set for that kind of use.
diff --git a/docs/manual/deploying-images.txt b/docs/manual/deploying-images.txt
new file mode 100644
index 0000000..ad77f09
--- /dev/null
+++ b/docs/manual/deploying-images.txt
@@ -0,0 +1,290 @@
+// -*- mode:doc; -*-
+// vim: set syntax=asciidoc:
+
+[[deploying-images]]
+Deploying target images built with Buildroot
+============================================
+
+After having run Buildroot, you will have a brand new filesystem for
+your target exported in the 'output/images' directory.
+The content of this directory depends on the selected options in the
+Buildroot configuration, especially those from the +Filesystem images+
+sub-menu.
+
+So what's next? You will probably want to :
+
+* deploy and/or install the freshly built images on the target to boot
+  and test it;
+
+* boot and test the images in emulators (http://wiki.qemu.org/Main_Page[Qemu],
+  http://www.linaro.org/engineering/engineering-projects/armv8[Foundation_v8]
+  --- a AArch64 emulator, ...);
+
+* generate a virtual disk to dump to real system or to use in
+  virtualization systems (http://wiki.qemu.org/Main_Page[Qemu],
+  https://www.virtualbox.org/[VirtualBox], ...).
+  This is mostly useful for 'x86' and 'x86_64' targets.
+
+This part of the work is really depending on each project and
+hardware, so we cannot describe every solutions here. This is where
+Buildroot's work ends.
+
+For some of the off-the-shelf boards that Buildroot supports, you can
+find a specific explanation in a readme file in the _board_ directory.
+
+This chapter aims at guiding new users on what to do next to avoid
+staying in the dark.
+
+This is *not* an exact guide on how to precisely do what is described.
+Please take the time to have a look to referred projets to get those
+details.
+
+
+Deploying images on the target hardware
+---------------------------------------
+
+Buildroot comes with a set of minimal configurations for allowing to
+boot various existing targets, from different vendors.
+
+All these configurations are stored in the 'configs/' directory.
+Most of these configurations also come with a directory:
+'board/<vendor name>/<platform name>', for additional resources.
+Some of them also contain a +readme.txt+ file with information about
+flashing and/or booting the given platform.
+
+Although, deploying the generated images on the actual hardware
+(flashing and booting the hardware) is very tight to the target
+hardware and can differ a lot from one target to another.
+Buildroot cannot provide information on this part.
+
+For deploying images on the actual target, refer to the hardware
+vendor instructions, or the readme file in the _board_ directory if
+any.
+
+[WARNING]
+Be careful, *the _board's_ readme files coming within Buildroot are
+provided without warranty of any kind*.
+They are contributions from Buildroot users, but Buildroot developers
+do not ensure their correctness, nor maintain them.
+
+
+Booting images in emulators
+---------------------------
+
+Buildroot comes with a set of configurations for various
+architectures running in http://wiki.qemu.org/Main_Page['Qemu'], or
+http://www.linaro.org/engineering/engineering-projects/armv8['Foundation_v8']
+(an AArch64 emulator).
+
+These configurations are stored under the 'board/qemu/<target name>'
+directory.
+
+Each of these configurations has a 'defconfig' and comes with a
++readme.txt+ file providing details to use the built images with
+'Qemu'.
+
+They are regularly tested and maintained by the Buildroot core
+developers.
+
+If you built one of these configurations and have 'Qemu' or
+'Foundation_v8' installed on your host machine, booting the images
+should be straight forward.
+
+
+Preparing a raw disk image for customized target layout
+-------------------------------------------------------
+
+This case is close to booting the actual hardware, so Buildroot
+cannot provides any information how to achieve it for every single
+target.
+
+However, Buildroot provides _host-tools_ that may help generating
+customized disk images, see the 'Host utilities' menu.
+
+[NOTE]
+Some of these tools are not really well documented, you may need to
+browse the source trees to find out how to use them.
+
+
+Preparing a bootable raw disk file for virtualization
+-----------------------------------------------------
+
+[NOTE]
+This section is mostly x86 target specific.
+
+If you plan to use virtual machines, or to copy a binary bootable
+image to your target, you may need to create a _disk image_.
+
+To create a bootable raw _disk image_ file, you will need to:
+
+* create an empty file with the +dd+ command;
+
+* edit the partition table of this _disk image_ file using some tools
+  like +fdisk+ (be carefull when using +fdisk+; mis-usage can damage
+  the host machine. Look at its manpage before using it;
+
+* install the MBR;
+
+* create nodes in +/dev+ pointing to the _disk image_ and its
+  partitions (as you will have with +/dev/sda+, +/dev/sda1+,
+  +/dev/sda2+, etc) with
+  http://robert.penz.name/73/kpartx-a-tool-for-mounting-partitions-within-an-image-file/[kpartx];
+
+* mount one or several partitions of the _disk image_ with the +mount+
+  command;
+
+* populate the root partition by extracting into it the
+  root-filesystem tarball generated by Buildroot.
+
+
+Booting the generated image over the network
+--------------------------------------------
+
+It is common to boot the target over the network when dealing with
+embedded devices, whatever the reasons could be:
+
+* to speed-up the in-progress images test during the development
+  phase;
+* to avoid premature wear or the flash memory devices;
+* to deploy the actual production images on the hardawre;
+* or because the target is not equiped with memory storage;
+* ...
+
+To achieve network-boot, there are several methods that depend on both
+the facility network infrastructure and the targets. Among these, the
+most common are:
+
+* TFTP boot
+* NFS boot
+* PXE boot (x86-specific)
+
+
+TFTP boot
+~~~~~~~~~
+
+Depending on the bootloader installed on the target, it may be
+possible to download the kernel image through the newtork, using TFTP
+protocole, loading it in RAM, then jump into it.
+
+For further information, refer to the bootloader documentation.
+
+Here is some related documentation to TFTP server setup and TFTP boot:
+
+* http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch16_:_Telnet,_TFTP,_and_xinetd#TFTP
+* https://linuxlink.timesys.com/docs/linux_tftp
+* http://www.webune.com/forums/how-to-install-tftp-server-in-linux.html
+
+
+NFS boot
+~~~~~~~~
+
+Loading the kernel over NFS
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Depending on the bootloader installed on the target, it may be
+possible to download the kernel image through the newtork, using NFS
+protocole, loading it in RAM, then jump into it.
+
+For further information, refer to the bootloader documentation.
+
+[[deploying-images-nfs-links]]
+Here is some related documentation to NFS server setup and NFS boot:
+
+* http://tldp.org/HOWTO/NFS-HOWTO/index.html
+* https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
+* https://wiki.archlinux.org/index.php/NFS
+* http://www.solid-run.com/mw/index.php/Setup_NFS_boot
+* http://wiki.openelec.tv/index.php?title=Network_Boot_-_NFS
+* http://www.armadeus.com/wiki/index.php?title=NFS
+
+NFS root filesystem mounted on +/+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The idea is to mount +/+ using a network shared folder from an
+http://tldp.org/HOWTO/NFS-HOWTO/index.html[NFS] server
+(usually on the host development machine).
+
+To enable the NFS boot, you should select the _tar root filesystem_
+option in the _Filesystem images_ submenu.
+
+The embedded kernel needs at least the following options:
+
+* 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. This includes:
+
+  * +CONFIG_IP_PNP+;
+  * +CONFIG_IP_PNP_BOOTTP+;
+  * +CONFIG_IP_PNP_DHCP+.
+
+After a complete build, just run the following command to setup the
+NFS root directory on the server:
+
+-------------------
+sudo tar -xavf /path/to/output_dir/rootfs.tar -C /path/to/nfs_root_dir
+-------------------
+
+Make sure the NFS root location appears in the +/etc/exports+ file,
+and an _NFS_ daemon is running on the server.
+
+After editing +/etc/exports+, you should run:
+
+-------------------
+sudo exportfs -ra
+-------------------
+
+To boot on a NFS root-filesystem, adjust the kernel command line
+parameters (see https://www.kernel.org/doc/Documentation/kernel-parameters.txt
+and the xref:deploying-images-nfs-links[above links]).
+
+For further information, refer to the
+xref:deploying-images-nfs-links[above links].
+
+
+Network PXE bootloader
+~~~~~~~~~~~~~~~~~~~~~~
+
+[NOTE]
+This section is mostly x86 target specific.
+
+To fully boot on the network you need a network bootloader. This is
+optional and you could use your classic bootloader to mount an 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 TFTP server.
+Then your target boots with it and comes back to the TFTP server to get
+the specific stuff (for instance its boot menu).
+
+Here are some hints on how to setup this:
+
+* http://www.digitalpeer.com/id/linuxnfs
+
+
+Chroot into generated image
+---------------------------
+
+If you want to 'chroot' in a generated image, then there are few things
+you should be aware of:
+
+* you should setup the new root from the _tar root filesystem_ image;
+
+* either the selected target architecture is compatible with your host
+  machine, or you should use some +qemu-*+ binary and correctly set it
+  within the +binfmt+ properties to be able to run the binaries built
+  for the target on your host machine;
+
+* Buildroot does not currently provide +host-qemu+ nor +binfmt+
+  correctly built and set for that kind of use. This usage is beyond
+  Buildroot scope.
diff --git a/docs/manual/manual.txt b/docs/manual/manual.txt
index 9685667..8fcb2c2 100644
--- a/docs/manual/manual.txt
+++ b/docs/manual/manual.txt
@@ -21,6 +21,8 @@ include::starting-up.txt[]
 
 include::working-with.txt[]
 
+include::deploying-images.txt[]
+
 include::faq-troubleshooting.txt[]
 
 include::going-further.txt[]
@@ -29,8 +31,6 @@ include::developer-guide.txt[]
 
 include::legal-notice.txt[]
 
-include::beyond-buildroot.txt[]
-
 include::get-involved.txt[]
 
 include::contribute.txt[]
diff --git a/docs/manual/using.txt b/docs/manual/using.txt
index de29ad6..783370d 100644
--- a/docs/manual/using.txt
+++ b/docs/manual/using.txt
@@ -67,7 +67,8 @@ Buildroot output is stored in a single directory, +output/+.
 This directory contains several subdirectories:
 
 * +images/+ where all the images (kernel image, bootloader and root
-  filesystem images) are stored.
+  filesystem images) are stored. For further details for using/booting
+  the images, refer to xref:deploying-images[].
 
 * +build/+ where all the components except for the cross-compilation
   toolchain are built (this includes tools needed to run Buildroot on
-- 
1.8.4

[Buildroot] [PATCH 9/9] manual: rework Deploying images chapter

[Arnout Vandecappelle]

On 10/05/13 21:49, Samuel Martin wrote:
> Add details about how to deploy images generated by Buildroot on real
> hardware, emulator or VM, over network (TFTP, NFS, PXE).
>
> Signed-off-by: A.R.D. <contact@team-ard.com>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>

  Some more spelling corrections:

>
> ---
> changes v2 -> v3:
> - typos and minor rewordings (Thomas De S. and Arnout V.)
> - typos + formating fixes + minor rewordings
> - rename beyond-buildroot.txt -> deploying-images.txt
> - move booting image chapter as chapter #4
> - add missing NFS links
> - enhance NFS boot section
> - add section about TFTP boot
> - add section about preparing custom disk image
>
> changes v1 -> v2 (Samuel):
> - split patch
> - rephrase commit message
> - wrap line at 70-80 chars
> - misc. typo and formating fixes
> - misc. rewordings
> - re-order the "Network boot" section
> - add a word about qemu targets
> - enhance section about disk image generation
> - enhance section about NFS boot + add links
> - keep "Beyond Buildroot" at the end of the manual
> - add cross-refs to "Beyond Buildroot"
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
>   docs/manual/beyond-buildroot.txt |  41 ------
>   docs/manual/deploying-images.txt | 290 +++++++++++++++++++++++++++++++++++++++
>   docs/manual/manual.txt           |   4 +-
>   docs/manual/using.txt            |   3 +-
>   4 files changed, 294 insertions(+), 44 deletions(-)
>   delete mode 100644 docs/manual/beyond-buildroot.txt
>   create mode 100644 docs/manual/deploying-images.txt
>
> diff --git a/docs/manual/beyond-buildroot.txt b/docs/manual/beyond-buildroot.txt
> deleted file mode 100644
> index a0d4af0..0000000
> --- a/docs/manual/beyond-buildroot.txt
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -// -*- mode:doc; -*-
> -// vim: set syntax=asciidoc:
> -
> -Beyond Buildroot
> -================
> -
> -Boot the generated images
> --------------------------
> -
> -NFS boot
> -~~~~~~~~
> -
> -To achieve NFS-boot, enable _tar root filesystem_ in the _Filesystem
> -images_ menu.
> -
> -After a complete build, just run the following commands to setup the
> -NFS-root directory:
> -
> --------------------
> -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.
> -
> -Chroot
> -------
> -
> -If you want to chroot in a generated image, then there are few thing
> -you should be aware of:
> -
> -* you should setup the new root from the _tar root filesystem_ image;
> -
> -* either the selected target architecture is compatible with your host
> -  machine, or you should use some +qemu-*+ binary and correctly set it
> -  within the +binfmt+ properties to be able to run the binaries built
> -  for the target on your host machine;
> -
> -* Buildroot does not currently provide +host-qemu+ and +binfmt+
> -  correctly built and set for that kind of use.
> diff --git a/docs/manual/deploying-images.txt b/docs/manual/deploying-images.txt
> new file mode 100644
> index 0000000..ad77f09
> --- /dev/null
> +++ b/docs/manual/deploying-images.txt
> @@ -0,0 +1,290 @@
> +// -*- mode:doc; -*-
> +// vim: set syntax=asciidoc:
> +
> +[[deploying-images]]
> +Deploying target images built with Buildroot
> +============================================
> +
> +After having run Buildroot, you will have a brand new filesystem for

  kernel, bootloader and filesystem?

> +your target exported in the 'output/images' directory.
> +The content of this directory depends on the selected options in the
> +Buildroot configuration, especially those from the +Filesystem images+
> +sub-menu.

  +Kernel+, +filesystem images+ and +bootloaders+ menus (they're not 
sub-menus).

> +
> +So what's next? You will probably want to :

  You probably want to do one of the following.

* Copy and install the images on the target device to boot and test it.

* Write the images to removable media that can be booted on the target
   device.

* Boot and test the images...

> +
> +* deploy and/or install the freshly built images on the target to boot
> +  and test it;
> +
> +* boot and test the images in emulators (http://wiki.qemu.org/Main_Page[Qemu],
> +  http://www.linaro.org/engineering/engineering-projects/armv8[Foundation_v8]
> +  --- a AArch64 emulator, ...);

  an AArch64 emulator

> +
> +* generate a virtual disk to dump to real system or to use in
> +  virtualization systems (http://wiki.qemu.org/Main_Page[Qemu],
> +  https://www.virtualbox.org/[VirtualBox], ...).
> +  This is mostly useful for 'x86' and 'x86_64' targets.

  'i386' and 'x86_64' target architectures.

> +
> +This part of the work is really depending on each project and
> +hardware, so we cannot describe every solutions here. This is where
> +Buildroot's work ends.
> +
> +For some of the off-the-shelf boards that Buildroot supports, you can
> +find a specific explanation in a readme file in the _board_ directory.
> +
> +This chapter aims at guiding new users on what to do next to avoid
> +staying in the dark.
> +
> +This is *not* an exact guide on how to precisely do what is described.
> +Please take the time to have a look to referred projets to get those
> +details.

  These six sentences should be one paragraph rather than four. There's 
also a bit of redundancy. Together with a little rephrasing and spelling 
correction that becomes:

This part of the work is really depending on each project and hardware,
so we cannot describe every solution here. This is where Buildroot's
work ends. The rest of this chapter gives some general examples and
hints about how the images can be deployed to the target device. This is
_not_ an exact guide and doesn't provide full details. Please take the
time to have a look to referred projects to get those details.


> +
> +
> +Deploying images on the target hardware
> +---------------------------------------
> +
> +Buildroot comes with a set of minimal configurations for allowing to

  that allow

> +boot various existing targets, from different vendors.
> +
> +All these configurations are stored in the 'configs/' directory.
> +Most of these configurations also come with a directory:

  Remove the :

> +'board/<vendor name>/<platform name>', for additional resources.
> +Some of them also contain a +readme.txt+ file with information about

  'readme.txt'

> +flashing and/or booting the given platform.
> +
> +Although, deploying the generated images on the actual hardware
> +(flashing and booting the hardware) is very tight to the target
> +hardware and can differ a lot from one target to another.
> +Buildroot cannot provide information on this part.
> +
> +For deploying images on the actual target, refer to the hardware
> +vendor instructions, or the readme file in the _board_ directory if
> +any.

  I don't like how these two paragraphs are formulated, but I can't 
readily think of an improvement.

> +
> +[WARNING]
> +Be careful, *the _board's_ readme files coming within Buildroot are
> +provided without warranty of any kind*.
> +They are contributions from Buildroot users, but Buildroot developers
> +do not ensure their correctness, nor maintain them.

  Is this warning really necessary? Most readme.txt files use removable 
media (or emulation), and the few that do write to flash have warnings 
already. The only exception is the Telit EVK-PRO3, so maybe we should 
just add a warning there.

> +
> +
> +Booting images in emulators
> +---------------------------
> +
> +Buildroot comes with a set of configurations for various
> +architectures running in http://wiki.qemu.org/Main_Page['Qemu'], or
> +http://www.linaro.org/engineering/engineering-projects/armv8['Foundation_v8']
> +(an AArch64 emulator).
> +
> +These configurations are stored under the 'board/qemu/<target name>'
> +directory.

  The armv8 one is under board/arm/foundation-v8.

> +
> +Each of these configurations has a 'defconfig' and comes with a
> ++readme.txt+ file providing details to use the built images with
> +'Qemu'.
> +
> +They are regularly tested and maintained by the Buildroot core
> +developers.
> +
> +If you built one of these configurations and have 'Qemu' or
> +'Foundation_v8' installed on your host machine, booting the images
> +should be straight forward.
> +
> +
> +Preparing a raw disk image for customized target layout

  Preparing bootable removable media

> +-------------------------------------------------------
> +
> +This case is close to booting the actual hardware, so Buildroot
> +cannot provides any information how to achieve it for every single
> +target.

How the target device is close to the actual hardware, so Buildroot
cannot explain how to achieve it for every single target. For boards
that use the same processor as one of the boards supported by Buildroot,
the 'readme.txt' can be a good starting point.

> +
> +However, Buildroot provides _host-tools_ that may help generating
> +customized disk images, see the 'Host utilities' menu.

In addition, Buildroot provides tools that run on your host that can help
generating bootable media or booting a device over USB, serial or the
network.

> +
> +[NOTE]
> +Some of these tools are not really well documented, you may need to
> +browse the source trees to find out how to use them.
> +
> +
> +Preparing a bootable raw disk file for virtualization
> +-----------------------------------------------------
> +
> +[NOTE]
> +This section is mostly x86 target specific.
> +
> +If you plan to use virtual machines, or to copy a binary bootable
> +image to your target, you may need to create a _disk image_.
> +
> +To create a bootable raw _disk image_ file, you will need to:
> +
> +* create an empty file with the +dd+ command;
> +
> +* edit the partition table of this _disk image_ file using some tools
> +  like +fdisk+ (be carefull when using +fdisk+; mis-usage can damage

  careful

> +  the host machine. Look at its manpage before using it;
> +
> +* install the MBR;
> +
> +* create nodes in +/dev+ pointing to the _disk image_ and its
> +  partitions (as you will have with +/dev/sda+, +/dev/sda1+,
> +  +/dev/sda2+, etc) with
> +  http://robert.penz.name/73/kpartx-a-tool-for-mounting-partitions-within-an-image-file/[kpartx];
> +
> +* mount one or several partitions of the _disk image_ with the +mount+
> +  command;
> +
> +* populate the root partition by extracting into it the
> +  root-filesystem tarball generated by Buildroot.
> +
> +
> +Booting the generated image over the network
> +--------------------------------------------
> +
> +It is common to boot the target over the network when dealing with
> +embedded devices, whatever the reasons could be:
> +
> +* to speed-up the in-progress images test during the development
> +  phase;
> +* to avoid premature wear or the flash memory devices;
> +* to deploy the actual production images on the hardawre;

  hardware

> +* or because the target is not equiped with memory storage;

  equipped

> +* ...
> +
> +To achieve network-boot, there are several methods that depend on both
> +the facility network infrastructure and the targets. Among these, the
> +most common are:
> +
> +* TFTP boot
> +* NFS boot
> +* PXE boot (x86-specific)
> +
> +
> +TFTP boot
> +~~~~~~~~~
> +
> +Depending on the bootloader installed on the target, it may be
> +possible to download the kernel image through the newtork, using TFTP

  network

> +protocole, loading it in RAM, then jump into it.

  the TFTP protocol

> +
> +For further information, refer to the bootloader documentation.
> +
> +Here is some related documentation to TFTP server setup and TFTP boot:
> +
> +* http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch16_:_Telnet,_TFTP,_and_xinetd#TFTP
> +* https://linuxlink.timesys.com/docs/linux_tftp
> +* http://www.webune.com/forums/how-to-install-tftp-server-in-linux.html
> +
> +
> +NFS boot
> +~~~~~~~~
> +
> +Loading the kernel over NFS
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Depending on the bootloader installed on the target, it may be
> +possible to download the kernel image through the newtork, using NFS

  network

> +protocole, loading it in RAM, then jump into it.

  the NFS protocol

> +
> +For further information, refer to the bootloader documentation.
> +
> +[[deploying-images-nfs-links]]
> +Here is some related documentation to NFS server setup and NFS boot:
> +
> +* http://tldp.org/HOWTO/NFS-HOWTO/index.html
> +* https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
> +* https://wiki.archlinux.org/index.php/NFS
> +* http://www.solid-run.com/mw/index.php/Setup_NFS_boot
> +* http://wiki.openelec.tv/index.php?title=Network_Boot_-_NFS
> +* http://www.armadeus.com/wiki/index.php?title=NFS
> +
> +NFS root filesystem mounted on +/+
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The idea is to mount +/+ using a network shared folder from an
> +http://tldp.org/HOWTO/NFS-HOWTO/index.html[NFS] server
> +(usually on the host development machine).
> +
> +To enable the NFS boot, you should select the _tar root filesystem_
> +option in the _Filesystem images_ submenu.

  menu

> +
> +The embedded kernel needs at least the following options:

  The target kernel

> +
> +* NFS filesystem support (+CONFIG_NFS_FS+);
> +
> +* Root file system on NFS (+CONFIG_ROOT_NFS+);

  filesystem

> +
> +* Ethernet (+CONFIG_NET_ETHERNET+);
> +
> +* The ethernet driver for the embedded network card;

  for the target's network interface;

> +
> +* IP: kernel level autoconfiguration. This includes:
> +
> +  * +CONFIG_IP_PNP+;
> +  * +CONFIG_IP_PNP_BOOTTP+;
> +  * +CONFIG_IP_PNP_DHCP+.

  AFAIK these are automatic when you select ROOT_NFS, no?

> +
> +After a complete build, just run the following command to setup the
> +NFS root directory on the server:
> +
> +-------------------
> +sudo tar -xavf /path/to/output_dir/rootfs.tar -C /path/to/nfs_root_dir
> +-------------------
> +
> +Make sure the NFS root location appears in the +/etc/exports+ file,
> +and an _NFS_ daemon is running on the server.

  No need to put NFS in italics.

> +
> +After editing +/etc/exports+, you should run:
> +
> +-------------------
> +sudo exportfs -ra
> +-------------------
> +
> +To boot on a NFS root-filesystem, adjust the kernel command line

  root filesystem

> +parameters (see https://www.kernel.org/doc/Documentation/kernel-parameters.txt
> +and the xref:deploying-images-nfs-links[above links]).
> +
> +For further information, refer to the
> +xref:deploying-images-nfs-links[above links].
> +
> +
> +Network PXE bootloader
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +[NOTE]
> +This section is mostly x86 target specific.
> +
> +To fully boot on the network you need a network bootloader. This is
> +optional and you could use your classic bootloader to mount an 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

  provides


  Regards,
  Arnout


> +boot ROM that is accessible from a TFTP server.
> +Then your target boots with it and comes back to the TFTP server to get
> +the specific stuff (for instance its boot menu).
> +
> +Here are some hints on how to setup this:
> +
> +* http://www.digitalpeer.com/id/linuxnfs
> +
> +
> +Chroot into generated image
> +---------------------------
> +
> +If you want to 'chroot' in a generated image, then there are few things
> +you should be aware of:
> +
> +* you should setup the new root from the _tar root filesystem_ image;
> +
> +* either the selected target architecture is compatible with your host
> +  machine, or you should use some +qemu-*+ binary and correctly set it
> +  within the +binfmt+ properties to be able to run the binaries built
> +  for the target on your host machine;
> +
> +* Buildroot does not currently provide +host-qemu+ nor +binfmt+
> +  correctly built and set for that kind of use. This usage is beyond
> +  Buildroot scope.
> diff --git a/docs/manual/manual.txt b/docs/manual/manual.txt
> index 9685667..8fcb2c2 100644
> --- a/docs/manual/manual.txt
> +++ b/docs/manual/manual.txt
> @@ -21,6 +21,8 @@ include::starting-up.txt[]
>
>   include::working-with.txt[]
>
> +include::deploying-images.txt[]
> +
>   include::faq-troubleshooting.txt[]
>
>   include::going-further.txt[]
> @@ -29,8 +31,6 @@ include::developer-guide.txt[]
>
>   include::legal-notice.txt[]
>
> -include::beyond-buildroot.txt[]
> -
>   include::get-involved.txt[]
>
>   include::contribute.txt[]
> diff --git a/docs/manual/using.txt b/docs/manual/using.txt
> index de29ad6..783370d 100644
> --- a/docs/manual/using.txt
> +++ b/docs/manual/using.txt
> @@ -67,7 +67,8 @@ Buildroot output is stored in a single directory, +output/+.
>   This directory contains several subdirectories:
>
>   * +images/+ where all the images (kernel image, bootloader and root
> -  filesystem images) are stored.
> +  filesystem images) are stored. For further details for using/booting
> +  the images, refer to xref:deploying-images[].
>
>   * +build/+ where all the components except for the cross-compilation
>     toolchain are built (this includes tools needed to run Buildroot on
>


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

[Buildroot] [PATCH 9/9] manual: rework Deploying images chapter

[Thomas De Schampheleire]

Hi Samuel, Arnout,

On Tue, Oct 8, 2013 at 10:29 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 10/05/13 21:49, Samuel Martin wrote:
>>
[..]
>> +flashing and/or booting the given platform.
>> +
>> +Although, deploying the generated images on the actual hardware
>> +(flashing and booting the hardware) is very tight to the target
>> +hardware and can differ a lot from one target to another.
>> +Buildroot cannot provide information on this part.
>> +
>> +For deploying images on the actual target, refer to the hardware
>> +vendor instructions, or the readme file in the _board_ directory if
>> +any.
>
>
>  I don't like how these two paragraphs are formulated, but I can't readily
> think of an improvement.
>

Maybe:
Nevertheless, how to deploy the generated images on actual hardware is
very board-specific. Buildroot cannot provide instructions for all
boards, or even provide complete instructions for a single board.
Please refer to the instructions provided by the target vendor.

[..]



Regarding the section names, currently you have:
4. Deploying target images built with Buildroot
4.1. Deploying images on the target hardware
4.2. Booting images in emulators
4.3. Preparing a raw disk image for customized target layout
4.4. Preparing a bootable raw disk file for virtualization
4.5. Booting the generated image over the network
4.6. Chroot into generated image

While 4 and 4.1 talk about 'deploying' the other sections start using
other terminology. Here is a suggestion:
4. Deploying target images built with Buildroot
4.1. Deploying images on the target hardware
4.2. Deploying images in emulators
4.3. Preparing a raw disk image for customized target layout
4.4. Preparing a bootable raw disk file for virtualization
4.5. Deploying images over the network
4.6. Chroot into generated image

In fact, 4.5 also talks about target hardware, so should probably be
moved above, or even a subsection of 4.1.
I'm not yet a big fan of the names of 4.3, 4.4 and 4.6 (it's unclear
to me what they really do based on the title) but I don't have good
suggestions.

Best regards,
Thomas

[Buildroot] [PATCH 9/9] manual: rework Deploying images chapter

[Arnout Vandecappelle]

On 15/10/13 22:27, Thomas De Schampheleire wrote:
> Hi Samuel, Arnout,
>
> On Tue, Oct 8, 2013 at 10:29 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> On 10/05/13 21:49, Samuel Martin wrote:
>>>
> [..]
>>> +flashing and/or booting the given platform.
>>> +
>>> +Although, deploying the generated images on the actual hardware
>>> +(flashing and booting the hardware) is very tight to the target
>>> +hardware and can differ a lot from one target to another.
>>> +Buildroot cannot provide information on this part.
>>> +
>>> +For deploying images on the actual target, refer to the hardware
>>> +vendor instructions, or the readme file in the _board_ directory if
>>> +any.
>>
>>
>>   I don't like how these two paragraphs are formulated, but I can't readily
>> think of an improvement.
>>
>
> Maybe:
> Nevertheless, how to deploy the generated images on actual hardware is
> very board-specific. Buildroot cannot provide instructions for all
> boards, or even provide complete instructions for a single board.
> Please refer to the instructions provided by the target vendor.

  Nice!

>
> [..]
>
>
>
> Regarding the section names, currently you have:
> 4. Deploying target images built with Buildroot
> 4.1. Deploying images on the target hardware
> 4.2. Booting images in emulators
> 4.3. Preparing a raw disk image for customized target layout
> 4.4. Preparing a bootable raw disk file for virtualization
> 4.5. Booting the generated image over the network
> 4.6. Chroot into generated image
>
> While 4 and 4.1 talk about 'deploying' the other sections start using
> other terminology. Here is a suggestion:
> 4. Deploying target images built with Buildroot
> 4.1. Deploying images on the target hardware
> 4.2. Deploying images in emulators
> 4.3. Preparing a raw disk image for customized target layout
> 4.4. Preparing a bootable raw disk file for virtualization
> 4.5. Deploying images over the network
> 4.6. Chroot into generated image
>
> In fact, 4.5 also talks about target hardware, so should probably be
> moved above, or even a subsection of 4.1.
> I'm not yet a big fan of the names of 4.3, 4.4 and 4.6 (it's unclear
> to me what they really do based on the title) but I don't have good
> suggestions.

  Right, my attempt: a bit of reordering and more "deploying":

4. Deploying target images built with Buildroot
4.1. Deploying images on the target hardware
      (includes the network deployment)
4.2. Deploying images on removable media
4.3. Preparing a bootable raw disk file for virtualization
4.4. Deploying images in emulators
4.5. Chroot into generated image


  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

[Buildroot] [PATCH 9/9] manual: rework Deploying images chapter

[Thomas De Schampheleire]

On Wed, Oct 16, 2013 at 11:29 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 15/10/13 22:27, Thomas De Schampheleire wrote:
[..]
>>
>>
>> Regarding the section names, currently you have:
>> 4. Deploying target images built with Buildroot
>> 4.1. Deploying images on the target hardware
>> 4.2. Booting images in emulators
>> 4.3. Preparing a raw disk image for customized target layout
>> 4.4. Preparing a bootable raw disk file for virtualization
>> 4.5. Booting the generated image over the network
>> 4.6. Chroot into generated image
>>
>> While 4 and 4.1 talk about 'deploying' the other sections start using
>> other terminology. Here is a suggestion:
>> 4. Deploying target images built with Buildroot
>> 4.1. Deploying images on the target hardware
>> 4.2. Deploying images in emulators
>> 4.3. Preparing a raw disk image for customized target layout
>> 4.4. Preparing a bootable raw disk file for virtualization
>> 4.5. Deploying images over the network
>> 4.6. Chroot into generated image
>>
>> In fact, 4.5 also talks about target hardware, so should probably be
>> moved above, or even a subsection of 4.1.
>> I'm not yet a big fan of the names of 4.3, 4.4 and 4.6 (it's unclear
>> to me what they really do based on the title) but I don't have good
>> suggestions.
>
>
>  Right, my attempt: a bit of reordering and more "deploying":
>
>
> 4. Deploying target images built with Buildroot
> 4.1. Deploying images on the target hardware
>      (includes the network deployment)
> 4.2. Deploying images on removable media
> 4.3. Preparing a bootable raw disk file for virtualization
> 4.4. Deploying images in emulators
> 4.5. Chroot into generated image

I like it, except still the 4.5. What is the use case for chroot'ing
into such an image? To manipulate the image? Or in the case of the
same target/native architecture to actually run stuff? Can we change
the section name to reflect the purpose rather than the solution?
If 'chroot' is the most clear way to put it in the section name, then
I'd change to:
"chroot'ing into a target image"
('ing' to match the other sections, 'a' article to make it read
better, and lowercase chroot because it's a special name and
capitalizing that reads odd IMO)

Best regards,
Thomas

[Buildroot] [PATCH 9/9] manual: rework Deploying images chapter

[Arnout Vandecappelle]

On 17/10/13 10:12, Thomas De Schampheleire wrote:
> On Wed, Oct 16, 2013 at 11:29 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> On 15/10/13 22:27, Thomas De Schampheleire wrote:
> [..]
>>>
>>>
>>> Regarding the section names, currently you have:
>>> 4. Deploying target images built with Buildroot
>>> 4.1. Deploying images on the target hardware
>>> 4.2. Booting images in emulators
>>> 4.3. Preparing a raw disk image for customized target layout
>>> 4.4. Preparing a bootable raw disk file for virtualization
>>> 4.5. Booting the generated image over the network
>>> 4.6. Chroot into generated image
>>>
>>> While 4 and 4.1 talk about 'deploying' the other sections start using
>>> other terminology. Here is a suggestion:
>>> 4. Deploying target images built with Buildroot
>>> 4.1. Deploying images on the target hardware
>>> 4.2. Deploying images in emulators
>>> 4.3. Preparing a raw disk image for customized target layout
>>> 4.4. Preparing a bootable raw disk file for virtualization
>>> 4.5. Deploying images over the network
>>> 4.6. Chroot into generated image
>>>
>>> In fact, 4.5 also talks about target hardware, so should probably be
>>> moved above, or even a subsection of 4.1.
>>> I'm not yet a big fan of the names of 4.3, 4.4 and 4.6 (it's unclear
>>> to me what they really do based on the title) but I don't have good
>>> suggestions.
>>
>>
>>   Right, my attempt: a bit of reordering and more "deploying":
>>
>>
>> 4. Deploying target images built with Buildroot
>> 4.1. Deploying images on the target hardware
>>       (includes the network deployment)
>> 4.2. Deploying images on removable media
>> 4.3. Preparing a bootable raw disk file for virtualization
>> 4.4. Deploying images in emulators
>> 4.5. Chroot into generated image
>
> I like it, except still the 4.5. What is the use case for chroot'ing
> into such an image? To manipulate the image? Or in the case of the
> same target/native architecture to actually run stuff? Can we change
> the section name to reflect the purpose rather than the solution?
> If 'chroot' is the most clear way to put it in the section name, then
> I'd change to:
> "chroot'ing into a target image"
> ('ing' to match the other sections, 'a' article to make it read
> better, and lowercase chroot because it's a special name and
> capitalizing that reads odd IMO)

  Ack that.

  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

[Buildroot] [PATCH 9/9] manual: rework Deploying images chapter

[Samuel Martin]

Arnout, Thomas, all,

2013/10/17 Arnout Vandecappelle <arnout@mind.be>

> On 17/10/13 10:12, Thomas De Schampheleire wrote:
>
>> On Wed, Oct 16, 2013 at 11:29 PM, Arnout Vandecappelle <arnout@mind.be>
>> wrote:
>>
>>> On 15/10/13 22:27, Thomas De Schampheleire wrote:
>>>
>> [..]
>>
>>>
>>>>
>>>> Regarding the section names, currently you have:
>>>> 4. Deploying target images built with Buildroot
>>>> 4.1. Deploying images on the target hardware
>>>> 4.2. Booting images in emulators
>>>> 4.3. Preparing a raw disk image for customized target layout
>>>> 4.4. Preparing a bootable raw disk file for virtualization
>>>> 4.5. Booting the generated image over the network
>>>> 4.6. Chroot into generated image
>>>>
>>>> While 4 and 4.1 talk about 'deploying' the other sections start using
>>>> other terminology. Here is a suggestion:
>>>> 4. Deploying target images built with Buildroot
>>>> 4.1. Deploying images on the target hardware
>>>> 4.2. Deploying images in emulators
>>>> 4.3. Preparing a raw disk image for customized target layout
>>>> 4.4. Preparing a bootable raw disk file for virtualization
>>>> 4.5. Deploying images over the network
>>>> 4.6. Chroot into generated image
>>>>
>>>> In fact, 4.5 also talks about target hardware, so should probably be
>>>> moved above, or even a subsection of 4.1.
>>>> I'm not yet a big fan of the names of 4.3, 4.4 and 4.6 (it's unclear
>>>> to me what they really do based on the title) but I don't have good
>>>> suggestions.
>>>>
>>>
>>>
>>>   Right, my attempt: a bit of reordering and more "deploying":
>>>
>>>
>>> 4. Deploying target images built with Buildroot
>>> 4.1. Deploying images on the target hardware
>>>       (includes the network deployment)
>>> 4.2. Deploying images on removable media
>>> 4.3. Preparing a bootable raw disk file for virtualization
>>> 4.4. Deploying images in emulators
>>> 4.5. Chroot into generated image
>>>
>>
>> I like it, except still the 4.5. What is the use case for chroot'ing
>> into such an image? To manipulate the image? Or in the case of the
>> same target/native architecture to actually run stuff? Can we change
>> the section name to reflect the purpose rather than the solution?
>> If 'chroot' is the most clear way to put it in the section name, then
>> I'd change to:
>> "chroot'ing into a target image"
>> ('ing' to match the other sections, 'a' article to make it read
>> better, and lowercase chroot because it's a special name and
>> capitalizing that reads odd IMO)
>>
>
>  Ack that.

Indeed, it's much more consistent with the rest of the chapter.
I will update the series and repost it.

Thanks all for your inputs.

Regards,

-- 
Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131017/ce2baa4b/attachment-0001.html>

[Buildroot] [PATCH 9/9] manual: rework Deploying images chapter

[Samuel Martin]

Arnout,


2013/10/8 Arnout Vandecappelle <arnout@mind.be>

> On 10/05/13 21:49, Samuel Martin wrote:
>
>> [...]
>
>  +
>> +[WARNING]
>> +Be careful, *the _board's_ readme files coming within Buildroot are
>> +provided without warranty of any kind*.
>> +They are contributions from Buildroot users, but Buildroot developers
>> +do not ensure their correctness, nor maintain them.
>>
>
>  Is this warning really necessary? Most readme.txt files use removable
> media (or emulation), and the few that do write to flash have warnings
> already. The only exception is the Telit EVK-PRO3, so maybe we should just
> add a warning there.

Well, the few boards we are talking about here are:
- Telit EVK-PRO3
- avnet s6lx9_microboard
- freescale mpc8315erdb
- freescale p1010rdb
For the 2 later, there is a warning about the bootloader in the readme.txt
files,
for the 2 others, it is not so obvious...

Anyway, I don't mind adding the warning in the readme files.
Having it close to the flashing instruction makes sense;
having it in the documentation (as a genreric warning) makes sense too imho.

Regards,

-- 
Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131017/407e625f/attachment.html>

[Buildroot] [PATCH 9/9] manual: rework Deploying images chapter

[Arnout Vandecappelle]

On 17/10/13 10:40, Samuel Martin wrote:
> Arnout,
>
>
> 2013/10/8 Arnout Vandecappelle <arnout at mind.be <mailto:arnout@mind.be>>
>
>     On 10/05/13 21:49, Samuel Martin wrote:
>
>         [...]
>
>         +
>         +[WARNING]
>         +Be careful, *the _board's_ readme files coming within Buildroot are
>         +provided without warranty of any kind*.
>         +They are contributions from Buildroot users, but Buildroot
>         developers
>         +do not ensure their correctness, nor maintain them.
>
>
>       Is this warning really necessary? Most readme.txt files use
>     removable media (or emulation), and the few that do write to flash
>     have warnings already. The only exception is the Telit EVK-PRO3, so
>     maybe we should just add a warning there.
>
> Well, the few boards we are talking about here are:
> - Telit EVK-PRO3
> - avnet s6lx9_microboard
> - freescale mpc8315erdb
> - freescale p1010rdb
> For the 2 later, there is a warning about the bootloader in the
> readme.txt files,
> for the 2 others, it is not so obvious...

  For the s6lx9 the danger isn't so big because you don't overwrite the 
bootloader.

>
> Anyway, I don't mind adding the warning in the readme files.
> Having it close to the flashing instruction makes sense;
> having it in the documentation (as a genreric warning) makes sense too imho.

  I just don't like scaring people off... But I guess the warning doesn't 
really hurt.

  Regards,
  Arnout

>
> Regards,
>
> --
> Samuel


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