[yocto] initramfs support in Yocto
Hello all, Does Yocto support initramfs build? Best Regards, Zhenhua ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] proper recipe for building for beagle xM? meta-ti?
Op 28 feb. 2012, om 23:28 heeft Robert P. J. Day het volgende geschreven: > On Tue, 28 Feb 2012, Koen Kooi wrote: > >> >> Op 28 feb. 2012, om 22:55 heeft Robert P. J. Day het volgende geschreven: >> >>> On Tue, 28 Feb 2012, Bruce Ashfield wrote: >>> It is true that the beagleboard is a hardware reference board in the yocto consolidated kernel tree and meta-yocto layers. That means that it gets the yocto standard QA builds and boot testing. That being said, if you are looking for the latest + specific features then you've been pointed in a good direction .. meta-ti will meet your needs. As for disentangling and reducing questions in this area .. rest assured, we are working on it. >>> >>> ok, that's perfectly reasonable -- meta-yocto provides a generic, >>> well-tested product, while the meta-ti layer provides more >>> leading-edge content, correct? >> >> No, the amount of testing is not the difference, the amount of >> support for the board is. Meta-ti supports the camera interfaces, 3d >> engine, dsp, crypto engines, expansion boards, etc. Meta-yocto lacks >> all that for beagleboard. > > i understand that reasonably well, and i'll make one more > observation, then i'll shut up. > > i cloned the meta-ti layer into my yocto clone, and here's the > majority of the meta-ti README: > > = start > > This layer depends on: > > URI: git://git.openembedded.org/openembedded-core > branch: master > revision: HEAD > > URI: git://git.openembedded.org/meta-openembedded > branch: master > revision: HEAD > > URI: git://git.angstrom-distribution.org/meta-angstrom > branch: master > revision: HEAD > > Currently meta-ti only works with the Angstrom distribution and hence > requires the meta-angstrom layer. There are known issues when using > gcc-4.6 based toolchain from OpenEmbedded-Core, thus gcc-4.5 > toolchain, provided by meta-openembedded, is needed. It is planned to > fix these shortcomings in the near future and allow building the base > BSP part of meta-ti with different distributions and layer stacks, > such as: distro-less (only with OE-Core), with Yocto/Poky, with > Angstrom or Arago. > > Due to the above, it is now recommended to follow the instructions at > http://www.angstrom-distribution.org/building-angstrom > > This will set it up for the OpenEmbedded-core layout instead of the > old "Classic" OpenEmbedded-dev layout. You can optionally tweak > sources/layers.txt and conf/bblayers.conf to (de)select BSP layers. > > = end > > by the time i'm done reading that, i'm not sure whether i've been > told i can use yocto as long as i do the necessary prep first, or that > i should give up on yocto and just use angstrom directly. Well, if you use the angstrom setupscript you get 'yocto'. Your phrasing seems to suggest you are confusing 'yocto' with 'poky', which is a common mistake. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] simplest recipe for running yocto qemu images?
i want to do a short writeup on the *simplest* recipe for how to run the pre-built yocto qemu image you can get here: http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/qemu/ and what should have been a simple procedure got a bit messy. to be clear, i want to document the absolute *least* you need to do to run a yocto-built qemu image without having to build anything since, technically, you shouldn't have to. i'm aware of the writeup in the quick start guide, but that seems like overkill based on what i'm trying to do. so here's what i just went through. first, starting with a fresh terminal window totally unconfigured for yocto, download a matching kernel image and rootfs; in my case, just for fun, i downloaded for arm: * zImage-qemuarm.bin * core-image-minimal-qemuarm.ext3 now that i have that, the obvious next step is to use the convenient "runqemu" wrapper in my yocto directory, so i'll extend my search path: $ PATH=~/yocto/git/scripts:$PATH and i'll turn on shell debugging in that "runqemu" script and test it out: $ runqemu qemuarm \ zImage-2.6.37-qemuarm-1.0.bin \ core-image-minimal-qemuarm.ext3 ... snip ... /home/rpjday/yocto/git/scripts/bitbake: line 106: -e: command not found + TMPDIR= + '[' -z '' ']' + echo 'Error: this script needs to be run from your build directory,' Error: this script needs to be run from your build directory, + echo 'or you need to explicitly set TMPDIR in your environment' or you need to explicitly set TMPDIR in your environment + exit 1 $ ok, not sure why simply running a qemu image requires invoking bitbake, but the error message looks pretty straightforward, so i'll fix that and try again: $ TMPDIR=/tmp runqemu qemuarm \ zImage-2.6.37-qemuarm-1.0.bin \ core-image-minimal-qemuarm.ext3 ... snip ... /home/rpjday/yocto/git/scripts/bitbake: line 106: -e: command not found + TMPDIR= + '[' -z '' ']' + echo 'Error: this script needs to be run from your build directory,' Error: this script needs to be run from your build directory, + echo 'or you need to explicitly set TMPDIR in your environment' or you need to explicitly set TMPDIR in your environment + exit 1 $ well, that appeared to solve nothing despite the fact that i did *exactly* what the earlier diagnostic suggested. oh, wait, there's this earlier in "runqemu": # Don't use TMPDIR from the external environment, it may be a distro # variable pointing to /tmp (e.g. within X on OpenSUSE) # Instead, use OE_TMPDIR for passing this in externally. TMPDIR="$OE_TMPDIR" g. ok, let's set OE_TMPDIR instead, whereupon we make considerably more progress until: ... snip ... ++ tap='Error: Unable to find tunctl binary in '\''/tmp/sysroots/x86_64-linux/usr/bin'\''' ++ '[' 1 -ne 0 ']' ++ sudo /home/rpjday/yocto/git/scripts/runqemu-ifup 1000 /tmp/sysroots/x86_64-linux Error: Unable to find tunctl binary in '/tmp/sysroots/x86_64-linux/usr/bin' ++ return $ which is actually fine since, obviously, i need to have an appropriate sysroot directory in my PATH to pick up commands liek "tunctl" and so on. no problem -- i've installed the appropriate ARM toolchain under /opt/poky so: $ PATH=/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin:$PATH $ type tunctl tunctl is /opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/tunctl $ all right, away we go again: $ OE_TMPDIR=/tmp runqemu \ qemuarm zImage-2.6.37-qemuarm-1.0.bin \ core-image-minimal-qemuarm.ext3 ... snip ... /home/rpjday/yocto/git/scripts/bitbake: line 106: -e: command not found Error: this script needs to be run from your build directory, or you need to explicitly set TMPDIR in your environment $ wait, i thought i took care of that. oh ... $ type runqemu runqemu is hashed (/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/runqemu) $ so now i'm picking up "runqemu" from the toolchain's sysroot directory, which does *not* have the OE_TMPDIR reference, only the earlier TMPDIR one. so let's completely remove my yocto install scripts directory from my search path, and use *only* the sysroots directory: $ PATH=/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin:$PATH $ TMPDIR=/tmp runqemu qemuarm \ zImage-2.6.37-qemuarm-1.0.bin \ core-image-minimal-qemuarm.ext3 ... snip ... Setting up tap interface under sudo +++ sudo /opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/runqemu-ifup 1000 /tmp/sysroots/x86_64-linux ++ tap='Error: Unable to find tunctl binary in '\''/tmp/sysroots/x86_64-linux/usr/bin'\''' ++ '[' 1 -ne 0 ']' ++ sudo /opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/runqemu-ifup 1000 /tmp/sysroots/x86_64-linux Error: Unable to find tunctl binary in '/tmp/sysroots/x86_64-linux/usr/bin' ++ return $ ok, it *has* to be easier than this. quite simply, if one wants to do nothing more than *run* one of those qemu images, there should be no need to do any building or bitbaking, should there? am i missing something hideously obvious? rday -- =
Re: [yocto] simplest recipe for running yocto qemu images?
On Friday 02 March 2012 06:57:57 Robert P. J. Day wrote: > ok, it *has* to be easier than this. quite simply, if one wants to > do nothing more than *run* one of those qemu images, there should be > no need to do any building or bitbaking, should there? am i missing > something hideously obvious? Only that we assume you *have* built the image in order to be able to use the runqemu script. If you haven't, well, you won't necessarily have some of the utilities the script looks for (e.g. tunctl). When the script looks for TMPDIR it is not looking for a temporary directory, it's looking for the TMPDIR that would have been set in your local.conf. The runqemu script just isn't designed to be used in the way that you're trying to use it. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] simplest recipe for running yocto qemu images?
On Fri, 2 Mar 2012, Paul Eggleton wrote: > On Friday 02 March 2012 06:57:57 Robert P. J. Day wrote: > > ok, it *has* to be easier than this. quite simply, if one wants > > to do nothing more than *run* one of those qemu images, there > > should be no need to do any building or bitbaking, should there? > > am i missing something hideously obvious? > > Only that we assume you *have* built the image in order to be able > to use the runqemu script. If you haven't, well, you won't > necessarily have some of the utilities the script looks for (e.g. > tunctl). When the script looks for TMPDIR it is not looking for a > temporary directory, it's looking for the TMPDIR that would have > been set in your local.conf. > > The runqemu script just isn't designed to be used in the way that > you're trying to use it. i gathered that. but is it unreasonable to suggest that this is something that *should* be easy to do? if new users simply want to see what a yocto-generated image looks like under qemu, shouldn't there be a way to let them do that without going through an entire build? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] simplest recipe for running yocto qemu images?
On Friday 02 March 2012 07:16:08 Robert P. J. Day wrote: > i gathered that. but is it unreasonable to suggest that this is > something that *should* be easy to do? if new users simply want to > see what a yocto-generated image looks like under qemu, shouldn't > there be a way to let them do that without going through an entire > build? I see what you're saying, but the problem with this is the qemu version we build is not the same as qemu that might be installed on the host machine. We apply quite a number of patches to qemu in order to support features we need (such as GL); if you allow beginners to easily use something else then it just makes support harder because certain things that normally work in the current setup will not work when the host tools are being used instead. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] simplest recipe for running yocto qemu images?
On Fri, 2 Mar 2012, Paul Eggleton wrote: > On Friday 02 March 2012 07:16:08 Robert P. J. Day wrote: > > i gathered that. but is it unreasonable to suggest that this is > > something that *should* be easy to do? if new users simply want to > > see what a yocto-generated image looks like under qemu, shouldn't > > there be a way to let them do that without going through an entire > > build? > > I see what you're saying, but the problem with this is the qemu > version we build is not the same as qemu that might be installed on > the host machine. We apply quite a number of patches to qemu in > order to support features we need (such as GL); if you allow > beginners to easily use something else then it just makes support > harder because certain things that normally work in the current > setup will not work when the host tools are being used instead. i briefly saw your point until i noticed that the yocto toolchain i installed comes with qemu-system-* executables, which would take precedence over the normal host ones, so i'm still skeptical. i'm going to mess with this a bit longer since i can't believe it should be hard to tweak this to get it to work. no matter what happens, i'm sure i'll come out of it smarter. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] simplest recipe for running yocto qemu images? [SOLVED]
On Fri, 2 Mar 2012, Paul Eggleton wrote: > On Friday 02 March 2012 07:16:08 Robert P. J. Day wrote: > > i gathered that. but is it unreasonable to suggest that this is > > something that *should* be easy to do? if new users simply want to > > see what a yocto-generated image looks like under qemu, shouldn't > > there be a way to let them do that without going through an entire > > build? > > I see what you're saying, but the problem with this is the qemu > version we build is not the same as qemu that might be installed on > the host machine. We apply quite a number of patches to qemu in > order to support features we need (such as GL); if you allow > beginners to easily use something else then it just makes support > harder because certain things that normally work in the current > setup will not work when the host tools are being used instead. just for fun, i addressed the only thing that was stopping me, and that was that runqemu was looking for a slightly different sysroots directory name than the toolchain provided, so: /opt/poky/1.1/sysroots$ sudo ln -s x86_64-pokysdk-linux/ x86_64-linux and then ran: $ TMPDIR=/opt/poky/1.1 runqemu qemuarm zImage-2.6.37-qemuarm-1.0.bin core-image-minimal-qemuarm.ext3 and it worked. yes, i'm sure i'm abusing all sorts of things but, in the end, once i dug through it, it seemed fairly easy to get it to work. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] initramfs support in Yocto
Hi Zhenhua, On 03/02/2012 01:59 AM, Luo Zhenhua-B19537 wrote: > Hello all, > > Does Yocto support initramfs build? Can you be more specific about what you are looking for? When you build an image with the cpio.gz image type, you can boot that as an initramfs with the following kernel command line: initrd=core-image-minimal-fri2.cpio.gz root=/dev/ram0 If you are looking for something beyond that, please elaborate. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/8] Yocto BSP tools
On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote: > From: Tom Zanussi > > This patchset implements the 'yocto-bsp' and 'yocto-kernel' BSP tools > previously described in some detail in this RFC posting: > > https://lists.yoctoproject.org/pipermail/yocto/2011-December/006111.html > > With the functionality implemented by this patchset, you can: > > - create a new Yocto BSP for any architecture supported Yocto, as well > as qemu versions of the same. The default mode of operation when > invoked from the command-line is to prompt the user for information > needed to generate the BSP. For the current set of BSPs, the user > is prompted for various important parameters such as which kernel to > use, which branch of that kernel to use (or re-use), whether or not > to use X, and if so, which drivers to use, whether to turn on SMP, > whether the BSP has a keyboard, touchscreen, etc. > > There's also an option (-i) that allows all the necessary > information to be supplied directly as a JSON object instead, which > allows the built-in prompting to be bypassed. This is mainly for > use by developers of alternate UIs, such as the ADT integration that > should now be possible with what's provided here. > > (available via the 'yocto-bsp create' command) This -i approach is adequate for an initial pass. However, a python module API would be preferable. However, if the ADT integration is written in java perhaps -i is the best way as I'm not sure if any of the Python bindings for Java (JPI, JPE, ...) are robust enough for our use. > > - list the architectures available for BSP generation (using the > 'yocto-bsp list karch' command). You can also list the properties > and possible values for those properties for all the input items > needed for a given architecture in order to create a bsp. The > latter is mainly useful for developers of alternate UIs. See the > documention in the built-in help system for details of the extensive > data displayed by this command. > > (available via the 'yocto-bsp list' command) > > - add and remove kernel patches to/from the BSP, as well as list the > kernel patches attached to the active kernel recipe for the BSP. > > (available via the 'yocto-kernel patch add/rm/list' commands) > > - add and remove kernel config items to/from the BSP, as well as list > the user-defined config items attached to the active kernel recipe > for the BSP. > > (available via the 'yocto-kernel config add/rm/list' commands) > > The built-in help system that makes it easy to drill down at any time > and remind oneself of the syntax required for any specific command: > > Simply entering the name of the command, or the command along with > 'help' will display a list of the available sub-commands. For example: > > $ yocto-bsp > $ yocto-bsp help > > Usage: > > Create a customized Yocto BSP layer. > > usage: yocto-bsp [--version] [--help] COMMAND [ARGS] > > The most commonly used 'yocto-bsp' commands are: > create Create a new Yocto BSP > listList available values for options and BSP properties > > See 'yocto-bsp help COMMAND' for more information on a specific command. > > > Options: > --versionshow program's version number and exit > -h, --help show this help message and exit > -D, --debug output debug information > > > Similarly, entering just the name of the subcommand will show the > detailed usage for that command: > > $ yocto-bsp create > > Usage: > > Create a new Yocto BSP > > usage: yocto-bsp create [-o | --outdir > ] > [-i | --infile ] > > This command creates a Yocto BSP based on the specified parameters. > The new BSP will be a new Yocto BSP layer contained by default within > the top-level directory specified as 'meta-bsp-name'.The -o option > can be used to place the BSP layer in a directory with a different > name and location. > > ... > > > For any subcommand, you can also use the word 'help' just before the > subcommand to get more extensive documentation on the subcommand: > > $ yocto-bsp help create > I believe it is more typical to have the "help" argument after the command: git branch -h, for example (since you used git-like in your description). Not a big deal, but some might trip over this. > NAME > yocto-bsp create - Create a new Yocto BSP > > SYNOPSIS > yocto-bsp create [-o | --outdir ] > [-i | --infile ] > > DESCRIPTION > This command creates a Yocto BSP based on the specified > parameters. The new BSP will be a new Yocto BSP layer contained > by default within the top-level directory specified as > 'meta-bsp-name'. The -o option can be used to place the BSP layer > in a directory with a different name and location. > > The value of the 'karch' parameter determines the set of files > that will be generated for the BSP, along with the specific set of > 'properti
Re: [yocto] [PATCH 1/8] yocto-bsp: add BSP template files
On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote:
> From: Tom Zanussi
>
> BSP template files for all supported Yocto architectures, plus qemu
> versions of the same.
>
> Signed-off-by: Tom Zanussi
> ---
> .../target/arch/arm/conf/machine/{{=machine}}.conf | 87 +
> .../{{ if xserver == \"y\": }} xorg.conf" | 34 ++
> ... == \"y\": }} xserver-xf86-config_0.1.bbappend" |3 +
> .../linux/files/{{=machine}}-non_hardware.cfg | 30 ++
> .../linux/files/{{=machine}}-preempt-rt.scc|8 +
> .../linux/files/{{=machine}}-standard.scc |8 +
> .../recipes-kernel/linux/files/{{=machine}}.cfg| 336
>
> .../recipes-kernel/linux/files/{{=machine}}.scc|7 +
> .../arm/recipes-kernel/linux/kernel-list.noinstall |3 +
> ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" | 34 ++
> ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" | 34 ++
> ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" | 36 ++
> ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" | 34 ++
> .../bsp/substrate/target/arch/common/COPYING.MIT | 17 +
> .../lib/bsp/substrate/target/arch/common/README| 118 +++
> .../substrate/target/arch/common/README.sources| 17 +
> .../substrate/target/arch/common/conf/layer.conf | 10 +
> .../formfactor/formfactor/{{=machine}}/machconfig |5 +
> .../recipes-bsp/formfactor/formfactor_0.0.bbappend |3 +
> .../tasks/task-core-tools-profile.bbappend |2 +
> .../arch/i386/conf/machine/{{=machine}}.conf | 44 +++
> ...erver_choice == \"xserver_emgd\": }} xorg.conf" | 48 +++
> ...erver_choice == \"xserver_i915\": }} xorg.conf" | 26 ++
> ...erver_choice == \"xserver_vesa\": }} xorg.conf" | 26 ++
> ... == \"y\": }} xserver-xf86-config_0.1.bbappend" |3 +
> .../linux/files/{{=machine}}-preempt-rt.scc|8 +
> .../linux/files/{{=machine}}-standard.scc |8 +
> .../recipes-kernel/linux/files/{{=machine}}.cfg| 54
> .../recipes-kernel/linux/files/{{=machine}}.scc| 30 ++
> .../recipes-kernel/linux/kernel-list.noinstall |3 +
> ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" | 34 ++
> ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" | 34 ++
> ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" | 36 ++
> ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" | 34 ++
> .../arch/mips/conf/machine/{{=machine}}.conf | 28 ++
> .../linux/files/{{=machine}}-preempt-rt.scc|8 +
> .../linux/files/{{=machine}}-standard.scc |8 +
> .../recipes-kernel/linux/files/{{=machine}}.cfg|1 +
> .../recipes-kernel/linux/files/{{=machine}}.scc|8 +
> .../recipes-kernel/linux/kernel-list.noinstall |3 +
> ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" | 34 ++
> ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" | 34 ++
> ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" | 36 ++
> ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" | 34 ++
> .../arch/powerpc/conf/machine/{{=machine}}.conf| 53 +++
> .../recipes-kernel/linux/files/user-config.cfg |4 +
> .../linux/files/{{=machine}}-preempt-rt.scc|8 +
> .../linux/files/{{=machine}}-standard.scc |8 +
> .../recipes-kernel/linux/files/{{=machine}}.cfg| 163 ++
> .../recipes-kernel/linux/files/{{=machine}}.scc| 11 +
> .../recipes-kernel/linux/kernel-list.noinstall |3 +
> ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" | 34 ++
> ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" | 34 ++
> ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" | 36 ++
> ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" | 34 ++
> .../arch/qemu/conf/machine/{{=machine}}.conf | 59
> .../xserver-xf86-config/{{=machine}}/xorg.conf | 69
> ..."x86_64\": }} xserver-xf86-config_0.1.bbappend" |2 +
> .../recipes-kernel/linux/files/user-config.cfg |4 +
> .../linux/files/{{=machine}}-preempt-rt.scc| 30 ++
> .../linux/files/{{=machine}}-standard.scc | 30 ++
> .../recipes-kernel/linux/files/{{=machine}}.scc|6 +
> .../recipes-kernel/linux/kernel-list.noinstall |3 +
> ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" | 32 ++
> ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" | 32 ++
> ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" | 34 ++
> ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" | 34 ++
> .../arch/x86_64/conf/machine/{{=machine}}.conf | 29 ++
> ...erver_choice == \"xserver_i915\": }} xorg.conf" | 26 ++
> ...erver_choice == \"xserver_vesa\": }} xorg.conf" | 26 ++
> ... == \"y\": }} xserver-xf86-config_0.1.bbappend" |3 +
> .../linux/files/{{=machine}}-preempt-rt.scc|8 +
> .../linux/files/{{=machine}}-standard.scc |8 +
> .../recipes-kernel/linux/files/{{=machine}}.cfg| 47 +++
> .../recipes-kernel/linux/files/{{
Re: [yocto] [PATCH 2/8] yocto-bsp-tools: add bsp library
Responded privately to Tom on this one... On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote: > From: Tom Zanussi > > Create a home for the yocto bsp tools. > > Signed-off-by: Tom Zanussi > --- > scripts/lib/bsp/__init__.py | 17 + > 1 files changed, 17 insertions(+), 0 deletions(-) > create mode 100644 scripts/lib/bsp/__init__.py > > diff --git a/scripts/lib/bsp/__init__.py b/scripts/lib/bsp/__init__.py > new file mode 100644 > index 000..978c2e4 > --- /dev/null > +++ b/scripts/lib/bsp/__init__.py > @@ -0,0 +1,17 @@ > +# > +# Yocto BSP tools library > +# > +# Copyright (C) 2012 Tom Zanussi > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License version 2 as > +# published by the Free Software Foundation. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License along > +# with this program; if not, write to the Free Software Foundation, Inc., > +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] proper recipe for building for beagle xM? meta-ti?
>From: yocto-boun...@yoctoproject.org [mailto:yocto- >boun...@yoctoproject.org] On Behalf Of Koen Kooi >Sent: Friday, March 02, 2012 2:07 AM > >Well, if you use the angstrom setupscript you get 'yocto'. Your phrasing seems >to suggest you are confusing 'yocto' with 'poky', which is a common mistake. Hey all - from the project perspective, the Yocto Project includes Poky, so I think it's very appropriate for Robert to think that using YP implies using Poky. This is in all of the project's official QA and communications, so I think it's reasonable. Dave ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] proper recipe for building for beagle xM? meta-ti?
On Fri, 2 Mar 2012, Stewart, David C wrote: > >From: yocto-boun...@yoctoproject.org [mailto:yocto- > >boun...@yoctoproject.org] On Behalf Of Koen Kooi > >Sent: Friday, March 02, 2012 2:07 AM > > > >Well, if you use the angstrom setupscript you get 'yocto'. Your phrasing > >seems > >to suggest you are confusing 'yocto' with 'poky', which is a common mistake. > > Hey all - from the project perspective, the Yocto Project includes > Poky, so I think it's very appropriate for Robert to think that > using YP implies using Poky. This is in all of the project's > official QA and communications, so I think it's reasonable. i do understand the distinction and i will admit, i'm sometimes sloppy with my terminology. as someone who is constantly berating others for their lack of precision, i should know better. :-) rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/8] yocto-bsp: add templating engine
On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote:
> From: Tom Zanussi
>
> The main implementation of the Yocto BSP templating engine,
> essentially containing the internal implementation of the 'yocto-bsp
> create' and yocto-bsp list' commands.
>
> Signed-off-by: Tom Zanussi
> ---
> scripts/lib/bsp/engine.py | 1336
> +
> 1 files changed, 1336 insertions(+), 0 deletions(-)
> create mode 100644 scripts/lib/bsp/engine.py
>
> diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
> new file mode 100644
> index 000..7bf3e92
> --- /dev/null
> +++ b/scripts/lib/bsp/engine.py
> @@ -0,0 +1,1336 @@
> +# ex:ts=4:sw=4:sts=4:et
> +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
> +#
> +# Copyright 2012 Intel Corporation
> +# Authored-by: Tom Zanussi
same comments here...
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License version 2 as
> +# published by the Free Software Foundation.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License along
> +# with this program; if not, write to the Free Software Foundation, Inc.,
> +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> +
> +import os
> +import sys
> +from abc import ABCMeta, abstractmethod
> +from tags import *
> +import shlex
> +import json
> +
This looks like a healthy list of dependencies. Do we need to augment
the required packages list?
> +class Line():
> +"""
> +Generic (abstract) container representing a line that will appear
> +in the BSP-generating program.
> +"""
> +__metaclass__ = ABCMeta
Oh, I didn't know about that. My ABCs have been rather amateur by
comparison. Nice.
> +
> +def __init__(self, line):
> +self.line = line
> +self.generated_line = ""
> +
> +@abstractmethod
> +def gen(self, context = None):
> +"""
> +Generate the final executable line that will appear in the
> +BSP-generation program.
> +"""
> +pass
> +
> +def escape(self, line):
> +"""
> +Escape single and double quotes and backslashes until I find
> +something better (re.escape() escapes way too much)
> +"""
> +return line.replace("\\", "").replace("\"", "\\\"").replace("'",
> "\\'")
> +
> +def parse_error(self, msg, lineno, line):
> + raise SyntaxError("%s: %s" % (msg, line))
> +
Very nicely pythonic Tom. Classes, PyDoc, decorators, exceptions. Nice work!
> +
> +class NormalLine(Line):
> +"""
> +Container for normal (non-tag) lines.
> +"""
> +def __init__(self, line):
> +Line.__init__(self, line)
> +self.is_filename = False
> +self.is_dirname = False
> +self.out_filebase = None
> +
> +def gen(self, context = None):
> +if self.is_filename:
> +line = "of = open(\"" + os.path.join(self.out_filebase,
> self.escape(self.line)) + "\", \"w\")"
> +elif self.is_dirname:
> +dirname = os.path.join(self.out_filebase, self.escape(self.line))
> +line = "if not os.path.exists(\"" + dirname + "\"): os.mkdir(\""
> + dirname + "\")"
> +else:
> +line = "of.write(\"" + self.escape(self.line) + "\\n\")"
> +return line
> +
> +
> +class CodeLine(Line):
> +"""
> +Container for Python code tag lines.
> +"""
> +def __init__(self, line):
> +Line.__init__(self, line)
> +
> +def gen(self, context = None):
> +return self.line
> +
> +
> +class Assignment:
> +"""
> +Representation of everything we know about {{=name }} tags.
> +Instances of these are used by Assignment lines.
> +"""
> +def __init__(self, start, end, name):
> +self.start = start
> +self.end = end
> +self.name = name
> +
> +
> +class AssignmentLine(NormalLine):
> +"""
> +Container for normal lines containing assignment tags. Assignment
> +tags must be in ascending order of 'start' value.
> +"""
> +def __init__(self, line):
> +NormalLine.__init__(self, line)
> +self.assignments = []
> +
> +def add_assignment(self, start, end, name):
> +self.assignments.append(Assignment(start, end, name))
> +
> +def gen(self, context = None):
> +line = self.escape(self.line)
> +
> +for assignment in self.assignments:
> +replacement = "\" + " + assignment.name + " + \""
> +idx = line.find(ASSIGN_TAG)
> +line = line[:idx] + replacement + line[idx + assignment.end -
> assignment.start:]
> +if self.is_filename:
> +return "of
Re: [yocto] [PATCH 0/8] Yocto BSP tools
On Fri, 2012-03-02 at 08:24 -0800, Darren Hart wrote: > > On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote: > > From: Tom Zanussi > > > > This patchset implements the 'yocto-bsp' and 'yocto-kernel' BSP tools > > previously described in some detail in this RFC posting: > > > > https://lists.yoctoproject.org/pipermail/yocto/2011-December/006111.html > > > > With the functionality implemented by this patchset, you can: > > > > - create a new Yocto BSP for any architecture supported Yocto, as well > > as qemu versions of the same. The default mode of operation when > > invoked from the command-line is to prompt the user for information > > needed to generate the BSP. For the current set of BSPs, the user > > is prompted for various important parameters such as which kernel to > > use, which branch of that kernel to use (or re-use), whether or not > > to use X, and if so, which drivers to use, whether to turn on SMP, > > whether the BSP has a keyboard, touchscreen, etc. > > > > There's also an option (-i) that allows all the necessary > > information to be supplied directly as a JSON object instead, which > > allows the built-in prompting to be bypassed. This is mainly for > > use by developers of alternate UIs, such as the ADT integration that > > should now be possible with what's provided here. > > > > (available via the 'yocto-bsp create' command) > > This -i approach is adequate for an initial pass. However, a python > module API would be preferable. However, if the ADT integration is > written in java perhaps -i is the best way as I'm not sure if any of > the Python bindings for Java (JPI, JPE, ...) are robust enough for our use. > Agreed - this first pass as far as the input I/O was mainly to enable the ADT developers to start integrating now, and I believe they're starting out using the command-line versions. This can easily be changed to something more appropriate, but I'll wait on actual need to make those changes. > > > > - list the architectures available for BSP generation (using the > > 'yocto-bsp list karch' command). You can also list the properties > > and possible values for those properties for all the input items > > needed for a given architecture in order to create a bsp. The > > latter is mainly useful for developers of alternate UIs. See the > > documention in the built-in help system for details of the extensive > > data displayed by this command. > > > > (available via the 'yocto-bsp list' command) > > > > - add and remove kernel patches to/from the BSP, as well as list the > > kernel patches attached to the active kernel recipe for the BSP. > > > > (available via the 'yocto-kernel patch add/rm/list' commands) > > > > - add and remove kernel config items to/from the BSP, as well as list > > the user-defined config items attached to the active kernel recipe > > for the BSP. > > > > (available via the 'yocto-kernel config add/rm/list' commands) > > > > The built-in help system that makes it easy to drill down at any time > > and remind oneself of the syntax required for any specific command: > > > > Simply entering the name of the command, or the command along with > > 'help' will display a list of the available sub-commands. For example: > > > > $ yocto-bsp > > $ yocto-bsp help > > > > Usage: > > > > Create a customized Yocto BSP layer. > > > > usage: yocto-bsp [--version] [--help] COMMAND [ARGS] > > > > The most commonly used 'yocto-bsp' commands are: > > createCreate a new Yocto BSP > > list List available values for options and BSP properties > > > > See 'yocto-bsp help COMMAND' for more information on a specific command. > > > > > > Options: > > --versionshow program's version number and exit > > -h, --help show this help message and exit > > -D, --debug output debug information > > > > > > Similarly, entering just the name of the subcommand will show the > > detailed usage for that command: > > > > $ yocto-bsp create > > > > Usage: > > > > Create a new Yocto BSP > > > > usage: yocto-bsp create [-o | --outdir > > ] > > [-i | --infile ] > > > > This command creates a Yocto BSP based on the specified parameters. > > The new BSP will be a new Yocto BSP layer contained by default within > > the top-level directory specified as 'meta-bsp-name'. The -o option > > can be used to place the BSP layer in a directory with a different > > name and location. > > > > ... > > > > > > For any subcommand, you can also use the word 'help' just before the > > subcommand to get more extensive documentation on the subcommand: > > > > $ yocto-bsp help create > > > > I believe it is more typical to have the "help" argument after the command: > > git branch -h, for example (since you used git-like in your > description). Not a big deal, but some might trip over this. > Since it's advertised as a git-like tool, it's behaves as expecte
Re: [yocto] [PATCH 4/8] yocto-bsp: add kernel interface
On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote:
> From: Tom Zanussi
>
> Yocto BSP kernel-related functions, for interacting with the kernel
> tools and implementing the machinery behind the 'yocto-kernel'
> command.
>
> Signed-off-by: Tom Zanussi
> ---
> scripts/lib/bsp/kernel.py | 679
> +
> 1 files changed, 679 insertions(+), 0 deletions(-)
> create mode 100644 scripts/lib/bsp/kernel.py
>
> diff --git a/scripts/lib/bsp/kernel.py b/scripts/lib/bsp/kernel.py
> new file mode 100644
> index 000..1b88b2f
> --- /dev/null
> +++ b/scripts/lib/bsp/kernel.py
> @@ -0,0 +1,679 @@
> +# ex:ts=4:sw=4:sts=4:et
> +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
> +#
> +# Copyright 2012 Intel Corporation
> +# Authored-by: Tom Zanussi
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License version 2 as
> +# published by the Free Software Foundation.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License along
> +# with this program; if not, write to the Free Software Foundation, Inc.,
> +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> +
> +import sys
> +import os
> +import shutil
> +from tags import *
> +import glob
> +
> +
> +def find_bblayers(scripts_path):
> +"""
> +Find and return a sanitized list of the layers found in BBLAYERS.
> +"""
> +bblayers_conf = os.path.join(scripts_path, "../build/conf/bblayers.conf")
> +
> +layers = []
> +
> +f = open(bblayers_conf, "r")
> +lines = f.readlines()
> +for line in lines:
> +line = line.strip()
> +in_bblayers = False
> +if line.startswith("BBLAYERS"):
> +in_bblayers = True
> +if line.startswith("/"):
> +if line.endswith("\\"):
> +line = line[:-1].strip()
> +layers.append(line)
This does not appear to handle something like:
BBLAYERS = " \
/path/to/layer1 \
/path/to/layer2"
Need to strip the " from the end of the last line.
Also doesn't handle:
BBLAYERS += "/path/to/layer3"
As it looks for lines starting with / and doesn't handle the " as
mentioned above.
> +f.close()
> +
> +return layers
> +
> +
> +def find_meta_layer(scripts_path):
> +"""
> +Find and return the meta layer in BBLAYERS.
> +"""
> +layers = find_bblayers(scripts_path)
> +
> +for layer in layers:
> +if layer.endswith("meta"):
> +return layer
> +
> +return None
I wonder if you could just use the bitbake-layers show-layers command?
$ bitbake-layers show-layers
Parsing recipes..WARNING: No recipes available for:
/home/dvhart/source/poky/layers/poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_2.6.34.bbappend
/home/dvhart/source/poky/layers/meta-intel/meta-fri2/recipes-kernel/linux/linux-yocto-tiny_3.2.bbappend
/home/dvhart/source/poky/layers/poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto-rt_2.6.34.bbappend
done.
layer path priority
==
meta /home/dvhart/source/poky/meta 5
meta-yocto/home/dvhart/source/poky/meta-yocto 5
meta-intel/home/dvhart/source/poky/layers/meta-intel 5
meta-fri2
/home/dvhart/source/poky/layers/meta-intel/meta-fri2 5
meta-kernel-dev
/home/dvhart/source/poky/layers/poky-extras/meta-kernel-dev 0
It's slow as snot in January in Toronto, but it avoids having to
re-implement all the bblayers parsing and the various corner cases that
bitbake already handles...
> +
> +def find_bsp_layer(scripts_path, machine):
> +"""
> +Find and return a machine's BSP layer in BBLAYERS.
> +"""
> +layers = find_bblayers(scripts_path)
> +
> +for layer in layers:
> +if machine in layer:
> +return layer
> +
> +print "Unable to find the BSP layer for machine %s." % machine
> +print "Please make sure it is listed in bblayers.conf"
> +sys.exit(1)
You would probably need to cache the result of the bitbake-layers as it
is way to slow to use repeatedly like you need to here...
The rest looks good to me.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] proper recipe for building for beagle xM? meta-ti?
Op 2 mrt. 2012, om 17:45 heeft Stewart, David C het volgende geschreven: >> From: yocto-boun...@yoctoproject.org [mailto:yocto- >> boun...@yoctoproject.org] On Behalf Of Koen Kooi >> Sent: Friday, March 02, 2012 2:07 AM >> >> Well, if you use the angstrom setupscript you get 'yocto'. Your phrasing >> seems >> to suggest you are confusing 'yocto' with 'poky', which is a common mistake. > > Hey all - from the project perspective, the Yocto Project includes Poky, so I > think it's very appropriate for Robert to think that using YP implies using > Poky. This is in all of the project's official QA and communications, so I > think it's reasonable. This begs the questions where other distributions (and OSVs) fit into yocto. regards, Koen ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/8] Yocto BSP tools
On 03/02/2012 09:02 AM, Tom Zanussi wrote: > On Fri, 2012-03-02 at 08:24 -0800, Darren Hart wrote: >>> For any subcommand, you can also use the word 'help' just before the >>> subcommand to get more extensive documentation on the subcommand: >>> >>> $ yocto-bsp help create >>> >> >> I believe it is more typical to have the "help" argument after the command: >> >> git branch -h, for example (since you used git-like in your >> description). Not a big deal, but some might trip over this. >> > > Since it's advertised as a git-like tool, it's behaves as expected ;-) > > $ git > > See 'git help COMMAND' for more information on a specific command. hah, I stand corrected :-) -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 5/8] yocto-bsp-tools: add help/usage
On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote: > From: Tom Zanussi > > This is essentially 'the documentation' for the Yocto BSP tools, along > with a few related functions. > > Signed-off-by: Tom Zanussi > --- > scripts/lib/bsp/help.py | 588 > +++ > 1 files changed, 588 insertions(+), 0 deletions(-) > create mode 100644 scripts/lib/bsp/help.py > > diff --git a/scripts/lib/bsp/help.py b/scripts/lib/bsp/help.py > new file mode 100644 > index 000..c7c6e6a > --- /dev/null > +++ b/scripts/lib/bsp/help.py > @@ -0,0 +1,588 @@ > +# ex:ts=4:sw=4:sts=4:et > +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*- > +# > +# Copyright 2012 Intel Corporation > +# Authored-by: Tom Zanussi Same comment here... Otherwise, all looks very nice. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 6/8] yocto-bsp: add some useful constants
On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote: > From: Tom Zanussi > > Some constants used by the templating engine. > > Signed-off-by: Tom Zanussi > --- > scripts/lib/bsp/tags.py | 39 +++ > 1 files changed, 39 insertions(+), 0 deletions(-) > create mode 100644 scripts/lib/bsp/tags.py > > diff --git a/scripts/lib/bsp/tags.py b/scripts/lib/bsp/tags.py > new file mode 100644 > index 000..99b5785 > --- /dev/null > +++ b/scripts/lib/bsp/tags.py > @@ -0,0 +1,39 @@ > +# ex:ts=4:sw=4:sts=4:et > +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*- > +# > +# Copyright 2012 Intel Corporation > +# Authored-by: Tom Zanussi same comment.. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/8] yocto-bsp: add BSP template files
On Fri, 2012-03-02 at 08:35 -0800, Darren Hart wrote:
>
> On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote:
> > From: Tom Zanussi
> >
> > BSP template files for all supported Yocto architectures, plus qemu
> > versions of the same.
> >
> > Signed-off-by: Tom Zanussi
> > ---
> > .../target/arch/arm/conf/machine/{{=machine}}.conf | 87 +
> > .../{{ if xserver == \"y\": }} xorg.conf" | 34 ++
> > ... == \"y\": }} xserver-xf86-config_0.1.bbappend" |3 +
> > .../linux/files/{{=machine}}-non_hardware.cfg | 30 ++
> > .../linux/files/{{=machine}}-preempt-rt.scc|8 +
> > .../linux/files/{{=machine}}-standard.scc |8 +
> > .../recipes-kernel/linux/files/{{=machine}}.cfg| 336
> >
> > .../recipes-kernel/linux/files/{{=machine}}.scc|7 +
> > .../arm/recipes-kernel/linux/kernel-list.noinstall |3 +
> > ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" | 34 ++
> > ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" | 34 ++
> > ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" | 36 ++
> > ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" | 34 ++
> > .../bsp/substrate/target/arch/common/COPYING.MIT | 17 +
> > .../lib/bsp/substrate/target/arch/common/README| 118 +++
> > .../substrate/target/arch/common/README.sources| 17 +
> > .../substrate/target/arch/common/conf/layer.conf | 10 +
> > .../formfactor/formfactor/{{=machine}}/machconfig |5 +
> > .../recipes-bsp/formfactor/formfactor_0.0.bbappend |3 +
> > .../tasks/task-core-tools-profile.bbappend |2 +
> > .../arch/i386/conf/machine/{{=machine}}.conf | 44 +++
> > ...erver_choice == \"xserver_emgd\": }} xorg.conf" | 48 +++
> > ...erver_choice == \"xserver_i915\": }} xorg.conf" | 26 ++
> > ...erver_choice == \"xserver_vesa\": }} xorg.conf" | 26 ++
> > ... == \"y\": }} xserver-xf86-config_0.1.bbappend" |3 +
> > .../linux/files/{{=machine}}-preempt-rt.scc|8 +
> > .../linux/files/{{=machine}}-standard.scc |8 +
> > .../recipes-kernel/linux/files/{{=machine}}.cfg| 54
> > .../recipes-kernel/linux/files/{{=machine}}.scc| 30 ++
> > .../recipes-kernel/linux/kernel-list.noinstall |3 +
> > ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" | 34 ++
> > ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" | 34 ++
> > ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" | 36 ++
> > ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" | 34 ++
> > .../arch/mips/conf/machine/{{=machine}}.conf | 28 ++
> > .../linux/files/{{=machine}}-preempt-rt.scc|8 +
> > .../linux/files/{{=machine}}-standard.scc |8 +
> > .../recipes-kernel/linux/files/{{=machine}}.cfg|1 +
> > .../recipes-kernel/linux/files/{{=machine}}.scc|8 +
> > .../recipes-kernel/linux/kernel-list.noinstall |3 +
> > ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" | 34 ++
> > ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" | 34 ++
> > ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" | 36 ++
> > ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" | 34 ++
> > .../arch/powerpc/conf/machine/{{=machine}}.conf| 53 +++
> > .../recipes-kernel/linux/files/user-config.cfg |4 +
> > .../linux/files/{{=machine}}-preempt-rt.scc|8 +
> > .../linux/files/{{=machine}}-standard.scc |8 +
> > .../recipes-kernel/linux/files/{{=machine}}.cfg| 163 ++
> > .../recipes-kernel/linux/files/{{=machine}}.scc| 11 +
> > .../recipes-kernel/linux/kernel-list.noinstall |3 +
> > ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" | 34 ++
> > ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" | 34 ++
> > ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" | 36 ++
> > ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" | 34 ++
> > .../arch/qemu/conf/machine/{{=machine}}.conf | 59
> > .../xserver-xf86-config/{{=machine}}/xorg.conf | 69
> > ..."x86_64\": }} xserver-xf86-config_0.1.bbappend" |2 +
> > .../recipes-kernel/linux/files/user-config.cfg |4 +
> > .../linux/files/{{=machine}}-preempt-rt.scc| 30 ++
> > .../linux/files/{{=machine}}-standard.scc | 30 ++
> > .../recipes-kernel/linux/files/{{=machine}}.scc|6 +
> > .../recipes-kernel/linux/kernel-list.noinstall |3 +
> > ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" | 32 ++
> > ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" | 32 ++
> > ...linux-yocto_3.0\": }} linux-yocto_3.0.bbappend" | 34 ++
> > ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" | 34 ++
> > .../arch/x86_64/conf/machine/{{=machine}}.conf | 29 ++
> > ...erver_choice == \"xserver_i915\": }} xorg.conf" | 26 ++
> > ...erver_choice == \"xserver_vesa\": }} xorg.conf" | 26 ++
> > ... == \"y\": }} xserver-xf86-config_0.1.bbappend" |3 +
> > .../lin
Re: [yocto] [PATCH 7/8] yocto-bsp: new script
On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote:
> From: Tom Zanussi
>
> Implementation of the 'yocto-bsp' command-line tool, for creating BSPs
> and listing BSP properties.
>
> Signed-off-by: Tom Zanussi
> ---
> scripts/yocto-bsp | 131
> +
> 1 files changed, 131 insertions(+), 0 deletions(-)
> create mode 100755 scripts/yocto-bsp
>
> diff --git a/scripts/yocto-bsp b/scripts/yocto-bsp
> new file mode 100755
> index 000..20fa89d
> --- /dev/null
> +++ b/scripts/yocto-bsp
> @@ -0,0 +1,131 @@
> +#!/usr/bin/env python
> +# ex:ts=4:sw=4:sts=4:et
> +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
> +#
> +# Copyright 2012 Intel Corporation
> +# Authored-by: Tom Zanussi
> +#
same comment...
...
> +def yocto_bsp_list_subcommand(args, usage_str):
> +"""
> +Command-line handling for listing available BSP properties and
> +values. The real work is done by bsp.engine.yocto_bsp_list()
> +"""
> +parser = optparse.OptionParser(usage = usage_str)
> +
> +parser.add_option("-o", "--outfile", action = "store", dest =
> "properties_file",
> + help = "dump the possible values for BSP properties to
> a JSON file")
> +
> +(options, args) = parser.parse_args(args)
> +
> +if not yocto_bsp_list(args, scripts_path, options.properties_file):
> +logging.error("Bad list arguments, exiting\n")
> +parser.print_help()
> +exit(1)
I see sys.exit() below and just exit() here, and above you "import sys",
so I believe this should also be sys.exit()
...
> +if __name__ == "__main__":
> +try:
> +ret = main()
> +except Exception:
> +ret = 1
> +import traceback
> +traceback.print_exc(5)
> +sys.exit(ret)
> +
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/8] yocto-bsp: add templating engine
On Fri, 2012-03-02 at 08:57 -0800, Darren Hart wrote:
>
> On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote:
> > From: Tom Zanussi
> >
> > The main implementation of the Yocto BSP templating engine,
> > essentially containing the internal implementation of the 'yocto-bsp
> > create' and yocto-bsp list' commands.
> >
> > Signed-off-by: Tom Zanussi
> > ---
> > scripts/lib/bsp/engine.py | 1336
> > +
> > 1 files changed, 1336 insertions(+), 0 deletions(-)
> > create mode 100644 scripts/lib/bsp/engine.py
> >
> > diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
> > new file mode 100644
> > index 000..7bf3e92
> > --- /dev/null
> > +++ b/scripts/lib/bsp/engine.py
> > @@ -0,0 +1,1336 @@
> > +# ex:ts=4:sw=4:sts=4:et
> > +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
> > +#
> > +# Copyright 2012 Intel Corporation
> > +# Authored-by: Tom Zanussi
>
> same comments here...
>
> > +#
> > +# This program is free software; you can redistribute it and/or modify
> > +# it under the terms of the GNU General Public License version 2 as
> > +# published by the Free Software Foundation.
> > +#
> > +# This program is distributed in the hope that it will be useful,
> > +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > +# GNU General Public License for more details.
> > +#
> > +# You should have received a copy of the GNU General Public License along
> > +# with this program; if not, write to the Free Software Foundation, Inc.,
> > +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > +
> > +import os
> > +import sys
> > +from abc import ABCMeta, abstractmethod
> > +from tags import *
> > +import shlex
> > +import json
> > +
>
>
> This looks like a healthy list of dependencies. Do we need to augment
> the required packages list?
>
This is all standard Python 2.6 stuff, so nothing special needed if we
have Python.
>
> > +class Line():
> > +"""
> > +Generic (abstract) container representing a line that will appear
> > +in the BSP-generating program.
> > +"""
> > +__metaclass__ = ABCMeta
>
> Oh, I didn't know about that. My ABCs have been rather amateur by
> comparison. Nice.
>
> > +
> > +def __init__(self, line):
> > +self.line = line
> > +self.generated_line = ""
> > +
> > +@abstractmethod
> > +def gen(self, context = None):
> > +"""
> > +Generate the final executable line that will appear in the
> > +BSP-generation program.
> > +"""
> > +pass
> > +
> > +def escape(self, line):
> > +"""
> > +Escape single and double quotes and backslashes until I find
> > +something better (re.escape() escapes way too much)
> > +"""
> > +return line.replace("\\", "").replace("\"",
> > "\\\"").replace("'", "\\'")
> > +
> > +def parse_error(self, msg, lineno, line):
> > + raise SyntaxError("%s: %s" % (msg, line))
> > +
>
>
> Very nicely pythonic Tom. Classes, PyDoc, decorators, exceptions. Nice work!
>
Heh, thanks, and then we have isinstance() everywhere, which is not.
Need to fix that. ;-)
> > +
> > +class NormalLine(Line):
> > +"""
> > +Container for normal (non-tag) lines.
> > +"""
> > +def __init__(self, line):
> > +Line.__init__(self, line)
> > +self.is_filename = False
> > +self.is_dirname = False
> > +self.out_filebase = None
> > +
> > +def gen(self, context = None):
> > +if self.is_filename:
> > +line = "of = open(\"" + os.path.join(self.out_filebase,
> > self.escape(self.line)) + "\", \"w\")"
> > +elif self.is_dirname:
> > +dirname = os.path.join(self.out_filebase,
> > self.escape(self.line))
> > +line = "if not os.path.exists(\"" + dirname + "\"):
> > os.mkdir(\"" + dirname + "\")"
> > +else:
> > +line = "of.write(\"" + self.escape(self.line) + "\\n\")"
> > +return line
> > +
> > +
> > +class CodeLine(Line):
> > +"""
> > +Container for Python code tag lines.
> > +"""
> > +def __init__(self, line):
> > +Line.__init__(self, line)
> > +
> > +def gen(self, context = None):
> > +return self.line
> > +
> > +
> > +class Assignment:
> > +"""
> > +Representation of everything we know about {{=name }} tags.
> > +Instances of these are used by Assignment lines.
> > +"""
> > +def __init__(self, start, end, name):
> > +self.start = start
> > +self.end = end
> > +self.name = name
> > +
> > +
> > +class AssignmentLine(NormalLine):
> > +"""
> > +Container for normal lines containing assignment tags. Assignment
> > +tags must be in ascending order of 'start' value.
> > +"""
> > +def __init__(self, line):
> > +NormalLine.__init__(self, line)
> > +self.a
Re: [yocto] [PATCH 8/8] yocto-kernel: new script
On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote:
> From: Tom Zanussi
>
> Implementation of the 'yocto-kernel' command-line tool, for modifying
> the kernel portion of a Yocto BSP.
>
> Signed-off-by: Tom Zanussi
> ---
> scripts/yocto-kernel | 219
> ++
> 1 files changed, 219 insertions(+), 0 deletions(-)
> create mode 100755 scripts/yocto-kernel
>
> diff --git a/scripts/yocto-kernel b/scripts/yocto-kernel
> new file mode 100755
> index 000..97a7a7c
> --- /dev/null
> +++ b/scripts/yocto-kernel
> @@ -0,0 +1,219 @@
> +#!/usr/bin/env python
> +# ex:ts=4:sw=4:sts=4:et
> +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
> +#
> +# Copyright 2012 Intel Corporation
> +# Authored-by: Tom Zanussi
same comment...
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License version 2 as
> +# published by the Free Software Foundation.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License along
> +# with this program; if not, write to the Free Software Foundation, Inc.,
> +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> +
> +__version__ = "0.1.0"
> +
> +import os
> +import sys
> +import optparse
> +import logging
> +
> +scripts_path = os.path.abspath(os.path.dirname(os.path.abspath(sys.argv[0])))
> +lib_path = scripts_path + '/lib'
> +sys.path = sys.path + [lib_path]
> +
> +from bsp.help import *
> +from bsp.kernel import *
> +
> +
> +def yocto_kernel_config_list_subcommand(args, usage_str):
> +"""
> +Command-line handling for listing BSP config options. The
> +real work is done by bsp.kernel.yocto_kernel_config_list().
> +"""
> +logging.debug("yocto_kernel_config_list_subcommand")
> +
> +parser = optparse.OptionParser(usage = usage_str)
> +
> +(options, args) = parser.parse_args(args)
> +
> +if len(args) != 1:
> +logging.error("Wrong number of arguments, exiting\n")
> +parser.print_help()
> +exit(1)
Same comment on exit here as 7/8. Maybe there is a subtle difference
that I'm missing? Same throughout the other subcommands...
Tom, this is all really great work. It's well-formed python, properly
documented both in comments and user visible help. Very nice.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 8/8] yocto-kernel: new script
On Fri, 2012-03-02 at 09:23 -0800, Darren Hart wrote:
>
> On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote:
> > From: Tom Zanussi
> >
> > Implementation of the 'yocto-kernel' command-line tool, for modifying
> > the kernel portion of a Yocto BSP.
> >
> > Signed-off-by: Tom Zanussi
> > ---
> > scripts/yocto-kernel | 219
> > ++
> > 1 files changed, 219 insertions(+), 0 deletions(-)
> > create mode 100755 scripts/yocto-kernel
> >
> > diff --git a/scripts/yocto-kernel b/scripts/yocto-kernel
> > new file mode 100755
> > index 000..97a7a7c
> > --- /dev/null
> > +++ b/scripts/yocto-kernel
> > @@ -0,0 +1,219 @@
> > +#!/usr/bin/env python
> > +# ex:ts=4:sw=4:sts=4:et
> > +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
> > +#
> > +# Copyright 2012 Intel Corporation
> > +# Authored-by: Tom Zanussi
>
> same comment...
>
> > +#
> > +# This program is free software; you can redistribute it and/or modify
> > +# it under the terms of the GNU General Public License version 2 as
> > +# published by the Free Software Foundation.
> > +#
> > +# This program is distributed in the hope that it will be useful,
> > +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > +# GNU General Public License for more details.
> > +#
> > +# You should have received a copy of the GNU General Public License along
> > +# with this program; if not, write to the Free Software Foundation, Inc.,
> > +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > +
> > +__version__ = "0.1.0"
> > +
> > +import os
> > +import sys
> > +import optparse
> > +import logging
> > +
> > +scripts_path =
> > os.path.abspath(os.path.dirname(os.path.abspath(sys.argv[0])))
> > +lib_path = scripts_path + '/lib'
> > +sys.path = sys.path + [lib_path]
> > +
> > +from bsp.help import *
> > +from bsp.kernel import *
> > +
> > +
> > +def yocto_kernel_config_list_subcommand(args, usage_str):
> > +"""
> > +Command-line handling for listing BSP config options. The
> > +real work is done by bsp.kernel.yocto_kernel_config_list().
> > +"""
> > +logging.debug("yocto_kernel_config_list_subcommand")
> > +
> > +parser = optparse.OptionParser(usage = usage_str)
> > +
> > +(options, args) = parser.parse_args(args)
> > +
> > +if len(args) != 1:
> > +logging.error("Wrong number of arguments, exiting\n")
> > +parser.print_help()
> > +exit(1)
>
>
> Same comment on exit here as 7/8. Maybe there is a subtle difference
> that I'm missing? Same throughout the other subcommands...
>
No, those are basically typos that work. I think they should all be
sys.exit. Thanks for noticing and pointing it out.
> Tom, this is all really great work. It's well-formed python, properly
> documented both in comments and user visible help. Very nice.
>
Thanks, I appreciate your comments.
Tom
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] running yocto QEMU images (sort of) by their lonesome
i wrote it up because IWFM (it works for me): http://www.crashcourse.ca/wiki/index.php/Yocto_and_QEMU#Running_pre-built_Yocto_images_in_QEMU yes, i'm well aware it's a hack but if newcomers want to fire up a yocto-built image, it seems to do the job. feel free to denigrate and demean it appropriately. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 4/8] yocto-bsp: add kernel interface
On Fri, 2012-03-02 at 09:11 -0800, Darren Hart wrote:
>
> On 03/01/2012 11:01 PM, tom.zanu...@intel.com wrote:
> > From: Tom Zanussi
> >
> > Yocto BSP kernel-related functions, for interacting with the kernel
> > tools and implementing the machinery behind the 'yocto-kernel'
> > command.
> >
> > Signed-off-by: Tom Zanussi
> > ---
> > scripts/lib/bsp/kernel.py | 679
> > +
> > 1 files changed, 679 insertions(+), 0 deletions(-)
> > create mode 100644 scripts/lib/bsp/kernel.py
> >
> > diff --git a/scripts/lib/bsp/kernel.py b/scripts/lib/bsp/kernel.py
> > new file mode 100644
> > index 000..1b88b2f
> > --- /dev/null
> > +++ b/scripts/lib/bsp/kernel.py
> > @@ -0,0 +1,679 @@
> > +# ex:ts=4:sw=4:sts=4:et
> > +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
> > +#
> > +# Copyright 2012 Intel Corporation
> > +# Authored-by: Tom Zanussi
> > +#
> > +# This program is free software; you can redistribute it and/or modify
> > +# it under the terms of the GNU General Public License version 2 as
> > +# published by the Free Software Foundation.
> > +#
> > +# This program is distributed in the hope that it will be useful,
> > +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > +# GNU General Public License for more details.
> > +#
> > +# You should have received a copy of the GNU General Public License along
> > +# with this program; if not, write to the Free Software Foundation, Inc.,
> > +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > +
> > +import sys
> > +import os
> > +import shutil
> > +from tags import *
> > +import glob
> > +
> > +
> > +def find_bblayers(scripts_path):
> > +"""
> > +Find and return a sanitized list of the layers found in BBLAYERS.
> > +"""
> > +bblayers_conf = os.path.join(scripts_path,
> > "../build/conf/bblayers.conf")
> > +
> > +layers = []
> > +
> > +f = open(bblayers_conf, "r")
> > +lines = f.readlines()
> > +for line in lines:
> > +line = line.strip()
> > +in_bblayers = False
> > +if line.startswith("BBLAYERS"):
> > +in_bblayers = True
> > +if line.startswith("/"):
> > +if line.endswith("\\"):
> > +line = line[:-1].strip()
> > +layers.append(line)
>
>
> This does not appear to handle something like:
>
> BBLAYERS = " \
> /path/to/layer1 \
> /path/to/layer2"
>
> Need to strip the " from the end of the last line.
>
> Also doesn't handle:
>
> BBLAYERS += "/path/to/layer3"
>
> As it looks for lines starting with / and doesn't handle the " as
> mentioned above.
>
> > +f.close()
> > +
> > +return layers
> > +
> > +
> > +def find_meta_layer(scripts_path):
> > +"""
> > +Find and return the meta layer in BBLAYERS.
> > +"""
> > +layers = find_bblayers(scripts_path)
> > +
> > +for layer in layers:
> > +if layer.endswith("meta"):
> > +return layer
> > +
> > +return None
>
> I wonder if you could just use the bitbake-layers show-layers command?
>
> $ bitbake-layers show-layers
> Parsing recipes..WARNING: No recipes available for:
>
> /home/dvhart/source/poky/layers/poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_2.6.34.bbappend
>
> /home/dvhart/source/poky/layers/meta-intel/meta-fri2/recipes-kernel/linux/linux-yocto-tiny_3.2.bbappend
>
> /home/dvhart/source/poky/layers/poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto-rt_2.6.34.bbappend
> done.
>
> layer path priority
> ==
> meta /home/dvhart/source/poky/meta 5
> meta-yocto/home/dvhart/source/poky/meta-yocto 5
> meta-intel/home/dvhart/source/poky/layers/meta-intel 5
> meta-fri2
> /home/dvhart/source/poky/layers/meta-intel/meta-fri2 5
> meta-kernel-dev
> /home/dvhart/source/poky/layers/poky-extras/meta-kernel-dev 0
>
>
> It's slow as snot in January in Toronto, but it avoids having to
> re-implement all the bblayers parsing and the various corner cases that
> bitbake already handles...
>
Yeah, good suggestion - makes a lot of sense to me - I'll see what I can
do to leverage that work.
>
> > +
> > +def find_bsp_layer(scripts_path, machine):
> > +"""
> > +Find and return a machine's BSP layer in BBLAYERS.
> > +"""
> > +layers = find_bblayers(scripts_path)
> > +
> > +for layer in layers:
> > +if machine in layer:
> > +return layer
> > +
> > +print "Unable to find the BSP layer for machine %s." % machine
> > +print "Please make sure it is listed in bblayers.conf"
> > +sys.exit(1)
>
> You would probably need to cache the result of the bitbake-layers as it
> is way to slow to use repeatedly like you need to here...
>
Right, makes
Re: [yocto] initramfs support in Yocto
> Can you be more specific about what you are looking for? When you build > an image with the cpio.gz image type, you can boot that as an initramfs > with the following kernel command line: > > initrd=core-image-minimal-fri2.cpio.gz root=/dev/ram0 > > If you are looking for something beyond that, please elaborate. > When most people refer to initramfs support it is compiling a built image in to the kernel binary(e.g. CONFIG_INITRAMFS_SOURCE). INITRAMFS_IMAGE is part of the kernel class that should enable that in the build. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 00/11][linux-yocto-3.0] Backport fixes and add FRI2 support to pch_uart
On 12-03-01 06:58 PM, Darren Hart wrote: Backport 7 patches bringing pch_uart up to date with required fixes and new features to support the 4 new patches (from me) enabling the FRI2 serial port. My patches have been sent to LKML and have received the approval one of the driver maintainers. They are currently pending review and a pull from Greg KH. Grabbed and merged these. Will push them out later today, along with my 3.0.23 + rt updates. Bruce Please apply to yocto/standard/base. The following changes since commit c578f3a1f357142a6e02a1df4ae9aa16f45094d6: Merge branch 'yocto/base' into yocto/standard/base (2012-02-26 00:04:15 -0500) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-yocto-3.0.git dvhart/yocto/standard/pch_uart http://git.infradead.org/users/dvhart/linux-yocto-3.0.git/shortlog/refs/heads/dvhart/yocto/standard/pch_uart Alexander Stein (3): pch_uart: add missing comment about OKI ML7223 pch_uart: Add MSI support drivers/tty/serial/pch_uart.c: add console support Darren Hart (4): pch_uart: Use uartclk instead of base_baud pch_uart: Add Fish River Island II uart clock quirks pch_uart: Add user_uartclk parameter pch_uart: Use existing default_baud in setup_console Jiri Slaby (1): TTY: serial, fix includes in some drivers Tomoya MORINAGA (2): pch_uart: Set PCIe bus number using probe parameter pch_uart: Change company name OKI SEMICONDUCTOR to LAPIS Semiconductor Uwe Kleine-König (1): serial/pch: use global div helper instead of creating a private one drivers/tty/serial/Kconfig |9 + drivers/tty/serial/apbuart.c|1 + drivers/tty/serial/cpm_uart/cpm_uart_core.c |1 + drivers/tty/serial/dz.c |1 + drivers/tty/serial/ioc3_serial.c|1 + drivers/tty/serial/ioc4_serial.c|1 + drivers/tty/serial/m32r_sio.c |1 + drivers/tty/serial/max3100.c|2 + drivers/tty/serial/max3107.c|2 + drivers/tty/serial/mpc52xx_uart.c |1 + drivers/tty/serial/msm_serial_hs.c |2 + drivers/tty/serial/mux.c|2 + drivers/tty/serial/nwpserial.c |1 + drivers/tty/serial/pch_uart.c | 227 --- drivers/tty/serial/sb1250-duart.c |1 + drivers/tty/serial/serial_ks8695.c |1 + drivers/tty/serial/serial_txx9.c|2 + drivers/tty/serial/sn_console.c |1 + drivers/tty/serial/timbuart.c |2 + drivers/tty/serial/uartlite.c |1 + drivers/tty/serial/ucc_uart.c |4 +- drivers/tty/serial/xilinx_uartps.c |4 +- drivers/tty/serial/zs.c |1 + 23 files changed, 246 insertions(+), 23 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/3] fri2: Add SMP and EFI support
On 12-03-01 06:59 PM, Darren Hart wrote: Rather than add these as features in the linux-yocto recipe, include them in the BSP meta-data directly. Include only the core EFI bits in the fri2.scc, and add the extended EFI support to the fri2-standard.scc so that other ktypes don't pull in more than what's absolutely required from fri2.scc. Makes sense. This makes the BSP standalone .. which we want. I've merged all the meta changes now. Bruce Signed-off-by: Darren Hart --- meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc |1 + meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc |1 + meta/cfg/kernel-cache/bsp/fri2/fri2.scc|2 ++ 3 files changed, 4 insertions(+), 0 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc index 142d71a..9e9a84c 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc @@ -5,3 +5,4 @@ define KARCH i386 # no new branch required, re-use the ktypes/preempt-rt branch include ktypes/preempt-rt include fri2.scc +include cfg/efi-ext.scc diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc index b28b650..1cd28fa 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc @@ -5,3 +5,4 @@ define KARCH i386 scc_leaf ktypes/standard fri2 include fri2.scc +include cfg/efi-ext.scc diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc index 1e0c295..39e6989 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc @@ -13,6 +13,8 @@ include features/framebuffer/vesafb.scc include cfg/usb-mass-storage.scc include cfg/boot-live.scc include features/power/intel.scc +include cfg/smp.scc +include cfg/efi.scc include features/logbuf/size-normal.scc ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/5][linux-yocto-3.2] Backport fixes and add FRI2 support to pch_uart
On 12-03-01 06:59 PM, Darren Hart wrote: Backport consle support and add the 4 new patches (from me) enabling the FRI2 serial port. My patches have been sent to LKML and have received the approval one of the driver maintainers. They are currently pending review and a pull from Greg KH. Please apply to standard/base and down. merged. I've grouped it with my 3.2.9 and -rt updates. Will have it pushed out after some build testing. Bruce The following changes since commit ee3b6f8f773c373ca2ef2e4a04d2fd58b748eaee: Merge branch 'base' into standard/base (2012-02-28 13:31:59 -0500) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-yocto-3.2.git dvhart/standard/pch_uart http://git.infradead.org/users/dvhart/linux-yocto-3.2.git/shortlog/refs/heads/dvhart/standard/pch_uart Alexander Stein (1): drivers/tty/serial/pch_uart.c: add console support Darren Hart (4): pch_uart: Use uartclk instead of base_baud pch_uart: Add Fish River Island II uart clock quirks pch_uart: Add user_uartclk parameter pch_uart: Use existing default_baud in setup_console drivers/tty/serial/Kconfig|9 ++ drivers/tty/serial/pch_uart.c | 209 +--- 2 files changed, 202 insertions(+), 16 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/6] Remove boot-live cfg duplication from BSPs
On 12-03-01 06:59 PM, Darren Hart wrote: From: Darren Hart Several BSPs duplicated the boot-live fragment in their BSP specific config. Remove the duplication and add CONFIG_RD_GZIP and CONFIG_BLK_DEV_SR to the boot-live fragment. Looks fine to me as well. That's a better place for the common options. Bruce Signed-off-by: Darren Hart Acked-by: Tom Zanussi --- .../cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg | 10 -- meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg| 10 -- meta/cfg/kernel-cache/bsp/emenlow/emenlow.cfg | 10 -- meta/cfg/kernel-cache/bsp/fishriver/fishriver.cfg | 10 -- meta/cfg/kernel-cache/bsp/fri2/fri2.cfg| 10 -- meta/cfg/kernel-cache/bsp/sys940x/sys940x.cfg |5 - meta/cfg/kernel-cache/cfg/boot-live.cfg|3 +++ 7 files changed, 3 insertions(+), 55 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg b/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg index 1cc14b1..32cd9e5 100755 --- a/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg +++ b/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg @@ -46,13 +46,3 @@ CONFIG_MODULES=y CONFIG_SHMEM=y CONFIG_TMPFS=y CONFIG_PACKET=y - -# Needed for booting (and using) USB memory sticks -CONFIG_BLK_DEV_LOOP=y -CONFIG_NLS_CODEPAGE_437=y -CONFIG_NLS_ISO8859_1=y - -CONFIG_RD_GZIP=y - -# Needed for booting (and using) CD images -CONFIG_BLK_DEV_SR=y diff --git a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg index e93c0b8..b101419 100644 --- a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg +++ b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg @@ -42,13 +42,3 @@ CONFIG_MODULES=y CONFIG_SHMEM=y CONFIG_TMPFS=y CONFIG_PACKET=y - -# Needed for booting (and using) USB memory sticks -CONFIG_BLK_DEV_LOOP=y -CONFIG_NLS_CODEPAGE_437=y -CONFIG_NLS_ISO8859_1=y - -CONFIG_RD_GZIP=y - -# Needed for booting (and using) CD images -CONFIG_BLK_DEV_SR=y diff --git a/meta/cfg/kernel-cache/bsp/emenlow/emenlow.cfg b/meta/cfg/kernel-cache/bsp/emenlow/emenlow.cfg index b9704c5..b1e72bd 100644 --- a/meta/cfg/kernel-cache/bsp/emenlow/emenlow.cfg +++ b/meta/cfg/kernel-cache/bsp/emenlow/emenlow.cfg @@ -40,13 +40,3 @@ CONFIG_MODULES=y CONFIG_SHMEM=y CONFIG_TMPFS=y CONFIG_PACKET=y - -# Needed for booting (and using) USB memory sticks -CONFIG_BLK_DEV_LOOP=y -CONFIG_NLS_CODEPAGE_437=y -CONFIG_NLS_ISO8859_1=y - -CONFIG_RD_GZIP=y - -# Needed for booting (and using) CD images -CONFIG_BLK_DEV_SR=y diff --git a/meta/cfg/kernel-cache/bsp/fishriver/fishriver.cfg b/meta/cfg/kernel-cache/bsp/fishriver/fishriver.cfg index e93c0b8..b101419 100644 --- a/meta/cfg/kernel-cache/bsp/fishriver/fishriver.cfg +++ b/meta/cfg/kernel-cache/bsp/fishriver/fishriver.cfg @@ -42,13 +42,3 @@ CONFIG_MODULES=y CONFIG_SHMEM=y CONFIG_TMPFS=y CONFIG_PACKET=y - -# Needed for booting (and using) USB memory sticks -CONFIG_BLK_DEV_LOOP=y -CONFIG_NLS_CODEPAGE_437=y -CONFIG_NLS_ISO8859_1=y - -CONFIG_RD_GZIP=y - -# Needed for booting (and using) CD images -CONFIG_BLK_DEV_SR=y diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2.cfg b/meta/cfg/kernel-cache/bsp/fri2/fri2.cfg index e93c0b8..b101419 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2.cfg +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2.cfg @@ -42,13 +42,3 @@ CONFIG_MODULES=y CONFIG_SHMEM=y CONFIG_TMPFS=y CONFIG_PACKET=y - -# Needed for booting (and using) USB memory sticks -CONFIG_BLK_DEV_LOOP=y -CONFIG_NLS_CODEPAGE_437=y -CONFIG_NLS_ISO8859_1=y - -CONFIG_RD_GZIP=y - -# Needed for booting (and using) CD images -CONFIG_BLK_DEV_SR=y diff --git a/meta/cfg/kernel-cache/bsp/sys940x/sys940x.cfg b/meta/cfg/kernel-cache/bsp/sys940x/sys940x.cfg index 3d45fe8..b101419 100644 --- a/meta/cfg/kernel-cache/bsp/sys940x/sys940x.cfg +++ b/meta/cfg/kernel-cache/bsp/sys940x/sys940x.cfg @@ -42,8 +42,3 @@ CONFIG_MODULES=y CONFIG_SHMEM=y CONFIG_TMPFS=y CONFIG_PACKET=y - -CONFIG_RD_GZIP=y - -# Needed for booting (and using) CD images -CONFIG_BLK_DEV_SR=y diff --git a/meta/cfg/kernel-cache/cfg/boot-live.cfg b/meta/cfg/kernel-cache/cfg/boot-live.cfg index 8ff7674..a102052 100644 --- a/meta/cfg/kernel-cache/cfg/boot-live.cfg +++ b/meta/cfg/kernel-cache/cfg/boot-live.cfg @@ -2,5 +2,8 @@ CONFIG_BLK_DEV_LOOP=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_VFAT_FS=y +CONFIG_RD_GZIP=y +# Needed for booting (and using) CD images CONFIG_BLK_DEV_IDECD=y CONFIG_ISO9660_FS=y +CONFIG_BLK_DEV_SR=y ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 4/6] eg20t: Enable serial console for the pch_uart
On 12-03-01 06:59 PM, Darren Hart wrote: From: Darren Hart The FRI2 uses the pch_uart driver for the serial console. Enable the console driver. It this safe for all eg20t users ? I see the crownbay also uses this. Bruce Signed-off-by: Darren Hart --- meta/cfg/kernel-cache/features/eg20t/eg20t.cfg |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/meta/cfg/kernel-cache/features/eg20t/eg20t.cfg b/meta/cfg/kernel-cache/features/eg20t/eg20t.cfg index ff2f6fd..3d4969c 100644 --- a/meta/cfg/kernel-cache/features/eg20t/eg20t.cfg +++ b/meta/cfg/kernel-cache/features/eg20t/eg20t.cfg @@ -3,6 +3,7 @@ CONFIG_PCH_DMA=y CONFIG_SERIAL_PCH_UART=y +CONFIG_SERIAL_PCH_UART_CONSOLE=y CONFIG_SERIAL_CORE=y CONFIG_SPI=y ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 5/6] fri2: Add SMP and EFI support
On 12-03-01 06:59 PM, Darren Hart wrote: From: Darren Hart Rather than add these as features in the linux-yocto recipe, include them in the BSP meta-data directly. Include only the core EFI bits in the fri2.scc, and add the extended EFI support to the fri2-standard.scc so that other ktypes don't pull in more than what's absolutely required from fri2.scc. Ack'd. Looks good. Bruce Signed-off-by: Darren Hart --- meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc |1 + meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc |1 + meta/cfg/kernel-cache/bsp/fri2/fri2.scc|2 ++ 3 files changed, 4 insertions(+), 0 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc index 142d71a..9e9a84c 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc @@ -5,3 +5,4 @@ define KARCH i386 # no new branch required, re-use the ktypes/preempt-rt branch include ktypes/preempt-rt include fri2.scc +include cfg/efi-ext.scc diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc index bbb0ebc..b17eca5 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc @@ -9,3 +9,4 @@ include features/emgd/emgd.scc git merge emgd include fri2.scc +include cfg/efi-ext.scc diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc index 2dd3170..a89a6e2 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc @@ -11,6 +11,8 @@ include cfg/vesafb.scc include cfg/usb-mass-storage.scc include cfg/boot-live.scc include features/power/intel.scc +include cfg/smp.scc +include cfg/efi.scc include features/logbuf/size-normal.scc ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 6/6] fri2: Move non-hardware optional features out of fri2.scc
On 12-03-01 06:59 PM, Darren Hart wrote: From: Darren Hart Move policy features out of fri2.scc and into the fri2-KTYPE.scc files. This allows KTYPEs like tiny to build smaller kernels while still reusing the fri2.scc file. Exactly. Good factoring of the options. I had one question on the series, but I've merged it all anyway. If we need to change the PCH console one, I'll revisit it later. Cheers, Bruce Signed-off-by: Darren Hart --- meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc |6 ++ meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc |6 ++ meta/cfg/kernel-cache/bsp/fri2/fri2.scc|6 -- 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc index 9e9a84c..1a9e638 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2-preempt-rt.scc @@ -5,4 +5,10 @@ define KARCH i386 # no new branch required, re-use the ktypes/preempt-rt branch include ktypes/preempt-rt include fri2.scc + +# default policy for preempt-rt kernels +include cfg/boot-live.scc +include features/logbuf/size-normal.scc +include features/latencytop/latencytop.scc +include features/profiling/profiling.scc include cfg/efi-ext.scc diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc index b17eca5..66b87ce 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc @@ -9,4 +9,10 @@ include features/emgd/emgd.scc git merge emgd include fri2.scc + +# default policy for standard kernels +include cfg/boot-live.scc +include features/logbuf/size-normal.scc +include features/latencytop/latencytop.scc +include features/profiling/profiling.scc include cfg/efi-ext.scc diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc index a89a6e2..62ad14b 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc @@ -9,12 +9,6 @@ include features/ericsson-3g/f5521gw.scc include features/iwlagn/iwlagn.scc include cfg/vesafb.scc include cfg/usb-mass-storage.scc -include cfg/boot-live.scc include features/power/intel.scc include cfg/smp.scc include cfg/efi.scc - -include features/logbuf/size-normal.scc - -include features/latencytop/latencytop.scc -include features/profiling/profiling.scc ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] [KERNEL] enable Cedarview config parameters
On 12-03-01 04:36 PM, Bodke, Kishore K wrote: Hi Bruce, We got the patches from Cedartrail Meego team and applied to Yocto/pvr branch. Below is the link where we have taken the patches from. http://build.meego.com/package/files?package=kernel-adaptation-pc&project=MeeGo%3A1.2.0%3ACedarTrail%3Aoss&rev=10 I'll update the header during the merge to have this reference. We have tested it on 3.0, but not yet tried on 3.2. In this case, I'll merge to 3.0, and we can do a forward propagation when we know 3.2 works. Bruce Thanks Kishore. -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Thursday, March 01, 2012 1:00 PM To: Bodke, Kishore K Cc: yocto@yoctoproject.org Subject: Re: [PATCH 0/1] [KERNEL] enable Cedarview config parameters On 12-02-29 07:13 PM, kishore.k.bo...@intel.com wrote: From: Kishore Bodke Hi, This patch is to enable Cedarview config parameters and add the kernel patches to the yocto/pvr branch in linux-yocto-3.0 and linux-yocto-3.2 tree. The patch itself looks ok. When merging features like this, we typically want the upstream reference. That makes carrying them much easier as we march forward. Where did these come from ? If we can get that in the header, that would be great. Often these patches can be broken up into subsystem chunks, but looking through this, the breaks would largely be artificial (unless there's an upstream repo we can leverage), so we can take a pass on breaking these into smaller parts. And you've tested the same content on 3.0 and 3.2 ? Cheers, Bruce Thanks Kishore. The following changes since commit 07e83cbd3e62a0bf91f558337aa7e37bc09f100b: Merge commit 'v3.0.22' into yocto/base (2012-02-26 00:02:48 -0500) are available in the git repository at: git://git.pokylinux.org/linux-yocto-2.6.37-contrib kishore/pvr-patch http://git.pokylinux.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=kishore/pvr-patch Kishore Bodke (1): enable Cedarview config parameters. drivers/staging/Kconfig|2 + drivers/staging/Makefile |1 + drivers/staging/cdv/Kconfig| 50 + drivers/staging/cdv/Makefile | 198 + drivers/staging/cdv/bc_video/bufferclass_video.c | 327 ++ drivers/staging/cdv/bc_video/bufferclass_video.h | 171 + .../staging/cdv/bc_video/bufferclass_video_linux.c | 838 .../staging/cdv/bc_video/bufferclass_video_linux.h | 67 + drivers/staging/cdv/drv/psb_bl.c | 135 + drivers/staging/cdv/drv/psb_dpst.c | 283 ++ drivers/staging/cdv/drv/psb_dpst.h | 98 + drivers/staging/cdv/drv/psb_drm.h | 562 +++ drivers/staging/cdv/drv/psb_drv.c | 1881 drivers/staging/cdv/drv/psb_drv.h | 1203 + drivers/staging/cdv/drv/psb_fb.c | 812 drivers/staging/cdv/drv/psb_fb.h | 59 + drivers/staging/cdv/drv/psb_gtt.c | 1045 + drivers/staging/cdv/drv/psb_gtt.h | 112 + drivers/staging/cdv/drv/psb_hotplug.c | 439 ++ drivers/staging/cdv/drv/psb_hotplug.h | 90 + drivers/staging/cdv/drv/psb_intel_bios.c | 289 ++ drivers/staging/cdv/drv/psb_intel_bios.h | 470 ++ drivers/staging/cdv/drv/psb_intel_crt.c| 353 ++ drivers/staging/cdv/drv/psb_intel_display.c| 1675 +++ drivers/staging/cdv/drv/psb_intel_display.h| 25 + drivers/staging/cdv/drv/psb_intel_dpll_cdv.c | 262 ++ drivers/staging/cdv/drv/psb_intel_drv.h| 252 + drivers/staging/cdv/drv/psb_intel_hdmi.c | 684 +++ drivers/staging/cdv/drv/psb_intel_hdmi.h | 935 drivers/staging/cdv/drv/psb_intel_hdmi_edid.h | 1057 + drivers/staging/cdv/drv/psb_intel_hdmi_reg.h | 130 + drivers/staging/cdv/drv/psb_intel_i2c.c| 171 + drivers/staging/cdv/drv/psb_intel_lvds.c | 701 +++ drivers/staging/cdv/drv/psb_intel_modes.c | 77 + drivers/staging/cdv/drv/psb_intel_opregion.c | 340 ++ drivers/staging/cdv/drv/psb_intel_reg.h| 1461 ++ drivers/staging/cdv/drv/psb_irq.c | 681 +++ drivers/staging/cdv/drv/psb_irq.h | 49 + drivers/staging/cdv/drv/psb_powermgmt.c| 875 drivers/staging/cdv/drv/psb_powermgmt.h| 98 + drivers/staging/cdv/drv/psb_pvr_glue.c | 74 + drivers/staging/cdv/drv/psb_pvr_glue.h | 26 + drivers/staging/cdv/drv/psb_reg.h | 596 +++ drivers/staging/cdv/drv/psb_reset.c| 144 + drivers/staging/cdv/drv/psb_schedule.c | 51 + drivers/staging/cdv/drv/psb_schedule.h | 79 + drivers/staging/cdv/
Re: [yocto] [PATCH 4/6] eg20t: Enable serial console for the pch_uart
On 03/02/2012 01:16 PM, Bruce Ashfield wrote: > On 12-03-01 06:59 PM, Darren Hart wrote: >> From: Darren Hart >> >> The FRI2 uses the pch_uart driver for the serial console. Enable the console >> driver. > > It this safe for all eg20t users ? I see the crownbay also > uses this. It is safe. The new code that this enables is machine specific. The console code would only kick in if the console is set to ttyPCH1, which it obviously isn't as that didn't work before. Shouldn't be a problem. -- Darren > Bruce > >> >> Signed-off-by: Darren Hart >> --- >> meta/cfg/kernel-cache/features/eg20t/eg20t.cfg |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/meta/cfg/kernel-cache/features/eg20t/eg20t.cfg >> b/meta/cfg/kernel-cache/features/eg20t/eg20t.cfg >> index ff2f6fd..3d4969c 100644 >> --- a/meta/cfg/kernel-cache/features/eg20t/eg20t.cfg >> +++ b/meta/cfg/kernel-cache/features/eg20t/eg20t.cfg >> @@ -3,6 +3,7 @@ >> CONFIG_PCH_DMA=y >> >> CONFIG_SERIAL_PCH_UART=y >> +CONFIG_SERIAL_PCH_UART_CONSOLE=y >> CONFIG_SERIAL_CORE=y >> >> CONFIG_SPI=y > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] proper recipe for building for beagle xM? meta-ti?
On 02/28/2012 05:28 PM, Robert P. J. Day wrote: On Tue, 28 Feb 2012, Koen Kooi wrote: Op 28 feb. 2012, om 22:55 heeft Robert P. J. Day het volgende geschreven: On Tue, 28 Feb 2012, Bruce Ashfield wrote: It is true that the beagleboard is a hardware reference board in the yocto consolidated kernel tree and meta-yocto layers. That means that it gets the yocto standard QA builds and boot testing. That being said, if you are looking for the latest + specific features then you've been pointed in a good direction .. meta-ti will meet your needs. As for disentangling and reducing questions in this area .. rest assured, we are working on it. ok, that's perfectly reasonable -- meta-yocto provides a generic, well-tested product, while the meta-ti layer provides more leading-edge content, correct? No, the amount of testing is not the difference, the amount of support for the board is. Meta-ti supports the camera interfaces, 3d engine, dsp, crypto engines, expansion boards, etc. Meta-yocto lacks all that for beagleboard. i understand that reasonably well, and i'll make one more observation, then i'll shut up. i cloned the meta-ti layer into my yocto clone, and here's the majority of the meta-ti README: = start This layer depends on: URI: git://git.openembedded.org/openembedded-core branch: master revision: HEAD URI: git://git.openembedded.org/meta-openembedded branch: master revision: HEAD URI: git://git.angstrom-distribution.org/meta-angstrom branch: master revision: HEAD Currently meta-ti only works with the Angstrom distribution and hence requires the meta-angstrom layer. There are known issues when using gcc-4.6 based toolchain from OpenEmbedded-Core, thus gcc-4.5 toolchain, provided by meta-openembedded, is needed. It is planned to fix these shortcomings in the near future and allow building the base BSP part of meta-ti with different distributions and layer stacks, such as: distro-less (only with OE-Core), with Yocto/Poky, with Angstrom or Arago. Due to the above, it is now recommended to follow the instructions at http://www.angstrom-distribution.org/building-angstrom This will set it up for the OpenEmbedded-core layout instead of the old "Classic" OpenEmbedded-dev layout. You can optionally tweak sources/layers.txt and conf/bblayers.conf to (de)select BSP layers. = end by the time i'm done reading that, i'm not sure whether i've been told i can use yocto as long as i do the necessary prep first, or that i should give up on yocto and just use angstrom directly. i'm fine with either approach, but the README seems to just waffle *totally* on which strategy to use. quite simply, that README seems to provide nothing but more confusion than anything else. Congratulations you are the first beta tester for the new README.txt language :) (patched two days ago). Denys: I suggest change: "Due to the above, it is now recommended to follow the instructions at http://www.angstrom-distribution.org/building-angstrom"; to: "When the other layer combinations are supported instructions will be supplied here. Until that time please see the Angstrom setup instructions below. *** Angstrom w/ meta-ti Layer Stack setup: *** Please follow the instructions at http://www.angstrom-distribution.org/building-angstrom"; etc. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] proper recipe for building for beagle xM? meta-ti?
On Fri, 2 Mar 2012, William Mills wrote: ... snip ... > Congratulations you are the first beta tester for the new README.txt > language :) (patched two days ago). > > Denys: I suggest > > change: > > "Due to the above, it is now recommended to follow the instructions > at http://www.angstrom-distribution.org/building-angstrom"; > > to: > > "When the other layer combinations are supported instructions will > be supplied here. Until that time please see the Angstrom setup > instructions below. > > *** Angstrom w/ meta-ti Layer Stack setup: *** > Please follow the instructions at > http://www.angstrom-distribution.org/building-angstrom"; i might try something a bit different. given that angstrom is the tested way to go, by all means, point that out and *strongly* recommend that approach. on the other hand, what is the current issue with the yocto/meta-ti combo? is it *known* to be broken? or is it simply not sufficiently tested? in cases like that, i see no problem in cautioning people about it, but telling them that if they're feeling adventurous, they're welcome to give it a shot but if it breaks, as they say, they get to keep all the pieces. don't discourage people from trying it, but make sure you give proper instructions for how to use it, that's all. unless, as i said, it's really and truly unusable. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] proper recipe for building for beagle xM? meta-ti?
On 03/02/2012 05:33 PM, Robert P. J. Day wrote: On Fri, 2 Mar 2012, William Mills wrote: ... snip ... Congratulations you are the first beta tester for the new README.txt language :) (patched two days ago). Denys: I suggest change: "Due to the above, it is now recommended to follow the instructions at http://www.angstrom-distribution.org/building-angstrom"; to: "When the other layer combinations are supported instructions will be supplied here. Until that time please see the Angstrom setup instructions below. *** Angstrom w/ meta-ti Layer Stack setup: *** Please follow the instructions at http://www.angstrom-distribution.org/building-angstrom"; i might try something a bit different. given that angstrom is the tested way to go, by all means, point that out and *strongly* recommend that approach. on the other hand, what is the current issue with the yocto/meta-ti combo? is it *known* to be broken? or is it simply not sufficiently tested? in cases like that, i see no problem in cautioning people about it, but telling them that if they're feeling adventurous, they're welcome to give it a shot but if it breaks, as they say, they get to keep all the pieces. don't discourage people from trying it, but make sure you give proper instructions for how to use it, that's all. unless, as i said, it's really and truly unusable. We will update the README when it is merely in need of testing. Today, we know there is code that does not work with GCC 4.6. Today, we know there are features in the recipes that do not work w/o Angstrom. As soon as we remove the above for even one platform we will update the README to reflect an Alpha state for oc-core &| poky layer stack for that platform(s). ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] proper recipe for building for beagle xM? meta-ti?
On 2012-03-02 15:50, William Mills wrote:
On 03/02/2012 05:33 PM, Robert P. J. Day wrote:
On Fri, 2 Mar 2012, William Mills wrote:
... snip ...
Congratulations you are the first beta tester for the new README.txt
language :) (patched two days ago).
Denys: I suggest
change:
"Due to the above, it is now recommended to follow the instructions
at http://www.angstrom-distribution.org/building-angstrom";
to:
"When the other layer combinations are supported instructions will
be supplied here. Until that time please see the Angstrom setup
instructions below.
*** Angstrom w/ meta-ti Layer Stack setup: ***
Please follow the instructions at
http://www.angstrom-distribution.org/building-angstrom";
i might try something a bit different. given that angstrom is the
tested way to go, by all means, point that out and *strongly*
recommend that approach.
on the other hand, what is the current issue with the yocto/meta-ti
combo? is it *known* to be broken? or is it simply not sufficiently
tested? in cases like that, i see no problem in cautioning people
about it, but telling them that if they're feeling adventurous,
they're welcome to give it a shot but if it breaks, as they say, they
get to keep all the pieces.
don't discourage people from trying it, but make sure you give
proper instructions for how to use it, that's all. unless, as i said,
it's really and truly unusable.
We will update the README when it is merely in need of testing.
Today, we know there is code that does not work with GCC 4.6.
Today, we know there are features in the recipes that do not work w/o Angstrom.
Can you elaborate on the above? I have been [I think] successfully using
poky+meta-ti
to support internal platform based on DM8148 and DM3730 - meta-ti is the best
choice
for a kernel "jumping off point" for these platforms. So far, I've only
had to make a scant few tweaks to get this combo to work, in particular:
* In conf/local.conf, I use this to avoid parsing problems with some meta-ti
recipes (none of which I need at the moment)
# Ignore troublesome TI recipes
BBMASK = ".*/meta-ti/recipes-misc/"
* In distro.conf (I do have my own distro, but it's very close to poky), I
needed
# Allow hardware overrides, e.g. armv7a
OVERRIDES .= ":${SOC_FAMILY}"
With these minor additions, I've been able to use the meta-ti layer for [some]
kernel work, u-boot, DSP support, etc - all the stuff one expects the layer
to provide.
I know my setup is a bit outside pure poky+meta-ti, but it does show that
you don't actually have to have Angstrom to use meta-ti.
It would be nice to understand what your concerns are, certainly the details
of your two "Today,..." statements above, if they fall outside what I've
outlined
here.
As soon as we remove the above for even one platform we will update the README to
reflect an Alpha state for oc-core &| poky layer stack for that platform(s).
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_qa_cofigure error message: host include and/or library paths while determining system capabilities
Hi Joshua, The error message however does not seem to print the correct problematic path.. but I was able to find the problem using your tips. Thanks ! Rahul -Original Message- From: Joshua Immanuel [mailto:j...@hipro.co.in] Sent: Thursday, March 01, 2012 7:52 PM To: Saxena, Rahul Cc: yocto@yoctoproject.org; Hart, Darren Subject: Re: [yocto] do_qa_cofigure error message: host include and/or library paths while determining system capabilities Hello Rahul, On Fri, 2012-03-02 at 02:00 +, Saxena, Rahul wrote: > Can someone explain the meaning of the following error: > > | ERROR: This autoconf log indicates errors, it looked at host include > and/or library paths while determining system capabilities. The insane.bbclass greps the config.log file for the strings like 'CROSS COMPILE Badness:', 'is unsafe for cross-compilation' to check for host contamination. If it finds any, it throws an error. So, you can check for yourself the config.log file and find the culprit :) Regards Joshua -- Joshua Immanuel HiPro IT Solutions Private Limited http://hipro.co.in ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] proper recipe for building for beagle xM? meta-ti?
On 03/02/2012 06:18 PM, Gary Thomas wrote: On 2012-03-02 15:50, William Mills wrote: On 03/02/2012 05:33 PM, Robert P. J. Day wrote: On Fri, 2 Mar 2012, William Mills wrote: ... snip ... Congratulations you are the first beta tester for the new README.txt language :) (patched two days ago). Denys: I suggest change: "Due to the above, it is now recommended to follow the instructions at http://www.angstrom-distribution.org/building-angstrom"; to: "When the other layer combinations are supported instructions will be supplied here. Until that time please see the Angstrom setup instructions below. *** Angstrom w/ meta-ti Layer Stack setup: *** Please follow the instructions at http://www.angstrom-distribution.org/building-angstrom"; i might try something a bit different. given that angstrom is the tested way to go, by all means, point that out and *strongly* recommend that approach. on the other hand, what is the current issue with the yocto/meta-ti combo? is it *known* to be broken? or is it simply not sufficiently tested? in cases like that, i see no problem in cautioning people about it, but telling them that if they're feeling adventurous, they're welcome to give it a shot but if it breaks, as they say, they get to keep all the pieces. don't discourage people from trying it, but make sure you give proper instructions for how to use it, that's all. unless, as i said, it's really and truly unusable. We will update the README when it is merely in need of testing. Today, we know there is code that does not work with GCC 4.6. Today, we know there are features in the recipes that do not work w/o Angstrom. Can you elaborate on the above? I have been [I think] successfully using poky+meta-ti to support internal platform based on DM8148 and DM3730 - meta-ti is the best choice for a kernel "jumping off point" for these platforms. So far, I've only had to make a scant few tweaks to get this combo to work, in particular: If we can make some simple changes (or document workarounds) that enable bare bones support for poky/oe-core that does not break full support in Angstrom, I'm all for it. Even if we have to limit it to a subset of boards. I'll try to give you a better answer Monday. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
