BSP for taskit stamp9g20

BSP for taskit stamp9g20

[Markus Hubig]

[-- Attachment #1: Type: text/plain, Size: 17634 bytes --]

Hello @all,

as part of my bachelor thesis, I'm in the process of creating a custom
Linux OS
for the taskit Stamp9G20<http://www.taskit.de/en/products/stamp9g20/index.htm>(a
small AT91SAM9G20 based CPU board). This is when
I came across the YoctoProject. Now I'm trying to build a BSP Layer for
this Board.

There are a lot of documentation out there, but I still miss the whole
picture ... :-(

This is what I've done so far:

$ yocto-bsp create stamp9g20 arm
-> kernel 3.2 [y]
-> new machine branch [y]
-> machine branch to base this BSP on
[standard/default/arm-versatile-926ejs]
-> Do you need SMP support? [n]
-> Which machine tuning would you like to use? [arm926ejs]
-> value for UBOOT_MACHINE [default: omap3_beagle_config]
-> UBOOT_ENTRYPOINT: [default: 0x80008000]
-> UBOOT_LOADADDRESS: [default: 0x80008000]
-> Do you need support for X? [n]
-> Does your BSP have a touchscreen? [default: n]
-> Does your BSP have a keyboard? [n]

(U-Boot stuff needs some adjustments but I save this for later ...)

Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
step? To get the right
kernel configuration for the stamp9g20 I can easily configure the kernel
with:

$ make ARCH=arm stamp9g20_defconfig

Here is what I "think" I have to do next. Please, please correct me if I
got it all wrong!

# make a bare clone
$ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
 linux-yocto-3.2.git

# make a *working clone* of the *bare clone*
$ git clone linux-yocto-3.2.git linux-yocto-3.2-work

# create a new branch based on arm-versatile-926ejs *inside my working clone
*
$ git checkout -b
yocto/standard/stamp9g20 remotes/origin/standard/default/arm-versatile-926ejs

# push the new branch back to the *bare clone*. Now I have a branch my
bsp-layer is based on?!
$ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20

# check out the *meta branch* inside the *working clone*
$ git checkout -b meta-stamp9g20 remotes/origin/meta

# now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and rename
everything ...
$ cd meta/cfg/kernel-cache/bsp
$ cp -a arm-versatile-926ejs stamp9g20
$ cd stamp9g20
$ rename 's/arm-versatile-926ejs/stamp9g20/' *
$ sed -i 's/arm-versatile-926ejs/stamp9g20/' *

Now it get's in to the details. Since I have a working kernel config from "make
ARCH=arm stamp9g20_defconfig" I *think*
all I have to do is using the resulting .config file and put *parts of it*into
stamp9g20.cfg, right? Later more on this, but since
I'm more interested in the "big picture" I will leave these files as they
are for now.

# Add, commit and push the changes to the bare clone
$ git add stamp9g20
$ git commit -a -s
$ git push origin meta-stamp9g20:meta

# Now I change meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
# to point to my new branch
KBRANCH_stamp9g20 = "standard/default/stamp9g20"
YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20  = "standard/default/stamp9g20"

# Clone poky-extras *into poky* ...
$ git clone git://git.yoctoproject.org/poky-extras poky-extras

#
edit poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

# Now lets try a build.
$ cd ~/poky
$ source oe-init-build-env

# Edit conf/bblayers.conf
BBLAYERS ?= " \
  /home/mhubig/Development/poky/meta \
  /home/mhubig/Development/poky/meta-yocto \
  /home/mhubig/Development/poky/meta-stamp9g20 \
  /home/mhubig/Development/poky/poky-extras/meta-kernel-dev \
  "

# Edit conf/local.conf
MACHINE ??= "stamp9g20"

and go ...

$ bitbake -c cleanall linux-yocto
$ bitbake -k core-image-minimal

This fails with a bunch of errors, all related to linux-yocto ...

$ bitbake -v -k linux-yocto
WARNING: Host distribution "Ubuntu 12.04 LTS" has not been validated with
this version of the build system; you may possibly experience unexpected
failures. It is recommended that you use a tested distribution.
Loading cache: 100%
|#############################################################################|
ETA:  00:00:00
Loaded 1104 entries from dependency cache.
Parsing recipes: 100%
|###########################################################################|
Time: 00:00:00
Parsing of 829 .bb files complete (827 cached, 2 parsed). 1105 targets, 37
skipped, 0 masked, 0 errors.

OE Build Configuration:
BB_VERSION        = "1.15.1"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "stamp9g20"
DISTRO            = "poky"
DISTRO_VERSION    = "1.2"
TUNE_FEATURES     = "armv5 dsp thumb arm926ejs"
TARGET_FPU        = "soft"
meta
meta-yocto
meta-stamp9g20    = "denzil:d20a24310eb43fed9a3f3e75752c9ad45a18cbe4"
meta-kernel-dev   = "master:42f1aba1c52da20edd65709152fec3529b3b516f"

NOTE: Resolving any missing task queue dependencies
NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to
PREFERRED_PROVIDERS
NOTE: selecting eglibc to satisfy virtual/libc due to PREFERRED_PROVIDERS
NOTE: selecting gcc-cross to satisfy virtual/arm-poky-linux-gnueabi-gcc due
to PREFERRED_PROVIDERS
NOTE: selecting linux-yocto to satisfy runtime kernel-base due to
PREFERRED_PROVIDER_virtual/kernel = linux-yocto
NOTE: selecting linux-yocto to satisfy runtime kernel-image due to
PREFERRED_PROVIDER_virtual/kernel = linux-yocto
NOTE: selecting eglibc to satisfy runtime eglibc-dev due to
PREFERRED_PROVIDER_virtual/libc = eglibc
NOTE: selecting eglibc to satisfy runtime libsegfault due to
PREFERRED_PROVIDER_virtual/libc = eglibc
NOTE: selecting eglibc to satisfy runtime eglibc due to
PREFERRED_PROVIDER_virtual/libc = eglibc
NOTE: selecting gcc-cross-intermediate to satisfy
virtual/arm-poky-linux-gnueabi-gcc-intermediate due to PREFERRED_PROVIDERS
NOTE: selecting linux-libc-headers to satisfy linux-libc-headers due to
PREFERRED_PROVIDERS
NOTE: selecting gettext to satisfy virtual/gettext due to
PREFERRED_PROVIDERS
NOTE: selecting gcc-runtime to satisfy
virtual/arm-poky-linux-gnueabi-compilerlibs due to PREFERRED_PROVIDERS
NOTE: selecting binutils-cross to satisfy
virtual/arm-poky-linux-gnueabi-binutils due to PREFERRED_PROVIDERS
NOTE: selecting eglibc to satisfy
virtual/arm-poky-linux-gnueabi-libc-for-gcc due to PREFERRED_PROVIDERS
NOTE: selecting db to satisfy virtual/db due to PREFERRED_PROVIDERS
NOTE: selecting linux-libc-headers to satisfy runtime
linux-libc-headers-dev due to PREFERRED_PROVIDER_linux-libc-headers =
linux-libc-headers
NOTE: selecting gettext to satisfy runtime gettext-dev due to
PREFERRED_PROVIDER_virtual/gettext = gettext
NOTE: selecting gettext to satisfy runtime gettext due to
PREFERRED_PROVIDER_virtual/gettext = gettext
NOTE: selecting db to satisfy runtime db-dev due to
PREFERRED_PROVIDER_virtual/db = db
NOTE: selecting db to satisfy runtime db due to
PREFERRED_PROVIDER_virtual/db = db
NOTE: selecting pigz-native to satisfy gzip-native due to
PREFERRED_PROVIDERS
NOTE: selecting eglibc-initial to satisfy
virtual/arm-poky-linux-gnueabi-libc-initial due to PREFERRED_PROVIDERS
NOTE: selecting eglibc to satisfy virtual/libiconv due to
PREFERRED_PROVIDERS
NOTE: selecting gcc-cross to satisfy virtual/arm-poky-linux-gnueabi-g++ due
to PREFERRED_PROVIDERS
NOTE: selecting libgcc to satisfy libgcc due to PREFERRED_PROVIDERS
NOTE: selecting libgcc to satisfy runtime libgcc due to
PREFERRED_PROVIDER_libgcc = libgcc
NOTE: selecting gcc-cross-initial to satisfy
virtual/arm-poky-linux-gnueabi-gcc-initial due to PREFERRED_PROVIDERS
NOTE: Preparing runqueue
NOTE: Marking Active Tasks
NOTE: Pruned 1364 inactive tasks, 992 left
NOTE: Assign Weightings
NOTE: Compute totals (have 1 endpoint(s))
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 422 of 992 (ID: 3,
/home/mhubig/Development/poky/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
do_patch)
NOTE: package
linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1:
task do_patch: Started
+ cd
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1
+ do_patch
+ cd
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux
+ [ -f
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01
627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/defconfig
]
+ [ -f
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux/scripts/util/configme
]
+ kbranch=standard/default/stamp9g20
+ [ -n standard/default/stamp9g20 ]
+ kbranch=standard/default/stamp9g20
+ [ -n t ]
+ createme_flags=--disable-meta-gen
+ createme --disable-meta-gen arm st
andard/default/stamp9g20
[INFO]: checkpoint is already restored, nothing to do
+ [ 0 -ne 0 ]
+
sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
el/linux/files/user-patches.scc
+ patches=
+ set +e
+ [ -n features/netfilter features/taskstats ]
+ addon_features= --feature features/netfilter
+ addon_features= --feature features/netfilter --feature features/taskstats
+ updateme --branch standard/default/stamp9g20 -DKDESC=stamp9g20:standard
--feature features/netfilter --feature features/taskstats arm stamp9g20
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
/home/mhubig/Development/poky/meta-stamp9g20/reci
pes-kernel/linux/files/stamp9g20.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-patches.scc
+ [ 0 -ne 0 ]
+ patchme standard/default/stamp9g20
ERROR. Could not locate meta series for standard/default/stamp9g20
+ [ 1 -ne 0 ]
+ echo ERROR. Could not modify standard/default/stamp9g20
ERROR. Could not modif
ERROR: Function failed: do_patch (see
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/temp/log.do_patch.31485
for further information)
ERROR: Logfile of failure stored in:
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/temp/log.do_patch.31485
Log data follows:
| + cd
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1
| + do_patch
| + cd
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux
| + [ -f
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01
|
627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/defconfig
]
| + [ -f
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux/scripts/util/configme
]
| + kbranch=standard/default/stamp9g20
| + [ -n standard/default/stamp9g20 ]
| + kbranch=standard/default/stamp9g20
| + [ -n t ]
| + createme_flags=--disable-meta-gen
| + createme --disable-meta-gen arm st
| andard/default/stamp9g20
| [INFO]: checkpoint is already restored, nothing to do
| + [ 0 -ne 0 ]
| +
sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
| el/linux/files/user-patches.scc
| + patches=
| + set +e
| + [ -n features/netfilter features/taskstats ]
| + addon_features= --feature features/netfilter
| + addon_features= --feature features/netfilter --feature
features/taskstats
| + updateme --branch standard/default/stamp9g20 -DKDESC=stamp9g20:standard
--feature features/netfilter --feature features/taskstats arm stamp9g20
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
/home/mhubig/Development/poky/meta-stamp9g20/reci
| pes-kernel/linux/files/stamp9g20.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-patches.scc
| + [ 0 -ne 0 ]
| + patchme standard/default/stamp9g20
| ERROR. Could not locate meta series for standard/default/stamp9g20
| + [ 1 -ne 0 ]
| + echo ERROR. Could not modify standard/default/stamp9g20
| ERROR. Could not modif
| ERROR: Function failed: do_patch (see
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/temp/log.do_patch.31485
for further information)
| + cd
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1
| + do_patch
| + cd
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux
| + [ -f
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/defconfig
]
| + [ -f
/home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux/scripts/util/configme
]
| + kbranch=standard/default/stamp9g20
| + [ -n standard/default/stamp9g20 ]
| + kbranch=standard/default/stamp9g20
| + [ -n t ]
| + createme_flags=--disable-meta-gen
| + createme --disable-meta-gen arm standard/default/stamp9g20
| [INFO]: checkpoint is already restored, nothing to do
| + [ 0 -ne 0 ]
| +
sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-patches.scc
| + patches=
| + set +e
| + [ -n features/netfilter features/taskstats ]
| + addon_features= --feature features/netfilter
| + addon_features= --feature features/netfilter --feature
features/taskstats
| + updateme --branch standard/default/stamp9g20 -DKDESC=stamp9g20:standard
--feature features/netfilter --feature features/taskstats arm stamp9g20
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-patches.scc
| + [ 0 -ne 0 ]
| + patchme standard/default/stamp9g20
| ERROR. Could not locate meta series for standard/default/stamp9g20
| + [ 1 -ne 0 ]
| + echo ERROR. Could not modify standard/default/stamp9g20
| ERROR. Could not modif
NOTE: package
linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1:
task do_patch: Failed
ERROR: Task 3 (/home/mhubig/Development/poky/meta/recipes-kernel/linux/
linux-yocto_3.2.bb, do_patch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 975 tasks of which 974 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:
  /home/mhubig/Development/poky/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
do_patch
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

[-- Attachment #2: Type: text/html, Size: 23721 bytes --]

Re: BSP for taskit stamp9g20

[Bruce Ashfield]

On 12-06-26 07:08 AM, Markus Hubig wrote:
> Hello @all,
>
> as part of my bachelor thesis, I'm in the process of creating a custom
> Linux OS
> for the taskit Stamp9G20
> <http://www.taskit.de/en/products/stamp9g20/index.htm> (a small
> AT91SAM9G20 based CPU board). This is when
> I came across the YoctoProject. Now I'm trying to build a BSP Layer for
> this Board.
>
> There are a lot of documentation out there, but I still miss the whole
> picture ... :-(
>
> This is what I've done so far:

This is on master ? Yocto 1.2 ? Some other release ?

>
> $ yocto-bsp create stamp9g20 arm
> -> kernel 3.2 [y]
> -> new machine branch [y]
> -> machine branch to base this BSP on
> [standard/default/arm-versatile-926ejs]
> -> Do you need SMP support? [n]
> -> Which machine tuning would you like to use? [arm926ejs]
> -> value for UBOOT_MACHINE [default: omap3_beagle_config]
> -> UBOOT_ENTRYPOINT: [default: 0x80008000]
> -> UBOOT_LOADADDRESS: [default: 0x80008000]
> -> Do you need support for X? [n]
> -> Does your BSP have a touchscreen? [default: n]
> -> Does your BSP have a keyboard? [n]
>
> (U-Boot stuff needs some adjustments but I save this for later ...)
>
> Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
> step? To get the right
> kernel configuration for the stamp9g20 I can easily configure the kernel
> with:
>
> $ make ARCH=arm stamp9g20_defconfig
>
> Here is what I "think" I have to do next. Please, please correct me if I
> got it all wrong!
>
> # make a bare clone
> $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
> <http://git.yoctoproject.org/linux-yocto-3.2> linux-yocto-3.2.git
>
> # make a *working clone* of the *bare clone*
> $ git clone linux-yocto-3.2.git linux-yocto-3.2-work
>
> # create a new branch based on arm-versatile-926ejs *inside my working
> clone*
> $ git checkout -b yocto/standard/stamp9g20
> remotes/origin/standard/default/arm-versatile-926ejs
>
> # push the new branch back to the *bare clone*. Now I have a branch my
> bsp-layer is based on?!
> $ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20
>
> # check out the *meta branch* inside the *working clone*
> $ git checkout -b meta-stamp9g20 remotes/origin/meta
>
> # now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and
> rename everything ...
> $ cd meta/cfg/kernel-cache/bsp
> $ cp -a arm-versatile-926ejs stamp9g20
> $ cd stamp9g20
> $ rename 's/arm-versatile-926ejs/stamp9g20/' *
> $ sed -i 's/arm-versatile-926ejs/stamp9g20/' *
>
> Now it get's in to the details. Since I have a working kernel config
> from "make ARCH=arm stamp9g20_defconfig" I *think*
> all I have to do is using the resulting .config file and put *parts of
> it* into stamp9g20.cfg, right? Later more on this, but since
> I'm more interested in the "big picture" I will leave these files as
> they are for now.
>
> # Add, commit and push the changes to the bare clone
> $ git add stamp9g20
> $ git commit -a -s
> $ git push origin meta-stamp9g20:meta
>
> # Now I change meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
> # to point to my new branch
> KBRANCH_stamp9g20 = "standard/default/stamp9g20"
> YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 = "standard/default/stamp9g20"

You don't actually have an external branch, because you made the right
choice to use git to manage your BSP :P So you don't need this.

>
> # Clone poky-extras *into poky* ...
> $ git clone git://git.yoctoproject.org/poky-extras
> <http://git.yoctoproject.org/poky-extras> poky-extras
>
> # edit
> poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
> KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
> SRC_URI =
> "git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

This is all good, I run with this all day every day .. so far so good.

>
> # Now lets try a build.
> $ cd ~/poky
> $ source oe-init-build-env
>
> # Edit conf/bblayers.conf
> BBLAYERS ?= " \
> /home/mhubig/Development/poky/meta \
> /home/mhubig/Development/poky/meta-yocto \
> /home/mhubig/Development/poky/meta-stamp9g20 \
> /home/mhubig/Development/poky/poky-extras/meta-kernel-dev \
> "
>
> # Edit conf/local.conf
> MACHINE ??= "stamp9g20"
>
> and go ...
>
> $ bitbake -c cleanall linux-yocto
> $ bitbake -k core-image-minimal
>
> This fails with a bunch of errors, all related to linux-yocto ...
>
> $ bitbake -v -k linux-yocto
> WARNING: Host distribution "Ubuntu 12.04 LTS" has not been validated
> with this version of the build system; you may possibly experience
> unexpected failures. It is recommended that you use a tested distribution.
> Loading cache: 100%
> |#############################################################################|
> ETA: 00:00:00
> Loaded 1104 entries from dependency cache.
> Parsing recipes: 100%
> |###########################################################################|
> Time: 00:00:00
> Parsing of 829 .bb files complete (827 cached, 2 parsed). 1105 targets,
> 37 skipped, 0 masked, 0 errors.
>
> OE Build Configuration:
> BB_VERSION = "1.15.1"
> TARGET_ARCH = "arm"
> TARGET_OS = "linux-gnueabi"
> MACHINE = "stamp9g20"
> DISTRO = "poky"
> DISTRO_VERSION = "1.2"
> TUNE_FEATURES = "armv5 dsp thumb arm926ejs"
> TARGET_FPU = "soft"
> meta
> meta-yocto
> meta-stamp9g20 = "denzil:d20a24310eb43fed9a3f3e75752c9ad45a18cbe4"
> meta-kernel-dev = "master:42f1aba1c52da20edd65709152fec3529b3b516f"
>
> NOTE: Resolving any missing task queue dependencies
> NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to
> PREFERRED_PROVIDERS
> NOTE: selecting eglibc to satisfy virtual/libc due to PREFERRED_PROVIDERS
> NOTE: selecting gcc-cross to satisfy virtual/arm-poky-linux-gnueabi-gcc
> due to PREFERRED_PROVIDERS
> NOTE: selecting linux-yocto to satisfy runtime kernel-base due to
> PREFERRED_PROVIDER_virtual/kernel = linux-yocto
> NOTE: selecting linux-yocto to satisfy runtime kernel-image due to
> PREFERRED_PROVIDER_virtual/kernel = linux-yocto
> NOTE: selecting eglibc to satisfy runtime eglibc-dev due to
> PREFERRED_PROVIDER_virtual/libc = eglibc
> NOTE: selecting eglibc to satisfy runtime libsegfault due to
> PREFERRED_PROVIDER_virtual/libc = eglibc
> NOTE: selecting eglibc to satisfy runtime eglibc due to
> PREFERRED_PROVIDER_virtual/libc = eglibc
> NOTE: selecting gcc-cross-intermediate to satisfy
> virtual/arm-poky-linux-gnueabi-gcc-intermediate due to PREFERRED_PROVIDERS
> NOTE: selecting linux-libc-headers to satisfy linux-libc-headers due to
> PREFERRED_PROVIDERS
> NOTE: selecting gettext to satisfy virtual/gettext due to
> PREFERRED_PROVIDERS
> NOTE: selecting gcc-runtime to satisfy
> virtual/arm-poky-linux-gnueabi-compilerlibs due to PREFERRED_PROVIDERS
> NOTE: selecting binutils-cross to satisfy
> virtual/arm-poky-linux-gnueabi-binutils due to PREFERRED_PROVIDERS
> NOTE: selecting eglibc to satisfy
> virtual/arm-poky-linux-gnueabi-libc-for-gcc due to PREFERRED_PROVIDERS
> NOTE: selecting db to satisfy virtual/db due to PREFERRED_PROVIDERS
> NOTE: selecting linux-libc-headers to satisfy runtime
> linux-libc-headers-dev due to PREFERRED_PROVIDER_linux-libc-headers =
> linux-libc-headers
> NOTE: selecting gettext to satisfy runtime gettext-dev due to
> PREFERRED_PROVIDER_virtual/gettext = gettext
> NOTE: selecting gettext to satisfy runtime gettext due to
> PREFERRED_PROVIDER_virtual/gettext = gettext
> NOTE: selecting db to satisfy runtime db-dev due to
> PREFERRED_PROVIDER_virtual/db = db
> NOTE: selecting db to satisfy runtime db due to
> PREFERRED_PROVIDER_virtual/db = db
> NOTE: selecting pigz-native to satisfy gzip-native due to
> PREFERRED_PROVIDERS
> NOTE: selecting eglibc-initial to satisfy
> virtual/arm-poky-linux-gnueabi-libc-initial due to PREFERRED_PROVIDERS
> NOTE: selecting eglibc to satisfy virtual/libiconv due to
> PREFERRED_PROVIDERS
> NOTE: selecting gcc-cross to satisfy virtual/arm-poky-linux-gnueabi-g++
> due to PREFERRED_PROVIDERS
> NOTE: selecting libgcc to satisfy libgcc due to PREFERRED_PROVIDERS
> NOTE: selecting libgcc to satisfy runtime libgcc due to
> PREFERRED_PROVIDER_libgcc = libgcc
> NOTE: selecting gcc-cross-initial to satisfy
> virtual/arm-poky-linux-gnueabi-gcc-initial due to PREFERRED_PROVIDERS
> NOTE: Preparing runqueue
> NOTE: Marking Active Tasks
> NOTE: Pruned 1364 inactive tasks, 992 left
> NOTE: Assign Weightings
> NOTE: Compute totals (have 1 endpoint(s))
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 422 of 992 (ID: 3,
> /home/mhubig/Development/poky/meta/recipes-kernel/linux/linux-yocto_3.2.bb
> <http://linux-yocto_3.2.bb>, do_patch)
> NOTE: package
> linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1:
> task do_patch: Started
> + cd
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1
> + do_patch
> + cd
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux
> + [ -f
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01
> 627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/defconfig
> ]
> + [ -f
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux/scripts/util/configme
> ]
> + kbranch=standard/default/stamp9g20
> + [ -n standard/default/stamp9g20 ]
> + kbranch=standard/default/stamp9g20
> + [ -n t ]
> + createme_flags=--disable-meta-gen
> + createme --disable-meta-gen arm st
> andard/default/stamp9g20
> [INFO]: checkpoint is already restored, nothing to do
> + [ 0 -ne 0 ]
> +
> sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
> el/linux/files/user-patches.scc

Aha. This is the problem, if you've decided to create a local repo,
and a BSP branch, you don't need these files outside of the tree. But
I'm betting these were created by the BSP tool .. hence the confusion
as two methods are being mixed.

If you stop using the local repository, and just use the BSP tool that
should at least clarify the error messages and I can help more after
that.

Cheers,

Bruce

> + patches=
> + set +e
> + [ -n features/netfilter features/taskstats ]
> + addon_features= --feature features/netfilter
> + addon_features= --feature features/netfilter --feature features/taskstats
> + updateme --branch standard/default/stamp9g20
> -DKDESC=stamp9g20:standard --feature features/netfilter --feature
> features/taskstats arm stamp9g20
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
> /home/mhubig/Development/poky/meta-stamp9g20/reci
> pes-kernel/linux/files/stamp9g20.scc
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-patches.scc
> + [ 0 -ne 0 ]
> + patchme standard/default/stamp9g20
> ERROR. Could not locate meta series for standard/default/stamp9g20
> + [ 1 -ne 0 ]
> + echo ERROR. Could not modify standard/default/stamp9g20
> ERROR. Could not modif
> ERROR: Function failed: do_patch (see
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/temp/log.do_patch.31485
> for further information)
> ERROR: Logfile of failure stored in:
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/temp/log.do_patch.31485
> Log data follows:
> | + cd
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1
> | + do_patch
> | + cd
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux
> | + [ -f
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01
> |
> 627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/defconfig
> ]
> | + [ -f
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux/scripts/util/configme
> ]
> | + kbranch=standard/default/stamp9g20
> | + [ -n standard/default/stamp9g20 ]
> | + kbranch=standard/default/stamp9g20
> | + [ -n t ]
> | + createme_flags=--disable-meta-gen
> | + createme --disable-meta-gen arm st
> | andard/default/stamp9g20
> | [INFO]: checkpoint is already restored, nothing to do
> | + [ 0 -ne 0 ]
> | +
> sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
> | el/linux/files/user-patches.scc
> | + patches=
> | + set +e
> | + [ -n features/netfilter features/taskstats ]
> | + addon_features= --feature features/netfilter
> | + addon_features= --feature features/netfilter --feature
> features/taskstats
> | + updateme --branch standard/default/stamp9g20
> -DKDESC=stamp9g20:standard --feature features/netfilter --feature
> features/taskstats arm stamp9g20
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
> /home/mhubig/Development/poky/meta-stamp9g20/reci
> | pes-kernel/linux/files/stamp9g20.scc
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-patches.scc
> | + [ 0 -ne 0 ]
> | + patchme standard/default/stamp9g20
> | ERROR. Could not locate meta series for standard/default/stamp9g20
> | + [ 1 -ne 0 ]
> | + echo ERROR. Could not modify standard/default/stamp9g20
> | ERROR. Could not modif
> | ERROR: Function failed: do_patch (see
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/temp/log.do_patch.31485
> for further information)
> | + cd
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1
> | + do_patch
> | + cd
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux
> | + [ -f
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/defconfig
> ]
> | + [ -f
> /home/mhubig/Development/poky/build/tmp/work/stamp9g20-poky-linux-gnueabi/linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1/linux/scripts/util/configme
> ]
> | + kbranch=standard/default/stamp9g20
> | + [ -n standard/default/stamp9g20 ]
> | + kbranch=standard/default/stamp9g20
> | + [ -n t ]
> | + createme_flags=--disable-meta-gen
> | + createme --disable-meta-gen arm standard/default/stamp9g20
> | [INFO]: checkpoint is already restored, nothing to do
> | + [ 0 -ne 0 ]
> | +
> sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-patches.scc
> | + patches=
> | + set +e
> | + [ -n features/netfilter features/taskstats ]
> | + addon_features= --feature features/netfilter
> | + addon_features= --feature features/netfilter --feature
> features/taskstats
> | + updateme --branch standard/default/stamp9g20
> -DKDESC=stamp9g20:standard --feature features/netfilter --feature
> features/taskstats arm stamp9g20
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-patches.scc
> | + [ 0 -ne 0 ]
> | + patchme standard/default/stamp9g20
> | ERROR. Could not locate meta series for standard/default/stamp9g20
> | + [ 1 -ne 0 ]
> | + echo ERROR. Could not modify standard/default/stamp9g20
> | ERROR. Could not modif
> NOTE: package
> linux-yocto-3.2.11+git4+f28e01627c8cef1102f3326009fa3b5d5a22fd97_1+ebb5e65d02a352e3e8601096e1674ffc261345f2-r1.1:
> task do_patch: Failed
> ERROR: Task 3
> (/home/mhubig/Development/poky/meta/recipes-kernel/linux/linux-yocto_3.2.bb
> <http://linux-yocto_3.2.bb>, do_patch) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 975 tasks of which 974 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
> /home/mhubig/Development/poky/meta/recipes-kernel/linux/linux-yocto_3.2.bb
> <http://linux-yocto_3.2.bb>, do_patch
> Summary: There was 1 WARNING message shown.
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
>
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BSP for taskit stamp9g20

[Markus Hubig]

On Tue, Jun 26, 2012 at 3:19 PM, Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
>
> On 12-06-26 07:08 AM, Markus Hubig wrote:
>>
>> AT91SAM9G20 based CPU board). This is when I came across the YoctoProject.
>> Now I'm trying to build a BSP Layer for this Board.
>>
>> There are a lot of documentation out there, but I still miss the whole
>> picture ... :-(
>>
>> This is what I've done so far:
>
> This is on master ? Yocto 1.2 ? Some other release ?

I'm using Yocto 1.2 at the moment ...

>> $ yocto-bsp create stamp9g20 arm
>> -> kernel 3.2 [y]
>> -> new machine branch [y]
>> -> machine branch to base this BSP on [standard/default/arm-versatile-926ejs]
>> -> Do you need SMP support? [n]
>> -> Which machine tuning would you like to use? [arm926ejs]
>> -> value for UBOOT_MACHINE [default: omap3_beagle_config]
>> -> UBOOT_ENTRYPOINT: [default: 0x80008000]
>> -> UBOOT_LOADADDRESS: [default: 0x80008000]
>> -> Do you need support for X? [n]
>> -> Does your BSP have a touchscreen? [default: n]
>> -> Does your BSP have a keyboard? [n]
>>
>> (U-Boot stuff needs some adjustments but I save this for later ...)
>>
>> Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
>> step? To get the right kernel configuration for the stamp9g20 I can easily
>> configure the kernel with:
>>
>> $ make ARCH=arm stamp9g20_defconfig
>>
>> Here is what I "think" I have to do next. Please, please correct me if I
>> got it all wrong!
>>
>> # make a bare clone
>> $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
>> <http://git.yoctoproject.org/linux-yocto-3.2> linux-yocto-3.2.git
>>
>> # make a *working clone* of the *bare clone*
>>
>> $ git clone linux-yocto-3.2.git linux-yocto-3.2-work
>>
>> # create a new branch based on arm-versatile-926ejs *inside my working
>> clone*
>>
>> $ git checkout -b yocto/standard/stamp9g20
>> remotes/origin/standard/default/arm-versatile-926ejs
>>
>> # push the new branch back to the *bare clone*. Now I have a branch my
>>
>> bsp-layer is based on?!
>> $ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20
>>
>> # check out the *meta branch* inside the *working clone*
>>
>> $ git checkout -b meta-stamp9g20 remotes/origin/meta
>>
>> # now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and
>>
>> rename everything ...
>> $ cd meta/cfg/kernel-cache/bsp
>> $ cp -a arm-versatile-926ejs stamp9g20
>> $ cd stamp9g20
>> $ rename 's/arm-versatile-926ejs/stamp9g20/' *
>> $ sed -i 's/arm-versatile-926ejs/stamp9g20/' *
>>
>> Now it get's in to the details. Since I have a working kernel config
>> from "make ARCH=arm stamp9g20_defconfig" I *think*
>> all I have to do is using the resulting .config file and put *parts of
>> it* into stamp9g20.cfg, right? Later more on this, but since
>>
>> I'm more interested in the "big picture" I will leave these files as
>> they are for now.
>>
>> # Add, commit and push the changes to the bare clone
>> $ git add stamp9g20
>> $ git commit -a -s
>> $ git push origin meta-stamp9g20:meta
>>
>> # Now I change meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
>> # to point to my new branch
>> KBRANCH_stamp9g20 = "standard/default/stamp9g20"
>> YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 = "standard/default/stamp9g20"
>
>
> You don't actually have an external branch, because you made the right
> choice to use git to manage your BSP :P So you don't need this.

OK so I just remove the YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 line?

>>
>> # Clone poky-extras *into poky* ...
>>
>> $ git clone git://git.yoctoproject.org/poky-extras
>> <http://git.yoctoproject.org/poky-extras> poky-extras
>>
>>
>> # edit
>> poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
>> KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
>> SRC_URI =
>> "git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>
>
> This is all good, I run with this all day every day .. so far so good.

OK ...

>> [INFO]: checkpoint is already restored, nothing to do
>> + [ 0 -ne 0 ]
>> +
>> sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
>> el/linux/files/user-patches.scc
>
> Aha. This is the problem, if you've decided to create a local repo,
> and a BSP branch, you don't need these files outside of the tree. But
> I'm betting these were created by the BSP tool .. hence the confusion
> as two methods are being mixed.

Aha this is hardly understandable from the Yocto Documentation ...

> If you stop using the local repository, and just use the BSP tool that
> should at least clarify the error messages and I can help more after
> that.

OK If I got this right, I don't need the poky-extra stuff and no local
kernel repository.
I can just go with the yocto-bsp created meta-stamp9g20 layer? Is this
right? This would
make things much easier ...

OK to summarize it again, I have two choices

1. Use a custom branch on the linux-yocto kernel repo and poky-extra
to point to it
2. Use the standard linux-yocto kernel and a own meta-bsp layer.

And if I go with methode 2 I just my kernel config into
"meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg"?

Thank you, very much! ;-)

Re: BSP for taskit stamp9g20

[Bruce Ashfield]

On 12-06-26 09:49 AM, Markus Hubig wrote:
> On Tue, Jun 26, 2012 at 3:19 PM, Bruce Ashfield
> <bruce.ashfield@windriver.com>  wrote:
>>
>> On 12-06-26 07:08 AM, Markus Hubig wrote:
>>>
>>> AT91SAM9G20 based CPU board). This is when I came across the YoctoProject.
>>> Now I'm trying to build a BSP Layer for this Board.
>>>
>>> There are a lot of documentation out there, but I still miss the whole
>>> picture ... :-(
>>>
>>> This is what I've done so far:
>>
>> This is on master ? Yocto 1.2 ? Some other release ?
>
> I'm using Yocto 1.2 at the moment ...
>
>>> $ yocto-bsp create stamp9g20 arm
>>> ->  kernel 3.2 [y]
>>> ->  new machine branch [y]
>>> ->  machine branch to base this BSP on [standard/default/arm-versatile-926ejs]
>>> ->  Do you need SMP support? [n]
>>> ->  Which machine tuning would you like to use? [arm926ejs]
>>> ->  value for UBOOT_MACHINE [default: omap3_beagle_config]
>>> ->  UBOOT_ENTRYPOINT: [default: 0x80008000]
>>> ->  UBOOT_LOADADDRESS: [default: 0x80008000]
>>> ->  Do you need support for X? [n]
>>> ->  Does your BSP have a touchscreen? [default: n]
>>> ->  Does your BSP have a keyboard? [n]
>>>
>>> (U-Boot stuff needs some adjustments but I save this for later ...)
>>>
>>> Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
>>> step? To get the right kernel configuration for the stamp9g20 I can easily
>>> configure the kernel with:
>>>
>>> $ make ARCH=arm stamp9g20_defconfig
>>>
>>> Here is what I "think" I have to do next. Please, please correct me if I
>>> got it all wrong!
>>>
>>> # make a bare clone
>>> $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
>>> <http://git.yoctoproject.org/linux-yocto-3.2>  linux-yocto-3.2.git
>>>
>>> # make a *working clone* of the *bare clone*
>>>
>>> $ git clone linux-yocto-3.2.git linux-yocto-3.2-work
>>>
>>> # create a new branch based on arm-versatile-926ejs *inside my working
>>> clone*
>>>
>>> $ git checkout -b yocto/standard/stamp9g20
>>> remotes/origin/standard/default/arm-versatile-926ejs
>>>
>>> # push the new branch back to the *bare clone*. Now I have a branch my
>>>
>>> bsp-layer is based on?!
>>> $ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20
>>>
>>> # check out the *meta branch* inside the *working clone*
>>>
>>> $ git checkout -b meta-stamp9g20 remotes/origin/meta
>>>
>>> # now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and
>>>
>>> rename everything ...
>>> $ cd meta/cfg/kernel-cache/bsp
>>> $ cp -a arm-versatile-926ejs stamp9g20
>>> $ cd stamp9g20
>>> $ rename 's/arm-versatile-926ejs/stamp9g20/' *
>>> $ sed -i 's/arm-versatile-926ejs/stamp9g20/' *
>>>
>>> Now it get's in to the details. Since I have a working kernel config
>>> from "make ARCH=arm stamp9g20_defconfig" I *think*
>>> all I have to do is using the resulting .config file and put *parts of
>>> it* into stamp9g20.cfg, right? Later more on this, but since
>>>
>>> I'm more interested in the "big picture" I will leave these files as
>>> they are for now.
>>>
>>> # Add, commit and push the changes to the bare clone
>>> $ git add stamp9g20
>>> $ git commit -a -s
>>> $ git push origin meta-stamp9g20:meta
>>>
>>> # Now I change meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
>>> # to point to my new branch
>>> KBRANCH_stamp9g20 = "standard/default/stamp9g20"
>>> YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 = "standard/default/stamp9g20"
>>
>>
>> You don't actually have an external branch, because you made the right
>> choice to use git to manage your BSP :P So you don't need this.
>
> OK so I just remove the YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 line?
>
>>>
>>> # Clone poky-extras *into poky* ...
>>>
>>> $ git clone git://git.yoctoproject.org/poky-extras
>>> <http://git.yoctoproject.org/poky-extras>  poky-extras
>>>
>>>
>>> # edit
>>> poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
>>> KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
>>> SRC_URI =
>>> "git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>>
>>
>> This is all good, I run with this all day every day .. so far so good.
>
> OK ...
>
>>> [INFO]: checkpoint is already restored, nothing to do
>>> + [ 0 -ne 0 ]
>>> +
>>> sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
>>> el/linux/files/user-patches.scc
>>
>> Aha. This is the problem, if you've decided to create a local repo,
>> and a BSP branch, you don't need these files outside of the tree. But
>> I'm betting these were created by the BSP tool .. hence the confusion
>> as two methods are being mixed.
>
> Aha this is hardly understandable from the Yocto Documentation ...

The BSP tool came after the sections that talk about local git trees,
so the docs are still debouncing a bit. They do need to make this
clear about the approaches, and that you should use one or the other
(and why).

>
>> If you stop using the local repository, and just use the BSP tool that
>> should at least clarify the error messages and I can help more after
>> that.
>
> OK If I got this right, I don't need the poky-extra stuff and no local
> kernel repository.
> I can just go with the yocto-bsp created meta-stamp9g20 layer? Is this
> right? This would
> make things much easier ...

That's the design. But there may of course still be issues .. there
always seem to be :)

>
> OK to summarize it again, I have two choices
>
> 1. Use a custom branch on the linux-yocto kernel repo and poky-extra
> to point to it
> 2. Use the standard linux-yocto kernel and a own meta-bsp layer.
>
> And if I go with methode 2 I just my kernel config into
> "meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg"?

Yes. And in method 1, you'd just put that config into the meta branch
where you created your BSP files based on the existing BSP.

Cheers,

Bruce

>
> Thank you, very much! ;-)

Re: BSP for taskit stamp9g20

[Markus Hubig]

Yhea! My first successful build!

Thank you very much!

On Tue, Jun 26, 2012 at 4:00 PM, Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
> On 12-06-26 09:49 AM, Markus Hubig wrote:
>>
>> On Tue, Jun 26, 2012 at 3:19 PM, Bruce Ashfield
>> <bruce.ashfield@windriver.com>  wrote:
>>>
>>>
>>> On 12-06-26 07:08 AM, Markus Hubig wrote:
>>>>
>>>>
>>>> AT91SAM9G20 based CPU board). This is when I came across the
>>>> YoctoProject.
>>>> Now I'm trying to build a BSP Layer for this Board.
>>>>
>>>> There are a lot of documentation out there, but I still miss the whole
>>>> picture ... :-(
>>>>
>>>> This is what I've done so far:
>>>
>>>
>>> This is on master ? Yocto 1.2 ? Some other release ?
>>
>>
>> I'm using Yocto 1.2 at the moment ...
>>
>>>> $ yocto-bsp create stamp9g20 arm
>>>> ->  kernel 3.2 [y]
>>>> ->  new machine branch [y]
>>>> ->  machine branch to base this BSP on
>>>> [standard/default/arm-versatile-926ejs]
>>>> ->  Do you need SMP support? [n]
>>>> ->  Which machine tuning would you like to use? [arm926ejs]
>>>> ->  value for UBOOT_MACHINE [default: omap3_beagle_config]
>>>> ->  UBOOT_ENTRYPOINT: [default: 0x80008000]
>>>> ->  UBOOT_LOADADDRESS: [default: 0x80008000]
>>>> ->  Do you need support for X? [n]
>>>> ->  Does your BSP have a touchscreen? [default: n]
>>>> ->  Does your BSP have a keyboard? [n]
>>>>
>>>> (U-Boot stuff needs some adjustments but I save this for later ...)
>>>>
>>>> Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
>>>> step? To get the right kernel configuration for the stamp9g20 I can
>>>> easily
>>>> configure the kernel with:
>>>>
>>>> $ make ARCH=arm stamp9g20_defconfig
>>>>
>>>> Here is what I "think" I have to do next. Please, please correct me if I
>>>> got it all wrong!
>>>>
>>>> # make a bare clone
>>>> $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
>>>> <http://git.yoctoproject.org/linux-yocto-3.2>  linux-yocto-3.2.git
>>>>
>>>> # make a *working clone* of the *bare clone*
>>>>
>>>> $ git clone linux-yocto-3.2.git linux-yocto-3.2-work
>>>>
>>>> # create a new branch based on arm-versatile-926ejs *inside my working
>>>> clone*
>>>>
>>>> $ git checkout -b yocto/standard/stamp9g20
>>>> remotes/origin/standard/default/arm-versatile-926ejs
>>>>
>>>> # push the new branch back to the *bare clone*. Now I have a branch my
>>>>
>>>> bsp-layer is based on?!
>>>> $ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20
>>>>
>>>> # check out the *meta branch* inside the *working clone*
>>>>
>>>> $ git checkout -b meta-stamp9g20 remotes/origin/meta
>>>>
>>>> # now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and
>>>>
>>>> rename everything ...
>>>> $ cd meta/cfg/kernel-cache/bsp
>>>> $ cp -a arm-versatile-926ejs stamp9g20
>>>> $ cd stamp9g20
>>>> $ rename 's/arm-versatile-926ejs/stamp9g20/' *
>>>> $ sed -i 's/arm-versatile-926ejs/stamp9g20/' *
>>>>
>>>> Now it get's in to the details. Since I have a working kernel config
>>>> from "make ARCH=arm stamp9g20_defconfig" I *think*
>>>> all I have to do is using the resulting .config file and put *parts of
>>>> it* into stamp9g20.cfg, right? Later more on this, but since
>>>>
>>>> I'm more interested in the "big picture" I will leave these files as
>>>> they are for now.
>>>>
>>>> # Add, commit and push the changes to the bare clone
>>>> $ git add stamp9g20
>>>> $ git commit -a -s
>>>> $ git push origin meta-stamp9g20:meta
>>>>
>>>> # Now I change
>>>> meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
>>>> # to point to my new branch
>>>> KBRANCH_stamp9g20 = "standard/default/stamp9g20"
>>>> YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 = "standard/default/stamp9g20"
>>>
>>>
>>>
>>> You don't actually have an external branch, because you made the right
>>> choice to use git to manage your BSP :P So you don't need this.
>>
>>
>> OK so I just remove the YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 line?
>>
>>>>
>>>> # Clone poky-extras *into poky* ...
>>>>
>>>> $ git clone git://git.yoctoproject.org/poky-extras
>>>> <http://git.yoctoproject.org/poky-extras>  poky-extras
>>>>
>>>>
>>>> # edit
>>>>
>>>> poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
>>>> KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
>>>> SRC_URI =
>>>>
>>>> "git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>>>
>>>
>>>
>>> This is all good, I run with this all day every day .. so far so good.
>>
>>
>> OK ...
>>
>>>> [INFO]: checkpoint is already restored, nothing to do
>>>> + [ 0 -ne 0 ]
>>>> +
>>>>
>>>> sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
>>>>
>>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
>>>>
>>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
>>>>
>>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
>>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
>>>> el/linux/files/user-patches.scc
>>>
>>>
>>> Aha. This is the problem, if you've decided to create a local repo,
>>> and a BSP branch, you don't need these files outside of the tree. But
>>> I'm betting these were created by the BSP tool .. hence the confusion
>>> as two methods are being mixed.
>>
>>
>> Aha this is hardly understandable from the Yocto Documentation ...
>
>
> The BSP tool came after the sections that talk about local git trees,
> so the docs are still debouncing a bit. They do need to make this
> clear about the approaches, and that you should use one or the other
> (and why).
>
>
>>
>>> If you stop using the local repository, and just use the BSP tool that
>>> should at least clarify the error messages and I can help more after
>>> that.
>>
>>
>> OK If I got this right, I don't need the poky-extra stuff and no local
>> kernel repository.
>> I can just go with the yocto-bsp created meta-stamp9g20 layer? Is this
>> right? This would
>> make things much easier ...
>
>
> That's the design. But there may of course still be issues .. there
> always seem to be :)
>
>
>>
>> OK to summarize it again, I have two choices
>>
>> 1. Use a custom branch on the linux-yocto kernel repo and poky-extra
>> to point to it
>> 2. Use the standard linux-yocto kernel and a own meta-bsp layer.
>>
>> And if I go with methode 2 I just my kernel config into
>> "meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg"?
>
>
> Yes. And in method 1, you'd just put that config into the meta branch
> where you created your BSP files based on the existing BSP.
>
> Cheers,
>
> Bruce
>
>
>>
>> Thank you, very much! ;-)
>
>



-- 
__________________________________________________________________

IMKO Micromodultechnik GmbH
Markus Hubig
Development & Research
Im Stoeck 2
D-76275 Ettlingen / GERMANY

HR: HRB 360936 Amtsgericht Mannheim
President: Dipl.-Ing. (FH) Kurt Koehler

Tel: 0049-(0)7243-5921-26
Fax: 0049-(0)7243-5921-40
e-mail: mhubig@imko.de
internet: www.imko.de
_________________________________________________________________

Re: BSP for taskit stamp9g20

[Bruce Ashfield]

On 12-06-26 10:56 AM, Markus Hubig wrote:
> Yhea! My first successful build!
>
> Thank you very much!

nice! and no problem at all.

Cheers,

Bruce

>
> On Tue, Jun 26, 2012 at 4:00 PM, Bruce Ashfield
> <bruce.ashfield@windriver.com>  wrote:
>> On 12-06-26 09:49 AM, Markus Hubig wrote:
>>>
>>> On Tue, Jun 26, 2012 at 3:19 PM, Bruce Ashfield
>>> <bruce.ashfield@windriver.com>    wrote:
>>>>
>>>>
>>>> On 12-06-26 07:08 AM, Markus Hubig wrote:
>>>>>
>>>>>
>>>>> AT91SAM9G20 based CPU board). This is when I came across the
>>>>> YoctoProject.
>>>>> Now I'm trying to build a BSP Layer for this Board.
>>>>>
>>>>> There are a lot of documentation out there, but I still miss the whole
>>>>> picture ... :-(
>>>>>
>>>>> This is what I've done so far:
>>>>
>>>>
>>>> This is on master ? Yocto 1.2 ? Some other release ?
>>>
>>>
>>> I'm using Yocto 1.2 at the moment ...
>>>
>>>>> $ yocto-bsp create stamp9g20 arm
>>>>> ->    kernel 3.2 [y]
>>>>> ->    new machine branch [y]
>>>>> ->    machine branch to base this BSP on
>>>>> [standard/default/arm-versatile-926ejs]
>>>>> ->    Do you need SMP support? [n]
>>>>> ->    Which machine tuning would you like to use? [arm926ejs]
>>>>> ->    value for UBOOT_MACHINE [default: omap3_beagle_config]
>>>>> ->    UBOOT_ENTRYPOINT: [default: 0x80008000]
>>>>> ->    UBOOT_LOADADDRESS: [default: 0x80008000]
>>>>> ->    Do you need support for X? [n]
>>>>> ->    Does your BSP have a touchscreen? [default: n]
>>>>> ->    Does your BSP have a keyboard? [n]
>>>>>
>>>>> (U-Boot stuff needs some adjustments but I save this for later ...)
>>>>>
>>>>> Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
>>>>> step? To get the right kernel configuration for the stamp9g20 I can
>>>>> easily
>>>>> configure the kernel with:
>>>>>
>>>>> $ make ARCH=arm stamp9g20_defconfig
>>>>>
>>>>> Here is what I "think" I have to do next. Please, please correct me if I
>>>>> got it all wrong!
>>>>>
>>>>> # make a bare clone
>>>>> $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
>>>>> <http://git.yoctoproject.org/linux-yocto-3.2>    linux-yocto-3.2.git
>>>>>
>>>>> # make a *working clone* of the *bare clone*
>>>>>
>>>>> $ git clone linux-yocto-3.2.git linux-yocto-3.2-work
>>>>>
>>>>> # create a new branch based on arm-versatile-926ejs *inside my working
>>>>> clone*
>>>>>
>>>>> $ git checkout -b yocto/standard/stamp9g20
>>>>> remotes/origin/standard/default/arm-versatile-926ejs
>>>>>
>>>>> # push the new branch back to the *bare clone*. Now I have a branch my
>>>>>
>>>>> bsp-layer is based on?!
>>>>> $ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20
>>>>>
>>>>> # check out the *meta branch* inside the *working clone*
>>>>>
>>>>> $ git checkout -b meta-stamp9g20 remotes/origin/meta
>>>>>
>>>>> # now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and
>>>>>
>>>>> rename everything ...
>>>>> $ cd meta/cfg/kernel-cache/bsp
>>>>> $ cp -a arm-versatile-926ejs stamp9g20
>>>>> $ cd stamp9g20
>>>>> $ rename 's/arm-versatile-926ejs/stamp9g20/' *
>>>>> $ sed -i 's/arm-versatile-926ejs/stamp9g20/' *
>>>>>
>>>>> Now it get's in to the details. Since I have a working kernel config
>>>>> from "make ARCH=arm stamp9g20_defconfig" I *think*
>>>>> all I have to do is using the resulting .config file and put *parts of
>>>>> it* into stamp9g20.cfg, right? Later more on this, but since
>>>>>
>>>>> I'm more interested in the "big picture" I will leave these files as
>>>>> they are for now.
>>>>>
>>>>> # Add, commit and push the changes to the bare clone
>>>>> $ git add stamp9g20
>>>>> $ git commit -a -s
>>>>> $ git push origin meta-stamp9g20:meta
>>>>>
>>>>> # Now I change
>>>>> meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
>>>>> # to point to my new branch
>>>>> KBRANCH_stamp9g20 = "standard/default/stamp9g20"
>>>>> YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 = "standard/default/stamp9g20"
>>>>
>>>>
>>>>
>>>> You don't actually have an external branch, because you made the right
>>>> choice to use git to manage your BSP :P So you don't need this.
>>>
>>>
>>> OK so I just remove the YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 line?
>>>
>>>>>
>>>>> # Clone poky-extras *into poky* ...
>>>>>
>>>>> $ git clone git://git.yoctoproject.org/poky-extras
>>>>> <http://git.yoctoproject.org/poky-extras>    poky-extras
>>>>>
>>>>>
>>>>> # edit
>>>>>
>>>>> poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
>>>>> KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
>>>>> SRC_URI =
>>>>>
>>>>> "git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>>>>
>>>>
>>>>
>>>> This is all good, I run with this all day every day .. so far so good.
>>>
>>>
>>> OK ...
>>>
>>>>> [INFO]: checkpoint is already restored, nothing to do
>>>>> + [ 0 -ne 0 ]
>>>>> +
>>>>>
>>>>> sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
>>>>>
>>>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
>>>>>
>>>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
>>>>>
>>>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
>>>>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
>>>>> el/linux/files/user-patches.scc
>>>>
>>>>
>>>> Aha. This is the problem, if you've decided to create a local repo,
>>>> and a BSP branch, you don't need these files outside of the tree. But
>>>> I'm betting these were created by the BSP tool .. hence the confusion
>>>> as two methods are being mixed.
>>>
>>>
>>> Aha this is hardly understandable from the Yocto Documentation ...
>>
>>
>> The BSP tool came after the sections that talk about local git trees,
>> so the docs are still debouncing a bit. They do need to make this
>> clear about the approaches, and that you should use one or the other
>> (and why).
>>
>>
>>>
>>>> If you stop using the local repository, and just use the BSP tool that
>>>> should at least clarify the error messages and I can help more after
>>>> that.
>>>
>>>
>>> OK If I got this right, I don't need the poky-extra stuff and no local
>>> kernel repository.
>>> I can just go with the yocto-bsp created meta-stamp9g20 layer? Is this
>>> right? This would
>>> make things much easier ...
>>
>>
>> That's the design. But there may of course still be issues .. there
>> always seem to be :)
>>
>>
>>>
>>> OK to summarize it again, I have two choices
>>>
>>> 1. Use a custom branch on the linux-yocto kernel repo and poky-extra
>>> to point to it
>>> 2. Use the standard linux-yocto kernel and a own meta-bsp layer.
>>>
>>> And if I go with methode 2 I just my kernel config into
>>> "meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg"?
>>
>>
>> Yes. And in method 1, you'd just put that config into the meta branch
>> where you created your BSP files based on the existing BSP.
>>
>> Cheers,
>>
>> Bruce
>>
>>
>>>
>>> Thank you, very much! ;-)
>>
>>
>
>
>

Re: BSP for taskit stamp9g20

[Markus Hubig]

Hello @all,

now I have a working BSP-Layer, but for now its only a plain copy
(created with yocto-bsp)
of arm-versatile-926ejs. And the only thing it does so far, is
creating a .config-Kernel
configuration file (which is fine by now). To adapt this to my needs
it seems I have to edit the
stamp9g20.cfg and the stamp9g20-non_hardware.cfg files. Am I right?

Since I can create a valid kernel configuration by simply:

$ make ARCH=arm stamp9g20_defconfig

I'm using this file as a reverence, but now I'm having a hard time
figuring out what part of
this config file I have to put inside my BSP cfg files and what to use
from the kernel
meta/cfg/kernel-cache/features stuff via a include statement ...

I try to make an example:

In my reference config file I have this

CONFIG_HIGH_RES_TIMERS=y

This can be found here "meta/cfg/kernel-cache/features/hrt/hrt.cfg" as
a kernel feature.
So I have to add the statement "include features/hrt/hrt.scc" into
"stamp9g20.scc", right?

But wait a minute ...
$ grep -r hrt.scc linux-yocto-3.2-work/meta/cfg/kernel-cache/
   linux-yocto-3.2-work/meta/cfg/kernel-cache/ktypes/standard/standard-nocfg.scc:include
features/hrt/hrt.scc

So its already included from "ktypes/standard" ... ;-(

To get a better overview (and because I'm a famous magician) I made up
a little spell:

# Look for all kernel config parameters if they are defined somewhere inside
# linux-yocto-3.2/meta/cfg/kernel-cache/(arch|cfg|features|ktypes/base|ktypes/standard)
# if found print the matching file, if not print NOT FOUND.
for i in $(grep -v '^#' ~/Development/linux-yocto-3.2-work/.config
|grep -v '^$' | awk -F"=" '{print $1}'); do
    grep -H $i $(find arch/ cfg/ features/ ktypes/base
ktypes/standard/ -name *.cfg) || echo NOT FOUND: $i;
done | sort | uniq > ~/Development/features_all.txt

# Split the features_all.txt file into found and not found
grep -v '^NOT FOUND' features_all.txt > features_found.txt
grep '^NOT FOUND' features_all.txt > features_not_found.txt

# finally get a list of all scc files I need to include.
cat features_found.txt |awk -F':' '{print $1}' |sed \
    "s/.*\/\(.*\)\.cfg$/\1.scc/" |uniq > modules_to_include.txt

(I put all the mentioned files here: https://gist.github.com/3017292)

I guess the config variables inside features_not_found.txt are the one
I need to include into
the stamp9g20.cfg, stamp9g20-non_hardware.cfg files? (Ok except the
ones that get enabled
by some kernel dependency stuff ... but how to figure out this?)

Is there a better way to go? Maybe one where you don't have to have
magical powers? ;-)

Re: BSP for taskit stamp9g20

[Bruce Ashfield]

On 12-06-29 09:34 AM, Markus Hubig wrote:
> Hello @all,
>
> now I have a working BSP-Layer, but for now its only a plain copy
> (created with yocto-bsp)
> of arm-versatile-926ejs. And the only thing it does so far, is
> creating a .config-Kernel
> configuration file (which is fine by now). To adapt this to my needs
> it seems I have to edit the
> stamp9g20.cfg and the stamp9g20-non_hardware.cfg files. Am I right?
>
> Since I can create a valid kernel configuration by simply:
>
> $ make ARCH=arm stamp9g20_defconfig
>
> I'm using this file as a reverence, but now I'm having a hard time
> figuring out what part of
> this config file I have to put inside my BSP cfg files and what to use
> from the kernel
> meta/cfg/kernel-cache/features stuff via a include statement ...
>
> I try to make an example:
>
> In my reference config file I have this
>
> CONFIG_HIGH_RES_TIMERS=y
>
> This can be found here "meta/cfg/kernel-cache/features/hrt/hrt.cfg" as
> a kernel feature.
> So I have to add the statement "include features/hrt/hrt.scc" into
> "stamp9g20.scc", right?
>
> But wait a minute ...
> $ grep -r hrt.scc linux-yocto-3.2-work/meta/cfg/kernel-cache/
>     linux-yocto-3.2-work/meta/cfg/kernel-cache/ktypes/standard/standard-nocfg.scc:include
> features/hrt/hrt.scc
>
> So its already included from "ktypes/standard" ... ;-(
>
> To get a better overview (and because I'm a famous magician) I made up
> a little spell:
>
> # Look for all kernel config parameters if they are defined somewhere inside
> # linux-yocto-3.2/meta/cfg/kernel-cache/(arch|cfg|features|ktypes/base|ktypes/standard)
> # if found print the matching file, if not print NOT FOUND.
> for i in $(grep -v '^#' ~/Development/linux-yocto-3.2-work/.config
> |grep -v '^$' | awk -F"=" '{print $1}'); do
>      grep -H $i $(find arch/ cfg/ features/ ktypes/base
> ktypes/standard/ -name *.cfg) || echo NOT FOUND: $i;
> done | sort | uniq>  ~/Development/features_all.txt
>
> # Split the features_all.txt file into found and not found
> grep -v '^NOT FOUND' features_all.txt>  features_found.txt
> grep '^NOT FOUND' features_all.txt>  features_not_found.txt
>
> # finally get a list of all scc files I need to include.
> cat features_found.txt |awk -F':' '{print $1}' |sed \
>      "s/.*\/\(.*\)\.cfg$/\1.scc/" |uniq>  modules_to_include.txt
>
> (I put all the mentioned files here: https://gist.github.com/3017292)
>
> I guess the config variables inside features_not_found.txt are the one
> I need to include into
> the stamp9g20.cfg, stamp9g20-non_hardware.cfg files? (Ok except the
> ones that get enabled

I wouldn't say that, was your input .config a minimal defconfig ?
You really don't need to list option in your BSPs configuration that
are not already defined, are not hardware and are the default
selection of the kernel already.

There are also the on-target scripts and techniques for streamling
your configuration that can result in a smaller input .config that you'd
feed to any process for streamlining a board's configuration.

> by some kernel dependency stuff ... but how to figure out this?)
>
> Is there a better way to go? Maybe one where you don't have to have
> magical powers? ;-)

There are few things that can help here:

   - I've just revived a script that takes a defconfig that has been
     fed to the kernel auditing subsystem and breaks it apart into the
     options that you really do or don't need in your BSP config

   - A lot of work on kernel configuration updating and policy has
     happened in the 3.4 kernel, and will be part of yocto 1.3. As part
     of that, the policy options (what you inherit), will be clear, or
     discoverable by script, as will optional and hardware configuration
     items.

   - there is a kernel-features.rc file that is part of the meta branch
     that will be further exposed. It lists all of the configuration
     fragments, with a description and whether or not they can be
     optionally included.

The end goal is that a developer / BSP that wants a quick bootstrap on
top of the existing configuration can just focus on the options that
make their board work and initially not be concerned with those software/
policy option .. until you get into a tuning phase on a BSP. Having
visibility and some scripts around this is part of the implementation
of that goal.

Cheers,

Bruce

> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: BSP for taskit stamp9g20

[Markus Hubig]

On Fri, Jun 29, 2012 at 3:47 PM, Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
>
> On 12-06-29 09:34 AM, Markus Hubig wrote:
>>
>> I guess the config variables inside features_not_found.txt are the one
>> I need to include into
>> the stamp9g20.cfg, stamp9g20-non_hardware.cfg files? (Ok except the
>> ones that get enabled
>
> I wouldn't say that, was your input .config a minimal defconfig ?

Hmm yes (or no) it's the .config file that gets created with
make ARCH=arm stamp9g20_defconfig. I doubt this is minimal,
but that's the only reference I have.

Uhh, I found something more minimal:

linux-yocto-3.2-work/arch/arm/configs/stamp9g20_defconfig

maybe this is what I need? (just 129 lines ;-)

> You really don't need to list option in your BSPs configuration that
> are not already defined, are not hardware and are the default
> selection of the kernel already.

Hmm ok ... I'll put my BSP repo online later today and maybe you can
take a quick look if it's ok? This would be really helpfull! ;-)

> There are also the on-target scripts and techniques for streamling
> your configuration that can result in a smaller input .config that you'd
> feed to any process for streamlining a board's configuration.
>
>> by some kernel dependency stuff ... but how to figure out this?)
>>
>> Is there a better way to go? Maybe one where you don't have to have
>> magical powers? ;-)
>
> There are few things that can help here:
>
>  - I've just revived a script that takes a defconfig that has been
>    fed to the kernel auditing subsystem and breaks it apart into the
>    options that you really do or don't need in your BSP config

Oh I would really like to try this! This would be really helpful for me,
and I think there are a lot of people out there who have a working
kernel .config file (like I do) and are looking for an easy way to
include this into a BSP. And the most relevant information one needs
to do so are (IMHO):

1. What config options can I ignore because there are handled by yocto.
2. What config options can I ignore because there are set by dependencies.
3. What config options do I absolutely have to set.

>  - A lot of work on kernel configuration updating and policy has
>    happened in the 3.4 kernel, and will be part of yocto 1.3. As part
>    of that, the policy options (what you inherit), will be clear, or
>    discoverable by script, as will optional and hardware configuration
>    items.

I wish I could have this now ... looking forward to it!

>  - there is a kernel-features.rc file that is part of the meta branch
>    that will be further exposed. It lists all of the configuration
>    fragments, with a description and whether or not they can be
>    optionally included.
>
> The end goal is that a developer / BSP that wants a quick bootstrap on
> top of the existing configuration can just focus on the options that
> make their board work and initially not be concerned with those software/
> policy option .. until you get into a tuning phase on a BSP. Having
> visibility and some scripts around this is part of the implementation
> of that goal.

Thank you for this explanation!

- Markus

Re: BSP for taskit stamp9g20

[Markus Hubig]

Hello @all, hello Bruce!

https://bitbucket.org/imko/meta-stamp9g20

here you can find my first attempt of a BSP for the taskit stamp9g20 and
portuxg20 Board. Until now there is only the kernel part. Please have a look
and give comments.

Thanks, Markus

Re: BSP for taskit stamp9g20

[Bruce Ashfield]

On 12-06-29 11:08 AM, Markus Hubig wrote:
> On Fri, Jun 29, 2012 at 3:47 PM, Bruce Ashfield
> <bruce.ashfield@windriver.com>  wrote:
>>
>> On 12-06-29 09:34 AM, Markus Hubig wrote:
>>>
>>> I guess the config variables inside features_not_found.txt are the one
>>> I need to include into
>>> the stamp9g20.cfg, stamp9g20-non_hardware.cfg files? (Ok except the
>>> ones that get enabled
>>
>> I wouldn't say that, was your input .config a minimal defconfig ?
>
> Hmm yes (or no) it's the .config file that gets created with
> make ARCH=arm stamp9g20_defconfig. I doubt this is minimal,
> but that's the only reference I have.
>
> Uhh, I found something more minimal:
>
> linux-yocto-3.2-work/arch/arm/configs/stamp9g20_defconfig
>
> maybe this is what I need? (just 129 lines ;-)

At times .. smaller is better, at least it's less to sort in this case.
Plus it lets the default yocto kernel policy make it through the the
.config without any intervention required.

>
>> You really don't need to list option in your BSPs configuration that
>> are not already defined, are not hardware and are the default
>> selection of the kernel already.
>
> Hmm ok ... I'll put my BSP repo online later today and maybe you can
> take a quick look if it's ok? This would be really helpfull! ;-)

I can definitely have a look, I've reviewed several hundred of these
over the years .. so I know what to look for :)

>
>> There are also the on-target scripts and techniques for streamling
>> your configuration that can result in a smaller input .config that you'd
>> feed to any process for streamlining a board's configuration.
>>
>>> by some kernel dependency stuff ... but how to figure out this?)
>>>
>>> Is there a better way to go? Maybe one where you don't have to have
>>> magical powers? ;-)
>>
>> There are few things that can help here:
>>
>>   - I've just revived a script that takes a defconfig that has been
>>     fed to the kernel auditing subsystem and breaks it apart into the
>>     options that you really do or don't need in your BSP config
>
> Oh I would really like to try this! This would be really helpful for me,
> and I think there are a lot of people out there who have a working
> kernel .config file (like I do) and are looking for an easy way to
> include this into a BSP. And the most relevant information one needs
> to do so are (IMHO):
>
> 1. What config options can I ignore because there are handled by yocto.
> 2. What config options can I ignore because there are set by dependencies.
> 3. What config options do I absolutely have to set.

Agreed, and I'm working to address this with some scripts that both
work on the config, and can report the policy options clearly. The script
is quite raw at the moment, and needs work, but it is better than
nothing.

>
>>   - A lot of work on kernel configuration updating and policy has
>>     happened in the 3.4 kernel, and will be part of yocto 1.3. As part
>>     of that, the policy options (what you inherit), will be clear, or
>>     discoverable by script, as will optional and hardware configuration
>>     items.
>
> I wish I could have this now ... looking forward to it!
>
>>   - there is a kernel-features.rc file that is part of the meta branch
>>     that will be further exposed. It lists all of the configuration
>>     fragments, with a description and whether or not they can be
>>     optionally included.
>>
>> The end goal is that a developer / BSP that wants a quick bootstrap on
>> top of the existing configuration can just focus on the options that
>> make their board work and initially not be concerned with those software/
>> policy option .. until you get into a tuning phase on a BSP. Having
>> visibility and some scripts around this is part of the implementation
>> of that goal.
>
> Thank you for this explanation!

No problem, it is this sort of thing that shows where the gaps are, and
where we should spend time improving things.

Cheers,

Bruce

>
> - Markus
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: BSP for taskit stamp9g20

[Bruce Ashfield]

On 12-06-29 01:19 PM, Markus Hubig wrote:
> Hello @all, hello Bruce!
>
> https://bitbucket.org/imko/meta-stamp9g20
>
> here you can find my first attempt of a BSP for the taskit stamp9g20 and
> portuxg20 Board. Until now there is only the kernel part. Please have a look
> and give comments.

I had a look, and it is definitely a good start. I can see that it
is still a work in progress, since you have one unreferenced file
(stamp9g20-non_hardware.cfg) and a few zero byte files in for the
kernel board description.

The board description looks good, standard, -rt kernels and hardware
configurations. If you do end up with board patches you would want
to update the stamp9g20-preempt-rt.scc with 'branch stamp9g20' after
the ktype include. The re-use of the -rt base branch is in some of the
basic BSPs to show how we can do it, but if you actually patch the
kernel, you'd want to keep them separate (typically).

stamp9g20.cfg actually looks pretty good. Those are hardware or board
specific settings, so generally speaking, they are fine in a board
configuration.

Taking it to the shiny new 3.4 kernel is also something to consider! :)

Cheers,

Bruce


>
> Thanks, Markus
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto